Amazon Cloud Club Ewha 3기 사이드 프로젝트
아키텍처 발전 과정을 순서대로 회고한다.
1. 초기 구상 (팀 회의 전)
초기에는 AWS로 인프라를 구축해본 경험이 없어, 리소스 배치나 VPC 구조를 고려하지 않았다.
1안 (MVP)
- 짧은 기간의 프로젝트이기에 개발 부담을 줄이기 위해 서버리스 Lambda로 설계했다.
API Gateway+Lambda+Dynamodb구조
*API Gateway는 websocket 통신을 지원한다.- WebSocket & REST 분리 구조
실시간 채팅은 WebSocket API, 나머지는 REST API로 나누어 각각 다른 API Gateway로 연결된다.
2안 (Elasticache 도입)
- 속도 개선 요구사항을 맞추기 위해 elasticache를 추가했다.
- Lambda에서 private subnet의 elasticache를 어떻게 접근해야 하는지 몰랐다..
3안 (Cognito 도입)
- 사용자 인증/인가를 Cognito로 처리하는 구조.
- 사용자 정보를 어떻게 DynamoDB에 저장해야 할지에 대한 구조가 부족했다.
2. 아키텍처 초안 (팀 회의 후)
팀 회의 후, ECS 기반 아키텍처로 결정했다.
개발자 요구사항으로 서버리스 제외
백엔드 개발자들이 직접 웹소켓 서버를 구축해보고 싶어해서 서버리스는 제외하게 되었다.
ECS Fargate 선택 이유
- 인프라를 구성해본 경험이 없는 팀원에게 관리 부담이 적어서
- (비용을 지원해주는 프로젝트라 가격이 더 비싸도 한번 써보고 싶어서)
문제점
- ENI를 위한 별도의 private subnet 구성 → 실제로는 ECS에서 자동 할당되어 별도의 subnet이 필요 없다.
- Cognito가 어떻게 애플리케이션과 상호작용하는지 고려하지 않았다.
- Redis/SQS 가 어떻게 작동하는지 모르고 그냥 붙였다. (NAT Gateway, ALB, SQS 작동 방식 등 전반적으로 잘 몰랐다.)
3. Elasticache 선택 논의
아키텍처를 개선하는 과정에서 Redis 사용 여부에 대해 백엔드와 논의해 다음 3가지 옵션을 비교했다.
1. ElastiCache + 직접 pub/sub 구현
구현 난이도 높음. 백엔드 파트에서 불가능하다고 판단.
2. Spring의 Simple Broker 사용
구현 간단하지만, multi-AZ 미지원 (고가용성 X)
3. 외부 브로커(Amazon mq)
구현 단순, 비용 증가
경험 부족+짧은 개발 기간+비용 지원→ Amazon MQ 선택
4. 최종 아키텍처(과제 제출용)
-
실제 aws 콘솔에서 설정은 해보지 않은 상태에서 완성한 아키텍처이다. (현실적인 문제를 겪지 않았다.)
-
ALB와 Cognito를 연동하여 인증된 요청만 백엔드에 전달하도록 설계했다. (프론트가 백엔드 레포지토리에 포함되어 배포된다고 생각해서..) 이를 위해서는 Cognito의 callback URI를 ALB 도메인으로 설정해야 했다.
-
하지만 실제로는 프론트엔드가 별도로 배포되기 때문에 callback URI를 프론트 도메인으로 지정해야 하는 충돌이 발생하게 된다...
5. 최종 아키텍처(발표용)
실제 구현을 해보며 실현 가능한 아키텍처가 되었다.
-
위에 적힌 이유로 Cognito + ALB 연동하지 않고, Cognito는 프론트와 소통하는 방식으로 바꿨다.
-
그러자, 백엔드 Spring Security에서 JWT 검증 시 외부 API 호출(JWKS) 필요.. → NAT Gateway 추가
CI/CD 파이프라인 구축
- Dockerfile에서 환경 변수 관리의 중요성 느낌.
- 테스트용 변수도 환경 변수화하면 좋을듯.
- 인프라-백엔드 소통 필요성
- VPC endpoint로 Amazon MQ에 연결했으나, MQ ARN 전달 실수로 NAT Gateway 제거 시 연결 실패..
배포 후 이슈
- Access Token 내 이메일 누락 → Cognito
Pre-sign-up Lambda 트리거추가 - 사용자 정보 저장→
Post-confirmation Lambda 트리거로 DynamoDB 연동
단, AWS 콘솔에서 사용자 수정 시 반영되지 않는 구조적 한계 있음 (MVP 단계에서는 수용 가능..)
6. NAT Gateway 대체 성공
Lambda + Private API Gateway로 외부 JWK API 호출 대체
- 사실 원래 이 방식으로 설계했으나, API Gateway 정책 오류로 급히 NAT Gateway 붙이게 된 것임.
- API Gateway 정책과 Spring Security 설정(
jwk-set-uri)을 수정하여 NAT Gateway 대체 성공!
Amazon MQ 연결 이슈
- Amazon MQ는 VPC Endpoint로 연결돼 있었으나, 백엔드에 MQ ARN만 전달되어 있어 NAT 제거 시 접근 불가
- 환경 변수/시크릿 관리의 중요성 깨달음 → AWS Parameter Store나 Secrets Manager 사용해보고 싶음. Terraform과 같은 IaC로 관리해도 같은 실수는 발생하지 않을 것 같음.
