ハイブリッドマルチクラウド: あるエレベーターアーキテクトの見解

エレベータアーキテクトはバズワードに惑わされず、その先を見て、アーキテクチャの決定と選択肢を導きだします。今回はハイブリッドマルチクラウドについて考えてみましょう。

輝くものを追いかける

命に限りある私たちが既存のアプリケーションをクラウドに移行したり、新しいクラウドレディなアプリケーションを開発したりするのに忙しい日々を送り続けているにもかかわらず、マーケティング部門は無責任にもマルチハイブリッドクラウドコンピューティング(あるいはハイブリッドマルチというべきでしょうか)のようなものを売り込みにきます。

今まで以上に輝き続ける何かを追いかけるのはシンプルだけど動作するものを提供するより簡単だと、私たちの中の皮肉な部分はすぐにささやきます。だから、新しい流行語の燃えるような輝きに惑わされることなく、誇大宣伝を無視し、流行をアーキテクチャの洞察に翻訳しましょう。マルチクラウドとハイブリッドクラウドに関する記事とGoogleの友人達の書いたパターンは役に立つのですが、私たちの持っている選択肢のアーキテクチャの本質と決定すべきことについて明確に説明していません。

ここでアーキテクトエレベータに乗るアーキテクトの考え方が役に立ちます。主要な決定事項、制約、仮定が解決方法に含まれているか。どのような選択肢があり、どのような決定が必要か。それぞれの選択肢の利点や金額だけでなく複雑さやロックインを含むコストは何か。では考えてみましょう。

ハイブリッドは現実、マルチクラウドは選択肢

最初にハイブリッドとマルチの違いについて見てみましょう。簡単なようですが、すでに混乱したり定義の矛盾に気がついた人もいるでしょう。まずはシンプルに考えてみましょう。

• ハイブリッド: ワークロードをクラウドとオンプレに分割します。一般的にこれらのワークロードは一つのアプリケーションです。つまり、クラウド上のワークロードとオンプレ上のワークロードは何かを行うために協調して動作します。
• マルチ: 複数のクラウドプロバイダー上でワークロードを稼働させます。より正確な定義を求めるなら、意見は分かれてしまいます。

オンプレをマルチクラウドの一部だと考える人たちもいます(「マルチクラウドの設定にはプライベートコンピューティング環境も含まれます」)。GCPもこの一派です。この二つは確かに技術的に関連していますが(「オンプレは単にもう一つのデータセンターにすぎません」)、ハイブリッドをマルチクラウドの一種と考えることができるのであれば、マルチハイブリッドという用語を使う必要はないでしょう。混乱してきましたか。では、別の視点で考えてみましょう。

「ある朝CIOが起きると、全てのワークロードがクラウド上で動くようになっていることはありえません。ハイブリッドクラウドは現実的な話です。」

どのような技術であれ、ハイブリッドとマルチクラウド導入の目的と原動力は全く異なります。ハイブリッドクラウドは企業にとって現実です。AWS Snowmobileのようなクールな技術があるにも関わらず、ある朝CIOが起きると、全てのワークロードがクラウド上で動いていることはありえません。いくつかは「外」に、いくつかは「内」に残り続けます。そして多分、外と内はつながっている必要があるでしょう。この話題は重要なので別の記事で取り上げます。

「ハイブリッドクラウド戦略の中核は分割方法の決定です。つまり、どのワークロードを外に置くべきか、何がオンプレに残り続けるかです。」

一方、マルチクラウド戦略はアーキテクチャの選択です。一般的なマルチクラウドアプローチとそれを使う理由を調べることにより、アーキテクチャの選択が可能になります。

マルチクラウドの分析

マルチクラウドを使う理由を理解するために、技術的なプラットフォームアーキテクチャを一般的なシナリオに分割してみましょう。「マルチクラウド」のスローガンのもとにパッケージ化されたものは、以下のカテゴリに分類できます。

この比較において、大きな番号の方が良いというわけではありません。ニーズに一致するアプローチを見つけ、適切な選択をおこなうためのものです。

「マルチクラウドは白か黒の選択ではないし、全ての用途に適したアーキテクチャでもありません」

任意(Arbitrary)

大企業が私たちに一つ教えてくれることがあるとすると、現実はプレゼンテーションスライドのようにはいかないという事です。この論理(そしていつもの皮肉)をマルチクラウドに当てはめると、企業のマルチクラウドの多くはガバナンスの不在と行き過ぎたベンダーの影響力の結果であることがわかります。つまり、いくつかのワークロードはブルークラウドで、また別のワークロードはライトブルークラウド、そしてレインボークラウドで動いているものもあるという状況です。どうしてこんな事になるのでしょうか。最初はオレンジクラウドで始めたはずです。次に、既存のライセンス契約のおかげでライトブルークラウドから大幅な割引をしてもらいました。また、新しもの好きな若者達はレインボークラウドが大好きです。そして、注意深く観察してみると、人脈とセールスの強烈な売り込みによるレッドクラウドも見つかるかもしれません。

