分散システムのパフォーマンスを最適化する方法がわからない場合は、この記事を彼に渡してください。

著者について: タオ・フイは、西安交通大学でコンピューターサイエンスとテクノロジーの学位を取得し、現在は杭州智力大データ株式会社の CTO 兼共同創設者として、インターネット技術を利用して建設業界の変革とアップグレードの実現を支援することに注力しています。彼は、Huawei、Tencent、Cisco、Alibaba などの分散システムでのデータ処理に携わる企業で勤務してきました。彼は Tencent Cloud の最も価値のある専門家 TVP です。彼は、Linux での高性能サーバー開発と大規模分散システム設計において豊富な経験を持っています。彼は『Nginx の徹底的な理解: モジュール開発とアーキテクチャ分析』の著者です。

この共有は 4 つの部分に分かれています。

基本的なリソースの最適化。 X86、ARM、Linux、Windows、スクリプト言語、C言語のいずれであっても、この種の最適化は効果的です。相対的に言えば、そのメリットは比較的大きく、より普遍的です。私はこれを基本的なリソース最適化として分類します。

ネットワーク効率の最適化。これには、システム層、アプリケーション層、伝送効率の最適化という 3 つのレベルと 3 つの層が含まれます。

リクエストの待ち時間を短縮します。キャッシュの使い方など、ユーザーエクスペリエンスを重視し、単一のリクエストをより高速に行うことができます。

スループット。システムの同時実行性を向上させます。スループットの観点からシステムの同時実行性を向上させる方法。

1. 基本的なリソースの最適化

私の意見では、基本的なリソースを最適化する鍵は、リソースの使用率を向上させることです。リソースを 4 つの部分に分割します。

• CPU キャッシュ。 CPU キャッシュは 3 つのレベルに分かれています。キャッシュにアクセスする CPU のレイテンシは約 10 ナノ秒である必要があり、第 1 レベル キャッシュのレイテンシはわずか 1 ナノ秒程度です。現時点では、普遍的な最適化手法であるCPUキャッシュヒット率をいかに向上させるかということに非常に関心があります。
• メモリ。メモリの速度は数百ナノ秒です。周波数が非常に高い場合でも、それほど高速ではないため、メモリ プールは多数存在します。たとえば、C、JVM、Python、Golang、Lua などにはすべて独自のメモリ プールがあります。これらのメモリ プールの割り当て速度を向上させ、断片化を減らし、メモリ使用率を向上させる方法。
• ディスク。ディスクには2種類あります。 1つはHDDです。機械式ハードディスクのアドレス指定時間は 7 ～ 8 ミリ秒で、ヘッドの回転速度は比較的低速です。過去には、多くのソフトウェア テクノロジがこの面で最適化されてきました。特に、エレベーター スケジューリング アルゴリズム、ゼロ コピー、Direct IO など、機械式ディスクに基づく PageCache ディスク キャッシュの使用が最適化されています。もうひとつのタイプはSSDです。 SSD は機械式ハードディスクとはまったく異なり、プログラミング方法や最適化方法も従来の方法とは異なります。ここでは、ヒット率や IO スケジューリング アルゴリズムなど、PageCache をエントリ ポイントとして簡単にまとめます。
• スケジュール。分散システムには多くのリクエストがあります。これらのリクエストを切り替えるにはどうすればいいですか?マルチプロセス、マルチスレッド、コルーチンのいずれであっても、スケジューリングのパフォーマンスをより高く、より効率的にし、データ同期をより高速にするにはどうすればよいでしょうか。

CPU

CPU キャッシュに関するトピックは多数あります。ここに例があります。誰もがNginxを使ったことがあると思います。 Nginx には 2 つのハッシュ テーブルがあります。 1 つはドメイン名ハッシュ テーブルです。通常の3レベルドメイン名のみを使用する場合、その上限に達することはありません。ただし、ドメイン名が 4 レベル、5 レベル以上ある場合は、64 バイトを超える場合があります。このとき、ハッシュテーブルのbucket_sizeを増やす必要があります。

