あらゆるクラウドで実行: クラウドの移植性を検討しましたか?

クラウド ポータビリティは、スケーラブルで回復力のあるクラウド ネイティブ アプリケーションを構築するための戦略です。クラウド ネイティブについて話すとき、通常はクラウドのポータビリティも暗黙的に考慮されます。クラウド ネイティブは、クラウド コンピューティング リソースの弾力性と俊敏性を最大限に高めるアプリケーション開発およびデプロイメント アーキテクチャへのアプローチです。しかし、チームが単一のクラウド プラットフォームを使い始め、そのプラットフォームのベンダーが提供する特殊なツールやマネージド サービスを中心に構築すると、すぐにベンダー ロックインに直面します。

Akamai クラウドコンピューティングの詳細を読む

ポータブル ワークロードは、さまざまなコンピューティング環境やインフラストラクチャ プラットフォーム間で簡単に移動、展開、管理できます。これにより、企業はベンダーロックインを回避し、クラウド戦略の柔軟性を維持できます。

最初からクラウドに依存しないアプローチを選択し、あらゆるクラウド プラットフォームと互換性のあるツールを使用すれば、ニーズの変化に応じて柔軟に変更を加えることができます。移植性戦略により、リソースがどのように、なぜ使用されるかについての理解が深まり、アプリケーションやビジネス ニーズに基づいて、さまざまなクラウド プラットフォームを選択したり、クラウド プラットフォーム間を移動したりできるようになります。

クラウドポータビリティ戦略を設計する

クラウド アプリケーション アーキテクチャを検討している場合、成功するポータブル ワークロードの設計を開始するために考慮すべき 5 つの事項を以下に示します。

ニーズを判断する

ポータブルなワークロードを実現するための最初のステップは、ワークロードの要件を客観的に決定することです。次のような状況はよく見られます。クラウド プロバイダーの魅力的なサービスに人々の目が惹かれ、最初のステップを踏む前に主観的な仮定がすでにプロセス全体に浸透しているのです。つまり、ここでのポイントは、クラウド プラットフォームを検討する前に、ニーズの範囲を定めるということです。

これは、最終結果を満たすために必要なすべての機能と特徴を理解するためのシンプルなアプローチを採用し、それらの要件を満たすソフトウェア スタックと依存関係、およびその他のコンポーネントを決定するようなものです。このように客観的かつ簡潔な視点を持つことは、広角レンズを通して雲を観察するようなものです。このアプローチにより、あらゆるクラウド プラットフォームのコア クラウド インフラストラクチャ上で実行できるさまざまな機能がより強調されます。

ロックポイントを決定する

アプリケーションがまだ構築段階または計画段階にあるか、またはすでにクラウド プラットフォーム上で開発および展開されているかにかかわらず、現在のアーキテクチャ設計を評価して、現在のプラットフォームで使用されている固有のコンポーネントとサービスを検出する必要があります。

潜在的なベンダー ロックインのポイントを特定した場合は、時間をかけて具体的な理由を評価してください。まず、次の質問に答えてください。

• より迅速な発売や市場投入までの時間の短縮を実現するためのソリューションを選択、または少なくとも検討しましたか?
• ソリューションは協議の結果として決定されるのか、それともプラットフォーム上の他のサービスとのサポート/相互運用性に基づいて決定されるのか?
• このソリューションを選択した場合のコストは、現在のコストと比べてどのように変化しましたか?

これらの質問に答えたら、理想的なオープンソース ソリューションまたは同じまたは類似の機能を提供できる他の代替ソリューションの計画を開始し、実装に必要な作業を評価し、実行計画を策定できます。すべての評価を行った後でも、特定のプラットフォームのサービスに固執することに決めた場合は、必ず終了戦略を用意してください。クラウド コンピューティング ベンダー ロックインには、アーキテクチャ ロックインと運用ロックインの 2 つの形式があります。独自のクラウド サービスに関するよく考えられた出口戦略により、両方の懸念を軽減できます。

スケーラブルで持続可能なビルド

負荷分散テクノロジーを活用し、コンテナ化、コンピューティングインスタンスイメージ、構成管理、ステートフルコンポーネントとステートレスコンポーネントの分離を組み合わせることで、水平スケーリングと分散をスムーズに実現できます。可能であれば、状態は宣言的であり、単一の「真実のソース」によって維持および管理され、自動的に複製および同期される必要があります。

モジュラー設計

モノリシック アーキテクチャは扱いにくくなり、管理が困難になり、移植可能な方法で変更を加えるために必要な柔軟性が低下します。したがって、ワークロードは、明確に定義されたコンポーネントが疎結合システムとして連携して動作するようにモジュール方式で設計する必要があります。クラウドネイティブ設計により、ワークロード全体に影響を及ぼすことなく個々のコンポーネントを更新または置き換える効率的なプロセスが提供され、最終的には保守性、適応性、移植性が向上します。

すべてはコードだ

クラウドネイティブ アプリケーションを開発している場合は、ワークロードのすべての部分 (アプリケーション、インフラストラクチャ、構成管理) をコードとしてコード化する宣言型デプロイメント アプローチに精通している必要があります。このアプローチにより、新しい環境 (開発、ステージング、テスト環境など) を自動的に展開したり、既存の環境を複製したりすることができます。これにより、ブルー/グリーンの展開プロセスが簡素化され、災害発生時に迅速な復旧が可能になります。

GitOpsアプローチは、移植性への単一のパスを提供し、自動化されたパイプラインの信頼性の利点を通じてデプロイメントを標準化し、コンプライアンス/監査の可視性を向上させ、ポリシーをコードとして適用します。

上記の 5 つの側面を考慮することで、独自のニーズに基づいて適切なクラウド ポータビリティ戦略を策定し、クラウド ネイティブ アプリケーションに真の柔軟性をもたらし、あらゆるクラウド プラットフォームでワークロードをスムーズに実行および移行できるようにし、あらゆる面でクラウド ネイティブが提供する価値を享受できるようになります。

クラウドサービスの購入やクラウド移行も検討されている場合は、

Akamai Linodeのソリューションについて詳しくは、リンクをクリックしてください。