スズメのようなマイクロ分散アーキテクチャを設計するにはどうすればよいでしょうか?

序文（本来の意図）

このシステムを設計する本来の目的は、ビジネス (またはマシン クラスター) のストレージ モデルを記述し、プロキシ キャッシュ サーバーのディスク ストレージと戻り率の関係を分析することです。このシステムの意義は、Tencent Cloud のコスト最適化プロセス中に、コンピュータ ルームの機器の拡張に対して定量的なガイダンスを提供することです。前半では、CDN キャッシュ モデルの背景を紹介し、理論的な考察を行います。後半では、実際に小型でありながら完全に機能する分散型一般システム アーキテクチャを構築し、最後にコスト最適化で発生する実際的な問題を解決するためのバックグラウンド関連機能をシステムに追加します。

キャッシュ サーバー ストレージ モデル アーキテクチャ (背景):

画像

図1 ストレージモデル

Tencent CDN のオンライン ルーティングは、さまざまな地域とオペレータに分散された OC -> SOC -> SMid -> オリジン ステーションの順に行われます。キャッシュ サーバーはノードの各レベルに展開されます。ユーザーからのリクエスト トラフィックの一部はサーバーに到達し、他の部分はソースへのトラフィックを生成します。

業務帯域幅が自然に増加し、ユーザー側帯域幅が増加すると、業務バックツーソース率が変わらないと仮定すると、ディスク キャッシュ排除更新 (排除) 率が速くなり、次の業務ボトルネックとして現れます (iowait が高くなり、バックツーソース帯域幅が高くなり、ディスク領域のサイズが制限されているためキャッシュ排除によりバックツーソース率が高くなります)。

この原則を説明します。 2 つの極端な状況を想定します。1 つは、デバイスのディスク容量が無制限で、ビジネスからのトラフィック キャッシュがソース サイトのキャッシュ ルールによってのみ制限される場合です。キャッシュの有効期限が切れていない限り、ディスクは無期限にキャッシュすることができ、戻りトラフィックは最初の訪問のトラフィックのみを必要とするため、戻り量（率）はビジネス特性（繰り返し率）にのみ関連します。もう 1 つの極端な例は、ディスク制限が小さい (ゼロ) 場合で、ビジネス キャッシュ設定の有効期限が切れるかどうかに関係なく、クライアント アクセス ボリュームはソースに対して 1:1 になります。平均的なビジネス キャッシュ期間は 1 時間であると想定します。そして、この時間の初期キャッシュ帯域幅（同じキャッシュ キーへの複数のアクセスを 1 つとして扱う）が、このハード ディスクに必要なスペースになります。このサイズは適切であり、ディスクが業務量に対応できる十分な大きさであることを保証できます。この量に到達できない、または到達したとしても、ビジネスの自然な成長により、最初のキャッシュ帯域幅が 1 時間以内に増加し、ハードディスク容量が不足するとします。

設備の拡張が解決策です。しかし、ストレステストシステムが開発される前は、どの程度の設備を拡張する必要があるかを証明する客観的なデータがありませんでした。あるいは、設備の拡張に対するグレースケール検証は行われず、設備の設置後すぐにマシンがオンラインで展開されます。実験マシンでオンライン ログを再生し、ストレージ シミュレーション曲線をシミュレートして、オンライン コンピュータ ルームでの適切な機器ストレージをガイドしました。これがリプレイログシステムを構築する意義です。

小さいながらも完全なリプレイ ログ モデル (概要)

この章では、次のモジュールを定義します。

ログ サーバーをシミュレートする: 特定のオンライン コンピュータ ルームのアクセス ログを一定期間ダウンロードします。ログには 10 分間のアクセス記録が保存されます。コンピュータ室にあるマシンの数だけログをダウンロードします。ログ サーバーは、タスク シャーディング情報のクエリ サービスも提供します。タスク ID が pig_120t のタスク スライスを再生する必要があるとします。次の図はタスク スライスの詳細を示しています。

画像

図2 ログサーバーのログフラグメントファイル