別の例を挙げると、Nginx の最も強力な側面は変数にあります。あらゆる関数は変数を通じて実装できます。変数もハッシュ テーブルに格納されます。この変数が大きい場合は、64 バイトに調整する必要があります。

では、なぜ最初の 64 バイトなのでしょうか?例えば、100バイトに調整したい場合、できますか？いいえ。128 バイトまたは 64 バイトの整数倍に調整する必要があります。

なぜこのようなことが起こるのでしょうか? CPU キャッシュに関して、例を挙げて説明します。 2005年頃、CPU周波数は3Ghz～4Ghz程度に達し、その後はCPU単体の発熱量が高すぎるため増加が止まり、水平方向にしか発展できなくなりました。

複数の CPU の利点の 1 つは、真の同時実行性です。オペレーティング システムにおける並行性はタイム スライスの切り替えによって実現されますが、これはマイクロ レベルでの真の並行性ではありません。ただし、マルチコア CPU の同時実行には問題があります。 2 つの CPU が同時に 2 つのプロセスまたはスレッドにアクセスし、2 つのデータが同時に 64 バイトのキャッシュに格納される場合、CPU キャッシュはバイトごとに取り出されるのではなく、バッチ単位で取り出され、各バッチは 64 バイトになります。

この問題を解決するために、Java には「パディング」と呼ばれる一般的な用語があります。先ほど説明した Nginx でも、パディング方式が使用されています。それほど多くのバイトは使用しませんが、マイクロレベルで真に並行にするには、大量のデータを埋める必要があります。 CPU は一貫性を確保する必要があり、データの一貫性がなければ高いパフォーマンスと正確性は得られません。 CPU キャッシュは、ミドルウェアを作成する人だけでなく、アプリケーション層の開発者にも多くのコードに影響を与えます。

メモリ

メモリプールに関しては、3年前にHuaweiで行った社内研修を思い出します。当時、クラスメイトから「Nginx を Google の TCMalloc に置き換えるべきかどうか」と尋ねられました。 (TCMalloc は Google が開発したメモリプールです。)

アプリケーションがメモリを割り当てる必要があるたびに、オペレーティング システム カーネルは brk および mmap と呼ばれるシステム コールを提供します。これらのシステム コールは、カーネル モードからユーザー モードへの切り替えを伴うため、効率的ではありません。それで私たちは何をすべきでしょうか?

C プログラムには C ライブラリがあり、Linux ではデフォルトで Ptmalloc2 と呼ばれます。デフォルトでは、1 バイトを割り当てると、64 MB バイトが事前に割り当てられます。 2 番目のバイトを割り当てると、このプールから検索され、解放後にこのメモリ プールに返されます。このプールには多くの問題があります。たとえば、Ptmalloc は非常に一般的なメモリ プールです。非常に高い効率を達成することが目的です。たとえば、メモリがスレッド A によって解放された場合、スレッド B はそれを直接使用できます。これにより、同時実行の問題が確実に発生するため、ロックする必要があります。ロックされるとパフォーマンスが低下します。ただし、tcmalloc と Ptmalloc はこれをデフォルトで受け入れ、何も変更しません。

Google の TCMalloc は、小メモリ、中メモリ、大メモリに分かれています。小さいメモリは 256KB バイト未満です。小さなメモリは共有されないため、ロックする必要がなく、非常に高速です。中メモリおよび大容量メモリの場合、速度は Ptmalloc ほど速くありません。サーバー開発、特にシンプルな Nginx サーバーの開発を行う場合、それが動的サーバーであれば、数 MB のメモリを割り当てることがよくあります。ただし、負荷分散や単純な Lua スクリプト操作のために大きなメモリを割り当てることは不可能であるため、TCmalloc が非常に適しています。

ここでは C ライブラリのメモリ プールについてのみ紹介しました。実際、上には多くのメモリプールがあります。たとえば、Nginx には共有メモリ内にメモリ プール スラブがあります。このスラブはオープンレストで再利用されます。通常のストレージ用のメモリ プールのほか、接続メモリ プールやリクエスト メモリ プールもあります。

