클라우드 & 성능 참조

클라우드 아키텍처 개념

Cloud-Native Application (클라우드 네이티브 애플리케이션)

탄력성, 분산 아키텍처, 컨테이너화, 매니지드 서비스 등 클라우드 특성을 활용하여 클라우드 환경에 특화 설계된 애플리케이션.

특징:

• Stateless (서버가 교체 가능)
• 수평 확장 가능 (더 큰 인스턴스 대신 더 많은 인스턴스 추가)
• 컨테이너화 (Docker/Kubernetes)
• 마이크로서비스 아키텍처
• 장애에 탄력적

이점: 낮은 비용, 빠른 배포, 내장된 이중화

Scaling Strategies (확장 전략)

Vertical Scaling (Scale-Up) — 수직 확장

기존 서버의 성능 향상 (CPU, 메모리, 디스크 추가).

서버 1대 CPU 1개 → 서버 1대 CPU 16개

장점:

• 단순함, 코드 변경 불필요
• 단기 해결책으로 적합

단점:

• 단일 장애점
• 하드웨어 한계
• 성능 대비 높은 비용
• 업그레이드 중 다운타임

Horizontal Scaling (Scale-Out) — 수평 확장

서버를 추가하여 부하를 분산.

대형 서버 1대 → 로드 밸런서 뒤에 소형 서버 10대

장점:

• 장애 허용 (서버 1대 장애 시 트래픽의 1/10만 영향)
• 비용 효율적
• 매우 큰 규모로 확장 가능
• 다운타임 없음 (동적으로 서버 추가)

단점:

• Stateless 아키텍처 요구
• 관리 복잡성 증가
• 네트워크 비용
• 분산 시스템 문제 (일관성, 조율)

Auto-Scaling (오토스케일링)

클라우드 경제학의 기반으로, 수요에 따라 리소스 수를 자동 조정.

Reactive Auto-scaling (반응형 오토스케일링)

메트릭이 임계값 초과 시 확장, 하락 시 축소.

트래픽 증가 → CPU > 80% → 스케일링 정책 트리거 → 2분 대기 → 서버 10% 추가

장점: 실제 수요에 반응

단점: 짧은 트래픽 급증은 처리 지연(수분)으로 일시적 성능 저하 가능

일반적인 트리거:

• 평균 CPU > 70%
• 메모리 > 80%
• 요청 큐 길이 > 100

Predictive Auto-scaling (예측형 오토스케일링)

과거 데이터에 머신러닝을 적용해 미래 리소스 필요량을 예측.

관찰된 패턴: 평일 오전 9~10시마다 트래픽 급증
ML 모델: 오전 8시 50분에 급증 예측
조치: 오전 8시 45분에 사전 스케일링
결과: 실제 급증 중 성능 저하 없음

장점: 급증으로 인한 영향 없음, 비용 최적화

단점: 과거 데이터 필요, 비정상 패턴에 실패 가능

사용처: AWS AutoScaling, Google Cloud AutoML

Scheduled Auto-scaling (예약형 오토스케일링)

예측 가능한 패턴에 유용한 시간 기반 스케일링 규칙.

월~금 오전 9시: 서버 100대로 확장 (업무 시간)
월~금 오후 6시: 서버 20대로 축소 (저녁)
주말: 서버 5대 (최소 수요)

장점: 예측 가능, 비용 효율적, 복잡성 없음

단점: 유연성 없음 (긴급 상황이나 비정상 상황에 적응 불가)

Load Balancer (로드 밸런서)

리소스 사용 및 가용성 최적화를 위해 여러 서버에 수신 요청/트래픽을 분산.

주요 기능:

1. 트래픽 분산: 라운드로빈, 최소 연결, 가중치 방식
2. 헬스 체크: 죽은 서버 감지 및 로테이션에서 제거
3. 세션 지속성: 동일 클라이언트를 동일 백엔드로 라우팅
4. SSL 종료: HTTPS 암호화/복호화 처리

유형:

• Layer 4 (네트워크): TCP/UDP 수준, 매우 빠르고 단순
• Layer 7 (애플리케이션): HTTP 수준, URL/호스트/쿠키로 라우팅 가능

예시 흐름:

클라이언트 1 → 요청 → 로드 밸런서 → 서버 A
클라이언트 2 → 요청 → 로드 밸런서 → 서버 B
클라이언트 3 → 요청 → 로드 밸런서 → 서버 C
(각 서버가 약 동일한 부하를 받음)

