この記事きじはQiitaのアドベントカレンダー記事きじのリバイバル公開こうかいです。
※ 当時とうじの記事きじから、一部いちぶ表現ひょうげんを見直みなおし加筆かひつしています。

はじめに

先日せんじつガートナーのレポートで「多おおくの企業きぎょうにおいて、特定とくていのクラウドベンダーにシステムを集中しゅうちゅうさせるリスクの重要じゅうよう度どが上昇じょうしょうしている」との発表はっぴょうがありました。

https://www.gartner.com/en/newsroom/press-releases/2023-10-30-gartner-says-cloud-concentration-now-a-significant-emerging-risk-for-many-organizations

日本にっぽんにおいてクラウドの活用かつようはますます進すすんでいる一方いっぽうで、特定とくていの Cloud Service Provider（CSP）にロックインされるリスクについては、常つねに議論ぎろんの余地よちがあると考かんがえています。
本ほん記事きじでは、特定とくていのクラウドに強つよく依存いぞんしないアーキテクチャについて「Cloud Agnostic Architecture」という言葉ことばを用もちいて整理せいりしていきます。

Cloud Agnostic Architecture とは

Cloud Agnostic¹ Architectureとは「特定とくていのクラウドに依存いぞんしないアーキテクチャ」を意味いみします。これはクラウドプラットフォーム自体じたいを利用りようしないという意味いみではなく、複数ふくすうのクラウドプラットフォーム間あいだ（ないしはオンプレミスとクラウドのハイブリッドモデル間あいだ）で、アプリケーション、ツール、サービスを含ふくむワークロードをシームレスに移植いしょくできるように設計せっけいすることを意味いみしています。

このアーキテクチャには次つぎのようなメリットがあります。

• クラウドロックイン²の回避かいひ
  何なにかしらの事情じじょうにより今こん利用りようしているクラウドプラットフォームから他たのクラウドプラットフォームへ移行いこうしなければならない（もしくは移行いこうすることでコスト面めんなどの恩恵おんけいを受うけられる）状況じょうきょうが発生はっせいした場合ばあいに、コストや時間じかんをかけずに移行いこうすることが可能かのうとなります。

• より広範こうはんなロケーションへのシステム展開てんかい
  複数ふくすうのクラウドプラットフォームを利用りようすることでより多おおくのロケーション（リージョン）にシステムを展開てんかいできるだけではなく、各かくロケーションに適てきしたクラウドプラットフォームを選択せんたくできるようになります。
  これは例たとえば、グローバルにシステムを展開てんかいするようなケースおいて、通常つうじょうは AWS を利用りようするが、中国ちゅうごくにおけるシステム展開てんかいにおいては、中国ちゅうごくの CSP（Alibaba CloudやTencent Cloud）を利用りようすることで、法ほう制度せいど的てきなリスクを最小さいしょう化かするといったことが考かんがえられます。

• マルチクラウド構成こうせいの容易よういな実現じつげん
  DR 対策たいさくとして複数ふくすうのクラウドプラットフォーム上じょうにシステムを展開てんかいしておくなど、冗長じょうちょうデプロイが必要ひつようなマルチクラウド構成こうせいをとることが容易よういになります。

Cloud Agnostic Architecture を実現じつげんするためのアプローチ

この章しょうでは Cloud Agnostic Architecture を実現じつげんするためのいくつかのアプローチを紹介しょうかいします。

OSS技術ぎじゅつの採用さいよう

CSPプロプライエタリなマネージドサービスを利用りようするのではなく、マネージドなオープンソースサービス（ないしはOSS互換ごかん性せいのあるサービス）を利用りようや、真しんに必要ひつような場合ばあいはOSSのセルフホスティングを行おこないます。

AWS を例れいに OSS / OSS互換ごかんのサービスとプロプライエタリなサービスの一いち例れいをみてみると、選択肢せんたくしがいくつかあることがわかるでしょう。

主要しゅような OSS / OSS互換ごかんのサービスは、基本きほん的てきにそれ自体じたいが業界ぎょうかい標準ひょうじゅん的てきな技術ぎじゅつ仕様しように準拠じゅんきょする形かたちで設計せっけいされており、メジャーなものは多おおくのクラウドプラットフォームにてマネージドサービスとして提供ていきょうされているため（もしくは提供ていきょうされていない場合ばあいでも、IaaSとしてのコンピューティングサービス上じょうにホスティングすることで、クラウドプラットフォームに依存いぞんせず利用りようできるため）、積極せっきょく的てきに利用りようすることでクラウドの移植いしょく性せいを高たかめることができます。

