​

AWS वास्तुकला अवलोकन

​

वास्तुकला आरेख

​

मुख्य घटक

​

1. नेटवर्किंग लेयर

​

DNS Provider

• उद्देश्य: डोमेन नाम रिज़ॉल्यूशन; किसी भी प्रदाता के साथ काम करता है (Route 53, Cloudflare, आदि)
• डोमेन (अपना स्वयं का डोमेन उपयोग करें, जैसे example.com):
  • app.example.com — वेब फ़्रंटएंड
  • api.example.com — FastAPI बैकएंड
  • automations.example.com — Automator सेवा
  • supabase.example.com — Supabase Kong (केवल सेल्फ़-होस्टेड)
  • signoz.example.com — SigNoz अवलोकन (वैकल्पिक)
• SSL सत्यापन: ACM DNS सत्यापन के लिए CNAME रिकॉर्ड्स आवश्यक

​

Application Load Balancer (ALB)

• उद्देश्य: SSL termination, लोड बैलेंसिंग और hostname-आधारित रूटिंग
• विशेषताएँ:
  • ACM प्रमाणपत्रों का उपयोग करके SSL/TLS termination (वाइल्डकार्ड या प्रति-सेवा)
  • HTTP → HTTPS रीडायरेक्ट
  • सभी लक्ष्य समूहों के लिए हेल्थ चेक्स
• द्वारा प्रबंधित: AWS Load Balancer Controller (helm-deployment/infrastructure में Helm chart)

​

VPC

• CIDR: वातावरण-विशिष्ट (जैसे 10.x.0.0/16)
• उपलब्धता क्षेत्र: चयनित क्षेत्र में 3 AZs
• सबनेट्स: 3 पब्लिक (NAT Gateways) + 3 प्राइवेट (EKS नोड्स)
• आउटबाउंड: नोड ईग्रेस के लिए प्रति AZ NAT Gateway

​

2. कम्प्यूट लेयर

​

EKS क्लस्टर

• संस्करण: Kubernetes 1.33
• सिस्टम Node Group: Karpenter कंट्रोलर चलाने वाला प्रबंधित node group (AWS बेस्ट प्रैक्टिस के अनुसार, Karpenter-प्रबंधित नोड्स पर नहीं)
• ऐड-ऑन्स: EBS CSI Driver, AWS Load Balancer Controller, CoreDNS, kube-proxy

​

Karpenter — गतिशील Node प्रोविज़निंग

• उद्देश्य: जस्ट-इन-टाइम node प्रोविज़निंग और लागत अनुकूलन
• Node Classes:
  • जनरल पर्पस: अधिकांश वर्कलोड के लिए Spot instances
  • कम्प्यूट इंटेंसिव: CPU-बाउंड टास्क के लिए हाई-CPU instances
  • मेमोरी इंटेंसिव: बड़े डेटासेट के लिए मेमोरी-अनुकूलित instances
  • डेटाबेस: स्टेटफुल/डेटाबेस वर्कलोड के लिए On-Demand instances
  • GPU: AI/ML वर्कलोड के लिए GPU instances (वैकल्पिक)
• विशेषताएँ: Spot प्राथमिकता, स्वचालित समेकन, SQS-आधारित interruption handling

​

KEDA — Kubernetes Event-Driven Autoscaling

• उद्देश्य: संसाधन मेट्रिक्स के आधार पर हॉरिज़ॉन्टल pod autoscaling
• लक्ष्य:

• स्केल-डाउन: तेज़ प्रतिक्रिया के लिए 30s स्थिरता विंडो

​

3. एप्लिकेशन सेवाएँ

​

वेब फ़्रंटएंड

• पोर्ट: 3000
• रेप्लिकास: 2–8 (KEDA-प्रबंधित)
• उद्देश्य: उपयोगकर्ता इंटरफ़ेस प्रदान करने वाला React एप्लिकेशन

​

FastAPI बैकएंड

• पोर्ट: 8001
• रेप्लिकास: 2–10 (KEDA-प्रबंधित)
• उद्देश्य: बिज़नेस लॉजिक और डेटा पहुँच को संभालने वाला REST API सर्वर

​

Celery Workers

• रेप्लिकास: 2–8 (KEDA-प्रबंधित)
• उद्देश्य: पृष्ठभूमि टास्क प्रोसेसिंग (RabbitMQ के माध्यम से क्यू किया गया)

​

Automator सेवा

• पोर्ट: 80
• रेप्लिकास: 2–8 (KEDA-प्रबंधित)
• उद्देश्य: वर्कफ़्लो स्वचालन और ऑर्केस्ट्रेशन

​

Supabase Kong

• पोर्ट: 8000 (आंतरिक क्लस्टर सेवा)
• उद्देश्य: सभी Supabase सेवाओं के लिए API gateway
• रूटिंग: बाहरी ट्रैफ़िक odin-services/main-ingress.yaml में परिभाषित ALB ingress के माध्यम से Kong तक पहुँचता है

​

SigNoz (वैकल्पिक)

