경험 중심 1인칭 답변
학부 캡스톤 프로젝트에서 사용자 트래픽이 불규칙한 서비스를 AWS로 설계한 경험이 있습니다. 트래픽 급증에 대응하기 위해 Auto Scaling Group과 ALB를 조합하고, DB 연결 과부하를 줄이기 위해 RDS 앞에 Connection Pooler를 두는 구조로 설계했습니다.
단일 리전에서 서비스가 중단됐을 때 복구 시간이 어느 정도인지를 먼저 정의하고, 그 RTO 기준에 맞춰 Multi-AZ와 Failover 설정을 결정했습니다. 비용 절감을 위해 비피크 시간대는 Spot Instance를 사용하는 방안도 검토했습니다.
분산 시스템 설계는 가용성과 비용의 트레이드오프를 먼저 정의해야 의미 있는 아키텍처 결정이 가능하다는 걸 그 과정에서 배웠습니다. 앞으로도 가용성·비용·복잡도의 트레이드오프를 RTO 기준에서 먼저 정의하고 아키텍처를 결정하는 방식을 유지하겠습니다. 분산 시스템 설계에서 가장 먼저 정해야 하는 건 허용 가능한 다운타임과 데이터 손실 범위입니다. 그 기준이 없으면 Multi-AZ나 Spot 인스턴스 같은 선택이 과잉일지 부족일지 판단할 수 없습니다.
클라우드 아키텍처는 완벽함보다 요구사항에 맞는 설계가 더 중요합니다.