将来を見据えて、西安の統一健康コードシステムの崩壊をどう防ぐことができるでしょうか?

[51CTO.comより]西安のワンコードパスシステムは、1ヶ月足らずで2度もクラッシュしました。実際のプロジェクトやオンライン運用においてシステムクラッシュは起こり得ますが、これほど大規模なクラッシュ、特に短期間に2度もクラッシュが発生することは極めて稀です。では、将来を見据えて、クラッシュの可能性を低減するために、ワンコードパスシステムをどのように設計すべきでしょうか？以下では、ワンコードパスシステムの設計について、技術面とビジネス面の両方の観点から考察します。

I. 墜落原因の分析

2つのクラッシュはQRコードのスキャンと表示機能にのみ影響していたため、これら2つのモジュールのビジネスロジックを分析します。QRコードのスキャンと表示機能は似ており、どちらもクエリを多用する典型的な操作であり、トラフィックの大部分はクエリから発生しています。それでは、異なるバージョン間での統合QRコードシステムの開発状況を見てみましょう。

統合IDシステムの最初のバージョンでは、個人のID番号、氏名、IDコードの色のみが表示されていました。これら3つのフィールドは単一のテーブルに保存され、単一のSQLクエリで取得できる可能性があります。しかし、数万人が利用するシステムでは、すべてのデータを単一のテーブルに保存することは不可能です。そのため、ID番号と氏名は1つのテーブルに保存され、IDコードの色は別のテーブルに保存されている可能性が非常に高くなります。したがって、少なくとも1つの結合操作が存在する可能性が高くなります。

OneCodePlatform の第2バージョンと第3バージョンでは、大幅な変更が行われました。まず、ワクチン接種情報が追加され、次に、検査日と結果を表示する核酸検査情報が追加されました。これにより、クエリが2つ追加されます。OneCodePlatform がキャッシュの使用を考慮せず、リレーショナルデータベースのみに依存している場合、少なくとも2つのSQLクエリが追加される可能性があります。

上記は、QRコード読み取り・表示モジュールの事業運営の概要です。この事業は、ピーク時には数百万件もの同時接続を処理する必要があり（西安の人口は1000万人を超えます）、これはインターネット企業によくあることです。では、なぜ事業は破綻したのでしょうか？公式発表には、以下の2つの段落が含まれていました（主要部分のみ抜粋）。

1. 西安の統一健康コードシステムにアクセスするユーザー数が急増し、1秒あたりのアクセス数が以前のピーク時の10倍以上に達し、ネットワークの混雑を引き起こした。

2. 問題がネットワークインターフェイス側で発生していることを確認します。

これはネットワークの問題を示しています。通常、ユーザーのリクエストはまずドメイン名にアクセスし、次にDNSサーバーを経由してIPアドレスに解決し、IPアドレスを経由してサーバーにアクセスし、最後にサーバーがクライアントに応答を返します。今回のケースでは、IPアドレスへのアクセス段階で障害が発生しました。ネットワークの混雑状況によっては、帯域幅を増やすことで解決できたかもしれませんが、システムが復旧した際に、西安のユーザーはシステムが初期バージョンに戻り、ホームページに核酸検査の問い合わせページへのリンクが追加されていることに気づきました。したがって、今回のクラッシュは帯域幅の問題だけでなく、外部からのリクエスト数がシステムの最大処理能力を超えたことが原因であると考えられます。

通常、この問題の原因はシステムアーキテクチャの問題に過ぎず、解決にはスケールアップとレート制限の 2 つの方法があります。

1. リクエスト負荷がピークに達したら、後続のリクエストをすべて待機状態にすることで、レート制限を実施します。レート制限のソリューションは数多くありますが、最もシンプルなのはNginxを使用することです。効果が理想的でない場合は、アクセス層でレート制限を行うカスタムアルゴリズムを使用することもできます。レート制限では問題を完全に解決することはできず、一部のリクエストをブロックするだけです。

2. サーバーやデータベースを追加してシステムのキャパシティを増やすことはスケーリングに該当します。Yimatong社は問題発生後にロールバックはしたものの、スケールアップは行わなかったことから、システムアーキテクチャの設計においてスケーリングが考慮されていなかった可能性が高いと考えられます。したがって、システムアーキテクチャを考慮すると、スケーリングは困難な解決策となる可能性があります。

II. 崩壊への解決策

前のセクションの問題を解決するには、3 つの側面からアプローチできます。

1. 読み書き分離を採用する

統合ヘルスコードサービスは、アクセス頻度に基づいて、頻繁に使用されるモジュールと使用頻度の低いモジュールに分割されています。トラフィック量が多い使用頻度の高いモジュールは、「読み取り」操作が個別に処理されます。データベースフロントエンドにキャッシュミドルウェアを追加することで、キャッシュからの情報の読み取りを優先します。これにより、データベースがクラッシュした場合でも、業務システムはキャッシュからデータを取得できます。核酸検査やワクチン接種情報の更新など、使用頻度の低いモジュールはトラフィック量が少なく、データベースに対して直接操作されます。

2. データベースのシャーディング、テーブルのパーティショニング、サービスの分割

ユーザーIDのモジュロ値に基づいて、分割する必要があるデータベースまたはテーブルの数が決定されます。各データベースまたはテーブルは、1つ以上のサービスサブシステムに対応します。このインターフェースはトラフィックを複数のサービスサブシステムに分散することで、単一のデータベースまたはテーブルとサービスシステムへの負荷を軽減し、トラフィックの急増時に迅速なスケーリングを可能にします。

3. 災害復旧バックアップ

複数の場所にある複数のデータセンターにサービスを展開し、事前に災害復旧バックアップ計画を準備しておくことで、前述の問題を回避できます。

要約

Xi'an One-Code-Passシステムは、厳密なシステムテストを実施せずに本番環境に導入されたため、高並列処理時にクラッシュが発生しました。この記事で説明する問題は現状の分析に基づいており、提案されている解決策は比較的一般的なものです。しかし、これらの解決策によってXi'an One-Code-Passのクラッシュ問題はほぼ完全に解決できます。

著者紹介

朱剛氏は51CTOコミュニティエディターであり、2019年のCSDNブログ専門家トップ20の一人であり、2020年のTencent Cloud+コミュニティの優れた執筆者でもあります。10年間の最前線開発経験を持ち、人材紹介サービスウェブサイトのアーキテクチャ設計、企業向けインテリジェントカスタマーサービス、大規模電子政府システムの開発に携わってきました。大手中央企業の内部漏洩防止および電子文書セキュリティ監視システムの構築を主導し、現在は大手BIM企業で入札ソフトウェアの開発に従事しています。

[これは51CTOからのオリジナル記事です。提携サイトへの転載の際は、原著者と出典を51CTO.comと明記してください。]

DUICUO