コンテナ技術ぎじゅつの採用さいよう

Dockerに代表だいひょうされるコンテナ型がたの仮想かそう化か技術ぎじゅつによりホスト環境かんきょうとアプリケーション環境かんきょうを分離ぶんりすることで、アプリケーションのポータビリティが向上こうじょうし、別べつのクラウドプラットフォームにアプリケーションを移行いこうしやすくなります。

独立どくりつ性せいのある DevOps の実践じっせん

特定とくていのクラウドに依存いぞんしない DepOps のツールやサービスを活用かつようし、ワークフローを自動じどう化かすることで、別べつのクラウドプラットフォームへのスイッチングコストを低ひくくできます。具体ぐたい的てきにどのようなものなのか、いくつか例れいを紹介しょうかいしましょう。

Infrastructure as Code

CSP プロプライエタリなサービス（例れい. AWSであればAmazon CloudFormation
やAWS CDK, GCPであればCloud Deployment Manager）ではなく、 Terraform や Crossplane に代表だいひょうされる複数ふくすうのクラウドに対応たいおうしたOSSのツールを活用かつようすることで、特定とくていのクラウドに依存いぞんしない IaC を実現じつげんできます。

Observability

可か観測かんそく性せい（Observability）を実現じつげんするためのツールやサービスは数多かずおおくありますが、複数ふくすうのクラウドに対応たいおうしたものを採用さいようし、一元いちげん的てきなモニタリングを行おこなうことで、特定とくていのクラウドに依存いぞんしない独立どくりつ性せいの高たかい Observability 基盤きばんを実現じつげんできます。

CNCFのCloud Native Landscapeを見みてみても様々さまざまなツールやサービスがありますが、OSSを活用かつようする一いち例れいとしては、データ可視かし化かにGrafana、メトリクス監視かんしにPrometeus、ログ監視かんしにGrafana Loki、トレース監視かんしにGrafana Tempoを採用さいようする（あるいはこれらをマネージドサービスとして提供ていきょうするGrafana Cloudを利用りようする）といった形かたちが考かんがえられます。

あるいは New Relic や DataDog といったSaaSを利用りようすることも有効ゆうこうです。もちろんこれらのサービスはマルチクラウドに対応たいおうしています。

1点てん補足ほそくをしておくと、CSPプロプライエタリなモニタリングサービスでしか直接ちょくせつメトリクスを取得しゅとくできないものがある（例れい. Amazon Aurora や AWS Lambda のメトリクスは Amazon CloudWatchでしか取得しゅとくできない）ため、CSPプロプライエタリなモニタリングツール（例れい. AWS であればAmazon CloudWatch）を完全かんぜんに利用りようしないというケースはあまり考かんがえられません。Amazon CloudWatch が提供ていきょうするデータを Prometheus に連携れんけいするといったように、独立どくりつしたObservability 基盤きばんに一元化いちげんかしていくアプローチになります。

CI/CD

CI/CDについても他たと同様どうよう、CSPプロプライエタリなサービスではなく、特定とくていのクラウドに依存いぞんしないツールやサービスを活用かつようしてパイプラインを構築こうちくすることで、クラウドプラットフォームの移植いしょく性せいが高たかくなります。
この領域りょういきにおいては、既すでに GitHub Actions や Circle CI といった特定とくていのクラウドに依存いぞんしないツールやサービスが広ひろく使つかわれており、AWSのCode Family³のようなCSPプロプライエタリなサービスが活用かつようされるケースよりも主流しゅりゅうになっています。

適切てきせつな抽象ちゅうしょう化か

アプリケーションのレイヤにおいて、適切てきせつに抽象ちゅうしょう化かされたインタフェースを用もちいてCSPの提供ていきょうするサービスとやりとりを行おこなうことで、コアとなるビジネスロジックが特定とくていのCSPに依存いぞんしない疎うと結合けつごうなつくりが実現じつげんできます。これにより、別べつのクラウドプラットフォームのサービスに切きり替かえを行おこなう（例れい. Amazon S3ではなくGCSを使用しようする）場合ばあいでも、既存きそんのソースコードへの影響えいきょうを最小限さいしょうげんに抑おさえることが可能かのうとなります。
クリーンアーキテクチャやリポジトリパターンなどを実践じっせんして自身じしんでインタフェースを定義ていぎするのも良よいですし、GoCDK や Apache jclouds のような各かくクラウドサービスやOSSプロダクトへの透過とうか的てきなインタフェースを提供ていきょうするライブラリを活用かつようする方法ほうほうもあります。

