배경 및 문제 상황
•
올리브영에서는 1,400만 명의 회원에게 일괄적으로 쿠폰을 발급해야 하는 상황
•
기존 시스템으로는 분당 약 1만 건 처리 속도로 총 23시간이 소요될 것으로 예상
기존 대량 데이터 처리 방식의 한계
전통적인 배치 어플리케이션 접근법
•
Multi Thread Step, AsyncItemProcessor, Remote Chunking, Partitioning 등의 기술을 활용했으나 성능 향상에 뚜렷한 한계 존재
Job Management 서버 기반 접근법
•
중앙 Job Management 서버가 작업을 여러 처리 서버에 분배
•
단일 Job Management 서버가 SPOF(Single Point of Failure)가 되어 안정성 저하
ECS를 활용한 솔루션
아키텍처 진화
•
초기 접근
◦
Batch Application을 ECS로 구성하고 Job Management Server를 ECS Task API로 대체
◦
한계: 동시에 실행할 수 있는 Task 수에 제약 존재
•
최종 솔루션: Amazon MQ와 ECS 통합 시스템
◦
Amazon MQ(RabbitMQ)의 Fanout Exchange를 활용해 여러 큐에 동시에 작업 분배
◦
ECS Fargate를 사용하여 인프라 관리 부담 없이 필요에 따라 작업 확장
구현 세부사항
•
AWS Fargate 활용으로 분당 2~3만 건 처리 가능
•
태스크 배포:
◦
평상시 운영: 6개 태스크 (분당 2만 건 처리)
◦
전체 회원 대상: 최대 10개 태스크로 확장
•
Fargate 스펙: 4 CPU / 8GB 메모리
기술적 고려사항
•
데이터베이스는 Oracle DB 사용 (원래 사용중이었던 DB)
•
쿠폰 번호와 회원 번호를 복합 기본키(PK)로 사용
•
동시 처리 환경에서 중복 발급 방지를 위해 글로벌 락(Global Lock) 도입
ECS Fargate 선택 이유
•
EC2 기반 방식 대비 관리 포인트 대폭 감소
•
자원 제약 없이 필요한 만큼 즉시 확장 가능
•
배치 작업의 특성상 필요할 때만 자원을 프로비저닝하는 Fargate의 특성이 적합
Amazon MQ 선택 이유
•
SQS Standard: 메시지 중복 수신 가능성이 있어 멱등성 보장이 추가로 필요
•
SQS FIFO: 처리량 제한(초당 300개 메시지, 배치 처리 시 3,000개)으로 대용량 처리에 부적합
•
MSK(Managed Kafka): 파티션 관리의 복잡성과 파티션 수 감소 시 발생할 수 있는 문제