Failover & High Availability (페일오버 및 고가용성)

Active-Passive (Failover) Architecture — 액티브-패시브 아키텍처

주 시스템이 트래픽을 처리; 대기 시스템은 주 시스템 장애 시까지 유휴 상태.

정상: 트래픽 → 주 서버       ; 백업 서버 유휴
장애: 트래픽 → 주 서버 (장애) → 페일오버 → 백업 서버

RTO (복구 시간 목표): 감지 + 전환에 5~30초

비용: 인프라 약 2배, 하나의 시스템만 실제 작동

사용 사례: 보장된 복구가 필요한 중요 시스템

Active-Active Architecture — 액티브-액티브 아키텍처

여러 시스템이 동시에 트래픽을 처리; 하나 장애 시 나머지가 부하 흡수.

트래픽 분산:
   ↙ 서버 A (25% 처리)
클라이언트 ↓ 서버 B (25% 처리)
   ↘ 서버 C (25% 처리)

서버 A 장애 시:
   서버 B, C가 자동으로 각각 50% 처리 (다운타임 없음)

RTO: 1초 미만 (즉각 자동)

비용: 동일 인프라, 모든 시스템이 활성 (비용 중립 또는 저렴 가능)

사용 사례: 대부분의 클라우드 애플리케이션, 더 나은 경제성

Regional & Multi-Region Deployment (리전 및 멀티 리전 배포)

Single Region (단일 리전)

모든 서비스를 하나의 지리적 위치에 배치.

클라우드 리전: 서울
├─ 서버 A
├─ 서버 B
└─ 서버 C

장점: 단순함, 단일 유지보수 구역

단점:

• 리전 재해 = 완전한 서비스 중단
• 원거리 사용자에게 높은 레이턴시
• 주요 장애에 대한 이중화 없음

Multi-Region (멀티 리전)

지리적으로 멀리 떨어진 여러 리전에 서비스 복제.

아시아-태평양          유럽-서부          미국-동부
├─ 서비스              ├─ 서비스          ├─ 서비스
└─ 데이터베이스         └─ 데이터베이스     └─ 데이터베이스
           ↓                    ↓                    ↓
      (동기화)            (동기화)             (동기화)

장점:

• 사용자 레이턴시 감소 (가장 가까운 리전에 접근)
• 재해 복구 (하나의 리전 장애 시 다른 리전이 트래픽 처리)
• 규정 준수 (데이터 레지던시)

단점:

• 복잡성 증가 (데이터 동기화 문제)
• 멀티 리전 비용
• 리전 간 레이턴시

일반적인 RTO: 5~15분 (정상 리전으로 자동 페일오버)

Content Delivery Network (CDN) — 콘텐츠 전송 네트워크

사용자 가까이에서 콘텐츠를 캐싱하는 지리적으로 분산된 네트워크.

동작 원리:

1. 한국 사용자가 미국에 있는 이미지를 요청
2. CDN이 요청을 가로챔
3. CDN이 서울 엣지 위치에서 캐시를 확인
4. 캐시 히트 → 서울에서 즉시 이미지 제공 (5~10ms 레이턴시)
5. 캐시 미스 → 미국 원본에서 가져와 서울에 캐싱 후 사용자에게 전달

이점:

• 레이턴시 감소 (사용자가 가장 가까운 위치에서 콘텐츠 받음)
• 원본 서버 부하 감소
• DDoS 방어 (트래픽 흡수)
• 대역폭 절감

주요 서비스: Cloudflare, AWS CloudFront, Akamai

---

성능 메트릭 및 SLA

Service Level Agreement (SLA) — 서비스 수준 협약

서비스 가용성 및 성능에 대한 계약적 약속.

AWS SLA 예시:
- 월간 업타임 99.99% 보장 (월 최대 4분 다운타임)
- SLA 크레딧: 미달 시 고객에게 환불

일반적인 SLA 등급:

• 99%: 소규모 스타트업 (월 다운타임 8.7시간 허용)
• 99.9%: 표준, 대부분의 서비스 (월 43분 다운타임)
• 99.99%: 고가용성 (월 4분 다운타임)
• 99.999%: 엔터프라이즈 중요 (월 약 26초 다운타임)

비용은 각 9마다 기하급수적으로 증가 (9 → 99 → 999 → 9999)