• Namespace: monitoring
• घटक: SigNoz प्लेटफ़ॉर्म + k8s-infra DaemonSet agent
• उद्देश्य: वितरित tracing, मेट्रिक्स एकत्रीकरण, लॉग प्रबंधन
• सक्षम: ENABLE_SIGNOZ=true

​

4. डेटा लेयर

​

ElastiCache Redis

• उद्देश्य: कैशिंग, सत्र स्टोरेज, और Celery broker/result backend
• कॉन्फ़िगरेशन:
  • Node प्रकार: कॉन्फ़िगर करने योग्य (जैसे cache.t3.micro)
  • पोर्ट: 6379
  • रेस्ट और ट्रांज़िट में एन्क्रिप्शन
  • उच्च उपलब्धता के लिए Multi-AZ
• सक्षम: ENABLE_AWS_SERVICES=true

​

Amazon MQ (RabbitMQ)

• उद्देश्य: अतुल्यकालिक टास्क प्रोसेसिंग के लिए मैसेज क्यूइंग
• कॉन्फ़िगरेशन:
  • Engine: RabbitMQ
  • पोर्ट्स: 5671 (AMQP/SSL), 15671 (Management/SSL)
  • तैनाती मोड: सिंगल-इंस्टैंस या active/standby
• सक्षम: ENABLE_AWS_SERVICES=true

​

Supabase — विकल्प A: क्लाउड (प्रबंधित)

• उद्देश्य: बाहरी प्रबंधित PostgreSQL, Auth, Storage और Realtime
• कनेक्शन: values/odin-services.yaml में कॉन्फ़िगर किया गया Supabase प्रोजेक्ट URL और service role key

​

Supabase — विकल्प B: EKS पर सेल्फ़-होस्टेड

• उद्देश्य: क्लस्टर के अंदर चलने वाला पूर्ण Supabase स्टैक
• घटक:
  • CloudNativePG operator (cnpg-system) — Postgres क्लस्टर जीवनचक्र प्रबंधित करता है
  • HA Supabase DB (ha-supabase-db) — PgBouncer pooler के साथ CloudNativePG Cluster रिसोर्स
  • Supabase एप्लिकेशन (supabase namespace) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
• तैनाती क्रम: CloudNativePG → HA Supabase DB → Supabase ऐप
• सक्षम: ENABLE_CNPG=true, ENABLE_HA_SUPABASE_DB=true, ENABLE_SUPABASE=true

​

PostgreSQL Automator

• उद्देश्य: Automator सेवा के लिए स्थानीय PostgreSQL डेटाबेस
• पोर्ट: 5432
• स्टोरेज: EBS स्थायी volume
• Node affinity: डेटाबेस-समर्पित नोड्स

​

5. सुरक्षा और IAM

​

IAM भूमिकाएँ

​

सुरक्षा समूह

• ALB: AWS Load Balancer Controller द्वारा स्वतः बनाया गया (80/443 इनबाउंड)
• EKS Cluster: नोड-से-नोड और pod संचार
• Redis: केवल VPC CIDR से पोर्ट 6379
• RabbitMQ: केवल VPC CIDR से पोर्ट्स 5671, 15671

​

SSL/TLS

• Termination: ALB स्तर (pods आंतरिक रूप से प्लेन HTTP देखते हैं)
• प्रमाणपत्र: ACM प्रमाणपत्र — या तो प्रति-सेवा या एकल वाइल्डकार्ड
• सत्यापन: आपके DNS provider के माध्यम से DNS CNAME सत्यापन
• न्यूनतम प्रोटोकॉल: TLS 1.2

​

6. Infrastructure as Code

​

Terraform मॉड्यूल्स

• modules/eks: EKS क्लस्टर, VPC, node groups, Karpenter, IAM, Helm releases
• स्टेट: S3 bucket वर्शनिंग के साथ, DynamoDB lock table

​

Terragrunt

• वातावरण अलगाव: terragrunt/environments/ के अंतर्गत प्रति वातावरण एक निर्देशिका
• टेम्पलेट: env-template-folder — नया वातावरण बनाने के लिए कॉपी करें और placeholders भरें
• DRY कॉन्फ़िगरेशन: प्रति-वातावरण overrides के साथ साझा root.hcl
• सक्षम/अक्षम फ़्लैग्स: वातावरण चरों (ENABLE_*) के माध्यम से सेवाएँ टॉगल की जाती हैं

​

Helm Charts

​

डेटा प्रवाह

​

1. उपयोगकर्ता अनुरोध प्रवाह

उपयोगकर्ता → DNS → ALB (SSL termination) → EKS Pod (वेब फ़्रंटएंड)
                                   → EKS Pod (FastAPI बैकएंड)
                                   → EKS Pod (Supabase Kong)

1. उपयोगकर्ता app.example.com तक पहुँचता है
2. DNS ALB को रिज़ॉल्व करता है
3. ALB SSL को terminate करता है और hostname द्वारा सही लक्ष्य समूह में रूट करता है
4. वेब फ़्रंटएंड React ऐप प्रदान करता है और api.example.com पर API कॉल करता है
5. FastAPI बैकएंड अनुरोधों को प्रोसेस करता है और डेटा सेवाओं से पढ़ता/लिखता है

