WeBank: 分散アーキテクチャの高可用性

【51CTO.comオリジナル記事】はじめに

インターネット金融が急速に発展するにつれ、データ量の爆発的な増加と大量の同時実行トランザクションのシナリオに直面して、従来の集中型アーキテクチャのパフォーマンスのボトルネックがますます顕著になってきています。これを踏まえて、近年ではますます多くの銀行などの金融機関が分散アーキテクチャに徐々に注目し、適用するようになりました。 51CTO企業アカデミーの招待を受け、WeBank技術協力サポート部門の設計者Liu Li氏が第11回「技術専門家対面」で「WeBank：分散型アーキテクチャの高可用性」と題する講演を行いました。これは読者のために特別にまとめられたものです。

[[392589]]

文章

WeBank の実践経験に基づいて、私たちのデザインのアイデアと実践を同僚と共有します。皆様とコミュニケーションをとり、金融テクノロジーの分野で共に進歩していきたいと考えております。

本日の共有内容は主に3つの側面に焦点を当てています。1つ目は、WeBank の分散アーキテクチャの設計アイデアです。 2 番目は、分散コア システムが分散アーキテクチャとどのように一致するかです。 3つ目は、分散アーキテクチャに基づいた運用・保守管理をどのように行うかです。さらに、WeBank の分散アーキテクチャとマイクロサービスの関係についても説明します。

01 分散アーキテクチャの設計アイデア

1.1 全体原則: アーキテクチャを通じてセキュリティと制御を実現し、基盤となる技術への依存を排除​​する

分散アーキテクチャを構築するための前提条件: WeBank は最初の民間インターネット銀行として比較的遅れてスタートし、歴史的な負担もそれほど大きくありませんでした。コンプライアンス上の制約により、承認された準備期間は6か月で、初期資本は30億でした。同社は包括的金融を位置づけていたため、全面的にコストを削減する必要がありました。

これらの前提条件を見ると、スタートアップ資本の規模から、IT構築を行う際にIOEを購入するだけの設備が本質的に整っていないことがわかります。インクルーシブファイナンスの位置づけは、ある意味ではコストコントロールやボトムコンポーネントの設定が基本的に決まっていることを意味します。このような状況に基づいて、私たちはデザインの観点から 3 つの異なる原則を定義しました。

まず、技術の普遍性を重視し、単一のメーカーに縛られないこと。

2番目はミニマリズムです。安定した成熟したテクノロジーを使用するように努め、全体的なパフォーマンス指標を達成するために技術的なパフォーマンスに依存しないでください。

3番目に、制御可能なものに頼ります。金融機関の IT 部門にとって、アーキテクチャの観点から制御できるのは、主に業務システムに関連するアーキテクチャ計画とプログラム コードです。独自開発ができないその他の部分については、技術的な共通化により解決します。

技術サポートを提供するメーカーには、ソリューションが可能な限りホワイトボックスであり、オープンソース コンポーネントを可能な限り使用することを期待しています。オープンソースコミュニティ自体にはある程度の汎用性があり、メーカー自体も比較的中核的な研究開発能力を持っています。明確にしておく必要があるもう 1 つの点は、分散アーキテクチャを完成させるために X86 を使用する予定の場合、基盤となるテクノロジとシステムが不安定であると想定する必要があるということです。この不安定性に運用や保守を通じてどのように対処し解決するかについても、事前に設計時に一定の計画を立てておく必要があります。

1.2 安全と制御のためのコア技術構築のコンセプト：XMLによる安全と制御の実現

以下では、セキュリティと制御を実現するために分散アーキテクチャをどのように設計し構築するかについて詳しく説明します。

ホスト: 通常、固定クラスターは数十から 100 台の X86 サーバーで構成されます。このように、単一のクラスターは分散アーキテクチャ内のユニットとして理解することもできます。このサーバー クラスターは、アプリケーション コンピューティング サービス、データベース サービス、およびストレージ サービスを提供します。通常、データセンターではこれをノードと呼びます。このユニット化されたノードは、内部的には DCN という名前が付けられます (後述)。

