テンセントの技術エンジニアが、QQフォトアルバムが18歳から現在までの写真を保存する仕組みを説明

少し前、中国本土のネットユーザーのWeChat MomentsやWeiboなどのソーシャルプラットフォームには、ビンテージ感あふれるさまざまな「18歳の写真」が溢れ、誰もが写真を投稿して青春時代を懐かしんでいた。興味深いのは、Momentsに投稿された写真のほとんどが、Renren Photo AlbumsとQQ Photo Albumsからのものであることです。多くの人から忘れ去られてしまったこれらのフォトアルバムサービスは、これまでどのようにして多くの乱雑な写真を安全に保存してきたのでしょうか。 Tencentの技術エンジニアxianmauがTencent Cloudコミュニティに記事を投稿し、技術的な内部情報を解説しました。

「QQフォトアルバムバックエンドストレージアーキテクチャの再構築とIDC間災害復旧の実践」

序文

大手企業として、QQ Photo Album のチームは安定した運営と効果的な災害復旧を常に追求してきました。 QQフォトアルバムのアーキテクチャは進化しています。この記事では、フォトアルバムアーキテクチャの再構築の詳細に焦点を当てます。再構築では、大規模なストレージの再配置と機能モジュールの統合が行われ、イメージアップロードの「2段階」プロセスが抽象化され、これに基づいて軽量の災害復旧ソリューションが設計されました。新しいアーキテクチャにより、多数のモジュールが合理化され、画像アップロードプロセスが最適化され、運用と保守の作業が削減されました。実際の運用結果から、4 9s のサービス品質を安定的に実現し、IDC をまたいだ災害からの復旧能力も備えています。

プロジェクトの背景

QQ フォトアルバムは、以前からインデックス オフサイト ディザスタ リカバリを開始しています。当時、災害復旧の設計と実装は、人的資源と設備資源、そして保守的なアップグレード戦略によって制限されていました。オリジナルのフォトアルバムのアーキテクチャとビジネスプロセスに基づいて、非常に軽量な設計を作成しました。過去 1 年間の実際の運用から判断すると、さまざまな変動や障害において一定の役割を果たしましたが、災害復旧シナリオが限られていること、アルバムのサイズが大きいこと、およびストレージとインデックスが多数のコンピューター ルームに分散していることから、ビジネスでは、わずかなネットワーク変動に対して依然として高い注意を払っています。 QQ フォト アルバム アクセス アーキテクチャが構築されてから 10 年が経ち、フォト アルバムのアップロードの成功率と全体的なサービス品質に対する要求はますます高まっています。ただし、アルバム ロジックの複雑さにより、元のアーキテクチャは、災害復旧、運用、保守の面で使いにくいものになっています (特に初心者の場合)。今年はシステムをリファクタリングしました！この記事では、この再構築の設計と実装の概要を示し、新しいアーキテクチャの下でのフォトアルバムの災害復旧の詳細と演習結果を示し、最後にプロジェクトの実装プロセス中のいくつかの考えをまとめます。

リファクタリングターゲット

ビジネスの観点から、このプロジェクトの実装は、QQ フォト アルバムのアップロードの成功率を向上させ、さまざまな小さなネットワークの変動や障害をほとんどまたはまったく感じさせないようにすること (アップロードの成功率は、分単位で安定して 3 ナインに達し、1 日を通して 4 ナインに達する)、およびコンピューター ルームの障害や大規模な災害が発生した場合でも、さまざまな場所で迅速に復旧および復元できることを目指しています。フォトアルバムプラットフォームには、主に以下の目標があります。

1. モジュールのマージ
2. 簡素化されたアーキテクチャ
3. アップロードプロセスを最適化する
4. 災害復旧ロジックの最適化

解決

全体的な構造調整

1. オリジナルアルバムの構成

QQ フォトアルバムは、外部の世界への豊富なインターフェースを提供します。現在のストレージ容量は300PBを超えています。ユーザー インデックス ストレージは場所ごとに分散されており、その容量も数百 TB に達します。現在のフォトアルバムプラットフォームは、このような大規模なビジネスを比較的安定してサポートしていますが、システムアーキテクチャには多くのモジュールと複雑なデータフローがあり、開発、運用、保守に多くの問題が生じています。オリジナルのアルバム構造を図 1 に示します。

図1: オリジナルのQQフォトアルバムアップロードアーキテクチャ

ユーザーは、アプリまたは PC クライアントを使用して、リストのアップロード、変更、削除、プルなどの QQ アルバム操作を実行します。これらのリクエストは preupload モジュールによって完了され、zz モジュールは写真の回転と再印刷を担当し、recycle モジュールはアルバムのごみ箱の操作を担当します。ここでは、図 2 に示すように、各コア モジュールの機能とデータ フローを説明するために、最も重要なアップロード操作を例に挙げます。アルバム データは膨大で、インデックスは複数のパークに分散されています。単一ユーザーのすべてのインデックス情報は同じパークに含まれます。ユーザー インデックスの場所は、ルーティング モジュールを通じて照会できます。

