マイクロサービスシステムアーキテクチャはどのようにネットワークのボトルネックを回避しますか？

私はサーバーアプリケーションのマイクロサービスアーキテクチャについて多くのことを読んでおり、内部ネットワークの使用がモノリスアーキテクチャに比べてボトルネックや重大な欠点ではないことを疑問に思っていました。

正確さのために、2つの用語の解釈を以下に示します。

1. モノリスアーキテクチャ：すべての機能、データなどを処理する単一言語の1つのアプリケーション。ロードバランサーは、アプリケーションの1つのインスタンスを実行する複数のマシンにエンドユーザーからのリクエストを分散します。

2. マイクロサービスアーキテクチャ：機能とデータのごく一部を処理する多くのアプリケーション（マイクロサービス）。各マイクロサービスは、（同じマシン上のプロセス間通信または共有メモリとは対照的に）ネットワークを介してアクセスされる共通のAPIを公開します。API呼び出しは、主にサーバー上でページを生成するためにスティッチングされますが、おそらくこの作業の一部は、個々のマイクロサービスを照会するクライアントによって行われます。

単純な想像では、マイクロマシンアーキテクチャは、同じマシン（メモリとディスク）の高速リソースとは対照的に、低速ネットワークトラフィックを使用するようです。内部ネットワークを介したAPIクエリにより、全体の応答時間が遅くならないようにするにはどうすればよいですか？

内部ネットワークは、多くの場合1 Gbps以上の接続を使用します。光ファイバー接続またはボンディングにより、サーバー間の帯域幅を大幅に拡大できます。ここで、APIからのJSON応答の平均サイズを想像してください。1秒間に1 Gbps接続で送信できる応答はどれくらいですか？

実際に計算してみましょう。1 Gbpsは1秒あたり131 072 KBです。JSONの平均応答が5 KB（これは非常に多い！）である場合、1組のマシンで1秒間に26 214応答を送信できます。そんなに悪くないですよね？

これがネットワーク接続が通常ボトルネックではない理由です。

マイクロサービスのもう1つの側面は、簡単に拡張できることです。2つのサーバーを想像してください。1つはAPIをホストし、もう1つはAPIを使用します。接続がボトルネックになった場合は、他の2つのサーバーを追加するだけで、パフォーマンスを2倍にできます。

これは、以前の26 214応答/秒がアプリの規模に対して小さすぎる場合です。他の9つのペアを追加すると、262 140の応答を提供できるようになります。

しかし、サーバーのペアに戻り、比較を行いましょう。

• データベースへのキャッシュされていないクエリの平均が10ミリ秒かかる場合、1秒あたり100クエリに制限されます。100件のクエリ。26 214応答。1秒あたり26 214応答の速度を達成するには、大量のキャッシュと最適化が必要です（応答が実際にデータベースのクエリなどの有用な処理を必要とする場合、「Hello World」スタイルの応答は適格ではありません）。

• 私のコンピューターでは、GoogleのホームページのDOMContentLoadedが394ミリ秒で発生しました。リクエストが送信された後。1秒あたり3リクエスト未満です。Programmers.SEホームページの場合、603ミリ秒でした。リクエストが送信された後。1秒あたり2回のリクエストでもありません。ちなみに、私は100 Mbpsのインターネット接続と高速コンピューターを持っています。多くのユーザーはもっと長く待つでしょう。

  ボトルネックがサーバー間のネットワーク速度である場合、これらの2つのサイトは、ページを提供しながら、文字通り異なるAPIに対して何千もの呼び出しを行う可能性があります。

これらの2例は、ネットワークは、おそらく理論的にはあなたのボトルネックになることはないだろうことを示している（実際には、あなたがのボトルネックの正確な位置を決定するために、実際のベンチマークとプロファイリングを行う必要があり、あなたの特定のハードウェア上でホストされている特定のシステムを）。実際の作業（SQLクエリ、圧縮など）を実行し、結果をエンドユーザーに送信するのに費やした時間がはるかに重要です。

データベースについて考える

