クラウドポータビリティに関する3つの考慮事項: 1. クラウドネイティブとコンテナ

市場にはさまざまなクラウドサービスプラットフォームが存在します。自分に最適なものをどのように選びますか?これには慎重な検討が必要になることがよくあります。しかし、もっと重要なのは、クラウドの移植性の問題について検討したことがあるかどうかです。今年、特定のニーズに基づいて選択したクラウドプラットフォームは、将来のニーズを満たすことができますか?満たせない場合、アプリケーションを他のプラットフォームに簡単かつ迅速に移植できますか?

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

海外のクラウドサービスならア・カマイクラウドコンピューティング！

このシリーズの記事では、アーキテクチャや設計、クラウドのポータビリティに関して考慮すべき具体的な詳細、クラウド時代の技術ロックインを最小限に抑える方法、クラウドの柔軟性を最大限に発揮する方法など、さまざまな側面を検討します。

次の記事では、クラウドネイティブとコンテナテクノロジーについて簡単に説明します。

クラウド時代において、コンテナやサーバーレスコンピューティングなどのクラウドネイティブテクノロジーは、移植性の高いアプリケーションの構築に不可欠です。これらのテクノロジーの助けを借りて、より回復力があり、拡張性があり、変化する環境に適応できるアプリケーションを設計できます。実際、これらすべての利点は「ポータビリティ」という一言で説明できます。

ますます煩雑になり、ほとんど管理不能になっているモノリシックモデルとは異なり、クラウドネイティブのマイクロサービスアーキテクチャはモジュール化されています。このアプローチにより、仕事に適したツールを自由に選択し、サービスを使用して特定の機能を実行し、「特化」を通じてより良い結果を達成できるようになります。ここでクラウドネイティブアプローチが効果を発揮し始め、ワークロード全体に影響を及ぼすことなく、アプリケーション内の個々のコンポーネントを更新および置換するための効率的なプロセスが提供されます。開発にクラウドネイティブの考え方を使用すると、アプリケーション、それらをサポートするソフトウェアスタック、および対応するシステム構成を個別にデプロイする宣言型のデプロイメントメソッドが生まれます。

コンテナを使用する理由は何ですか?

コンテナは、特定のタスクを実行するために設計された超軽量の仮想マシンと考えることができます。コンテナは寿命が短い傾向があり、1 分間実行されていても次の瞬間には消えてしまう可能性があるため、永続性がありません。実際には、必要な永続性は、コンテナー自体にバインドするのではなく、ホストファイルシステムまたはマウントされた他のストレージサービスからのブロックストレージをバインドすることによって実現されます。

アプリケーションをコンテナ化することで、移植可能になります。コンテナイメージを準備するだけで、異なるアーキテクチャのCPUで実行されているさまざまなオペレーティングシステムにそれをデプロイし、コンテナを順番に実行できます。コンテナ化されたアプリケーションは、必要な依存関係、ライブラリ、構成ファイルがすべて含まれた自己完結型のスタンドアロンユニットであるため、異なるクラウド環境で実行するときにコードを変更する必要はありません。

簡単に言えば、クラウドネイティブ設計では、コンテナーは次の方法で移植性を実現します。

軽量仮想化:コンテナーは、アプリケーションを実行するための分離された環境を提供します。ホストオペレーティングシステムカーネルを共有しますが、プロセス、ファイルシステム、およびネットワークリソースは分離されます。
移植性と一貫性:コンテナーはアプリケーションとその依存関係をまとめてパッケージ化し、開発環境でも運用環境でもアプリケーションが一貫して実行されるようにします。
リソース効率:コンテナーはプロセスを分離し、ホストオペレーティングシステムのカーネルを共有するため、仮想マシンよりも消費するリソースが少なくなります。コンテナでは、ホストオペレーティングシステム上で実行するための別個の「ゲスト」オペレーティングシステムも必要ないため、オーバーヘッドがさらに削減されます。
高速な起動と展開:コンテナーは完全なオペレーティングシステムを起動する必要がないため、非常に高速に起動し、迅速な展開、スケーリング、回復などのシナリオに最適です。
不変のインフラストラクチャ:コンテナは設計上不変です。つまり、コンテナが一度構築されると、変更されることはありません。この機能により、コンテナの展開、バージョン管理、ロールバックのプロセスが簡素化されるとともに、さまざまな環境での一貫した動作が保証されます。

コンテナの使用を検討する必要があるのはいつですか?

コンテナーは、一貫性を維持しながら、詳細なデバッグ出力など、開発プロセスにおける特定のステージングおよび運用手順を省略するのに役立ちます。開発中にリリースされたコードは、テストおよび展開サイクル全体を通じてそのまま残ります。

コンテナはリソースの使用効率が非常に高く、本質的に非常に軽量です。コンテナは仮想マシンに似ていると上で述べましたが、コンテナのサイズは一般的に数十MB程度で、仮想マシンほど大きくはありません (仮想マシンのサイズは数GBであることが多いですが、より小さいものもありますが、リソースの浪費はより深刻です)。コンテナが軽いほど起動が速くなり、動的なクラウドコンピューティング環境で弾力性と高性能を備えた水平拡張を実現しやすくなります。コンテナも設計上不変です。何かを変更する必要がある場合、その変更をコンテナに埋め込む必要はありません。古いコンテナを破棄して、新しいコンテナを作成するだけです。

さらに、クラウドネイティブモデルの一部としてコンテナーを使用するかどうかを決定する際に考慮すべきその他の要素は次のとおりです。