Service Level Objective (SLO) — 서비스 수준 목표

SLA보다 엄격한 내부 목표로, 조기 경보 임계값 역할.

예시:
- SLA: 99.9% 업타임 (계약)
- SLO: 99.95% 업타임 (내부 목표)

SLO 위반 시 → 팀이 원인 조사,
SLA 위반(고객 영향) 전에 대응

이점: 조기 경보 시스템 역할

Service Level Indicator (SLI) — 서비스 수준 지표

SLO 달성을 반영하는 실제 측정된 성능 메트릭.

SLI 예시:

• 오류율 < 0.1% (업타임 지표)
• P95 레이턴시 < 100ms (성능 지표)
• 요청 성공률 > 99.95%

공식:

SLI 달성률 = 성공 요청 수 / 전체 요청 수

SLI > SLO → 정상
SLI < SLO → 비정상 (조사 필요)

Apdex (Application Performance Index) — 애플리케이션 성능 지수

애플리케이션 성능에 대한 사용자 만족도를 측정하는 0~1.0 점수.

Apdex 점수 = (만족 + 허용/2) / 전체 요청

만족:    응답 시간 < 1.5초
허용:    응답 시간 1.5~4.5초
불만:    응답 시간 > 4.5초

예시:
90 만족 + 5 허용 + 5 불만 = 100 요청
Apdex = (90 + 5/2) / 100 = 0.925 (양호)

등급 기준:

• 0.94~1.0: 우수 (Excellent)
• 0.85~0.94: 양호 (Good)
• 0.75~0.85: 보통 (Fair)
• < 0.75: 불량 (Poor)

시간 기반 가용성 메트릭

Uptime / Availability — 업타임 / 가용성

시스템이 운영 중인 시간의 비율.

업타임 = (전체 시간 - 다운타임) / 전체 시간

예시:
1개월 (30일 = 43,200분)
다운타임: 43분
업타임 = (43,200 - 43) / 43,200 = 99.9%

연간 허용 분 계산:

• 99%: 연간 525.6분
• 99.9%: 연간 52.6분
• 99.99%: 연간 5.26분
• 99.999%: 연간 26.3초

Mean Time Between Failures (MTBF) — 평균 장애 간격

시스템이 하나의 인시던트에서 복구된 후 다음 장애까지의 평균 시간.

MTBF = 총 운영 시간 / 장애 횟수

예시:
- 시스템이 365일 운영됨
- 2번의 장애 발생
- MTBF = 365 / 2 = 182.5일 평균 장애 간격

높은 MTBF: 장애 사이에 1개월 이상 (바람직함)

Mean Time To Repair (MTTR) — 평균 수리 시간

장애를 수정하는 평균 시간. 인시던트 MTTR(시작 → 해결)과 다름.

MTTR = 총 수리 시간 / 장애 횟수

예시:
- 수리에 각각 30분, 90분 걸린 2번의 장애
- MTTR = (30 + 90) / 2 = 60분 평균 수리 시간

MTTR 개선 방법:

• 런북 (더 빠른 진단)
• 자동화 (더 빠른 수정)
• 이중화 (수정 대신 전환)

Availability Equation — 가용성 방정식

MTBF, MTTR, 가용성 사이의 수학적 관계.

가용성 = MTBF / (MTBF + MTTR)

예시:
- MTBF: 60일
- MTTR: 1시간
- 가용성 = 60일 / (60일 + 1시간) = 99.93%

99.99%로 개선하려면:
- 높은 MTBF (매우 신뢰성 높음, 거의 장애 없음)
- 짧은 MTTR (매우 빠른 복구)

---

분산 시스템 과제

CAP Theorem (CAP 정리)

근본적 트레이드오프: 분산 시스템은 3가지 속성 중 최대 2가지만 가질 수 있다.

         일관성 (Consistency)
              ∆
             /|\
            / | \
           /  |  \
          /   |   \
      C  /    |    \  A
        /     |     \
       /       |     \
      /________|______\
   CP        CAP        AP
  (드묾)    (균형)   (일반적)

C = Consistency (모든 노드가 동일 데이터를 봄)
A = Availability (시스템이 항상 응답)
P = Partition Tolerance (네트워크 분리 생존)

유형:

CA (일관성 + 가용성, 분리 내성 없음):

• 모든 노드가 같은 위치에 있어야 함 (네트워크 지연 허용 안 됨)
• 현대 시스템에서는 드묾 (비현실적 가정)

