Technology Diaries

Google Cloud Platform: ITインフラストラクチャーのモダナイゼーション -マルチクラウド、クラウド選定、ベンダーロックインを考える (前編)

2020/06/24

テクノロジーコンサルティング本部 Dataグループ　シニア・マネジャーの青柳雅之です。私はデータやアナリティクスの領域を中心にAWS/Azure/GCPといった各パブリッククラウドにおける業務に従事しています。

お客様からは「新しいビジネスに柔軟に俊敏性を持って対応し、安定性の高いITインフラストラクチャーを構築したい」というご要望を聞くことが多いです。今回のブログでは、このようなご要望に関して主要な論点を選び、ITインフラストラクチャーのモダナイゼーションに関するポイントについて解説します。筆者はAccenture Google Cloud Business Group ソリューションアーキテクトも兼任していますので、例としてGCPのサービスを掲載させていただきますが、基本的な考え方自体は他のパブリッククラウドでも通用するものです。この前編では、ITインフラストラクチャーのモダナイテーションに関する疑問、クラウドの選定、マルチクラウドによるベンダーロックイン回避に関する論点を解説します。次の後編では、コンテナによるベンダーロックインの可否、メインフレームのクラウドへの移行に関する論点を解説します。

■ITインフラストラクチャーのモダナイゼーションに関する疑問

ITインフラストラクチャーのモダナイゼーションとは何か
ITインフラストラクチャーのモダナイゼーションとは、IT部門がレガシーのITインフラストラクチャーに対して抱える次のような諸問題の解決を現行の技術で行うことだと言えます。

表：レガシーITインフラストラクチャーの問題とモダナイゼーションによる解決
どのようなステップでモダナイゼーションを行えばいいか
基本的には従来の移行プロジェクトと同様です。ITインフラストラクチャーを構成するIT資産の棚卸を行い、現行システムの構成やハードウェアのスペックを調査します。その上でターゲットとなる環境のアーキテクチャを策定し、その環境へのIT資産の移行方針をまとめます。これらがまとまったら移行チームを編成し、PoCと移行、テストを行います。

上記は技術面の話です。それ以外の領域について、施策の内容や順番は、組織独自の様々な考慮が必要であることを認識します。

たとえば、オンプレミスに存在するデータをクラウドに保存する場合の扱いはセキュリティ部門との調整が必要な場合があります。クラウドは新しい技術なので人材の育成も必要になります。クラウドの運用を行うために既存の運用基盤に追加の仕組みを入れる必要もあります。
組織によってはITアーキテクト部、システム運用部、事業部のITチームなど、様々なステークホルダーが存在し、クラウドを導入する前の段階でステークホルダー間の調整に時間がとられる場合があります。これらの各調整を移行（モダナイゼーション）ロードマップ上の施策とするならば、組織によって状況や課題は異なるため、当然モダナイゼーションのロードマップは組織ごとに異なります。

GCPからは、「Google Cloud 導入フレームワーク」にて、人、テクノロジー、プロセスの観点を中心にクラウド導入上の検討事項が提供されています。組織の各部署のステークホルダーが持つクラウドへの懸念（検討事項）の多くはここに記載されています。またこのフレームワークは、組織がどの程度これらの課題をクリアしているか？という状況から、組織のクラウド成熟度を見極めることができます。

図：Google Cloud 導入フレームワーク

AWSやマイクロソフトも同様のフレームワークを従来から提供しています。重複している事項もありますが観点は各社で異なりますので、読めばクラウド導入の課題への理解が深まります。筆者はこの2社のフレームワークの他、「クラウドCoEとクラウドEA」で紹介させていただいたように、次のような自社の同様のフレームワークも活用しています。組織の状況に応じて、必要な部分を取捨選択すればいいでしょう。なお、この観点の数は各事項をどの広さでグルーピングするかという問題に過ぎないので多少は問題ありません。また、クラウド導入のためのワークショップを行うこともあります。ステークホルダーを集めてこのフレームワークを参考にしながら、クラウドの導入に際して実施すべき施策の優先順位を合意形成を行いながら付けていきます。

図:クラウド導入における9個の視点
※図中で"Stream"とは「一連の施策」という意味を指す

クラウドの選定はどう考えるか
IaaSが主流で大企業でパブリッククラウドが使われ始めた５、６年ほど前は、機能が多く実績も多いAWSをベースに考えることが多かったことと思います。ここでAzureを選択するかどうかの決め手の１つは、国内のDR要件があるか否かでした。当時、AWSには東京リージョンと同等の大阪リージョンがなく、DRサイトはシンガポールなどに配置していました。そのため、国内にDRサイトを作る要件がある場合はAzureを選定することもありました。現在はGCPも加え、大阪にリージョンがありますので、このDRサイトによる判断基準はありません。

