안녕하세요,
최근 저의 URL단축서비스가 굉장히 느려지는 현상이 있었습니다. 처음 설계할 당시에는 느리지 않았는데 무슨 이유인지 갑작스럽게 느려져서 원인을 파악하고 있었습니다. 이럴땐 서비스를 정지하고 원인을 찾으면 좀 쉬울텐데 24시간 작동해야 하는 서비스 특성상 쉽지 않았습니다 (테이블에 담긴 120-130만건 정도 되는 데이터가 문제인가 싶었습니다)
새롭게 INSERT하는 것이 매우 느렸고, SELECT와 UPDATE는 그나마 쓸만할 정도였습니다(새로운 링크 생성까지 약 5-6초 정도 지연 발생). 이렇게 느려터진 서비스를 계속 놔두면 사용자가 빠져나가니 원인을 한번 파악해봅시다.
사실 몇 주 전부터 데이터베이스 쓰기에 약간의 속도 문제가 있었습니다. 그리고 EBS의 Burst도 너무 빨리 소진되는 문제가 있었지요.
24시간동안 발생하는 EBS 읽기 바이트 지표. 사용자가 거의 없는 한가한 시간에도 평균적으로 1-2GB씩 읽기가 발생합니다(UTC 기준입니다)
EBS Burst Balance (피크시간대가 되면 첨벙거립니다)
문제에 대한 접근
처음에는 PHP-FPM의 문제거나 EC2 인스턴스가 성능이 좋지 않아서 발생하는 문제인 줄 알고 접근했습니다.
OPCache를 설정했고, 약 1초 정도의 시간상의 이익을 봤습니다. (OPCache 쓰세요.. Cache 만으로도 시간의 20%나 벌었습니다) 그러나 근본적으로 새로운 링크를 작성하는데 1초를 벌어도 4초씩 걸리는건 아무리 생각해도 수상하다고 생각했습니다.
혹시 I/O의 문제인가 싶어 다시금 EBS Burst Instance로 전환했습니다(EBS Type gp3 -> gp2 변경)
상단의 읽기 바이트를 보시면 아시겠지만 서비스의 규모와 시간대에 비해 굉장히 높은 I/O가 발생하는 것을 볼 수 있습니다.
PHP를 디버그해서 실행시간을 측정했을 때 SQL INSERT가 수행될 무렵 속도가 느려지는 것을 식별했고 데이터베이스를 튜닝하기 시작합니다.
데이터베이스 보안상 SQL코드는 보여드리지는 못하고 워낙 간단한 SQL문이기 때문에 데이터베이스 튜닝 쪽으로 생각을 바꾸게 됩니다.
문제 파악과 InnoDB Buffer Pool Size 수정
데이터베이스가 너무너무 느렸기 때문에 이건 튜닝 문제다! 라는 생각을 하고 있었습니다.
혹시나 InnoDB의 문제가 아닐까라는 추측을 하게 되었고 허무하게 문제를 해결했습니다. 기존의 InnoDB Buffer Pool 사이즈가 256MB였고 이를 1G로 수정해보니 속도가 무진장 빨라졌습니다. (약 5초 -> 0.6초) 거의 100% 정도 시간을 벌었습니다.
InnoDb 에 대한 내용은 생략하고 지표를 보겠습니다.
지표가 매우 불안정하고 exponential 하게 차올랐는데 5월 15일부터는 계속적으로 안정적인 모습을 유지하고 있습니다.
결언
데이터센터에서 일할 당시 데이터베이스 튜닝을 전문적으로 하는 사람이 온 것을 본 적이 있습니다. 로그인 과정만 9초씩 걸리는 SSO 서버를 튜닝을 통해 0초대로 줄이는 모습을 보고 참 대단하다는 생각을 했는데 제가 직접 비슷한 상황을 경험해보니 대단히 새로웠습니다. 참고로 서버를 확장하면 매년 수천만원씩, 일시에 수억원씩 추가적인 지출이 예상되어 있었습니다(서버, 라이선스비용 등)
문제를 해결하게 되어 정말 기뻤고 다른 분들께 힌트가 되었으면 좋겠습니다.
