DB 성능 저하? 스토리지 IOPS 한계 돌파가 해답

IT 시스템을 운영하며 가장 두려운 순간은 무엇일까요? 저는 단연코 예측 불가능한 서비스 장애라고 생각합니다. 특히 사용자가 직접 체감하는 서비스 지연이나 먹통 현상은 비즈니스에 치명적인 타격을 줄 수 있죠. 그리고 종종 이런 재앙의 뒤에는 눈에 잘 띄지 않는 '숨겨진 주범'이 있습니다. 바로 스토리지 레이턴시(Storage Latency)입니다.

오늘은 제가 직접 겪었던, 그리고 많은 IT 담당자들이 한 번쯤은 겪게 될 스토리지 레이턴시 급증으로 인한 DB 성능 마비 사례와 그 해결 과정을 상세히 공유해 드리고자 합니다.

어느 날 갑자기, 서비스가 멈춰 섰습니다

저는 잊을 수 없는 경험이 있습니다. 여느 때와 다름없이 평화로운 오후, 갑자기 모니터링 시스템의 경고음이 울리기 시작했습니다. 처음에는 일부 사용자로부터 "웹 서비스가 느리다"는 문의가 들어오기 시작하더니, 이내 걷잡을 수 없이 확산되었습니다. 웹 서비스 응답 속도는 10초 이상 지연되었고, 급기야 사용자들의 결제 및 조회 기능이 완전히 마비되는 초유의 사태가 발생했습니다.

저희 팀은 비상 체제로 돌입했습니다. 가장 먼저 눈에 들어온 것은 DB 서버의 CPU 사용률 그래프였습니다. CPU가 쉴 새 없이 일하고 있는데, 정작 시스템은 느려터진 아이러니한 상황. 자세히 들여다보니 CPU는 연산 작업이 아닌, 'iowait' 상태에서 무려 60% 이상의 시간을 보내고 있었습니다. 즉, CPU가 디스크 I/O 작업(데이터 읽기/쓰기)을 기다리느라 아무것도 하지 못하고 있다는 뜻이었죠.

뒤이어 애플리케이션 로그에서는 Connection Pool Exceeded 에러가 폭포수처럼 쏟아졌고, 데이터베이스에서는 SQL Transient Connection Exception 메시지가 끊임없이 발생했습니다. DB가 요청을 처리하지 못해 커넥션 풀이 고갈되고, 결국 모든 서비스 요청이 실패하는 전형적인 마비 증상이었죠. 이 모든 것이 불과 몇십 분 만에 벌어진 일이었습니다. 서비스 장애는 곧바로 비즈니스 손실로 이어지는 상황이라, 정말 발등에 불이 떨어진 심정이었습니다.

범인을 찾아라! 스토리지 레이턴시의 실체

iowait 수치가 높다는 것은 명백히 디스크 I/O 병목 현상을 의미했습니다. 저희 팀은 즉시 서버에 접속하여 원인 분석에 착수했습니다.

가장 먼저 `top`, `vmstat` 명령어로 CPU의 디스크 대기 시간을 재차 확인했습니다. 역시나 `iowait`는 여전히 높았고, 이는 스토리지 I/O가 느려지고 있음을 강력하게 시사했습니다. 다음으로 `iostat -x 1` 명령어를 통해 각 디스크 볼륨의 상세 I/O 통계를 살펴보았습니다. 그리고 충격적인 수치를 발견했습니다.

• 특정 스토리지 볼륨의 await (평균 I/O 대기 시간) 값이 100ms를 훌쩍 넘었으며, 때로는 수백 ms에 달했습니다. (정상적인 시스템에서는 10ms 이하를 유지해야 합니다.)
• 동시에 해당 볼륨의 util (사용률) 값은 100%에 근접해 있었습니다.

이 수치들은 해당 스토리지 볼륨이 완전히 포화 상태이며, 들어오는 I/O 요청을 제때 처리하지 못하고 심각하게 지연시키고 있다는 명백한 증거였습니다. 마치 고속도로의 모든 차선이 꽉 막혀버린 것과 같았죠.

정확한 원인을 파고들자 몇 가지 주요 요인들이 밝혀졌습니다.

원인 1: 스토리지 IOPS 한계치 도달