通常、データベースはそれらを使用するWebアプリケーションとは別にホストされます。これは懸念を引き起こす可能性があります。アプリケーションをホストするサーバーとデータベースをホストするサーバー間の接続速度はどうですか？

実際には、接続速度が問題になる場合があります。つまり、データベース自体で処理する必要がなく、すぐに利用できるはずの大量のデータ（大きなバイナリファイル）を保存する場合です。ただし、そのような状況はまれです。ほとんどの場合、転送速度はクエリ自体の処理速度に比べてそれほど大きくありません。

転送速度が実際に重要なのは、企業がNASで大きなデータセットをホストしていて、NASが複数のクライアントから同時にアクセスされる場合です。これは、SANがソリューションになる可能性がある場所です。とはいえ、これが唯一の解決策ではありません。Cat 6ケーブルは、最大10 Gbpsの速度をサポートできます。ボンディングを使用して、ケーブルやネットワークアダプターを変更せずに速度を上げることもできます。複数のNASにわたるデータ複製を含む他のソリューションが存在します。

速度を忘れてください。スケーラビリティについて考える

Webアプリの重要なポイントは、スケーリングできることです。実際のパフォーマンスは重要ですが（より強力なサーバーにお金を払う必要はありません）、必要に応じて追加のハードウェアを投入できるため、スケーラビリティがはるかに重要です。

• 特に高速でないアプリを使用している場合、より強力なサーバーが必要になるため、お金を失うことになります。

• スケーリングできない高速アプリを使用している場合、増加する需要に対応できないため、顧客を失うことになります。

同様に、仮想マシンは10年前に大きなパフォーマンスの問題として認識されていました。実際、サーバーでアプリケーションをホストする場合と仮想マシンでホストする場合は、パフォーマンスに重要な影響がありました。現在、このギャップははるかに小さくなっていますが、依然として存在しています。

このパフォーマンスの低下にもかかわらず、仮想環境は柔軟性を備えているため非常に人気がありました。

ネットワーク速度と同様に、VMが実際のボトルネックであり、実際の規模を考えると、VMなしでアプリを直接ホストすることで数十億ドルを節約できます。しかし、これはアプリの99.9％で起こることではありません。それらのボトルネックはどこか他の場所にあり、VMによる数マイクロ秒の損失という欠点は、ハードウェアの抽象化とスケーラビリティの利点によって簡単に補われます。

「マイクロ」の部分を読みすぎていると思います。すべてのクラスをネットワークサービスに置き換えるわけではありませんが、モノリシックアプリケーションを適切なサイズのコンポーネントにコンポーネント化し、各コンポーネントがプログラムの側面を処理します。サービスは相互に通信しないため、最悪の場合、大きなネットワーク要求をいくつかの小さな要求に分割してしまいます。返されるデータは、とにかく受け取ったものと大きく異なることはありません（ただし、より多くのデータを返して、クライアントに統合することもできます）

結果として得られるシステムがモノリシックアプリケーションまたは構成経由の分散アプリケーションとして実行するのに十分な柔軟性を持つように、コードおよびリソースアクセスを構造化します。一般的なインターフェイスの背後にある通信メカニズムを抽象化し、同時実行を念頭に置いてシステムを構築する場合、システムのプロファイルを作成し、実際のボトルネックを見つけた後、すべてを簡単に最適化できます。

分散（エンティティレベル）シミュレーションという非常に異なる前提を持つ異なる業界から、異なる視点を追加したいと思います。概念的には、これは分散FPSビデオゲームによく似ています。主な違い：すべてのプレイヤーはいくつかの状態を共有しています：ドラゴンは今どこにいますか。データベース呼び出しなし。すべてが速度と低レイテンシのためにRAMに保持され、スループットはそれほど重要ではありません（しかし、完全に無視することもできないと思います）。

参加する各アプリケーションは、モノリス（プレーヤーのすべての面を表す）またはマイクロサービス（群衆の中の1人のプレーヤーのみを表す）のいずれかと考えることができます。

同僚から、単一の参加アプリケーション自体を、共有される可能性のあるより小さなマイクロサービスに分解することに興味がありました。たとえば、損害の調停や見通し計算、通常シミュレーションにバンドルされているものです。

