서버 환경 구성하기4 - 성능과 가용성을 보장하기

데이터 엑세스 지연 시간 줄이기

온라인 트랜잭션 처리는 대부분을 데이터 액세스가 차지합니다. 정적 콘텐츠의 경우 CDN을 활용할 수 있고, 동적 콘텐츠/DB데이터의 경우 인메모리 캐시를 활용하여 지연 시간을 줄일 수 있습니다.

 

1) 캐시의 층위: L1 vs L2 (관용적 용어)

• L1 (Local / In-process / Near cache)
  • 각 앱 프로세스 메모리(Map/LRU/Caffeine 등)
  • 가장 빠름(네트워크 왕복 없음)
  • 인스턴스마다 값이 달라 일관성/무효화 관리 필요
• L2 (Distributed / Shared)
  • Redis/ElastiCache 같은 분산 인메모리 캐시
  • L1보다 느리지만 여러 서버가 공유하고 용량 확장 쉬움

2) 캐시 패턴: 언제/어떻게 채우고 지울까

• Cache-Aside (권장)
  • 읽기: 캐시에 없으면 → DB 조회 → 캐시에 넣고 반환
  • 쓰기: DB 갱신 후 캐시 무효화(삭제) 또는 새 값으로 갱신
  • 단순·명료, 점진 도입 쉬움
• Write-Through: 쓰기 시 캐시와 DB 동시 갱신, 읽기는 캐시에서(일관성↑, 쓰기 지연↑)
• Write-Back/Behind: 먼저 캐시에 쓰고 비동기로 DB 반영(레이턴시↓, 위험 관리 난이도↑)
• TTL + 버전 키
  • TTL로 자동 만료 + 키에 버전 포함(profile:v12:user:123)
  • 업데이트 시 버전 증가 → 즉시 최신 반영, 무효화 부담↓

3) Redis란?

• 인메모리(Key–Value) 데이터 저장소: 데이터를 RAM에 두고 초고속 접근.
• 캐시에 필수적인 기능 내장
  • TTL/만료: 키마다 수명 부여 → 자동 정리
  • Eviction 정책: 메모리 한계일 때 어떤 키부터 내보낼지(LRU/LFU 등)
  • 복제 및 고가용성: Primary–Replica, 장애 시 자동 승격(ElastiCache에서 관리)
  • 샤딩(Cluster): 16,384 슬롯 기반의 수평 확장
  • Pub/Sub·Streams: 변경 이벤트 전파, 비동기 처리에 활용
  • 풍부한 자료구조: String/Hash/Set/ZSet/Bitmap/HyperLogLog 등

4) AWS ElastiCache

Redis 서버의 복제·장애조치·패치·모니터링을 AWS가 관리해주는 서비스라고 생각하면 됩니다.

• 엔진: Redis 또는 Memcached (데이팅 앱 캐싱은 보통 Redis 권장)
• 고가용성/복제: 멀티 AZ, Primary-Replica 구성, 장애 시 자동 Failover
• 확장성:
  • (Redis) Cluster Mode: 샤딩으로 수평 확장(여러 샤드 + 각 샤드의 리플리카)
  • 온라인 수직/수평 확장(다운타임 최소화 절차 제공)
• 보안:
  • VPC 내 배치(프라이빗 서브넷)
  • 전송 구간 암호화(TLS), 암호/ACL(Redis 6+)
  • 보안그룹으로 접근 제어
• 백업/스냅샷(Redis): 지정 시간 스냅샷 + 유지 정책
• 운영 편의: 패치/마이너 업그레이드, CloudWatch 지표, 알람, 유지보수 작업 자동화

 

오토 스케일링으로 성능 보장

부하가 변하는 환경에서도 성능이 저하되지 않는 인프라를 설계하려면 부하에 따라 자동으로 서버 수를 늘리거나 데이터 액세스 응답 속도를 빠르게 하는 등의 성능에 대한 고려가 필요합니다. 위에서 살펴본 것은 후자이고, 이제 서버 수를 자동으로 늘리고 줄이는 것에 대해 살펴보겠습니다.

1. AWS CloudWatch

클라우드 워치는 EC2 인스턴스의 상태를 모니터링해 처리 능력이 부족하면 경보를 발생시킵니다. 이는 성능의 저하 뿐 아니라 재해가 일어났을 때에 서버의 장애를 감지할 수 있습니다. 이때 EC2의 자동 복구 기능을 통해 자동으로 재기동시킬 수 있습니다.

 

핵심 기능

1. Metrics (지표 수집)