저희 DB에 연결된 스토리지(온프레미스 환경의 SAN/NAS 또는 클라우드 환경의 EBS 같은 블록 스토리지)가 처리할 수 있는 초당 I/O 작업(IOPS, Input/Output Operations Per Second)의 물리적 한계에 도달한 것이었습니다. 서비스가 성장하면서 DB에 가해지는 트래픽과 I/O 요청은 기하급수적으로 늘어났지만, 스토리지 자체의 성능은 이를 따라가지 못하고 있었던 겁니다. 마치 좁은 병목 현상처럼, 아무리 많은 요청이 들어와도 정해진 양만 처리할 수밖에 없는 상황이었죠.

원인 2: Noisy Neighbor (소란스러운 이웃) 현상

가장 황당했지만 흔히 발생하는 원인 중 하나는 바로 '소란스러운 이웃'이었습니다. 동일한 스토리지 인프라를 공유하는 다른 서버에서 대규모 백업 작업이나 배치(Batch) 작업이 돌고 있었던 겁니다. 이 작업들이 스토리지의 대역폭과 IOPS를 독점하면서, 정작 중요한 DB 서비스는 제대로 된 자원을 할당받지 못하고 있었습니다. 핵심 서비스가 '착한 이웃'의 희생양이 된 셈이죠.

원인 3: 클라우드 스토리지의 쓰로틀링 (Throttling)

만약 클라우드 환경을 사용한다면, 처음 설정했던 스토리지 볼륨 대비 낮은 IOPS 설정이 발목을 잡을 수 있습니다. 서비스 규모가 커지면서 필요한 IOPS는 급증했는데, 스토리지 볼륨의 성능 티어가 낮게 설정되어 있어 클라우드 제공업체에서 강제로 성능을 제한(Throttling)하는 상황이 발생한 것입니다. 클라우드는 유연하지만, 자원 할당에 대한 이해 없이는 오히려 성능 저하를 겪을 수 있습니다.

물론, 이 모든 상황 속에서 실행 시간이 긴 쿼리들이 제대로 인덱스를 사용하고 있었는지, 과도한 물리적 읽기를 유발하고 있지는 않았는지도 함께 대조 분석했습니다. 스토리지 문제가 가장 컸지만, 비효율적인 쿼리도 I/O 부하를 가중시킬 수 있는 요인이기에 항상 함께 점검해야 합니다.

긴급 조치와 근본 해결: 재앙을 넘어서는 방법

원인을 파악했으니 이제 해결해야 합니다. 긴급 상황에서는 '일단 불을 끄는 것'이 최우선이고, 이후에 '재발 방지'를 위한 근본적인 해결책을 마련해야 합니다.

긴급 조치: 일단 숨통을 트이게 하라!

• 스토리지 과점 비핵심 작업 즉시 중단: 저희의 경우, 대규모 데이터 이관 배치 작업을 급하게 중단시켰습니다. 스토리지 자원을 독점하던 '소란스러운 이웃'을 일단 잠재우는 것이 급선무였습니다.
• 클라우드 스토리지 IOPS 상위 등급으로 즉시 업그레이드: 클라우드 환경이었다면, 비용을 잠시 뒤로하고라도 스토리지의 IOPS 성능 등급을 최상위 티어로 긴급하게 업그레이드했을 것입니다. 서비스 정상화가 가장 중요하기 때문입니다.

이러한 긴급 조치로 서비스는 점차 정상화되기 시작했습니다. 하지만 이는 어디까지나 임시방편일 뿐, 다시 유사한 문제가 발생할 여지가 있었습니다. 이제는 재발 방지를 위한 근본적인 해결책을 마련해야 했습니다.

근본 해결: 다시는 겪지 않기 위해

• DB 튜닝 (버퍼 풀 확장, 인덱스 최적화): 가장 먼저 데이터베이스 자체의 성능을 최적화했습니다. 버퍼 풀(Buffer Pool)을 확장하여 디스크 I/O를 최대한 줄이고, 문제가 되었던 쿼리들의 실행 계획을 분석하여 인덱스를 최적화하거나 새로 생성했습니다. 효율적인 인덱스는 불필요한 디스크 읽기를 극적으로 줄여줍니다.
• DB 전용 스토리지로 자원 분리: '소란스러운 이웃' 현상의 재발을 방지하기 위해, 핵심 DB 서비스에는 다른 용도의 서버나 작업과 완전히 분리된 전용 스토리지 자원을 할당했습니다. 물리적으로든 논리적으로든 DB I/O가 다른 작업에 의해 방해받지 않도록 보장하는 것이 중요합니다.

