WeChat R&Dシステムにおける分散構成システムの設計の概要

[[347509]]

著者: ypaapyyang、Tencent WXG バックエンド開発エンジニア、個人公開アカウント: Coder クラス代表。

本稿では、分散構成システムの必要性、実現可能性、および主要な制約を分析し、WeChat R＆Dシステムにおけるこの一連の分析に基づいた実践的な試みを紹介することを目的としています。

序文

多くのビジネス開発の学生にとって、運用資料の処理は簡単な作業ではなく、通常はカスタマイズされたデータのクリーニング、形式の変換、およびツールの開発が必要になります。筆者もかつてそんな嫌な思い出を持っていた。 10種類近くの構成データを一度にインポートするのに2日かかりました。この経験に価値があるとすれば、分散構成システムについて考え、それを職場で実践するきっかけとなり、再びこのような悪いプロセスに陥らないようにできる点です。

構成定義

ソフトウェアモデリングの本質は現実世界 (人、物、オブジェクト、ルール) のマッピングであり、マッピングの出力にはプログラミングシステムと構成が含まれることはわかっています。構成により、プログラムの実行時の動作を動的に変更する機能が提供されます。これは、「システム実行時の飛行姿勢の動的調整」と呼ばれることがよくあります。根本的な原因は、「人間はすべてを制御したり予測したりすることはできません。ソフトウェア分野にマッピングする場合、システムの特定の機能特性のためにいくつかの制御スレッドを常に予約しておく必要があります。そうすれば、将来必要になったときにこれらのスレッドを手動で操作して、システムの動作特性を制御できます。」

したがって、この記事で言及する構成は、具体的には社内オペレータ（製品、運用、研究開発などを含む広義のシステムオペレータ）によって生成されたデータを指し、プログラミングシステム（リアルタイムシステム、バッチプログラム、データタスクなどを含む）上の入力パラメータとして機能します。

要約すると、構成には通常、次の 3 つのタイプが含まれます。

a.環境構成。IP、ポートなど、アプリケーションを実行するための環境関連のパラメータを定義します。

b.アプリケーション構成。初期メモリ割り当てサイズ、データベース接続プールサイズ、ログレベル、アカウントパスワードなど、アプリケーション関連のパラメータや情報セキュリティ制御を定義します (パスワードや証明書などは構成システムに配置するのではなく、統合サービスを使用して暗号化および復号化する必要があります)

紀元前ビジネス構成では、最も一般的な機能スイッチ、イベントに参加する販売者のリストなど、アプリケーションによって実行されるビジネス動作データを定義します。

システムの制約

データモデル

構成の最も基本的なデータ単位は、キー = 値 (つまり、構成項目) です。たとえば、関数スイッチは通常、ブール値を使用してプログラム実行リンクに影響を与える最も単純なタイプです (グレースケールの場合は考慮しません)。しかし、キーバリュー型だけでは不十分です。たとえば、DB 接続構成には、IP、ポート、ユーザー名、パスワードなどのフィールドが含まれており、ini ファイルの実装ではさまざまな構成項目で構成されます。これらは論理的に同じ構成オブジェクトに属します。したがって、オブジェクト指向の設計概念に基づくと、key=object はより一般的な構成モデルであり、物理的な実装では json または xml、または protobuf メッセージになることができます。

オブジェクトタイプのデータは、フラットまたはマルチレベル (ネスト) のいずれかになります。実際のビジネスアプリケーションでは、フラットデータには特殊性があり、通常はより多くのエントリが含まれます。最も一般的なデータはホワイトリストであり、これには数万ものエントリが含まれる場合があります。オフラインでは、社内の運用スタッフが Excel を使用してこのタイプのデータを管理します。単純にオブジェクトにパッケージ化すると、データが多すぎるとシステム効率が低下する可能性があります (構成の書き込み効率の低下または構成の読み取り効率の低下)。そのため、これを表現するために、プレーンオブジェクトの配列、つまりキー=テーブル型のデータを使います。

モデルへのアクセス

製品ユーザーが生成したデータとは異なり、構成システムのデータフローは単方向であり、オフラインシステムとリアルタイムシステムを組み合わせて読み取りと書き込みを分離します（非同期書き込みとリアルタイム読み取り）。最終的に構築したい分散構成システムも、このタイプのアクセスモデルに基づいて設計する必要があります。

