このドキュメントでは、EKB サービスインフラストラクチャの AWS アーキテクチャの包括的な概要を説明します。このアーキテクチャは、AWS マネージドサービス、Kubernetes オーケストレーション、自動スケーリングを備えたクラウドネイティブパターンに従っています。

AWS アーキテクチャの概要

このアーキテクチャは、AWS マネージドサービス、Kubernetes オーケストレーション、自動スケーリングを備えたクラウドネイティブパターンに従っています。

アーキテクチャ図```mermaid

flowchart TD INTERNET[”🌐 INTERNET”] DNS[“DNS Provider\n(Route 53 / Cloudflare / etc.)\n──────────────────────────────\n• app.your-domain — Web Frontend\n• api.your-domain — FastAPI Backend\n• automations.your-domain — Automator\n• supabase.your-domain — Supabase Kong\n• signoz.your-domain — SigNoz”] ALB[“APPLICATION LOAD BALANCER\n──────────────────────────────\n• SSL Termination via ACM\n• HTTP → HTTPS Redirect\n• Health Checks & Target Groups\n• Routing by hostname/path”] subgraph VPC[“VPC”] subgraph PUB[“Public Subnets (3 AZs)”] NAT[“NAT Gateway × 3”] end subgraph PRIV[“Private Subnets (3 AZs)”] NODES[“EKS Worker Nodes”] end end subgraph EKS[“EKS CLUSTER”] KARPENTER[“KARPENTER — Dynamic Node Provisioning\n──────────────────────────────\n• Spot prioritisation & consolidation\n• Interruption handling via SQS\n• Node classes: general, compute-intensive, database”] KEDA[“KEDA — Event-driven Pod Autoscaling\n──────────────────────────────\n• CPU / Memory threshold scaling\n• Fast scale-down stabilisation”] PODS[“APPLICATION PODS\n──────────────────────────────\n• Web Frontend (port 3000)\n• FastAPI Backend (port 8001)\n• Celery Workers\n• Automator (port 80)\n• Supabase services (Kong, Auth, Storage…)\n• PostgreSQL Automator (port 5432)”] SIGNOZ[“OBSERVABILITY — SigNoz (optional)\n──────────────────────────────\n• Distributed tracing, metrics, logs\n• k8s-infra agent for cluster metrics”] end subgraph DATA[“DATA LAYER”] REDIS[“ELASTICACHE\n(Redis)\n──────────\n• Encryption\n• Multi-AZ\n• Port 6379”] MQ[“AMAZON MQ\n(RabbitMQ)\n──────────\n• Async queue\n• AMQP/SSL\n• Port 5671”] SUPABASE[“SUPABASE\n(DB / Auth)\n──────────\nOption A: Cloud\nOption B: Self-hosted\nvia CNPG HA on EKS”] end INTERNET —> DNS DNS —> ALB ALB —> VPC PUB —> PRIV PRIV —> EKS EKS —> DATA

Self-hosted Supabase uses a CloudNativePG-managed HA PostgreSQL cluster (__PLACEHOLDER_0__) with PgBouncer pooling, MinIO for object storage, and the full Supabase application stack deployed via __PLACEHOLDER_1__. Supabase Cloud is the alternative if self-hosting is not required.
</Info>
---
 
## Key Components
 
### 1. Networking Layer
 
#### DNS Provider
 
- **Purpose:** Domain name resolution; works with any provider (Route 53, Cloudflare, etc.)
- **Domains** (use your own domain, e.g. `example.com`):
  - `app.example.com` — Web Frontend
  - `api.example.com` — FastAPI Backend
  - `automations.example.com` — Automator Service
  - `supabase.example.com` — Supabase Kong (self-hosted only)
  - `signoz.example.com` — SigNoz observability (optional)
- **SSL Validation:** CNAME records required for ACM DNS validation
 
#### Application Load Balancer (ALB)
 
- **Purpose:** SSL termination, load balancing, and hostname-based routing
- **Features:**
  - SSL/TLS termination using ACM certificates (wildcard or per-service)
  - HTTP → HTTPS redirect
  - Health checks for all target groups
- **Managed by:** AWS Load Balancer Controller (Helm chart in `helm-deployment/infrastructure`)
 
#### VPC
 
- **CIDR:** Environment-specific (e.g. `10.x.0.0/16`)
- **Availability Zones:** 3 AZs in the chosen region
- **Subnets:** 3 public (NAT Gateways) + 3 private (EKS nodes)
- **Outbound:** NAT Gateway per AZ for node egress
 
---
 
### 2. Compute Layer
 
#### EKS Cluster
 
- **Version:** Kubernetes 1.33
- **System Node Group:** Managed node group running Karpenter controller (not on Karpenter-managed nodes, per AWS best practice)
- **Add-ons:** EBS CSI Driver, AWS Load Balancer Controller, CoreDNS, kube-proxy
 
#### Karpenter — Dynamic Node Provisioning
 
- **Purpose:** Just-in-time node provisioning and cost optimisation
- **Node Classes:**
  - **General Purpose:** Spot instances for most workloads
  - **Compute Intensive:** High-CPU instances for CPU-bound tasks
  - **Memory Intensive:** Memory-optimised instances for large datasets
  - **Database:** On-demand instances for stateful/database workloads
  - **GPU:** GPU instances for AI/ML workloads (optional)
- **Features:** Spot prioritisation, automatic consolidation, SQS-based interruption handling
 
#### KEDA — Kubernetes Event-Driven Autoscaling
 
- **Purpose:** Horizontal pod autoscaling based on resource metrics
- **Targets:**
 
| Service | Replicas | CPU Threshold | Memory Threshold __PLACEHOLDER_51__ Web Frontend | 2–8 | 60% | 80% __PLACEHOLDER_52__ FastAPI Backend | 2–10 | 70% | 80% __PLACEHOLDER_53__ Celery Workers | 2–8 | 70% | 80% __PLACEHOLDER_54__ Automator | 2–8 | 70% | 80% |
 
- **Scale-down:** 30s stabilisation window for fast response
 
---
 
### 3. Application Services
 
#### Web Frontend
 
- **Port:** 3000
- **Replicas:** 2–8 (KEDA-managed)
- **Purpose:** React application serving the user interface
 
#### FastAPI Backend
 
- **Port:** 8001
- **Replicas:** 2–10 (KEDA-managed)
- **Purpose:** REST API server handling business logic and data access
 
#### Celery Workers
 
- **Replicas:** 2–8 (KEDA-managed)
- **Purpose:** Background task processing (queued via RabbitMQ)
 
#### Automator Service
 
- **Port:** 80
- **Replicas:** 2–8 (KEDA-managed)
- **Purpose:** Workflow automation and orchestration
 
#### Supabase Kong
 
- **Port:** 8000 (internal cluster service)
- **Purpose:** API gateway for all Supabase services
- **Routing:** External traffic reaches Kong via the ALB ingress defined in `odin-services/main-ingress.yaml`
 
#### SigNoz (optional)
 
- **Namespace:** `monitoring`
- **Components:** SigNoz platform + k8s-infra DaemonSet agent
- **Purpose:** Distributed tracing, metrics aggregation, log management
- **Enabled by:** `ENABLE_SIGNOZ=true`
 
---
 
### 4. Data Layer
 
#### ElastiCache Redis
 
- **Purpose:** Caching, session storage, and Celery broker/result backend
- **Configuration:**
  - Node type: configurable (e.g. `cache.t3.micro`)
  - Port: `6379`
  - Encryption at-rest and in-transit
  - Multi-AZ for high availability
- **Enabled by:** `ENABLE_AWS_SERVICES=true`
 
#### Amazon MQ (RabbitMQ)
 
- **Purpose:** Message queuing for asynchronous task processing
- **Configuration:**
  - Engine: RabbitMQ
  - Ports: `5671` (AMQP/SSL), `15671` (Management/SSL)
  - Deployment mode: single-instance or active/standby
- **Enabled by:** `ENABLE_AWS_SERVICES=true`
 
#### Supabase — Option A: Cloud (managed)
 
- **Purpose:** External managed PostgreSQL, Auth, Storage, and Realtime
- **Connection:** Supabase project URL and service role key configured in `values/odin-services.yaml`
 
#### Supabase — Option B: Self-hosted on EKS
 
- **Purpose:** Full Supabase stack running inside the cluster
- **Components:**
  - CloudNativePG operator (`cnpg-system`) — manages the Postgres cluster lifecycle
  - HA Supabase DB (`ha-supabase-db`) — CloudNativePG Cluster resource with PgBouncer pooler
  - Supabase application (`supabase` namespace) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
- **Deployment order:** CloudNativePG → HA Supabase DB → Supabase app
- **Enabled by:** `ENABLE_CNPG=true`, `ENABLE_HA_SUPABASE_DB=true`, `ENABLE_SUPABASE=true`
 
#### PostgreSQL Automator
 
- **Purpose:** Local PostgreSQL database for the Automator service
- **Port:** 5432
- **Storage:** EBS persistent volume
- **Node affinity:** Database-dedicated nodes
 
---
 
### 5. Security & IAM
 
#### IAM Roles
 
| Role | Purpose __PLACEHOLDER_55__ EKS Cluster Role | Cluster-level API permissions __PLACEHOLDER_56__ Node Group Role | EC2 node permissions (ECR, SSM, networking) __PLACEHOLDER_57__ Karpenter Controller Role | EC2 provisioning, SQS interruption queue __PLACEHOLDER_58__ AWS Load Balancer Controller Role | ELBv2 and EC2 management __PLACEHOLDER_59__ EBS CSI Driver Role | EBS volume lifecycle management |
 
Role names follow the pattern `<env-name>-<component>` and are created by the EKS Terraform module.
 
#### Security Groups
 
- **ALB:** Auto-created by AWS Load Balancer Controller (80/443 inbound)
- **EKS Cluster:** Node-to-node and pod communication
- **Redis:** Port 6379 from VPC CIDR only
- **RabbitMQ:** Ports 5671, 15671 from VPC CIDR only
 
#### SSL/TLS
 
- **Termination:** ALB level (pods see plain HTTP internally)
- **Certificates:** ACM certificates — either per-service or a single wildcard
- **Validation:** DNS CNAME validation via your DNS provider
- **Minimum protocol:** TLS 1.2
 
---
 
### 6. Infrastructure as Code
 
#### Terraform Modules
 
- **`modules/eks`:** EKS cluster, VPC, node groups, Karpenter, IAM, Helm releases
- **State:** S3 bucket with versioning, DynamoDB lock table
 
#### Terragrunt
 
- **Environment isolation:** One directory per environment under `terragrunt/environments/`
- **Template:** `env-template-folder` — copy and fill placeholders to create a new environment
- **DRY configuration:** Shared `root.hcl` with per-environment overrides
- **Enable/disable flags:** Services toggled via environment variables (`ENABLE_*`)
 
#### Helm Charts
 
| Chart | Namespace | Description __PLACEHOLDER_60__ __PLACEHOLDER_32__ | __PLACEHOLDER_33__ | ALB Controller __PLACEHOLDER_61__ __PLACEHOLDER_34__ | __PLACEHOLDER_35__ | Web, API, Workers, Automator, Ingress __PLACEHOLDER_62__ __PLACEHOLDER_36__ | __PLACEHOLDER_37__ | EBS volume provisioning __PLACEHOLDER_63__ __PLACEHOLDER_38__ | __PLACEHOLDER_39__ | Pod autoscaling __PLACEHOLDER_64__ __PLACEHOLDER_40__ | __PLACEHOLDER_41__ | PostgreSQL operator __PLACEHOLDER_65__ __PLACEHOLDER_42__ | __PLACEHOLDER_43__ | HA Postgres cluster + PgBouncer __PLACEHOLDER_66__ __PLACEHOLDER_44__ | __PLACEHOLDER_45__ | Full Supabase stack __PLACEHOLDER_67__ __PLACEHOLDER_46__ | __PLACEHOLDER_47__ | Observability platform __PLACEHOLDER_68__ __PLACEHOLDER_48__ | __PLACEHOLDER_49__ | Cluster metrics agent |
 
---
 
## Data Flow
 
### 1. User Request Flow```
User → DNS → ALB (SSL termination) → EKS Pod (Web Frontend)
                                   → EKS Pod (FastAPI Backend)
                                   → EKS Pod (Supabase Kong)
