Users
  ↓
Load Balancer (ELB)
  ↓
App Servers (3+ instances, auto-scaled)
  ↓
Cache Layer (Redis)
  ↓
Database (Primary + Read Replicas)
  ↓
Object Storage (S3)

장점:

개발과 디버깅이 간단함
배포와 수평 확장이 쉬움
운영 부담이 적음

단점:

코드베이스가 커지면 유지보수가 어려움
공유 데이터베이스가 확장을 제한함
특정 기술에 종속됨(언어, 프레임워크)

발전시킬 시점: 사용자 5만 명 이상에서 데이터베이스 병목이 발생할 때

패턴: 마이크로서비스 아키텍처

적합한 경우: 대규모 팀, 사용자 10만 명 이상, 여러 서비스

토폴로지:

API Gateway
├─ Auth Service
├─ User Service
├─ Product Service
├─ Order Service
├─ Payment Service
├─ Notification Service
└─ Analytics Service

Shared Infrastructure:
- Service Mesh (Istio, Linkerd)
- Message Bus (Kafka, RabbitMQ)
- Distributed Tracing
- Centralized Logging

장점:

서비스별 독립적인 확장
팀이 자율적으로 작업 가능
다양한 언어를 포함한 유연한 기술 선택
개별 서비스 배포가 쉬움

단점:

운영 복잡성 증가
분산 시스템의 과제(최종 일관성, 디버깅)
서비스 간 네트워크 지연
성숙한 DevOps 관행 필요

적합한 시점: 모놀리스가 병목이 되고, 이를 지원할 팀 구조까지 갖췄을 때

패턴: 서버리스(FaaS)

적합한 경우: 이벤트 기반, 가변 부하, 비용을 중시하는 워크로드

토폴로지:

API Gateway
  ↓
Lambda Functions (auto-scaled to zero)
  ├─ DynamoDB (serverless database)
  ├─ S3 (object storage)
  ├─ SQS/SNS (messaging)
  └─ CloudWatch Logs

장점:

실제 사용한 컴퓨팅 시간만 지불
유휴 상태에서 자동으로 0까지 축소
개발과 배포가 간단함
인프라 관리 불필요

단점:

콜드 스타트 지연
제한적인 환경 맞춤 설정
공급업체 종속(AWS Lambda, GCP Functions)
기존 서버보다 어려운 디버깅

적합한 경우: 갑작스러운 트래픽 증가, 드문 작업, 운영 인력이 적은 스타트업

패턴: 데이터 레이크 및 분석

적합한 경우: 빅데이터, 머신러닝, 분석 워크로드

토폴로지:

Data Sources (streaming + batch)
  ↓
Data Ingestion (Kafka, Kinesis, SQS)
  ↓
Data Lake (S3, Blob Storage)
  ↓
ETL/Transform (Spark, Glue, Dataflow)
  ↓
Data Warehouse (Redshift, BigQuery, Snowflake)
  ↓
BI/ML Tools (Tableau, DataStudio, SageMaker)

고려사항:

데이터 품질과 거버넌스
스키마 유연성(읽기 시 스키마와 쓰기 시 스키마)
개인 식별 정보(PII) 처리와 개인정보 규정 준수
쿼리 성능 최적화

최적화 전략

비용 최적화

1. 리소스 크기 적정화

최대 용량이 아니라 실제 사용량을 모니터링
CloudWatch 등으로 사용 패턴 파악
과도하게 할당된 인스턴스의 크기 축소

2. 예약 인스턴스

안정적인 워크로드 예측
1~~3년 예약 인스턴스 구매(20~~40% 할인)
변동 부하는 자동 확장과 결합

3. 스팟 인스턴스

장애를 허용할 수 있는 비핵심 워크로드에 사용
온디맨드보다 70% 저렴
2~5%의 중단율 예상

4. 캐싱 전략

자주 사용하는 데이터를 메모리에 캐시(Redis)
데이터베이스 부하를 50~80% 감소
정적 자산에 CDN 사용(80% 이상 비용 절감)

5. 데이터 전송 최적화

비용이 큰데도 자주 간과되는 항목
VPC 엔드포인트로 데이터 전송 요금 회피
전송 데이터를 압축
전 세계 배포에 CloudFront 사용

확장성 최적화

1. 수평 확장

