출처: https://severalnines.com/database-blog/preparing-mongodb-server-production
어플리케이션과 데이터베이스 모델을 개발한 후(개발 환경으로 옮겨야 할 때). 우선적으로 먼저 해야할 일들이 몇가지 있습니다. 종종 개발자들이 MongoDB 데이터베이스를 서비스로 배포할 때 놓치는 것들이 있습니다. 그리고 개발 모드에서는 필요없었지만 프로덕션 모드에서는 꼭 필요한 것들을 만날 수 있습니다. 어쩌면 그것이 큰 문제를 일으킬수도 있습니다. 이러한 것들을 이번 글에서 살펴볼 것입니다.
최신 버전의 드라이버를 이용 하셔요
보통 모든 기술의 최신 버전은 이전버전보다 향상된 것입니다. Mongodb의 최신 버전들은 이전 버전보다 건강한 상태이며 퍼포먼스, 안정성, 메모리 이용에 향상되어있습니다. 최신 버전을 권장하는 것은 데이터베이스 드라이버에 관해서도 동일합니다.
64 비트 시스템을 이용하셔요.
만약 32 비트를 이용한다면 몽고DB 프로세스는 약 2.5GB의 데이터로 제한됩니다. 왜냐하면 메모리에 맞게 퍼포먼스가 결정되기 때문이죠. 32비트 시스템에서 몽고db를 구동할때의 큰 문제점을 예로 들어보겠습니다.
적은 메모리의 시스템에서 서버를 구동하는 상황에서 에러가 발생했다면, 메모리의 크기가 작기 때문에 서버를 다시 킬 메모리가 충분해지기 전까지는 서버를 재구동시킬수 없게 됩니다.
이용하는 메모리에 맞는 크기의 데이터인지 확실히하셔요.
데이터 베이스는 가상 메모리에서 데이터를 읽어오는데에 실패할수 있습니다. 그리고 페이지 폴트를 발생시킵니다. 페이지폴트는 데이터베이스를 물리적 리스크로부터 데이터를 읽게 만듭니다. 그리고 그렇게 되면 어플리케이션에 지연이 생겨 퍼포먼스가 확연히 느려집니다.
페이지폴트는 이용하는 데이터가 메모리의 크기보다 클때 발생합니다. 이것은 특정 mongoDB의 다큐먼트가 감당할수 없을 만큼 크다는 것을 의미합니다. 혹은 sharding 방식이 형편없다는 것을 의미합니다. 이를 해결하려면,
- Document의 크기를 16mb이하로 제한합니다.
- Document 갯수를 제한하도록 shard를 설정합니다.
- MongoDB 인스턴스의 크기를 키웁니다.
레플리카 셋
데이터베이스 세상에서 단일 데이터베이스에 의존하는 것은 좋지 않습니다. 어떤 문제가 터질지 모르니 당연합니다. 그리고 유저가 계속해서 증가한다면 데이터 이용성 또한 증가시켜야 합니다. '복제'는 DB 장애에 대처하는 매우 중요한 접근 방식입니다. MongoDB는 데이터를 지역적으로 전달하는 능력이 있습니다: 여러 다른 지역에서의 유저들은 제일 가까운 곳에 있는 cloud host에서 데이터를 전달 받게 됩니다. 이런 방식으로 요청에 대한 지연을 최소화합니다.
만약 primary node(는 쓰기 작업을 하는 node를 의미합니다.)가 작동을 하지 않는다면, 새로운 node가 primary node로 선택됩니다. 그리고 선택된 node는 primary node가 진행하던 쓰기 작업을 대신 진행합니다. 이러한 방식의 장점은 에러가 난 node의 역할을 다른 node가 하기때문에 복구되는 시간을 기다릴 필요가 없게 됩니다.
백업 방식을 확실히하세요.
많은 비지니스들이 백업 시스템이 없거나 열악하여 데이터 손실 후 비지니스를 더이상 진행할 수 없는 상황이 되곤 합니다. 프로덕션 배포전에 이중 한개라도 적용하고 있는지 확인하세요.
- Mongodump: 아주 작은 크기의 배포, 혹은 특정 요구에 따라 필터링 백업을 생성할 때 최적입니다.
- Copying underlying: 큰 크기의 배포에 적합합니다. 그리고 DB의 모든 데이터를 백업하거나 새로 저장할때 적합합니다.
- MongoDB Management Service(MMS): 지속적인 온라인 백업을 제공해주는 관리 서비스입니다. 분산된 클러스터와 레플리카 셋에 적합합니다.
백업 파일들은 당연히 같은 호스트에 저장되어있으면 안됩니다. ! Backup Ninja를 사용해보십시오.
느린 쿼리를 체크하세요.
사실 개발 과정에서는 쿼리가 느린지 잘 알 수 없습니다. 개발과정에서는 데이터의 양이 적기때문입니다. 느린 쿼리는 보통 index를 사용하지 않았거나, 잘못 사용했을 때 나타납니다. 느린 쿼리를 찾고 해결하기 위해 우리는 MongoDB Query Profiler를 이용합니다.
'MongoDB Query Profiler'는 퍼포먼스 하락을 일으킬 수 있는 요인들을 찾아줍니다. 실제 배포하기 전에 성능 하락을 일으킬 수 있는 collection들에 profiler를 활성화 시키면 미래에 문제가 될 수 있는 들을 미리 체크할 수 있습니다. 특히 embedding이 여러번 된 collection에는 꼭 확설화 시켜보셔야 합니다.
모니터링 툴을 연결시키세요.
우리는 언제든지 DB의 상태를 알수 있어야 합니다. 데이터베이스를 모니터링 툴에 연결시키는 것은 우리의 데이터베이스가 무엇이 필요한지 쉽게 알려줍니다. 툴을 이용하면 시각적으로 무엇이 문제인지 무엇이 필요한지 쉽게 보여주기 때문에 문제를 알아차리기도 쉽습니다. 그리고 모니터링 툴은 알람 시스템이 있기 때문에 문제가 발생할때, 문제가 발생할 수 있는 상황에 언제든지 알람을 전달해줍니다.