クラウドを利用する目的を定義しないまま、各クラウドの機能の優劣を比較した表を作ることはあまり意味がありません。たとえば、あるクラウドが対応するデータベースの種類が他のクラウドよりも多いとしても、自分の組織でそのデータベースを使わない場合はわざわざ種類を多く持つクラウドを使わなくてもよいのです。筆者はユースケースによっては、現在はどのクラウドも機能的には大きな差異はないと考えています。その上で、クラウドの選定には6つの基準があると考えています。上から順番にチェックしてクラウドを絞り込んでいくというよりは、行ったり来たりしていろいろな角度から考えます。

クラウドの選定基準

1.小さくともすでに利用を開始してプロダクション環境として実績のあるクラウドの利用を拡大する。
2.組織の要件に見合うサービスを持つクラウドを選択する。
3.複数のクラウドが該当すれば、最も実績のあるクラウドを選択する。
4.組織のセキュリティ要件を満たすクラウドを選択する。
5.要件をいずれのクラウドも満たす場合、コスト比較をする。
6.その組織とクラウドベンダーやパートナー企業との関係で彼らから支援を引き出しやすいクラウドを選択する。

表：クラウドの選定基準

１を考えるのは、多くの組織にとって、複数のクラウドのための人材確保や運用の仕組みを構築するのは至難の業だからです。既に導入済みであればクラウドを導入する組織のハードルを越えており、また、一番利用になれているはずなのであえて別のクラウドを持ち出して、０から比較をして新たに選定しなおす必要はありません。

そして、そのクラウドのサービスでは要件を満たせないが他社のクラウドでは満たせる場合に、他のクラウドの選定を検討するのが2や３です。

初めて組織でクラウドを導入する場合、まずは自社のセキュリティポリシーを満たすクラウドか否かを判断する必要があります。これが４です。特定の国ではある第三者認証が必要だがこのクラウドは取得していない、そのセキュリティ要件を満たすのに必要なマネージドサービスはいずれのクラウドにも存在するが、このクラウドのほうが料金が安いので選択する(基準5に該当)、といった判断も出てきます。

また、自社の要件に必要かつ、特定のクラウドベンダーしか持たないキラー的なサービスがあるケースもあります。そのサービスを持つクラウドをベースに、様々なサービスと要件とのFit & Gap分析を行っていくとよいでしょう。例えば、GCPでは大量データに対する高速な分析を可能にするDWHであるBigQuery等がそのキラー的なサービスとして挙げられるケースもあります。当然ながら、他のクラウドにキラー的なサービスがあれば、そちらを優先的に考えることになります。Fit & Gap分析の結果、ITインフラストラクチャーの多くを担う１つのクラウドと、特殊な用途のための別のクラウドという組み合わせもマルチクラウドの組み合わせとして十分ありうる選択肢です。

もしクラウド間でその組織としてはサービスにあまり差がない場合は、基準6を考慮します。6としていますが、これは意外と最初に検討する基準かもしれません。

マルチクラウドはベンダーロックインを回避する技術として有効か
現実には、クラウをすでに導入している、もしくは複数のパブリッククラウドを活用するマルチクラウドをすでに導入しているエンタープライズの組織はそれなりに多いです。IDGの調査によると次のようになっています（こちらで内容をサマライズしています）。

組織の73%はすでにクラウドを持っています。
組織の42%がマルチクラウドを持っています。
理由は1)クラウドオプションの増加、2)より簡単で高速な災害復旧です。
出典:IDG Cloud Insights survey, 2018

すべてがベンダーロックインの回避を目指しているかは定かではないですが、組織内のビジネスニーズや部署が適材適所で各クラウドを選択しているのではないかと思います。

ベンダーロックインを回避する方法の1つとして、マルチクラウド化があげられることあります。現場ではマルチクラウドの運用は困難なのでなるべく１つのクラウドの運用にこだわりたい一方、お客様との会話の中では、CXOレベルではベンダーロックインを回避するためにマルチクラウドを志向する場合があると感じます。
とはいえ、先に述べたように現場レベルではマルチクラウドは負荷となってしまいます。また、特定のクラウドに集中することでそのクラウドの専門知識が強化され運用コストが下がり、そのクラウドベンダーからサポート要員の拡充やボリュームディスカウントなどのさらなる優遇措置を引き出せる場合もあります。
そのため、将来的にはマルチクラウドを選択肢に入れながらも、まずは先のいくつかの観点から導入しやすいクラウドを選定し、その１つのクラウドを中心にしっかりと運用を行うのが良いでしょう。1つのクラウドで標準化構成と運用が安定化すると、他のクラウドにも同様の取り組みを実施する組織は多いです。大きな組織になると、部署毎に異なるビジネスニーズがあり、様々なクラウドを導入する要望があります。結果的に、そのような流れで中長期でマルチクラウド化を実現してきた組織が多いと想定されます。

表：マルチクラウド化のメリット/デメリット

次の後編では、コンテナによるベンダーロックインの可否、メインフレームのクラウドへの移行について論点を記載したいと思います。