협력적으로 대응하기

블핑은 종교다

지난 5월 말 NCT 신규 앨범이 발매되는 이벤트가 있었을 때 케타포 서비스는 3일 연속 장애가 났었다. 나는 그때 예정되어 있던 가족 여행을 위해 휴가 중이었고, 무슨 일이 있었는지도 잘 몰랐었다. 그냥 3일 내내 이벤트가 열리는 시간에는 서비스 접속이 잘 안 되었다. 그저 데이터베이스가 부하를 견디지 못해서 서버 증설을 하고, 그래도 트래픽을 수용하지 못해서 불안정한 시간이 지속되었다. 그럼에도 불구하고 전 세계의 K-POP 고객들은 트래픽이 안정화될 때를 기다려 앨범을 구매했다. 우리가 안정적으로 서비스를 제공했다면 고객들은 정말 쾌적하게 케타포에서 앨범을 구매할 수 있었을 것이다.

이후 6, 7월에 많은 오류를 개선하고, 기획/개발 조직의 일하는 방식을 좀 더 협력적으로 바꾸려 노력했고, 구성원들의 표정에서 좋은 방향으로 가고 있다는 느낌을 받았다(깔때기 구조로 일하기 , 협력의 가치 참고).

8월 11일에 블랙핑크 신규 앨범 예약 구매 이벤트가 있었다. 이벤트가 열리는 시간에 엄청난 순간 트래픽으로 사이트는 얼마 버티지 못하고 접속이 안 되는 상태가 되었다. 회의를 하다가 팀원 분들과 장애 대응을 같이 했다. 사실 나는 모니터링이랑 제안 정도를 하고 실제 작업은 AWS와 DevOps에 능한 팀원분이 진행했다. 

참 이상했다. 이전처럼 데이터베이스에 과부하가 걸린 것이 아니었다. 심지어 WAS도 부하가 높지 않았다. 백엔드 개발자들은 재택인 분도 계셔서 온라인으로 채팅을 하면서 문제의 원인을 찾고 있었다. 그러다 Tomcat Sesssion Cluster를 위해 사용하고 있는 Redis 메모리가 꽉 찼다는 것을 발견했다. 이로 인해 WAS까지 트래픽이 들어오지도 못하고 있었던 것이었다. 케타포 서비스는 오랫동안 서비스되고 많은 사람들에 의해 변경된 레거시였고, 심지어 이력을 가지고 있는 개발자는 거의 없었다. 이 상황에서 해결책을 찾기보다는 서버 증설로 문제를 완화시키려고 했다. 서비스는 조금씩 안정화되었지만 여전히 Redis 메모리가 증가하고 있었다. 이때 채팅 방에서 누군가 Redis에 사용자별로 어떤 정보가 있는지 찾았고 상당한 크기의 정보가 사용자 별로 저장되는 것을 발견했다. 그러니 순간 트래픽 유입을 감당하지 못한 것이었다. 또 케타포에 수년을 다닌 개발자 분은 그런 정보에서 불필요한 정보를 찾아서 제거하는 작업을 해 주셨다. 그리고 실서비스에 개선안을 적용하니 Redis 메모리가 안정적으로 되었고, 서비스는 안정을 찾았다.

이 상황에서 또 다른 분은 S3로 이동하면 좋을 정적 파일들을 찾아서 이동시켜주셨다. 그래서 2시간 정도 불안정한 시간이 있었지만 그날 저녁에는 많은 개선을 통해 안정적인 상태를 이루었다.

그 후 다시 블랙핑크 2차 이벤트가 있었을 때는 사소한 실수로 10분 정도 불안정했지만 높은 트래픽을 안정적으로 수용했다.

Redis에서 문제가 발생했을 때 나는 네트워크 구성이 문제가 아닌가라는 생각을 먼저 했다. WAS에 트래픽이 안 들어오니... 하지만 우리는 협력적으로 일하며 정확한 문제를 파악했고, 누군가는 그 문제를 빠르게 해결할 방법, 또 누군가는 그 문제를 원천적으로 해결할 방법을 찾았다. 그리고 속도를 더 높일 수 있는 방법도 또 다른 누군가가 찾았다. 한 가지 일을 이렇게 여러 명이 협력적으로 일하면서 아주 짧은 시간에 서비스의 성능과 안정성을 빠르게 달성할 수 있었다.

이러한 경험이 쌓이고, 정리되고, 공유되면 케타포의 개발 조직은 좀 더 사용자의 경험을 높이면서 안정적으로 서비스를 제공할 수 있을 것이라고 생각한다.