AWS에서 성능 문제를 해결하는 것은 자동차 정비사의 일과 비슷합니다. 자동차가 느려졌다면 엔진인지, 타이어인지, 연료인지 원인을 찾아야 합니다. AWS에서도 서버가 느려졌을 때 CPU인지, 메모리인지, 저장 장치인지, 네트워크인지 하나씩 확인해야 합니다. 이 포스트에서는 그 진단 도구들을 배웁니다.
EC2 인스턴스 유형 — 올바른 도구 선택
EC2 인스턴스는 용도에 따라 여러 종류가 있습니다. 요리를 예로 들면, 빵 굽는 오븐과 국 끓이는 냄비가 다르듯이 작업에 맞는 인스턴스를 골라야 합니다.
| 유형 | 대표 이름 | 특징 | 어떤 작업에? | |------|---------|------|-----------| | 범용 | M 시리즈, T 시리즈 | CPU와 메모리 균형 | 웹 서버, 소규모 데이터베이스 | | 컴퓨팅 최적화 | C 시리즈 | CPU 성능이 특히 높음 | 배치 처리, 과학 계산, 게임 서버 | | 메모리 최적화 | R 시리즈, X 시리즈 | 메모리(RAM)가 매우 큼 | 인메모리 데이터베이스, 대용량 캐시 | | 스토리지 최적화 | I 시리즈, D 시리즈 | 디스크 읽기/쓰기 속도가 빠름 | 데이터 웨어하우스, 분산 파일 시스템 |
T 인스턴스의 크레딧 시스템
T 시리즈(T3, T4g 등)는 특별한 방식으로 동작합니다. 평소에 CPU를 조금 쓸 때 "크레딧"을 쌓아두고, CPU가 많이 필요할 때 그 크레딧으로 성능을 올립니다. 마치 은행 통장처럼, 평소에 저축했다가 필요할 때 인출하는 방식입니다.
크레딧이 모두 소진되면 CPU 성능이 기본 수준(예: t3.micro라면 약 10%)으로 제한됩니다. 이때 서버가 갑자기 느려질 수 있습니다.
Unlimited 모드를 활성화하면 크레딧이 없어도 계속 높은 CPU를 사용할 수 있지만, 초과 사용한 만큼 추가 요금이 붙습니다.
시험 팁: "EC2가 갑자기 느려졌다, T 인스턴스를 사용 중"이라는 문제가 나오면 CPU 크레딧 소진을 먼저 의심하세요.
배치 그룹(Placement Groups) — 서버들을 어디에 놓을까
인스턴스들을 물리적으로 어디에 배치할지 결정하는 설정입니다.
클러스터 배치 그룹: 인스턴스들을 같은 가용 영역(AZ) 안에서 서로 가까운 물리적 위치에 배치합니다. 서버 간 통신 속도가 매우 빨라집니다. 머신러닝 학습이나 고성능 컴퓨팅(HPC)처럼 서버들이 서로 엄청난 양의 데이터를 빠르게 주고받아야 할 때 사용합니다. 단점은 한 AZ에 몰려 있으므로 그 AZ에 장애가 나면 전체가 영향을 받습니다.
분산 배치 그룹: 인스턴스들을 서로 다른 물리적 하드웨어에 분산시킵니다. 하나의 하드웨어가 고장나도 다른 인스턴스는 살아남습니다. 핵심 서버를 고가용성으로 운영할 때 적합합니다.
파티션 배치 그룹: 인스턴스들을 "파티션"이라는 그룹으로 나누고, 각 파티션은 서로 다른 하드웨어 랙에 위치합니다. HDFS(하둡)나 Cassandra 같은 대규모 분산 데이터베이스 시스템에 적합합니다.
EBS 볼륨 유형 — 저장 장치도 종류가 중요합니다
EBS(Elastic Block Store)는 EC2에 연결하는 하드디스크 같은 것입니다. 사무실 컴퓨터에 연결하는 외장 하드처럼 생각하면 됩니다. 볼륨 유형마다 속도와 가격이 다릅니다.
| 볼륨 유형 | 최대 IOPS | 최대 처리량 | 특징 | 용도 | |---------|---------|----------|------|------| | gp3 | 16,000 | 1,000 MB/s | IOPS와 처리량을 볼륨 크기와 별개로 설정 | 대부분의 범용 작업 | | io2 Block Express | 256,000 | 4,000 MB/s | 최고 성능, Multi-Attach 가능 | 미션 크리티컬 DB | | st1 | N/A | 500 MB/s | 순차 읽기에 최적화, 저렴 | 빅데이터, 로그 처리 | | sc1 | N/A | 250 MB/s | 가장 저렴, 자주 접근 안 하는 데이터 | 아카이브, 백업 |
IOPS는 초당 입출력 작업 수입니다. 데이터베이스처럼 작은 데이터를 빠르게 많이 읽고 쓰는 작업에서 중요합니다. 처리량(Throughput)은 초당 전송할 수 있는 데이터 용량입니다. 동영상 스트리밍이나 대용량 파일 처리처럼 큰 파일을 연속으로 읽는 작업에서 중요합니다.
gp3의 핵심 포인트: gp2는 볼륨 크기가 커질수록 IOPS도 자동으로 늘어났지만, gp3는 볼륨 크기와 상관없이 IOPS를 원하는 값으로 직접 설정할 수 있습니다. 비용을 더 효율적으로 관리할 수 있습니다.
RDS Performance Insights — 데이터베이스의 건강검진 리포트
온라인 쇼핑몰을 운영한다고 상상해보세요. 주문 처리가 갑자기 느려졌습니다. 원인이 네트워크인지, 서버인지, 데이터베이스 쿼리인지 알아야 합니다. RDS Performance Insights는 데이터베이스 내부에서 무슨 일이 일어나는지 시각적으로 보여주는 도구입니다.
주요 기능:
가장 많은 부하를 주는 SQL 쿼리를 순위별로 보여줍니다. "이 쿼리가 전체 DB 부하의 40%를 차지하고 있다"는 식입니다.
대기 이벤트를 보여줍니다. 쿼리가 기다리는 이유가 CPU 부족인지, 디스크 I/O 때문인지, 다른 쿼리의 잠금(Lock) 때문인지 파악할 수 있습니다.
DB 로드 그래프로 데이터베이스가 얼마나 바쁜지 시각적으로 확인합니다. vCPU 수 대비 부하를 보여주므로, 인스턴스 크기를 늘려야 할지 판단할 수 있습니다.
Enhanced Monitoring과의 차이: RDS Performance Insights는 DB 엔진 내부(쿼리, 대기 이벤트)를 분석합니다. Enhanced Monitoring은 RDS가 돌아가는 서버 자체의 OS 수준 지표(CPU, 메모리, 프로세스)를 수집합니다. 두 도구는 서로 보완적입니다.
S3 Transfer Acceleration — 멀리 있어도 빠르게 업로드
서울에 있는 팀이 미국 S3 버킷에 대용량 동영상을 업로드해야 한다고 가정해봅시다. 일반 인터넷으로 직접 업로드하면 중간에 거치는 네트워크 홉이 많아서 느립니다.
S3 Transfer Acceleration은 이 문제를 해결합니다. 가장 가까운 CloudFront 엣지 로케이션(서울에도 있음)까지 업로드하면, 거기서부터 AWS 전용 고속 백본 네트워크를 통해 미국 S3 버킷까지 데이터가 전달됩니다. 일반 인터넷보다 훨씬 안정적이고 빠릅니다.
사용 방법: 버킷 엔드포인트를 으로 변경하면 됩니다. 멀티파트 업로드와 함께 사용하면 더욱 효과적입니다.
주의: 가까운 거리에서는 오히려 느려질 수 있습니다. 대륙 간 전송처럼 장거리일 때 효과가 있습니다.
EFS 성능 모드 — 공유 파일 시스템의 속도 조절
EFS(Elastic File System)는 여러 EC2 인스턴스가 동시에 접근할 수 있는 공유 폴더입니다. 회사 내 공유 네트워크 드라이브와 비슷합니다.
성능 모드는 두 가지입니다. 범용(General Purpose) 모드는 응답 시간이 짧아서 웹 서버나 CMS(콘텐츠 관리 시스템)처럼 빠른 응답이 필요한 곳에 적합합니다. Max I/O 모드는 처리량이 높은 대신 응답 시간이 약간 더 깁니다. 수천 개의 인스턴스가 동시에 접근하는 빅데이터나 미디어 처리 작업에 적합합니다.
처리량 모드도 세 가지가 있습니다. Bursting은 파일 시스템 크기에 비례해서 처리량이 늘어납니다. Provisioned는 파일 시스템 크기와 관계없이 원하는 처리량을 직접 지정합니다. Elastic은 실제 사용량에 따라 자동으로 조절됩니다.
CloudTrail — 누가 무엇을 했는지 기록
CloudTrail은 AWS 계정에서 일어나는 모든 API 호출을 기록하는 감사 로그입니다. 회사 건물의 출입 기록 시스템과 같습니다. 누가 언제 어떤 문을 열었는지 모두 기록합니다.
보안 사고가 발생했을 때 "누가 이 S3 버킷을 공개로 바꿨는가?", "언제 이 IAM 사용자가 만들어졌는가?" 같은 질문에 답할 수 있습니다.
이벤트 종류:
관리 이벤트는 인프라에 대한 작업입니다. EC2 인스턴스 시작, IAM 역할 생성, S3 버킷 생성 등이 여기에 해당합니다. 기본으로 수집됩니다.
데이터 이벤트는 리소스 안에 있는 데이터에 대한 작업입니다. S3 객체 읽기/쓰기, Lambda 함수 호출 등입니다. 기본으로 수집되지 않으며 추가 비용이 있습니다.
Insights 이벤트는 비정상적인 API 호출 패턴을 자동으로 탐지합니다. 예를 들어 갑자기 IAM 역할 생성 API 호출이 폭증하면 보안 위협 가능성을 알려줍니다.
CloudTrail Lake: SQL을 사용해서 CloudTrail 이벤트를 직접 쿼리할 수 있는 기능입니다. 과거 이벤트를 분석하거나 규정 준수를 확인할 때 유용합니다.
Systems Manager Automation — 반복 작업을 자동화
서버가 이상하게 동작할 때마다 수동으로 접속해서 재시작하는 것은 비효율적입니다. Systems Manager(SSM) Automation을 사용하면 이런 반복적인 운영 작업을 자동화할 수 있습니다.
런북(Runbook)은 "이 상황에서는 이렇게 해라"를 단계별로 정의한 문서입니다. 예를 들어 "EC2 인스턴스 재시작 런북"은 1단계 알림 발송, 2단계 인스턴스 중지, 3단계 인스턴스 시작, 4단계 상태 확인을 자동으로 수행합니다.
자주 쓰이는 패턴: CloudWatch 경보가 발동되면 EventBridge가 이를 감지하고 SSM Automation 런북을 실행합니다. 사람이 개입하지 않아도 서버가 자동으로 복구됩니다.
AWS가 기본으로 제공하는 런북도 있습니다. AWS-RestartEC2Instance(인스턴스 재시작), AWS-StopEC2Instance(인스턴스 중지) 등을 바로 사용할 수 있습니다.
시험 핵심 정리
"T 인스턴스가 갑자기 느려짐" -- CPU 크레딧 소진 확인, Unlimited 모드 활성화 또는 인스턴스 유형 변경
"서버 간 네트워크 지연 시간을 최소화" -- 클러스터 배치 그룹
"하드웨어 장애 격리, 고가용성 인스턴스" -- 분산 배치 그룹