• EC2 CPU 사용률, 메모리, 네트워크 I/O 같은 AWS 리소스 상태를 자동으로 수집합니다.
• 사용자 애플리케이션 지표(custom metrics)도 추가할 수 있어요.
• 수집한 지표를 대시보드에서 시각화 가능.

2. Logs (로그 관리)

• 애플리케이션 로그, 서버 로그, Lambda 로그를 CloudWatch Logs에 저장합니다.
• 로그 검색, 필터링, 집계가 가능해요.
• 예: ERROR 키워드가 들어간 로그만 모아서 알람 설정.

3. Alarms (알람 설정)

• 특정 지표가 임계치를 초과하면 알람을 발생시킵니다.
• 예: CPU 사용률이 80% 이상이면 알람 발송.
• 알람은 SNS(문자/이메일), Lambda 실행, Auto Scaling 정책 트리거 등과 연결할 수 있습니다.

4. Events (이벤트 처리)

• AWS 서비스에서 발생하는 이벤트(예: EC2 상태 변경, 배포 완료)를 감지해서 자동으로 동작을 실행할 수 있어요.
• 예: EC2가 중지되면 자동으로 다른 인스턴스를 시작하도록 설정

 

모니터링 항목

1. 기본 제공 Metrics (AWS 리소스 모니터링)

AWS 서비스별로 자동 수집되는 지표들이 있어요. 대표적으로:

• EC2 (가상 서버)
  • CPUUtilization (CPU 사용률)
  • NetworkIn / NetworkOut (네트워크 I/O)
  • DiskReadOps / DiskWriteOps (디스크 I/O)
  • StatusCheckFailed (인스턴스 상태 체크)
• RDS (데이터베이스)
  • CPUUtilization
  • FreeableMemory (남은 메모리)
  • DatabaseConnections (DB 연결 수)
  • ReadIOPS / WriteIOPS (디스크 읽기/쓰기 성능)
  • ReplicaLag (리드 리플리카 지연)
• ELB / ALB (로드밸런서)
  • RequestCount (요청 수)
  • HealthyHostCount / UnHealthyHostCount (정상/비정상 대상 수)
  • Latency (지연 시간)
  • HTTPCode_ELB_5XX (에러 응답 수)
• S3 (스토리지)
  • NumberOfObjects (객체 수)
  • BucketSizeBytes (버킷 크기)
  • AllRequests (요청 수)
• Lambda (서버리스 함수)
  • Invocations (호출 횟수)
  • Duration (실행 시간)
  • Errors (실패 횟수)
  • Throttles (제한 발생 수)

즉, CloudWatch는 AWS에서 운영되는 각 서비스의 성능, 리소스 사용량, 상태 지표를 자동으로 모니터링합니다.

2. Logs (CloudWatch Logs)

• 애플리케이션 로그, 시스템 로그, Lambda 로그를 수집·저장합니다.
• 로그 필터를 만들어 특정 패턴(예: ERROR)이 나오면 알람을 걸 수 있어요.
• EC2 인스턴스 로그도 CloudWatch Agent를 설치하면 수집 가능합니다.

3. Events (CloudWatch Events → EventBridge)

• AWS 리소스의 상태 변화 이벤트를 모니터링합니다.
  예:
  • EC2 인스턴스 시작/중지 이벤트
  • RDS 백업 완료 이벤트
  • IAM 정책 변경 이벤트
• 이벤트에 반응해 자동 작업을 실행할 수 있어요 (예: Lambda 실행, SNS 알림, Step Functions).

4. Custom Metrics (사용자 정의 지표)

• 기본 지표 외에, 사용자가 직접 애플리케이션 상태를 CloudWatch로 전송할 수 있습니다.
• 예:
  • API 요청 성공률
  • 특정 큐의 대기 메시지 개수
  • 사용자 세션 수

5. Alarms (모니터링 트리거)

• 위의 지표(Metrics)·로그·이벤트를 기준으로 조건을 걸어 알람을 발생시킵니다.
• 예:
  • CPUUtilization > 80% → Auto Scaling 실행
  • Errors > 100 → Slack/SNS로 알림

 

2. 오토 스케일링 그룹 설정