Lua 仮想マシンなどの他の言語の場合は、独自の Lua と独自のメモリ プールがあります。 Java には JVM メモリ プールがあり、golang にも独自のメモリ プールがあります。たとえば、golang は tcmalloc によって変更されたガベージ コレクション メカニズムに基づいています。主にオフライン学習を通じて、皆さんの注目を集めたいと考えています。

ディスク

ディスクは PageCache を中心に展開されると思います。従来の機械式ハード ドライブである PageCache は、同時実行が必要な場合でも同時実行できず、ただ回転し続けるだけなので、スケジューリング アルゴリズムを使用して、できるだけ一方向に回転するようにする必要があります。読み取り時に、PageCache はキャッシュをヒットし続けるものと見なされます。

たとえば、ゼロコピーですが、ゼロコピーは常に効果的でしょうか?例えば、動画のライブ配信や CDN を行う場合、ファイルは非常に大きいため、再度ヒットする可能性は高くありません。ページキャッシュは非常に制限されています。ファイルが非常に大きい場合、同時に異なるファイルを取得する同時行が多数あるため、ヒットする可能性は非常に低くなります。

PageCache に入ると何が起こりますか?

• 再度アクセスするのは困難であり、PageCache によってパフォーマンスも低下します。
• PageCache はほとんど使用されないため、何かを取り込むと、必ず出力されます。外に出るものは、再びアクセスされる可能性が高い小さなリソースとファイルなので、再びアクセスされる可能性がなくなります。そのため、直接 IO と非同期 IO が存在します。 Linux の作者は、インターフェースのデザインが非常に悪いと考えていますが、これはまったく役に立たないわけではなく、非常に便利です。

高速ディスク キャッシュについては、共有すべきことがまだたくさんあります。

たとえば、SDD は、私の意見では、SDD は別の種です。通常、誰もが「SDD は機械式ハードディスクよりも IOPS が高く、レイテンシが低く、思考量が多いため、全体的なスループットが高い」と考えます。これは確かにそれほど単純ではありません。

例を挙げてみましょう。まず、SSD には書き込み増幅と呼ばれる問題があります。

誰もがカフカを知っていますが、カフカのパフォーマンスがなぜこんなに優れているのでしょうか? 1 つの機能は、ピークを滑らかにして谷を埋めることであり、データを永続化することを目的としています。ハードディスクに書き込んでいるのに、なぜパフォーマンスが良いのでしょうか?ディスクの回転速度を最大限に活用するため、メッセージキューは本質的に時系列キューであり、ファイルに継続的に追加する必要があるため、ディスク使用率が非常に高くなります。機械式ディスクをたくさん入れれば、パフォーマンスは向上し続けます。

SSDに変更しても、このようなメリットはあるのでしょうか? SSD ははるかに高速ですが、書き込み増幅の問題があるため、この方法を使用すると問題が発生します。ライトアンプリフィケーションとは何ですか?たとえば、ログ ファイルを書き込むときは、後ろにいくつかのバイトを追加しますが、これは SSD では不可能です。 SSD には基本単位であるページがあり、ページ単位で書き込まれます。

たとえば、現在のページにすでに 1 バイトあり、2 番目のバイトを書き込む場合、ページ全体をキャッシュに読み込み、それをキャッシュに追加し、最後に誰も書き込んでいない新しいページに書き込むため、大きな増幅効果が得られます。 1 バイトを書き込むたびに、数 KB を書き込む場合があります。最も恐れられているのはインプレース書き込みなので、Kafka が使用する方法には問題があります。

2番目は、バランスを失うことです。

SSD の寿命は良くありません、寿命が短いものは何ですか?クリアできないため、ストレージユニットごとにクリアできる回数が制限されます。ハードディスクに、OS などの頻繁に読み書きされるデータなど、特に高温になるデータが入っている場合、読み取り中に故障する可能性があります。これは誰にとっても耐えられないことですが、他の部分は問題ありません。そこで、継続的にデータを移動するための GC を設定しました。ホットデータはここにあり、コールドデータはあちらにあります。移動しておきます。それらを移動した後、すべてがバランスが取れ、ディスクがすぐに故障することはなくなります。