システムの制約

当然のことながら、プロデューサーとしては、内部オペレーターのすべての構成はテキストタイプ (読み取り可能) で、データ量が少なく (ユーザーやシステムなどの運用データに比べて)、必要なストレージスペースが少なく、更新頻度が低い必要があります。全体の構成システムアーキテクチャにおいて、入力側はキーボードのようなもので、CPU に比べて非常に遅いデバイスであることがわかります。システムの使いやすさ、操作のしやすさ、セキュリティに対する要件は高くなります。

構成システムのアクセスモデルを部分的に満たすユーザーポートレートシステムについて考えてみましょう。つまり、データフローは一方向であり、オフラインシステムがポートレートデータの書き込みを担当し、リアルタイムシステムがデータを読み取ります。しかし、まず第一に、そのデータ生成者は通常、オペレーターではなくオフラインタスクです。第二に、関係するデータの量が膨大であり、通常はカスタマイズされたストレージエンジンが必要になります。設定体系が全く異なります。

比較すると、構成システムの消費者は読み取りアクセスの頻度が高く、システムのスループット、レイテンシ、ネットワークトラフィック、可用性、一貫性、および要求の単調性に対する要件が高くなります。その後、それぞれの問題について深く検討していきます。

構成システムの設計では、上記のデータモデル、アクセスモデル、およびシステム制約を十分に考慮する必要があります。 (不思議なことに、関連する構成システムの実装を調べていたとき、一貫性とリクエストの単調性に関する議論をほとんど見かけませんでした。これが、この記事を書くきっかけにもなりました。)

セキュリティ上の制約

構成によってシステムの実行時の動作を簡単に調整できるため、構成のセキュリティは非常に重要です。セキュリティを実現するための必要条件は、適切な人が適切な構成を適切な方法で適切なタイミングでリリースできるようにすることです。したがって、構成システムは、グレースケールリリースの基本機能をサポートするだけでなく、権限管理、権限粒度管理、構成変更のレビュー、監査、履歴バージョンなどの領域での構築も強化する必要があります。

システムの進化

スタンドアロン構成ファイル

スタンドアロンシステムの時代では、基本的に構成ファイルを使用して構成データ (ini ファイル、xml ファイルなど) を保存します。構成ファイルは理解しやすく、実装も簡単で、可用性も高いため、分散クラスターの時代でも広く使用されています。

ただし、構成ファイルには次のような多くの欠点があります。

使いやすさが悪く、主に単一のデータ型で表現されていることに反映されています。たとえば、ini は設定項目、つまりキー = 値型のデータのみを管理できます。 XML ファイルを使用して key=table タイプのデータを管理する場合、ファイルコンテンツの初期化効率が低く、エラーが発生しやすく、保守が困難になります。
操作性が悪い。基本的に、構成ファイルは開発者のみが変更およびリリースできます。製品や業務の日常的な業務資料の変更は開発実行に関与する必要があり、これは業務プロセスの効率に重大な影響を及ぼします。
正確性と安全性を保証することは困難です。構成ファイルは実装が簡単なため、多くのチームはオペレーティングシステムの構築を怠ります。 R&D 担当者は、設定ファイルの恣意的かつ悪意のある変更を防ぐことができず、きめ細かい権限管理、操作レビュー、監査を行うことは不可能です。
放出効率が低い。構成ファイルは単一のマシンに展開されます。クラスターが大きい場合、構成ファイルへの変更は、ネットワーク全体にリリースされるまでに長いグレースケールリリースプロセスを経る必要があります。設定ファイルが静的にロードされる場合、バイナリを再起動する必要があり、研究開発および運用保守担当者のエネルギーが大量に消費されます。
ファイルの一貫性を保証することは困難です。構成変更をリリースするプロセス中にクラスターでダウンタイムが発生すると、異なるマシン間で構成の相違が発生します。自動修正機能はなく、人員または運用・保守システムのサポートに依存するため、ビジネスが未定義の動作に陥ることになります。

