ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

MongoDBを時系列データベースとして使用

当社は2009年から時系列データベースとしてのMongoDBを使用してきました。

MongoDBは、当社の サーバ監視 サービスで収集した時系列データのボリューム拡大に対応して、スケールアップするのに役立ちます。 長年に渡り、当社は月に40GBから250TB以上までのデータ処理を行ってきました。

長年に渡って、当社のサービスに役立ってきましたが、私は必ずしも、MongoDBが時系列データのための最高の可能なデータベースと提唱していません。それは当社がこれまで使用してきたというだけで、(当社は常にいろいろな選択肢を検討しています)。

その上で、私はMongoDBの使用方法について何度か書いたことがあります。(ここで当社の時系列グラフの背後にある技術)でご覧頂けます。 Story of the Payload_のキャンペーンの一環として (お楽しみに! ) その内部の仕組みを詳しく、クラスタ設定を再検討しようと思いました。

ハードウェア

当社は長年に渡り、様々なインフラの選択肢を試してみました。これらの中にはGoogle Compute EngineAWSSSDs対するスピンするディスクVMWare、そして現在からの マネージドクラウドからSoftlayer への移行があります。当社ではUbuntu Linuxで標準化し、以下のようにクラスタが設定されています。:

Ubuntu Linux 12.04 LTS

私たちは、 LTSのリリースですべてのサーバーを運用し、固定のスケジュールで次のLTSにアップグレードしています。当社のチームは、新しい機能やバンドルされたライブラリにアクセスする必要がある場合、特定のアップグレードをスピードアップすることができます。

ベアメタルサーバー

当社は過去に仮想マシンで実験し、保証されたディスクI / Oパフォーマンスでもホストの競合に問題があることを見つけました( AWS EBSまたはCompute EngineのSSDのような製品は、SOFTLAYERとは異なり、このオプションを提供しています)。

Solid State Disks

当社は、複数のSSDが保有しておりー、ジャーナルを含む各データベースを独自のディスクに収納しています。
すべてはPuppetで管理されています**。

当社は独自のマニフェストを作成するために使用しました。オフィシャルの Forge MongoDB モジュールがそれ以来、より良いオプションとなる、それに移行しています。
サーバー自体については、以下のようなスペックです。:

  • x2 2GHz Intel Xeon-SandyBridge (E5-2650-OctoCore) (全部で16コア)
  • 16x16GB Kingston 16GB DDR3
  • x1 100GB Micron RealSSD P300 (MongoDBジャーナル用)
  • x2 800GB Intel S3700 Series (データベースにつき1つ)

MongoDB クラスタ

当社は現在の環境を18ヶ月間使用してきました。この間に、当社は垂直的(RAMを追加)もっと破片を追加)及び水平的に(シャードを追加)スケーリングしました。詳細とスペックは以下の通りです。:

  • x3 データノードレプリカセット及び1つのシャードごとにアービター.
  • Washington DCのプライマリデータセンターにx2ノード、 San Jose, CAにフェイルオーバーノード. アービターはDallas, TXの3つ目のデータセンターに収納。
  • アイテム(例、サーバ)のIDおよびメトリックに基づく配分のX5シャード。これは、最大の可用性のために複数のシャードで顧客の記録を分割します。MongoDBは、ハッシュベースのシャーディングを使用してバランスを保ちます。
    *平均負荷は1ミリ秒あたり6000回の書き込みで、 1日あたり約5億の新規ドキュメントと相当になります。

  • 当社は MongoDB クラウドバックアップサービス を使用しており、これによりリアルタイムでオフサイトのバックアップができます。それぞれのレプリカセットでレプリカノードとして機能します。 すべての書き込み操作の(コンパクト、圧縮)のコピーを受け取ります。現在のスループットは、42 Mbpsを保っています。

  • 当社ではGoogle Compute Engine 及びMongoDB クラウドバックアップサービスAPIを利用して、 バックアップの復元 をして、1日に2回にプロダクションのクラスターと照合しています。
  • 当社では、最終的な災害復旧オプションとしてヨーロッパでGoogleのクラウドストレージ内にバックアップのコピーを保持しています。10日間に遡って、 1日2回のコピーを保存します。

データ

クラスタの書き込みのワークロードは、ほとんどは挿入および更新で構成されています。

最下位レベルのデータのために、新しいデータが挿入され、更新されない時には、当社は追加専用のスキーマを使用しています。これらの書き込みは約2-3ミリ秒かかります。

時間平均タイプのメトリックでは(当社はそれらを永遠に保存しています – [監視グラフ](https://www.serverdensity.com/monitoring-graphs/”Server Density Monitoring Graphs”) を確認ください) 、当社は一日ごと、メトリックごとに、アイテムごとのたりのドキュメントを割り当てをしています。

このドキュメントは、合計やカウントで更新されます。そこから、当社は、データを照会する際の平均値を計算します。この書き込み作業が完了するまでに大体500ミリ秒かかります。

当社は書き込みを最適化し、フィールド修飾子を使用、事前割り当てにより文書の増加を避けています。 そうであっても、ドキュメントの更新に関連して、多大なオーバーヘッドがあります。

データを照会する際には(例 グラフを描く)、ユーザーが経験する平均応答時間は189ミリ秒です。応答の中央値は、 39ミリ秒であり、 95パーセンタイルが532ミリ秒で、 99パーセンタイルは1400ミリ秒です。大部分の時間は、APIのレスポンスを構築するので、アプリケーションコードによって使用されます。クエリの最も遅いのは、広い時間の範囲にわたって複数の項目とメトリックがある場合です。アプリケーション・コードを除外した場合は、MongoDBの平均クエリ時間は0.0067ミリ秒です。

要約

これが、Server DensityでのMongoDBクラスタ設定です。みなさんのご意見をお聞かせください。どのようにMongoDBを使用していますか?ご使用のクラスタはどのような形態ですか?また時間ととものどのように進化していますか?