しかし、このメカニズムには問題があり、アプリケーションに課題をもたらします。アプリケーションが従来の方法で作成され、多数の書き込み操作が継続的に入力されると、メカニズムが継続的にトリガーされます。 GC が追いつくと、再びブロックされ、パフォーマンスが再び低下します。

実際、SSD は多くの点で HDD とは異なります。たとえば、機械式ハード ドライブを使用する場合、ハード ドライブはただ回転しているだけなので、最終的には複数のスレッドをキューに入れる必要があるため、速度を上げるためにスレッドをさらに開くことは考えられません。しかし、SSD は異なります。スレッドをいくつ開いても、本質的に並行処理が可能なため、その速度になります。

たとえば、SSD はランダム読み取りと書き込みに非常に優れています。機械式ハードドライブではデータの読み取りと書き込みをできるだけ減らすようにしていますが、SSD でもデータの読み取りと書き込みは可能です。

高い同時実行性に戻りましょう。高い並行性を実現するためにコルーチンを使用する必要があるのはなぜですか?なぜマルチスレッドよりも高速で効率的なのでしょうか?私の考えでは、理由は 2 つあります。

1. 各コルーチンによって消費されるメモリは非常に少ないです。各スレッドの高さはどれくらいですか?ヒープ メモリ プールが作成されます。バイトごとに 1 つのメモリ プールが作成されるとのことです。スレッドにはスタックがあります。スタックはいつオーバーフローしますか?スタックの大きさはどれくらいですか?一般的には2MB～8MBです。このような大きなスレッドの場合、どれだけのメモリが必要になるか想像できますか?

数十 GB のメモリ上で 10,000 スレッドが同時に実行されると、メモリが足りなくなり、他の業務が実行できなくなります。

最大の問題は、リクエストを同時に処理するとメモリを大量に消費できないが、コルーチンではそれが可能であることです。基本的に、数 KB から 10 KB を超えるコルーチンでリクエストを処理できます。したがって、10 GB を超えるメモリを介して、数万、あるいは数十万のリクエストを簡単に送信できます。

2. 切り替えコストが低い。スレッドを切り替えると、カーネル モードからユーザー モードに切り替わり、大量のコピーを行う必要があります。コルーチンの場合は、フルスタックのユーザー状態なので、スキルデバイスを切り替えることも、スキルデバイスを切り替えないで、切り替えるコードに直接スケジュールすることもできるので、コストが比較的低くなります。

最後にまとめると、CPU に特に効果的なツールがあります。パフォーマンスを最適化する際には、ボトルネックを見つける必要がある場合があります。ボトルネックが近ければ近いほど、最適化する価値が高まります。ボトルネックを見つけるにはどうすればいいですか?フレームグラフをお勧めします。自分でログを管理して書き込むと、何かを見逃してしまう可能性が高くなります。何もインストールする必要はありません。必要なのは Linux perf + FlumeGraph の 2 つのソフトウェアだけです。

オンCPUとオフCPUの2種類に分かれます。 onCPU は主に暖色系で表示され、すべての機能が考慮されているため CPU がどれだけ消費されているかを示します。 offCPU は寒色で表示され、各関数がプロセスまたはスレッドをスリープ状態にするのにかかる時間を示します。これら 2 つのグラフの利点の 1 つは、SVG ベクター グラフィックであるため、さまざまな正規表現と一致させることができ、クリックして拡大できることです。さらに、同じ関数は同じコールスタックにマージされるため、どの関数に最も時間がかかるかを簡単に比較できます。

2. ネットワーク効率の最適化

ネットワーク効率の最適化には、主にエンコードとデコード、および伝送方法の改善が含まれます。

コーデックには 3 つの部分があります。

1. システム層の伝送効率。システム層は主に TCP プロトコルであり、その最適化には 3 ウェイ ハンドシェイク リンク確立の最適化と 4 ウェイ ハンドシェイク終了の最適化が含まれます。主にネットワーク環境、パケット損失率が高いかどうか、レイテンシが長いかどうかによって異なります。パケット損失率が非常に良好で再試行回数が多い場合は、調整できます。バッファ最適化と輻輳制御もあります。
2. アプリケーション層のコーディング効率。
3. アプリケーション層の伝送効率。