使いやすさ、操作性、正確性、セキュリティはオペレーティングシステムを構築することで向上しますが、公開効率の低さやファイルの一貫性の確保の難しさは、スタンドアロン構成ファイルの致命的な弱点です。本質的には、スタンドアロン構成ファイルシステムは外部からの変更を受動的かつ個別に受け入れ、プロアクティブな機能がないためです。

集中化された構成ファイルセンター

その結果、上記の問題を解決するために集中型の構成ファイルシステムが登場しました。開発者は、構成ファイルを独立したサードパーティサービスに保存します (通常は ZooKeeper によって管理されますが、一部のチームでは独自にマイクロサービス管理も実装します)。その後、エージェントは定期的に構成をローカルキャッシュにプルするか (プル)、イベントサブスクリプション通知機能を通じて対応するクラスターに変更を公開します (プッシュ)。

集中型構成ファイルシステムは、リリース変更の効率性と構成ファイルの一貫性の保証という問題を特に解決します。しかし、私が知っているアプリケーションケースでは、解決する必要がある次のような問題がまだ残っています。

一貫性の粒度は粗いです。集中型の構成ファイルでは、分散クラスターが最終的な一貫性に到達することしか保証できません (時間はプルとプッシュの頻度とレートによって異なります)。ただし、すべてのプロセス、スレッド、コルーチンがいつでも任意の構成で同じデータを参照することを保証することはできません。これは通常、予期しないビジネス障害につながります。
リクエストの単調性は保証されません。ビジネスリクエストでは、ユーザーに表示される構成コンテンツが静的であることが望まれます。途中で変更が発生すると、業務に支障をきたす可能性があり、深刻な場合にはユーザーデータの状態が乱れる原因にもなります。ただし、集中型の構成ファイルシステムに基づく構成は通常は動的に読み込まれ、構成の変更はいつでもリアルタイムシステムに反映される可能性があり、その結果、ビジネスリクエストで異なるデータ状態が見られることになります。
セキュリティはまだ完全には保証されていません。集中化された構成ファイルの変更によって権限を制御できますが、コンシューマーマシンでは、開発者がローカル構成ファイルキャッシュを手動で変更して、プログラムの実行動作に影響を与えることができます。
グレースケール機能をサポートできません。構成ファイルの変更は完全に発行されます。グレースケールリリース機能をサポートする場合は、ビジネス側を関与させて独自に実装する必要があります。

構成ファイルシステムの問題は、スタンドアロン構成ファイルであるか集中型構成ファイルであるかにかかわらず、キャリアとしての構成ファイルと集中型構成ファイルシステムのパイプラインの位置付けによって最終的に決まり、洗練された管理に高いコストがかかります。

構成ファイルの可視性と読みやすさはプロデューサーにとっては重要ですが、コンシューマーにとっては無関係です。したがって、リンク全体が構成ファイルによって運ばれると、読み込み効率が低下する可能性があります (たとえば、数千万のブラックリストとホワイトリストを処理する場合や、ビジネス関係者がリンクのリアルタイムでの動的な読み込みを要求する場合など)。
構成ファイルでは、メタデータを安全かつ便利に管理することが困難です。一貫性、単調性、セキュリティを実現するために、構成にはメタデータ情報の管理が必要です (詳細は後述)。ただし、ビジネス側が高コストの自己実装を使用しない限り、構成ファイルシステムにはこの機能がありません。
構成ファイルの数は構成の数と密接に関係しています。時間が経つにつれて、設定ファイルの数が増え、新たな運用上の問題が発生します。
集中型の構成ファイルシステムは通常、パイプラインとしてのみ位置付けられます (私の知る限り)。つまり、構成ファイルの内容を理解または維持しません。エージェントには単一の機能があり、ビジネスコンシューマーはシステムと直接対話せず、構成ファイルのみを参照します。疎結合により可用性は向上しますが、ビジネス側では構成ファイルを処理するために多額の開発コストを投資する必要があります。

構成ファイルは、構成の物理的なキャリアにすぎません。上記の欠点は克服できないものではありません。ただし、構成ファイルに基づく構成システムでは、上記の機能を実装するためのコストが高く、より多くの使用上の制約と周辺サポート機能が必要になります。

データベース構成の保存