```1. ユーザーは `app.example.com` にアクセスします
2. DNS は ALB に解決されます
3. ALB は SSL を終了し、ホスト名によって正しいターゲット グループにルーティングします。
4. Web フロントエンドは React アプリを提供し、`api.example.com` への API 呼び出しを行います。
5. FastAPI バックエンドはリクエストを処理し、データ サービスへの読み取り/書き込みを行います。
 
### 2. APIリクエストフロー```
Client → ALB → FastAPI Backend → Redis (cache) / RabbitMQ (queue) / Supabase (DB)
```1. クライアントが `api.example.com` を呼び出します
2. ALB が FastAPI ポッドにルーティングする
3. バックエンドは Redis キャッシュをチェックします。ミスの場合、Supabase データベースにクエリを実行します
4. 非同期タスクは RabbitMQ のキューに入れられ、Celery Workers によって処理されます
 
### 3. バックグラウンド処理の流れ```
FastAPI → RabbitMQ → Celery Worker → Supabase DB
```1. FastAPI は RabbitMQ のタスクをキューに入れます
2. Celery Worker がタスクをデキューして処理します
3. 結果は Supabase データベースに書き戻されます
 
### 4. オートメータのワークフロー```
Automator → PostgreSQL (local) → Redis → External APIs
```1. Automator がワークフロー リクエストを受信します
2. ワークフローの状態はローカルの PostgreSQL インスタンスに保持されます
3. Redis は中間結果をキャッシュします
4. 外部 API は自動化の一部として呼び出されます。
 
### 5. スケーリングフロー```
Metrics → KEDA → Pod scaling → Karpenter → Node provisioning
```1. KEDA は、設定されたしきい値に対して CPU/メモリ メトリックを評価します。
2. ポッドは構成されたレプリカ範囲内で水平方向にスケーリングされます。
3. クラスターの容量が不十分な場合、Karpenter は新しい EC2 ノードをプロビジョニングします (スポットを優先します)。
4. 負荷が低下すると、KEDA はポッドをスケールダウンします。 Karpenter はアイドル状態のノードを統合して終了します
 
### 6. セキュリティフロー```
Internet → ALB (TLS 1.2+, ACM) → Security Groups → Pods → IAM IRSA roles → AWS APIs
```1. すべての外部トラフィックは ALB で TLS を終了します
2. セキュリティ グループは最小特権のネットワーク アクセスを強制します
3. ポッドは IRSA (サービス アカウントの IAM ロール) 経由で AWS サービスと通信します。
 
---
 
## 高可用性の概要
 
| Feature | Implementation __PLACEHOLDER_0__ Multi-AZ deployment | 3 AZs for EKS nodes, Redis, subnets __PLACEHOLDER_1__ Load balancing | ALB with multiple target groups __PLACEHOLDER_2__ Pod redundancy | Minimum 2 replicas per service __PLACEHOLDER_3__ Database HA | CloudNativePG cluster with PgBouncer (self-hosted) or Supabase Cloud __PLACEHOLDER_4__ Cache redundancy | ElastiCache Multi-AZ __PLACEHOLDER_5__ Node autoscaling | Karpenter with Spot + On-Demand mix __PLACEHOLDER_6__ Pod autoscaling | KEDA CPU/Memory-based __PLACEHOLDER_7__ Observability | SigNoz (optional) __PLACEHOLDER_8__ State management | S3 with versioning + DynamoDB lock |
 
---
 
## コストの最適化
 
- **スポット インスタンス:** Karpenter は、データベース以外のすべてのワークロードに対してスポットを優先します。
- **ノードの統合:** Karpenter は、十分に活用されていないノードを自動的に回収します。
- **ポッドの適切なサイジング:** KEDA は、静かな期間にポッドをスケールダウンします。
- **必要な場合のみオンデマンド:** データベース ノード クラスは安定性を確保するためにオンデマンドを使用します
 
---
 
## メンテナンスと運用
 
### 導入プロセス```bash
cd terragrunt/environments/<your-env-name>
# Set required ENABLE_* and domain/certificate environment variables
terragrunt apply
# Rolling updates: re-apply after updating image tags or values files
```完全な展開シーケンスについては、[Terragrunt Deployment Guide](/on-premise/kubernetes-deployment/terragrunt-deployment.mdx) を参照してください。
 
### バックアップ戦略
 
- **EBS スナップショット:** 永続ボリュームの自動スナップショット (Automator DB、Supabase MinIO)
- **CloudNativePG:** 継続的な WAL アーカイブ + スケジュールされたベース バックアップ (構成されている場合)
- **Supabase クラウド:** 管理された毎日のバックアップ (クラウド オプション)
- **IaC 状態:** S3 バージョン管理されたバケット
 
### 災害復旧
 
- **マルチ AZ:** すべてのステートフル サービスは複数のアベイラビリティ ゾーンにまたがります
- **CloudNativePG HA:** Postgres プライマリとレプリカの間の自動フェイルオーバー
- **Supabase クラウド:** クロスリージョン冗長性 (クラウド オプション)
- **Terraform の状態:** S3 バージョニングにより、以前の状態にロールバックできます
 
---
 
## 追加のリソース
 
- __リンク_7__
- __リンク_8__
- __リンク_9__
- __リンク_10__
- __リンク_11__
- __リンク_12__
- __リンク_13__

​AWS アーキテクチャの概要

​アーキテクチャ図```mermaid

AWS アーキテクチャの概要

アーキテクチャ図```mermaid