준비하는 프로젝트가 대용량 트래픽을 견뎌내는 것이 핵심 과제 중 하나다보니, 시스템 모니터링 환경을 구축하는 게 필요했고, 내가 맡게 됐다.
컴퓨터 공학을 하면서, 이를 통해 하나의 소프트 웨어를 만든다고 할 때, 하나의 선순환을 만들고 싶었다.
실험 → 진행상황 모니터링 → 문제 발견 및 진단 → 대응 실시 → 재실험 → 결과 모니터링 → ...... →
시스템의 상태를 실시간으로 파악함으로써 전체 시스템에서 문제가 되는 지점을 찾아내고, 문제의 원인을 밝혀낸다. 이는 대응방안의 근거가 될 것이며 이러한 과정이 곧 공학적 깊이를 더해줄 것이라 생각한다.
성공적인 product 운영은 단순히 기능을 만드는 것을 넘어, 시스템의 상태를 실시간으로 파악하고 문제의 징후를 조기에 발견하여 대처하는 능력에 달려있다. 이를 위해 시스템 메트릭
, 애플리케이션 메트릭
으로 층위로 나누어 시스템을 입체적으로 진단할 수 있다.
CPU 사용률
메모리 사용률
디스크 I/O (Input/Output)
네트워크 트래픽
지표 (Symptom) | 진단 (Diagnosis) | 조치 (Action) |
---|---|---|
CPU 사용률 90% 이상 지속 | 쿼리/코드의 계산 로직이 비효율적이거나, 처리 용량을 초과하는 요청이 유입되고 있다. | DB: 쿼리 튜닝, 인덱스 재설계 API 서버: 비효율적 루프 등 코드 개선 공통: EC2 인스턴스 사양 업그레이드 |
메모리 사용률 지속적 증가 | 애플리케이션 코드에 메모리 누수(Memory Leak)가 발생했을 가능성이 매우 높다. | API 서버: 코드 리뷰를 통해 메모리 해제 로직을 검토하고 버그 수정. |
디스크 읽기(Read) I/O 급증 | 메모리가 부족하여 필요한 데이터를 디스크에서 계속 읽어오는 '스왑(Swap)' 현상일 수 있다. 아니면 한번 사용된 데이터가 메모리에 머무르지 않아서 캐싱을 못하고 있을 수 있다. | DB/API 서버: EC2 인스턴스의 RAM 용량을 증설하여 메모리 캐싱 효율을 높인다. 혹은 인메모리 캐시 기법을 도입한다. |
네트워크 출력(Egress) 과다 | API 응답에 불필요하게 크거나 중복된 데이터가 포함되어 있다. | API 서버: 응답 데이터 포맷을 최적화하거나, Gzip 등 데이터 압축 적용을 검토한다. |
API 요청 수 (RPS, RPM)
에러율 (Error Rate, %)
쿼리 요청 수 (QPS)
응답 시간 (Latency, p95/p99)
지표 (Symptom) | 진단 (Diagnosis) | 조치 (Action) |
---|---|---|
특정 API의 RPS만 유독 높음 | 해당 기능이 사용자들에게 핵심 기능으로 자주 사용되고 있다. | 해당 API의 성능 최적화에 우선순위를 두고 리소스를 집중 투자하는 의사결정을 내린다. |
p99 응답 시간만 비정상적으로 높음 | 대부분의 요청은 빠르지만, 특정 사용자 그룹이나 복잡한 조건의 요청만 매우 느리게 처리되고 있다. | 분산 추적(Distributed Tracing) 도구를 활용해 느린 요청의 경로를 추적하고, '슬로우 쿼리(Slow Query)'를 찾아내 튜닝한다. |
약어 의미 간단 설명 p95 95번째 백분위수 (95th percentile) 측정값 중 상위 5%(느린 5%)를 제외한 지연 시간.
“전체 요청 중 95%는 이 시간 이내에 처리된다”는 의미.p99 99번째 백분위수 (99th percentile) 측정값 중 상위 1%(가장 느린 1%)를 제외한 지연 시간.
“99%의 요청이 이 시간 이내에 처리된다”는 의미.RPS Requests Per Second 초당 처리하는 HTTP/API 요청 수. QPS Queries Per Second 초당 처리하는 데이터베이스 쿼리(또는 기타 질의) 수.
이걸 데이터들을 어떻게 얻어내고 어떻게 보는지는 다음 포스팅에...
많이 배워갑니다