このマルチクラウドのセットアップに戦略という言葉はふさわしくありません。しかし、最悪というわけではありません。少なくとも何かをクラウドにデプロイしています。これは良い事です。なぜなら、舵を取る前に移動する必要があるからです。少なくとも、移動し始めています。つまり、複数の技術プラットフォームの経験と構築スキルセットを手に入れようとしているという事です。ただし、思考の外部委託をしていなければですが。

分割(Segmented)

ワークロードを異なるクラウドへ分割するのは一般的で良い一歩です。特定の種類のワークロードを特定のクラウドにデプロイします。

このシナリオは、異なるワークロードの種類に対して異なるベンダーを選択することにより発生します。例えば、個々のベンダーの強みやライセンス条件などです。一般的な組み合わせとしては、ほとんどのワークロードをオレンジで、Windows関連のワークロードはライトブルーで、機械学習/分析はレインボーで稼働させることです。たとえ、ベンダーの提供する機能が後者のカテゴリーに急激に移行していたとしてもです。

分割方法を決定するためのいくつかの観点が存在します。

• ワークロードの種類 (レガシー、あるいはモダン)
• データの種類 (機密、オープン)
• 製品の種類 (計算、データ分析、コラボレーションソフトウェア)

このアプローチを採用する場合、アプリケーションの半分が左に残りが右になるため、莫大な外向きの通信費用がかからないように、アプリケーションのつなぎ目を理解すると良いでしょう。

また、私はベンダーとの関係によって、企業が分割から任意に戻っていくのを見たことがあります。例えば、クラウドベンダーXの特定の種類のサービスを使おうとしているとします。しかし、別のベンダーの(プリ)セールスは、彼らの別のサービスを使うようにチームを説得するでしょう。それが彼らの仕事なので、あなたはどうするかを決める必要があります。そうしないと、95%の計算をシンガポールのECSで実行し、残りを東京のAppEngineで計算する羽目になります(実例です)。これは全く意味がありません。

選択(Choice)

多くの人は、先の二つの例を本物のマルチクラウドとは考えないかもしれません。彼らが求めている(そして売り込んでいる)のは、ワークロードを自由に色々なクラウドプロバイダーにデプロイできることです。そうすれば、ロックイン(あるいはそう認識しているもの)を最低限にすることができます。通常、これは抽象化レイヤー、あるいはガバナンスフレームワークを構築する事により実現されます。複数のクラウドの特色を認識しつつ、クラウドプラットフォームの最初の選択が可能となります。ただし、後で気が変わらない前提です。

このような選択の自由は大規模組織における共有ITプロバイダーにとって一般的です。彼らは幅広い事業単位とITの選択肢をサポートすることを期待されています。多くの場合、このようなやり方には、取引関係の一括管理と選択したクラウドプロバイダー上にインスタンスを作る共通のフレームワークが含まれています。そして、そのフレームワークにはコーポレートガバナンスと制約が組み込まれています。

この方法の利点は、プロジェクトがマネージドデータベースのようなプロプライエタリなクラウドサービスを自由に使えることです。ロックインを避けることと、オペレーションのオーバヘッドを最低限に抑えることのトレードオフをどう考えるか次第ではありますが。したがって、マルチクラウドの最初の一歩としてこのやり方を選択することは何も問題ありません。

並列(Parallel)

ひとつ前の方法はクラウドサービスプロバイダーの選択を可能にしますが、そのプロバイダーのサービスレベルに縛られます。多くの企業は、一つのプロバイダーの複数のアベイラビリティゾーンの利用より高いレベルの可用性を保障するために、クリティカルなアプリケショーンを複数のクラウドにデプロイしようとしています。

同一のアプリケーションを複数のクラウドにでデプロイするためには、クラウドプロバイダーのプロプライエタリな機能との疎結合化が必要です。これには幾つかの方法があります。例えば、

• アイデンティティ管理、デプロイメントの自動化、モニタリングなどをアプリケーションから分離し、クラウドベンダー固有の方法で管理する
• 可能な限りオープンソースのコンポーネントを利用する。一般的にオープンソースのコンポーネントはどのクラウドでも実行可能です。これは純粋な計算(ほとんどのクラウドでマネージドKubernetesが提供されています)では比較的うまくいきますが、データストアやモニタリングのような完全なマネージドサービスを利用する利点が減るかもしれません。マネージドサービスはクラウドに移行する利点の一つなので、選択肢を慎重に検討する必要があります。
• マルチクラウドに対応した抽象化フレームワークを利用する。一度開発すれば、どのクラウドにもデプロイできます。
• アプリケーションにおけるクラウドプロバイダー固有のコンポーネントを二つのブランチで保守し、それらを共通のインターフェースでラップします。例えば、ブロックデータストレージの共通インターフェースを作ることができるでしょう。

