クラウドネイティブ
クラウド ネイティブ (Cloud Native) は、クラウド環境でアプリケーションを構築、デプロイ、管理することに焦点を当てた手法と哲学です。クラウドネイティブ アプリケーションは、弾力性、自動化、拡張性、高可用性など、クラウド コンピューティング インフラストラクチャの利点を最大限に活用できます。この概念は、アーキテクチャ、開発、展開、運用と保守、チーム文化など、多くの側面をカバーしています。
クラウドネイティブの機能と原則
- コンテナ化: アプリケーションとその依存関係をコンテナにパッケージ化して、一貫した動作環境を実現します。Docker などのコンテナー テクノロジーには、分離性、移植性、迅速な導入という利点があります。
- マイクロサービス アーキテクチャ: アプリケーションを小さな独立したサービス ユニットに分割し、それぞれが特定のビジネス機能に焦点を当てます。これにより、保守性、拡張性、俊敏性が向上します。
- 自動化: 効率と安定性を向上させるために、継続的インテグレーション、継続的デリバリー、自動拡張などを含む、自動化された開発、テスト、導入、運用および保守プロセスを重視します。
- 柔軟性: マイクロサービス アーキテクチャとコンテナ化を通じて、クラウド ネイティブ アプリケーションにより、各サービス ユニットを独立して開発、展開、拡張できるようになり、変化への対応力が強化されます。
- 弾力性: クラウドネイティブ アプリケーションは、トラフィックの変化に対処するために、負荷に基づいて自動的にスケールアップおよびスケールダウンできます。
- サービス ガバナンス: サービスの検出、負荷分散、トラフィック管理、およびフォールト トレランス メカニズムを重視して、サービスの信頼性の高い通信を確保します。
- 宣言型 API とコードとしてのインフラストラクチャ: アプリケーションの自動展開と管理は、宣言型 API とコードとしてのインフラストラクチャを通じて実現されます。
- 可観測性: 問題をタイムリーに特定して解決するために、アプリケーションの監視、ロギング、トレース、およびメトリクスを重視します。
- オープン性と多様性: クラウド ネイティブ テクノロジーは、特定の言語、フレームワーク、クラウド プラットフォームに限定されず、オープン スタンダードと多様なテクノロジー スタックの採用を促進します。
クラウド ネイティブは、アプリケーションがクラウド コンピューティングをより有効に活用し、より高い信頼性、拡張性、俊敏性を提供できるようにすることを目的とした包括的な概念です。コンテナ化、マイクロサービス、自動化、弾力性などの原則は、クラウドネイティブ アプリケーションを実現するための鍵となります。
分散システムの固有の問題
マイクロサービスアーキテクチャでは、登録の検出、追跡管理、負荷分散、送信通信など、解決しなければならない問題がいくつか発生します。分散システムである限り、これらの問題を完全に回避する方法はありませんが、振り返ってみると、これらの問題は分散システム自体で解決する必要があるのでしょうか。
1、SpringCloudとKubernetes
同じ分散サービスの問題に対して、Spring Cloud が提供するアプリケーション レベルのソリューションと Kubernetes が提供するインフラストラクチャ レベルのソリューションを比較してみると、Spring Cloud
と Kubernetes は出発点が異なりますが、問題解決の方法と効果も異なります。 Kubernetes が、問題を解決するための新しくてより有望な方法を提供していることを無視することはできません。
ビジネスに関係のない技術的な問題は、ソフトウェア レベルから分離され、ハードウェア インフラストラクチャ内で静かに解決される可能性が高く、ソフトウェアはビジネスのみに集中し、チームと製品を真に「ビジネス機能を中心に構築」することができます。
したがって、分散アーキテクチャの問題はソフトウェア レベルでのみ解決できるため、別の解決策があります。それは、アプリケーション コードとインフラストラクチャ ソフトウェアおよびハードウェアが統合され、それらが連携して問題に対処することです。
Kubernetes の制限
インフラストラクチャはコンテナ全体をまとめて管理され、その粒度は比較的粗いです。
一部の問題はアプリケーション システムやインフラストラクチャの末端にあり、Kubernetes がインフラストラクチャ レベルでそれらを完全に解決することは困難です。
- ビジネス ロジックとインフラストラクチャの関係: 一部の問題は特定のビジネス ロジックに密接に関連している可能性があり、共通のインフラストラクチャでは解決することが困難です。この場合、マイクロサービス フレームワーク (Spring
Cloud など) を使用すると、ビジネス向けにカスタマイズされたソリューションを提供するのが簡単になる可能性があります。 - マイクロサービスのガバナンスとビジネス ルール: 一部の問題にはビジネス ルールとガバナンスの組み合わせが含まれており、より高いレベルの抽象化とカスタマイズが必要になる場合があります。
- ビジネスの複雑さ: 一部の複雑なビジネス プロセスでは、特定のカスタマイズされたソリューションの方が適している場合がありますが、一般的なインフラストラクチャ (Kubernetes など) ではさらなる適応が必要な場合があります。
2. サービス メッシュとサイドカー プロキシ
Service Mesh は、マイクロサービス アーキテクチャ内のサービス間の通信を管理および監視するためのインフラストラクチャ層です。サービス検出、負荷分散、セキュリティ、障害処理など、マイクロサービス アーキテクチャにおけるいくつかの一般的な問題を解決するための一連のツールと機能を提供します。
**サイドカー プロキシ (**サイドカー プロキシ) は、サービス間の通信を処理するためにマイクロサービス アーキテクチャで使用されるパターンです。通信ロジックをアプリケーション コードから分離し、同じコンテナ、同じホスト、または同じ仮想マシン上で別個のプロキシ プロセス (サイドカー) として実行し、メイン アプリケーションと連携して動作し、ルーティング、負荷分散、セキュリティ、監視、その他の通信関連のタスク。
サイドカープロキシの主な利用シーン
- サービス ディスカバリとロード バランシング: サイドカー プロキシはサービス ディスカバリを担当し、サービス間のロード バランシングを実装し、リクエストをさまざまなサービス インスタンスに動的に割り当てます。
- セキュリティ: サイドカー プロキシは、認証、承認、暗号化などのセキュリティ機能を提供し、承認されたサービスのみが通信できるようにします。
- 監視と追跡: サイドカー エージェントは、問題の分析と解決を支援するために、監視と追跡の目的でリクエスト データと応答データを収集して記録できます。
- 再試行とタイムアウト: サイドカー プロキシは、リクエストの再試行とタイムアウトを処理して、リクエストが一定時間内に応答されるようにします。
- サーキット ブレーカーとサーキット ブレーカー: サイドカー プロキシは、システム全体への影響を回避できなかった場合にサービスへのリクエストの送信を停止するサーキット ブレーカーとサーキット ブレーカー メカニズムを実装できます。
- ルーティングとフロー制御: サイドカー エージェントはフロー制御とルーティング戦略を実装でき、グレー リリースや A/B テストなどの機能を実装するために使用されます。
- リクエストの変換と応答の処理: サイドカー エージェントは、リクエストと応答を変換および処理して、プロトコル変換とデータ形式変換を実装できます。
サイドカー プロキシの利点
- 通信ロジックの分離: サービス メッシュは通信ロジックをアプリケーションから分離するため、開発者は通信の詳細を気にせずにビジネス ロジックの開発に集中できます。
- 可観測性: サービス メッシュは通常、開発者と運用チームがサービス間の通信をよりよく理解して管理できるように、豊富な監視、トレース、ロギング機能を提供します。
- トラフィック管理: サービス メッシュにより、トラフィック分割、A/B テスト、グレースケール パブリッシングなどを含むトラフィックのきめ細かい制御が可能になり、柔軟性が向上します。
- セキュリティ: サービス グリッドは、サービス間の通信の安全性を確保するために、認証、認可、暗号化などのセキュリティ機能を提供できます。
- 障害の回復: サービス グリッドは障害の検出と回復を処理でき、サービス インスタンスに障害が発生した場合は、他の正常なインスタンスに自動的に切り替えることができます。
- クロス言語サポート: サービス メッシュは通常、複数のプログラミング言語とテクノロジー スタックをサポートしており、多様なマイクロサービス エコシステムに適しています。
サイドカー代理店費用
- 複雑さ: サービス メッシュを導入すると、システムがさらに複雑になります。特に小規模プロジェクトでは過度になる可能性があります。
- パフォーマンス オーバーヘッド: サービス メッシュのプロキシは通信ロジックを処理する必要があるため、特に高スループット シナリオでは、特定のパフォーマンス オーバーヘッドが発生する可能性があります。
- 学習曲線: サービス メッシュの学習とデプロイには時間がかかり、開発チームはその概念と構成に精通している必要があります。
- メンテナンス: サービス メッシュの展開とメンテナンスには、特に複数のサービスが関与する複雑な環境では、追加の作業が必要になる場合があります。
- 適用性: すべてのマイクロサービス アーキテクチャがサービス グリッドを必要とするわけではなく、一部の単純なシナリオでは、そのような複雑な通信層の導入が必要ない場合があります。
一般的なサイドカー プロキシ
Envoy : CNCF (Cloud Native Computing Foundation) が管理するオープンソース プロキシで、強力なルーティング、負荷分散、障害回復機能を備えています。
Istio : Google、IBM、Lyft が共同でオープンソース化したサービス グリッド プラットフォームで、マイクロサービス アーキテクチャにおけるサービス間の通信、管理、監視を簡素化および改善するように設計されています。Istio は、トラフィック管理、障害回復、セキュリティと可観測性など、マイクロサービス アーキテクチャにおけるいくつかの一般的な問題を解決する一連の機能とツールを提供します。
サービス グリッドは、マイクロサービス間の通信と対話の主流のモードとなり、「どの通信プロトコルを選択するか」や「認証と認可をどのように行うか」などの技術的問題をアプリケーション ソフトウェアから分離し、今日の Spring Cloud ファミリ バケットを置き換えます。関数内のコンポーネントの説明。
ソフトウェアアーキテクチャの進化の方向性
開発者がビジネス ロジックに集中し、ビジネスに関係のない技術的問題をソフトウェア レベルから分離し、インフラストラクチャとツールを通じてこれらの技術的問題に対処できるようにすることで、開発効率の向上、保守コストの削減、開発チームの能力の向上に役立ちます。中核的なビジネス機能のイノベーションにより重点を置きます。
ビジネスとテクノロジーが完全に分離され、リモートとローカルが完全に透過的になる、分散アーキテクチャの最良の時代が到来しているのかもしれません。