問題は、呼び出しをディスパッチし、要求を待機する待ち時間です。他の人が指摘しているように、帯域幅はとにかく無関係で豊富です。しかし、視線の計算が1マイクロ秒から100マイクロ秒になった場合（たとえば、すべてのプレーヤーアプリケーション間で共有される新しいマイクロサービスのキューイングのため）、それは大きな損失です（複数のまたは多くの視線の計算が必要になる場合があります）各更新、数回の更新/秒）。

サービスがどのように機能するか、いつ呼び出されるか、どのデータが交換されるかについて、慎重に検討してください。私たちのアプリケーションはすでに位置情報だけを交換するのではなく、推測航法情報を交換しています-私は位置xにいて、速度qで方向yに向かっています。そして、それらの仮定が変わるまで、情報を更新する必要はありません。更新がはるかに少なくなり、待機時間（まだ問題はあります）が発生する頻度はそれに比例して低くなります。

したがって、より高い頻度できめ細かなサービスを要求するのではなく、次の方法で頻度を下げてみてください。

1. 要求されるデータの変更とローカル計算の使用
2. 非同期応答のクエリまたはトリガーパラメーターの送信
3. バッチリクエスト
4. 推測に基づいて要求を予測し、応答を事前に準備する（遅延評価の反対）
5. 可能な限り、他のマイクロサービスを呼び出すマイクロサービスを避けます。これは明らかに問題を複雑にします。これはマイクロサービスをより大きくするインセンティブであり、ポイントをいくぶん打ち負かすことになると理解していますが、マイクロサービスはレイテンシーの友達ではありません。たぶんそれを認めて乗り越えてください。

ここで、システムに関する前提を必ず確認してください。レイテンシよりもスループットに関心がある場合、または共有状態などを持っていない場合は、意味のあるマイクロサービスを必ず使用してください。意味をなさない場所では使用しないでください。

あなたの素朴な想像力は正しいです。そして、多くの場合、それは重要ではありません。最新のマシンは高速です。マイクロサービスアーキテクチャの主な利点は、開発と保守の労力と時間に見られます。

そしてもちろん、共有メモリを使用できない、または1つの実行可能ファイルに複数のサービスを物理的に展開することさえできないというルールはありません。それに依存しないように設計する限り。

多くの人々が言及したように、それはネットワークのボトルネックに関するものではありません。それは、ネットワークの脆弱性に関するものです。したがって、最初のステップは同期通信を避けることです。思ったより簡単です。必要なのは、適切な境界を持つサービスだけです。適切な境界により、サービスは自律的で、疎結合であり、高度に結合されています。優れたサービスには、他のサービスからの情報は必要ありません。すでに情報があります。優れたサービスが通信する唯一の方法は、イベント経由です。良いサービスも最終的に一貫性があるため、分散トランザクションはありません。

この良さを実現する方法は、最初にビジネス能力を特定することです。ビジネス能力は、特定のビジネス責任です。全体的なビジネス価値への貢献。システムの境界について考えるときに取るステップシーケンスは次のとおりです。

1. より高いレベルのビジネス責任を特定します。それらのいくつかがあります。このサービスを、組織がビジネス目標を達成するために歩むべきステップとして扱います。
2. 各サービスの詳細を調べます。親サービスを構成する下位レベルのサービスを特定します。
3. 最初の2つのポイントと並んで、サービスコミュニケーションについて考えます。ビジネスプロセスの結果について互いに通知するためだけに、主にイベントを介して実行する必要があります。イベントはデータコンベヤーと見なすべきではありません。

ビジネスサービスには、人、アプリケーション、ビジネスプロセスが含まれることに留意してください。通常、その一部のみが技術機関として表されます。

これは少し抽象的に聞こえるかもしれないので、おそらくサービス境界の識別の例は興味深いでしょう。

現在の回答に追加するもう1つの要素。粗粒度のサービス。すべての呼び出しからの待ち時間を避けるため、10回の呼び出しを行う代わりに、DTOに必要な10個のデータを取得する呼び出しを行います。

また、マイクロサービスは人々が考えるほどマイクロではないことを忘れないでください。