5-1-4 現実的なクロスクラウドの選択肢
前のセクションではマルチクラウドなデータベースでも、難度が高く、多くのベンダーでサービス化が実現していないクロスクラウドの構成について、NewSQLがもたらす新たな可能性に言及しました。
ここでは先ほど紹介したNewSQLの可用性構成パターンをベースに、クロスクラウドなDBaaSが現実的にどのような構成を取りうるかについて、いくつかの種類に分けて解説していきます。この分類にはクロスクラウドという軸に加えて、リージョンの概念を追加します。つまり、次の2つに大きく分かれます。
- シングルリージョン＋クロスクラウド
- マルチリージョン＋クロスクラウド
それぞれの構成で推奨される可用性構成パターンについて、解説をしていきます。
シングルリージョン＋クロスクラウド
まず、クロスクラウドの構成で考えられるのが、シングルリージョンにデータベースクラスターがすべて収まる構成です。シングルクラウドの節で見たように、同一リージョン内のマルチデータセンター間では同期レプリケーションが多く使われます。これにより、障害時にもデータ消失が発生しないという大きなメリットを享受できます。
これをクロスクラウドに拡張した場合も基本的な考え方は同様で、クラウド間をつなぐ低レイテンシーな閉域ネットワーク接続（1-5ms程度のレイテンシー）を活かして、同期レプリケーションを構成します。ここで、クロスクラウドで利用するクラウドベンダーを2つにするのか3つにするのか、それぞれにいくつのノードを配置するかは重要な検討ポイントとなります。
まず、シングルリージョン＋クロスクラウドでクラウドベンダーは2社である場合について考えてみましょう。NewSQLの仕組みとして説明したように、データベースクラスターに必要なノード数は最小3の奇数台です。この場合、メインとなるクラウドベンダーに2つ（過半数）のノードを配置し、スタンバイに残り1つを配置します。同一のリージョン内で異なるクラウド間を高速に接続する閉域ネットワーク接続が利用できる場合には現実的な構成です。
この構成のメリットは、通常時はメインとなるクラウド内の合意で高速に処理が進み、クラウド障害に備えてデータの複製もされる点です。そして、1台のノード障害時ではメインからサブへクラウドの切り替えも発生しません（DB②がLeaderとなる場合）。
一方、デメリットとして、メインクラウドの障害時にはデータベースの稼働に必要なノード数が確保できません。メインクラウドが全く使えない場合にはデータベースクラスターを再構成する必要があります。
シングルリージョン＋クロスクラウドでベンダー2社のケースでは、データ消失の発生を許容し、障害復旧時間を短縮するために非同期クラスターレプリケーションを用いることは次善の選択肢です。つまり、メインとサブのクラウドに1つずつ独立したデータベースクラスター（最低3ノード）を配置することになります。
また、障害復旧時間はある程度長くても許される場合には、シングルリージョンであっても別クラウドにリードレプリカを配置して、データの退避のみを行うという考え方もあります。
データ消失もなし、障害復旧時間も最短で考える場合に有力な選択肢は、シングルリージョン＋クロスクラウドの構成でクラウドベンダーを3社にするパターンです。この場合、クラウドベンダーに2つまたは1つのノードを配置して、最低5台でデータの複製を行います。
ここでクラウドベンダーが2社から3社に増えると、なぜ合計ノード数が3台から5台になるのか、不思議に思うかも知れません。これはノード1台で障害が発生した際にメインからサブのクラウド切り替えが発生してしまうことを防止するためです。例えば、DB①が障害となった場合、DB②がLeaderとなることで、クラウド1からクラウド2や3への切り替えは不要になります。
こちらの構成は、シングルクラウドのグローバルデータベース例として紹介したGoogleのCloud Spannerのマルチリージョンによく似た構成となります。特性も同様で、クラウドベンダー2社のパターンと比較して常にクラウド間の合意を待つためにレイテンシーは劣化しますが、可用性は向上します。この構成を取る場合、単一のクラウドベンダー障害はデータベースの稼働に影響を与えません。
マルチリージョン＋クロスクラウド
クロスクラウドで考えられるもう1つの構成が、マルチリージョンかつクロスクラウドというデータベース構成です。
この場合、クラウド間のレイテンシーは構成決定の主因ではなく、リージョン間のレイテンシーの影響が大きくなります。そのため、マルチリージョンでよく採用される非同期クラスターレプリケーションが有用な選択肢となります。
メインクラウド（メインリージョン）にプライマリのデータベースクラスターを配置し、別クラウド（サブリージョン）のクラスターに非同期でデータを更新します。この場合、クラウドベンダーは最低限の2社で十分で、3社に分散しても可用性向上には余り寄与しません。クラウド間で非同期レプリケーションを用いることから、シングルクラウドのグローバルデータベースのケースと同様に、データ消失が発生する可能性はあります。しかし、クラウド／リージョン間のレイテンシーがパフォーマンスに影響を与えないため、バランスの取れた構成と言えます。
次善の選択肢となるのは、マルチリージョン＋クロスクラウドでもストレッチクラスターを採用する構成です。リージョン間のレイテンシーがパフォーマンスに与える影響を許容でき、加えて構成には3つのリージョンを準備する必要があります。次に紹介するのは、3つのクラウドベンダーと3つのリージョンに2つまたは1つのノードを配置する構成です。
ここで全体のノード数が3台から5台に増えているのは、シングルリージョン＋クロスクラウドの項での説明と同様の理由になります。
この構成ではクラウドベンダーの障害も、1リージョンが全断する広域災害でもデータベースの稼働が可能です。しかし、合意に必要な通信が必ずクラウドとリージョンをまたぐため、レイテンシーがパフォーマンスに与える影響は大きくなります。可用性を非常に重視するパターンで採用に値する構成です。
なお、ここまでで説明したシングルリージョン＋クロスクラウド、マルチリージョン＋クロスクラウドの構成は、執筆時点で存在するDBaaSでは実現されていません。しかし、ベンダーが今後発表する新しい可用性構成オプションを評価する際に有用な指標となりますので、現時点で検討を行うことは無駄にはなりません。
クロスクラウドを実現しているMongoDB Atlas
今回はリレーショナルデータベースを中心に紹介してきましたが、ドキュメント型データベースMongoDBを利用可能なDBaaSであるMongoDB Atlasは、すでにクロスクラウドを実現している珍しいサービスです。
データの一貫性に関する考え方等に違いはありますが、リレーショナルデータベース同様に、MongoDBでも可用性やスケーリングの仕組みにおいてレプリケーションやシャーディングが取り入れられています。
MongoDB AtlasはAWS、Azure、Google Cloudでサービスを提供しており、サーバレスにも対応するなど、さまざまな利用者からの要求に応えています。そして、当書籍で言及しているマルチクラウド観点でも、次のような冗長化オプションから可用性要件に応じて柔軟な構成を選ぶことができます。
- アベイラビリティゾーン間の冗長性
- クラウドリージョン間の冗長性
- クラウドプロバイダー間の冗長性
マルチリージョンとマルチクラウドの組み合わせでも構成可能で、先述したシングルクラウド＋クロスクラウドやマルチクラウド＋クロスクラウドのように、クラウド障害に耐える高い可用性とグローバルなビジネス展開の両側面に対応しています。
NoSQLのDBaaSからクロスクラウドの利便性が利用者に広まり、リレーショナルデータベースにおいてもそうした機能が展開される日はそう遠くないのかも知れません。
クロスクラウド構成の注意点
ここまでクロスクラウドを「クラウド障害に対応した高い可用性」を実現するものとして、メリットばかりを紹介してきましたが、ほかの技術がそうであるようにすべての人がデメリットなく取り入れられる構成ではありません。
まず、考えられるクロスクラウドのデメリットはコストの増大です。Chapter2で紹介したように、現在のクラウドの料金体系ではアウトバウンド通信にコストが掛かります。異なるAZやリージョンへの通信にもコストが掛かるケースがありますので、そちらも利用するクラウドの料金体系を確認してください。
とくにレイテンシーを小さくするために、ここまでの構成ではインターコネクト（閉域ネットワーク接続）を利用することを推奨してきましたが、この場合は通信料金が最も高額になります。クロスクラウドの構成を取るにあたって、通信料金はデータベースのノード間で同期されるデータ量に大きく依存します。データ保護の観点からは遅延を許容して、更新をまとめて同期することもできません。
このコストを下げるために現状で可能なことは、このChapterで何度か説明しているWitnessノードの利用です。クロスクラウドの構成でもWitnessノードが配置されたクラウドにデータを送る必要はなく、その分のコスト削減が可能です。
ただし、執筆時点でWitnessノードを利用可能なデータベースはGoogle Cloud SpannerやEDB Postgres Distributedなどに限定されており、クロスクラウドに展開したいNewSQLの多くで実装されていません。
もう1つ考えられるクロスクラウドのデメリットは、データベースのセキュリティです。セキュリティの観点では、クロスクラウドの構成を取る場合にクラウド間接続の経路安全性について慎重に検討する必要があります。通信の傍受のリスクも高まりますし、ノード間のレプリケーションで暗号化通信が行われているかも確認すべきポイントです。
また、複数のクラウドを利用するにあたって、権限付与などのアカウントに関する設定が異なっている場合があります。一方のクラウドでは適切な権限が与えられているアカウントしかデータが見えない状態になっていても、クロスクラウドで複製されている別のクラウドで同様の制御ができているかは、利用者の責任で確認すべき事項となります。
マルチクラウドは万人のものか？
コストの増加とセキュリティ以外にも、運用の煩雑さなどクロスクラウドのデメリットはいろいろと考えられます。そこで読者は次のような疑問を抱くはずです。
- 「マルチクラウドは誰にでも必要になるのか？」
- 「マルチクラウドは自分の会社に必要なのか？」
筆者は「現時点で必要な企業は限られるが、備えておくべき」だと考えています。
データベースに限らず多くの技術がそうであったように、登場してすぐに利用に踏み切る企業は多くありません。しかし、当該技術の発展により導入の敷居が下がり、気づくと一般化している事例はこれまでにも多くありました。
NewSQLもこのような発展が現在進行形で続いています。
筆者も数年前には「NewSQLって数ペタバイトの巨大なデータを持つ、グローバルな企業が使うものでしょう？」という質問を受けました。その際に、「備えておくべき技術です。データベースの移行はビジネス拡大後に行うにはリスクが高く、当初からscale-out readyなデータベースを評価しておくことには価値があります」と回答していましたが、2023年には実際にNewSQLの導入や検証を行う企業が増加し、当時考えていた未来は実現しつつあります。
同じことはマルチクラウドにも言えます。現在、重要なシステムのデータベースでマルチデータセンターの構成を取らない利用者はほとんどいないと思いますが、技術の進展やコスト体系の変化などに後押しされて、同様の意識の変化がマルチクラウドに訪れる可能性はあります。
マルチクラウドデータベースの教科書 クラウドロックインを乗り越えるデータベース構築ノウハウ
朝日英彦、小林隆浩、矢野純平 著
出版社：翔泳社
発売日：2024年8月6日
価格：3,740円（税込）
本書について
マルチクラウドにおける、現代的なデータベース構築・設計を解説する書籍です。4大クラウド（AWS, Microsoft Azure, Google Cloud, Olacle Cloud Infrastructure）のDBaaSの解説はもちろん、データベースの観点からマルチクラウドの優位性や課題を紹介します。
本書の特徴
- マルチクラウドジャーニーを徹底解説：データベースという視点から一段登って、システム全体を俯瞰してマルチクラウドを推進する際に必要な点を整理しています
- DBaaSを網羅的に紹介：発行時点でのDBaaSの特徴を保存したスナップショットとして、クラウド選定時やDBaaS選定時に活用いただけます
- マルチクラウドで利用可能なDBaaS、その構成パターンを紹介：現時点で採用可能な構成パターンを本書にまとめました。マルチクラウドデータベースのもたらす価値も丁寧にまとめています
