एक bucket के मालिक दो हों, तो आखिरी apply करने वाला जीतता है

शुरुआत एक मामूली सफाई की समस्या से हुई। उपयोगकर्ता जिस रास्ते से media files (recording, image) अपलोड करते हैं, वह presigned URL वाला तरीका है। server upload के लिए URL जारी करता है, client सीधे S3 पर फ़ाइल चढ़ाता है, फिर commit API call करके बताता है कि "इस key को औपचारिक asset के रूप में दर्ज कर लो"। दिक्कत तब है जब presign तो मिल गया पर commit कभी नहीं आया। app बीच में crash हो जाए, network कट जाए, या user screen छोड़ दे, तो bucket में एक ऐसा object रह जाता है जो कहीं भी दर्ज नहीं है।

मैं इसे lifecycle rule से साफ करना चाहता था, पर rule लगा ही नहीं सकता था। commit हो चुके और न हुए objects एक ही prefix में घुले-मिले थे, इसलिए "पुराना है तो मिटा दो" कहने वाला rule औपचारिक assets को भी मिटा देता। daily upload quota बढ़ोतरी को रोके हुए तो था, पर recovery का कोई रास्ता नहीं है, यह तथ्य जस का तस था।

डिज़ाइन: जो commit नहीं हुआ, वह tmp में रहता है

समाधान की रीढ़ है key namespace का बँटवारा।

1. presign tmp/ prefix के साथ अस्थायी key जारी करता है।
2. commit जब validation (HEAD से existence check, Content-Type, size की ऊपरी सीमा) पार कर लेता है, तो CopyObject से object को औपचारिक key पर promote करता है और tmp वाला original मिटा देता है।
3. जिस object का commit आखिर तक नहीं आया, वह tmp/ में पड़ा रहता है और lifecycle rule उसे 7 दिन बाद expire कर देता है।

इस तरह lifecycle को सिर्फ tmp/ देखना है। औपचारिक assets शुरू से ही rule की पहुंच से बाहर हैं। client बदलने की जरूरत नहीं पड़ी। तीनों upload flows पूरे पढ़कर पुष्टि की, सब commit response में आई key को ही आगे के calls में इस्तेमाल करते हैं, इसलिए server key का रूप बदल दे तो भी उन्हें पता नहीं चलता। deploy के वक्त हवा में तैर रही पुरानी शक्ल वाली keys का commit भी पुराने रास्ते से वैसे ही process होता है।

यहां एक जाल है। इस bucket पर versioning चालू है। versioned bucket में expiration object को मिटाता नहीं, बस delete marker चढ़ा देता है, और असली bytes noncurrent version बनकर पड़े रहते हैं। noncurrent_version_expiration (1 दिन) को जोड़ी में न लगाएं तो सफाई करते रहिए, storage एक byte भी नहीं घटता।

design review भी काम आया। promotion logic पर review बिठाया तो तीन पक्के defects निकले। admin के custom key path से tmp/ key को final key के तौर पर commit कर दें तो lifecycle live asset को उड़ा देगा वाला छेद (shared commit boundary पर tmp final key block की), promotion का sourceKey एक arbitrary copy primitive बन जाने की समस्या (tmp और final key की बराबरी enforce की), और एक ही tmp key का एक साथ commit हो तो एक तरफ का copy 404 से मर जाता है वाली idempotency समस्या। तीनों को code में ठीक करके आगे बढ़ा।

और फिर apply fail हो गया

lifecycle rule को terraform में जोड़कर merge किया। staging apply fail हो गया।

error था lifecycle configuration write का timeout, पर खोदने पर निकला कि timeout तो लक्षण है, बीमारी structure में है। इस bucket की lifecycle के मालिक दो terraform resources थे। एक image resize module के अंदर था (module अपने काम के rules खुद लगाता था), दूसरा environment-wise bucket configuration file में (जहां इस बार tmp rule जोड़ा गया)। एक ही physical bucket, मालिक दो।

