マルチクラウドとオープンソースを組み合わせることで、既存ベンダーの強みを活かしつつ、パブリッククラウド本来の柔軟性を引き出す方法を解説します。
クラウドの柔軟性を引き出す鍵となるオープンソース
クラウドの最大の魅力は、ほぼ制約のない柔軟性にあります。しかし、多額のコストや法的トラブル、技術的な非互換性なしにクラウドプロバイダーを乗り換えられないとすれば、その柔軟性は大きく損なわれてしまいます。
複数のクラウドプロバイダーを併用すれば一見スマートに解決できそうですが、話はそう単純ではありません。本記事では、クラウド利用者が直面するベンダーロックイン問題、マルチクラウド導入だけでは解決しない理由、そしてオープンソースが果たす役割を掘り下げていきます。
クラウドでベンダーロックインが起きる仕組み
使っている技術が単一プロバイダーからしか提供されておらず、ライセンス料や保守料を払い続けなければ利用を継続できない状態。これがベンダーロックインです。クラウドへの移行は本来、こうした制約から解放してくれるはずです。利用者は概ね自分の裁量でクラウドを使えるからです。たとえば主要なクラウドプロバイダーはいずれも従量課金制を採用しており、理論上はいつでも環境を停止し、データや仮想マシンをエクスポートして撤退することができます。
加えて、クラウドサービスは一般的にプラットフォームへの双方向のデータ移行に対応するよう設計されています。各ベンダーは、データベースやそれを利用するアプリケーションをクラウドへ、あるいはクラウド間で移行するためのサービスやツールを整備しています。
とはいえ、クラウドでのプロバイダー乗り換えは決して一筋縄ではいきません。たとえばデータ転送。同一のデータベースエンジンを使うサーバー間のデータ移行(同種移行)は比較的容易です。しかしバージョン番号程度のわずかな違いでも、別のエンジンへ移行する(異種移行)前に解決すべき課題が次々と表面化することがあります。場合によっては、まったく別のアプローチやアプリケーションが必要になります。
さらに、既存ベンダーの強みを最大限に活かして構築されたアプリケーションも考慮しなければなりません。そうしたアプリケーションを別のクラウドでネイティブに動かせるよう作り直すのは複雑な作業です。これこそがクラウドのベンダーロックイン問題の核心です。各プロバイダーのやり方は微妙に異なるため、移行には必ず一定のハードルが伴います。なかでも、新しいベンダーの技術や流儀に対するチームの知識ギャップは見過ごせない要素です。
マルチクラウドだけでは答えにならない理由
マルチクラウド戦略は単一ベンダーへの依存を軽減してくれますが、ベンダーロックイン対策の万能薬ではありません。既存のアプリケーションやworkloadsをオンプレミスからクラウドプロバイダーのインフラへ移すこと自体は比較的容易で、利用者側もベンダーロックインからかなり守られています。サーバー、ネットワーク、ストレージをクラウドベンダーに支払って利用する場合、仮想マシンを別のクラウドへ移すコストは、本質的にプロビジョニング用の新しいAPIを習得するコストとほぼ同義です。
ところが、サービスとなると話はまったく違います。パブリッククラウドベンダーはたいてい、自社のクラウドエコシステム内でしか動作しない独自の管理ツールを前提にサービスを設計しています。たとえばAmazon Web Services(AWS)上にアプリケーションを1つデプロイするだけでも、Kinesis、DynamoDB、ElastiCache、Simple Queue Services、TimeStream、Lambdaといったサービスを使うことになります。これらはいずれもAWSでしか提供されていない独自サービスです。
特定のクラウドプラットフォーム向けに開発したアプリケーションを別のプラットフォーム向けにリファクタリングするコストを踏まえると、上位の独自サービスを複雑に組み合わせて構築されたクラウドサービスでは、技術選定とクラウドベンダー選定を切り離すのは困難です。理論上は同じworkloadsを複数のクラウドで動かすことも可能ですが、それは最大公約数的な仕様に合わせることを意味し、パブリッククラウドが本来もたらすイノベーションの可能性を犠牲にしてしまいます。
マルチクラウド戦略を成功させたいなら、各アプリケーションを最適なクラウド上で設計・構築するのが理想です。しかし現実には、分析よりも目先の都合でworkloadsの配置先が決まってしまうことも少なくありません。各クラウドの強みと自社のビジネスユースケースとの相性を見極めることが欠かせません。選んだクラウド上でworkloadsがどう動くかを示す信頼できるデータがなければ、配置先の判断は調査ではなく運任せになってしまいます。
オープンソースがベンダーロックイン回避に役立つ理由
独自プラットフォームへの依存を減らすために、利用者はさまざまなオープンソースのクラウドコンピューティングプラットフォームやツールを活用できます。オープンソースを使えば、技術選定とクラウドベンダー選定を実質的に切り離せます。開発者はworkloadsや環境のデプロイ・プロビジョニング・管理にあたり、これらのプラットフォームやツールのソースコードを自社要件に合わせて柔軟にカスタマイズできます。
ソフトウェアのデプロイ、スケーリング、管理を自動化するコンテナオーケストレーションシステムKubernetesと、サービスメッシュIstioは、いずれもGoogleによってオープンソース化されました。Googleはオープンソースコミュニティを牽引する主要な貢献者として確固たる地位を築いています。
たとえば、Google Cloud Platform(GCP)の多くのツールはオープンソース技術を基盤としており、GCPはその上に運用管理レイヤーを重ねて付加価値を提供し、利用者がスムーズに採用できるようにしています。Google Kubernetes Engine(GKE)や、Dataflow、Cloud Composer、Managed Service for Prometheus、Cloud Data Fusionといったサービスは、同じビジネスロジックを別の場所でもそのまま実行できるよう設計されており、運用部分を実装し直すだけで移行可能です。
GoogleのAnthosのようなプラットフォームは、ハイブリッドマルチクラウドでのアプリケーションモダナイゼーションを実現し、GCP、AWS、Azure、プライベートクラウド、ベアメタル上でKubernetesクラスターやVM(プライベートプレビュー)をオーケストレーション・実行できるようにします。Kubernetesをクラウド全体の基盤に据えていなくても、パブリッククラウド内で動く一部のworkloadsをオーケストレーションする用途で十分役立ちます。
オープンソースソフトウェアの将来を確かなものにするには、企業が従業員によるオープンソースへの貢献を奨励し、インセンティブを設けることが大切です。CNCFの最新レポートによると、いまや96%の組織がKubernetesを利用しており、その他のクラウドネイティブなオープンソースプロジェクトもこの1年で爆発的に増えています。オープンソースソフトウェアは効果的なマルチクラウド戦略を後押しし、企業が単一クラウドに縛られる事態を防ぐ助けになります。
ただし、オープンソースサービスに大きく依存する場合にはトレードオフがあります。Day 2運用の責任を自社で背負うことになるのです。監視、アップデート、セキュリティ対策をすべて自前で行う必要があり、そのために要する追加のリソースやプロセスに見合うとは限りません。
また、サポート体制は最小限で、SLAらしきものもほぼないなかで運用しなければならず、本番環境で障害が発生しても基本的には自力で対処することになります。重要なサービスに機能を追加したいときも同様です。エンジニアは自社プロダクトのコア機能を強化する時間を削って、オープンソースコミュニティへの貢献に充てなければなりません。マルチクラウド戦略と同じく、ベンダーロックイン回避のためにオープンソースだけに頼るのも答えにはなり得ません。
次の一手
では、ベンダーが課しうる制約から解き放たれ、クラウド本来の力を引き出すにはどうすればよいのでしょうか。主要クラウドプロバイダーすべてに精通したパートナーと組むことで、選んだクラウドベンダーから最大限のビジネス価値を引き出せるクラウド戦略を描くことができます。
DoiTのチームは、企業が複数のクラウドを使いこなしてビジネス目標を達成するのを支援してきた豊富な実績を持つだけでなく、クラウド運用を効率化し、複雑な技術課題を解決し、独自プラットフォームへの依存を軽減するためのオープンソースツールも開発・提供しています。適切なアプローチを取れば、既存ベンダーの強みを活かしながら、パブリッククラウドが約束する柔軟性を余すところなく享受できるのです。