デプロイメントの一貫性の向上:コンテナーはアプリケーションとその依存関係をまとめてパッケージ化し、異なる環境で実行するときに一貫した動作を保証します。これにより、展開プロセスが簡素化され、構成関連の問題のリスクも軽減されます。
スケーラビリティの向上:コンテナを使用すると、需要の急増に応じて新しいインスタンスをすばやく起動し、アプリケーションの迅速な拡張が可能になるほか、リソースの使用を最適化して全体的なシステムパフォーマンスを向上させることができます。
コスト効率の高いリソース利用:コンテナは従来の仮想マシンよりもはるかに少ないリソースを使用するため、企業は同じハードウェア上でより多くのインスタンスを実行でき、クラウドインフラストラクチャのコストを節約できます。
開発とテストのサイクルを加速:コンテナーにより、開発、テスト、運用環境間のシームレスな移行が容易になり、開発プロセスが簡素化され、新機能やバグ修正のリリースがスピードアップします。
アプリケーション管理を簡素化:コンテナオーケストレーションプラットフォームは、コンテナ化されたアプリケーションの展開、拡張、保守の管理を担当し、ほとんどの運用および保守タスクを自動的に実装して、 ITチームの負担を軽減します。

コンテナのベストプラクティス

コンテナを実行する方法は多数あり、それらはすべて相互運用可能です。たとえば、他のパブリッククラウドプラットフォームから移行する場合は、コンテナイメージを新しい環境に再デプロイするだけで、ワークロードをすばやく移行できます。さらに、さまざまなツールやエンジンを使用してコンテナを実行することもできます。これらのアプローチでは、リソースの利用率と価格が異なります。 Linode ( Akamaiのクラウドコンピューティングサービス) を通じてホストされている場合、ユーザーはLinode Kubernetes Engine ( LKE )を使用して独自のコンテナーを実行したり、仮想マシンを通じてPodman 、 HashiCorp Nomad 、 Docker Swarm 、 Compose を実行したりできます。

これらのオープン標準に準拠したツールは、開発とテストの作業を迅速に完了するのに役立ちます。また、 LKEなどのサービスを使用する場合は、管理を簡素化することでユーザーにさらなる付加価値をもたらすこともできます。 Kubernetes はユーザーのコントロールプレーンになります。ユーザーはこれをコンソールとして考え、さまざまなボタンやノブを使用してコンテナーを制御し、オープンスタンダードに基づくさまざまなツールを使用できます。さらに、 AWS Elastic Container Service (ECS)などのさまざまなプラットフォームネイティブ製品を使用する場合は、さまざまなタイプの使用に対して料金を支払う必要があります。

コンテナに関するもう 1 つの重要なポイントは、コンテナイメージを保存およびアクセスするために何を使用するかを理解することです (これはコンテナレジストリとも呼ばれます)。通常はHarborの使用をお勧めします。 CNCFプロジェクトとして、 Harbor は関連するセキュリティ設定を制御するための専用コンテナレジストリの実行に役立ちます。

コードが最高のパフォーマンスとセキュリティの要件を満たしていることを確認するために、常にテストを実行し、十分に詳細な回帰テストスイートを用意するようにしてください。コンテナにも障害計画が必要です。コンテナに障害が発生した場合、再試行メカニズムはどのようになるでしょうか?再起動するにはどうすればいいですか?これはどのような影響を与えるでしょうか?アプリケーションを回復するにはどうすればよいですか?ステートフルデータはマップされたボリュームまたはバインドマウントされたボリュームに保存されますか?

クラウドネイティブ開発モデルでコンテナを使用する場合は、次のベストプラクティスにも注意する必要があります。

軽量ベースイメージを使用する: Alpine LinuxやBusyBoxなどの軽量ベースイメージから始めると、コンテナーの全体的なサイズが縮小され、攻撃対象領域が最小限に抑えられます。
コンテナオーケストレーションツールを使用する: Kubernetes 、 HashiCorp Nomad 、 Docker Swarm 、 Apache Mesosなどのコンテナオーケストレーションツールを使用して、複数のホスト間でコンテナを管理およびスケーリングします。
コンテナレジストリを使用する: コンテナレジストリ ( Docker Hub 、 GitHub Packages レジストリ、 GitLab Container レジストリ、 Harborなど) を使用して、コンテナイメージを保存およびアクセスします。これは、複数のホストおよびコンピューティング環境にわたってコンテナイメージを共有および展開するのに役立ちます。
コンテナの権限を制限する:コンテナに付与される権限を制限し、意図した目的を達成するために必要な権限のみをコンテナに付与します。コンテナが侵害されたり悪用されたりするリスクを軽減するために、可能な限りルートレスコンテナをデプロイします。
リソース制約を実装する:コンテナーがリソースを過剰に使用してシステム全体のパフォーマンスに影響を与えないように、 CPUやメモリなどのリソースに制限を設定します。
コンテナを最新の状態に保つ:脆弱性のリスクを最小限に抑えるために、最新のセキュリティパッチと更新プログラムを使用してコンテナイメージを最新の状態に保ちます。
コンテナを徹底的にテストする:コンテナを本番環境にデプロイする前に、コンテナが期待どおりに動作し、脆弱性が含まれていないことを確認します。 CIパイプラインを使用して、あらゆる段階でテストを自動化し、人的エラーを削減します。
コンテナのバックアップおよびリカバリメカニズムを実装する:コンテナによってアクセスされる永続データのバックアップおよびリカバリ戦略を実装して、障害や災害の発生後にワークロードを迅速にリカバリできるようにします。