アプリケーション層では、HTTP プロトコルが主な焦点となります。

1996 年は HTTP1.0、1999 年は HTTP1.1、現在は主に 1.0 と 1.1 が使用され、2015 年は HTTP2 です。これらはすべて TLS と TCP 上で実行されますが、なぜでしょうか?開発効率を簡素化できるからです。

TCP は順序付けられたバイト ストリームを実装し、TLS も順序付けられたバイト ストリームに基づいています。順序付けられたバイト ストリームがない場合、現在は動作しません。たとえば、これを QUIC で再実装する必要があります。 HTTP2 は、順序付けられたバイト ストリームにより多くの問題を排除し、ファイルのサイズに関係なく、ファイルを正常に転送できるようにします。

これにより問題が発生します。順序付けされていないものが、順序付けされたバイト ストリームに配置されます (HTTP は複数の同時実行が可能であり、同時実行は明らかに順序付けされていません)。順序付けられたバイト ストリーム上で順序付けられていないものを運ぶことによって発生する問題は、ヘッドオブライン ブロッキングです。複数のストリームがあります。 1 つのストリームが表示される限り、TCP はパケットを失う可能性があり、後続のストリームが機能できなくなるため、UDP を介してのみ解決できます。

UDP が解決された後、QUIC レイヤーが登場しました。この QUIC 層は、TCP 層の多くの機能 (パケット損失、再送信、輻輳制御) を実行する独立した層です。 TLS も書き換える必要があり、HTTP2 のストリームもカプセル化されて TLS 内に配置されます。

HTTP3 の利点は何ですか? 1. 多重化; 2. 接続の移行3. QPACKエンコーディング4. パケット損失の再送信。

例を挙げてみましょう。たとえば、HTTP3 パケットをキャプチャすると、UDP ヘッダーがパケットの先頭にあることがわかります。 UDP ヘッダーは、送信元 IP、宛先 IP、送信元ポート、宛先ポートの 4 つの要素で構成されます。次はパケット ヘッダーです。パケット ヘッダーには connection_id と呼ばれる整数があります。なぜ connection_id があるのですか?

以前は接続はどのように定義されていましたか? 4 組 (送信元 IP、宛先 IP、送信元ポート、宛先ポート)。 4 タプルが変更された場合は、再接続する必要があります。

IOT時代には、5G基地局の頻繁な切り替えやWIFIへの切り替えなど、さまざまな高速モバイルデバイスが頻繁に切り替わります。この時点で、IP アドレスは確実に変更されるため、接続を再確立する必要があります。接続を再確立するコストが高すぎるので、接続の再確立を回避するにはどうすればよいでしょうか?パケット ヘッダーから、connection_id 整数が定義されます。

この整数が変更されない限り、接続を再利用できるため、TLS ハンドシェイクを実行する必要はありません。なぜこれが可能なのでしょうか?実のところ、それは非常に簡単です。これらは HTTP3 で暗号化されます。復号化できればセキュリティ上の問題はありません。パケット ヘッダーでは、これは接続移行と呼ばれ、接続移行と呼ばれます。これは HTTP3 の最初の使用です。

HTTP3 の 2 番目の用途は多重化です。多重化は QUIC フレーム ヘッダーに対して行われます。パケット ヘッダーは、接続が順序付けられていないバイト ストリーム接続であることを定義します。パケットを失わない限り、もし失ったとしても、再送信を見つけるのに役立つ ID があります。

でも、順序が間違っていても構いません。重要なのは QUIC フレーム ヘッダーです。彼は何かを作って、TCP 接続と同じ QUIC ストリームの概念を再定義しました。ここで TCP 接続が確立され、TCP 接続とまったく同じように使用されます。

TCP 3 ウェイ ハンドシェイクがシーケンスを同期していることは誰もが知っています。 SYN パラメータの完全な名前は、Synchronize Sequence Numbers です。シーケンス番号は、送信される後続のバイトごとに 1 ずつ増加し、相手側も確認を受信するときに同じことを行うため、両側でシーケンス番号を同期します。その中にはシーケンスも含まれており、それらはすべてまったく同じです。