トレードオフを理解りかいする

Cloud Agnostic Architecture はそれ自体じたいが銀ぎんの弾丸だんがんではないため、トレードオフを理解りかいした上うえで採用さいようすることが重要じゅうようとなります。
先述せんじゅつしたように Cloud Agnostic Architecture を採用さいようすることで、クラウドの移植いしょく性せいが向上こうじょうします。一方いっぽうで、クラウド非ひ依存いぞんを目指めざすということは、同時どうじに「クラウドのネイティブ機能きのうを最大限さいだいげん活用かつようしない」という判断はんだんを（多おおかれ少すくなかれ）していることでもあり、常つねにクラウドプラットフォーム間あいだの差異さいを抽象ちゅうしょう化かすることを意識いしきする必要ひつようがあります。そのため、時ときには複雑ふくざつ性せいが増まし、プロダクトを市場いちばに投入とうにゅうするまでの時間じかんが大おおきくなる可能かのう性せいもあります。

CSPプロプライエタリなサービスのメリットの1つとして「サービス間あいだのシームレスな連携れんけい」が挙あげられますが、ここでは具体ぐたい的てきな例れいとして、オブジェクトストレージへの操作そうさをトリガーとして、非同期ひどうき処理しょりを実行じっこうするケースを考かんがえてみましょう。

AWSネイティブなサービス/機能きのうを採用さいようする場合ばあい、S3 のイベント通知つうちを利用りようして、Lambda 関数かんすうを実行じっこうするアーキテクチャが考かんがえられます。
S3のイベント通知つうちは At Least Once の到達とうたつが保証ほしょうされてますが、イベントはS3内部ないぶでコントロールされるため、オブジェクト操作そうさ側がわの処理しょりでイベントの作成さくせいを意識いしきすることはありません。また、非同期ひどうきで呼よび出だされる処理しょりについても、Lambdaの機能きのうとして起動きどうトリガーやリトライ回数かいすう、DLQの送信そうしん先さきなどの設定せっていができるため、開発かいはつ者しゃはコアとなる処理しょりのみに集中しゅうちゅうできます。
このようにアプリケーションコードを必要ひつよう最小限さいしょうげんに保たもちながら簡単かんたんに連携れんけいを実現じつげんできる点てんが、このアーキテクチャの1つのメリットだと言いえます。

一方いっぽうで、このワークロードを別べつのクラウドプラットフォームに移植いしょくしようとした場合ばあい、それは簡単かんたんでしょうか。オブジェクトストレージのイベントをトリガーとして処理しょりを実行じっこうする機構きこうは移行いこう対象たいしょうのクラウドプラットフォームに備そなわっているのでしょうか。備そなわっていたとして管理かんり対象たいしょうとなっているイベントは充足じゅうそくしている⁴のでしょうか。
さらに言いえば、非同期ひどうきで呼よび出だされる処理しょりにおいては、少すくなくともイベントをハンドリングする部分ぶぶんの処理しょりはクラウド依存いぞんしているため、ソースコードの修正しゅうせい/追加ついかが必要ひつようとなります。
このようにクラウドの移植いしょく時じに困難こんなんが生しょうじ得える、そのための変更へんこうに時間じかんがかかるというのがこのアーキテクチャのデメリットでもあります。

次つぎにこれを Cloud Agnostic Architecture で実現じつげんする例れいを見みてみます。
AWSネイティブなS3のイベント機構きこうは利用りようせず、代かわりにマネージド Kafka を使用しようしてイベントメッセージの管理かんりを行おこないます。またコンピューティンレイヤも コンテナベースのアーキテクチャを採用さいようします。

これによりAWSプロプライエタリなサービスに依存いぞんする部分ぶぶんが小ちいさくなり、代かわりにクラウドの移植いしょく性せいが高たかまります。
ただし、このようなアーキテクチャを採用さいようすることで、イベントメッセージの到達とうたつ保証ほしょうやエラー時じのハンドリングなど、CSPに任まかせていた部分ぶぶんを自分じぶん自身じしんで設計せっけい・実装じっそうする必要ひつようがでてくるかもしれません。また、S3イベント通知つうちと同等どうとうの可用性かようせいや性能せいのうを担保たんぽするためには、時ときには追加ついかのコストが必要ひつようになるかもしれません。

