クラウドアプリ移行の頭痛を避けるための4つの対策

企業は、ビジネスクリティカルなアプリケーションをクラウドで稼働させることを一旦決めたら、他のプロバイダーに移行することはほとんどない。その大きな理由の1つは、多くの場合、選択したプロバイダーのエコシステムにロックインされているからだ。移行コストは単純に高すぎると、ガートナーのクラウドサービス・テクノロジー担当副社長シド・ナグは言う。「しかし、きちんと計画を立てれば、アプリケーションを移行する必要はないはずです」と彼は言う。

プロフェッショナル・サービス企業Globantのクラウドオペレーションおよびサイバーセキュリティ・スタジオ・パートナーであるパブロ・デル・ジュディチェは、組織を正しく配置すれば移行は可能だと付け加える。そして、彼と彼のチームはそれを成功させている。「重要なのは、オープンなプラットフォームとフレームワークを戦略的に採用し、クラウド・プロバイダーをインフラレイヤーの役割に追いやることだ。このアプローチは、学習曲線が急な反面、中長期的にはより有利な結果をもたらす」と彼は付け加える。「重要なのは、プラットフォーム・ニュートラルなソフトウェア・アーキテクトを導入することだ。」

米国特許商標庁のCIOであるジェイミー・ホルコムは、もう少しニュアンスの異なる見方をしている。同は、クラウド・サービス・プロバイダー間でアプリケーションを移行させる選択肢をオープンにしておきたいと考えており、主要なプロバイダーすべてについて市場調査を行っている。しかし、そのためには、アプリケーションを初めてクラウドに移行する前に、早めに計画を立てる必要がある。

ロックインのリスクを最小限に抑える

各ベンダーのクラウドネイティブサービスを利用する際には、トレードオフを慎重に検討する必要がある。「アグノスティック（不可知論的）であることを維持するために、クラウド・プロバイダーのネイティブ・サービスを利用しないという選択をすると、『より良い、より安い、より速い』というビジネス・ケースの指標の多くを失うことになる」とホルコムは言う。「ベンダーロックインにコストがかかるように、不可知論的であることにもコストがかかる。」

デル・ジュディスは、クラウド・ベンダーのロックインを3つの形態に分類している。プラットフォーム・ロックインとは、クラウドの基盤構成（リソース・グルーピング、ポリシー、RBAC、ハイブリッド接続、モニタリング、コンプライアンスなど）が完成している場合に発生するもので、そのすべてを新しいプラットフォームで再作成するのは複雑なため、別のプラットフォームへの移行が困難になる。

アーキテクチャー・ロックインは、アプリケーションがクラウド・プロバイダーの複数のマネージド・サービスに依存している場合だ。この場合、移行する前にアプリケーションを再設計する必要がある。

そして、法的なロックインもある。あらかじめ決められた期間、エンタープライズ・サービス契約にコミットしている場合だ。「このようなコミットメントは解約が難しく、マイグレーションの実行を困難にする」と彼は言う。

ベンダーの囲い込みは、CIOが回避しようと最善を尽くしても避けられないことがある。CIOは通常、統合を望むが、コストが高すぎて正当化できないことが多い。CIOは通常、統合を望むが、コストが高すぎて正当化できないことが多い。ほとんどの場合、CIOはマルチクラウド・モデルを維持するとナグは言う。

しかし組織には、障害にもかかわらずIaaSプロバイダー間を移行する正当な理由があるかもしれない、とデル・ジューディスは言う。最も一般的なのは、競合するクラウドサービス・プロバイダーの積極的な割引を利用するために、価値とOPEXの間のコスト比率を改善すること、そして組織が信頼性を向上させたい場合にマルチクラウド・アーキテクチャを活用することである。

将来的な移行を見据えた計画を立てる

しかし、ガートナーが「クラウド・リパトリエーション」と呼ぶように、主要なアプリケーションをクラウドプロバイダー間で移行させたいと考えるのは、たいていの場合、誤った計画の結果であるとナグは言う。ナグは、クラウドへのリフト・アンド・シフトのデプロイメントだけでなく、手頃な価格のクラウドネイティブ・ミドルウェアや開発ツールの使用を決定し、完了したらアプリケーションをオンプレミスのプライベート・クラウドに戻すことを意図している場合にも、この傾向が見られるという。

