한아름마켓 마이크로서비스 목표 아키텍처

목표는 주문·결제·재고·회원 시스템을 점진적으로 분리하면서 다음을 달성하는 것입니다.

• 평시 대비 10~15배 트래픽을 자동 확장으로 처리
• 단일 AZ 장애 시 주문·결제 중단 방지
• 카드 원문정보의 시스템 외부 격리 및 PCI-DSS 범위 최소화
• 서비스별 독립 배포와 장애 격리
• 12명 규모 개발팀이 운영 가능한 수준의 복잡도 유지

권장 AWS 리전은 ap-northeast-2(서울)이며, 최소 3개 AZ에 걸쳐 배포합니다.

1. 논리 아키텍처

flowchart LR
    User[고객 웹/모바일] --> CF[CloudFront]
    CF --> WAF[AWS WAF]
    WAF --> ALB[Public ALB]
    ALB --> BFF[API BFF / API Gateway]

    BFF --> Member[회원 서비스]
    BFF --> Catalog[상품/카탈로그 서비스]
    BFF --> Order[주문 서비스]
    BFF --> Payment[결제 오케스트레이터]
    BFF --> Inventory[재고 서비스]

    Order -->|동기: 주문 검증| Inventory
    Order -->|동기: 결제 승인 요청| Payment
    Payment --> PSP[외부 PG/결제대행사]
    Payment --> Vault[카드 토큰/결제 Vault]

    Order --> Outbox[Transactional Outbox]
    Payment --> Outbox
    Inventory --> Outbox
    Member --> Outbox

    Outbox --> Bus[EventBridge 또는 SNS]
    Bus --> Queue1[SQS 주문 이벤트]
    Bus --> Queue2[SQS 재고 이벤트]
    Bus --> Queue3[SQS 알림 이벤트]
    Bus --> Queue4[SQS 정산 이벤트]

    Queue1 --> Fulfillment[주문 후속 처리]
    Queue2 --> Inventory
    Queue3 --> Notification[알림 서비스]
    Queue4 --> Settlement[정산 서비스]

    Member --> MemberDB[(회원 DB)]
    Order --> OrderDB[(주문 DB)]
    Payment --> PaymentDB[(결제 DB)]
    Inventory --> StockDB[(재고 DB)]
    Catalog --> CatalogDB[(상품 DB)]

    Cache[(ElastiCache Redis)]
    Member -.-> Cache
    Catalog -.-> Cache

2. 서비스 및 도메인 분리

서비스	주요 책임	권장 저장소
회원 서비스	회원 가입, 로그인, 등급, 주소, 약관	Aurora PostgreSQL
인증/인가 서비스	토큰 발급, 세션, MFA, 권한	Cognito 또는 별도 IAM 경계
상품/카탈로그 서비스	상품, 가격, 옵션, 노출 상태	Aurora PostgreSQL + Redis
주문 서비스	주문 생성, 상태 전이, 주문 조회	Aurora PostgreSQL
결제 서비스	결제 승인·취소·환불, PG 연동	Aurora PostgreSQL
재고 서비스	재고 차감, 예약, 복원, 품절 처리	DynamoDB 또는 Aurora
쿠폰/프로모션 서비스	쿠폰 발급, 할인 계산, 사용 처리	DynamoDB
배송/주문후속 서비스	출고 요청, 배송 상태 연계	Aurora 또는 DynamoDB
알림 서비스	이메일, SMS, 카카오 알림톡, 푸시	SQS 기반 비동기
정산 서비스	PG 정산, 판매자 정산, 매출 집계	Aurora + S3
검색 서비스	상품 검색 및 필터	OpenSearch 선택 적용
플랫폼 공통 서비스	이벤트, 설정, 감사 로그, 관측성	EventBridge, CloudWatch, S3

초기에는 서비스 수를 과도하게 늘리지 않는 것이 좋습니다. 1단계의 핵심 분리는 다음 네 가지로 제한합니다.

1. 회원
2. 주문
3. 결제
4. 재고

쿠폰, 배송, 알림, 정산은 주문 시스템이 안정화된 후 분리합니다.

3. 배포 아키텍처

