クラウドネイティブテクノロジーマップを1つの記事で理解する

クラウド ネイティブ アプリケーションとテクノロジを追跡および調査している場合は、Cloud Native Computing Foundation (CNCF) のクラウド ネイティブ テクノロジの状況を認識している必要があります。一見すると、クラウドネイティブの巨大さに驚かされるでしょう。なぜこんなに多くのカテゴリーとテクノロジーが存在するのでしょうか?完全なテクノロジーマップを理解するのは簡単ではありません。

しかし、それを剥がしてカテゴリーに分解し、各カテゴリーがどのようなテクノロジーを表し、各カテゴリーがどのような問題を解決するかを理解すれば、理解がはるかに容易になります。一般的に、クラウド ネイティブ テクノロジ マップは、プロビジョニング レイヤー、ランタイム レイヤー、オーケストレーションおよび管理レイヤー、アプリケーション定義および開発レイヤーの 4 つのレイヤーに分けられます。アーキテクチャの各レイヤーには独自のサブカテゴリがあります。

プロビジョニング層

構成レイヤーは、クラウドネイティブ アプリケーションの基盤の構築に関係するツールです。インフラストラクチャの作成、管理、構成の自動化から、コンテナ イメージのスキャン、署名、保存まで、あらゆるものを網羅します。ポリシーの設定と適用、アプリケーションとプラットフォームへの認証と承認の組み込み、シークレットの配布、リソースのプロビジョニング、さらにはセキュリティ領域への拡張を処理するためのツールを提供します。いくつかの重要なサブカテゴリが含まれています:

• 自動化および構成ツール - エンジニアが人間の介入なしにコンピューティング環境を構築するのに役立ちます。
• コンテナ レジストリ – アプリケーションの実行可能ファイルを保存します。
• セキュリティとコンプライアンスのフレームワーク – セキュリティのさまざまな領域をカバーします。
• キー管理ソリューション - 許可されたユーザーのみがアプリケーションにアクセスできるようにする暗号化。

これらのツールを使用すると、エンジニアはインフラストラクチャの詳細をすべて整理して、システムが必要に応じて環境を調整できるようにし、一貫性とセキュリティを確保できます。

ランタイムレイヤー

ランタイムは混乱を招く可能性のある用語の 1 つです。 IT の多くの用語と同様に、厳密な定義はなく、コンテキストに応じて異なる定義が使用されることがあります。狭義では、ランタイムとは、アプリケーションを実行するために準備された、特定のコンピューター上のサンドボックスであり、アプリケーションに必要な最小限のものです。広い意味では、ランタイムとは、アプリケーションを実行するために必要なものすべてを指します。

CNCF のクラウド ネイティブ コンテキストでは、ランタイムはその中間で定義され、コンテナ化されたアプリケーションにとって特に重要なコンポーネント、つまり実行、記憶、および対話に必要なものに重点が置かれます。これらには以下が含まれます:

• クラウドネイティブ ストレージは、コンテナ化されたアプリケーションに仮想化されたディスクまたは永続性を提供します。
• コンテナ ランタイムは、コンテナの制約、リソース、およびセキュリティ上の考慮事項を提供し、プログラムされたアプリケーションを使用してファイルを実行します。
• クラウドネイティブ ネットワークは、分散システムのノード (マシンまたはプロセス) が接続して通信するためのネットワークです。

オーケストレーションと管理レイヤー

インフラストラクチャのセットアップがセキュリティとコンプライアンスの標準に合わせて自動化され、アプリケーションの実行に必要なツールがセットアップされたら、エンジニアはアプリケーションをオーケストレーションして管理する方法を理解する必要があります。オーケストレーションおよび管理レイヤーは、コンテナ化されたすべてのサービス (アプリケーション コンポーネント) をグループとして管理する方法を扱います。他のサービスを識別し、相互に通信し、調整する必要があります。クラウド ネイティブ アプリケーションは本質的にスケーラブルであり、このレイヤーによって実現される自動化と弾力性に依存します。

このレイヤーに含まれるもの:

• オーケストレーションとスケジューリング - コンテナのクラスターをデプロイおよび管理して、回復力、疎結合、スケーラビリティを確保します。実際、ほとんどの場合、コンテナとオペレーティング環境を管理してクラスターを形成するために、オーケストレーション ツール Kubernetes が使用されます。
• オーケストレーションとサービス検出 - サービス (アプリケーション コンポーネント) が相互に検索して通信できるようにします。
• リモート プロシージャ コール (RPC) - あるノード上のサービスが、ネットワークを介して接続された別のノード上のサービスと通信できるようにするテクノロジ。
• サービス ブローカー – サービス間の通信に使用される仲介者です。プロキシの唯一の目的は、サービス通信をより細かく制御することであり、通信自体には何も追加しません。これらのプロキシは、以下で説明するサービス メッシュに不可欠です。
• API ゲートウェイ – 外部アプリケーションが通信できる抽象化レイヤー。
• サービス メッシュ - API ゲートウェイといくつかの点で似ていますが、アプリケーションが通信するための専用のインフラストラクチャ レイヤーですが、ポリシー駆動型の内部サービス間通信を提供します。さらに、トラフィックの暗号化からサービスの検出、アプリケーションの観測可能性まで、あらゆるものが含まれる可能性があります。

