クラウド ネイティブはマイクロサービスにどのように役立ちますか?

テクノロジーの発展に伴い、クラウド ホスティングの時代は徐々にクラウド ネイティブへと進化してきました。クラウドネイティブとは、マイクロサービスやDevOpsのアーキテクチャ概念と、クラウドが提供するコンテナやサーバーレスをより適切に組み合わせることで、リソースの利用効率を高め、研究開発や運用保守の効率を向上させることです。では、クラウド ネイティブの時代において、マイクロサービスはクラウド ネイティブをどのように補完すべきでしょうか?

[[343847]]

マイクロサービスの定義を見てみましょう。マイクロサービスとは、モノリシック アプリケーションを複数のマイクロサービスに分割し、それらが連携して外部サービス サポートを提供することです。マイクロサービスの運用には 3 つの問題があります。

1. マイクロサービスのライフサイクルを管理する方法

2. 異なるテクノロジー スタックのマイクロサービス間の通信を管理する方法。

3. 異なるテクノロジー スタックのマイクロサービス リクエストをどのように処理しますか?

マイクロサービスのライフサイクルを管理する方法を見てみましょう。当初、サービスはモノリシックであり、起動時に特定のマシン リソースに直接展開できました。例外が発生すると、マシン上のサービス バージョンは直接オフラインになります。サービスとリソースの関係は比較的単純で、動的な依存関係はありませんでした。サービスをマイクロサービスに分割すると、異なるマイクロサービスが異なるマシンにデプロイされ、最終的にアプリケーション全体が形成されてユーザーに提示されます。このとき、サービスとリソースの関係は複雑になります。アプリケーションが異なるテクノロジー スタックを使用して開発および実装されている場合 (たとえば、一部のマイクロサービスでは C++、一部では Java、一部では PHP、一部では Golang を使用する場合)、各サービスをデプロイするときに、対応するオペレーティング環境をマシンにインストールする必要があり、アプリケーション全体の運用および保守コストが増加します。

しかし、クラウドネイティブの時代では、Docker などのコンテナや Kubernetes などのコンテナ プラットフォーム テクノロジーによって、これらすべてがシンプルになりました。 Docker コンテナ テクノロジーは、標準パッケージングと標準ランタイムを通じてマイクロサービスの展開を標準化します。 Kubernetes テクノロジーにより、標準化されたマイクロサービスをマシン上で簡単に実行できるようになります。運用および保守担当者は、特定のマシンにマイクロサービスを割り当てる必要がなくなります。 Kubernetes の Pod モデルは、単一のコンテナ実行ステータス インターフェースと DNS アドレス サービスを外部に提供します。簡単な二次開発により、各マイクロサービスがどのアドレスで実行されているかを確認できるため、マイクロサービスのライフサイクル全体の管理が簡素化されます。

異なるテクノロジー スタックのマイクロサービス間の通信を管理する方法を見てみましょう。当初、サービスはモノリシックであり、モジュール間の通信は静的コンパイルによって生成されており、比較的単純でした。サービスをマイクロサービスに分割すると、モジュール間の通信が動的に関連付けられ、マイクロサービスが別のマイクロサービスを見つけることが複雑になります。 Java の Spring などの一部のマイクロサービス フレームワークは、開発者の負担を軽減します。 Java サービスを開発する限り、マイクロサービス間の通信のロジックを書き直す必要はありません。

しかし、企業が複数のテクノロジースタックを導入する場合、上位層はJavaで記述され、下位層はGolangで記述されるのが一般的です。異なるマイクロサービス間の通信フレームワークは異なるため、開発者のコ​​ストが間違いなく増加します。しかし、クラウドネイティブの時代には、通信ハイジャックを通じてサービス間の通信の監視と管理を向上させる ServiceMesh が存在します。サービスメッシュには、サイドカー コンテナの概念があります。これは、マイクロサービスのビジネスからの通信機能を抽象化し、コンテナに分離してマイクロサービスと並行して実行し、Istio によって提供される管理および制御機能を使用して、マイクロサービスとサイドカー コンテナをメッシュ化されたデータ プレーンに構築し、その上でサービス間の通信を構成、管理、監視します。

さまざまなテクノロジー スタックのマイクロサービス リクエストを処理する方法を見てみましょう。ブラウザやアプリから外部からのリクエストが送られてきたら、アプリケーション層/ネットワーク層の負荷分散によってどのマシンに処理が分散されるかが決まります。モノリシック アプリケーションは全体として大きく、直接配布できるため、比較的簡単です。マイクロサービスでは、どのサービスとマシンに提供するかを決定するために複雑な論理的判断が必要です。マルチテクノロジー スタック開発の場合、各マイクロサービス フレームワークでリクエスト ロジックを記述する必要があります。しかし、クラウドネイティブの時代には、サーバーレスという概念があります。リクエストタイプ、リクエスト管理、リクエスト処理のロジックを抽出し、標準化できます。ビジネス層では、フロントエンドは関数を呼び出すだけでよく、その後のリクエスト処理や配信を管理する必要がなくなります。

マイクロサービスの出現は確かにテクノロジーの進化を大きく前進させましたが、マイクロサービスは万能ではありません。それを使用する場合、その複雑さによってもたらされるコストを必然的に負担しなければなりません。しかし、マイクロサービスは確かに良い薬です。クラウドネイティブテクノロジーの出現により、この優れた薬がもたらす副作用の多くを排除することができます。クラウド ネイティブは、企業がマイクロサービスを実装するための優れたパートナーである必要があります。