flowchart TB
    Internet[인터넷] --> Route53[Route 53]
    Route53 --> CloudFront[CloudFront]
    CloudFront --> WAF[AWS WAF]
    WAF --> ALB[Application Load Balancer]

    subgraph VPC["서울 리전 VPC"]
        subgraph Public["Public Subnet - 3 AZ"]
            ALB
            NAT1[NAT Gateway AZ-a]
            NAT2[NAT Gateway AZ-b]
            NAT3[NAT Gateway AZ-c]
        end

        subgraph PrivateApp["Private App Subnet - 3 AZ"]
            ECS1[ECS/Fargate AZ-a]
            ECS2[ECS/Fargate AZ-b]
            ECS3[ECS/Fargate AZ-c]
        end

        subgraph PrivateData["Private Data Subnet - 3 AZ"]
            Aurora[(Aurora PostgreSQL<br/>Multi-AZ)]
            Redis[(ElastiCache Redis<br/>Multi-AZ)]
            DDB[(DynamoDB<br/>Multi-AZ 서비스)]
        end
    end

    ALB --> ECS1
    ALB --> ECS2
    ALB --> ECS3

    ECS1 --> Aurora
    ECS2 --> Aurora
    ECS3 --> Aurora

    ECS1 --> Redis
    ECS2 --> Redis
    ECS3 --> Redis

컨테이너 플랫폼

개발팀 규모와 운영 부담을 고려하면 초기 플랫폼은 ECS on Fargate를 권장합니다.

• Kubernetes 운영 복잡도 감소
• 서비스별 Task 수평 확장
• ALB 및 Cloud Map과의 통합 용이
• 배포 시 인프라 관리 부담 감소
• 향후 필요 시 EKS로 이전 가능

각 서비스는 다음 기준으로 배포합니다.

• 최소 3개 Task
• Task를 3개 AZ에 분산
• 서비스별 CPU·메모리·오토스케일링 정책 분리
• Rolling 또는 Blue/Green 배포
• 배포 중 최소 정상 Task 수 보장
• 주문·결제 서비스는 별도 ECS 서비스 및 별도 오토스케일링 그룹으로 격리

4. 서비스 간 통신

동기 통신

즉시 결과가 필요한 경우에만 REST 또는 gRPC를 사용합니다.

• 주문 생성 → 재고 예약
• 주문 생성 → 결제 승인
• 주문 조회 → 회원/상품 정보 조회
• 결제 취소 → PG 취소 요청

외부 API 및 내부 API에는 다음을 적용합니다.

• REST/JSON: 외부 공개 및 일반 업무 API
• gRPC: 내부 저지연 호출이 필요한 경우
• 타임아웃 필수
• 재시도는 멱등성이 보장되는 API에만 적용
• Circuit Breaker
• Bulkhead 격리
• Correlation ID 전파
• API 버전 관리

비동기 통신

처리 지연을 허용할 수 있는 업무는 EventBridge/SNS와 SQS를 사용합니다.

예시 이벤트:

OrderCreated
InventoryReserved
PaymentAuthorized
PaymentFailed
OrderConfirmed
OrderCancelled
InventoryReleased
RefundCompleted

권장 조합은 다음과 같습니다.

• EventBridge: 도메인 이벤트 라우팅
• SQS FIFO: 주문·재고 순서가 중요한 흐름
• SQS Standard: 알림, 통계 등 순서가 중요하지 않은 작업
• DLQ: 처리 실패 메시지 보관
• Lambda 또는 ECS Worker: 비동기 소비자

초기에는 Kafka/MSK를 도입하지 않는 것이 좋습니다. 하루 3만 주문 규모에서는 SQS와 EventBridge가 운영 난이도와 비용 측면에서 적절합니다.

5. 주문·결제·재고 일관성

분산 트랜잭션이나 2PC는 사용하지 않고, Saga 패턴과 보상 트랜잭션을 적용합니다.

sequenceDiagram
    participant C as 고객
    participant O as 주문 서비스
    participant I as 재고 서비스
    participant P as 결제 서비스
    participant G as PG
    participant E as 이벤트 버스

    C->>O: 주문 생성 요청
    O->>O: 주문 상태=PENDING
    O->>I: 재고 예약 요청
    I-->>O: 예약 성공
    O->>P: 결제 승인 요청
    P->>G: PG 승인
    G-->>P: 승인 결과
    P-->>O: 결제 성공
    O->>O: 주문 상태=CONFIRMED
    O->>E: OrderConfirmed 이벤트

    alt 재고 예약 실패
        I-->>O: 예약 실패
        O->>O: 주문 취소
    else 결제 실패
        P-->>O: 결제 실패
        O->>I: 재고 예약 해제
        O->>O: 주문 취소
    end