同氏は、MSPやシステムインテグレーターのサービスを利用して計画を立て、クラウドに移行するアプリケーションを正しく選択することを勧めている。「一旦クラウドに移行してしまうと、そのプラットフォームに縛られることになるからだ。」

金融サービス企業のUSAAは、4つのクラウドサービスプロバイダーの中から、各ワークロードと通常のビジネスアプリケーションをホストするプロバイダーを慎重に選んだとSVP兼CTOのジェフ・カルシンスキーは言う。「我々は、クラウドプロバイダーを、彼らが最も得意とするビジネスや技術サービスに合わせました。」

この機関のマルチクラウド戦略は、同が「オープン・バイ・デザイン」と呼ぶ原則に基づいている。「オープンな標準が存在する場合はそれを使用することで、ベンダーロックインの可能性を減らしています」と彼は言うが、ロックインの可能性と天秤にかけなければならない魅力的な価値提案を提供するネイティブサービスもあることを認めている。

また、オープンな設計原則は、ロックインの可能性という点では限界があるとナグは言う。最新のサービスを利用していても、プラットフォームごとに実装は異なるからだ。例えば、アマゾンのEC2基盤はグーグルのGCPと同じことをするが、EC2上で動くアプリケーションは、高価な手直しをしなければGCP上では動かない。また、Kubernetesは業界標準だが、Azure Communication ServicesやGoogle Kubernetes Engineなどの実装は、同じようには動作しない。

「しかし、クラウドプロバイダーとアプリケーションの間には、いくつかの抽象化レイヤーが出現している。」とデル・ジュディチェは言う。これらのサービスは、ネイティブのクラウド・プロバイダー・サービスを使用している場合でも、移行を簡素化することができる。「pub/sub、サービス呼び出し、シークレット管理、ステート管理などのこれらのサービスは、クラウド・プロバイダーに関係なくアプリケーションのコンポーネントを抽象化する。要するに、選択肢は開かれているが、あるクラウド・プロバイダーから別のクラウド・プロバイダーへ移行するためには、いくつかの作業を行う必要があるということだ。」

データ要件もまた、慎重な計画が必要な分野だ。「クラウド間でアプリを移行させるには、関連するデータも移行させる必要があるためコストがかかる。」とナグは言う。

そのため、事前に計画を立てる必要がある、とホルコムは付け加える。「契約書を交わさない限り、プロバイダーと契約してはならない。そうすることで、データを取り出す方法や、ソフトウェア・サービスを別の場所に複製する方法を知ることができる。」

しかし、適切なETL戦略を持つことで、プロバイダー間でデータを構造化された方法で、利用可能なフォーマットで移行できることが保証されるとしても、そのような計画は存在しないことが多いとデル・ジューディスは言う。「クラウド・サービス・プロバイダーは、理論的には使いやすいオープン・プラットフォームやデータ・アクセス・プロトコルの利用を強調しているが、これらのサービスにアクセスするためのネットワークの制限やセキュリティは見落とされがちだ」

どのクラウド・ネイティブ・サービスを使うかを決めるとき、組織には選択の余地がないこともある。セキュリティが良い例だ。「セキュリティのニーズが高い場合、一般的なサイバーセキュリティでは不十分かもしれません」とホルコムは言う。ニーズが具体的であればあるほど、ベンダーロックインという点で、サービスは厳しくなる。また、データ集約型の業務を行う企業は、ストレージと帯域幅の両方の問題に直面しており、PaaSとIaaSのプロバイダーはその両方を競争上の差別化要因として利用している、と同氏は言う。「両方を使って高いパフォーマンスを活用しようとすれば、それは難しいことです」

ホルコムは、ネイティブ・サービスを活用したカスタマイズに対して、同が「ブラック・スプルース」と呼ぶアプローチに従っている。黒いトウヒが枝を幹に密着させるように、USPTOもカスタマイズを可能な限り「細く」しているという。そうすることで、ロックインを減らすだけでなく、同が「過剰でコストのかかるバージョニング・パス」と呼ぶような作業に悩まされることもなくなる。

カルシンスキーも同様のアプローチをとっている。「ほとんどのPaaSには、コア機能と付随機能がある。我々は、補助的な機能の数を制限し、コアに集中する。」

SaaSベースのアプリケーションも同様で、RemedyからServiceNowとSalesforceに移行した後、彼のチームはこれに従った。「多くをカスタマイズせず、必要なときに変更できるようにすることだ。我々はSalesforceに縛られることなく、ServiceNowは構造的に良いプラットフォームだった。しかし、最適化が過剰に施されていると、行き詰まってしまう」