この順序付けられたバイト ストリームに基づいて、行頭輻輳の問題は完全に解決されるため、その多重化は真の多重化になります。

次は HTTP3 フレーム ヘッダーです。 QUIC フレーム ヘッダーはすでに TCP 接続を提供していますが、HTTP には独自の独立したアプリケーションが多数あります。たとえば、リクエスト/レスポンスに加えて、サーバー プッシュもあります。サーバー プッシュは新しいフレーム ヘッダーなので、この機能を完了するために、前に別のヘッダー レイヤーが追加されます。

また、別の機能である QPACK も含まれています。皆さんご存知のとおり、HTTP2 には HPACK があり、その機能はヘッダーを圧縮することです。最も高い圧縮率は、ビデオを視聴するときにキー フレームと増分フレームが存在する場合と同じです。ビデオを圧縮すると、圧縮後に音量が数百分の一に削減されても、非常に鮮明に見えます。キーフレームと増分フレームなので圧縮効率が非常に高いです。 HPACKも全く同じです。接続時に初めて HTTP ヘッダーを送信すると、それがキーフレームになります。

後で増分フレームを作成するときは、数字を渡すだけです。しかし、この方法には、誰が最初に来て、誰が後から来るかというタイミング効果もあります。そこで、順序付けられていない接続に基づく関数を実装する QPACK が誕生しました。

ユニキャストとマルチキャスト、ユニキャストとは何ですか?たとえば、ホスト 1 がホスト 2、3、4 に同時に送信する場合、ユニキャストであれば、赤、青、緑の 3 つの TCP 接続が確立されます。ネットワーク層でマルチキャストの場合はこのように送信されます。たとえば、ホスト 1 がメッセージを送信した後、ルータ A はメッセージをルータ B に 1 つ、ホスト 2 に 1 つコピーします。ルータ B に到達した後、さらに 2 つのコピーをコピーします。1 つはホスト 3 に、もう 1 つはホスト 4 にコピーするため、ネットワーク効率が特に高くなります。

ただし、ネットワークを越えることはできません。まず、セキュリティ上の問題があり、簡単にネットワークストームが発生する可能性があります。 2 番目に、ルータ A とルータ B は同じメーカーのものではないため、取り扱いが非常に困難になります。したがって、ネットワーク層マルチキャスト（ARP プロトコルなど）は LAN 内でのみ発生します。

したがって、私たちが実行できる最善の策は、アプリケーション層マルチキャストです。ホスト 1 が 2、3、4 にメッセージを送信する場合は、次のようにします。ホスト 1 は、メッセージをプルして最初に 3 に送信する集中ノードになる場合があります。 3 は、メッセージを発信する主導権を握ることもできます。メッセージを取得した後、3 は中央サーバーからそのメッセージを取得できます。たとえば、4 が持っていない場合は、3 がそれを引っ張ります。これはとても便利です。

大規模なクラスターで数百メガバイトの新しいバージョンをリリースする必要がある場合、それを 1 台のマシン上の全員にプッシュすると、マシンに過負荷がかかります。 10G または 40G の外部ネットワーク カードを使用した場合でも、帯域幅はわずか数 G しかなく、数千台のサーバーが同時にプルすることに耐えることはできません。たとえば、Alibaba のオープンソース Dragonfly は非常に使いやすいです。この概念を使用するだけで、実装は非常に簡単です。任意のプロトコルを実装できますが、HTTP プロトコルを使用するだけで、全体的な実践コストが大幅に削減されます。

もう 1 つの例は、実際には感染症プロトコルである GossIP プロトコルです。 Redis クラスター内の管理ノードはすべて GossIP プロトコルを使用します。

3. リクエストのレイテンシを短縮する

リクエストの待ち時間を短縮し、ユーザー エクスペリエンスを向上させます。私はそれを4つの部分に分けました:

• キャッシュ
• 非同期
• マップリデュース
• ストリームコンピューティング