データベース: MySQL をベースにしたデータベース、または少なくとも MySQL と高い互換性を持つデータベースが必要です。このデータベースの特徴は、設計原理が「3 枚の画像の強力な同期」に準拠していることです (詳細は後述)。データはストレージに依存せず、ローカル ディスクに配置されます。自動障害監視および回復が実現されます。

その他のテクノロジー: 現在、基盤となるサポート全体は基本的に、Linux と KVM に代表されるオープンソース テクノロジーの組み合わせです。

1.2.1 データベースの選択:顧客ベースの分散型疎結合シングルマスター複数コピー強力同期アーキテクチャ

データベースの選択に関しては、Tencent TDSQL データベースを選択しました。実際には、すべての分散アーキテクチャの設計には、顧客ベースまたはビジネスの分割が必要であることがわかりました。

従来の銀行の IOE アーキテクチャでは、プログラムは基本的に 1 台または 2 台のホスト サーバーで実行され、データの一貫性は問題になりません。しかし、容量拡張が必要な​​場合、ハードウェアの交換やデータの移行が非常に複雑になり、アイドル状態やリスクが比較的高くなります。対照的に、多くのインターネット企業は、データベースの最適化中にデータベースとテーブルを分割します。完全に分散化されたアプローチでは、優れた柔軟性とスケーラビリティが実現されますが、データの一貫性を保証することは難しく、金融サービスのセキュリティと安定性の要件は一般的なインターネット サービスよりも高くなります。全体的に、これら 2 つのモデルにはそれぞれ利点があるため、両方の特性を組み合わせたアーキテクチャを設計できないかと考えています。

この考慮に基づいて、分散疎結合アーキテクチャを採用しました。まず、すべての分散ノードは、顧客グループとビジネスという 2 つの次元に従って分割されます。つまり、各データセンターの分散ノードは、一部の顧客グループのみをサポートし、特定の種類のビジネスのみをサポートします。次に、データベース レベルでは、データの最終的な一貫性を確保するために、1 つのマスター ノードと 2 つのスレーブ ノードの強力な同期構造を採用することを選択します。

これを行う利点は、コンピューティング ノードが顧客グループに応じて分割され、各ノードが顧客グループの一部のみをサポートするため、単一ノード障害の影響が効果的に軽減され、運用上のリスクを制御できることです。高いパフォーマンス要件を満たすために、ビジネス ロジックは複数のコンピューティング ノードに分散されます。データ層は、マスター 2 スレーブ アプローチを使用して、高いデータ冗長性を実現し、高可用性の要件を満たします。デフォルトでは、CAP 理論の制限を回避するために、マスター ノードのデータに焦点を当てます。

これによる悪影響としては、管理の複雑さを軽減し、運用と保守の効率を向上させるために、自動化された管理ツールをサポートする必要があることが挙げられます。効率的なデータ同期メカニズムを実現するためにデータベース技術を改善する必要性。

1.2.2 データセンターノードの分散ロジック: DCNアーキテクチャによる完全分散型銀行システムの構築

WeBank のデータセンター ノードの分散ロジックは、顧客ディメンションに応じて複数の DCN グループに分割されます。各 DCN グループは、一定容量の顧客のみをサポートします。顧客数が増えた場合は、DCN を複製して展開できます。 DCN のグループには、同じ都市の異なるデータ センターに 3 つ以上のコピーが存在します。

簡単に言えば、各 DCN は WeBank の支店のようなものです。たとえば、100 個のノードを分割することは、100 個の小さな支店を開設することと同じであり、これらの 100 個の小さな支店のいずれかに問題が発生しても、ビジネス全体や顧客ベースには影響しません。このように、すべてのビジネスと顧客グループを分散された小さなノードに分割することと同じです。各分散ノードの仕様、コンピューティング リソース、データベース定義も標準化されています。

1.2.3 実際のユースケース: WeBank の分散アーキテクチャの全体的な論理的ビュー

