क्लाउड / सिस्टम
स्टैटिक वेबसाइट की खूबसूरती है कि उसमें बहुत कम झंझट होता है। पैच करने के लिए कोई एप्लिकेशन सर्वर नहीं, खत्म होने वाला डेटाबेस कनेक्शन पूल नहीं और चौबीसों घंटे चालू रखने वाली सार्वजनिक API नहीं। ब्राउज़र फ़ाइलें मांगता है; कंटेंट डिलीवरी नेटवर्क उन्हें लौटा देता है।
इसी सादगी ने इस पोर्टफ़ोलियो के लिए एक दिलचस्प सवाल खड़ा किया: क्या मैं दिखा सकता हूं कि साइट कहां पढ़ी जा रही है और समय के साथ अनुरोध कैसे बदल रहे हैं, बिना उसे डायनामिक एप्लिकेशन बनाए या निजी रहने वाली जानकारी प्रकाशित किए?
इसका जवाब CloudFront access logs, CloudWatch, Lambda, EventBridge और S3 में एक JSON ऑब्जेक्ट से बनी छोटी डेटा पाइपलाइन के रूप में मिला। विज़िटर दुनिया का नक्शा, देशों के कुल आंकड़े, लोकप्रिय पेज और अनुरोध दर के ग्राफ देखते हैं। उन्हें कच्चे लॉग, IP पते, user agents या किसी व्यक्ति का ब्राउज़िंग इतिहास नहीं मिलता।
वेबसाइट स्टैटिक ही रहती है। डेटा कहीं और तैयार होता है और एक और स्टैटिक फ़ाइल की तरह पहुंचता है।
एक अनुरोध के रास्ते से आर्किटेक्चर समझें
सार्वजनिक अनुरोध का रास्ता जानबूझकर छोटा रखा गया है:
- विज़िटर Amazon CloudFront के जरिए साइट खोलता है।
- CloudFront कैश में रखी फ़ाइलें भेजता है, जिनका निजी origin एक S3 bucket है।
- इसके बाद ब्राउज़र डाउनलोड करता है
content/public-visitors.jsonकिसी अन्य स्टैटिक एसेट की तरह। - क्लाइंट-साइड JavaScript उस अनाम दस्तावेज़ से नक्शा और ग्राफ बनाती है।
ब्राउज़र Lambda नहीं चलाता। वह CloudWatch से क्वेरी नहीं करता। उसके पास AWS क्रेडेंशियल नहीं हैं और वह अलग समय-अवधि या अधिक विस्तृत रिकॉर्ड नहीं मांग सकता। महंगा और संवेदनशील सारा काम सार्वजनिक अनुरोध के रास्ते से बाहर होता है।
पर्दे के पीछे डेटा का रास्ता इस तरह है:
CloudFront → CloudWatch Logs → scheduled Lambda → aggregated JSON → S3 → CloudFront → browser
यही अलगाव आर्किटेक्चर का सबसे अहम फैसला है। संचालन वाला सिस्टम विस्तृत access data पर काम कर सकता है; प्रकाशन वाला सिस्टम सिर्फ उतना हिस्सा निकालता है जितना सार्वजनिक रूप से दिखाना है।
इकट्ठा एक बार करें, प्रकाशित कम करें
CloudFront standard logging version 2 चुने हुए access-log फ़ील्ड CloudWatch Logs group में भेजता है। संचालन के लॉग में अनुरोधों और status codes की जांच के लिए पर्याप्त जानकारी होती है, लेकिन इसका मतलब यह नहीं कि वह सब सार्वजनिक डैशबोर्ड पर जाना चाहिए।
प्रकाशन फ़ंक्शन जानबूझकर डेटा को समेकित आंकड़ों तक सीमित करता है:
- देश के कोड के अनुसार सफल HTML पेज व्यू;
- सबसे ज्यादा मांगे गए HTML पाथ;
- समेकित HTTP status metrics से निकाले गए प्रति मिनट अनुरोध;
- अपडेट का टाइमस्टैम्प और हर समय-अवधि को समझाने वाले लेबल।
बनी हुई फ़ाइल में source IP पते, शहर-स्तर की लोकेशन, कुकीज़, user-agent strings या किसी विज़िटर की पूरी यात्रा पहचानने वाला क्रम नहीं होता। सार्वजनिक परिणाम यह बताता है कि साइट को कितना ट्रैफ़िक मिला, यह नहीं कि कौन आया।
इसीलिए मैं यह शब्द इस्तेमाल करता हूं: पेज व्यू, न कि लोग। एक पाठक कई अनुरोध बना सकता है। सर्च क्रॉलर, लिंक प्रीव्यू सेवाएं, मॉनिटरिंग जांच और दूसरी ऑटोमेशन भी इंसानों के ट्रैफ़िक के साथ दिख सकती हैं। डैशबोर्ड इन्फ्रास्ट्रक्चर के संकेत दिखाता है, पहचान नहीं।
बीच में CloudWatch क्यों है
CloudWatch उसी गतिविधि को दो उपयोगी रूपों में दिखाता है। CloudWatch Logs Insights संरचित अनुरोध रिकॉर्ड पर क्वेरी करके देश और पेज के समेकित आंकड़े निकाल सकता है। Metric filters चार HTTP status समूह—2xx, 3xx, 4xx और 5xx—गिनते हैं, जिससे हर बार सारे लॉग पढ़े बिना CloudWatch metrics से अनुरोध दर की समय-श्रृंखला बन सकती है।
सार्वजनिक डेटासेट में कई दृश्य हैं:
- पिछले 24 घंटे, 7 दिन और 30 दिन के देशवार कुल आंकड़े;
- 24 घंटे, 7 दिन, 30 दिन और 12 महीने के अनुरोध दर बिंदु;
- लंबी अवधियों के लिए बड़े समय-खंड, ताकि दस्तावेज़ छोटा रहे।
CloudFront logs रियल-टाइम इवेंट स्ट्रीम नहीं हैं। AWS के अनुसार standard logs आम तौर पर एक घंटे के भीतर पहुंचते हैं, लेकिन कुछ रिकॉर्ड देर से भी आ सकते हैं। इसलिए वे पिछले ट्रैफ़िक का ईमानदार डैशबोर्ड बनाने के लिए अच्छे हैं, लाइव विज़िटर काउंटर के लिए नहीं।
सार्वजनिक API की जगह तय समय पर स्नैपशॉट
EventBridge का एक नियम हर छह घंटे में प्रकाशन Lambda चलाता है। फ़ंक्शन सीमित क्वेरी करता है, metrics series लेता है, दस्तावेज़ तैयार करता है और S3 की ठीक एक key को अपडेट करता है: content/public-visitors.json.
छह घंटे का अंतर जानबूझकर रखा गया है। विज़िटर एनालिटिक्स को हर सेकंड ताजा होना जरूरी नहीं, और हर अपडेट लॉग डेटा स्कैन करता है। कम अंतर रखने से क्वेरी और लागत बढ़ेगी, लेकिन पेज उतना ज्यादा उपयोगी नहीं बनेगा।
JSON ऑब्जेक्ट ऐसे cache headers के साथ भेजा जाता है जो पुनः सत्यापन को ध्यान में रखते हैं। इसलिए होमपेज नया स्नैपशॉट खोज सकता है और CloudFront फिर भी S3 origin की रक्षा करता है। आंकड़े बदलने पर पूरी साइट दोबारा डिप्लॉय करने या ग्लोबल cache invalidation की जरूरत नहीं पड़ती।
इस स्नैपशॉट मॉडल में विफलता भी संभली हुई है। क्वेरी या Lambda invocation असफल हो तो पुराना स्टैटिक दस्तावेज़ उपलब्ध रहता है। डैशबोर्ड पुराना हो सकता है, लेकिन पोर्टफ़ोलियो चलता रहता है और कोई अनुरोध एनालिटिक्स पाइपलाइन का इंतजार नहीं करता।
कम से कम अधिकार, सीमित नुकसान
प्रकाशन Lambda का अपना अलग IAM role है। उसके जरूरी अधिकार जानबूझकर सीमित रखे गए हैं:
- सिर्फ तय access-log group पर क्वेरी चलाना और परिणाम लेना;
- अनुरोध दर के ग्राफ के लिए जरूरी CloudWatch metrics पढ़ना;
- सिर्फ यह लिखना
content/public-visitors.jsonसाइट bucket में; - अपने execution logs लिखना।
यह मनमानी साइट फ़ाइलें डिप्लॉय नहीं कर सकता, CloudFront distribution बदल नहीं सकता और S3 bucket को सार्वजनिक नहीं बना सकता। EventBridge को सिर्फ उसी तय नियम से इसी फ़ंक्शन को चलाने की अनुमति मिलती है।
साइट bucket खुद निजी रहती है। CloudFront, Origin Access Control से S3 को signed requests भेजता है। इससे विज़िटर distribution को छोड़कर bucket को सार्वजनिक फ़ाइल सर्वर की तरह इस्तेमाल नहीं कर सकते।
सार्वजनिक नक्शा जानबूझकर कम सटीक है
ज्यादा विस्तार वाला डैशबोर्ड हमेशा बेहतर सार्वजनिक डैशबोर्ड नहीं होता। शहर के मार्कर आकर्षक लगते हैं, लेकिन कम अनुरोधों की संख्या, सटीक समय और किसी परिचित व्यक्ति की जानकारी मिलकर पहचान खोल सकती है। देशवार कुल आंकड़े साइट की वैश्विक पहुंच बताने के लिए काफी हैं; उनसे किसी खास पाठक के रहने की जगह साबित होने का दावा नहीं होता।
डिज़ाइन भी इस सीमा को साफ रखता है। नक्शा देशों के अनुसार ट्रैफ़िक की तीव्रता और रैंकिंग दिखाता है। ठीक नीचे समझाया गया है कि अनुरोध संकेत हैं, लोग नहीं। इंटरफ़ेस किसी एक इवेंट का पूरा विवरण खोलने नहीं देता।
यह फर्क जरूरी है, क्योंकि सुंदर ग्राफ जरूरत से ज्यादा भरोसा पैदा कर सकते हैं। IP से मिला देश edge platform का एक अनुमान है। VPN, कंपनी नेटवर्क, मोबाइल ऑपरेटर, क्रॉलर और कैश किए प्रीव्यू के कारण पीछे की मानवीय कहानी कहीं अधिक जटिल होती है।
लागत दिखावट से नहीं, स्कैन किए गए डेटा से बढ़ती है
नक्शा और ग्राफ ब्राउज़र में बनते हैं, उसी कोड से जो स्टैटिक साइट पहले ही भेजती है। इसलिए उनका जटिल दिखना सर्वर-साइड रेंडरिंग का बिल नहीं बढ़ाता। असली संचालन लागत लॉग इकट्ठे करने और रखने, metrics लेने तथा तय समय की क्वेरी से लॉग स्कैन करने की है।
इसलिए लागत नियंत्रण डिज़ाइन में है, सजावट में नहीं:
- 30 दिन की log-retention policy डेटा को अनिश्चित समय तक बढ़ने से रोकती है;
- फ़ंक्शन दिन में सिर्फ चार बार चलता है;
- क्वेरी सीमित समय-अवधि और जरूरी फ़ील्ड ही मांगती हैं;
- लंबे ग्राफ के लिए metrics की बड़ी समय-अवधि इस्तेमाल होती है;
- प्रकाशित JSON फ़ाइल मूल लॉग की तुलना में बहुत छोटी है।
इस पैमाने पर Lambda का execution time और एक छोटे दस्तावेज़ का S3 storage बहुत कम खर्च करते हैं। ट्रैफ़िक या retention काफी बढ़े तो Logs Insights के scan volume पर नजर रखना ज्यादा जरूरी होगा।
इसे बनाने से मैंने क्या सीखा
स्टैटिक होने का मतलब अंधेरे में रहना नहीं है। ऑब्ज़र्वेबिलिटी स्टैटिक साइट के साथ रह सकती है, बिना उसके सीधे अनुरोध वाले रास्ते में आए।
समेकन एक सुरक्षा सीमा है। संचालन के लॉग से सार्वजनिक दस्तावेज़ तक बदलाव स्पष्ट, समीक्षा किया हुआ और एकतरफा होना चाहिए।
झूठे रियल-टाइम दावे से बेहतर है पर्याप्त ताजा डेटा। छह घंटे का स्नैपशॉट standard access logs की देरी के अनुकूल है और गैरजरूरी काम बचाता है।
विफलता में पिछली सही जानकारी बची रहनी चाहिए। एनालिटिक्स सेवा बंद होने से होमपेज टूटने के बजाय पुराना स्नैपशॉट दिखना बेहतर है।
ग्राफ के पास ही उसकी सीमाएं समझाएं। सार्वजनिक ग्राफ में bots, बार-बार आने वाले अनुरोध, भौगोलिक अनुमान और ट्रैफ़िक तथा लोगों के फर्क का संदर्भ जरूरी है।
मैं अलग डिज़ाइन कब चुनूंगा
यह तरीका मध्यम ट्रैफ़िक वाली निजी साइट और पहले से तय कुछ दृश्यों के लिए अच्छा है। अगर उपयोगकर्ताओं को मनचाही क्वेरी, लॉगिन वाला डैशबोर्ड, हर सेकंड ताजा डेटा या बड़े बहुआयामी डेटासेट चाहिए हों, तो मैं फिर विचार करूंगा। ऐसी जरूरतों के लिए API, अलग analytics store या managed visualization platform उचित हो सकता है।
इस पोर्टफ़ोलियो में वे चीजें उस समस्या को हल करेंगी जो मेरे पास है ही नहीं। एक scheduled function और एक static document उन खूबियों को बचाए रखते हैं जिनके लिए मैंने यह साइट बनाई: छोटा attack surface, अनुमान लगाने योग्य व्यवहार और आसानी से समझ आने वाले हिस्से।
मुख्य सीख
इस विज़िटर डैशबोर्ड का सबसे जरूरी हिस्सा दुनिया का नक्शा नहीं, उसके पीछे की सीमा है।
विस्तृत अनुरोध डेटा संचालन के निजी एनवायरनमेंट में रहता है। सीमित अधिकारों वाली प्रक्रिया समय-समय पर उसे अनाम समेकित आंकड़ों में बदलती है। वेबसाइट को सिर्फ एक छोटा स्टैटिक स्नैपशॉट मिलता है और ब्राउज़र उससे कहानी दिखाता है।
इससे साइट की गतिविधि दिखती है, बिना उसे कमजोर डायनामिक बैकएंड दिए।