주문 상태 예시

CREATED
  -> INVENTORY_RESERVED
  -> PAYMENT_PENDING
  -> CONFIRMED
  -> PREPARING
  -> SHIPPED
  -> COMPLETED

실패 보상:
INVENTORY_RESERVED -> CANCELLED
PAYMENT_PENDING -> CANCELLED
CONFIRMED -> REFUND_PENDING -> REFUNDED

반드시 필요한 멱등성 처리

모든 주문·결제 요청에 다음 키를 사용합니다.

Idempotency-Key: 고객 요청별 고유 키
Order-Id: 주문 식별자
Payment-Id: 결제 시도 식별자

같은 결제 요청이 재전송되어도 PG에 중복 승인되지 않도록 결제 서비스가 요청 결과를 저장하고 반환해야 합니다.

Transactional Outbox

주문 DB 변경과 이벤트 발행 사이의 유실을 방지합니다.

1. 주문 상태 변경
2. Outbox 테이블에 이벤트 저장
3. 같은 DB 트랜잭션으로 커밋
4. Outbox Publisher가 이벤트 버스로 전달
5. 성공 이벤트를 발행 완료 상태로 표시

소비자는 중복 이벤트를 받을 수 있다고 가정하고 멱등적으로 구현합니다.

6. 결제 및 PCI-DSS 보안

카드번호(PAN), CVC, 유효기간 원문은 한아름마켓의 애플리케이션과 데이터베이스에 저장하지 않습니다.

권장 결제 흐름:

flowchart LR
    Browser[고객 브라우저] --> PSPToken[PG Hosted Field / SDK]
    PSPToken --> Token[PG 결제 토큰]
    Token --> Payment[결제 서비스]
    Payment --> PG[PG사]
    PG --> Payment
    Payment --> Order[주문 서비스]

보안 원칙

• 카드 입력은 PG Hosted Page 또는 PG SDK 사용
• 내부 시스템에는 PG 토큰과 결제 식별자만 저장
• 비밀값은 AWS Secrets Manager에 저장
• 암호화 키는 AWS KMS로 관리
• DB, S3, 백업, 로그 모두 암호화
• 운영자 접근은 VPN + MFA 필수
• AWS IAM은 최소 권한과 역할 기반 접근
• 개발·검증·운영 AWS 계정 분리
• 운영 DB 직접 접근 금지
• 접근이 필요한 경우 SSM Session Manager와 승인 절차 사용
• 카드정보가 로그에 기록되지 않도록 마스킹 및 탐지 정책 적용
• CloudTrail, GuardDuty, Security Hub 활성화
• PCI-DSS 감사 증적을 S3 Object Lock 등으로 보관

PCI 범위는 PG의 토큰화 방식과 카드 입력 방식을 기준으로 QSA와 확정해야 합니다. 애플리케이션이 카드정보를 직접 처리하면 PCI 범위가 급격히 확대되므로 피하는 것이 좋습니다.

7. 데이터 저장 전략

주문·회원·결제

Aurora PostgreSQL을 사용합니다.

• Multi-AZ Writer/Reader 구성
• 자동 백업 및 PITR
• RDS Proxy를 통한 커넥션 보호
• 읽기 부하는 Read Replica로 분산
• 서비스별 스키마 또는 별도 DB로 논리적 경계 유지
• 다른 서비스 DB 테이블 직접 조회 금지

재고

재고 차감 경쟁이 높으므로 DynamoDB 또는 조건부 갱신을 권장합니다.

UPDATE stock
SET available = available - :quantity,
    reserved = reserved + :quantity
WHERE product_id = :id
  AND available >= :quantity

DynamoDB를 사용할 경우 조건부 쓰기와 TTL 기반 예약 만료를 사용합니다.

캐시

ElastiCache Redis는 다음 용도로 제한합니다.

• 상품 조회 캐시
• 세션 또는 짧은 수명의 토큰
• 재고 예약 만료 보조 데이터
• Rate Limit

Redis를 원장 데이터로 사용하지 않습니다. 캐시 유실 시 DB에서 재생성할 수 있어야 합니다.

8. 확장 전략

평시 대비 10~15배 트래픽을 목표로 하되, 단순히 서버 수만 늘리는 방식은 피해야 합니다.

수평 확장