タスク コントローラー: タスクを開始または終了するためのメイン スイッチ。タスクは特定のブルートフォース サーバーとプロキシ サーバーに均等に分散されます。タスクをタスク プールに挿入し、サーバーのリアルタイムの合計トラフィック、バックツーソース トラフィック、リクエストの合計数、バックツーソース数データを収集し、バックツーソース レート結果データ テーブルに挿入します。

Broiler : タスク プールのタスク テーブルをポーリングします。タスクがある場合は、タスクの詳細（時間、オンラインコンピュータルーム IP）に応じて、ログサーバーにシャードのログをダウンロードするように要求します。指定されたプロキシ サーバーへの要求を再生します。

プロキシ サーバー: リアルタイムのソース データ クエリ サービスを提供します。そして、nws キャッシュ サーバーなどのコンポーネントをインストールします。このマシンは、オンライン コンピュータ ルームのソフトウェア モジュールに相当します。

リアルタイム表示インターフェース：リアルタイムの返品率や一部のタスクの異常ステータス情報をいつでも表示できます。

図 3 は、クライアントとサーバー間の相互作用図です。図4は、タスク実行中のタスク制御端と他のモジュール間の連携プロセスを示しています。

画像

図3: ボットとプロキシサーバーのアーキテクチャ

画像

図4 制御側でのタスク連携処理

分散システムの特徴

ログ再生モデルの中核は高性能ストレス テスト システムですが、ログのダウンロード、ログの分析と再構築、結果データの収集、データのレポートと表示などのロジックを追加する必要があります。分散システムの中核となるのは、スケーラブル、回復可能、構築が容易、フォールト トレラント、自動化されているかどうかです。以下の内容は順次拡充してまいります。

まず、一般的なモデルにおける高性能についてお話ししましょう。オンラインログをシミュレートします。ログ再生速度はオンライン QPS よりも速くする必要があるため、このシステムは効率的である必要があります。マシンを再生できる速度によって、結果を分析できる速度が決まります。同時に、速度が速いほど、必要なブロイラーのリソースが少なくなります。著者は最終的に、Python と Golang のさまざまな URL リクエスト ライブラリの中から、Golang を使用してブロイラーを実装することにしました。 Golang はネイティブの c+epoll と同じくらい高速ですが、コードの実装ははるかに簡単です。理論的には、プロキシのパフォーマンスボトルネックの分析を実行しました。オンライン ログはシミュレーション ログよりも複雑なので、QPS が多少低下するのは避けられません。 Golang クライアントは期待された目標を達成します。

スケーラビリティ: シミュレートされたマシン クラスター内のブロイラーの数をいつでも増やしたり、ストレス テスト タスクにアイドル状態のプロキシ サーバー リソースを追加したりできます。したがって、システムはいつでも新しいマシンを利用可能なマシン データ テーブルに追加します。

画像

図5 システムの動的スケーラビリティ

回復可能: 分散システムはスタンドアロン システムとは異なります。さまざまな失敗は避けられません。場合によっては、システム内の一部のノードに障害が発生することがあります。未処理の結果を引き続き使用するよりも、このノードを使用しないことをお勧めします。中間状態はなく、0 または 1 のいずれかです。さらに、分散システムのネットワーク伝送遅延は制御できません。したがって、ストレス テスト システムには、ハートビート検出が失敗した場合にデータ テーブルからブルート フォース サーバーを自動的に削除する機能など、フォールト トレラント メカニズムが設計されています。インターフェース例外許容度。タイムアウトした未完了のタスクを削除します。 Crontab は定期的に終了プロセスなどを取得します。

簡単に構築できます: ajs インターフェイスとバッチ インストール スクリプトを使用します。ボットとサーバーを自動的に展開します。 DNS 解決 IP (ログ サーバー、タスク プール、および戻り率の結果が配置されているデータベース IP) を構成し、TCP time_wait 状態を再利用し、いくつかのシステム制限を解除することを忘れないでください (ulimit fd 制限を解除し、ここで 100000 に設定し、永続的な設定のために /etc/security/limits.conf を編集します)。ブルートフォースマシンに依存するプログラムランタイムライブラリがある場合は、それらを同時にダウンロードする必要があります。ブルートフォース マシンにブルートフォース クライアントと構成をダウンロードし、サーバー マシンにサーバーと構成をダウンロードし、スケジュールされた起動プログラム スクリプトをダウンロードして、スケジュールされた実行のために crontab に追加します。上記のすべてはバッチ スクリプトを使用して自動的に実行されます。

