MongoDB 클러스터링 운영 중, 서버 중지(Kill) 및 원복 후 느려짐

이 포스팅은 팁으로 올리는 포스팅이 아니라, 금일 발생한 문제에 대해서 적어보기 위함이다. 아직까지 문제는 해결되지 않았고 추후 이런 문제가 재발되었을 경우 어떻게 해야 될지 고민중이라 그냥 끄적이는 일기장같은거라고 해야 할까?

 

하루에 엄청나게 들어오는 사이트에서 백엔드의 일부 서비스를 몽고DB 3대를 클러스터링한 것으로 API를 제공하고 있다. 몽고DB에는 추천 알고리즘으로 분석된 결과가 저장되어 있으며, 이를 일부 서비스에서 제공을 하고 있었는데 금일 오전 갑자기 클러스터 한대가 중지(Kill) 되었다.

 

깔끔하게 죽어버려서 로그(Log)를 뒤져봐도 아무런 문제가 없었는데 다행인것은 클러스터이기 때문에 API는 해당 서버를 무시하고 나머지 서버와 통신을 하며 운영중이었다. 머리속에서 DB 대수를 늘려야 되나? 또 이런 문제가 발생하면 어떡하지? 라는 생각과 함게 일단 서비스를 기동 시켰는데 문제는 다음에 발생하였다.

 

클러스터간에 동기화가 안돼서 그런건지, 모든 응답이 1000ms 가 넘어가게 되어 버렸다. 현재 API는 평균 50ms에 처리하게 되어 있고 Front에서는 1000ms가 넘어가면 문제가 있다 판단하여 데이터를 가져오지 않는다. 이 문제는 30분 후에 Bulk로 도는 배치 프로그램이 자동으로 데이터를 모두 변경시켜줘서 해결이 되었는데 결국 클러스터의 함정인 것이다.

 

서버를 재기동하면 API가 반응을 하여 해당 서비스에 호출을 하게 될텐데 이 문제를 어떻게 해야 할까? 고민을 하는 상황에서 3가지의 대안을 고민중이다.

 

첫째, 특정 서버가 죽을 경우 API는 클러스터를 호출하는 방식에서 개별 DB를 호출하는 방식으로 변경을 한다. 물론 이 방식을 썼을 때 서버가 클러스터 확인을 할 지 안할지 모르기 때문에 일단 스테이징 서버에서 2대를 구성하여 테스트 해볼 예정이다.

 

둘째, 클러스터를 하나 더 구성한다. 즉 A서비스와 B서비스를 목적으로 만든 개별적인 클러스터에서 특정 클러스터의 장애가 발생되었다면, Stand By인 클러스터에서 서비스를 진행한다. 문제는 이렇게 하면 한 DB에 데이터가 너무 많이 저장되는 문제가 있다.

 

셋째, 완전 다른 이종DB를 구성한다. 같은 NoSQL 계열에 다양한 기능이 내장된 엘라스틱서치에 데이터를 넣어서 장애가 발생되었을 경우 임시적으로 바라보게 한 후, 복구되면 다시 MongoDB를 바라보게 한다. 

 

첫번째를 사용하면 서버를 증설할 문제는 사라지지만, 확실히 된다는 보장이 없고 가장 안전한 방법은 세번째 방법이라 생각한다. 즉 장애가 나서 엘라스틱 서치를 바라봐도 분석 프로그램이 모두 돌아서 Batch 작업이 끝난다면 다시 MongoDB를 바라보게 프로그램을 하면 간단히 해결이 되니깐 말이다.

 

확실히 NoSQL은 너무나 문제가 많은 것 같다. 성능 측면에서는 분명 좋지만 이렇게 쉽게 Kill이 된다니 말이다. 일단 SE팀에서는 해당 버전이 문제가 있는 것 같아서 버전업을 하자는 의견을 제시하였는데 현재 MongoDB는 4.4.3 버전이니 이 버전을 쓰고 있거나 계획을 하고 있는 사람은 다른 버전을 쓰는 것을 권장하고 싶다.