adr foundation hub split

ADR - Foundation / Hub 분리

메타데이터	값
상태	accepted
결정일	2026-05-09 (통합 아키텍처 기준 문서화일)
현재 유효 여부	유효, 단 리소스 목록은 현재 Terraform 기준으로 갱신
Superseded 관계	DynamoDB 소유권은 2026-05-21 0021-dynamodb-to-foundation이 후속 확장
구현 근거	infra/foundation/, infra/hub/, build/destroy scripts
검증 근거	docs/ops/14_hub_run_commands.md, Hub-only rebuild 검증 기록

Wiki ADR 파일명은 유지한다. 숫자 prefix 충돌은 docs/changes/README.md와 파일명별 이력으로 식별한다.

---

결정

AWS 리소스를 생명주기에 따라 분리한다.

Terraform root	현재 책임
infra/foundation	S3 data bucket, ECR, FactoryStatus DynamoDB, 공통 DNS/인증서 등 Hub와 분리해 보존할 리소스
infra/hub	Hub VPC/subnet/NAT, EKS/node group, Hub IAM/IRSA와 관측 add-on
infra/data-pipeline	DataProcessor, IoT Rule, Scheduler, aggregator, collector, alert dispatcher 등 재배포 가능한 처리 계층

초기 설명처럼 IoT Rule과 Lambda를 foundation 소유로 보지 않는다. 현재 구현에서 이들은 infra/data-pipeline이 관리하며 foundation의 S3/DynamoDB를 data source로 조회한다.

---

이유

• 비용이 큰 Hub EKS/VPC를 데이터와 분리해 삭제할 수 있다.
• S3/DynamoDB 식별자와 데이터가 Hub rebuild에 종속되지 않는다.
• 처리 코드와 schedule은 data-pipeline에서 독립적으로 재배포한다.
• Terraform root별 state와 destroy 순서를 명확히 한다.

---

결과와 경계

Hub-only destroy/build 중에도 Spoke publisher, IoT Core, data-pipeline, DynamoDB/S3, ECS Dashboard를 유지하면 데이터 수집은 계속된다. Hub 복구 후에는 ArgoCD cluster/ApplicationSet 연결과 Slow Collector의 EKS access binding을 복구한다.

Foundation까지 삭제하는 전체 destroy는 데이터 보존 시나리오가 아니다. 또한 data-pipeline은 foundation DynamoDB를 data source로 조회하므로 destroy는 data-pipeline -> foundation, build는 foundation -> data-pipeline 순서를 지켜야 한다.