設計パラダイムに関する考察

単一生産者と複数消費者

ブルートフォース クライアントの設計では、ログ ファイルを 1 行ずつ読み取り、それをメッセージ パイプラインに追加し、複数の実行ワーカーがメッセージ パイプラインから URL を取得して、シミュレートされた要求を実行します。メッセージ パイプラインは、実行するログ URL を送信します。 IO を消費するプログラムとは、コンシューマーがアクセス ログを実行して結果を即座に完了するが、プロデューサーがログに対して複雑な文字列処理 (正規表現など) を実行する必要がある場合、次回データを取得できず、パイプラインによってブロックされることを意味します。もう 1 つは CPU を消費するプログラムです。ログ URL が事前処理されている場合、プロデューサーはデータをメッセージ パイプにコピーするだけです。消費者が URL にアクセスすると、予期しないネットワーク遅延が発生します。すると、複数のコンシューマ（ネットワークアクセス時間も含まれるため、コンシューマの数はCPUコアの数の2倍などを超えるように設計されている）が同時にアクセスすることになり、読み取り側の速度が書き込み側の速度よりも遅くなります。ログ ファイルの実験では、180,000 件のログ レコードを処理するのに 0.3 秒かかりましたが、これらの URL にアクセスするタスクを完了するには 3 分かかりました。これは CPU を消費するプロセスであることは明らかです。 IO を消費するプログラムの場合。 Golang には、ファンアウトと呼ばれるメッセージ モデルがあります。次のように設計できます: 複数の読者が複数の chan リストの chan を読み取り、1 人のライターが 1 つの chan を書き込みます。 Fanout は、書き込み側の chan をループ内の chan リスト内の chan に書き込みます。

マップリデュース

場合によっては、特定の地理的な場所にある通信事業者のデータセンターのログ分析を行うこともあります。コンピュータ ルームには複数のマシン IP が含まれます。複数のボット クライアントがログに並行してアクセスするように適切にスケジュール設定すると、マージされたリターン率データをより迅速に取得できます。

並列メカニズム、古典的なマップリデュース、ログファイルはコンピュータルーム内のマシンのIP緯度に従ってスライスされて分散され、N個のブロイラーが並列にアクセスするために起動され、最後のブロイラーがタスクを完了すると、各ブロイラーのデータがマージされ、成功したリクエストの数、成功したリクエストのトラフィック、失敗したリクエストの数、失敗したリクエストのトラフィックなどに従ってカウントされます。オンラインログによる校正にも使用されます。ここでのマッパーはブロイラーであり、生成されたデータ テーブルは関心のあるタイプ (リデューサー) に応じて抽出されます。

簡素化されたマップ リデューサー (分散ファイル システムに基づいていません)。マップとリデュース間のデータ転送は、データ テーブルを使用して実装されます。各マッパーによって生成されたログ データは、最初にローカルに保存され、その後データ テーブルに報告されます。ただし、データ テーブルのサイズ制限により、ヘッダー アクセス URL のみをアップロードできます。したがって、この方法を使用すると、データは不完全になるか、完全に正確ではなくなります。これは、おそらく 2 台のブロイラーの結合されたヘッダー データに、ブロイラーがアップロードしていないログがたまたま含まれているからです (ログが 1 台のブロイラーのトップ訪問数の基準を満たしていないため)。

