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

Server Densityについて

Author Archives: David Mytton

  1. クラウドの場所は重要である。 -待ち時間、プライバシー、冗長性

    Comments Off on クラウドの場所は重要である。 -待ち時間、プライバシー、冗長性

    昨今、クラウドのインフラ市場の競争は過熱しており、各ベンダーは差別化を図るためのいろいろな努力をしています。インフラを構築するためには莫大な予算がかかり、最適な場所に投資することは重要な選択です。クラウドベンダーは製品やテクニカルサービスにおいて革新的であっても、場所も重要なのです。 –皆さんのベンダーのデータセンターがどの地域にあり、そのことがなぜ重要なのでしょうか?

    なぜ場所が重要なのか?

    場所が重要な理由はいくつか挙げられます。:

    • 冗長性:サーバ障害の可能性と比較して、データセンター全体の停止はごく稀です。–しかし、それは起こりうる障害です。停電, ソフトのバグ極端な気象の場合に、複数の独立した施設に渡って、ワークロードを分散できることが重要です。これは、悪天候や電気的故障のようなローカルの問題を避けるために、単なるデータセンター間だけでなく、地域にまたがって冗長性を得ることです。待ち時間を最小にするのに十分近く、十分に地域にが離れたデータセンターを必要です。
    • データ保護: 異なるタイプのデータは、異なるローカルの要件を有します。例えば、EUでは個人データは同地域内になければいけません。
    • ユーザーの待ち時間: エンドユーザーの応答時間はアプリケーションによっては非常に重要で、ユーザーの近くにデータセンターがある必要があります。また、異なる領域にトラフィックを送信する機能は、これを簡素化に役立ちます。コンテンツによってはCDNsが使用される場合がありますが、ソースへの接続も必要になります。

    世界中にデータセンターを展開するのは安価ではなく、ここが大きなクラウドプロバイダーが優位性を持っている分野です。これはデータセンターを装備し、人材を配置するというだけではありません。– イノベーションはどれだけこれらの施設が効率的であるかにかかっています。それはローカルの地域でグリーンなデータセンターを構築するとか自家発電のシステムを作ると行ったことがありますが、これはすべてにおいて価格の削減に貢献し、唯一スケールにおいて実現できます。

    トップのプロバイダーのパフォーマンスの実態は?

    異なるプロバイダはすべて特定の地理内のデータセンターや地域の概念を持っています。

    通常では、地域内での冗長性を得ることができるので、これらは複数の領域に分割されます。しかし、真の冗長性を実現するためにはそれは十分ではありません。なぜならば地域全体で問題が発生したり、嵐のようなローカルでの出来事があるからです。そのため、真の地域をカウントすることが重要です。

     

    プロバイダー アメリカ ヨーロッパ アジア その他
    Amazon 3 1 3 1
    Azure 5 2 4 1
    Google 1 1 1 0
    Rackspace 3 1 2 0
    Softlayer 5 2 2 1

    Azureが12地域でリードしています。次いでSoftlayer (10)、Amazon (8) 、Rackspace (6)、でGoogle はわずか3地域しかありません。

    どこに投資がされているか?

    Amazonがヨーロッパでは唯一の単一の地域でやっているのはやや意外です。 — しかしながら、これは ドイツでの新地域の証拠により変わるかもしれません。もし、冗長性を求めているのであれば、少なくとも近くに2つのデータセンターが必要です。さもなければ、待ち時間が問題となります。例えば、海を越えてデータを送信する必要がある場合(例えばUSとアイルランド間)、データセンター間の生産データベースを複製することは、より高い待ち時間を経験することになります。アイルランドとドイツ間でデータの複製をする方がいいはずです!

    aws-map

    Softlayerは他の地域へ展開を進めていて、2014年に新しいデータセンターの構築に12億ドルを投資することを発表しました。最近では、香港やロンドンでデータセンターを立ち上げ、さらに北米(2)、ヨーロッパ(2)、ブラジル、UAE、インド、中国、日本とオーストラリア(2)に展開予定です。

    softlayer-network-map

    Googleにはもっとも失望します。 インフラには多額の投資をしています。 また、Google Cloud以外に世界中にデータセンターがもっとたくさんあります。– 米国(6),、ヨーロッパ(3) 、 アジア (2) – これはマイクロソフトに次いで2番目です。もちろんGoogleはクラウド市場へは新参者でもあり、コンスーマー向のGoogle searchやGmailなど製品の需要に対応せねばなりません。新機能の立ち上げのスピードを考慮に入れ、他社との競争に本当に勝ち抜くためにはこの状況は変わってくると思います。

    google-locations

    中国については?

    特に上記の数値から中国を除外していますが、中国はまた面白いケースで。問題は中国内部の接続は(一部の地域では)非常に良いですが、国境を越えることは大変な遅延とパケットロスが起こります。マイクロソフトとAmazonの両社は中国内の領域を持っていますが、別のアカウントを必要とし、通常は適用するために中国に拠点を置かなければなりません。Softlayerは上海にデータセンターを構築することを発表しており、良いスループットでグローバルなプライベートネットワークへ接続できるかどうかは興味深いです。Googleに関しては4年前に中国から正式に撤退しており、この地域では2度と展開しないと思われます。.
    これは、場所が競争優位性の上で重要であることは明確で、マイクロソフトが現在、トップですが、すぐにSoftlayerのその座を譲ることになります。投資した金額のことを考慮すると、どの地域でクラウドの利用が広がるのか興味深いです。

  2. ゼロダウンタイムの新しい環境へ高スループットのアプリケーション移行

    Comments Off on ゼロダウンタイムの新しい環境へ高スループットのアプリケーション移行

    現在、当社はすべてのサーバーとウェブ監視関連の製品であるServer DensityをSoftlayer からGoogle Compute Engineへと移行するプロジェクトを終えようとしています。当社ではサービスを提供するために100台以上のサーバーが稼働中であり、毎月 30-40TB 程度のデータを処理し、毎日MongoDB へ10億ものドキュメントを書き込んでいます。Server Density はお客様の42,000台以上のサーバー監視のために負担がかかっておりますが、ゼロダウンタイムで影響を最小限に抑えるために気をつけなければなりません。

    このポストではどのように移行を計画し、遂行するかについて論じます。

    Server Densityのインフラ環境

    なぜGoogle Cloudへ移行するのか?

    ここ数ヶ月間、私はUKやUSにて移行のプロセスに関して話をしてきましたし、このポストの一番下のビデオでさらに詳細の理由について説明しています。また近いうちになぜGoogle Cloudに移行したか書きたいと思います。 何か質問があれば、是非コメントを書き込んで下さい!

    移行へのステップ

    ゼロダウンタイムで影響を最小限に抑える必要があり、移行のプロセスは複雑であるためにこのプロジェクトに関していくつかのステップを踏みました。

    1. 計画
    2. テスト
    3. 複製
    4. 切換え

    すべてのプロジェクトの中でもっとも大切なポイントはできるだけシンプルにするということです。 – 当社はSoftlayerでサーバーが稼働しており、Google Compute Engineのサーバーへ 1:1 で移行することを計画しました。これは初期の段階でロードバランサー、バックアップ用のスナップショットなどのGoogle Cloud のたくさんの機能を使用しないことを意味します。私共は将来的にはこのような機能は使用する予定ですが、変更点をできるだけ少なくして、できるだけ既存の環境のまま移行させることにしました。

    Screen-Shot-2014-08-26-at-12.03.42

    ステップ1: 計画

    100台以上のサーバーと多大な トラフィックを移行するためには多くの作業が伴い、最新の注意を払って計画をせねばなりません。以下の様な質問への問いかけが必要です。:

    • 違いは何か? – 新しい環境は古いものとは違います。多分違ったOSのイメージが利用可能でしょう。またネットワークも違った形で設定されているかもしれません。地域やゾーンはどのように設定しましょうか?多くの人が Amazon zones は独立していると思っていますが、すべての地域で失敗がおきるかもしれません。Google は特にゾーン間で展開すれば冗長性のために十分であると言っています。しかしながら、決して100%の保証はありません!
    • ベンダー特定のAPIがあるか? – 新しい環境にはないかもしくは全く同じAPIもしくは特定のベンダーの機能を使用しているかもしれません。再実装のためにはスクリプトが必要になるかもしれません。
    • 新たに修得することは?- 上記の質問に関連しますが、これはいかに新しい環境が稼働しチームが通常の業務を行うことができるように知識を身につけなければなりません。フェイルオーバー、サポートのプロセスやリソースなどについてです。
    • コスト – 既存の環境を複製して、しばらくの間は同時に2つの環境を稼働させるので、コストは2倍はかかります。このためできるだけ複製する部分を削減できるようにうまく計画を策定しなければなりません。新たしい環境のコストはできるだけ既存の環境と比較して十分にモデルを作るひつようがあります。そうすることにより、全く予想していなかったi/oやネットワークのコストを心配する必要がなくなります。

    ステップ 2: テスト

    この段階は全く違った環境で、現実的にプロダクションのワークロードのシミュレーションが必要になるので、一番時間がかかります。Softlayer では当社はMongoDBの配備のためにSSD搭載のカスタムスペックの専用サバーを保有しておりGoogle Compute Engineでも少なくとも同等レベルのパフォーマンスを確保したいと思っています。

    私はここで重要な情報を発見しました。例えば Google Compute Engineのインスタンスはディスクをどのように正確に設定するかまたはRAIDが不必要であるなど、ディスクボリュームとVMの両方を制限するということです。

    また最新のLinuxのカーネルを使用していることを確かめることが重要です。少なくともLinux 3.3 を使用することによりGoogle SSDsの最良のディスクパフォーマンスが可能になります。また最近では私は新しいGoogleディスク製品をテストしており、これによりMongoDBより優れたパフォーマンスが可能になります。近いうちにこのサービスについては発表することができるでしょう!

    GCEでの共通する問題はボリュームサイズが小さすぎるということです。これは IOPのボリュームのザイズに応じて直線的に調整されるためです。 そして、ディスクの必要なスペースに応じて設定すると、ディスクの設定が小さくなってしまいます。

    Google Computeエンジンの共通の問題

    ステップ 3: 複製

    さて、ここで本当の意味の移行が始まり、新しいプロバイダーの環境への複製が行われます。. ここでは主に Puppetを使用しました。 なぜならば、すべの設定が一元化できるので、自社のすべての環境を定義し、他でサーバーを複製することが簡単です。

    MongoDBは使い易い複製の機能を持っており、データを複製するためには新しい環境へ複製のスレーブを簡単に設定するだけです。Benchmarking the connectivity between Softlayerと GoogleのUS地域の接続性のベンチマークでは、当社は 250Mbps以上のスループットがあります。これはSoftlayer’s WDCと 冗長性のために複製するSJCデータセンターの間の数値とほぼ同じです。

    MongoDBで複製をせっていするには、複製のセットとクライアントのすべてのコネクションをSSLかVPNを設定して使用することが必要です。SSLはカスタムメードのバージョン(もしくはエンタープライズバージョン)のMongoDBでのみ使用が可能です。 MongoDB 2.4はローリングのアップデートができず、すべてのクラスターがSSLを使うか全くなしでやることになるので、あまり優れものではありません。 MongoDB 2.6ではこの問題は解決されていますが、当社では現在バージョン2.4で稼働させており、原則として新しい主要なMongoDB のバージョンへはアップグレードしません。

    これはVPNの設定が必要になり、SoftlayerとGoogleの両方のVPNのサポートを使用することで可能になります。

    接続性 - VPN かSSL?

    ステップ 4: 切換え

    当社はGoogle Compute Engineに環境に複製しており、これは効率的な第二のデータセンターであるので、プライマリーのデータセンターからのフェイルオーバーのように切り替えることができることができます。

    このプロセスを行うためには Softlayer MongoDB のノードをフリーズさせる必要があります。 それにより、プライマリー変更せずにステップダウンをすることになり、 Googleノードがプライマリーにしてから、まずはトラフィックがGoogleに行くようにしてDNSを切換えます。ユーザーによっては古い施設のウェブサーバーにアクセスしたり、データがVPN経由で他のプロバイダーへ送信される場合には遅れも発生します。しかしながら、これはすべて透明で重要であり、ダウンタイムがあってはなりません。

    明らかにこれはどのように機能するかの簡単な説明です。実際には、当社はいつどのようなステップをとるかについての細かな確認リストを持っています。事前にリハーサルをすることは重要であり、当社が切換えの日に何も見逃すことないように確認することができます。

    切換えが終わったら、すべての機能が稼働しているか確認してから、古い環境を止める作業を始めることができます。これはまずサーバーを止めて、数日後にSoftlayerとキャンセルをします。これによりサーバーを実際に壊さずに何か見逃したことはないか見つけることができます!

    切換え

    現状

    当社はGoogleでの新しい環境を準備する最終段階です。移行が終了したらフォロアップの投稿を期待していて下さい。どのように移行が進んで、どんなことを学んで、どのように問題を解決したかをご説明したいと思います。もし読者の方がお客様であるならば、新しいIP(もしホワイトリストに登録されているのであれば)と共に移行の日をステータスのページで公表します。

  3. GoogleコンピュートエンジンでのMongoDBー -ヒントとベンチマーク評価

    Comments Off on GoogleコンピュートエンジンでのMongoDBー -ヒントとベンチマーク評価

    ここ四年間以上、Server Density社ではMongoDBをずっと運用しており、私は専用ハードウェア、仮想マシン及び複数のクラウドサービスのプロバイダー間で展開することができました。

    専用のサーバーは一番いい環境と言えます。それは特にCPUとディスクi/oのホストのコンテンションの問題があるためです。しかしながら、Googleはコンピュートエンジンの製品の一貫性及びパフォーマンスを誇っており、特に高度の帯域幅調整により複雑な問題を処理できるとしています。

    そこで、私はGoogleコンピュートエンジンでMangoDBがどのようなパフォーマンスを見せるかについて検証することしました。

    Google コンピュートエンジンロゴ

    書き込み確認(Write Concern)のテスト-パフォーマンスと耐久性

    MongoDBの書き込み確認(Write Concern)の問題は、以前から物議を醸してきました。元来、Mongoは耐久性を犠牲にして非常に高度な書き込みスループットを得るために設計されていますが、この件に関しては十分に立証されていませんでした。しかしそのデフォルトはかなり前に変更され、現在では、書き込みに関しては受け入れられたことを確認応答(Acknowledgement)をする上に、速度か耐久性を調整できる柔軟性があります。

    私は書き込み確認(Write Concern)のテストをして、どの程度の応答時間を期待できるか確認してみたいと思います。:

    未確認(Unacknowledged): w = 0 AND j = 0

    このやり方では、ドライバーはサーバーに書き込みをしたか確認をしません。そのため、うまく書き込めたかは不明で、そのネットワークエラーの発見についても不明確です。

    確認済み(Acknowledged): w = 1 AND j = 0 (デフォルト設定)

    このやり方では、うまく書き込みができたか確認できますが、実際に書き込みがされたかというしるしはありません。しかしこれにより大部分のエラーを見つけられます。例えば、解析エラー、ネットワークエラーなどです。

    実行記録の書き込み(Journaled): w = 1 AND j = 1

    このやり方ではプライマリのレプリカセットのメンバーによるジャーナルへの書き込みと確認されるまで、書き込みを待たせることになります。そのため、単一サーバーとしての耐久性はあっても、データが他のクラスターにレプリケーションされたということを保証するものではありません。理論的には、データセンターの障害や書き込みの失敗の可能性が考えられます。

    レプリカ確認(Replica acknowledged): w = 2 AND j = 0

    このテストでは、データの書き込みがレプリカセットによって確認されるまでどのくらい時間がかかるか、またレプリカセットの少なくとも1つのメンバーが確認されるまでにどのくらいの時間がかかるかが分かります。また、2つのサーバー間での耐久性が生まれます。しかし、理論的に、その書き込みは両方とも失敗する可能性もあります。なぜならば、ジャーナルへの書き込みをチェックはしてないからです。

    レプリカ確認(Replica acknowledged)実行記録の書き込み(Journaled): w = 2 AND j = 1

    このやり方では、データはプライマリに送られ、そのレプリカセットの中の少なくとも一つのメンバーによる確認を保証できます。

    レプリカ確認(Replica acknowledged)と過半数確認: w = majority AND j = 0

    複数のデータセンター環境では、ユーザーは、データが安全に複製されたか知りたいはずです。この majorityのキーワードにより、書き込みがレプリカセットの過半数メンバーにより確認されたことを保証します。もしユーザーがそのセットを均一的にデータセンターに配備できた場合には、データーは安全に複数の場所に保管されていることを確認できます。

    レプリカ確認(Replica acknowledged)と過半数確認と実行記録の書き込み: w = majority AND j = 1

    これはおそらくパラノイドモードの最たるもので、書き込みがプライマリでしっかり確認されて、過半数のノードに複製されたことが分かります。

    環境設定

    レプリカセット

    実世界では、アプリケーションはレプリカセットを利用して、複数のデータセンター間での冗長性とフェイルオーバー機能を持たせています。このことを正確にテストするために、テスト環境では2つのゾーンに渡る4つのデータノードを含めました。そのうち2つは us-central1-a ゾーンで、他の2つがus-central1-bゾーンです。

    実際の配備においては、障害の時にそのセットを維持できるよう過半数のセットを持っていなければいけません。そのためアービタとして5つ目のノードを他のデータセンターに配備します。なお、ここでは話を単純にするために、私は試しませんでした。

    Googleコンピュートエンジン

    私はn1-standard-2 (2 vCPUs と 7.5GB RAM)とn1-highmem-8 (8 vCPUs と 52GB RAM)イスタンスタイプに backports-debian-7-wheezy-v20140318 OSイメージを追加してテストしました。

    インスタンスのCPUコアの数により、i/oパフォーマンスも影響を受けます。最高のパフォーマンスの実現のためには、提供される全部のメモリーを使わないとしても、4つか8つのコアのインスタンスタイプを使用しなければなりません。

    さらにそのデフォルトロケールがまだ設定されていないところでの
    GCE Debianイメージにはバグがあることにも留意ください。このことがDebianパッケージからMongoDBを正常にスタートさせることを阻んでいます。その回避策は以下のようにデフォルトを設定することです。

    sudo locale-gen en_US.UTF-8
    sudo dpkg-reconfigure locales

    Google永続ディスク

    Google永続ディスクのパフォーマンス特徴とIOPSが、ボリュームのサイズとどのようにリニアに変動するか理解することは重要です。以下、ここでの重要なポイントを記します。

    • 少なくとも別々の永続ディスク上にMongoDB dbpathをマウントする必要があります。これはすべてのコンピュートエンジンインスタンスのデフォルトルートボリュームが小さいために、低いパフォーマンスしか期待できないためです。仮にOSバーストは許容するとしても、通常持続的な使用要件のあるMongoDBでは十分ではありません
    • directoryperdb を使用して、それぞれのデータベースに永続ディスクボリュームを付与します。これにより、パフォーマンスとコストを最適化できます。さらに自身のデータ増加に対応する場合やIOPsのパフォーマンスの利点を得るためにボリュームを修正できます。
    • directoryperdbがない場合でも、は ジャーナルはいつも自身のディレクトリにあるので、別のボリュームにジャーナルを書き込むことは可能です。もし、別のボリュームにデータベースを入れないとしても、パフォーマンスの改善はx3までと顕著なので、ジャーナルを自身の永続ディスクに分離しておく価値はあります。 (結果は以下を参照).
    • ジャーナルの書き込みは数GBのスペースだけしか使用しないので、必要なボリームは相当少ないかもしれません。しかしながら、利用可能なIOPsはボリュームサイズとともに上がるので、永続ディスクのボリュームを小さく割り当てることはパフォーマンスの低下につながります。ジャーナルの書き込みには、少なくとも200GBのボリュームを選択して下さい。

    • もし、自分のデータベース(もしくはジャーナルだけでも)を他のボリュームに分離したら、バックアップ用のスナップショットは利用できません。これは複数のボリュームでのスナップショットは、必ずしも同時に起きないので、一貫性がないためです。その代わりに、mogodを終了して(あるいはfsyncロックをして)、すべてのディスクのスナップショットを取らねばなりません。

    私はパフォーマンスの特徴の違いを確認するために、様々なディスク設定で何度もテストをしました。

    1. 1.デフォルト10GBシステムボリュームのみで追加のディスク、すなわちdbpathは無し
    2. 2.dbpath用の、200GBの永続ディスクを加える
    3. 3.dbpath用の200GBの永続ディスク、及びジャーナル書き込み専用の200GBの永続ディスクを加える

    テスト方法

    私はコレクションに静的ドキュメントを挿入するために、Pythonの短いスクリプトを書きました。これは1000回実行されて、3回繰り返されました。このテストを完了するため、Pythonのtimeitライブラリーが使用されましたが、この資料では3回のテストサイクルの平均/標準偏差は有効ではないと示されていることから、ここでは最速の時間が採られました。

    結果 ― Google コンピュートエンジンでのMongoDBのパフォーマンス

    n1-standard-2

    結果 ― Google コンピュートエンジンでのMongoDBのパフォーマンス - n1-standard-2

    n1-highmem-8

    結果 ― Google コンピュートエンジンでのMongoDBのパフォーマンス - n1-highmem-8

    単一の永続ディスクボリュームを使用する場合には、耐久性のオプションを上げるまではパフォーマンスにあまり違いはありません。これは、確認(acknowledged)または未確認(Unacknowledge)の書き込みはメモリに行くだけだからです。書き込み確認(Write Concern)のオプションを増やすとディスクのパフォーマンスは制限されますので、ジャーナルの書き込みを別のボリュームに分離することで大きな違いが生じることは明白です。

    n1-水準-2の2コアと比較した場合、8コアの大きなn1-highmem-8のインスタンスタイプは、実際の差は小さいものの、その数字からパフォーマンスが向上していることがこの図から明らかです。 実際の差はかなり小さいとしても、実世界では役に立ちます。

    重要なポイントは耐久性がアップすると、パフォーマンスは低下するということです。それはトレードオフであると言えます。耐久性をもたせながら最高のパフォーマンスを得るには、コンピュートエンジンでより高いスペックのインスタンスタイプを選び、データベース/ジャーナルごとに別の大型の永続ディスクボリュームを利用するということです。

  4. 当社の時系列グラフを支える技術 – 一日に20億、月に30TBに及ぶドキュメント

    Leave a Comment

    Server Density(サーバーデンシティ)社は月に30TBに及ぶサーバからの受信データポイントを処理し、単純なLinuxシステムのロードアベレージから18カ国からのウェブサイトレスポンスタイムまで多岐にわたる顧客データ監視しています。これらすべてのデータはMongoDBにリアルタイムに入力され、顧客がグラフを閲覧したり、ダッシュボードのアップデートやレポート作成時に出力されます。

    当社では MongoDBを2009年半ばから使用しており これまでデータベースのスケーリングに関して多くのことを学んできました。当社は複数のMongoDBクラスタを使用していますが、本記事ではこれまでの履歴データを保存しているクラスタに注目し、当社がどのようなスケーリングを行なったかを解説致します。

    1. 専用ハードウェア及びSSDの使用

    当社のMongoDBインスタンスはすべてソフトレイヤー社の2つのデータセンターにある専用のサーバーにて処理されています。なぜならば、当社はかつて仮想化において苦い経験をしたためです。その際には、ホストに対するコントロールがないにもかかわらず、データベースはディスクI/Oのパフォーマンス保証をせねばなりませんでした。共用ストレージ(例:SAN)ではEBS上のAWSのプロビジョンIOPS (SSDに保存)などから保証されたスループットが手に入らなければ、これを実現することは難しいです。
    MongoDBはCPUに依存するオペレーションが稀であるため(通常インデックスの作成などに限られる)CPUに関するボトルネックはありませんが、問題はCPUスチール、つまりホスト上で他のゲスト同士がCPUリソースを取り合うことです。

    当社ではこの問題を解決するために専用ハードウェアに移動することで、CPUスチールの可能性やその他の妨げとなる利用者を取り除くという手法を取っています。またローカルSSDにデータベースパスを配置することで、共用ストレージを使用する際に生じる問題を回避しています。

    仮想化された、あるいは専用ハードウェアでMongoDBを管理する方法についてはMongoDBワールドで6月に詳しく解説します。

    2. 改善された同時実行性の利点により複数のデータベースを使用する

    SSDでデータベースパスを実行するのは手始めとしてはいいですが、複数のデータベースにデータを分散し、他のデータベースのジャーナルを含むそれぞれのデータベースを別々のSSDに振り分けることで、より優れたパフォーマンスを実現することができます。

    MongoDBのロッキングはデータベースレベルで行なわれるため、コレクションをそれぞれのデータベースに移動させることで分散が可能になります。これはデータの書き込みスケーリングと共に読み取りも行なう時に特に重要となります。もし同じディスク上にデータベースを保存し続ければ、ディスク自身がスループットの限界となってしまいます。このことは、それぞれのデータベースをデータベース別ディレクトリオプションを用いてそれぞれのSSDに入れることで改善されます。何台ものSSDは特にランダムな読み取りや書き込みを行う際に、IOPS数や各オペレーションのレイテンシに関連するI/Oレイテンシを軽減する点で助けとなります。これはメモリーマップデータが連続的かつシンクロ的にフラッシュされるWindows環境ではさらに顕著になります。つまり、複数のSSDがこれらの軽減に役立っていると言えます。

    ジャーナルは常にディレクトリ内にあるため、最初のステップとしてそのままSSDにマウントすることができます。書き込みはすべてジャーナルを通して行なわれ、後にディスクにフラッシュされるため、もしもジャーナルへの書き込みが成功した時に書き込み確認が返されるならば、ひとつのSSD上でこれらを行うことで書き込みがより早くなり、クエリー時間が向上します。とはいうものの、データベース別ディレクトリオプションを有効にすれば、異なる目標に対する最適化にも柔軟に対応できます。例えば、もしコストを抑えたいのであれば、あるデータベースをいくつかのSSDに、他のデータベースは異なるタイプのディスク(あるいはEBS PIOPSボリューム)に入れることもできます。

    注意すべきことは、MongoDBが作動している状態でスナップショットに基づいたファイルシステムを起動し、ジャーナルを異なるディスク(あるいは異なるファイルシステム)に移動させることは不可能であるという点です。この場合はMongoDBをシャットダウンし(さらなる書き込みを防ぐため)、スナップショットを行う必要があります。

    3. 一様分布にハッシュベースのシャーディングを使用する

    当社がモニターするすべてのアイテムは(サーバーなど)それぞれのMongoIDを持ち、このMongoIDはメトリックデータを保存するためのシャードキーとして用いられます。

    クエリーインデックスはアイテムID(例:サーバーID)、メトリックタイプ(例:ロードアベレージ)やタイムレンジにつけられていますが、すべてのクエリーがアイテムIDを持つのでシャードキーとして十分に機能します。しかしながら、重要なことは一つのアイテムIDの下にドキュメントが多すぎないことであり、多すぎた場合はジャンボチャンクとなり移動させることができなくなってしまいます。ジャンボチャンクとはデータのスプリットに失敗した状態であり、サイズをオーバーしているもののそれ以上細かく分解することができない状態を指します。

    シャードチャンクが均等に分配されるために当社ではMongoDB 2.4のハッシュドシャードキーファンクショナリティーを使用しています。ハッシュドシャードキーは均等分配に適していますが、クエリー内でハッシュドフィールドを使用しない場合、ターゲットでない分配クエリーまたは収集クエリーが使用されるため、かえってパフォーマンスを阻害してしまいます。

    4. TTLインデックスを使用してMongoDBにデータ消去をさせる

    当社のほとんどの顧客が唯一関心を持っていることは、短期間の高解析度のデータと長期間のより一般的なトレンドであるため、当社では時系列データを平均値化しオリジナルデータを消去しています。実際には、当社では実際の値と後で引出す平均値を算出するために必要な合計値/個数を構成する値をそれぞれ挿入しています。クエリー時間によって当社では平均値あるいは実際値のいずれかを読み込んでいますが、クエリーレンジが長過ぎる場合には送り返すデータポイントが多くなりすぎる恐れがあります。しかし、この方法を用いることで、バッチプロセスなしで済むので、計算を待つことなくすべてのデータをリアルタイムで提供することが可能になります。

    一定期間を過ぎたデータの消去はTTLインデックスを用いて行われています。これは高解析データがどの程度の期間必要なのかという顧客調査に基づいて設定されています。TTLインデックスをデータ消去に用いることは、バッチプロセスで消去するより効率的で、MongoDBによって正確なタイミングで行なわれます。

    多大なデータを入力及び消去することは、データ断片化の恐れが伴いますが、TTLインデクスを用いることにより自動でPowerOf2Sizesが起動して、ディスク使用をより効率的にします。MongoDB 2.6以降ではこのストレージオプションはデフォルトに設定されています。

    5. クエリー及びスキーマデザインをケアする

    無数のアップデートを行なうことで、ドキュメントが大きくなる場合には、パフォーマンスは最も落ちます。書き込み後にドキュメントサイズが大きくなると、ドキュメント全体を再び読み込み、それを異なる部分のデータファイルに新たなロケーション情報と共に書き込みする必要が生じるので、既存のドキュメントをアップデートするよりはるかに多くの時間を要します。

    従って、このような状況を避け、ネットワーク上で送信されなければならないものを最小化する適切な変更子を使って、ドキュメントがアップデートできるような、スキーマとクエリーをデザインすることが重要です。ドキュメントのアップデートの際に、やってはいけないことの一例は、アプリケーションを通してドキュメントの読み込みとアップデートをし、その後データベースに書き込むことです。それよりもむしろ、セットや消去、増分といった適切なコマンドを用いて直接ドキュメントを修正することが望ましいといえます。

    このことは同時にBSONデータタイプ及び未割当ドキュメントに注意を払うことを意味しますが、これはMongoDBスキーマデザインの落とし穴で触れた内容です。

    6. ネットワークスループット及びパケット数を考慮する

    100Mbpsのネットワークで十分であるという考えは、通常時はさておきセカンダリのレプリカセットメンバーとの再同期が必要な場合など特別なイベントの際には問題につながりかねません。

    データベースをクローンする際、MongoDBはデータ転送を迅速に行うためOplogのロールオーバー前に、可能な限り多くのネットワークを使うことになります。通常のオペレーションの際に50-60Mbpsが使用されている場合、100Mbpsネットワークでは大した余裕がなく、スループットの限界のために再同期が滞ってしまいます。

    さらにネットワークを通して行われるパケット通信量(これは重要な生スループットに限られない)にも気を配る必要があります。膨大な量のパケット通信はクオリティの低いネットワーク機器では処理しきれません。当社でも数年前に利用していたホストプロバイダーでこの問題に直面しました。結果としてパケットのロスに陥り、診断が難しくなります。

    結論

    スケーリングは増分の過程であり、すべてを解決してくれる一つの方法が存在するわけではありません。しかしながら、これらすべての微調整や最適化は1の書き込み確認での、1秒単位で何千もの書き込みオペレーションや10ミリセカンド当たりのレスポンスタイムに貢献してくれます。

    最終的には、このすべては当社の顧客が、信じられない程高速にグラフをロードできることができることを保証するものであり、 その一方で、当社はデータが素早く安全に書き込まれ、継続的にデータが大きくなるに伴ってスケーリングできることを理解しています。