図2: オリジナルユーザーアップロードフローチャート

2. アーキテクチャのリファクタリング

かつては、建築の調整のほとんどは「解体」によって行われていました。しかし、業務データ量の増加や業務ニーズの変化の緩和に伴い、システムの安定性と高可用性にさらに重点を置くようになりました。そこで、今回の再構築では「統合」という考え方を採用し、zzとrececyleをpreupoadに統合しました。機能が結合されてpreuploadが肥大化しているようです。ただし、zz と recycle の機能ロジックから見ると、これらは preupload と同じか非常に似ており、基礎となるストレージも共有されます。これらは独立して展開されます。時間が経つにつれて、3 つのモジュールのコード ロジックの違いが大きくなり、開発、保守、運用が困難になります。新しいアーキテクチャでは、ckv システムや原画像システムなどの不要なモジュールも削除され、原画像機能がより高い伝送速度でマイクロクラウド システムに完全に接続されます。災害復旧モジュールも、相互バックアップでペアになる 3 つの場所に配備されていたものから、単一のパークに配備されるものに変更されました。再構成図は図3に示されています。

図3: 新しいQQフォトアルバムアップロードアーキテクチャ

アルバム ユーザーは独自の場所を持っているため、ローカル アップロード要求の半分以上でリモート同期インデックス作成が必要になる可能性があります。元のアーキテクチャでは、アップロード プロセスでこのロジックを判断して個別に処理する必要があり、すでに複雑なアップロード ロジックがさらに理解しにくくなり、災害復旧にも大きな問題が生じます。再構築中は、この状況が考慮され、アップロード プロセスはデータ ランディングとインデックス ランディングの 2 つの段階に抽象化されました。このようにして、アップロード プロセスは次のように簡素化されます。最も近いプレアップロードがアップロード要求を受信すると、まずイメージ データを圧縮し、次にインデックス情報をインデックス プレアップロードに送信してインデックスを作成します (図 4 を参照)。

図4: 新規ユーザーアップロードフローチャート

災害復旧プロセスの調整

1. 災害復旧用にオリジナルの写真アルバムをアップロードする

一般的な災害復旧プロセスを図 5 に示します。

図5: オリジナルのQQフォトアルバムアップロード災害復旧プロセス

2. 災害復旧プロセスの最適化

新しいアーキテクチャでは、データ ランディングとインデックス ランディングが独立して扱われ、災害復旧プロセスをさらに簡素化できます。まず、アップロード要求プロトコルの予約フラグを使用して、通常の要求を災害復旧要求に巧みに変換し、災害復旧構成項目を通じてモジュールの災害復旧レベルを事前に設定しておきます。システムは、リクエストの種類 (災害復旧リクエストであるかどうか)、構成項目、および動的統計情報に基づいて、対応する災害復旧戦略を実装します。災害復旧のデータフローを図 6 に示します。

図6: 新しいQQフォトアルバムアップロードの災害復旧プロセス

3. 災害復旧戦略

新しい災害復旧プロセスと災害復旧戦略は比較的単純で、次のように要約できます。

1. インデックスの事前アップロードの可用性とタイムアウト率に基づいて、アップロード要求を災害復旧アップロード要求（災害復旧要求または災害復旧再試行）に変換するかどうかを決定します。
2. アップロード事前アップロードの可用性とタイムアウト率に基づいて、近くのアップロード事前アップロードを要求するか、リモートアップロード事前アップロードを要求するかを決定します（リモートの場所から要求するか、リモートの場所から再試行するか）

以下では、さまざまな観点から具体的な戦略の実装について説明します。

ビジネスの視点

企業は、要求に基づいて災害復旧を実行します。

1. プロキシが利用できないため、ビジネスはリクエストを利用可能なプロキシにリダイレクトします。
2. プロキシのタイムアウト。タイムアウト率が 10% 未満の場合、リクエストは 1 回再試行できます。タイムアウト率が10%を超える場合、容量に応じてリクエストはリモートプロキシにリダイレクトされます（タイムアウト率のしきい値は実際の操作に応じて調整されます）
3. プロキシが過負荷状態のため再試行できません。要求は容量に応じてリモート プロキシにリダイレクトされます。
4. プロキシはエラーを返します。再試行はお勧めしません。

プロキシの視点

1. 大規模な障害が発生すると、モジュール全体が使用できなくなり、直接のリモート要求またはインデックスの災害復旧が必要になります。リクエストが失敗した場合、再試行は実行されません。

表1: 大規模障害復旧の構成と動作

2. 一般的な障害や軽微な変動については、最も近い事前アップロードを直接リクエストしてください。リクエストが失敗した場合は、タイムアウト率とエラー コードに基づいて、対応する再試行措置を講じます。

表2: 大規模障害復旧の構成と動作

アップロード前の視点をアップロードする

アップロードの preupload はプロキシからのリクエストを受信すると、まず画像データをアップロードします。災害復旧アップロードの場合は、災害復旧インデックスを生成し、synsrv に送信する必要があります。通常のアップロードでは、通常のインデックスを生成し、それをインデックスの事前アップロードに送信してから、再試行せずに synsrv バックアップ インデックスを書き込みます。