最後の方法は、その場しのぎのように聞こえますが、データベースや他の多くの依存コンポーネントに対して行ってきたことと同じです。適切にラップされていれば、現実的な選択肢です。

注意すべき重要な側面は複雑さです。複雑さのせいで期待していたほど稼働時間が増えないかもしれません。抽象化レイヤーやツールを使うことにより設定ミスの可能性も高まります。また、壊れたアプリケーションを両方のクラウドにデプロイしてしまうと、ダウンタイムが発生するので、ヒューマンエラーに対する考慮も必要です。

私は複数のクラウドベンダーの三つのアベイラビリティゾーンにデプロイし、かつそれぞれにディスアスタリカバリーの環境を足した設計を提案するベンダーを見たことがあります。つまり、それぞれのコンポーネントは 3 * 2 * 3 = 18ノードを必要とします。この台数のマシンが9ノード(ゾーンごと、かつクラウドプロバイダーごとに1つ)より高い可用性を提供するかどうか疑問です。

移行可能(Portable)

マルチクラウドの頂点と考えられているのは、クラウド間の自由な移行です。つまり、ワークロードをどこにでもデプロイでき、好きな所に移動できることです。利点は明白です。例えば、ベンダーロックインを避けることができるので、ベンダーに対する交渉力を手に入れることができます。リソースニーズにもとづきアプリケーションを移動することもできます。例えば、普段はあるクラウド上で処理を実行し、バーストした大量トラフィックを他のクラウドで実行することができます。

これを可能にする仕組みはクラウドサービスから分離された高度な自動化と抽象化です。並列(Parallel)デプロイメントの場合、半手動のセットアップやデプロイメントプロセスで十分かもしれません。しかし、完全な移行では、ワークロードをいつでも移動できないといけないため全てを完全に自動化する必要があります。

Anthosのようなマルチクラウド抽象化フレームワークはこのような設定を簡単にします。しかし、無料というわけではありません。特定のベンダー、製品、アーキテクチャへのロックイン、それに加えてアプリケーションのコンテナへのデプロイという形で対価を払う必要があります。また、このような抽象化は一般的にデータを面倒みてくれません。計算ノードがプロバイダ間で自由に移動する場合、どのようにデータを同期しますか。 もし、このハードルを超えたとしても、外向きのデータの通信費用が問題となる可能性も残っています。

輝くものを磨く

光り輝くものを追いかける時には、輝きの強いものほど良いという思考の罠に陥りがちです。大企業の戦いの傷を負っている人はみな、輝くものを磨き、より輝かせるためにはコストがかかることを良く知っています。金銭的なコストは明白な懸念事項ですが、複数のベンダーの管理、正しいスキルセットの発見、長期的な可能性(全てのコンテナを捨てて、サーバレスに移行しますか)といった複雑さが増すことも考慮する必要があります。これらはお金では解決できる問題ではありません。

したがって、最も大事な目的を理解し、明確に伝えることが重要です。可用性の向上や、あるプロバイダーだけがデータセンターを持つリージョンへのデプロイのサポートをベンダーと交渉するために、あなたはマルチクラウドを検討していませんか。ロックインの排除」は単にメタゴールにすぎません。ロックインは望ましいアーキテクチャではありますが、具体的なメリットによって必要性を判断する必要があります。

次の表に、選択肢、主要な原動力、注意すべき副作用をまとめました。

スタイル	重要な機能	重要なメカニズム	考慮事項
任意(Arbitrary)	アプリケーションのクラウドへのデプロイ	クラウドのスキル	ガバナンスの欠如。ネットワークトラフィックの費用
分割(Segmented)	クラウドの利用方法の明確なガイダンス	ガバナンス	ベンダーに舵取りされ任意(Arbitrary)へ後戻り
選択(Choice)	プロジェクトのニーズと選択肢のサポート(ロックインを減らす)	プロビジョニング、支払い、ガバナンスのための共通フレームワーク	別のレイヤの抽象化。ガイダンスの欠如
並行(Parallel)	単一のクラウドより高い可用性	自動化、抽象化、負荷分散	複雑さ(クラウドサービスの不十分な活用)
移行可能(Portable)	好きなところへのワークロードの移動	完全な自動化、抽象化、データの移行性	複雑さ(マルチクラウドフレームワークへのロックイン)

予想通りTANSTAAFLです。つまり無料のランチはありません(there ain’t no such a thing as a free lunch)。アーキテクチャはトレードオフの問題です。したがって、選択肢を整理し、意味のある名前をつけ、その意味を理解することが重要です。これらのツールを使えば、アーキテクトエレベータに乗り、ハイブリッドマルチクラウドに向けての啓蒙計画を立てることができます。もちろん、何かをクラウドに移行する前に、自分達で構築していないものを動かすなということを思い出してください。