• ECS 서비스별 Auto Scaling
• CPU뿐 아니라 요청 수, 응답 지연, SQS Queue Depth 기준 확장
• 주문·결제 Task 수는 상품 조회 Task와 독립적으로 확장
• ALB 뒤에 최소 3개 AZ Task 유지
• 이미지·정적 파일은 S3 + CloudFront로 분리
• 읽기 요청은 Redis와 Read Replica로 흡수
• 비동기 작업은 SQS Queue로 급증을 완충

세일 기간 사전 대응

행사 직전에는 다음을 수행합니다.

• 예상 피크의 2~3배 부하 테스트
• ECS 최소 Task 수 사전 증설
• Aurora 용량 및 연결 수 점검
• Redis 메모리와 Eviction 정책 점검
• SQS 및 DLQ 모니터링
• PG사 TPS 한도 확인
• WAF Rate Limit 및 Bot Control 정책 점검
• 신규 배포 동결 또는 승인된 변경만 반영
• 장애 대응 담당자와 연락망 사전 지정

결제 처리량은 내부 시스템보다 PG사의 TPS 제한이 병목이 될 수 있으므로 계약된 처리량과 피크 시 승인 지연을 반드시 검증해야 합니다.

9. 장애 대응 목표

권장 초기 목표는 다음과 같습니다.

영역	목표
주문·결제 API 가용성	월 99.95% 이상
단일 AZ 장애	서비스 중단 없이 다른 AZ로 트래픽 전환
주문 데이터 RPO	0 또는 거의 0
주문 서비스 RTO	5분 이내
일반 조회 API RTO	15분 이내
결제 중복 승인	0건
이벤트 유실	0건, 재처리 가능 구조
장애 이벤트 보존	최소 30일

단일 AZ 장애 대응을 위해서는 다음이 모두 충족되어야 합니다.

• ALB가 3개 AZ에 연결
• ECS Task를 여러 AZ에 배치
• Aurora Multi-AZ 구성
• NAT Gateway를 AZ별로 구성
• Redis Multi-AZ 및 자동 장애 조치
• SQS/EventBridge 사용
• 단일 AZ의 서브넷, NAT, 노드에 의존하지 않음

PG 자체 장애는 별도 문제이므로 결제 상태를 PAYMENT_UNKNOWN으로 보존하고, 조회 API 및 재조정 작업으로 최종 상태를 확인해야 합니다.

10. 관측성 및 운영

필수 지표

• API 요청 수, 오류율, p95/p99 지연
• 주문 생성 성공률
• 결제 승인 성공률
• PG 응답 지연과 오류율
• 재고 예약 실패율
• SQS Queue Depth 및 Age
• DLQ 메시지 수
• Aurora CPU, 연결 수, 잠금 대기
• Redis Hit Ratio, 메모리, Eviction
• ECS Task 재시작 수
• AZ별 트래픽 편중

로그와 추적

• 모든 요청에 Correlation-ID
• 주문·결제에는 Order-ID, Payment-ID
• CloudWatch Logs 중앙 수집
• OpenTelemetry 기반 분산 추적
• 민감정보 자동 마스킹
• 애플리케이션 로그에 카드번호·인증정보 기록 금지
• 장애 발생 시 Trace → 주문 → 결제 → PG 요청까지 연결 가능해야 함

알림 기준 예시

• 결제 실패율 5분 평균 3% 초과
• 주문 API p99 2초 초과
• DLQ 메시지 1건 이상
• 결제 승인 대기 5분 초과
• 재고 예약 실패율 급증
• Aurora Failover 발생
• 비정상적인 관리자 접근
• WAF 차단량 급증

11. CI/CD 및 배포

flowchart LR
    Git[Git Repository] --> CI[Build/Test/Security Scan]
    CI --> Image[Container Image]
    Image --> ECR[ECR]
    ECR --> Staging[Staging ECS]
    Staging --> Test[Integration/Load Test]
    Test --> Approval[승인]
    Approval --> Prod[Production ECS]
    Prod --> Monitor[CloudWatch/X-Ray]
    Monitor --> Rollback[자동 롤백]

권장 파이프라인:

• Pull Request 단위 단위 테스트
• 계약 테스트 및 통합 테스트
• 이미지 취약점 검사
• IaC 정적 검사
• ECR 이미지 서명 또는 provenance 관리
• Staging 자동 배포
• Production Blue/Green 배포
• 오류율·지연 기반 자동 롤백
• DB 스키마는 backward-compatible migration
• 애플리케이션 배포와 DB 삭제 변경을 분리

