ObjectRocketがMongoDBを常に正常かつ利用可能な状態に保つ仕組み

※本記事は2020年11月にObjectRocket.com/blogで公開された内容をもとに再編集したものです。

Rackspaceでは、ObjectRocketチームがお客様のMongoDB®データベースの運用管理を全面的にサポートします。災害復旧(DR)、レプリケーション、耐障害性、そして高可用性(HA)まで、MongoDBデータベースの安定稼働に必要な機能をワンストップで提供しています。

はじめに

ObjectRocketでは現在、シャーディング構成とレプリカセット構成の2種類のMongoDBインスタンスを選択できます。しかし内部では、データの冗長性と耐障害性を確保するために、常に3ノード構成のレプリカセットを使用しています。シャーディングインスタンスは、専用のmongosサーバー、コンフィグサーバー、そしてそれぞれが3ノードレプリカセットとして動作するシャード群によって構成されます。

一方、災害復旧(DR)はまた別の仕組みです。ObjectRocketでは、シャーディングおよびレプリカセット構成のMongoDBインスタンスに対して、別のデータセンターにミラーリングされたメンバーレプリカセットを追加料金で提供するDRスキームを用意しており、万一の災害発生時に備えることができます。

標準パッケージに含まれる機能

ObjectRocketの管理型MongoDBインスタンスには、高可用性、レプリケーション(データ冗長化)、耐障害性が標準でパッケージ化されています。

高可用性(HA)

高可用性(HA)により、さまざまな技術を通じていつでもデータへアクセスできます。ほぼすべてのHAソリューションにおいて鍵となるのが、データのレプリカ(複製)です。ここでデータ冗長化が重要な役割を果たします。ユーザーから見えるのは1つのデータベースだけですが、その裏側では2つ以上の完全なコピー(レプリカ)が存在しており、障害発生時にあるレプリカセットノードから別のノードへスムーズに切り替えることが可能になります。

耐障害性

耐障害性とは、同一の障害ドメイン内にあるコンポーネントに障害が発生した場合でも、システム全体が正常に動作し続けることができる特性です。ビジネス継続性を確保するため、当社ではシャードの各レプリカセットメンバーを異なるホスト(サーバー)に配置しています。これにより、1台がダウンしても他のノードが稼働を続けられます。

レプリケーション(データ冗長化)

MongoDBのレプリケーションは、アプリケーションレベルで複数のサーバー間のデータを同期させるプロセスです。レプリケーションは冗長性を提供し、異なるデータベースサーバー上に持たせた複数のデータコピーによってデータ可用性を向上させます。単一サーバーの喪失からデータベースを守り、ハードウェア障害やサービス中断からの迅速な復旧を可能にします。さらに、余分なデータコピーを災害復旧、レポーティング、バックアップなどの用途に充てることもできます。

災害復旧(DR/オプション)

災害復旧(DR)とは、自然災害や停電など、データセンターレベルの大規模な停止を引き起こしかねない重大なネガティブイベントから組織を守るための計画分野です。DRの目標は、ビジネスを可能な限り通常どおりの状態で継続させることにあります。

DRなしのユースケース

ここで、年間を通じて売上が好調で、特にサイバーマンデーやホリデーシーズンにアクセスが集中するシナリオを想定してみましょう。

アーキテクチャはどのような構成になるのか

米国拠点の企業として、データを米国内に保管したいと考えます。そこでこの例では、DFWデータセンターにデータを保存し、IADデータセンターにバックアップを保持する構成を採用します。

HAは、secondary(セカンダリ)ノードとして動作する2つのノードへデータをミラーリングすることで実現します。primary(プライマリ)に何らかの理由で障害が発生すると、secondaryの1台が新しいprimaryノードへ昇格し、さらに別のバックアップも残ったままになります。その間に、当社のサポートチームが障害の発生したノードを復旧させ、新しいprimaryと同期させます。

MongoDBは、1つのprimaryと2つのsecondaryノードからなる大規模な単一レプリカセットによって水平スケールアウトを実現できます。ノードの稼働状態(アップ/ダウン)はハートビート通信で監視され、secondaryへのレプリケーションはoplogを通じて行われます。

耐障害性については、同じデータセンター内であっても各ホストを異なるハードウェア上に配置することで実現しています。こうすることで、仮にいずれかのハードウェアに障害が発生しても、MongoDBは稼働し続けられます。

一般的に、シャードは単一のMongoDBインスタンスで構成することも可能です。しかし前述のとおり、ObjectRocketのレプリカセットは3つのMongoDBインスタンスで構成されています。以下の図をご覧ください。

シャード構成:

• DFWNODE1:PRIMARY
• DFWNODE2:SECONDARY
• DFWNODE3:SECONDARY

ObjectRocketにおけるHA・データ冗長化・耐障害性の仕組み

メンテナンス、計画停止、あるいは障害が発生した場合でも、システムはprimaryを任意のsecondaryノードと切り替えて問題なく処理を継続できるため、HAが実現します。

データはPRIMARYノードからSECONDARYノードへoplog経由で複製されるため、データ冗長化が実現します。

耐障害性については、レプリカセットメンバーの1つをホストしているサーバーが故障するという稀なシナリオを想像してみてください。primaryが落ちた場合でもsecondaryが落ちた場合でも、サポートチームが問題を解消するまでの間、MongoDBインスタンスは2ノード構成のレプリカセットとして稼働を続けます。

DRありのユースケース

当社のDRスキームでは、既存のインスタンス(インスタンスに追加されたシャードの数に関係なく)を、そのインスタンスから最も近いデータセンターの1つへミラーリングします。この例では、IADにもDRプランを設定します。IADのレプリカセットメンバーをDFW3のprimaryノードに接続し、データをリージョン間で同期的に複製することで、データが常に最新の状態に保たれます。以下の例をご覧ください。

シャード構成:

• DFWNODE1:PRIMARY
• DFWNODE2:SECONDARY
• DFWNODE3:SECONDARY
• IADNODE1:SECONDARY
• IADNODE2:SECONDARY
• IADNODE3:SECONDARY

まとめ

ObjectRocketプラットフォームでは、HA、レプリケーション、耐障害性が災害復旧(DR)と組み合わさることで、多層的なデータ保護を実現します。さらに、これらすべてを経験豊富な専門チームが24時間体制で支え、ピーク時にも安心してご利用いただける安全で安定した環境をお届けします。

Managed MongoDBについて詳しくはこちらをご覧ください。

コメントやご質問がある場合は、フィードバックタブからお気軽にお寄せください。私たちとの対話もぜひ始めてみてください。