작은 AWS 시스템의 다음 확장 후보들

AWS 실전 운영 시리즈 9/12

작은 운영 콘솔을 만들 때 처음부터 모든 AWS 기능을 켤 필요는 없다.

RDS Proxy, WAF, X-Ray, ECS Fargate, Reserved Concurrency, Request Validation, DLQ 같은 것들은 모두 유용하다.

하지만 처음부터 다 넣으면 시스템이 과해진다.

중요한 것은 지금 쓰지 않더라도, 어떤 조건이 되면 검토할지 적어두는 것이다.

현재 구조에서 출발하기

작은 운영 콘솔은 다음 정도로 시작할 수 있다.

React SPA
-> S3 + CloudFront
-> API Gateway
-> Lambda
-> S3 / RDS

일부 잦은 API
-> EC2 + Docker
-> RDS

이 구조는 충분히 현실적이다.

하지만 규모나 요구사항이 바뀌면 추가할 후보들이 생긴다.

확장 후보는 서비스 이름 목록이 아니라 신호와 대응을 연결해서 보는 편이 좋다.

이렇게 적어두면 "언젠가 하면 좋은 것"이 아니라 "어떤 증상이 보이면 검토할 것"이 된다.

1. RDS Proxy

Lambda에서 RDS를 자주 호출하면 DB connection이 문제가 될 수 있다.

Lambda는 동시 실행이 늘어날 때 DB connection도 함께 늘어날 수 있다.

이때 RDS Proxy를 검토한다.

검토 조건:

• Lambda가 RDS를 자주 조회한다.
• 동시 실행이 늘고 있다.
• DB connection count가 불안정하다.
• connection storm이 우려된다.
• 상주 서버로 옮기기 애매한 워크로드다.

처음부터 꼭 필요하지는 않다.

하지만 DB 연결 문제가 보이면 가장 먼저 검토할 후보 중 하나다.

2. Reserved Concurrency

Lambda는 자동으로 확장된다.

이 장점은 때로 위험이 된다.

무거운 Lambda가 너무 많이 동시에 실행되면 DB나 외부 API를 압박할 수 있다.

Reserved Concurrency는 특정 Lambda의 동시 실행 수를 제한하거나 보장하는 기능이다.

검토 조건:

• 리포트 생성처럼 무거운 작업이 있다.
• 동시에 너무 많이 실행되면 DB에 부담이 된다.
• 비용 폭주를 막고 싶다.
• 다른 Lambda와 실행 한도를 분리하고 싶다.

비동기 worker에는 특히 유용할 수 있다.

3. Dead Letter Queue 또는 실패 이벤트 저장

Lambda 비동기 호출은 실패할 수 있다.

실패 이벤트를 잃지 않으려면 DLQ나 실패 destination을 검토한다.

검토 조건:

• 비동기 작업 실패를 나중에 재처리해야 한다.
• 실패한 payload를 보존해야 한다.
• 작업 누락이 운영 문제로 이어진다.
• 단순 로그만으로는 복구가 어렵다.

초기에는 job table에 실패 상태를 남기는 것만으로 충분할 수 있다.

하지만 이벤트 자체를 보존해야 한다면 DLQ가 필요해진다.

4. WAF

내부 도구라면 처음부터 WAF가 필요하지 않을 수 있다.

하지만 외부 공개 페이지나 API가 있다면 WAF를 검토할 수 있다.

검토 조건:

• 공개 경로가 인터넷에 노출되어 있다.
• 비정상 요청이나 봇 트래픽이 보인다.
• 기본적인 SQL injection, XSS 방어 룰이 필요하다.
• 특정 국가나 IP 제한이 필요하다.
• API Gateway 또는 CloudFront 앞단에서 보호하고 싶다.

WAF는 보안 기능이지만 운영 비용과 false positive도 함께 고려해야 한다.

5. X-Ray 또는 분산 추적

CloudWatch Logs만으로 충분한 시기가 있다.

하지만 요청이 여러 서비스를 지나고 지연 원인을 찾기 어려워지면 tracing이 필요하다.

검토 조건:

• API Gateway, Lambda, 외부 API, DB가 이어진 요청이 많다.
• 지연 원인을 로그만으로 찾기 어렵다.
• 특정 구간의 latency를 시각화하고 싶다.
• 장애가 간헐적으로 발생한다.

