대용량 처리 시스템 구축을 경험 할 수 없으니, 교육을 들으며 경험할 수 밖에..
그 동안 어떤 문제점이 있었고, 이 문제점을 어떻게 해결했는지, 그리고 해결한 문제의 결과는 어땠는지에 대한 설명이다.
1. 클라우드 이전
테스트 가능한 환경 (Testable env AEarlyAP)
· Synchronized Deploy On-Premise & Cloud
DB Replication Relay via VPN
· VPN - enough to relay, and eventually synchronized
· Reduce switching time
Amazon Aurora (only MySQL, PostgreSQL)
· Expensive, but Efficient
클라우드 이전은 Not Only Infra Duty
· Required Collabo-Ship
Infra(Cloud) 오너쉽 - important for Next Stage
2. First BlackFriday on Cloud
BlackFriday 2019
· 절반의 성공
· 짧은 운영/적용기간
· 장애 감지 & 대처 미흡
· Infra & Network 확장, but 일부 App은 일부만 변화
· 작은 DB 지연 -> 전체 장애
· 장애는 약한 고리를 찾아 이동한다.
· Traffic 대응에 적합한 Architecture/SW 변화 필요
3. 이후의 시도들
Micro Services
· 병목 구간 서비스 분리 (장애 격리) - Cloning
· Log Transaction Node (주문)
· Massive Traffic Node (이벤트, 메인)
· 큰 서비스 변경 시, 별도 구조 분리 - Refactoring
· 회원, 전시, 검색, 결제...
· 분리된 도메인 간 통신 Internal (REST) API
· DB 분리는 선택적 - DML만 API를 적용하기도
DB Splitting
· Legacy를 분리 하는 것은 어렵지만
· 새로운 서비스는 혼합하지 않는다
· or Replication READ Performace
CQRS Pattern
· EX) 로그인 시 회원 등급 계산, 회원 가입 후 후처리, 좋아요 Action
Cache Strategy
· Lazy Loading Cache - TTL 기반, 쉬운 적용, 갱신 시 이슈 내포
· Write Through Cache - 갱신 로직 필요, CQRS Pattern과 경합한 강력한 구조 기능
4. 2020 Black-Friday 7일간 Records - Zero Downtime
· 결제 금액 743억원 (x 2.3)
· 결제 약 100만건 (x 1.5)
· HTTP/s 요청 42억 (x 6)
· 사용 AWS 서비스 수 34개 (x 1.8)
· Zero DownTime
블랙플라이데이 Billboard
· 실기간 누적 결제액
· 이벤트 3주전 아이디어 회의 시작
· 2주만에 개발 및 상용 서비스 준비
· 전체 HTTP 요청의 1/3트래픽
· 최대 분당 370만 호출 by t3.micro x 10
· redis(for Pub/Sub), Lambda, Golang
· Extra VPC network
5. 그리고 현재 on Production
· 11 Cache Cluster
· 15 DataBase ( 10 DB Cluster)
· 35 Lambdas
· 70 Deployable Micro Service
· 15,000 Deploys/year
· 효율과 독립 성을 높이는데 집중
· Container (Kubernetes - EKS)
· 배포 시간을 줄이고,OS Level Resource 절감
· Devel 환경 전환 완료
· Alpha/Production 환경 전환 중
· Event Driven / Event Bus (Kafka - MSK)
· API기반의 밀결합 된 구조에서
· Event 기반의 독립된 개발 환경
· Distributed Tracing (Applying)
· ML based Photo/Image Processing Tech for Musinsa (Ongoing)