先ほど述べた読み取りロード キャッシュに加えて、書き込みキャッシュもあります。 CAP 定理があり、データが冗長であるためキャッシュには P が必要であることがわかっています。両方のマシンにキャッシュがありますが、一貫性を重視する場合はライトスルー キャッシュになります。 AP はライトバック キャッシュに重点を置く可能性があるため、単一の要求の使用率は高くなります。

BASE 理論には、キャッシュの用途も数多くあります。たとえば、Nginx または Openresty のバックエンドがクラッシュすると、アクセスごとに 502 リクエストが返されます。何かを追加して HTTP 502 と一致させると、元の後のキャッシュが直接顧客に返されるため、可用性が向上し、災害復旧と同等であり、基本的な可用性が提供されます。

MapReduce については多くのことが語られてきましたが、これはデータの分散、各ノードでの Map 関数の計算、出力のマージという 3 つのステップに分けることができます。 SQL の Group by 集計計算を使用すると、分散と回避が本質的に互換性があるため、SQL で MapReduce を頻繁に実行します。標準偏差を計算する場合でも、平均を計算する場合でも、並列計算を簡単に実行できます。もちろん、依存関係がある場合はそれを実行する方法はありません。

MapReduce には、データ ソースと密接に関連しているというもう 1 つの特徴があり、この点では Java エコシステムは基本的に無敵です。その理由は、すべての人のデータがそこに保存されているからです。つまり、データはインターネット企業の中核資産です。データがここにあると、他のフレームワークがどれだけうまく書かれていても役に立ちません。

ストリーミング コンピューティングと MapReduce には大きな違いがあります。時間枠があります。テクニカル ウィンドウを使用する場合でも、タイム ウィンドウを使用する場合でも、時間的な順序があります。ただし、ネットワーク レポートには時系列がなく、順序が異なります。そのため、ウィンドウを分割するのはかなり面倒です。そのため、ある程度軽減するためにロードマークを用意します。第二に、ビジネスとの関連性が強いことです。ウィンドウは固定時間である場合もありますが、ほとんどの場合はユーザーがログインしたときです。これはセッションと密接に関連しています。

4. システムの同時実行性を向上させる

システムの同時実行性を向上させ、システムを効率的に拡張するにはどうすればよいでしょうか?

ここでAKF拡張キューブについてお話します。これはとても便利だと思うので、皆さんに紹介したいと思います。

たとえば、多くのアップストリームは Nginx 上に構成されています。デフォルトのアップストリームは RoundRobin です。アップストリームに 8 コアと 16G がある場合でも、4 コアと 8G がある場合でも、重みを設定する必要があります。重さは違うようですが、どちらのマシンもどんな要求にも対応できます。したがって、実際には最小限の接続数を使用してコピーされ、上流サーバーの負荷に重点が置かれます。

これはX軸です。 X軸のコストは非常に低く、機械を追加するだけで済みます。しかし、Y軸とZ軸に関しては異なります。招待に基づいて開始されます。たとえば、MySQL が読み取りと書き込みを分離する場合、select ステートメントと update ステートメントが表示されます。選択ステートメントの場合は、スレーブまたはバックアップ データベースを見つけてアクセスするだけで、X 軸に戻ります。

アップデートの場合は、読み取りと書き込みが分離されているメイン データベースを入力する必要がある場合があります。 API Gateway でも同様のことがよく起こります。コードのリファクタリング後、ユーザー クラスとログ クラスを異なるクラスターに分割して処理したいと考えています。現時点ではすべてがY軸に基づいており、Y軸のコストは非常に高くなっています。

Z 軸は、基本的にハッシュに基づいたデータベースとテーブルのシャーディングです。ユーザー A のデータはサーバー 1 でのみ利用可能であり、ユーザー B のデータはサーバー 2 で利用可能である可能性があります。Z 軸のコスト、たとえばハッシュ アルゴリズムを言うのは難しいのですが、なぜコンシステント ハッシュと呼ばれるのでしょうか。このハッシュベースの負荷分散には大きな問題があるからです。リクエストのセットはほぼ無限ですが、アップストリーム サーバーのマッピング セットは非常に限られています。選択肢はサーバーの数だけあり、そのようなクラスターにのみマップできます。