では、この問題をどう解決すればよいのでしょうか?根本的な理由は、集約されたデータが配置されるファイルシステムが分散ではなくローカルであることです (Hadoop の HDFS はおそらくこの要求に基づいて発明されました)。ステータス コードの次元の場合、http ステータス コードの総数は非常に少ないため、このアイデアは問題ありません。したがって、URL ディメンションの場合、たとえば、特定のコンピューター ルームで 1 羽の鶏に対して実行される 1 つのタスクでは、10 分間で URL データの総量が 180,000 になります。ログ重複カウントが 100 を超えるブロイラー データのみを確認します。最大誤差は 100 * ブロイラーの数であるため、ブロイラーが 10 匹いるコンピュータ ルームの場合、合計結果は 1000 を超えます。すべて信頼できる。ドメイン名のディメンションの場合、少数の上位顧客のトラフィックが帯域幅の大部分を占めます。これはいわゆるホットキーであり、少数のホットキーがトラフィックの大部分を占めています。したがって、ドメイン名の広さに関しては、指定されたドメイン名の URL リストに焦点を当てることができます。データ テーブルにローカルに報告されるデータの量が大きすぎる場合は、URL を短いアドレスに圧縮することもできます。もちろん、他社を追い越したくない場合は、この問題を強制的に解決する必要があり、そのためには HDFS などの分散ファイルシステムが必要になる場合があります。

ストリーム処理

ログ クライアント システムを開発する場合、このタスクに必要なログ (通常はマシンの 10 分間のアクセス ログ) をログ サーバーからダウンロードする必要があります。まず、ローカル ログがタスク サーバーに送信され、再生タスクが照会されます。次に、ログ サーバーに移動してダウンロードします。シミュレートされたクラスターが DC ネットワーク上に構築されている場合、10 分間のログ (約 150 MB のファイル) のダウンロードは、ほぼ 1 ～ 2 秒で完了します。しかし、OC ネットワーク上に分散システムを構築する場合、OC ネットワークのボットネット サーバーはダウンロードのために DC (コンピュータ ルームの信頼性を考慮して、ログ サーバーは DC ネットワーク上に設置) まで移動する必要があり、イントラネットから外部ネットワークへの NAT 変換後、ダウンロードに約 10 秒かかります。ログサーバーのダウンロードが完了するまで待つ必要がある場合も、時間がかかります。

分散システム、いわゆるストリーム処理では、バッチ処理とは異なり、データは無制限です。ログのダウンロードがいつ完了するかはわかりません。バッチ処理の前工程と後工程の関係は、生産ラインにおける工程に似ています。次のプロセスは前のプロセスが完了した後にのみ開始され、次のプロセスは前のプロセスの出力結果が何であるかを正確に認識します。

いわゆるストリーム処理では、前のプロセスの部分的な出力結果が到着したときに次のプロセスを開始する必要があります。前のプロセスは出力を継続し、次のプロセスは処理イベントに応答する必要があります。後者では、プログラムを頻繁にスケジュールする必要があります。

メッセージ ブローカー: 前のステージからの出力の一部がメッセージ ブローカーに入力されます。メッセージ システムは、ログが完全であることを検出すると、次のプロセスへの入力を生成できます。ここで問題が発生します。ログのダウンロード速度 (10 秒) は、これらのログの再生速度 (3 分) よりもはるかに速くなります。メッセージ システムに応じて、バッファがない場合は破棄、キューに応じてキャッシュ、次のプロセスと前のプロセスの一致速度を同期させるフロー制御を実行するなどのアクションが考えられます。ここでは、キューをキャッシュすることを選択します。もちろん、厳密な分散データベース設計では、メッセージ ブローカーはデータ損失を考慮できるノードです。ブローカーは、プログラムのコアダンプを防ぐために、完全なデータを下流のプロセスに送信し、バッファー データをバックアップ用にハード ディスクにキャッシュします。フロントエンド プロセスが遅い場合は、フローを破棄または制御するための包括的なソリューションを構成できます。ここで、メッセージ ブローカーはデータベースとは異なります。中間の未処理データは一時的に保存され、処理済みのメッセージはストレージからクリアする必要があります。

要約する

もちろん、実際の生産ラインの分散システムはこれよりもはるかに複雑ですが、この記事で実装した 0 から 1 までのミニスパロウ分散システムには、一定の実用的な意義があります。それは一夜にして達成できるものではなく、継続的な反復が必要です。もちろん、このシステムは著者の KPI ストレージ モデル分析も完了します。途中で問題が発生した場合、設計の考え方と改善点をまとめ、全員で共有します。