インデックスの事前アップロードの観点

インデックスの事前アップロードは、事前アップロードのアップロード要求を受け取り、プライマリ インデックスとセカンダリ インデックスを書き込みますが、再試行は実行しません。

synsrv の視点

1. バックアップ要求を受信すると、システムは成功メッセージで直接応答し、バックアップ インデックスを書き込みます。
2. 災害復旧要求を受信すると、まずバックアップ インデックスが書き込まれ、災害復旧インデックスが保存され、ビットマップがマークされます。すべてのステップが正常に完了した後にのみ成功が返されます。
3. 災害復旧インデックスがあるかどうかを定期的に確認してください。そうであれば、アップロード前のインデックス ポイントに同期し直します。

4. タイムアウト設定について

再試行は、災害復旧において重要かつ必要な手段です。しかし、シンプルに見えて、実際に使いこなすのは簡単ではありません。特に、再試行するとトラフィックが増加します。失敗率が非常に高い場合、再試行が多すぎるとマシンが過負荷になったり、バックエンド サービスがクラッシュしたりする可能性があります。さらに、複数ステップのプロセス タスクの場合、どのステップを再試行するかを決定し、各ステップのタイムアウトを設定するのは困難です。

すべてのモジュールの過負荷保護機能を考慮し、再試行メカニズムを簡素化しました。設定されたタイムアウト レートの範囲内では、プロキシ レベルでローカル再試行またはリモート再試行が 1 回のみ実行されます。図 7 は、最長リンクを使用する各プロセスのタイムアウト設定を示しています。経験上、ビジネスのアップロード タイムアウトは 120 秒、プロキシ ローカル要求タイムアウトは 60 秒、ローカル再試行タイムアウトは 60 秒、リモート要求タイムアウトは 60 秒です。タイムアウト期間は実際の操作後に調整され、最適化される場合があります。

図7: アップロードインターフェースの各プロセスのタイムアウト設定

重要な成果

このプロジェクトはしばらく前から稼働しており、実際の運用結果から判断すると、設定された目標をかなり達成していると言えます。

1. モジュールの簡素化。アルバムが再構築された後、3か所に原画を転送するためのrawupload、2か所に原画を着陸させるためのrawupload、4つの公園に再印刷するためのpreupload、リサイクルビンのためのpreuploadなどのモジュールが棚から直接削除されました。もともと複数のパークに配備されていた災害復旧システムモジュールが深センパークに統合されました。業務モジュールの数が37から18に削減され、保守・運用作業が大幅に簡素化されました。

2. 成功率が向上します。アップロード プロセスと再試行戦略が最適化され、最も頻度の高い上位 10 個のエラー コードのトラブルシューティングに重点が置かれました。アップロード成功率は、1 日あたり平均 3 ナインから、1 分あたり 3 ナイン、1 日あたり 4 ナインという安定した平均に向上しました。図 8 は再構築の最適化前のアップロード成功率の統計を示し、図 9 は再構築の最適化後のアップロード成功率を示しています。

図8: 再構築前のアップロード成功率

図9: 再構築後のアップロード成功率

3. 災害復旧機能の向上。新しい災害復旧戦略は、慎重に分類されたエラー コードの分類に基づいており、正確なリモート災害復旧を実現できます。災害復旧機能が開始されて以来、障害の小さな変動でも適時にリモート災害復旧をトリガーできるようになり、成功率がより完全に保証されるようになりました。しかし、開始以来大きな障害は発生していないため、ライブネットワーク障害訓練も実施しました。訓練の結果、新しい災害復旧ロジックは大規模な障害への対処にも優れた性能を発揮することが示されました。表 3 と表 4 は、それぞれ災害復旧レベル 2 とレベル 3 構成での演習データです。

表3: 災害復旧レベル2構成での小規模災害復旧訓練の成功率

表4: 災害復旧レベル3構成での小規模災害復旧訓練の成功率

***で書かれた

アルバムアップロード再構築プロジェクトはしばらく前から実行されていました。実際の運用結果から判断すると、システムメンテナンス、運用保守、実際のアップロード成功率、ビジネスクレーム量などで良好な最適化効果を達成しています。アーキテクチャ設計における「分離と統合」は科学です。フォトアルバムはデータとインデックスを別々に保存し、インデックスはプライマリインデックスとセカンダリインデックスに分かれています。重要なものと重要でないものを分けることで、保管効率が向上します。新しいアーキテクチャでは、アップロード プロセスが抽象化され、データ ランディングとインデックス ランディングが論理的かつモジュール的に分離されるため、理解しやすくなり、フォールト トレランスの設計が容易になります。論理的な重複度が高いモジュールをマージすると、システムの保守と運用が容易になります。建築設計においては、永遠の再会や永遠の分離はなく、オンライン要件の変化とプロセスの変化だけがあるのです。アーキテクチャが新しいシナリオに適応できなくなった場合は、再構築して調整する必要があります。