CP (일관성 + 분리 내성):

• 네트워크 분리 발생 시 시스템은 사용 불가 상태가 됨
• 충돌하는 데이터 없음 보장
• 예시: 전통적인 데이터베이스, 레거시 시스템
• 트레이드오프: 일관성을 위해 가용성 포기

AP (가용성 + 분리 내성):

• 네트워크 분리 시 가용하지만 데이터 불일치 가능
• 대부분의 클라우드 시스템이 이를 선택 (네트워크 분리는 발생함)
• 예시: NoSQL 데이터베이스, Eventual Consistency
• 트레이드오프: 가용성을 위해 즉각적 일관성 포기

실제로는: 모든 현대 시스템은 P(분리 내성). 선택은 C vs. A.

Eventual Consistency (최종 일관성)

데이터가 즉시는 아니지만 결국 모든 노드에서 일관되게 되는 방식.

노드 A에 쓰기 → 노드 A 성공 반환 → 비동기로 노드 B에 복제
복제 전 노드 B에서 읽기 → 오래된 데이터 반환
복제 후 노드 B에서 읽기 → 올바른 데이터 반환

이유: 가용성 향상, 글로벌 분산에 필요

Distributed Tracing (분산 추적)

레이턴시를 파악하기 위해 마이크로서비스 전반에서 요청 흐름을 추적.

사용자 요청 유입:
  → API Gateway (20ms)
    → Auth Service (50ms)
      → User Service (100ms)
        → Database (30ms)
      ← (30ms 반환)
    ← (100ms 반환)
  ← (50ms 반환)
← (총 레이턴시: 250ms)

도구: Jaeger, Zipkin, Datadog, OpenTelemetry

가치: 마이크로서비스 체인에서 병목 식별

---

부하 테스트를 위한 데이터베이스 개념

Connection Pool (커넥션 풀)

재사용을 위해 미리 열어둔 데이터베이스 커넥션 세트.

풀링 없이:
요청 1 → 커넥션 열기 → 쿼리 실행 → 커넥션 닫기 (느림)
요청 2 → 커넥션 열기 → 쿼리 실행 → 커넥션 닫기 (느림)

풀링 있음:
커넥션 풀 (미리 열린 커넥션 10개)
요청 1 → 커넥션 A 대여 → 실행 → 풀에 반환
요청 2 → 커넥션 B 대여 → 실행 → 풀에 반환
요청 3 → 커넥션 A 재사용 → 실행 → 반환
(훨씬 빠름, 열기/닫기 오버헤드 없음)

일반적인 풀 크기: 부하에 따라 5~50개 커넥션

Read Replica (읽기 레플리카)

읽기 전용 쿼리를 처리하는 데이터베이스 복사본, 주 DB는 계속 쓰기 처리.

쓰기 → 주 DB → 복제 → 읽기 레플리카 1 ←─ 읽기 쿼리
                     → 읽기 레플리카 2 ←─ 읽기 쿼리

사용 사례: 여러 레플리카에 읽기 부하 분산

참고: 읽기 레플리카는 약간 지연됨 (즉각적 일관성 아님)

Query Optimization (쿼리 최적화)

인덱싱 및 재구성을 통해 데이터베이스 쿼리를 빠르게 만드는 것.

일반적인 느린 쿼리 패턴:

• 전체 테이블 스캔 (인덱스 누락)
• N+1 쿼리 (100개 항목 로드 + 세부 사항에 대한 개별 쿼리 100개)
• 비효율적인 JOIN (잘못된 키, 인덱스 누락)

최적화 효과:

느린 쿼리: SELECT * FROM users;  (100만 행 스캔에 1000ms)
인덱스 적용: SELECT * FROM users WHERE email='x@y.com';  (인덱스로 10ms)
개선: 100배 빠름

Database Locks (데이터베이스 Lock)

동일 데이터의 동시 수정을 방지하는 메커니즘.

유형:

• 읽기 Lock: 여러 읽기 허용, 쓰기 불가
• 쓰기 Lock: 독점 접근, 다른 읽기/쓰기 불가

Lock 경합: 너무 많은 Lock이 큐잉을 유발해 동시성 감소

---

모니터링 및 관측 가능성 도구

Metrics (메트릭)

시계열 데이터: CPU%, 메모리%, 레이턴시, 처리량, 오류율.

특성:

