クラウドジャーニーの一例
この企業は先進性が高く、国内の金融システムとして、いち早くクラウド活用を推進してきたと言えるでしょう。AWSの東京リージョンが開設されてまもなく、2012年から、個人情報を持たないシステムを対象としてクラウド上でのサービス提供を開始しました。そこで実用性や統制面での機能の充実度などを確認した後、2017年からは「クラウドファースト」を掲げ、2020年にはほぼすべてのシステムのクラウド移行を完了しました。
2023年にはマルチリージョン化を行い、現在はクラウドネイティブなシステムとするためのマイクロサービス化を推進しており、今後はマルチクラウド化も視野に入れています。特定のクラウドで企業全体の習熟度を向上させたのちに、マルチクラウドを検討している段階となります。今後、同様に習熟度を向上させた企業がマルチクラウドを検討する機会は増えていくと考えられます。
また、メインフレームを利用しているシステムや大規模な基幹システムについて、これまでクラウド活用を見送っていた企業においてもクラウドへの移行を検討、推進しています。
多数の企業が基幹システムのクラウド移行を実現した実績があること、クラウドベンダーからメインフレームのクラウド移行を支援するメインフレームモダナイゼーションと呼ばれるサービスが提供されていることも後押しとなっているでしょう。これらの企業がまずはシングルクラウドへの移行を完了させたのち、マルチクラウドを検討していくことも考えられます。
マルチクラウドの導入を推進する要因
次に、企業がマルチクラウドの導入を推進する要因について考えます。要因としては、大きく分けてビジネス上の課題、技術的な課題の2つが考えられるでしょう。
それぞれの要因について、マルチクラウドを推進する理由、その概要を次表にまとめます。
その他、海外では、活発な企業の合併・買収（M＆A）によりマルチクラウド運用となるケースも多いようです。これは複数のサービスを買収したことによる望ましくない副作用となっているケースもあり、長期的に特定のクラウドベンダーへの統合が計画、推進されることもあるでしょう。
交渉力を得るためのマルチクラウド
複数クラウドで事業展開を行っている大企業でよく聞かれるのが、クラウドベンダーとの交渉力を獲得するためのマルチクラウド戦略です。
これはクラウド以前からベンダーとやり取りをしている企業にはなじみ深い考えだと思いますが、簡単に言えばベンダーAとベンダーBを競わせるやり方です。例えば、利用者がすべてのシステムをA社のクラウド上に構築する場合、利用者はA社にロックインされ、移行の手間などを考えるとコストなどの観点で優位であっても他のクラウドに移れません。そのため、例えばデータベースサービスのコストに不満があっても、ディスカウントを要望するのは難しくなります。
一方、利用者がA社とB社にシステムを展開している場合、新規システムの構築や既存システムの移行等を他方のクラウドにすることを前提に、クラウドベンダーと交渉をできます。A社のデータベースサービスはコストなどの観点で採用が厳しいと伝えることで、何らかのディスカウントプログラムや支援プログラムなどを得る可能性もあります。
もちろん、こうした話は一定以上の規模でないとクラウドベンダーにうま味がない点や、ボリュームディスカウントを交渉材料とした方が良いケースもありますので、マルチクラウドの最大目的ではなく、そのプロセスの一部と考えるのが妥当です。
シングルクラウドでの可用性の向上
では、技術的な課題であるマルチクラウドとすることでの可用性の向上（複数のクラウドを利用したシステム分散）について考えます。ただし、1つのクラウド利用でも、可用性を向上するための分散配置構成は可能となります。まずは、1つのクラウド利用において高可用性を実現しているリージョンやアベイラビリティゾーン（データセンターを抽象化した概念。各クラウドで名称は異なりますが、本書では共通した概念として紹介する場合、AZ（Availability Zone）と表記します）について紹介します。
リージョン
クラウドは、世界中の多数のデータセンターを利用して提供されています。クラウドで共通している用語としてリージョンがあり、リージョンは、クラウドがサービスを提供している拠点（国と地域）を指します。日本では、各クラウドから次の名称のリージョンが提供されています。
リージョン同士は、それぞれが地理的に離れた場所へ配置され、完全に独立しています。なお、AWSやGoogle Cloud、OCIは東京（Tokyo）や大阪（Osaka）という都道府県名が含まれていますが、関東圏や関西圏を利用して、リージョン内でも広域に分散配置されている複数のデータセンター群で構成されています。
AZ
これらのデータセンター群はリージョンの中にある論理的な区分となり、実態はデータセンターを抽象化した概念となりますが、各クラウドでは異なる名称となっており、AWSではAZ（Availability Zone）、Azureでは可用性ゾーン、Google Cloudではゾーン、OCIでは可用性ドメイン（Availability Domains）と呼ばれています。クラウドベンダーやリージョンによっても異なりますが、1つのリージョンには1つ以上のAZが存在します。また、1つのAZは1つ以上の近接したデータセンター群で構成されています。つまり、1つ以上のデータセンター群がAZを構成し、複数のAZが集まったものがリージョンとなります。
AZについては、地理的な分離のみではなく、電源の系統も分離されており、一カ所の停電によりAZ内のすべてのデータセンター群が一斉にダウンしないように設計されています。複数のAZの地理的・電源的独立により、1つのリージョンであっても、障害への耐久性、信頼性が高くなっており、2つ以上のAZを利用することで冗長構成を組むことができます。
単一のAZのみでシステムを構築していた場合、オンプレミスの単体のデータセンターでシステムを構築していた場合と耐障害性は変わりません。耐障害性を高めてシステム全体の可用性を高めるには、複数のAZを利用してシステムを構築する必要があります。
複数のAZにサーバー、データベースなどをあらかじめ冗長化し配置しておくことで、耐障害性や可用性を確保できます。停電や地震等の災害の影響で1つのAZが停止しても、リージョン内の別のAZでサービス提供を継続できます。このような冗長構成は、マルチAZ構成と呼ばれます。次の図は、AWSにおいて、アプリケーションサーバー、データベースを利用するシステムをマルチAZ構成にする場合の基本的な構成です。ロードバランサーから2 台のアプリケーションサーバーに負荷分散し、AZ間で冗長化・データ同期されたデータベースにアクセスする構成になります。どちらかのAZで障害が発生しても、もう一方のAZでサービス提供を継続します。なお、データベースについては、書き込み可能なプライマリのAZのデータベースに障害が発生した場合は、セカンダリのデータベースがプライマリに昇格するように設計、実装します。データベースは、AWSが提供する機能によりAZをまたいでデータ同期が行われます。
なお、AZ内でも可用性を向上させる分散配置が可能です。例として、OCIは可用性ドメイン（Availability Domains）の中に複数のフォルト・ドメイン（FD）が含まれています。FDとは、可用性ドメイン内のハードウェアおよびインフラストラクチャをグループ化し分離したものです。FDではアンチアフィニティ（特定の仮想マシンが常に異なるホストで実行される必要があること）が提供されており、単一の可用性ドメイン内でインスタンスが同じ物理ハードウェア上に存在しないように分散できます。1つのFDに影響するハードウェア障害やメンテナンスは、ほかのFD内のインスタンスに影響しないため、複数のFDに分散配置させることで、システム全体の可用性を向上させることができます。
なお、OCIのFDに類似したAZ内での分散配置機能は、AWSではパーティションプレイスメントグループまたはスプレッドプレイスメントグループ、Azureでは可用性セットと呼ばれる機能で提供されています。
また、リージョン間は各クラウドのバックボーンネットワークで、高帯域幅で接続されています。これにより、複数のリージョンにまたがってグローバルにアプリケーションを提供することも可能になっています。
VPCとサブネット
なお、リージョン、AZと関連する用語として、VPC（Virtual Private Cloud）とサブネットがあります。VPCとは、「パブリッククラウド内の特定の場所（リージョン、アベイラビリティーゾーン）において、サービス契約者のリソースに契約者自身だけがアクセスできるようにするための仮想的なネットワーク区画を区切るサービス」のことです。論理的に分離された区画となるため、ほかのVPCやサービスと接続していない限り、ほかの利用者からは分断され、独立して利用できる区画となります。AWSとGoogle CloudではVPC、AzureではVNET（Virtual Network）、OCIではVCN（Virtual Cloud Networks）と呼ばれており、名称は異なっています。
サブネットとは、IP アドレス範囲（CIDR ブロック）が割り当てられたネットワーク区画を区切るサービスです。1つのVPCは、複数の「サブネット」というネットワーク区画で構成されます。VPCは、大きな用途単位（業務サービス用途、運用管理用途など）で分離し、VPC内のネットワーク要件（インターネットと直接接続するか、サーバー種別など）の違いをサブネット単位で区切って制御するケースに利用します。
AWSでは、リージョンの中にVPCが存在して、AZの中にサブネットが存在します。
Azureでは、リージョンの中にVNETとサブネットが存在します。AWSとは異なり、サブネットは可用性ゾーンをまたいで作成できます。
Google Cloudは、VPCがグローバルな存在となり、全世界のリージョンをまたいでVPCを作成できます。リージョンの中にサブネットがあり、サブネットはAzureと同様にゾーンをまたいで作成できます。ただし、リージョンをまたいでサブネットを作成することはできません。
Google Cloudの大きな特徴として、複数の国や地域向けにグローバルなサービス提供をする場合に、複数リージョンを利用しながら1つのVPCで対応できる点があります。ロードバランサーの配下に複数リージョンのサーバーを配置して、グローバルにリクエストを分散させることが可能です。
OCIでは、リージョンの中にVCNが存在しています。サブネットは、可用性ドメイン（Availability Domains）に固有のもの、また可用性ドメイン（Availability Domains）をまたいだもの（リージョナル・サブネット）が作成可能です。なお、可用性ドメイン（Availability Domains）の障害を考慮したリージョナル・サブネットが推奨されています。
AWS、Azure、Google Cloud、OCIそれぞれの構成は次のようになります。複数リージョンを利用する場合は、AWS、Azure、OCIについてはリージョン単位でVPCやVNET、VCNを追加します。Google Cloudについては、VPC内にリージョンを追加します。リージョン内でサブネットを追加する点はどのクラウドサービスでも共通となります。
クラウド障害の過去事例
クラウドサービスはリージョン、AZごとに独立してサービス提供されています。ただし、1つのクラウドでシステムを運用している場合、過去事例から見ても、大規模な障害により、一時的に特定のクラウド上で運用するサービスが提供できなくなったことがあります。
AZ単位の障害
2019年8月に発生したAWSの障害は、AWSの東京リージョン内の1つのデータセンター（AZ）で、AZ内の制御システムに問題が発生し、複数の要因により冗長化された冷却システムに障害が発生しました。それによってAZ内の一部のサーバー区画の温度が上昇した結果、サーバーの電源が停止するなど、同一AZ内のRDS、ほかのサービスのパフォーマンス劣化なども発生しました。1つのAZの障害ではありましたが、そのAZを利用しているシステムにおいては、完全な復旧までに少なくとも6時間程度の時間を要しました。
リージョン単位の障害
2021年9月に発生したAWSの障害は、東京リージョンのすべてのAZへ影響するものでした。AWSの管理するネットワークデバイスの潜在的なバグにより、東京リージョンに至るDirect Connect（閉域ネットワーク接続サービス）が約5時間にわたって不通となり、東京リージョンをマルチAZで利用していた場合でも、東京リージョンを利用するさまざまな企業や組織のITシステムに障害が発生した、というものです。障害発生当時、AWSからはDirect Connectではなく、VPN接続に切り替えることで障害を迂回できると発表されましたが、Direct Connectと比較すると帯域や品質、安定性が劣るVPNを構築している、またはしなければならない、手動で切り替えなければならないことから、多くの利用者は対応できませんでした。
ただし、この障害は大阪リージョンには影響がありませんでした。東京リージョンに加えて、大阪リージョンを利用するマルチリージョン構成であれば、大阪リージョンに切り替えることでサービス提供は継続できたでしょう。
なお、後日Transit Gatewayと呼ばれるサービスをマルチリージョン構成とし、同様の事象発生時に閉域ネットワークを利用する構成で迂回させることで、東京リージョンを利用したサービス継続も可能となる、と発表されました。この迂回構成の詳細についてはコラムで紹介します。
マルチリージョンでの迂回
2021年9月に発生したAWSの障害は、東京リージョンのすべてのAZへ影響するものでした。ただし、障害箇所は東京リージョン全域のDirect Connectであったものの、ほかの東京リージョン内のサービス（EC2やRDSなど）は正常に稼働しており利用が可能でした。また、Direct Connectを利用していないシステムには影響がないものでした。
本障害への対策として、Transit Gatewayと呼ばれるサービスをマルチリージョン構成とし、同様の事象発生時に閉域ネットワークを利用する構成で迂回（東京リージョンのDirect Connectを経由させないように）させることで、東京リージョンを利用したサービス継続も可能となります。
概要構成を紹介します。Transit Gateway（TGW）はマルチリージョン構成となり、専用線接続サービスであるDirect Connectは、リージョンに紐づかないグローバルサービスとなるDirect Connect Gateway（DXGW）を利用します。
Transit Gatewayはリージョン間を接続するInter-Region Peeringを使って、東京リージョン-大阪リージョン間の迂回経路を構成しています。Inter-Region Peeringについては、通常時は東京リージョンと大阪リージョンを接続するリージョン間通信経路としても利用可能です。
本障害は、東京リージョンに至るDirect Connect全域が障害箇所でした。そのため、Direct Connect Gatewayから大阪リージョンTransit Gatewayを迂回して東京リージョンへ到達させることで、東京リージョンのDirect Connectを経由することなく、専用線、東京リージョンを利用したままサービス提供を継続できます。
なお、大阪リージョンを経由させることになりますので、レイテンシーが発生します（筆者が構築した環境では、通常時は4-5msであったレイテンシーが、迂回後は20ms程度に上昇しました）。また、Transit Gatewayの障害を考慮する必要もあると考えられます。
クラウドベンダー単位の障害
2023年1月に発生したMicrosoftのネットワーク障害は、影響範囲が全世界に波及しうるものでした。原因はWAN（ネットワーク）の保守作業を行った際に、設定変更を予定していた機器のみではなく、WAN内のすべての機器に対してコマンドが送信されたことで、WAN内のすべての機器でルーティングに必要な情報の再計算が引き起こされたことによるものと発表されています。結果、Azureの一部サービスへのアクセスや、Microsoft 365、Microsoft Teamsなどが約5時間以上利用できなくなりました。
この障害は、マルチリージョン構成であっても回避できないAzure全体に影響するものでした。
その他にも、世界全体でみると、各クラウドベンダーで大なり小なりの障害は発生しています。2023年4月には、Google Cloudのパリリージョンにおいて、冷却システムのポンプが故障した結果、バッテリールームが浸水し、火災にまで至った障害が発生しており、本障害の完全な復旧には数週間を要する大規模な障害となりました。障害が発生していないクラウドベンダーはありません。落雷などの災害によるもの、電源障害などの設備故障によるもの、ヒューマンエラー（設計の不具合や運用、手順誤り）によるシステム障害など、原因は多岐にわたり障害をゼロにすることはできないということを裏付けています。また、マルチAZやマルチリージョン構成に分散していても、集中し共通する箇所は存在しており、あるクラウドの全リージョンが影響範囲となる障害が存在することが明らかになりました。
クラウドベンダー単位による障害は、企業や組織のITシステムが1つのクラウドサービスに依存することに対して、どのようなリスクマネジメントに取り組むのかを問いかけています。このリスクを低減する対応策の1つが、「マルチクラウド」であると考えられます。
マルチクラウドでの機能分散
なお、複数のクラウドの機能を利用したい、またはデファクトスタンダードが存在しない機能であるため、複数のクラウドを比較評価しながら選定したいという要望もあります。執筆時点で、最も活況であるのは生成AIのサービスでしょう。実際に、AWS、Azure、Google Cloudの3つのサービスから成るマルチクラウド環境を利用している企業もあります。
また、サービスを提供するプラットフォームはAWSやAzureを利用しつつ、データ分析プラットフォームはGoogle Cloudを利用している企業もあります。サービス提供で利用する業務データベースとは別のクラウドのデータベースを活用して分析用の環境を利用する構成となります。各クラウドの提供するサービスのメリットを見極め、良い部分を組み合わせてマルチクラウドでの運用を選択したケースと言えるでしょう。
まとめ
マルチクラウドについては、気づいたら企業内で複数のクラウドを利用していたというケースもあります。このようなケースについては、ガバナンスが効いておらず、いわゆるカオスな状態であったり、シャドーIT（企業・組織側が把握せずに利用されているクラウドサービスなど）となっていたりすることも多いでしょう。
シングルクラウドのベンダーロックイン回避、コストや技術的な課題に対する対策、機能ごとの使い分け、ワークロードの分散などの要件に合わせて、計画的、発展的、戦略的にマルチクラウドを推進していくことが望まれるでしょう。
マルチクラウドデータベースの教科書 クラウドロックインを乗り越えるデータベース構築ノウハウ
朝日英彦、小林隆浩、矢野純平 著
出版社：翔泳社
発売日：2024年8月6日
価格：3,740円（税込）
本書について
マルチクラウドにおける、現代的なデータベース構築・設計を解説する書籍です。4大クラウド（AWS, Microsoft Azure, Google Cloud, Olacle Cloud Infrastructure）のDBaaSの解説はもちろん、データベースの観点からマルチクラウドの優位性や課題を紹介します。
本書の特徴
- マルチクラウドジャーニーを徹底解説：データベースという視点から一段登って、システム全体を俯瞰してマルチクラウドを推進する際に必要な点を整理しています
- DBaaSを網羅的に紹介：発行時点でのDBaaSの特徴を保存したスナップショットとして、クラウド選定時やDBaaS選定時に活用いただけます
- マルチクラウドで利用可能なDBaaS、その構成パターンを紹介：現時点で採用可能な構成パターンを本書にまとめました。マルチクラウドデータベースのもたらす価値も丁寧にまとめています