分散ノードに顧客を割り当てるにはどうすればよいでしょうか?当社には、顧客ベースの制御可能なディストリビューション全体の中核となる、GNS (Global Naming Service) と呼ばれる特別なコンポーネントがあります。このコンポーネントは、各ユーザーがログインすると自動的に GNS 番号を割り当てます。この GNS 番号には特定の書き込みルールがあり、新しいユーザーには分散ノードが割り当てられます。今後、新規ユーザーに関連する業務処理やデータ保存は基本的にこのノード上で固定されることになります。以降の業務処理では、GNS コードを参照することで、ユーザのノードをすぐに見つけることができます。各 DCN ノードの構成が固まれば、水平展開に非常に役立ちます。ユーザー規模の拡大に応じて、DCN ノードを追加するだけで、システムの処理能力を水平方向に無限に拡張できます。

1.2.4 Weizhong IDC 2.0 アーキテクチャ: 同じ都市に 6 つのセンターがあり、複数のアクティブ センターとリモート ディザスタ リカバリ センターがある

WeBank の IDC2.0 アーキテクチャにおける同一都市でのマルチアクティブの実装の現在の方法も、DCN ノードの設計と密接に関連しています。まず、グローバルな負荷分散メカニズムがあります。業務は外部ネットワークから入った後、データセンターに割り当てられます。ビジネスが接続されると、メッセージ チャネルを介して処理され、バックグラウンドでさまざまなビジネス アプリケーションにアクセスし、最終的にすべての書き込み操作がメイン データベースに送信されます。外部ネットワーク アクセスの問題、アプリケーションの問題、データベースの問題など、何らかの問題が発生した場合、IDC に障害が発生すると、バックアップ データベースがプライマリ データベースに切り替わり、データベースの読み取りと書き込みを引き継ぎます。各業務操作はメイン データベースに書き込んだ後に 2 つのコピーを書き込み、これら 2 つのコピーは異なるデータ センターに分散されるため、データベース切り替えメカニズムは非常に高速です。このステップが完了すると、次のビジネス プロセスを続行するためのフィードバックがユーザーに提供されます。

このことから、WeBank は実際には同じ都市内のマルチアクティブ メカニズムをデータベース自体の高可用性メカニズムに任せていることがわかります。このアプローチの利点は、基盤となるハードウェアの同期に依存せず、データベースのメカニズムのみを使用して実行し、一般的に RPO 0 を実現できることです。基本的に業務が中断されない状態を実現しますが、RPO は数秒以内に切り替わります。

1.2.5メッセージバスルーティングメカニズムを通じて、同一都市内で効率的かつ安定したマルチアクティブアーキテクチャを実現する

メッセージ バスのルーティング メカニズムを使用して、同じ都市で効率的で安定したマルチアクティブ アーキテクチャを実現するにはどうすればよいでしょうか。

まず、WeBank にはメッセージ バスに基づく分散アーキテクチャ データ バックボーンがあります。バスはシステム間の通信の分離を実現します。バス分離メカニズムとネットワーク分離により、法人間のメッセージフロー制御を実現できます。バスは、負荷分散、電流制限、ヒューズなどのサーバー側の保護メカニズムを提供し、大規模なトランザクションでもサービスの安定性を確保します。

第二に、トランザクションは可能な限りローカルで処理される必要があります。メッセージ ルーティングにより、データ センター内のサービスが優先され、データ センター間の呼び出しが削減され、トランザクションの待ち時間が短縮されます。

さらに、メッセージ キューには柔軟なルーティング アドレス指定機能が与えられます。メッセージ アドレス配置コンポーネントを使用して、システム間の呼び出し時にメッセージ アドレス指定機能を提供し、アプリケーション コード ロジックとサービス デプロイメント アドレスの結合を回避します。

最後に、メッセージ交換を厳密に制御します。法人間のメッセージ ルーティングをサポートしますが、サービス ガバナンスを通じてアクセス許可とポリシーを厳密に制御します。通信はデフォルトで無効になっており、不適切な呼び出しを回避するために、メッセージ ルーティングはオンデマンドで有効になります。

