マルチクラウドによるDR構成で落ちないシステムを目指す

マルチクラウドが求められる背景

マルチクラウドが求められる背景には、主に以下に挙げるニーズがあります。

• 単独で要件を満たすクラウドがなかった
• ベンダーロックインを回避したい
• 大規模障害時のリスク分散

それぞれのニーズごとの利用シーンの詳細を以下で解説します。なお、マルチクラウドのメリット・デメリットについては、「マルチクラウドとは」をあわせてご確認ください。

単独で要件を満たすクラウドがなかった

クラウドサービスは、ベンダーごとに提供される機能・品質・価格などがそれぞれ異なります。そのため、単一のベンダーでは、システムに必要な機能がない・要求される品質が達成できない・コストに見合わないといった問題が生じる可能性があります。しかし、複数のベンダーのサービスを組み合わせ適材適所に配置できれば、それぞれのサービスの特長を生かして要件を満たせる可能性が出てきます。

例えば、エンタープライズの基幹システムでは、SLAで高可用性を保証しているだけでなく、日本語でのサポートも受けやすい国内のクラウドベンダーを採用し、開発環境やビッグデータの分析や処理などを行う大容量ストレージなどでは、安価に利用できる海外のクラウドベンダーを採用するといった使い分けが考えられます。

ベンダーロックインを回避したい

クラウドベンダーに限らずですが、サービスはいつまでも同じものが同じ価格で提供されるとは限りません。提供されるサービス内容が変化したり、サービスが値上げされることもあるでしょう。こうなると場合によっては、利用するベンダーを変更したくなるかもしれません。しかし、システムが特定のベンダー固有の機能に強く依存していると、別のベンダーのサービスへの乗り換えは困難となってしまいます。これにより「ベンダーロックイン」と呼ばれる、最初に選択したベンダーに縛られる現象が発生してしまいます。

マルチクラウド化のメリットの1つは、特定のベンダーに依存せず、あらかじめ異なるベンダーのサービスを横断することを前提にシステムを構築することで、ベンダーロックインを回避できる点です。

ですが、クラウドベンダーによっては、異なるアーキテクチャーのプラットフォームを採用していることも珍しくありません。そのため、マルチクラウドでアプリケーション（以下アプリ）を動かそうとすると、アプリを異なるアーキテクチャで動作させるための改修コストが発生してしまいます。これはかかるコストに対してメリットが見合わないと判断されることも多く、マルチクラウド化が見送られる原因となっていました。

しかし、近年では、コンテナ技術の普及とともにこの状況が変化しつつあります。コンテナとは、アプリの実行環境をカプセル化して、ポータビリティを高められる技術です。コンテナ化によって、環境を跨いでアプリを自由に「持ち運ぶ」ことが可能になり、異なる環境へのデプロイも従来よりも格段に行いやすくなっているのです。

最近では、多くのクラウドベンダーがコンテナオーケストレーションシステムである「Kubernetes」をマネージドサービスとして提供し始めており、ポータビリティの高い共通アプリケーションプラットフォームとして普及してきています。それに加えて、Googleをはじめ、Microsoft、Red Hatなどの複数のベンダーがマルチクラウドに対応した統合管理ソリューションをリリースしていることも、よりマルチクラウドの実現性を高めていると言えるでしょう。

ただし、これはあくまでアプリがコンテナ化されているのが前提の話です。従来のようにアプリが仮想マシン上に直接デプロイされているようなシステムでは、前述の改修コストの問題が発生します。そのため、こうしたシステムではベンダーロックインの回避のみを目的としてマルチクラウドを選択するのは、かかるコストに比べて得られるメリットは少ないでしょう。

大規模障害発生時のリスク分散

近年は、日本でも政府公共機関や金融機関・決済システムなどの基盤として、メガクラウドを中心にクラウドの利用が拡大しています。しかし、それはクラウドサービスに大規模な障害が発生した時には、公共性の高い社会インフラと言えるサービスが長時間停止するといった問題にも繋がります。

そこで、リスク分散としてマルチクラウドによるDRが注目されています。具体的には、複数の海外のクラウドを組み合わせたり、海外のクラウドと国内のクラウドを組み合わせるといったマルチクラウドを選択するニーズが高まってきています。

とはいえ、実際にマルチクラウドによるDRを実現するには、いくつか考慮しなければならない問題があります。まずは、ベンダーロックインの回避の項で説明したように異なるアーキテクチャ上でアプリを動かせる必要があります。これには、前述の通りアプリをコンテナ化してポータビリティを高めるといった工夫が必要となるでしょう。ニフクラでもこうしたニーズに応えるために、Certified Kubernetes認定され、Kubernetesの標準に準拠したマネージドKubernetesサービス「Kubernetes Service Hatoba」を提供しています。

また、単に複数のクラウド上でアプリを動かせるだけでは不十分です。DRを実現するには、迅速に本番環境と待機環境を切り替えられるネットワーク構成も重要となります。インターネットを経由して通信する場合であれば、拠点間VPNなどを用いて、それぞれのクラウドサービス同士を疎通させる必要があるでしょう。「AWS Client VPNとニフクラ拠点間VPNゲートウェイ(IPsec-VTI)を組み合わせたマルチクラウド構成を組んでみた」では、AWS環境とニフクラ環境を、ニフクラの拠点間VPNゲートウェイを使って接続する構成を解説していますので、こちらもあわせてご確認ください。それ以外の方法としては、コストは高くなるものの閉域網・専用線を使用してセキュアかつパフォーマンスの高いマルチクラウドを構築する方法も考えられます。「プライベートアクセス for Equinix Cloud Exchange™」を使えば、インターネットを経由せずにEquinix Cloud Exchange™網内を経由して、ニフクラと他社クラウド、あるいはオンプレミスを接続できます。

マルチクラウドとクラウドネイティブ

マルチクラウドに対応したKubernetesクラスタの統合管理機能が、複数のベンダーから提供されているのは先に述べた通りです。こうした機能を利用すれば、パブリッククラウドのみならず、オンプレミスやエッジも含めたハイブリッドクラウド環境に展開したKubernetesクラスタをも管理しやすくなります。しかし、こうした例からも解るように、現在のIT環境は高機能化すると同時に高度に複雑化しています。このような環境下でアプリのビルドやデプロイを迅速かつ確実に行うためには、人の手による管理では不可能と言ってよいでしょう。

そこで、必須となるのが人の手を介さない「自動化」です。開発・運用スタイルとしてDevOpsを導入したり、技術面では、アプリのマイクロサービス化やコンテナ・オーケストレーションツールの採用、開発プロセスの自動化など、いわゆるクラウドネイティブなシステムの活用が求められています。クラウドネイティブなシステムを構成する具体的な用途については、「クラウドネイティブとは？ クラウドファーストとの違いやポイントを解説」の記事もあわせてご確認ください。