しかし今回、カルシンスキーは違ったアプローチをしている。「SaaSプラットフォームでは、ビジネスとしてベンダーの能力に十分な差別化が見られず、変更の可能性が低いため、可能な限りプラットフォームを採用する。」

潜在的な移行の痛みを回避する

クラウドプロバイダー間の移行には無数の課題があることは明らかだ。互換性の問題、セキュリティ上の懸念、アプリケーションの大規模な再構成の必要性、新しい環境にシームレスに統合できない古いオペレーティングシステムや時代遅れの技術スタックに基づくイメージへの対応などだ。大量のデータを移行することは、ダウンタイムやデータ損失の可能性にもつながりかねず、移行中の一貫したパフォーマンスとスケーラビリティを確保することは極めて重要である。「これらの課題を管理するには、綿密な計画、徹底的なテスト、明確に定義されたロールバック戦略が必要」とデル・ジューディスは言う。

また、PaaS移行の主な失敗ポイントとしては、コストやビジネス上の期待に応えられていないこと、リソースのスキルが十分でないこと、標準化やセキュリティ基盤が不足していること、クラウドネイティブな機能を活用できていないこと、セキュリティやコンプライアンスに関する懸念があること、クラウド運用モデルを採用していないことなどが挙げられる。

デル・ジュディチェは、クラウドプロバイダー間の移行を検討している組織に対して、6つのステップからなるアプローチを推奨している。まず、サブスクリプション・モデルを評価し、それがROIの目標に合致していることを確認する。ハイブリッド・クラウドのアプローチを採用する。可能な限りクラウドにとらわれないソリューションを使用し、将来の移行オプションの幅を広げる。ネイティブ・クラウド・サービスを利用する場合は、抽象化レイヤーを用いてアプリケーションを設計する。データ移行の計画、テスト、バックアップ戦略に投資し、リスクを軽減する。必要に応じてライセンス契約を見直し、調整する。

選択肢を慎重に検討する

クラウドプロバイダーの移行を検討する際には、移行コストとデータの所有権を常に考慮する必要がある、とカルシンスキーは言う。

また、ロックインを高めるネイティブ・クラウド・サービスを利用するのか、それともアグノスティック（不可知論的）な立場を維持するのかのバランスを取る場合、組織とそのミッションにとって最適なものを選ぶだけで、正解はないとホルコムは言う。問題なのは、クラウドベースのアプリケーションが組織のミッションに合致し、長期的にそれを達成するために最高の価値を提供するかどうかだという。「複雑すぎるコスト・インフラを導入してしまうと、ビジネスモデルが変わったときに変更することができません」と同は言い、USPTOが設計上マルチクラウド・アーキテクチャを採用しているように、選択肢を広げておくべきだ」と付け加えた。「私の一番の理由は、サービス・プロバイダー間の競争をさせるためです」と彼は言う。

クラウド移行の戦略を練る際には、価格設定モデルに留意することが重要だとデル・ジュディチェは言う。「コスト削減の可能性のあるプランを検討し、データ転送コストを考慮に入れてください」と彼は言う。「このアプローチは、予期せぬクラウド運用費の高騰を防ぎ、予算制約との整合性を確保するために不可欠である。移行戦略を実行する際には、他に2つの要素を考慮する必要がある。第一に、マイクロサービスやサーバーレスなど、移行を促進するためにクラウドサービスプロバイダーが提供するサービスは何か。カスタマイズされたソリューションを使うか、クラウドプロバイダーのマネージドサービスを使うかを決める必要があるが、これはベンダーロックインのリスクを生む。第二に、クラウド・プロバイダーは、アプリケーションの移行に対してインセンティブ・プログラムを提供している場合があり、大規模な移行にはかなりの割引が適用される。」

その性質上、クラウド移行にはリスクが伴う。しかし、事前に計画を立て、このプロセスに粘り強く取り組むCIOは、より費用対効果の高いクラウドサービスと価格モデル、スケーラビリティとリソース割り当ての改善、パフォーマンスと応答性の向上を実感できるだろう。「ベンダーの囲い込みが減ることで、俊敏性とイノベーションが促進される」とデル・ジュディチェは言う。「最終的に、クラウドへの移行は競争力、革新性、効率性の向上につながる。」