マルチクラウド アプリケーションを構築するための 4 つのヒント

一般的に、マルチクラウドに関する議論を推進する力は 2 つあります。組織が必要とするクラウド コンピューティング ツールとプラットフォームを自由に選択できることと、それらの選択に伴う複雑さです。

必ずしも簡単ではありませんが、組織が環境間で一貫性を保ち、ベンダー ロックインを回避する IT を設計する方法はあります。企業は、マルチクラウド アプリケーションの構築方法に関するアドバイスに従い、そうする価値がない場合を理解する必要があります。

マルチクラウドアプリケーションを構築する前に、これらの要素を考慮してください。

停止、価格変更、ベンダーとの関係の悪化、その他の理由にかかわらず、多くの企業は、適切なときに適切な場所にコードを移動できるようにアプリケーションを構築したいと考えています。

しかし、クラウドに依存しないコードを書くには、プラットフォーム固有のツールを避けるだけでは不十分です。複数のクラウド プラットフォームで使用できるアプリケーションを構築するときに留意すべき 4 つの要素は次のとおりです。

1. パスワードや API キーなどの機密情報をソース コードに含めないでください。

2. アプリケーションに単一のエントリ ポイントを提供します。障害点のリスクを最小限に抑えるには、ラウンドロビン DNS レコードを使用して、クラウド コンピューティング プロバイダー間で負荷を分散します。

3. 複雑さを最小限に抑えるために、可能な限り自動化します。

4. ネイティブ ツールを完全に排除しないでください。クラウド コンピューティング ベンダーが真にユニークで価値のあるサービスを提供している場合や、特定のツールを回避するコストがベンダー ロックインのリスクを上回る場合もあります。

移植性をいつ、どのように計画するかを検討する

組織が特定のクラウド プラットフォーム向けにワークロードを最適化すればするほど、後でそれらのアプリケーションを移行することが難しくなります。 IT チームが移植性を実現したい場合は、使用するサービスの影響と、アプリケーションを特定のプラットフォームに固定する方法を理解する必要があります。

たとえば、クラウド プロバイダーは競合他社と同等の機能を求めていますが、それによってクラウド間でのワークロードの移行が必ずしも容易になるわけではありません。 2 つのプロバイダーが同等のサービスを提供している場合でも、それらは異なる API を通じて提供されます。開発者は、他のクラウド プラットフォームで動作するようにコンポーネントを書き直す必要があります。

ただし、モビリティは絶対的なものではありません。実際、ワークロードに適したプラットフォームを見つけることは、コストが高くても、長期的にはコスト効率が高くなります。企業に相互接続されたアプリケーションがある場合は、トラフィック コスト、統合、セキュリティの問題を制限するために、それらのアプリケーションを自社のデータ センターでホストするのが最適です。

プラットフォームの違いを克服する

マルチクラウド戦略を導入する組織は、異なるクラウドに導入されたアプリケーションのパフォーマンスが異なるという事実を補う必要があります。企業は、拡張を 1 つのクラウド プラットフォームに制限したり、異なるクラウドで並列展開を実行したり、特定のコンポーネントを抽象化したりすることで、これを実現できます。

組織が Apache Mesos や Kubernetes などのソフトウェアを使用してデプロイメントを均一化し、アプリケーション プレーンを抽象化したり、Ansible、Chef、Puppet などの DevOps ツールを使用したりする場合は、スケールと再デプロイのアプローチが採用されます。

並列デプロイメントの実行は、スケールおよび再デプロイの方法に似ていますが、トランザクションやその他のタスクは共有されます。これには、重複するアプリケーション コンポーネント間でロード バランサーを使用する必要がありますが、クラウド間で移動されるのは作業のみであるため、特別なデプロイメント手法は必要ありません。

アプリケーション コンポーネントをクラウド プラットフォーム間で拡張またはフェイルオーバーする必要がある場合、IT チームはアダプタ設計パターンに基づく何らかの独自のミドルウェアを使用できます。これにより、さまざまなクラウド プラットフォーム プロバイダー API が単一の API にまとめられ、開発者が使用できるようになります。プロバイダーのサービスが異なる場合は、より高レベルの抽象化を作成して、組織の API を各クラウドの特定の機能にマッピングします。

継続的インテグレーションと継続的デリバリー（CI/CD）パイプラインを簡素化

クラウド プロバイダーに依存しない継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用すると、マルチクラウド アプリケーションの展開プロセスを簡素化できます。IT チームがこのルートを選択する場合、いくつかのオプションがあります。

ほとんどのクラウド コンピューティング プロバイダーは、安全なファイル転送プロトコルをサポートしています。エラーが発生しやすい一方で、開発者はこれを使用することで、デプロイメントの性質を維持しながらエンドポイントを交換、更新、または削除できます。

IT チームはコンテナを使用してアプリケーション ビルドを一元化し、アプリケーション コード全体を複数の環境に展開する必要がなくなります。アプリケーション イメージは、任意のクラウドからアクセス可能なコンテナ リポジトリに保存でき、開発者は特定のプロバイダーのオーケストレーション ツールを使用してアプリケーション イメージを起動できます。

企業が依然としてクラウドネイティブ サービスを使用したい場合は、移植性が低下し、複雑さが増す可能性がありますが、依存関係の分散に対処するための他の方法があります。たとえば、コンテンツ配信ネットワーク アセットをアップロードするためのツールを備えているプロバイダーが 1 つしかない場合は、宛先が別のクラウドであっても、その CDN にコンテンツをアップロードするときは必ずそのクラウドを使用するようにしてください。

アプローチに関係なく、企業はクラウド内の負荷を分散するために、各環境で実行される展開後のタスクも決定する必要があります。同様に、クラウド プラットフォームが増えると複雑さが増すため、アプリケーションが依存するホスト機能と、追加の配管工事が必要となる方法に注意してください。