SOA-C03 05/16 — 스토리지·데이터베이스 성능
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 용량·IOPS·처리량·지연을 따로 읽는다
저장장치가 느리다는 말에는 여러 원인이 들어 있다. 데이터를 더 담을 공간이 없는지, 작은 요청을 처리하는 횟수가 부족한지, 큰 데이터를 옮길 대역폭이 부족한지 먼저 나눈다.
| 축 | 의미 | 예시 관측 |
|---|---|---|
| 용량 | 보관할 수 있는 데이터 양 | free space 감소 |
| IOPS | 초당 처리하는 I/O 횟수 | 작은 random I/O가 많음 |
| Throughput | 초당 전송하는 데이터 양 | 큰 sequential read가 많음 |
| Latency | 개별 작업이 끝날 때까지 시간 | 요청당 대기 증가 |
| Queue | 처리되지 않고 기다리는 작업 | 수요가 처리 속도보다 빠름 |
대략적인 관계는 throughput ≈ IOPS × 평균 I/O 크기다. 예를 들어 16 KiB 요청을 초당 3,000회 처리하면 약 46.9 MiB/s다. 이것은 단위 관계를 설명하는 계산이며 실제 서비스 성능 보장은 아니다. 같은 IOPS라도 I/O 크기와 병렬성에 따라 결과가 달라진다.
2. EBS 유형은 접근 패턴과 지속 성능에 맞춘다
| 유형 | 선택 중심 | 확인할 경계 |
|---|---|---|
| gp3 | 범용 SSD, 용량과 IOPS·throughput 조정 | volume 설정과 EC2 EBS 한도 |
| gp2 | 크기와 성능·burst 관계를 가진 범용 SSD | 작은 볼륨의 credit과 지속 부하 |
| io2 Block Express·io1 | 높은 지속 IOPS가 필요한 workload | 지원 instance, 지연 요구, 비용 |
| st1 | 큰 순차 처리 중심의 HDD | 작은 random I/O에는 부적합 |
| sc1 | 드물게 읽는 처리량 중심 HDD | 낮은 비용과 접근 지연의 절충 |
st1·sc1은 boot volume으로 쓰지 않는다. 작은 random I/O 중심과 큰 streaming 중심을 구분하는 것이 단순 최대 수치 암기보다 먼저다. 정확한 한도는 유형·환경별 공식 표로 확인한다. EBS volume types
진단에서는 VolumeReadOps·WriteOps, ReadBytes·WriteBytes, queue·latency와 instance의 EBS 처리 능력을 같은 시간에 본다. 볼륨만 상향했는데 개선되지 않으면 04에서 다룬 EC2 측 한도, 파일시스템, 애플리케이션 대기로 범위를 넓힌다.
용량 확장도 두 층이다. EBS 크기를 늘린 뒤 OS에서 partition·filesystem이 그 공간을 사용하도록 확장해야 할 수 있다. API 성공과 파일시스템 free space 증가를 별도로 확인한다.
3. S3의 전송 성능과 보관 정책
S3는 객체 단위 API 접근이다. 객체 크기·동시 요청 수·클라이언트 위치·재시도 패턴이 처리량을 좌우한다.
- 큰 객체는 multipart upload로 부분을 병렬 전송하고 실패한 부분만 재전송할 수 있다. 완료 요청 전에는 최종 객체 업로드가 끝난 것으로 보지 않는다. 중단한 multipart의 남은 부분은 정리한다. Multipart upload
- 클라이언트와 bucket 사이가 멀면 Transfer Acceleration을 후보로 두고 실제 전송 경로에서 비교한다. 가까운 경로까지 항상 더 빠르다고 가정하지 않는다. 동시 연결·byte-range read·재시도도 함께 고려한다. 성능 지침
- Lifecycle은 객체를 다른 storage class로 전환하거나 만료시키는 정책이다. 저장 비용뿐 아니라 조회 빈도·복원 대기·최소 보관 조건과 삭제 영향을 확인한다. 과거 버전 관리와 incomplete multipart 정리도 구분한다. Lifecycle
- DataSync는 저장소 간 데이터 이동을 관리한다. source·destination·task·검증 설정과 실행 결과를 확인하며, 네트워크·원천 저장소·목적지 처리 능력이 함께 전송 속도를 제한한다. DataSync
운영 예: 대량 업로드가 느리다면 원격 클라이언트의 업링크, 병렬성, 오류·재시도, 객체 크기를 먼저 본다. 저장 등급을 바꾸는 Lifecycle은 이 전송 경로 병목의 직접 해결책이 아니다.
4. 공유 파일 저장소는 프로토콜과 데이터 흐름으로 선택한다
| 서비스 | 중심 요구 | 운영 관찰 |
|---|---|---|
| EFS | Linux 계열 공유 NFS 접근 | mount·권한·처리량·접근 빈도 |
| FSx for Windows File Server | SMB·Windows 파일 기능·AD | 인증·share/파일 권한·throughput |
| FSx for Lustre | 병렬 데이터 처리·HPC | 클라이언트·병렬성·S3 import/export |
| S3 Files | S3 데이터를 공유 파일 연산으로 접근 | mount·동기화·활성 데이터·객체 경로 |
EFS Lifecycle은 접근 패턴에 따라 IA·Archive 등으로 이동시켜 저장 비용을 조정한다. 드문 접근으로 분류된 데이터를 다시 자주 읽기 시작하면 접근 비용과 성능을 함께 검토한다. EFS Lifecycle
FSx는 단일 파일시스템 제품이 아닌 제품군이다. Windows File Server는 SMB·AD 통합, Lustre는 병렬 처리·S3 연계라는 요구 차이를 먼저 본다. 다른 FSx 유형이 요구에 등장하면 해당 제품의 프로토콜·기능을 확인한다. Windows File Server, Lustre
S3 Files에서 파일 쓰기와 bucket 반영을 구분한다
S3 Files는 S3 bucket 또는 prefix와 연결된 공유 파일시스템이다. 활성 데이터의 고성능 저장 계층과 S3를 이용하고 파일 연산과 객체 사이의 동기화를 관리한다. NFS·파일 잠금·POSIX 권한을 제공하므로 단순히 객체 API에 경로 모양을 붙인 것과 다르다. S3 Files
파일 쪽 변경이 S3에 동기화되는 시점과 파일시스템 안에서 읽히는 시점을 구분한다. 같은 데이터를 bucket과 파일시스템에서 동시에 수정하면 충돌이 생길 수 있고, 문서의 충돌 처리 규칙을 적용해야 한다. 파일 저장 직후 별도 S3 소비자가 반드시 최신 데이터를 읽는다고 가정하지 않는다. 동기화
5. RDS 성능은 host 압력과 DB 내부 대기를 연결한다
CloudWatch는 CPU·메모리·저장 공간·연결 수 같은 서비스 지표를 보여 주고, Performance Insights API의 DB load는 active sessions를 SQL·wait·user·host 등으로 분해한다. CPU가 충분해도 lock wait가 높으면 인스턴스 크기보다 긴 transaction이나 경합을 조사한다. Performance Insights API
현재 운영 화면에는 시간에 따른 변경이 있다. AWS는 2026-07-31 이후 Performance Insights 콘솔을 CloudWatch Database Insights로 전환한다고 안내한다. Performance Insights API는 유지된다. 따라서 계획에 있는 DB load·wait·SQL 분석 범위는 유지하면서 현재 콘솔은 Database Insights로 찾아간다. 전환 안내
자동 proactive recommendation은 관찰된 metric·설정에서 조사 후보를 제시한다. 활성화·보존 모드 조건을 확인하고, 권고가 제시된 시간과 실제 SQL·wait를 대조한다. 권고 상태가 resolved라고 해서 사용자 영향까지 해소됐다고 대신 판단하지 않는다. RDS recommendations
6. RDS Proxy는 연결 압력을 다룬다
짧은 요청을 처리하는 애플리케이션이 연결을 매번 새로 만들면 DB가 연결 관리에 자원을 쓴다. RDS Proxy는 연결 pool과 재사용을 통해 이 부담을 줄이고 DB 연결 관리에 도움을 준다. 다만 긴 transaction이나 session 상태 때문에 연결이 pinning되면 공유 효과가 줄어들 수 있다. 느린 SQL의 실행 계획을 proxy가 자동으로 고치는 것은 아니다. RDS Proxy
Proxy 도입 후에는 client 연결과 backend DB 연결, borrow 대기, connection failure를 분리해서 본다. DB CPU가 계속 높다면 query·index·lock·I/O 가설로 돌아간다.
7. 완성된 운영 적용 — 웹 지연과 DB 연결 급증
- ALB·애플리케이션 지연 시작 시각을 DB connections·CPU·free memory와 맞춘다.
- trace에서 DB 연결 획득과 SQL 실행 중 어디가 느린지 구분한다.
- 연결 획득이 문제면 pool·동시성·RDS Proxy를 검토한다.
- DB load가 lock wait에 몰리면 transaction·blocking SQL을 조사한다.
- I/O wait가 높으면 쿼리 접근 패턴과 저장장치 IOPS·throughput을 본다.
- 수정 후 요청 지연·DB wait·연결 수를 다시 비교하고, 쓰기 정확성과 오류도 확인한다.
시험 범위는 저장 방식·성능 조정·관측 도구를 요구와 연결하는 것이다. 실제 운영의 변경은 복구 가능성과 데이터 검증을 포함하며, 백업·복원은 07에서 다룬다. 범위: Domain 1.
계획과 연결
-
ID:
05-storage-database-performance -
의존:
02-collection-alarms-dashboards-notifications -
결정 축: 지연·IOPS·처리량·용량·접근 패턴·연결 압력을 올바른 스토리지와 데이터베이스 제어면에 배치한다.
-
범위: EBS metrics·volume types, S3 multipart upload·Transfer Acceleration·Lifecycle, DataSync, EFS, FSx, S3 Files, RDS Performance Insights·CloudWatch alarms·proactive recommendations·RDS Proxy.
-
시험 매핑: Domain 1, Skills 1.3.2–1.3.5.