アプリケーション定義および開発レイヤー

名前が示すように、アプリケーション定義および開発レイヤーは、エンジニアがアプリケーションを構築し、実行し続けることを可能にするツールに重点を置いています。上記で説明した内容はすべて、必要なすべてのアプリケーション依存関係が利用可能な、信頼性が高く安全な環境を構築することです。

このレイヤーには以下が含まれます。

• データベース – アプリケーションがデータを整理して収集できるようにするデータベース。
• ストリームとメッセージ - 配信により、アプリケーションはメッセージ (イベントとストリーム) を送受信できるようになります。これはネットワーク層ではなく、メッセージをキューイングして処理するためのツールです。
• アプリケーション定義とイメージ構築は、コンテナ イメージ (アプリケーションの実行可能ファイル) の構成、保守、実行を支援するサービスです。
• 継続的インテグレーションとデリバリー (CI/CD) — 開発者は、コードがコード ベース (アプリケーションの残りの部分) と互換性があるかどうかを自動的にテストし、チームが十分に成熟している場合は自動的に本番環境にデプロイすることもできます。

すべての層で実行されるツール

カテゴリに戻って、すべてのレイヤーで実行される列分類について説明しましょう。可観測性と分析は、すべてのレイヤーを監視するためのツールです。一方、プラットフォームは、可観測性や分析など、これらのレイヤーの複数のテクノロジーを 1 つのソリューションにまとめます。

観測性と分析

サービスの中断を制限し、MRRT (問題解決時間) を短縮するには、アプリケーションのあらゆる側面を監視および分析して、異常があればすぐに検出して修正できるようにする必要があります。複雑な環境では障害が発生しますが、これらのツールは障害をできるだけ早く特定して解決することで、影響を軽減するのに役立ちます。このクラスはすべてのレイヤーを横断して監視するため、特定のレイヤーに埋め込まれるのではなく、垂直面に配置されます。

このレイヤーには以下が含まれます。

• イベント ログを収集します - プロセスに関する情報を記録するログ ツールです。
• 監視ソリューション - メトリック (RAM の可用性などの数値システム パラメーター) を収集します。
• 追跡 – ユーザー要求の伝播の監視と監視よりも一歩進んだ機能です。サービス メッシュに関連します。
• カオス エンジニアリングは、運用中のソフトウェアをテストし、サービス提供に影響が出る前に欠陥を特定して修正するためのツールです。

プラットフォーム

前述のように、各モジュールは特定の問題を解決します。ストレージだけでは、アプリケーションの管理に必要なすべての機能が提供されるわけではありません。オーケストレーション ツール、コンテナ ランタイム、サービス検出、ネットワーク、API ゲートウェイなどが必要です。複数のレイヤーをカバーするプラットフォームは、さまざまなツールをバンドルして、より大きな問題を解決します。

さまざまなモジュールを構成および微調整して信頼性とセキュリティを高め、モジュールが活用するすべてのテクノロジが更新され、脆弱性が修正されるようにします。プラットフォームを使用することで、ユーザーはこれらの詳細を心配する必要がなく、生産において付加価値を実現できます。

すべてのカテゴリが Kubernetes を中心に展開されていることにお気づきかもしれません。これは、Kubernetes がクラウド ネイティブ スタックの中核にあるためです。忘れないでください。Kubernetes は CNCF の最初のインキュベーション プロジェクトであり、その後のすべてのプロジェクトは Kubernetes に続いて登場しました。

プラットフォームには 4 つの種類があります。

• Kubernetes ディストリビューションは変更されていないオープンソース コードを使用しますが、一部のベンダーは市場の要求に応じてコードを変更し、追加機能を追加します。
• ホスト型 Kubernetes はディストリビューションに似ていますが、プロバイダーまたはユーザー独自のインフラストラクチャ上でプロバイダーによって管理されます。
• Kubernetes のインストールと構成プロセスを自動化する Kubernetes インストーラー。
• PaaS/コンテナ サービスは、マネージド Kubernetes に似ていますが、幅広いアプリケーション デプロイメント ツール (多くの場合、クラウド ネイティブ環境の一部) が含まれています。

要約する

各カテゴリ内には、同じ問題または類似の問題を解決するさまざまなツールがあります。その中には、現在のクラウドネイティブ テクノロジーに準拠しているものもあれば、まったく新しいものもあります。違いは、実装と設計のアプローチにあります。ほとんどの場合、テクノロジーは設計とアーキテクチャの選択によって制限され、常にトレードオフが存在するため、完璧なテクノロジーは存在しません。

スタックを選択する際、クラウド ネイティブ エンジニアは各機能を慎重に検討し、トレードオフを比較検討して、ユースケースに最適なオプションを決定する必要があります。これにより複雑さが増しますが、アプリケーションのニーズに最適なデータ ストレージ、インフラストラクチャ管理、メッセージング システムなどを選択することが必須です。システムの設計は、クラウド ネイティブ以前の世界と比べてはるかに簡単になりました。また、適切に設計されていれば、クラウド ネイティブ テクノロジーは強力で、非常に必要とされる柔軟性を提供します。