작은 시스템에서는 처음부터 켜지 않아도 된다.

하지만 병목 분석이 반복되면 검토할 만하다.

6. ECS Fargate

EC2 + Docker로 시작한 상주 API 서버는 나중에 ECS Fargate로 옮길 수 있다.

검토 조건:

• 컨테이너가 여러 개로 늘어난다.
• 무중단 배포가 필요하다.
• 오토스케일링이 필요하다.
• 단일 EC2 장애가 부담된다.
• 서버 패치 책임을 줄이고 싶다.
• task definition 기반 배포가 필요하다.

처음부터 ECS를 쓰지 않았더라도 Docker image 기반으로 운영했다면 이동 경로가 열린다.

7. API Request Validation

초기에는 Lambda 코드 안에서 요청 검증을 할 수 있다.

하지만 외부 입력이 늘어나면 Gateway 단에서 기본 검증을 하고 싶어진다.

검토 조건:

• 잘못된 요청이 자주 들어온다.
• Lambda까지 보내기 전에 차단하고 싶다.
• API schema를 명확히 관리하고 싶다.
• 외부 클라이언트가 늘어난다.

REST API Gateway의 request validation이나 별도 schema validation을 검토할 수 있다.

8. Secrets Manager 또는 Parameter Store

환경 변수에 모든 값을 직접 넣는 방식은 단순하다.

하지만 secret 관리가 중요해지면 Secrets Manager나 Parameter Store를 검토해야 한다.

검토 조건:

• DB password나 API key 회전이 필요하다.
• 여러 Lambda와 서버가 같은 secret을 쓴다.
• 환경별 secret 관리가 복잡하다.
• 배포 환경 변수에 secret을 직접 넣기 부담스럽다.

초기에는 환경 변수로 충분할 수 있다.

하지만 secret lifecycle이 생기면 전용 서비스를 쓰는 것이 낫다.

9. S3 Lifecycle Policy

리포트 파일이나 감사 백업이 계속 쌓이면 정리 정책이 필요하다.

검토 조건:

• 다운로드 파일이 계속 누적된다.
• 감사 백업의 보관 기간이 정해져 있다.
• 오래된 파일은 저렴한 storage class로 옮기고 싶다.
• 개인정보가 포함된 파일의 만료가 필요하다.

파일을 생성하는 기능이 있다면 삭제 정책도 설계의 일부다.

처음부터 다 하지 않는 이유

이 후보들은 모두 유용하다.

하지만 처음부터 다 도입하면 다음 문제가 생긴다.

• 설정이 많아진다.
• 운영 문서가 복잡해진다.
• 장애 원인 구간이 늘어난다.
• 비용이 늘어난다.
• 팀이 이해해야 할 개념이 많아진다.

작은 운영 도구에서는 단순성이 큰 장점이다.

따라서 현재 문제를 해결하는 최소 구조로 시작하고, 확장 후보와 검토 조건을 문서화하는 방식이 좋다.

로드맵 문서로 남기기

개선 후보는 머릿속에 두지 말고 문서에 남긴다.

예시:

후보	검토 조건	현재 판단
RDS Proxy	Lambda DB 연결 증가	아직 미도입
Reserved Concurrency	worker 동시 실행 제어 필요	검토 후보
WAF	공개 트래픽 증가	추후 검토
ECS Fargate	컨테이너 다중화 필요	다음 단계
X-Ray	지연 원인 추적 반복	필요 시 도입

이 표는 "왜 안 했는가"를 설명해준다.

안 한 것도 결정이다.

정리

작은 AWS 시스템은 처음부터 완성형일 필요가 없다.

S3, CloudFront, API Gateway, Lambda, 필요한 경우 EC2 + Docker 정도로 시작할 수 있다.

대신 다음 확장 후보를 알고 있어야 한다.

• RDS Proxy
• Reserved Concurrency
• DLQ
• WAF
• X-Ray
• ECS Fargate
• Request Validation
• Secrets Manager
• S3 Lifecycle

중요한 것은 기능 목록이 아니라 검토 조건이다.

지금 하지 않는 이유와 나중에 해야 할 신호를 문서화하면, 작은 시스템도 무리 없이 성장할 수 있다.

함께 볼 GitHub 저장소

• aws-console-operations-notes