​

2. API अनुरोध प्रवाह

Client → ALB → FastAPI बैकएंड → Redis (कैश) / RabbitMQ (क्यू) / Supabase (DB)

1. Client api.example.com पर कॉल करता है
2. ALB FastAPI pod में रूट करता है
3. बैकएंड Redis कैश जाँचता है; मिस होने पर, Supabase डेटाबेस को क्वेरी करता है
4. अतुल्यकालिक टास्क RabbitMQ में क्यू किए जाते हैं और Celery Workers द्वारा प्रोसेस किए जाते हैं

​

3. पृष्ठभूमि प्रोसेसिंग प्रवाह

FastAPI → RabbitMQ → Celery Worker → Supabase DB

1. FastAPI RabbitMQ में एक टास्क क्यू करता है
2. Celery Worker टास्क को डीक्यू और प्रोसेस करता है
3. परिणाम Supabase डेटाबेस में वापस लिखे जाते हैं

​

4. Automator वर्कफ़्लो

Automator → PostgreSQL (स्थानीय) → Redis → बाहरी APIs

1. Automator एक वर्कफ़्लो अनुरोध प्राप्त करता है
2. वर्कफ़्लो स्टेट स्थानीय PostgreSQL instance में संग्रहीत होता है
3. Redis मध्यवर्ती परिणामों को कैश करता है
4. स्वचालन के भाग के रूप में बाहरी APIs कॉल की जाती हैं

​

5. स्केलिंग प्रवाह

मेट्रिक्स → KEDA → Pod स्केलिंग → Karpenter → Node प्रोविज़निंग

1. KEDA CPU/Memory मेट्रिक्स को कॉन्फ़िगर की गई सीमाओं के विरुद्ध मूल्यांकन करता है
2. Pods कॉन्फ़िगर की गई रेप्लिका रेंज के भीतर हॉरिज़ॉन्टली स्केल किए जाते हैं
3. यदि क्लस्टर क्षमता अपर्याप्त है, तो Karpenter नए EC2 नोड्स प्रोविज़न करता है (Spot को प्राथमिकता)
4. जब लोड कम होता है, KEDA pods को स्केल-डाउन करता है; Karpenter निष्क्रिय नोड्स को समेकित और समाप्त करता है

​

6. सुरक्षा प्रवाह

इंटरनेट → ALB (TLS 1.2+, ACM) → सुरक्षा समूह → Pods → IAM IRSA भूमिकाएँ → AWS APIs

1. सभी बाहरी ट्रैफ़िक ALB पर TLS को terminate करता है
2. सुरक्षा समूह न्यूनतम-विशेषाधिकार नेटवर्क पहुँच लागू करते हैं
3. Pods IRSA (IAM Roles for Service Accounts) के माध्यम से AWS सेवाओं के साथ संवाद करते हैं

​

उच्च उपलब्धता सारांश

​

लागत अनुकूलन

• Spot Instances: Karpenter गैर-डेटाबेस वर्कलोड के लिए Spot को प्राथमिकता देता है
• Node समेकन: Karpenter स्वचालित रूप से कम उपयोग वाले नोड्स को पुनः प्राप्त करता है
• Pod राइट-साइज़िंग: KEDA शांत अवधि के दौरान pods को स्केल-डाउन करता है
• केवल जहाँ आवश्यक On-Demand: डेटाबेस node class स्थिरता के लिए On-Demand का उपयोग करता है

​

रखरखाव और संचालन

​

तैनाती प्रक्रिया

cd terragrunt/environments/<your-env-name>
# आवश्यक ENABLE_* और domain/certificate वातावरण चर सेट करें
terragrunt apply
# रोलिंग अपडेट: image tags या values files अपडेट करने के बाद पुनः लागू करें

​

बैकअप रणनीति

• EBS Snapshots: स्थायी volumes (Automator DB, Supabase MinIO) के लिए स्वचालित snapshots
• CloudNativePG: लगातार WAL archiving + अनुसूचित base backups (यदि कॉन्फ़िगर किया गया)
• Supabase Cloud: प्रबंधित दैनिक बैकअप (क्लाउड विकल्प)
• IaC स्टेट: S3 वर्शन्ड bucket

​

आपदा वसूली

• Multi-AZ: सभी स्टेटफुल सेवाएँ कई उपलब्धता क्षेत्रों में फैली हुई हैं
• CloudNativePG HA: Postgres primary और replicas के बीच स्वचालित failover
• Supabase Cloud: क्रॉस-क्षेत्र रिडंडेंसी (क्लाउड विकल्प)
• Terraform स्टेट: S3 वर्शनिंग किसी भी पिछली स्थिति में वापस जाने की अनुमति देता है

​

अतिरिक्त संसाधन

• AWS Load Balancer Controller
• Karpenter दस्तावेज़ीकरण
• KEDA दस्तावेज़ीकरण
• CloudNativePG दस्तावेज़ीकरण
• Supabase सेल्फ़-होस्टिंग
• SigNoz दस्तावेज़ीकरण
• Terragrunt तैनाती गाइड