企業がクラウドロックインを回避するための 4 つの重要な技術決定

[51CTO.com クイック翻訳] すべてのクラウドプロバイダーには、企業や開発者をそのプラットフォーム上で製品を構築するよう誘致する主力サービスがあります。これらの主力サービスはプラットフォーム上の他のサービスとうまく連携しますが、他のパブリック クラウドとの相互運用性が制限されることが多く、クラウド ベンダーのロックインにつながります。ロックインを受け入れる理由はいくつかあります。ロックインによって、企業は生産性を高め、ユーザーに価値をより早く提供できるようになります。

Render では、オンプレミスのワークロードを追加する計画で、複数のパブリック クラウドにまたがる新しいクラウド プラットフォームを構築しており、単一のプロバイダーに縛られないようにすることが重要です。この記事では、単一のクラウド プロバイダーへのロックインを回避し、ハイブリッド クラウドの将来に備えるために私たちが行った重要な技術的決定について説明します。

図 1: この図は、2 つの例示的なテクノロジー スタックを視覚的に示しています。左側はクラウド ロックインのないテクノロジー スタック、右側はクラウド ロックインを採用したテクノロジー スタックです。

インフラストラクチャ・アズ・コード

Infrastructure as Code (IaC) は、今日のほとんどのソフトウェア企業にとって必須の要件です。これはあらゆるテクノロジー スタックの基礎であり、一度選択すると変更するのは困難です。人気のある選択肢としては、AWS CloudFormation、Terraform、Pulumi、Chef、Ansible などがあります。

AWS CloudFormation は、AWS 製品をフル活用する企業にのみ適しています。 Terraform は多くの組織で人気がありますが、新しいドメイン固有の言語を学習する必要があります。すでに知っている言語を使用したい場合は、Pulumi (Node.js、Go、Python、.NET Core)、Chef (Ruby)、または Ansible (Python) の方が適している可能性があります。最終的に、成熟したエコシステムと幅広いクラウド プロバイダーのサポートを理由に、Terraform と Ansible を使用しました。 Ansible はマシン イメージを構成するための最適なツールであり、Terraform はインフラストラクチャ コンポーネントのプロビジョニングや複数のパブリック クラウド上のネットワークの構成に適しています。

構成とシークレット

すべての本番レベルのアプリケーションは、構成変数とシークレットにアクセスする必要があります。これらは、専用の暗号化された、簡単にアクセスできる場所に保存するのが最適です。クラウド プロバイダーは、このデータを安全に保存してアクセスすることを容易にする API 駆動型製品を提供しています。AWS Secrets Manager、AWS SSM パラメータ ストア、Google Cloud Secret Manager はすべてこのような製品の例であり、ユーザーは基盤となるストレージと暗号化を管理する必要がなくなります。ただし、API 経由でこれらのサービスにアクセスするには、IAM ログイン情報が必要であり、クラウド間で移植できません。

当社の構成およびシークレット管理ソリューションは、データに対する完全な制御、すべての主要なクラウド プロバイダーとの連携、そして当社の成長に合わせて簡単に拡張できるものでなければなりませんでした。専門家によってレビューされたソースコードへのアクセスも重要です。 Vault は最終的に当社のすべての要件を満たし、セットアップと管理がより簡単になるという利点も加わりました。

サービスオーケストレーション

Kubernetes は過度に複雑になる可能性がありますが、パブリック クラウドとプライベート データ センター全体でサーバー/コンテナー オーケストレーションを統合する便利な抽象化を提供します。私たちのチームには以前から Kubernetes の経験があり、欠点はあるものの、コミュニティの急速な成長と開発のペースから、他のオーケストレーション ツールよりも Kubernetes を選択しました。

当社は当初、できるだけ早く市場に参入することに重点を置いていたため、マネージド Kubernetes サービスを使用することを決定しました。しかし、毎月数十億件のリクエストを処理していたため、複数のクラウドにまたがるホスティング ソリューションで複数の制限やソフトウェア バグも発生しました。最終的に、コントロール プレーンへのアクセスと可視性が不足していたため、当初の設定では不十分であり、独自の Kubernetes クラスターを管理する必要があることが明らかになりました。同時に、すべてのクラスターで同じ Kubernetes 管理プリミティブを使用することが重要でしたが、これは、別のクラウド プロバイダーのマネージド Kubernetes を使用した場合には当然不可能でした。 Render のフランクフルト ホスティング リージョンの立ち上げは大きなマイルストーンでした。Render をマルチリージョン、マルチクラウド プラットフォームに変えただけでなく、Kubernetes を根本から管理する専門知識を構築することにも役立ちました。

Kubernetes ロックインを採用することで、クラウド ロックインを回避できたようです。しかし、UX に関する私たちの決定はここで大いに役立ちました。私たちは、単なる別のマネージド Kubernetes プラットフォームになることを避け、代わりに Render を UX 重視のプラットフォームにすることに完全に焦点を合わせ、Kubernetes を顧客に公開しないことを選択しました。これにより、ユーザーのニーズに最適な社内またはサードパーティのオーケストレーション ツールにいつでも移行できます。

メッセージキュー

分散システムに新しいコンポーネントを追加すると、複雑さが劇的に増加し、すぐに管理者にとって悪夢になる可能性があります。メッセージ キューは、新しいサービスがすべての既存および将来のサービスと通信するための単一の統合ポイントを提供することで、この問題の解決策を提供します。パブリック クラウドは、独自のキュー サービスと統合することで、デフォルトでロックインを作成します。たとえば、Google は BigQuery と Pub/Sub 間のネイティブ統合を提供しており、AWS では SQS を Lambda、RDS、Redshift、その他の AWS コンポーネントと非常に簡単に接続できます。

メッセージング ロックインに対する当社のソリューションはシンプルです。自己ホスト型の Redis Pub/Sub と優れたオープン ソース マシン プロジェクトを使用して、Redis 上に Golang キューの抽象化を提供します。これにより、必要に応じてアプリケーション コードを変更せずに別の OSS キューに交換できます。当社のメッセージ キュー アプローチは、1 日あたり 1 億件を超えるイベントを処理できる規模に拡張されており、コードを 1 行も変更せずにメッセージ キューを新しいクラウドやリージョンに展開できます。

原題: クラウド ロックインを回避するテクニック、著者: Shantanu Joshi

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。