로드 밸런서 뒤에 서버 추가
데이터베이스: 읽기 복제본 추가(기본과 복제본)
캐시: 캐시 노드 추가

2. 샤딩(데이터베이스)

키별로 데이터 분할(사용자 ID, 리전, 날짜)
각 샤드가 독립적으로 확장
절충점: 샤드 간 조정이 복잡해짐

3. 연결 풀링

데이터베이스 연결 재사용
처리량 2~3배 향상
연결 오버헤드 감소

4. 캐싱 전략

애플리케이션 계층에서 자주 쓰는 데이터 캐시
무효화 전략을 갖춘 API 응답 캐시
ORM 수준의 데이터베이스 쿼리 캐시

보안 모범 사례

1. 암호화

전송 중: 모든 엔드포인트에 TLS 1.3
저장 시: KMS 키를 사용하는 AES-256
데이터베이스: 암호화된 볼륨과 PII의 애플리케이션 수준 암호화

2. 인증과 인가

모든 사용자 계정에 MFA
외부 연동에 OAuth 2.0
최소 권한 IAM 정책
앱 사용자에 RBAC

3. 네트워크 보안

VPC 격리(데이터베이스용 프라이빗 서브넷)
필요한 포트만 허용하는 보안 그룹
추가 방어 계층으로 NACL
로드 밸런서에 WAF(웹 애플리케이션 방화벽)

4. 데이터 보호

PII 토큰화와 마스킹
민감 데이터의 필드 수준 암호화
데이터 보존 정책에 따른 오래된 데이터 삭제
백업 복구 테스트

5. 모니터링과 감사

모든 API 호출의 CloudTrail 및 감사 로그
이상 징후에 대한 CloudWatch 경보
정기 보안 감사
인시던트 대응 런북

성능 모범 사례

1. 지연 최적화

정적 자산에 CDN 사용
자주 사용하는 쿼리에 데이터베이스 인덱스
쿼리 최적화(N+1 쿼리 회피)
API 요청 일괄 처리

2. 처리량 최적화

서버 간 부하 분산
데이터베이스 연결 풀링
오래 걸리는 작업의 비동기 처리
CPU 집약적 워크로드의 수직 확장

3. 신뢰성

자동 복구를 포함한 상태 확인
의존 대상에 대한 서킷 브레이커
지수 백오프를 적용한 재시도
점진적인 기능 축소

배포 모범 사례

1. 코드형 인프라

모든 것을 Terraform 또는 CloudFormation으로 정의
버전 관리
적용 전 동료 검토
먼저 스테이징에서 테스트

2. 지속적 배포

자동 테스트(단위, 통합, E2E)
카나리 배포(점진적 출시)
블루그린 배포(중단 없음)
롤백 전략

3. 모니터링과 관측 가능성

구조화된 로그(JSON)
분산 추적(X-Ray, Jaeger)
메트릭 수집(Prometheus, CloudWatch)
오류뿐 아니라 SLO를 기준으로 경보

❌ 어느 곳이든 단일 장애 지점 존재(이중화 없음) ❌ 과도한 설계(성장에 필요해지기 전에 복잡한 아키텍처 도입) ❌ 비용 영향 무시(불필요한 기능 때문에 서비스 선택) ❌ 수동 확장(자동화해야 함) ❌ 모니터링 없음(상태를 알 수 없음) ❌ 재해 복구 계획 없음(희망은 전략이 아님) ❌ 모든 리소스를 하나의 가용 영역에 배치(데이터센터 장애에 취약)

다음 단계

패턴 라이브러리 탐색 → 패턴 라이브러리
아키텍처 분석 학습 → 분석 모듈
거버넌스 모범 사례 → 거버넌스

모범 사례

설계 원칙

1. 단순하게 시작하고 점진적으로 확장하기

2. 장애를 전제로 설계하기

3. 최적화 전에 측정하기

4. 절충점 이해하기

5. 모든 것을 자동화하기

일반적인 아키텍처 패턴

패턴: 모놀리식 웹 애플리케이션

패턴: 마이크로서비스 아키텍처

패턴: 서버리스(FaaS)

패턴: 데이터 레이크 및 분석

최적화 전략

비용 최적화

확장성 최적화

보안 모범 사례

성능 모범 사례

배포 모범 사례

안티패턴(피해야 할 것)

다음 단계

이 페이지의 내용