構造が複雑で種類が多い構成の場合、通常、ビジネス R&D 担当者は構成ファイルを直接使用して実行することはありません。代わりに、データベース (リレーショナルまたは非リレーショナル) テーブルを使用して構成を保存し、データをインポートするためのツールを作成します。このストレージソリューションは、構成ファイルに関するいくつかの問題を克服し、より洗練された構成管理を提供します。ただし、カスタマイズの度合いが高く、再利用性が低く、開発の重複が多いという明らかな欠点もあります。したがって、これを改善し、構成の保存、読み取り、書き込み、および管理プロセスの共通性を抽出し、それらを普遍的かつプラットフォームベースにする必要があります。

ソリューション思考

物理モデル

設定ファイルは、洗練された方法で管理することが難しく、侵入されやすい物理エンティティ (ローカルファイル) を持っているため、設定を保持するための新しいデータ構造が必要です。前述したように、構成には key=object と key=table という 2 つのデータモデルがあります。ユーザーにとって、構成は表示可能、読み取り可能、および管理可能である必要があります。この目標を達成するには、社内の運用担当者と構成システムの中核との間に、適切に設計された運用システムを構築するだけで済みます。バックエンドはどうですか?消費者にとって最も重要なのは、伝送と計算の効率です。同時に、マイクロサービスフレームワークと整合させるためには、protobuf メッセージが間違いなく最適な形式です。

ただし、protobuf は一目瞭然ではありません。メッセージ定義がないと、テキスト構成を pb バイナリストリームに変換することも、デシリアライズすることもできません。そのため、ビジネスメッセージの定義をオペレーティングシステムに持ち込む必要がありますが、protobuf は視覚的な編集にはあまり適していません。したがって、実現可能なアイデアは、JSON データに基づいて構成を定義、視覚化、送信、および保存することです。データ型の変換は、ビジネス側に到達したときにのみ実行されます。

セキュリティ管理

構成操作システムを構築し、それをオペレーターが構成を管理するための唯一のエントリポイントにすると、簡単に高い収益を得ることができます。オペレーティングシステムに応じて、さまざまな構成のセキュリティ強化を実行できます。たとえば、構成の変更には対応する権限が必要であり、レビューに合格した後にのみシステムに適用できます。すべての操作には監査機能が必要であり、構成の履歴バージョンをすばやく確認できます。

同時に、グレースケールやロールバックなどの機能もオペレーティングシステムに基づいて操作する必要があります。

システムSDKの設定

前述のように、集中型構成ファイルシステムのパイプラインの位置付けでは、エージェントは構成を定期的に取得してローカルファイルシステムにキャッシュする役割のみを担います。ビジネスシステムは構成システムと疎結合されています。設定ファイルの開発コストは依然として高いと考えています。ビジネス関係者にとって、最適な開発方法は次のとおりです。

 int GetConfig<Message>(const std::string& key , ::google::protobuf::Message& msg);

ファイルの内容や形式を理解する必要はありません。次に、ビジネス側に構成システム SDK のセットを提供して、構成システムの詳細、データ構造、およびその他の情報を保護する必要があります。これにより、ビジネス側は構成された Protobuf メッセージオブジェクトのみを参照できるようになります。

SDK に基づいて、消費者はわずかに介入するだけで (ビジネスプラグイン、以下を参照)、プロトコル変換、構成キャッシュ、プロセス、スレッド、コルーチンの高速化と最終的な一貫性、要求の単調性、グレースケールリリースの機能を実現できます。

構成システム SDK は、洗練された管理の基盤となります。構成コンテンツ自体に加えて、構成メタデータ情報を維持することで、上記の機能を実現できます。

非同期

非同期は SDK を構成するための鍵となります。多くのローカルキャッシュ更新は、リアルタイムリンク要求によって定期的に処理されます。これは実装が簡単ですが、特に構成にビジネスロジックも構成する必要があることを考慮すると、効率に問題があります。したがって、最善の解決策は、非同期プロセスを通じて構成の読み込み、初期化、およびその他のロジック処理を実行することです。

非同期によって発生する問題は、非同期プロセスとリアルタイム要求の同時実行性です。つまり、構成変更プロセス中に、非同期プロセスはリアルタイムリンクの読み取り要求をどのように処理すればよいのでしょうか。これはエンジニアリングの問題であり、別の記事で説明します。実現可能なアイデアとしては、マルチバージョンと参照カウント技術があります。