재발 방지: 사전 예방이 최고의 무기

재앙을 겪고 나면 가장 중요한 것은 '학습'입니다. 다시는 이런 일을 겪지 않기 위한 시스템과 프로세스를 구축해야 합니다.

• 대규모 배치 작업 피크 타임 회피 및 분산 실행: 대규모 배치 작업은 서비스 피크 타임을 피해 심야 시간대나 시스템 부하가 적은 시간에 실행하도록 스케줄을 조정했습니다. 또한, 작업을 한 번에 몰아서 하지 않고 작은 단위로 쪼개 분산 실행하는 방식으로 스토리지에 가해지는 부하를 줄였습니다. 이는 스토리지뿐만 아니라 DB 서버의 부하를 분산하는 데도 효과적입니다.
• 스토리지 레이턴시 및 IOPS 사용률 임계치 알람 설정: 가장 중요한 재발 방지책 중 하나는 '사전 감지'입니다. 스토리지의 레이턴시(응답 시간)와 IOPS 사용률에 임계치(Threshold)를 설정하고, 이 수치를 넘어서면 담당자에게 즉시 알람이 오도록 모니터링 시스템을 고도화했습니다. 덕분에 이제는 문제가 심각해져 서비스 장애로 이어지기 전에 미리 이상 징후를 감지하고 선제적으로 대응할 수 있는 체계를 갖추게 되었습니다.

FAQ: 스토리지 장애, 더 궁금한 점은?

Q: iowait 급증이 항상 스토리지 문제인가요?

A: 대부분의 경우 스토리지 I/O 병목 현상의 주요 지표입니다. CPU가 디스크에서 데이터를 읽거나 쓰는 것을 기다리느라 유휴 상태에 빠져있다는 뜻이니까요. 하지만 드물게는 네트워크 파일 시스템(NFS)의 문제나 특정 드라이버/커널 버그로 인해 발생하기도 합니다. 그럼에도 불구하고 가장 먼저 스토리지 성능을 의심하고 iostat 같은 도구로 디스크별 상세 통계를 확인하는 것이 문제 해결의 첫걸음입니다.

Q: Noisy Neighbor 현상은 어떻게 예방하나요?

A: 가장 확실한 방법은 핵심 서비스에 필요한 자원(스토리지, 네트워크, CPU 등)을 다른 비핵심 작업과 물리적/논리적으로 완전히 분리하는 것입니다. 클라우드 환경에서는 전용 볼륨을 사용하거나, 온프레미스에서는 물리적으로 다른 스토리지 어레이를 할당하는 방식이 있습니다. 또한, 자원 사용량이 많은 배치 작업은 서비스 피크 시간을 피해 실행하고, 리소스 제한(예: Linux cgroup)을 설정하여 다른 서비스에 영향을 주지 않도록 관리할 수 있습니다.

Q: 클라우드 스토리지 IOPS 설정 시 고려할 점은?

A: 클라우드 스토리지의 IOPS는 주로 볼륨 크기(용량)에 비례하거나, 별도의 프로비저닝된 IOPS 옵션으로 설정됩니다. 초기에는 최소한의 비용으로 시작하더라도, 서비스의 트래픽 패턴과 DB 워크로드를 정확히 분석하여 필요한 최소 IOPS를 산정하는 것이 중요합니다. 주기적인 모니터링을 통해 IOPS 사용량을 추적하고, 예상 사용량의 70~80% 정도를 임계치로 설정하여 선제적으로 등급을 조정할 수 있는 계획을 세워두어야 합니다. 무엇보다 성능이 비즈니스 크리티컬한 부분에서는 비용 효율성만 따지지 말고 과감한 투자가 필요합니다.

스토리지 레이턴시 문제는 한 번 발생하면 서비스 전체를 마비시킬 수 있는 치명적인 장애입니다. 하지만 충분한 이해와 체계적인 관리, 그리고 선제적인 모니터링을 통해 충분히 예방하고 대응할 수 있습니다. 오늘 공유해 드린 경험과 노하우가 여러분의 안정적인 IT 서비스 운영에 조금이나마 도움이 되기를 바랍니다. 다음에도 더 유익한 IT 이야기로 찾아뵙겠습니다!