SOA-C03 04/16 — 컴퓨트 성능과 리소스 최적화
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 느리다는 증상을 자원별 압력으로 나눈다
SAA에서 인스턴스 유형을 요구사항에 맞춰 골랐다면, SOA에서는 운영 중 측정한 신호로 그 선택을 다시 검증한다. CPU가 낮아도 디스크 대기나 네트워크 제한 때문에 요청이 느릴 수 있다.
사용자 지연·오류 확인
→ 같은 시간의 CPU·메모리·I/O·네트워크 관찰
→ 어느 자원의 수요가 처리 능력을 넘는지 가설 구성
→ 코드·설정·인스턴스·배치 중 개입 지점 선택
→ 대표 부하로 변경 전후 비교| 관측 | 우선 확인할 가설 | 추가 증거 |
|---|---|---|
| CPU 사용률이 지속적으로 높다 | 계산량 증가, 실행 반복, 병렬 처리 포화 | 프로세스별 CPU, 요청량, 배포 시각 |
| 메모리 부족·swap·OOM | working set 증가, 누수, 과도한 동시성 | agent 지표, OOM 로그, 프로세스 메모리 |
| CPU는 낮고 작업이 대기한다 | 저장장치·DB·네트워크 대기 | I/O latency·queue, DB waits, trace |
| 짧은 네트워크 손실 | bandwidth·PPS·connection allowance | ENA 지표, 패킷 수, 연결 수 |
| 특정 노드만 느리다 | 부하 편중, 유형·설정 차이 | 노드별 차원, tag, 배포·이미지 버전 |
CPU 평균을 fleet 전체로 합치면 일부 노드의 포화를 감출 수 있다. 먼저 사용자 영향의 시간과 대상 instance ID를 맞춘다. 메모리·파일시스템 내부 신호는 02에서 다룬 수집 설정이 있어야 보인다.
2. Burstable의 기준선과 credit을 읽는다
Burstable 인스턴스는 기준선 이하에서 CPU credit을 모으고 그 이상에서 소비한다. CPU credit 한 단위는 vCPU 하나를 100%로 1분 사용하는 양이다. Standard와 Unlimited는 credit 소진 이후의 성능·비용 관계가 다르다.
- Standard에서는 사용 가능한 credit과 baseline을 함께 보며 지속 부하의 제약을 판단한다.
- Unlimited에서는 surplus credit 사용과 과금 조건을 함께 확인한다.
- 짧은 부하 시험에서 빠르다는 결과만으로 장시간 부하에 적합하다고 결론 내리지 않는다.
- CPUUtilization에 CPUCreditBalance·사용량·surplus 관련 지표를 붙여 시간 흐름을 본다.
일정 시각의 배치가 반복적으로 느려진다면 시작 직후와 수십 분 후를 비교한다. credit 소진과 지연 증가가 겹치는지, 코드의 입력 크기가 바뀌었는지 확인한 뒤 지속 성능 인스턴스로의 변경을 검토한다. Burstable 개념
3. 네트워크 성능은 Gbps 하나로 끝나지 않는다
인스턴스의 표시 bandwidth에는 baseline과 burst, 단일 flow와 여러 flow, 목적지 경로에 따른 조건이 있다. PPS와 추적 연결 수 같은 allowance를 먼저 넘을 수도 있다.
CloudWatch의 NetworkIn·NetworkOut은 전송량을 보여 주지만 짧은 microburst를 평균 속에서 놓칠 수 있다. ENA의 allowance 초과 지표를 함께 보면 전송량이 낮아 보이는 동안 발생한 제한을 찾는 데 도움이 된다. 작은 패킷이 많은 workload는 바이트 처리량보다 PPS가 먼저 병목이 될 수 있다. EC2 network bandwidth
운영 질문을 세 단계로 나눈다.
- 수요: 동시에 몇 연결이 얼마나 큰 패킷을 보내는가?
- 능력: 이 유형·크기·드라이버·경로에서 허용하는 성능은 무엇인가?
- 실제: 손실·재전송·지연과 allowance 초과가 같은 시간에 나타나는가?
인스턴스를 크게 바꾸기 전에 애플리케이션 connection reuse, 전송 병렬성, 경로와 수신 측 제한도 확인한다.
4. EBS 성능은 볼륨과 EC2 양쪽에서 제한된다
EBS volume의 IOPS·throughput을 높여도 연결된 EC2의 EBS 처리 능력이 더 작으면 그 지점에서 제한된다. 여러 볼륨의 부하가 인스턴스 측 한도에 합쳐지는지도 본다. EBS-optimized는 스토리지 I/O를 위한 성능 경계를 제공하지만 모든 유형에서 같은 수치를 보장하지 않는다. EBS-optimized 인스턴스
따라서 변경 후보를 이렇게 나눈다.
- 볼륨의 provisioned IOPS가 포화: volume 설정·유형과 I/O 패턴 확인.
- 인스턴스의 EBS bandwidth가 포화: instance 유형·크기 검토.
- 파일시스템이 가득 참: 용량·정리·확장 문제로 다룸.
- DB lock 때문에 대기: storage 상향 전에 DB 원인 확인.
구체적인 볼륨 선택과 데이터베이스 진단은 05에서 이어진다.
5. Placement group은 통신과 장애 동시성의 선택이다
| 전략 | 배치 의도 | 운영 판단 |
|---|---|---|
| Cluster | 한 AZ 안에서 인스턴스를 가깝게 배치 | 긴밀한 노드 간 통신·낮은 지연 |
| Partition | partition 사이의 기반 하드웨어를 분리 | 복제형 분산 시스템에서 장애 영향을 partition 단위로 설계 |
| Spread | 소수 인스턴스를 서로 다른 하드웨어에 분산 | 중요한 노드들의 동시 장애 가능성을 줄임 |
| Precision time | 정밀 시간원에 직접 접근하는 지원 하드웨어 사용 | 정밀 시각 요구가 명시된 workload에서 검토 |
현재 문서에는 Precision time도 포함된다. 기존 계획의 placement groups 범위 안에서 구분하되, 핵심 통신·장애 배치 판단은 앞의 세 전략으로 설명한다. Cluster를 선택했다고 다중 AZ 복원력이 만들어지지 않는다. Partition도 애플리케이션의 복제 배치를 자동으로 설계해 주지는 않는다. Placement groups
6. Tag와 Compute Optimizer를 판단 자료로 사용한다
Tag는 Environment·Service·Owner 같은 맥락을 리소스에 붙여 비교·비용 배분·작업 대상을 정하는 데 쓴다. tag가 없는 리소스나 잘못 붙은 리소스를 자동 조치 대상에 섞지 않도록 값과 대상 집합을 검증한다. 이름표가 실제 역할이나 접근 권한 자체를 보장하지 않는다. EC2 tags
Compute Optimizer는 관찰 기간의 사용량과 사양을 바탕으로 추천과 이유·예상 위험·비용 차이를 제시한다. 메모리 분석에는 필요한 지표 수집 조건이 있다. 추천 유형이 Arm 기반이면 이미지·바이너리·라이브러리 호환성을 확인하고, network·storage interface 차이도 본다. EC2 추천
추천을 적용하기 전에 관찰 창이 평상시뿐인지, 월말 배치나 행사 부하를 포함하는지 묻는다. 비용 감소 예상은 변경 후 실제 청구나 서비스 성능의 증거가 아니다. 대표 트래픽에서 요청 성공률·지연·자원 압력·비용을 비교한다.
7. 완성된 운영 적용 — 배치가 일정 시간 후 느려짐
가정: 같은 입력을 처리하는 배치가 시작 직후에는 빠르지만 이후 처리량이 줄어든다. 이 사례는 설명용이며 실환경 측정 결과가 아니다.
- 처리량 저하 시각과 CPU·credit·I/O·network 신호를 정렬한다.
- CPU credit 고갈이 겹친다면 Standard/Unlimited 설정과 baseline을 확인한다.
- I/O queue만 증가한다면 EBS volume과 EC2 한도를 각각 확인한다.
- Network allowance만 증가하면 PPS·flow·목적지 경로를 확인한다.
- 확인한 병목에 맞는 유형·설정 하나를 바꾸고 같은 입력으로 비교한다.
- 완료 시간 개선과 함께 오류·비용·다른 자원의 새 병목을 확인한다.
한 번에 여러 축을 바꾸면 빨라져도 어떤 조치가 효과를 냈는지 알기 어렵다. 운영상 가능한 범위에서 가설별로 변경하고 관찰 근거를 남긴다.
8. 연결 요약
- 낮은 CPU는 자원 전체의 여유를 뜻하지 않는다.
- credit·baseline·burst와 지속 성능을 구분한다.
- 네트워크는 bandwidth·PPS·flow·연결 한도를 함께 본다.
- EBS는 볼륨 성능과 인스턴스 측 성능 중 더 좁은 경계에 주목한다.
- 추천은 후보이며 변경 후 검증이 최종 판단을 만든다.
시험에서는 지표와 요구사항에 맞는 최적화 수단을 선택한다. 실제 운영에서는 대표 부하·호환성·변경 영향까지 검증한다. 범위: Domain 1.
계획과 연결
-
ID:
04-compute-performance-and-resource-optimization -
의존:
02-collection-alarms-dashboards-notifications -
결정 축: 부하·용량·배치·인스턴스·네트워크 신호를 구분하고 성능 요구와 비용을 함께 맞춘다.
-
범위: EC2 성능 지표, resource tags, placement groups, 인스턴스·네트워크 성능, AWS Compute Optimizer와 관련 운영 도구.
-
시험 매핑: Domain 1, Skills 1.3.1, 1.3.6.