• 수치값
• 타임스탬프 포함
• 집계 가능 (서버 전반 평균 CPU)
• 실시간 대시보드

도구: Prometheus, Datadog, New Relic, CloudWatch

Logs (로그)

상세 이벤트 기록: [2024-03-23 14:30:45] 사용자 로그인 실패: 잘못된 비밀번호

특성:

• 컨텍스트가 있는 텍스트 라인
• 고카디널리티 (많은 고유 값)
• 대용량
• 특정 문제 디버깅에 사용

도구: ELK Stack, Datadog, Splunk, CloudWatch Logs

Traces (트레이스)

레이턴시 분석을 보여주는 서비스 전반의 요청 흐름.

특성:

• 요청 수준 상세 정보
• 서비스 의존성 표시
• 병목 식별
• 대용량, 자주 샘플링

도구: Jaeger, Zipkin, Datadog, AWS X-Ray

Dashboard (대시보드)

메트릭 및 로그의 실시간 시각화.

표시할 핵심 메트릭:

• 요청 속도 (RPS)
• 오류율
• P95 레이턴시
• CPU 사용률
• 활성 사용자/세션
• 온콜 알림 상태

목적: 운영자가 시스템 상태를 한눈에 파악

Alerting System (알림 시스템)

메트릭이 임계값을 위반할 때 자동으로 알림 전송.

구성 요소:

• 메트릭 수집 (모니터링에서)
• 임계값 평가 (메트릭 > 임계값인가?)
• 알림 라우팅 (누가 알아야 하는가?)
• 알림 채널 (이메일, SMS, PagerDuty, Slack)

모범 사례:

• 조치 가능한 문제에만 알림
• 오탐 최소화를 위한 임계값 조율
• 명확한 알림 이름과 설명
• 알림에 런북 링크 포함

---

비용 최적화

Reserved Instances / Savings Plans — 예약 인스턴스

알려진 기본 부하에 대해 할인된 가격으로 컴퓨팅 용량을 사전 구매.

On-Demand: 서버 시간당 $3 지불
Reserved:  3년치 선불 시 시간당 $1 (67% 할인)

24/7/365 서버 필요 시 → 예약 인스턴스 사용
변동 부하 → 온디맨드 오토스케일링 사용

Right-Sizing (적절한 사이즈 조정)

실제 워크로드 필요에 맞는 인스턴스 유형 선택.

문제: 피크 기준으로 사양 결정 (CPU 100개, RAM 500GB)이지만
      평균적으로 CPU 10개, RAM 50GB만 사용 = 90% 낭비

해결: 평균 부하에는 소형 인스턴스, 피크에는 오토스케일
결과: 80~90% 비용 절감

Spot Instances / Pre-Emptible Instances — 스팟 인스턴스

클라우드 제공업체가 종료할 수 있는 할인된 인스턴스.

표준: 시간당 $3 (보장)
스팟: 시간당 $0.90 (2분 경고 후 종료 가능)

사용 사례: 배치 작업, 장애 허용 가능한 백그라운드 작업
사용 금지: 시간 중요, 고객 facing 서비스

CDN & Edge Computing — CDN 및 엣지 컴퓨팅

비용이 많이 드는 이그레스 대역폭 절감: 엣지 위치에서 서비스 제공.

호주 사용자가 10MB 파일 요청:
- CDN 없음: 미국 원본에서 10MB 전체 전송 = 비용 $1.20
- CDN 있음: 시드니 엣지에서 캐시 제공 = 현지 사용, $0.15
절감: 87.5%

---

핵심 교훈

✅ 클라우드 네이티브: 수평 확장, Stateless, 컨테이너화

✅ 멀티 리전: 레이턴시 감소 및 재해 대비

✅ 모니터링: 메트릭 + 로그 + 트레이스 (관측 가능성)

✅ SLA/SLO/SLI: 계약, 내부, 측정된 성능 정렬

✅ CAP 정리: 분리 내성 수용, 일관성 vs. 가용성 선택

✅ 비용 최적화: 예약 인스턴스, 적절한 사이즈 조정, 엣지 캐싱

❌ 단일 리전: 리전 재해 시 완전한 서비스 중단

❌ 수직 확장만 사용: 비용 높음, 유연성 없음, 장애 내성 낮음

❌ 모니터링 없음: 고객이 불평할 때까지 문제를 모름

❌ 과다 프로비저닝: 미사용 용량에 돈 낭비