02分散コア設計共有

この部分の主な内容は、分散コアシステムが分散アーキテクチャとどのように組み合わされるかについてです。

2.1インターネットバンキングマイクロコアの分散特性

現在、WeBank のインターネット コア システム (預金およびローン コア、クレジットカード コアなど) はすべて WeBank 自身によって完全に開発されています。したがって、コアシステムを配布する際には、実際に分割しました。最初の分割は、コア機能を分散する必要があることです。 2 つ目は、ビジネス機能を分散する必要があることです。 3 つ目は、システム パフォーマンスも分散する必要があることです。

2.1.1マイクロコア – コア機能に基づいて分散

コアシステムとアカウントシステムを設計する際には、機能を分散できることを期待していたため、早い段階で一部のコアシステムの機能を分割しました。たとえば、預金コアの境界を口座コアと簿記の観点に絞り込みます。この上に、支払い、ポジション管理、不正防止などの統合トランザクション層が個別の機能として存在します。このように、製品を設計する際には、適切な機能を組み合わせるだけで済みます。言い換えれば、私たちはいくつかの一般的な機能をサービス指向およびプラットフォームベースの機能に変換するために最善を尽くしています。

ご覧のとおり、この設計アイデアはマイクロサービスのロジックと非常によく似ています。実際、サービスと配信の面では、WeBank はすでにマイクロサービス ロジックを使用してすべてのシステムとサブシステムを構築するところまで来ていますが、これらのシステム間の通信は現在、メッセージ キューを介して行われています。この時点で、機能ベースの分散が実現できたと言えます。

2.1.2マイクロコア – ビジネス機能のマルチコア分散

ビジネス特性に基づいた分散処理により、ビジネス展開への適応性も向上します。これは、多くのシステムが実際には要求に大きな違いを持っ​​ているためです。たとえば、オンライン バンキング アプリの一般的なシナリオでは、顧客ベースはあまり変化せず、同時ユーザー数も多くありませんが、製品全体を表示し、ユーザーにさらに多くのコンテンツを表示できることが求められます。しかし、WeChatゼロバランスウォレットなどのインターネットシナリオに接続すると、ユーザーにとっては単なる単一の入り口となり、他の製品形式やユーザー情報はユーザーにとって興味の対象ではなくなります。このプロセスの特徴は、トランザクションの頻度が非常に高いにもかかわらず、プロセス全体は非常にシンプルであることです。大規模なシナリオにおける要求は常に多様です。

その後、すべてを 1 つのコアに配置する必要はないことがわかりました。例えば、預金コアシステムの場合、このコアシステムの特定のバージョンが特定の業務に対応します。たとえば、デポジット コア 2.0 は一般的なデポジットに特化しており、バージョン 3.0 は高頻度取引のシナリオに対応し、バージョン 3.1 はピア間の協調デポジットに対応している可能性があります。異なるバージョンのコアは、異なるビジネス製品に対応します。このような観点から、事業特性に応じた配分を実現します。

私たちにとって、インターネットの核となる部分は、分解したり、反復したり、成長したり、消滅したりする可能性があります。

2.1.3マイクロコアベースの技術システムインターネットコア

パフォーマンスの分離については先ほども触れました。分離は DCN ノードを通じて行われ、水平方向と垂直方向の拡張を実現します。つまり、機能からビジネス機能、パフォーマンスへの分離を実現できます。そのため、WeBank の現在のアーキテクチャでは、当社製品は適切なマイクロコア コンポーネントを選択し、この製品のトランザクション ライブラリに対応してから製品を実行し、実行後にすべての情報を要約することができます。各製品に独自のトランザクション ライブラリが備わった後、このトランザクション ライブラリの最終的なデータ ツールは、業界レベルのビッグ データ プラットフォームに再度まとめられ、リアルタイム クエリ、データ統計などのニーズに対応します。

