|
1. 개요 및 탄력성의 중요성
1-1. 탄력성의 비용
메시지 손실이나 시스템 다운 타임으로 인한 비용은 단순히 재정적인 손실을 넘어 브랜드 가치와 고객 신뢰에 심각한 타격을 줍니다.
1-2. 탄력성의 정의
인프라 중단, 설정 오류 또는 일시적인 네트워크 문제로부터 저항하고 복구할 수 있는 능력을 의미합니다.
1-3. 탄력성에 대한 공동 책임 모델
AWS는 인프라를 책임지지만, 사용자는 구성 관리 및 다중 AZ 배포와 같은 필요한 탄력성 작업을 책임집니다. 서버리스 환경에서는 AWS가 고가용성, 오토 스케일링 등을 관리하므로, 사용자는 애플리케이션 아키텍처 및 코드에 집중합니다.
2. 아키텍처 설계 시 고려 사항
2-1. 아키텍처 다이어그램의 선(Line)에 대한 가정 질문
두 서비스 A와 B를 연결하는 단순한 선이 있더라도, 다음 질문을 통해 숨겨진 복잡성을 이해합니다.
- 상호 작용 모델: 동기식(Synchronous)인가 비동기식(Asynchronous)인가?
- 결합도: 점대점(Point-to-point)인가 Pub/Sub 모델인가?
- 오류 처리: 재시도, 지수 백오프(Exponential Backoff), 부분 실패, 멱등성(Idempotency)이 구현되었는가?
2-2. 결합도(Coupling)의 차원
느슨한 결합(Loose Coupling)은 이상적이지만, 기술, 공간, 시간적 결합(Temporal Coupling) 등 여러 차원에서 트레이드 오프가 발생합니다. 특히 비동기식 상호 작용을 처리하는 서버리스에서 시간적 결합을 관리하는 것이 중요합니다.
2-3. 서버리스의 일반적인 실패 원인 및 안티 패턴
- 서비스 한도 및 할당량 초과 (예: DynamoDB 읽기/쓰기 용량 부족으로 Lambda 타임아웃)
- 잘못된 구성 (특히 IAM 권한)
- 함수 체인(Function Chaining): 하나의 함수가 다른 함수를 호출하는 방식은 피해야 할 안티 패턴
3. AWS 도구 및 서비스별 탄력성 기능
3-1. AWS Power Tools
Well-Architected Serverless Lens의 모범 사례를 코드로 구현한 유틸리티이며, 관찰 가능성(Observability), 배치 처리(Batch Processing), 멱등성 처리 등을 표준화하여 개발자가 별도의 구현 없이 바로 적용 가능합니다.
3-2. API Gateway를 통한 트래픽 관리
- Throttling: 계정, 단계(Stage), 메서드(Method) 수준에서 인바운드 요청 속도를 제한하여 백엔드를 보호
- Usage Plans: 사용량에 따라 다른 조절 속도(Throttling Rates)를 적용하여 고객별로 차등화된 서비스를 제공(예: SaaS 애플리케이션)
- Method-Level Caching: GET 요청에 대한 캐싱을 활성화하여 백엔드에 대한 불필요한 호출을 줄이고 백 프레셔(Back Pressure)를 해소
3-3. Lambda 호출 유형별 탄력성
- 동기식 (Synchronous/Push Model): 호출자가 응답을 기다림. Lambda는 자동으로 재시도하지 않으며 내구성(Durability)이 없음. 실패는 즉시 호출자의 책임이 됨 ($1백만 달러 위젯을 잃을 수 있음)
- 비동기식 (Asynchronous): EventBridge, S3 알림 등. AWS가 내부 큐에 요청을 넣고 Lambda가 처리. 최대 2번의 재시도를 자동으로 수행하며, 실패 시 DLQ(Dead Letter Queue) 또는 대상으로 보낼 수 있어 내구성을 제공
- 이벤트 소스 매핑 (Event Source Mapping): SQS, DynamoDB/Kinesis Streams. Lambda가 이벤트 소스를 폴링(Poll). SQS의 경우 기본적으로 배치 단위로 성공/실패가 처리되나, **부분 배치 응답(Partial Batch Response)**을 구성하여 실패한 메시지만 SQS로 반환. Power Tools의 배치 프로세서 유틸리티를 사용하면 이 과정을 자동화
3-4. 멱등성(Idempotency)의 중요성
분산 아키텍처에서 생산자가 재시도할 경우를 대비하여, 같은 메시지를 여러 번 처리해도 최종 결과가 동일함을 보장해야 합니다. Power Tools의 멱등성 유틸리티는 요청의 기록 및 응답 상태를 관리하여 중복 제거를 도와줍니다.
3-5. EventBridge의 탄력성
기본적으로 최대 24시간 동안 185회까지 대상으로 메시지 전송을 재시도합니다(지수 백오프 포함). 재시도 횟수나 메시지 보존 기간을 세밀하게 제어하고, 실패한 메시지를 구성된 SQS DLQ로 보낼 수 있습니다.
4. 탄력성 설계 패턴
4-1. API Gateway를 다른 서비스와 직접 통합
- API Gateway $\rightarrow$ SQS/Step Functions: Lambda를 중개자로 사용하지 않고 HTTP 요청을 직접 큐에 넣어 비동기식 아키텍처를 구축하고 내구성을 확보하는 좋은 방법
- API Gateway $\rightarrow$ DynamoDB: 데이터 읽기(Read) 작업은 가능하지만, 상태를 조작하는 쓰기(Write) 작업에는 권장하지 않음. 실패 시 클라이언트가 직접 재시도를 해야 하므로 경험이 좋지 않음
4-2. 트랜잭션 아웃박스(Transactional Outbox) 패턴 (EventBridge Pipes 사용)
Lambda 함수가 데이터베이스 쓰기 및 이벤트 게시를 동시에 수행하면 분산 트랜잭션 문제가 발생하여 데이터 불일치 상태가 됩니다.
해결책은 Lambda는 DynamoDB에만 기록하고, DynamoDB Streams를 통해 변경 사항을 EventBridge Pipes로 보냅니다. Pipes는 DynamoDB 레코드를 비즈니스 컨텍스트를 담은 EventBridge 이벤트로 변환하여 다른 서비스에 게시합니다. 이는 쓰기와 이벤트 생성을 하나의 논리적 트랜잭션으로 묶어 일관성을 보장합니다.
4-3. Step Functions를 활용한 탄력적인 워크플로우
Step Functions는 복잡하고 장기 실행되는 비즈니스 워크플로우를 구축하는 데 유용합니다.
- 내장된 탄력성 기능: 오류 처리, 자동 재시도, 지수 백오프, 타임아웃/하트비트 등을 제공하여 워크플로우를 안정적으로 만듬
- Saga 패턴: 분산 트랜잭션이 필요한 경우, Step Functions를 사용하여 일련의 보상 트랜잭션(Compensating Transactions)을 구축하여 실패 시 전체 워크플로우를 일관된 상태로 되돌릴 수 있음
5. 탄력성 검증: 카오스 엔지니어링
- Fault Injection Service (FIS): 타임아웃, 콜드 스타트, 네트워크 오류 등의 장애를 의도적으로 주입하여 시스템이 비정상적인 상황에서 어떻게 동작하고 안전하게 복구되는지 검증
|
