マルチクラウドは必要か。利点と、運用が重くなる点

マルチクラウドとは、AWS・Microsoft Azure・Google Cloud など、複数のクラウドの事業者を用途ごとに使い分ける構成です。特定の事業者に頼りすぎない、各社の得意な機能を使える、といった利点がある一方で、運用の手間と担当者に求める知識は増えます。

「複数を使うほうが安全そう」という印象だけで始めると、運用が追いつかなくなることがあります。この記事では、マルチクラウドの利点と、運用が重くなる点を整理し、必要かどうかの判断の仕方を説明します。

マルチクラウドとは

マルチクラウドは、複数の事業者のクラウドを、同時に使う構成です。似た言葉のハイブリッドクラウドは、クラウドと自社のサーバー（オンプレミス）を組み合わせる構成を指します。

マルチクラウドには、用途ごとに使うクラウドを分ける形（ある業務のシステムは AWS、データ分析は Google Cloud、など）と、同じシステムを複数のクラウドに置いて障害に備える形があります。Google Cloud の設計の指針も、ハイブリッド・マルチクラウドの構成を、システムの部品を環境ごとに分けて置く「分散」の型と、同じシステムを複数の環境に置く「冗長」の型に分けて整理しています。

出典：Hybrid and multicloud architecture patterns（Google Cloud）

マルチクラウドを採る理由

マルチクラウドを採る理由は、事業の面と技術の面の両方にあります。

Google Cloud は、ハイブリッド・マルチクラウドを採る主な理由として、次のようなものを挙げています。

• 国や地域のデータの保存場所の決まりに対応する
• 各事業者に固有の機能（高度なデータ分析や AI など）を使う
• 特定の事業者への依存（ロックイン）を避け、重要なシステムの障害への強さを高める
• オンプレミスからクラウドへ、またはほかのクラウドへの移行を進める（移行の間だけ、一時的に複数の環境を使う）

出典：Drivers, considerations, strategy, and approaches（Google Cloud）

このうち、移行の途中で一時的に2つの環境を並べるのは、多くの会社が経験する形です。また、AI のように各社の機能の差が出やすい分野では、中心のクラウドとは別に、特定の事業者の AI のサービスだけを使う、という使い方も見られます。

運用が重くなる点

マルチクラウドでは、運用の仕事が、使うクラウドの数だけ増えると考えておく必要があります。

Google Cloud は、検討するときの注意点として、次のようなものを挙げています。

出典：Drivers, considerations, strategy, and approaches（Google Cloud）

運用の現場では、具体的に次のような手間が増えます。IAMの仕組みが事業者ごとに違うため、権限の設計と見直しを別々に行うことになります。監視の道具や手順書も、それぞれに用意が要ります。障害のときに、どちらのクラウドで何が起きたのかを切り分ける手間も増えます。

費用の面では、クラウドから外へ出ていく通信に料金がかかる点に注意します。クラウドの間で大量のデータをやりとりする設計にすると、その通信の費用がかさみます。考え方はデータ転送料金とは。クラウドから出ていく通信の費用で説明しています。

必要かどうかを判断する

マルチクラウドは、それ自体を目的にせず、はっきりした理由があるところだけに使う、と考えるのが現実的です。Google Cloud も、ハイブリッドやマルチクラウドの構成が、それ自体の目的になることはまれで、事業の要件から決めるべきだとしています。

判断のときは、次の問いに答えてみます。

1. 1つのクラウドでは満たせない、具体的な要件があるか（保存場所の決まり、ほかにない機能、取引先からの求め など）
2. 増える運用の仕事を、誰が担うか。社内か委託先に、それぞれのクラウドに慣れた人がいるか
3. クラウドの間で、どのくらいのデータが行き来するか。その通信の費用はいくらになるか
4. 障害への備えが目的なら、同じリージョンの中の複数のゾーンや、同じ事業者の別のリージョンで足りないか

4つ目の問いは見落とされがちです。障害への備えは、多くの場合、1つの事業者の中で複数のアベイラビリティゾーンやリージョンに分けて置くことでも高められます。考え方はリージョンとアベイラビリティゾーン。障害に備えた配置の考え方で説明しています。

依存を減らしたいなら、乗り換えられる備えから

「特定の事業者に頼りすぎたくない」という理由であれば、いきなり複数のクラウドで同じシステムを動かすより、乗り換えられる備えをしておくほうが、手間に見合うことが多くあります。

たとえば、構成をコードで管理しておく（インフラのコード化）、データを標準的な形で取り出せるようにしておく、独自の機能を使う部分と使わない部分を記録しておく、といった備えです。こうした備えがあれば、必要になったときに移る選択肢を残せます。考え方はベンダーロックインを避けるには。原因と、契約・設計での手当てとクラウドの事業者の乗り換えと「抱え込み」を避ける考え方で説明しています。

当社のご支援

当社のクラウドの構築と運用管理は、AWS・Microsoft Azure・Google Cloud のいずれにも対応しており、1つのクラウドを中心に置くか、用途ごとに使い分けるかの整理からお手伝いしています。すでに複数のクラウドを使っていて、権限や監視、費用の管理が散らばっている場合は、クラウドの現状チェックで全体を棚卸しするところから始められます。