ビジネスプラグイン

非同期によって得られるもう 1 つの利点は、構成が有効になったときに、構成の正確性の確認やビジネスに適したデータ構造の構築など、ビジネスでいくつかの初期化アクションを実行できることです。たとえば、ビジネスホワイトリストは pb 内の単なる配列です。企業がヒット検索を実行する場合、コストは比較的高くなります。ビジネスにとって最も望ましい方法は、間違いなく地図をストレージに使用することです。したがって、SDK を非同期に構成すると、ビジネスプラグイン機能の基盤が提供されます。

プッシュとプル

構成の更新を積極的にプルするように SDK を構成することをお勧めします。プッシュとプルの弁証法は、効率性と可用性にあります。プッシュはより効率的であり、無駄なネットワーク消費はありません。ただし、このプッシュにより、新しいシステム依存関係 (イベントセンターなど) が導入されます。必要ない場合はエンティティを追加しないでください。この考えに基づいて、SDK が定期的にそれらを積極的にプルすることを推奨します。効率に関しては、さまざまなエンジニアリング手段を通じて許容できるレベルまで最適化できます。

もちろん、これはシステムの規模によっても異なります。部分的なセンターレベルではなく、会社のマシンの構成システムについて議論している場合は、プッシュまたはプッシュプルの組み合わせモデルも真剣に検討します。

高速で最終的に一貫性のある

スタンドアロン構成ファイルシステムであっても、集中型構成ファイルシステムであっても、重大な不一致が存在します。構成の変更の場合、最終的な一貫性 (つまり、すべての同時操作で同じデータ状態が認識される) が実現されるまでには通常長い時間がかかります。

実現可能なアイデアとしては、複数のバージョンを用意し、時間制限を設けて有効性を確保することが挙げられます。構成は、将来の特定の時点（SDK が最新のデータを取得したとき）にのみ一般公開されます。すべての SDK がデータを取得したことを確実にする方法については、可用性の問題が関係しますが、これについては別の記事で説明します。

単調さを要求する

タイミングによっては、リクエストの単調性の問題を解決することはできません。要求の単調性とは、リアルタイムサービスが要求を処理するときに、保留中のデータが有効データになった場合でも、要求呼び出しスタック中に読み取られた構成コンテンツが静的で変更されない必要があることを意味します。 1 つのアイデアは、スレッドプライベート変数 (コルーチンプライベート変数) を通じて構成バージョンをキャッシュできることです。

グレースケールリリース

SDK のマルチバージョン機能に基づいて、グレースケールリリースの実装も容易です。グレースケールリリース機能は、有効な構成バージョンを選択する機能にすぎません。ローカルマシン、ロール、リクエストのビジネスキー (ユーザー、販売者、注文など) などがグレースケールの範囲に該当する場合は新しいバージョンが使用され、それ以外の場合は元のバージョンが使用されます。

効率性の向上

効率性の向上には、ネットワーク経由で送信されるデータの量の削減と、構成ストレージサービスへの負荷の軽減が含まれます。これらは特定のエンジニアリング対策であり、この理論セクションでは説明しません。

ユーザビリティの改善

分散システムの可用性の向上は一般的なトピックです。構成システムの独自の機能に焦点を当てるため、この記事では構成システムについては具体的に説明しません。

(ただし、システム内の単一ポイントを最小限に抑えることは重要な原則です。これは、前のセクション「プッシュとプル」でも言及されています。同時に、ビジネスの可用性のために、サードパーティの構成システムの運用機能、プロアクティブな障害検出機能、障害通知機能、再現および位置特定機能も非常に重要です。これは、車輪の再発明の重要な理由でもあります。多くのチームは優れたソフトウェアを持っているかもしれませんが、サービス機能（主に運用機能を指します）は少し不十分です。)

[この記事は51CTOコラムニスト「Tencent Technology Engineering」によるオリジナル記事です。転載については原作者（WeChat ID: Tencent_TEG）までご連絡ください。

この著者の他の記事を読むにはここをクリックしてください

<<: VMware、企業のアプリケーション近代化を支援する製品ポートフォリオを強化

>>: クラウドネイティブ時代において、アプリケーションアーキテクチャはどのように進化するのでしょうか?