。マイクロサービス アーキテクチャには多くの利点があるため、IT 部門の全員がこの新しいアーキテクチャに移行するのも不思議ではありません。 マイクロサービス アーキテクチャには、複雑なアプリケーションを小さな自己完結型アプリケーションに分割して、それぞれを独立して拡張および保守できるようにすることが含まれます マイクロサービス アーキテクチャの中核には、リバース プロキシの概念があります。リバース プロキシは、異なるマイクロサービス間でトラフィックを転送し、マイクロサービスの複数のインスタンスにワークロードを分散する上で重要な役割を果たします。リバース プロキシがなければ、今日私たちが理解しているマイクロサービス アーキテクチャ内の複雑な相互作用と負荷分散は、まったく実現不可能です。 マイクロサービス設定におけるリバース プロキシの役割を詳しく見てみましょう。 プロキシとは何ですか? プロキシは、クライアントのコンピュータとインターネットの間にあるサーバーです。クライアントのマシンから送信されるトラフィックはすべてプロキシ サーバーを通過します。インターネットの残りの部分では、プロキシ サーバーがリクエストを開始しているように見えます。 プロキシ サーバーを使用する理由はいくつかあります。そのうちのいくつかは次のとおりです - プロキシを使用すると、クライアントの本当の ID がインターネットに公開されなくなります。これを使用すると、クライアントに対してブロック/制限されるはずだったコンテンツにアクセスできます。 ID マスキング: 特定の構成を使用すると、プロキシ サーバーを使用して、クライアントの特定のコンテンツへのアクセスを制限できます。 制限のセットアップ: セキュリティも強化されます リバースプロキシとは何ですか? リバース プロキシは、インターネットとバックエンド サーバーの間にあるサーバーです。サーバー宛てのトラフィックはすべて、リバース プロキシを通過する必要があります。インターネットの残りの部分では、リバース プロキシがリクエストを処理しているように見えます。 一般に、リバース プロキシを使用すると、いくつかの利点があります。いくつかは リストされています。 ここに リバース プロキシの概念はマイクロサービス アーキテクチャに命を吹き込み、クライアントがアクセスするサーバーを決定することによってマイクロサービスの動的な環境をナビゲートできるようにします。この重要なコンポーネントがなければ、クライアントはマイクロサービス アーキテクチャの複雑な状況を効果的にナビゲートする手段を失うことになります。 サービスディスカバリ 🌍 マイクロサービス アーキテクチャのサービスは、負荷に基づいてスケールアップおよびスケールダウンします。これは、サービスのレプリカがアプリケーションの存続期間中いつでも行き来できることを意味します。リバース プロキシはサービスのサーバーを検出し、クライアントのトラフィックをこれらのサーバーに効果的に転送します。 ロードバランシング ⚖️ サービスには複数のレプリカが実行されている場合があるため、クライアントのリクエストが利用可能なサーバー間で適切に分散されることが重要になります。負荷分散は、ここで使用される Revere プロキシのもう 1 つの機能です。リバース プロキシは、サービスの利用可能なレプリカ全体に負荷をスマートに分散します。 モニタリング🖥️ アプリケーションに入るリクエストはすべてリバース プロキシを通過するため、リクエストを監視し、ログを実行するのに適した場所です。これは、システム内に存在するサービスの数に関する重要な洞察を得るのに役立ちます。 内部トラフィック 🚦 マイクロサービス設定では、クラスターの内部トラフィックのルーティングにもリバース プロキシが使用されます。これは、サービス間通信の場合に特に役立ちます。 キャッシング 💰 キャッシュは、リバース プロキシの使用に伴う一般的な利点です。プロキシ サーバーは、同様のクエリに対してキャッシュされた結果を返すことができるため、クライアントの応答時間が短縮されます。 集約 ⛙ 単一のクライアントのリクエストには、バックエンドの複数のサービスからの応答の集約が必要な場合があります。このような集約はリバース プロキシによって実行でき、クライアントはクリーンなエンドポイントを使用できるようになります。 レイヤー間のプロキシ リバース プロキシはさまざまな構成で使用できます。通常、これらの構成は、ルーティングの決定が行われる OSI 層を決定します。一般に、有名なプロキシ処理には、(1) レイヤ 4 でのプロキシ処理、(2) レイヤ 7 でのプロキシ処理の 2 つがあります。レイヤが上がるにつれて、ルーティングの決定に使用できるインターネット パケットからより多くの情報がデコードされます。 レイヤ 4 プロキシ OSI モデルのレイヤー 4 はトランスポート層です。アプリケーション開発者の観点から見ると、レイヤ 4 でルーティング決定に利用できるものは次のとおりです。 リクエストを送信するクライアントの IP とポート リクエストを受信しているサーバーのIPとポート したがって、レイヤー 4 プロキシは、サーバーとクライアントの IP とポートに基づいてのみルーティングを決定できます。リクエストの内容を調べることができないため、限定的なルーティング決定を行うことができます。 レイヤ 4 プロキシを使用する理由はいくつかあります。 パケットレベルのロードバランシングのみが必要な場合。 安全上の懸念から、リバース プロキシがリクエストを復号化することは望ましくありません。 レイヤ 4 でのプロキシ処理は高速であるため、効率が求められます。 レイヤ 4 プロキシにはいくつかの欠点もあります。 レベル 4 なので、スマートな負荷分散は不可能です 真のマイクロサービスの負荷分散を実行することはできません。 レイヤ 7 プロキシ OSI モデルのレイヤー 7 はアプリケーション層です。アプリケーション開発者の観点から見ると、レイヤー 7 でルーティング決定に利用できるものは次のとおりです。 レイヤー 4 で利用可能なものはすべて ヘッダーを含むリクエストのコンテンツ全体 レイヤ 7 では意思決定のためのより多くのコンテンツが利用できるため、よりスマートなルーティングを実行できます。 レイヤ 7 プロキシを使用する理由は次のとおりです。 リバースプロキシで賢明なルーティング決定を行う必要がある キャッシングを利用したい レイヤ 7 プロキシの使用にはいくつかの欠点があります - レイヤ 7 プロキシは、リクエストを復号化し、その内容を調べてルーティングを決定するため、一般にレイヤ 4 よりも遅くなります。 リバースプロキシはリクエストの内容を検査するため、レイヤー7プロキシの使用には安全性の懸念もあります リバース プロキシは、間違いなくマイクロサービス アーキテクチャにおける重要な部分の 1 つです。これがなければ、マイクロサービス アーキテクチャの真のメリットを完全に実現することはできません。 これにてこのブログは終わりとさせていただきます！今日は何か新しいことを学べたことを願っています。
