MongoDBの可用性を高めるために気をつけていること 構成編
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
はじめに弊社MongoDBクラスタ構成パターンスタンドアロンレプリカセットシャーディング高可用性のためにマネージメントツールMongoDB Cloud ManagerMongoDB Atlasまとめ終わりに
はじめに
MongoDBはご存知のように、NoSQLデータベースというカテゴリに分類される、ドキュメント指向の分散データベースの一つです。
2011年頃、MongoDBが1.X系の頃から部分的に使われ始め、2系が出た頃には、主にソーシャルゲーム分野で大規模に使われ始めました。
現在では、その特徴であるスキーマレス、スケーラビリティの性能からゲーム分野だけに留まらず、メディア系サービスのマスターデータを取り扱うDBとしての使用も多くされています。
弊社でのMongoDBの利用について、Webで検索をかけると比較的古い情報はヒットするものの、近年の情報はそこまで多くありません。
- タップルでの事例
- ピグパーティでの事例
そこで本記事では簡単に、現状についてご紹介してみたいと思います。
弊社MongoDBクラスタ構成パターン
スタンドアロン
レプリカセットやシャーディングを組むことなく、1台で構成されています。
主にデータセットが小さい検証環境や一時的なデータ、ログの展開先などの調査用途、個人の開発環境に用いられることが多いです。
レプリカセット
こちらは毎日利用する検証環境や、システムの一部機能などに用いられています。
シャーディング
シャーディングを導入すると、大きなデータセットを持つ高いスループットを必要とするアプリケーションに対応でき、読み込みと書き込みの両方をクラスタ全体に水平分散することができます。必要に応じた拡張が容易であることもメリットの一つです。
また各シャードを独立したレプリカセットとして構成することでスケーラビリティも向上させることができます。
反面、管理対象となる構成要素が多くなるためコストの増加は避けられません。
こちらもMongoDB Cloud Manager管理下か、MongoDB Atlasで運用されています。
高可用性のために
弊社ではほとんどの本番環境において、レプリカセット、もしくはシャーディングの構成が取られています。
過去においては大量の物理サーバをデータセンターに置き、30shardを超えるような大規模運用をしていた時代もありましたが、機器の性能も上がり、インスタンスの性能も非常に高い現在では、物理サーバの運用はされていません。
プラットフォームとしては、弊社独自の"Cycloud"というPrivate Cloud上や、AWS、Google CloudといったPublic Cloud上に構成されています。
現状使用されている構成パターンを見てわかるように、サービスの中核としてのデータベースである以上、高水準の可用性を実現するためにMongoDBではレプリカセットの使用は必要です。そして高い読み込みと書き込みが必要なサービスにおいては、シャーディングも活用されています。クラスタが大規模になり管理対象が大きくなると、スケール時やバージョンアップ時などの手順が煩雑になるため、マネージメントツールを用いることでの運用負荷の低減を図っています。
マネージメントツール
MongoDB Cloud Manager
MongoDB Cloud Managerは、インフラの管理をほぼ自動化でき、アップグレードやモニタリング、バックアップなどをWeb上のUIから実行することができます。
MongoDB Atlas
MongoDB Atlasは、MongoDB社のマネージドサービスとして、各パブリッククラウド上でホスティングされる、DBaaS（Database-as-a-Service）です。
MongoDB Cloud Managerと比べて、ワークロードの変動に応じたスケールアップやスケールダウンの機能があり、パフォーマンスとコストの最適化が可能です。加えて、インデックスの提案やパフォーマンスアドバイザーなどのツールが準備されているため、運用管理コストを最適化することができます。
このように、公式のマネージメントツールを利用する機会が多くなってきています。デプロイ管理の自動化サービスを利用したほうが管理コストとしては下がるためです。
またこれだけだと、MongoDB社の紹介記事のようになってしまうので付け加えておくと、
MongoDBを利用していたサービスでの、他データベースへの移行事例もあります。
近年ではMongoDBとの互換APIを備えた、下記のようなデータベースも登場しています。
- Amazon Document DB
- Azure Cosmos DB for MongoDB
- Oracle Database API for MongoDB
これらの紹介と移行事例についてもいずれ、記事にしてみたいと思います。
まとめ
まとめると、MongoDBの構成として
- レプリカセットの使用
- シャーディングの導入
は可用性を担保するために重要であり、耐障害性の向上と負荷分散を実現できます。
またマネージメントツールの導入も、運用負荷や運用ミスの軽減に寄与しています。
そして適材適所ではあるものの、DBaaSの導入も非常に効果的です。
互換APIを備えたデータベースへの移行も、要件によっては効果的なため検討する価値があります。
終わりに
今回は、弊社内で使用されているMongoDBの構成について、可用性の観点から紹介させていただきました。
また今回では言及しなかった以下の点、
- メモリサイズの考察
- インスタンスのスペックの決定
- クエリの最適化
- コストの最適化
- インデックスについて
- キャッシュレイヤーの導入
- 監視、モニタリングについて
などなど、今後も投稿していこうと思います。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