大きなクラスターから小さなクラスターにマッピングする場合、使用するアルゴリズムの数に関係なく、最後に剰余演算を行う必要があります。余りがなければ、そのような小さな集合にまとめることはできません。余りを計算するときに問題があります。残りは変更できません。アップストリーム マシンがクラッシュしたり追加されたりすると、残りの部分が変更され、ハッシュ関数全体が変更されます。この関数が変化すると、Z 軸全体が大きく変化します。

ハッシュ関数とは異なるワンタイムハッシュを使用します。ハッシュ関数は実際には O1 の複雑度を持ちますが、一貫性のあるハッシュは O1 の複雑度ではありません。 logMになります。要求されたキーワードの情報をハッシュ ノードにマッピングします。ハッシュは 32 ビットの整数です。 32 ビットの整数は 0 ～ 42 億を構成します。 42億を超えるとリングを形成し、再び0に到達します。このような整然としたセグメンテーションにより、通常の使用時にはバイナリ検索によって検索されます。

コンシステント ハッシュの通常の使用にはまだ問題があるため、通常は仮想ノード レイヤーを使用します。仮想ノード レイヤーを使用する理由は何ですか?雪崩現象を避ける必要があります。上流サーバーがクラッシュした場合、影響を受けるのは周囲のノードのみです。周囲のノードの負荷が 80% に達した場合、このマシンへのすべてのトラフィックがそのマシンに送信され、このマシンもクラッシュします。それがクラッシュすると、下流もクラッシュし、すべてがクラッシュします。

私たちが期待するのは、ノード A がダウンした後、すべてのノードがトラフィックを均等に共有できることです。これは最善の解決策であり、実際には二次ハッシュで実現できます。いわゆる仮想ノード層は非常に印象的ですが、実際には二次ハッシュにすぎません。最初のハッシュはリングを形成し、2 番目のハッシュはリングの別のハッシュを作成します。これは基本的に 2 つの層です。

一般的に言えば、レイヤーごとに 100 ～ 200 個あります。このような方法により、雪崩を回避でき、分布の均一性も得られるという利点もあります。

どのような機能を使用しても、完了後に独自のデータ要求の配布と一致しなくなります。データが非常に大きい場合、この問題をどのように解決しますか?二次ハッシュにより、分散をよりバランスよくすることができます。

最後に、持続性についてお話ししましょう。以前、永続データに取り組んでいたときは、2 つの方法しかありませんでした。たとえば、データに冗長なコピーが多数ある場合、2 つの方法が考えられます。毎回、両方のマシンに書き込むことになるため、書き込み速度のパフォーマンスが非常に悪くなります。書くときは、ランダムに 1 つ書いて、それを非同期で他のマシンと同期します。一貫性は比較的低く、データが失われる可能性がありますが、パフォーマンスは向上します。 Amazon に関しては、2000 年代初頭に Quorum の論文が発表され、NWR アルゴリズムについて説明されていました。冗長データの数は N、W は書き込みノードの数、R は読み取りノードの数、N は冗長ノードの数です。いわゆる高可用性は、W+R>N によって実現できます。

W+R は N より大きいです。たとえば、データには読み取りと書き込みの 3 つのノード (R1R2R3) があります。と書くと、1と3は返されますが、2は返されません。今度こそまだ成功できるだろう。また、読み取り時には 2 だけ読み取ればよく、1 または 3 は必ず読み取ります。このとき、タイムスタンプ方式を使用して、誰が正しいデータを持っているかを判断できれば、データの強い一貫性を確保できます。

W が N より大きい場合、元々 3 つのノードに書き込んでいましたが、現在は 1 つのノードがダウンしています。これより少ない場合、たとえばノードが 2 つしかなく、1 つのノードがダウンしている場合は、書き込みは使用できません。ノードが 3 つある場合、1 つに障害が発生しても引き続き使用できます。

本日の私のシェアは以上です。まとめると、下から上への見方は必ずしも正しくない可能性があるということです。