클라우드 인프라를 운영할 때 중요한 것은 단순히 서버를 실행하는 것이 아니다. 필요한 성능을 안정적으로 제공하면서 불필요한 비용을 줄이고, 장애가 발생하더라도 서비스를 복구할 수 있는 구조를 만드는 것이 핵심이다.
AWS와 같은 클라우드 환경에서는 리소스 사용량 분석, 오토스케일링, 가용 영역을 활용한 고가용성 설계, 백업 및 복구 전략을 종합적으로 고려해야 한다.
특히 실시간 게임 플랫폼이나 멀티플레이어 서버는 접속자 수와 트래픽이 시간에 따라 크게 변할 수 있다. 따라서 평균 사용량만을 기준으로 서버를 구성하면 트래픽이 급증할 때 성능 문제가 발생하고, 반대로 최대 사용량만을 기준으로 구성하면 유휴 시간에도 높은 비용이 발생한다.
리소스 사용량 분석
리소스 사용량 분석은 서버의 실제 부하를 파악하고 비용과 성능을 최적화하기 위한 과정이다.
CPU, 메모리, 네트워크, 디스크 I/O, 데이터베이스 연결 수 등의 지표를 수집하고 분석하면 현재 인프라가 적절하게 구성되어 있는지 판단할 수 있다.
주요 모니터링 지표
| 지표 | 분석 목적 |
|---|---|
| CPU 사용률 | 연산 부하와 처리 능력 확인 |
| 메모리 사용량 | 메모리 부족 및 누수 확인 |
| 네트워크 처리량 | 트래픽 증가와 네트워크 병목 분석 |
| 디스크 I/O | 저장소 읽기·쓰기 병목 분석 |
| 응답 지연 시간 | 사용자 체감 성능 확인 |
| 오류율 | 서버 과부하와 장애 징후 확인 |
| DB 연결 수 | 커넥션 풀 고갈 여부 확인 |
| 요청 처리량 | 서버가 처리하는 요청 규모 확인 |
CPU 사용률이 높다고 무조건 서버 사양을 높여야 하는 것은 아니다. 비효율적인 쿼리, 동기식 작업, 불필요한 반복 연산 등 애플리케이션 내부의 병목이 원인일 수 있다.
반대로 CPU 사용률은 낮지만 응답 시간이 길다면 데이터베이스 대기, 외부 API 지연, 락 경합 또는 네트워크 지연을 의심해야 한다.
따라서 리소스 지표와 애플리케이션 지표를 함께 분석해야 한다.
AWS 모니터링 도구
AWS 환경에서는 Amazon CloudWatch를 활용해 EC2, RDS, ElastiCache 등의 지표를 수집하고 대시보드와 경보를 구성할 수 있다.
- CloudWatch Metrics: CPU 사용률, 네트워크 처리량 등 수치형 지표 수집
- CloudWatch Logs: 애플리케이션 로그 수집 및 검색
- CloudWatch Alarms: 임계치 초과 시 알림 또는 자동화 작업 실행
- AWS Cost Explorer: 서비스별 비용과 사용량 분석
- AWS Compute Optimizer: 수집된 사용량을 기반으로 적절한 컴퓨팅 리소스 검토
모니터링은 장애가 발생한 뒤 원인을 찾는 용도로만 사용해서는 안 된다. 사용량 증가 추세를 분석해 장애를 사전에 예방하고, 실제 부하에 맞춰 리소스를 조정하는 데 활용해야 한다.
비용 최적화의 기본 원칙
비용을 줄이기 위해 무조건 저사양 인스턴스를 선택하면 안 된다. 서버 사양을 낮춘 결과 처리량이 감소하고 응답 시간이 길어지면, 같은 요청을 처리하기 위해 더 많은 서버가 필요해질 수 있다.
중요한 것은 비용 자체가 아니라 일정한 성능을 제공하는 데 필요한 총비용이다.
예를 들어 서버 사양을 높여 인스턴스당 처리량을 개선하면 전체 서버 수를 줄일 수 있다. 반대로 메모리 부족으로 장애가 반복된다면 메모리 최적화와 적절한 인스턴스 선정이 비용 절감보다 우선이다.
오토스케일링 정책
오토스케일링은 서비스 부하에 따라 서버 인스턴스 수를 자동으로 조정하는 기능이다.
트래픽이 증가하면 서버를 추가하고, 트래픽이 감소하면 불필요한 서버를 제거해 성능과 비용을 함께 관리한다.
AWS에서는 EC2 Auto Scaling과 Application Load Balancer를 조합해 여러 EC2 인스턴스에 요청을 분산하고 인스턴스 수를 자동으로 조절할 수 있다.
오토스케일링의 주요 방식
Target Tracking Scaling
특정 지표를 목표값에 가깝게 유지하도록 인스턴스 수를 조정한다.
예를 들어 평균 CPU 사용률을 목표 수준으로 유지하도록 설정할 수 있다. 구성과 운영이 비교적 간단해 일반적인 웹 서버에 적합하다.
Step Scaling
지표가 임계치를 얼마나 초과했는지에 따라 서로 다른 규모로 확장한다.
CPU 사용률이 일정 수준을 초과하면 소수의 인스턴스를 추가하고, 더 높은 임계치를 초과하면 더 많은 인스턴스를 추가하는 방식이다.
Scheduled Scaling
예측 가능한 시간대에 맞춰 인스턴스 수를 미리 조정한다.
게임 이벤트, 정기 점검 종료, 출퇴근 시간대처럼 트래픽 증가 시점을 예측할 수 있는 서비스에 유용하다.
Predictive Scaling
과거 사용량 패턴을 분석해 미래의 수요를 예측하고 사전에 용량을 확보한다. 반복적인 트래픽 패턴이 있는 서비스에서 활용할 수 있다.
오토스케일링 정책 설계 시 고려 사항
오토스케일링은 인스턴스를 추가한다고 즉시 처리 능력이 증가하는 구조가 아니다. 인스턴스 시작, 애플리케이션 초기화, 캐시 준비, 헬스 체크 통과 등의 과정이 필요하다.
따라서 트래픽이 급증한 뒤 확장을 시작하면 이미 응답 지연이나 오류가 발생할 수 있다.
이를 방지하려면 다음 사항을 고려해야 한다.
- 최소 인스턴스 수를 설정해 기본 가용 용량을 확보한다.
- 최대 인스턴스 수를 설정해 비용 폭증을 방지한다.
- 확장과 축소에 서로 다른 정책을 적용한다.
- 축소 시 일정한 대기 시간을 두어 잦은 증감을 방지한다.
- CPU뿐 아니라 요청 수, 응답 지연 시간, 큐 적체량 등을 활용한다.
- 인스턴스가 정상적으로 트래픽을 처리할 수 있는지 헬스 체크로 확인한다.
- 데이터베이스와 외부 서비스가 확장된 트래픽을 감당할 수 있는지 검증한다.
특히 서버 인스턴스만 확장하고 데이터베이스 연결 수를 관리하지 않으면, 서버가 늘어날수록 데이터베이스 연결 요청이 폭증할 수 있다. 오토스케일링은 전체 시스템의 처리 용량을 고려해 설계해야 한다.
실시간 게임 서버의 특성
실시간 게임 서버는 일반적인 HTTP 요청 처리 서버와 다른 특성이 있다.
WebSocket 연결을 유지하는 서버에서는 인스턴스가 제거될 때 해당 인스턴스에 연결된 클라이언트의 연결이 종료될 수 있다. 따라서 인스턴스 수를 줄이는 과정에서 연결 종료와 재접속을 처리해야 한다.
또한 게임 세션 상태가 특정 서버의 메모리에만 저장되어 있다면 서버를 추가하거나 제거하는 것만으로는 원활한 확장이 어렵다.
이를 해결하려면 다음과 같은 구조를 고려할 수 있다.
- 세션과 게임 상태의 소유권을 명확히 정의한다.
- 공유가 필요한 상태는 Redis나 데이터베이스 등 외부 저장소에 관리한다.
- 서버 종료 전에 신규 연결을 차단하고 기존 세션을 정리하는 드레이닝 절차를 둔다.
- 매칭 서버와 게임 서버의 확장 정책을 분리한다.
- 연결 수와 메시지 처리량을 함께 관측한다.
오토스케일링의 목적은 서버 수를 자동으로 조정하는 것이 아니라, 부하 변화에도 서비스가 정상적으로 동작하도록 처리 용량을 유지하는 것이다.
가용 영역과 고가용성
고가용성(High Availability, HA)은 특정 서버나 인프라 구성 요소에 장애가 발생하더라도 서비스 중단을 최소화하는 설계 방식이다.
AWS에서는 여러 가용 영역(Availability Zone, AZ)에 리소스를 분산해 하나의 가용 영역에서 장애가 발생하더라도 다른 가용 영역에서 서비스를 지속할 수 있도록 구성한다.
가용 영역은 독립적인 장애 대응을 고려해 설계된 데이터센터 단위의 인프라 영역이다. 동일 리전 내 여러 가용 영역을 사용하면 단일 영역에 장애가 집중되는 위험을 줄일 수 있다.
단일 가용 영역 구성의 한계
모든 서버를 하나의 가용 영역에 배치하면 구성이 단순하고 비용을 줄이기 쉽다. 하지만 해당 영역에 장애가 발생하면 서비스 전체가 영향을 받을 수 있다.
서버 자체의 장애뿐 아니라 네트워크, 전원, 데이터센터 관련 문제까지 고려하면 단일 영역 구성은 서비스 연속성을 보장하기 어렵다.
다중 가용 영역 구성
다중 가용 영역 환경에서는 여러 영역에 서버를 배치하고 로드 밸런서를 통해 요청을 분산한다.
예를 들어 Application Load Balancer가 여러 가용 영역의 EC2 인스턴스로 트래픽을 전달하도록 구성할 수 있다. 특정 영역의 인스턴스가 정상적으로 응답하지 않으면 헬스 체크 결과를 바탕으로 해당 인스턴스에 대한 트래픽 전달을 중단할 수 있다.
데이터베이스도 별도의 고가용성 구성이 필요하다. Amazon RDS Multi-AZ는 지원되는 구성에서 대기 인스턴스와 장애 조치 기능을 제공해 데이터베이스 가용성을 높인다.
다만 다중 가용 영역을 사용한다고 모든 장애가 자동으로 해결되는 것은 아니다.
애플리케이션 설정 오류, 잘못된 배포, 공통 데이터베이스 장애, 계정 권한 문제, 리전 단위 장애 등은 별도로 고려해야 한다.
고가용성 설계의 핵심 원칙
- 단일 서버 장애가 전체 서비스 장애로 이어지지 않도록 한다.
- 여러 가용 영역에 애플리케이션 인스턴스를 분산한다.
- 로드 밸런서의 헬스 체크를 구성한다.
- 데이터베이스와 캐시의 장애 대응 방식을 별도로 설계한다.
- 세션과 상태 정보를 특정 서버에 과도하게 종속시키지 않는다.
- 장애 조치 이후에도 데이터 정합성이 유지되는지 검증한다.
- 배포 오류와 인프라 장애를 구분해 대응할 수 있도록 한다.
고가용성은 단순히 서버를 여러 대 실행하는 것으로 완성되지 않는다. 장애가 발생했을 때 트래픽이 정상적인 구성 요소로 이동하고, 데이터가 보호되며, 애플리케이션이 복구 절차를 수행할 수 있어야 한다.
백업 및 복구 전략
백업 및 복구 전략은 데이터 손실과 서비스 중단을 최소화하기 위한 계획이다.
서버 장애뿐 아니라 데이터 삭제 실수, 잘못된 배포, 랜섬웨어, 데이터 손상, 리전 장애 등 다양한 상황을 고려해야 한다.
특히 데이터베이스를 사용하는 게임 플랫폼에서는 계정 정보, 포인트 잔액, 결제 내역, 아이템 보유 정보, 경기 결과와 같은 데이터가 중요하다. 이러한 데이터가 손실되면 단순한 서비스 재시작만으로는 복구할 수 없다.
백업의 종류
전체 백업
복구에 필요한 전체 데이터를 저장한다. 복구 절차가 단순해질 수 있지만 저장 공간과 백업 시간이 많이 필요할 수 있다.
증분 백업
마지막 백업 이후 변경된 데이터만 저장한다. 저장 공간과 백업 시간을 줄일 수 있지만 복구 시 여러 백업 데이터가 필요할 수 있다.
스냅샷
특정 시점의 저장소나 시스템 상태를 보존한다. 빠른 복구나 환경 복원에 유용하지만, 서비스와 데이터베이스의 일관성을 고려해야 한다.
시점 복구(Point-in-Time Recovery)
지원되는 데이터베이스에서 백업과 트랜잭션 로그 등을 활용해 특정 시점으로 데이터를 복구하는 방식이다. 잘못된 데이터 변경이 발생하기 직전 상태로 돌아가야 할 때 유용하다.
AWS 백업 관련 서비스
- AWS Backup: 지원되는 AWS 리소스의 백업 정책과 보존을 중앙에서 관리한다.
- Amazon RDS 자동 백업: 지원되는 RDS 구성에서 백업과 시점 복구를 지원한다.
- Amazon S3 Versioning: 객체의 여러 버전을 보존해 잘못된 덮어쓰기나 삭제에 대응할 수 있다.
- Amazon EBS Snapshots: EBS 볼륨 데이터를 스냅샷으로 보존한다.
- AWS Elastic Disaster Recovery: 지원되는 환경에서 재해 복구를 위한 복제와 복구 절차를 제공한다.
서비스별 지원 범위와 복구 조건은 서로 다르므로 실제 운영 환경에 맞춰 설정해야 한다. 백업이 존재한다는 사실만으로 복구 가능성이 보장되지는 않는다.
RPO와 RTO
백업 및 복구 전략을 수립할 때는 RPO와 RTO를 정의해야 한다.
RPO(Recovery Point Objective) 는 장애 발생 시 허용할 수 있는 데이터 손실의 범위를 의미한다.
RPO가 짧을수록 장애 직전까지의 데이터를 보존해야 하므로 백업 주기, 로그 보존, 복제 방식 등을 더 엄격하게 설계해야 한다.
RTO(Recovery Time Objective) 는 장애 발생 후 서비스를 복구하기까지 허용할 수 있는 시간을 의미한다.
RTO가 짧다면 백업 데이터만 보관하는 방식으로는 부족할 수 있다. 대기 인프라, 자동화된 복구 절차, 사전 구성된 네트워크와 권한, 복구 훈련 등이 필요하다.
예를 들어 포인트 정산 시스템은 데이터 손실을 최소화하는 것이 중요하고, 실시간 매칭 서비스는 복구 시간을 줄이는 것이 중요할 수 있다. 서비스의 특성에 따라 서로 다른 RPO와 RTO를 설정해야 한다.
백업과 복제의 차이
복제(Replication)는 데이터를 다른 시스템으로 전달해 가용성과 읽기 성능을 높이는 방식이다. 백업은 특정 시점의 데이터를 보존해 과거 상태로 복구할 수 있도록 하는 방식이다.
두 기능은 목적이 다르다.
데이터가 잘못 변경되거나 삭제되면 그 변경 사항이 복제 대상에도 전파될 수 있다. 따라서 복제만으로는 과거의 정상 데이터를 복구하지 못할 수 있다.
안정적인 복구 전략에는 백업, 복제, 버전 관리, 접근 제어, 복구 테스트가 함께 필요하다.
복구 절차 검증
백업은 실제로 복구할 수 있는지 확인해야 의미가 있다.
정기적인 복구 테스트를 통해 백업 데이터의 무결성, 복구 소요 시간, 서비스 재가동 절차, 데이터 정합성을 확인해야 한다.
특히 포인트나 아이템을 관리하는 게임 플랫폼에서는 복구 이후 중복 보상 지급이나 거래 내역 불일치가 발생하지 않는지 검증해야 한다.
운영 환경과 분리된 계정이나 저장소에 백업을 보관하고, 백업 데이터의 삭제 권한을 제한하면 운영 계정 침해로 인해 백업까지 손상되는 위험도 줄일 수 있다.
비용과 안정성의 균형
비용 최적화와 고가용성은 서로 반대되는 목표처럼 보일 수 있다. 하지만 실제 운영에서는 장애 비용과 서비스 중단에 따른 손실까지 포함해 판단해야 한다.
| 설계 방식 | 비용 측면 | 안정성 측면 |
|---|---|---|
| 단일 인스턴스 | 상대적으로 저렴 | 단일 장애점 존재 |
| 다중 인스턴스 | 컴퓨팅 비용 증가 | 서버 장애 대응 가능 |
| 다중 가용 영역 | 네트워크 및 리소스 비용 증가 가능 | 영역 단위 장애 대응 강화 |
| 자동 백업 | 저장 및 보존 비용 발생 | 데이터 복구 가능성 향상 |
| 대기 복구 환경 | 유지 비용 증가 | 짧은 복구 시간 달성에 유리 |
| 오토스케일링 | 부하에 따라 비용 변동 | 트래픽 급증 대응에 유리 |
모든 시스템에 가장 높은 수준의 고가용성을 적용하는 것이 정답은 아니다. 서비스의 중요도, 허용 가능한 중단 시간, 데이터 손실 범위, 운영 예산을 기준으로 적절한 수준을 결정해야 한다.
실무 적용 체크리스트
- CPU, 메모리, 네트워크, 데이터베이스의 사용량을 모니터링한다.
- 리소스 지표와 응답 지연 시간, 오류율을 함께 분석한다.
- 오토스케일링의 최소·최대 용량과 확장·축소 조건을 설정한다.
- 인스턴스 확장으로 데이터베이스에 과부하가 발생하지 않는지 확인한다.
- 여러 가용 영역에 애플리케이션을 분산한다.
- 서버와 데이터베이스의 장애 조치 절차를 검증한다.
- 중요 데이터별 백업 주기와 보존 기간을 정의한다.
- 서비스별 RPO와 RTO를 명확하게 설정한다.
- 운영 환경과 분리된 백업 보관 방식을 검토한다.
- 정기적으로 복구 테스트와 장애 대응 훈련을 수행한다.
- AWS 비용을 주기적으로 분석하고 사용하지 않는 리소스를 정리한다.