このようにそれぞれのアーキテクチャは一長一短いっちょういったんであり、トレードオフを理解りかいすることが重要じゅうようです。

クラウド依存いぞんする or 依存いぞんしないの2択よではない

ロックイン自体じたいが「ロックインする or しない」の2値ちで語かたられるものではないのと同様どうよう、Cloud Agnostic Architecture は 特定とくていのクラウドに「依存いぞんする or 依存いぞんしない」の2択よではなく「どの程度ていどクラウド間あいだの移植いしょく性せいを高たかめるか」の度合どあいで、評価ひょうかされるべきものです。

例たとえば、コスト面めんの観点かんてんからAWS Lambda を採用さいようするが、イベントをハンドリングする部分ぶぶんはコアロジックと分離ぶんりし疎うと結合けつごうな作つくりにする、イベントソースは原則げんそく API Gateway に限定げんていする、などの方針ほうしんを持もつことで、無尽蔵むじんぞうに依存いぞん度どが高たかまらないようにするなどといったように、トレードオフの世界せかいで最適さいてきな解かいを見みつけることになります。
主要しゅようなコンピューティングやデータベースの領域りょういきは強つよく移植いしょく性せいを意識いしきし、運用うんよう管理かんり系けいの機能きのうは最大限さいだいげんクラウドネイティブの恩恵おんけいを享受きょうじゅする、という戦略せんりゃくも有効ゆうこうでしょう。

何なにが最適さいてきかというのは、対象たいしょうとなるシステムが置おかれている状況じょうきょうに応おうじてさまざまです。
例たとえば、市場いちばまでの投入とうにゅう時間じかんが重要じゅうような要件ようけんであるスタートアップにおいては、クラウドの移植いしょく性せいを犠牲ぎせいにしてでも、CSPプロプライエタリなサービスを積極せっきょく的てきに利用りようする方ほうが良よいかもしれません。逆ぎゃくに特定とくていのCSPに依存いぞんすることが大おおきなリスクとなり得えるクリティカルなシステムや、グローバル展開てんかいに伴ともないマルチクラウド対応たいおうが前提ぜんていとなるシステムにおいては、クラウドの移植いしょく性せいが重要じゅうような要件ようけんになることでしょう。

このように唯一ゆいいつの正解せいかいはありませんが、1つだけ不ふ正解せいかいと言いえる選択せんたくは存在そんざいします。
それは、ロックインのリスクを適切てきせつに評価ひょうかせず、システム全体ぜんたいとしてのポリシーをろくに定さだめないまま、個別こべつ最適さいてきを追求ついきゅうしてCSPプロプライエタリなサービスを無闇むやみやたらに採用さいようすることです。

適切てきせつにリスクアセスメントを行おこなった上うえで、指針ししんを定さだめることが重要じゅうようとなります。

ロックインは完全かんぜんに回避かいひできない

最後さいごに Cloud Agnostic Architecture を採用さいようしたからといっても、システムにおけるロックインは完全かんぜんに回避かいひできるものではない点てんを補足ほそくしておきます。
システムにおけるロックインは、本ほん記事きじで取とり上あげた CSP ロックインだけでなく、プロダクトロックインやバージョンロックイン、スキルロックインなどさまざまな次元じげんに分類ぶんるい⁵できます。

例たとえば、CSP ロックインを回避かいひするために、OSS互換ごかんのサービスを積極せっきょく的てきに採用さいようしたとしてもプロダクトロックインを回避かいひできているわけではありません。
RDB の世界せかいでは ANSI SQL 標準ひょうじゅんに準拠じゅんきょすることで、DBプロダクトの移植いしょく性せいを高たかめるといった工夫くふうが考かんがえられますが、各かくロックインの次元じげんにおいて、ロックインされることによるリスクを適切てきせつに評価ひょうかした上うえで、どこまで対応たいおうするかの判断はんだんを行おこなうことが求もとめられます。

参考さんこう資料しりょう

• Don’t get locked up into avoiding lock-in
• Modern cloud applications: Do they lock you in?
• 開発かいはつにおけるロックインのリスク評価ひょうかと考かんがえ方かた
• ベンダーロックインを解ときほぐしていくために