binchoo
commented
9 months ago 카카오 챗봇 관련해서 경험한 이슈입니다.
[이슈 내용]
- 일 배치로 게임사 API에 요청해 출석체크를 진행하는 워크로드
- 등록 유저수 급증으로 동일 IP에 대한 TooManyRequests 응답이 생기기 시작
- 응답 성공 수준이 50%
[상세 내용]
1. Gentle request를 짜기 어려웠다.
2. 비용을 극한으로 아껴야 했다.당시 일 배치 구조는 Amazon EventBridge + AWS Lambda(Springboot) + Amazon DynamoDB 서버리스 아키텍처입니다.
- 게임사가 Batch Put API를 제공하지 않으니 Lambda 함수는 유저 수 만큼 API를 호출해야 했음
- 함수의 Public IP를 요리조리 바꿔줄 수 있었을까?
- Lambda의 Public IP는 내가 제어 불가하며, VPC 배치하면 NAT Gateway IP를 이용할 수 있음
- 함수 스케일링 시 병렬 실행은 70개 정도였기에, 이들보다 더 많은 공개 IP를 확보하려면 n개의 NAT GW와, n개의 Elastic IP 부착 작업이 필요함 (n > 70)
- 그 수준보다 많은 IP를 확보해야 400 오류를 피할 수 있으니 무의미
- EIP 부착하는 작업도 월에 몇 번 반복하면 과금 대상임. IP 갈아끼우는 얌체짓 못하도록 막혀 있음.
[조치 내용]
- 실패시에 재시도 로직을 일단 돌림
- AWS Lambda Retry Policy 사용
- 실패된 출석체크 건 기록, 일정 시간 지난 후 재시도 조치
- 서비스 로직은 성공하지 않은 유저 출석체크를 조회해서 다시 수행했음
- 유저를 그룹으로 쪼개 시간 차를 두고 요청 개시 조치
- SQS 메시지의 Visibility 옵션 사용
- 응답 성공률 추적 위해 커스텀 메트릭 정의하고 매일 확인
- CloudWatch PutMetricData API
- 출첵 이력이 또 너무 많이 쌓이는데, 며칠 간만 유효하므로 TTL 처리
- DynamoDB TTL
결국
-
이벤트 기반 구성으로 Request and Forget 패턴으로 일 배치 구성
- 요청 실패시 앱이 Abort 하지 않도록 대비
- 성공/실패 기록하여 재시도 지원
-
AWS가 제공하는 서버리스 솔루션으로 트래픽 확장 대비
- Lambda와 SQS가 제공하는 옵션을 활용해 재시도 및 트래픽 분산 시도
- 그러나 게임사 API가 빡빡했던 관계로 난해함을 겪음
-
매일 메트릭 확인하면서 성공률이 만족스럽지 않으면, 수동으로 트리거
kth990303
질문
A. 얼마 전에 KT IDC-AWS 서울/도쿄에 latency 및 loss가 1시간 이내로 발생하였는데요 이로 인해 저희 시스템도 영향을 받게 되어 비상 근무를 섰습니다
여러분의 시스템은 이런 상황이 발생했을 때
B. 저희 시스템은 트래픽이 많지 않아서, 트래픽이 급증하는 상황을 경험해보지 못했는데요 여러분은 트래픽이 급증하는 상황을 겪은 적이 있으신가요?
있으시다면
연관 챕터
6
@caffeine-library/readers-release-everything