つまり、分散型コアシステムを構築しながら、最終的にはビッグデータプラットフォームを通じてデータを収集・集約し、銀行の視点からの管理を実現し、規制要件を満たすことが必要です。

2.2アプリケーションレベルの分散トランザクションの実装

マイクロサービスという概念が登場し、信頼できる成熟したフレームワークが存在しなかった以前は、トランザクションの一貫性を確保するために、アカウント層、つまり各インターネット コアでアプリケーション レベルの分散トランザクションを実装することを選択しました。

実装ロジックは次のとおりです。サービス イニシエーターは、開始されたサブトランザクションの状態の一貫性を保証します。サービスプロセッサは、異常な状況で呼び出し元が使用するための対応する例外処理インターフェイスを提供します。例外処理を同期するか、エラー登録テーブルを登録して早期警告をトリガーします。トランザクション処理フローでは、最初に業務チェックを行い、その後に業務処理を行うようにして、トランザクション異常の可能性を減らします。一貫性は、統合された分散トランザクション管理ミドルウェアまたはアプリケーション コードを通じて実現できます。

03 分散アーキテクチャ管理制御ツールシステム

最後に、分散アーキテクチャの管理および制御システムについて簡単に紹介します。

3.1分散アーキテクチャ管理と運用の開発パス

分散アーキテクチャでは、管理と運用に 4 つの大きな課題が生じます。まず、経験豊富な運用・保守エンジニアは高価であり、それでもミスをする可能性があります。第二に、アーキテクチャが大規模であることです。 WeBank は現在 12,000 台以上のサーバーを管理しており、さらに多くのアプリケーション ノードを保有しています。仮想マシンが含まれる場合は、さらに多くのものが存在する可能性があり、一部のコンテナの管理も含まれる可能性があります。 3 番目に、24 時間 365 日の中断のない運用には、事業継続性に関する厳しい要件があります。 4、分散型コアシステムは、銀行の顧客にサービスを提供するために90以上のコアシステムを同時に実行しており、バージョン構成管理、グレースケールリリースなどの作業負荷が大きい。これらの課題により、運用と保守の標準化、自動化、インテリジェンスに対する要件がさらに厳しくなりました。

3.2運用保守システムの構築を強化し、自動化とインテリジェント化による運用保守能力を強調する

当社には、非常に厳格な運用および保守ツール、システム、管理方法が備わっています。当時の私たちの最も重要な基準の 1 つは、運用と保守管理がアーキテクチャ設計に基づいて行われるようにする方法でした。これには、アーキテクチャ設計の最初から運用と保守のロジックを考慮する必要があり、アーキテクチャの設計時から最終的なシステムの起動時までの動作状態要件が可能な限り一貫している必要があります。さらに、従うべき 4 つの原則があります。

外部スキルをしっかり練習しましょう。運用と保守の効率を向上させ、人件費と人為的エラーの可能性を削減するために、運用と保守用の自動化ツールセットを構築します。

自分の内面の強さをしっかり鍛えましょう。アーキテクチャ設計からオンラインでの運用・保守まで、情報フローは設計状態から運用状態まで閉じられています。

情報の正確性を確保します。テクノロジープラットフォーム層（IaaS/PaaS）での情報管理だけでなく、システムやサービスの情報も含めたSaaS層の情報を統合し、設計から運用・保守までの一貫性を確保します。

情報の正確性を確保します。各データに対して明確な責任組織を定義し、データ検証メカニズムを確立し、情報の正確性を確保します。

当社は、運用保守システムの構築に加え、キャパシティ見積もりや生産異常の根本原因特定など、AIOps分野での業務も行っています。 WeBank は設立以来の運営・保守データをすべて保有しています。実際に、この運用および保守データを使用してモデルを構築し、異常を特定して根本原因分析を行うことができます。現在、多層AIアルゴリズムモデルの認識精度は90％以上に達し、根本原因の位置決め精度は70％に近づいており、どちらも手動操作とメンテナンスの負担を軽減するために使用できます。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]