S3 के lifecycle API में "एक rule जोड़ना" नाम की कोई चीज़ नहीं है। PutBucketLifecycleConfiguration पूरा document बदल देता है। terraform का aws_s3_bucket_lifecycle_configuration भी उसी पर खड़ा है, इसलिए यह resource अपनी जानकारी के rules से bucket का पूरा lifecycle document overwrite करता है। मालिक दो हों तो हर एक सिर्फ अपने rules वाला document एक-दूसरे पर ठेलता है। एक ही apply में दोनों मिलें तो concurrent write से timeout आता है, और अलग-अलग मिलें तो और बुरा। बिना किसी error के success दिखाते हुए आखिरी विजेता दूसरे के rules मिटा देता है।

इस पूरे किस्से का सबसे सिहरा देने वाला हिस्सा यही है। timeout तो शोर मचाने वाली विफलता थी, एक तरह से गनीमत। यह structure जिंदा रह जाता, तो अगली बार image resize module को छूने वाला कोई भी apply अभी-अभी डाला गया tmp expiration rule चुपचाप मिटा देता। plan में वह बस उस bucket resource के in-place update की एक पंक्ति भर दिखता, और uncommitted objects फिर हमेशा के लिए जमा होने लगते। सफाई का rule गायब हो गया है, यह पकड़ने वाली कोई monitoring कहीं नहीं थी।

दरअसल इस बिंदु पर code review के दौर में एक बार उंगली उठ भी चुकी थी, "लगता है दो resources एक ही bucket को छू रहे हैं" वाले शक के रूप में। तब उसे potential risk मानकर रख दिया गया, पर merge के फ़ौरन बाद apply fail हुआ और potential को reality बनने में चंद मिनट भी नहीं लगे।

समाधान: मालिक एक ही हो

सुधार की दिशा साफ थी। per bucket lifecycle का मालिक एक ही होना चाहिए। module से lifecycle resource हटाया, environment configuration file को single owner बनाया और module जो rules लगाता था उन्हें भी उधर ही ले गया।

यहां जो औज़ार काम आया वह है terraform का removed block। module से resource declaration यूं ही मिटा दें तो terraform असली lifecycle configuration को destroy करने दौड़ता है। यानी अभी live चल रहे rules को मिटाकर दोबारा बनाने की एक window खुल जाती। removed block में destroy = false दें तो terraform उस resource को सिर्फ state में भूलता है। असल चीज़ जस की तस रहती है, सिर्फ बही-खाते से नाम कटता है, और ownership बिना downtime के environment configuration की तरफ चली जाती है।

सुधार के बाद staging apply पास हुआ, prod तक पहुंचाने के बाद AWS API से असली bucket state खुद जाकर देखी। दोनों buckets में tmp expiration rule जिंदा था और पहले के तीनों rules भी सही-सलामत। सिर्फ terraform plan देखकर क्यों नहीं रुका, यह इसी घटना ने सिखाया था। plan हर मालिक का अपना बही-खाता भर है, और document overwrite करने वाले structure में दो बही-खाते एक-दूसरे को जानते ही नहीं।

जो सीख बची

document स्तर के resource का मालिक एक ही होना चाहिए। बात सिर्फ S3 lifecycle की नहीं है। bucket policy, CORS configuration, notification configuration जैसे "पूरा बदल दो" वाले API पर खड़े सारे terraform resources का यही स्वभाव है। एक ही target की ओर इशारा करती declarations module और environment configuration में एक-एक हों, तो compile error की जगह runtime का चुपचाप overwrite मिलता है। नया rule जोड़ने से पहले यह खोजना चाहिए कि उस document का कोई मालिक पहले से तो नहीं बैठा है।

एक और बात। resource declaration मिटाना और असल चीज़ मिटाना दो अलग काम हैं, और terraform यह फ़र्क removed block से जताता है। मकसद ownership transfer हो, तो destroy से गुज़रते ही zero-downtime टूट जाता है।

आखिर में, recovery का रास्ता key design से शुरू होता है। "commit हुआ और नहीं हुआ" जैसे अलग-अलग उम्र वाले data एक ही namespace में रहें, तो कोई भी सफाई का rule सुरक्षित तरीके से नहीं लग सकता। उम्र अलग है तो पहले रहने की जगह अलग करनी चाहिए। वैसे यह तरीका पहले से जमा हो चुके uncommitted objects को पीछे जाकर वापस नहीं ला पाता। उन objects को औपचारिक assets से अलग पहचानने का कोई तरीका ही नहीं (यही तो इस पूरी समस्या का शुरुआती बिंदु था), इसलिए जानबूझकर नई uploads से लागू होने का दायरा चुना।