DB 변경 순서는 다음과 같이 운영합니다.

1. 새 컬럼 추가
2. 구버전·신버전 코드 모두 호환
3. 데이터 백필
4. 신버전 코드 전환
5. 구컬럼 제거

12. 모놀리식 시스템 전환 전략

한 번에 전환하지 않고 Strangler Fig 패턴을 사용합니다.

단계 1: 기반 구축

• AWS 계정 및 네트워크 분리
• VPC, Private Subnet, VPN, IAM, KMS 구성
• CI/CD, ECR, CloudWatch, CloudTrail 구축
• API Gateway/BFF 도입
• 공통 인증 및 Correlation ID 적용

단계 2: 회원 및 상품 조회 분리

• 회원 조회 API부터 분리
• 상품 조회·검색을 분리
• 기존 모놀리스와 CDC 또는 이벤트로 데이터 동기화
• 읽기 트래픽을 신규 서비스로 점진 전환

단계 3: 재고 분리

• 재고 예약 API를 먼저 분리
• 조건부 차감과 예약 만료 구현
• 대규모 부하 테스트
• 모놀리스 주문의 재고 호출을 신규 서비스로 전환

단계 4: 결제 분리

• PG 연동을 결제 서비스로 이동
• Idempotency와 결제 상태 재조정 구현
• 카드 원문 데이터가 기존 DB·로그에 남아 있는지 전수 점검
• 결제 실패·타임아웃 시나리오 검증

단계 5: 주문 분리

• 주문 생성과 상태 머신을 신규 주문 서비스로 이동
• Outbox 및 Saga 도입
• 트래픽을 1%, 10%, 50%, 100% 단계로 전환
• 모놀리스 주문 생성 기능을 제거

13. 주요 설계 결정 로그

ID	결정	이유	대안 및 기각 사유
ADR-001	초기 컨테이너 플랫폼으로 ECS Fargate 채택	12명 팀의 운영 부담 감소	EKS는 유연하지만 초기 운영 복잡도 높음
ADR-002	이벤트 브로커로 EventBridge + SQS 사용	주문 규모에 충분하고 운영 단순	MSK는 처리량 대비 운영 비용이 큼
ADR-003	서비스별 데이터 소유권 분리	결합도와 장애 전파 감소	공용 DB는 단기 편하지만 장기적으로 분리 불가
ADR-004	주문 흐름에 Saga 적용	분산 트랜잭션 없이 보상 가능	2PC는 성능·가용성·운영 측면에서 부적합
ADR-005	카드정보를 PG 토큰화로 처리	PCI 범위 최소화	자체 카드 저장은 보안·감사 부담이 큼
ADR-006	재고에 조건부 갱신 적용	동시 주문 시 초과 판매 방지	단순 조회 후 차감은 Race Condition 발생
ADR-007	멀티 AZ 3개 구성	단일 AZ 장애 대응	2 AZ는 장애 여유가 작음
ADR-008	점진적 전환	비즈니스 중단 및 대규모 빅뱅 리스크 감소	일괄 재작성은 실패 시 복구가 어려움

14. 개발팀 구현 규칙

모든 서비스는 다음 공통 규칙을 따릅니다.

• 서비스는 자신의 DB만 직접 접근
• 외부 서비스 테이블 조회 금지
• API에는 타임아웃과 요청 ID 적용
• 재시도 가능한 요청은 반드시 멱등성 보장
• 이벤트 소비자는 중복 이벤트 처리 가능해야 함
• 실패 메시지는 DLQ로 이동
• 모든 상태 변경은 감사 로그 기록
• 민감정보는 로그·이벤트·트레이스에 포함하지 않음
• API와 이벤트 스키마는 버전 관리
• 헬스 체크와 Readiness 체크 분리
• 모든 서비스에 부하 테스트 시나리오 보유
• 장애 복구 절차를 문서화하고 정기적으로 훈련

핵심은 “서비스를 많이 만드는 것”이 아니라 주문·결제·재고의 장애 격리, 데이터 소유권, 멱등성, 이벤트 재처리를 먼저 확립하는 것입니다. 이 구조라면 현재 규모에서는 운영 복잡도를 통제하면서도 세일 기간 10~15배 급증과 단일 AZ 장애에 대응할 수 있습니다.