모여타(판교 출퇴근 택시·동행 매칭 서비스) 의 클라우드 인프라 설계 기록입니다. 서비스·팀 가정에서 출발해 V1(EC2 + Docker Compose) 구축, CI/CD, SLI/SLO 정의, 부하 측정으로 찾은 V1의 한계, V2(ECS 기반 확장) 설계까지 작업 순서대로 정리했습니다.

각 문서 제목을 누르면 해당 문서로 이동합니다. 문서를 읽다가 다른 문서로 넘어갈 때는 오른쪽 사이드바나 이 페이지의 목차를 사용하세요.

flowchart LR
    A["0. 서비스와 팀 가정<br/>DAU·RPS·예산"] --> B["1. V1 인프라<br/>EC2 + Compose"]
    B --> C["2. CI"]
    C --> D["3. CD"]
    A --> E["4. CUJ · SLI/SLO"]
    E --> F["5. V2 확장 가정<br/>V1 부하 측정"]
    D --> F
    F --> G["6. V2 인프라<br/>CloudFront·ALB·ECS·RDS·Redis"]
    G --> H["7. 모니터링·장애 알림<br/>PLG + Alloy · Discord"]

1. 서비스 문제와 제공 가치 가정 → 사용자 상황과 행동 기반 RPS 가정: 서비스가 무엇이고 트래픽이 얼마인지
2. V1 아키텍처 설계: V1이 왜 단일 EC2 + Docker Compose인지
3. V1 핵심 사용자 여정별 SLI/SLO 정의: 무엇을 기준으로 품질을 판단하는지
4. V2 서비스 확장 가정 및 V1의 한계 지점: 부하 측정으로 무엇이 먼저 무너졌는지
5. V2 백엔드 애플리케이션 인프라 설계: 그래서 V2를 어떻게 바꾸는지

인프라 결정의 출발점이 되는 팀 규모·예산·시장·트래픽 가정입니다. 이후 모든 문서의 수치 근거가 여기서 나옵니다.

_{⬆ 목차로}

비용과 운영 인력 제약 아래에서 V1을 EC2 1대 + Docker Compose 로 빠르게 띄우기 위한 설계와 구축 기록입니다.

_{⬆ 목차로}

_{⬆ 목차로}

_{⬆ 목차로}

"서비스가 느리다"를 숫자로 말하기 위해, 핵심 사용자 여정(CUJ)을 정하고 여정별 SLI/SLO를 정의했습니다. 5·6단계 부하 측정과 V2 목표의 판정 기준이 됩니다.

_{⬆ 목차로}

V2 성장 목표를 세우고, V1 구조에 부하를 걸어 어디가 먼저 포화되는지 실측한 문서들입니다. 6단계 V2 설계의 근거입니다.

_{⬆ 목차로}

5단계에서 찾은 한계 지점별로 V2 구조를 결정한 문서입니다.

_{⬆ 목차로}

V2를 운영하면서 장애를 사용자보다 먼저 알기 위한 관측·알림 설계입니다.

_{⬆ 목차로}