인스턴스 수에 대해 정책을 설정해두면, 그에따라 인스턴스 수가 자동으로 조정되도록 하는 것이 오토 스케일링입니다. 크게 두 가지 종류가 있습니다. 첫 번째는 스케줄러에 의해 정해진 수로 규모를 변경하는 '예약된 조정'과 인스턴스 사용 모니터링 결과에 따라 동적으로 변경하는 '동적 조정'이 있습니다. 전자는 업무 특성이나 과거의 사용 패턴으로부터 처리량이 많은 시기를 예상할 수 있을 때 사용합니다. 동적 조정은 예기치 않은 피크 발생에 대비할 필요가 있거나, 예상할 수 있다고 해도 필요한 리소스가 변동하는 경우에 사용합니다. 모니터링 서비스인 클라우드 워치에서 CPU 사용률, 요청 횟수 등을 모니터링하여 임계값에 도달했을 때 추가 인스턴스를 시작하도록 합니다. 이 두가지 방법은 함께 사용할 수 있습니다. 

 

오토 스케일링 그룹 설정

오토 스케일링으로 EC2가 자동으로 생성되도록 하기 위해서는 우선 AMI(가상 서버의 템플릿)이 만들어져 있어야 합니다. 또한 관리 콘솔에서 '오토 스케일링 그룹'을 작성합니다. 오토스케일링 그룹은 EC2 인스턴스 집합으로서 인스턴스 수를 설정할 수 있습니다. 오토 스케일링 그룹에 ELB를 붙이면 자동으로 요청이 분산됩니다. 

클라우드워치에 의한 모니터링 설정

예상치 못한 트래픽에 대비하기 위해서는 클라우드워치 모니터링 항목에 대해 임계값을 설정합니다. 즉, 인스턴스 수를 증가시키는 트리거와 감소시키는 트리거를 만듭니다. 감소에 대한 트리거를 만들어두지 않으면 리소스가 남아돌아도 인스턴스 수가 줄어들지 않게 됩니다. 예를 들어서 CPU 사용률을 모니터링하여 사용률이 70%를 초과하면 그룹 크기를 증가시키고 사용률이 50% 이하로 떨어지면 그룹 크기를 감소시킬 수 있습니다. 

EC2 인스턴스의 구매 옵션

구매 옵션은 온디멘드 인스턴스와 스팟 인스턴스가 있습니다. 온디멘드 인스턴스는 확실하게 시작 가능한 통상 가격의 인스턴스입니다. 스팟 인스턴스는 설정한 입찰 가격이 '실시간으로 변동되는 시장 가격'을 웃도는 동안만 시작할 수 있는 인스턴스입니다. 스팟 인스턴스의 평균 시장 가격은 온디멘드보다 훨씬 저렴하지만 인스턴스의 생명 주기를 마음대로 정할 수 없는 불확실성이 있기 때문에 이용 기업이 많지 않습니다. 

 

장애 발생을 전제로 설계하기

사람의 실수, 자연재해 등 여러 원인으로 서버에 장애가 생길 수 있습니다. 처음부터 이런 장애 발생을 전제로 하고 설계하면 장애 발생 시에도 서비스가 중단 없이 제공될 수 있습니다. 

 

단일 리전 내에서는 서버를 다중화하여 ELB로 연결하고, 단일 리전 내의 여러 가용 영역에 대해 EC2 인스턴스를 배치할 수 있습니다. 그러면 한 가용 영역이 완전히 중단되어도 다른 가용 영역에서 제공되는 EC2가 ELB에 의해 제공되기 때문에 서비스 중단이 없습니다. 만약 단일 리전 전체가 중단될 수도 있기 때문에, 다른 리전에 백업 사이트를 설치할 수도 있습니다. EC2는 메인 서버와 동일한 서버를 작성하고 동작시킬 수 있고, DB와 S3 도 크로스 리전 복제 기능을 활용하여 백업 사이트에 데이터를 동기화합니다. 그리고 Route 53을 사용하여 대상이 되는 ELB 를 바꿀 수 있습니다. 즉, 백업 사이트를 바라보는 다른 리전의 ELB로 도메인이 연결되도록 할 수 있습니다. 

 

Amazon Route 53

• DNS(Domain Name System) 서비스
• 웹사이트 주소(예: example.com) → 실제 서버 IP 주소로 변환해주는 역할.
• 단순히 “어느 서버(혹은 로드밸런서)로 보내줄까?”를 결정하는 네임 서버 역할을 합니다.

주요 기능

• 도메인 등록/관리: myapp.com 같은 도메인 등록 가능.
• DNS 라우팅:
  • 사용자를 가장 가까운 리전으로 보내는 지리적 라우팅
  • 서버 상태를 보고 정상 서버로만 보내는 헬스체크 라우팅
• 트래픽 분산: 여러 엔드포인트(EC2, ELB, S3, CloudFront) 중에서 조건에 따라 분산 가능.