QQは会員活動運営プラットフォームをどのように構築しているのでしょうか?

QQ会員活動運営プラットフォーム（AMS）は、QQ会員付加価値運営業務の重要な担い手の一つであり、大規模な活動運営を担うウェブシステムです。過去 4 年間で、AMS の 1 日あたりのリクエスト数は 200 万～500 万から 3 億～5 億に増加し、CGI の 1 日あたりのリクエスト数は最高で 8 億に達しました。このプロセスの間、AMS はアーキテクチャの大幅な調整と変更を経て、非常に記憶に残る技術的な旅を経験しました。

本稿では、QQ会員活動運営プラットフォームのアーキテクチャ設計実践を共有し、技術系の学生の皆さんのお役に立てれば幸いです。

1. 大規模事業運営の課題と当社のソリューション

製品ビジネスの発展は、常に「運営」という言葉と切り離せないものであり、さまざまな運営形態が活動ニーズに反映されます。製品ビジネスが運営指向であるほど、活動運営の発展ニーズも通常より多く発生します。

「アクティビティ」について話すとき、多くの人の最初の反応は、これはそれほど技術的な難しさを必要としないものだということです。一般的に、1～2 個のアクティビティだけであれば、技術的な困難さはそれほどありません。しかし、規模が 1,000 個以上に増えると、技術的な問題が生じます。

1. イベント運営事業における課題と問題点

（１）テンセントのSNG付加価値サービスは、大規模な活動の運営と開発において課題に直面している

テンセントの付加価値製品部門は、新規ユーザーの獲得、活性化、維持を促進するために、QQ会員システム、ゲーム運営、パーソナライゼーションなど、さまざまな業務において継続的に高強度の運用活動を行う必要があり、それ自体が多くの運用ニーズを生み出しています。さらに、2014年以降、モバイルインターネットが成熟段階に入ったため、QQプラットフォームでのモバイルゲーム運営の需要が爆発的に増加し、1か月間にオンラインで立ち上げる必要のあるアクティビティの数は数倍に増加しました。

（２）活動展開の複雑さ

キャンペーンの開発自体には、ある程度の作業が必要です。特に大規模なプロモーション活動の場合、機能とパフォーマンスに対する要件が高くなります。典型的な大規模イベントでは、通常、数千万人のユーザーが参加するため、パフォーマンス要件は比較的高くなります。「フラッシュセール」や「ラッシュ購入」などの高並列機能が関係する場合、基本的なサポートシステムにとって大きな課題となります。

このイベントには、ギフト パッケージ、抽選、共有、招待、引き換え、ランキング、支払いなど、多くの機能があります。これらのさまざまな参加および表現形式には、より多くのバックエンド インターフェイス通信と共同デバッグも含まれます。例えば、当社のゲーム運営事業には数百のゲームが含まれており、ゲームごとに異なるサービスインターフェースが対応しています。ゲーム関連の通信インターフェースは数千に及びます。

もう一つの非常に重要な問題は、イベント運営の安全性と信頼性です。これは、当社の活動のほとんどが、 iPhone 、iPad、その他の高額ギフトパッケージなど、非常に高いセキュリティ要件が求められる重要な物理的な賞品の配布を伴うためです。

（３）イベント運営・開発における人材問題

従来の手動開発モデルでは、通常のアクティビティでも 1 週間の開発サイクルが必要であり、典型的な大規模なアクティビティでは 1 ～ 2 週間の開発サイクルが必要であり、開発とテストの作業負荷が重くなります。さらに、多くのアクティビティは指定された休日に宣伝されており、通常は厳しいオンライン時間要件があります。緊急かつ急速に増大する運用ニーズに直面して、人員は非常に限られています。

現在、年間を通じて4,300以上のアクティビティがオンラインで実施されています。

2. 活動の性質と方法論

さまざまな業務のアクティビティ パターンを分析および抽象化することで、ほとんどのアクティビティを「条件」と「アクション」のセットの形式で抽象化してカプセル化できることがわかりました。これにより、共通の「条件」(ルール) と「アクション」(操作) アクティビティ コンポーネントが形成されます。さまざまな条件とアクションの組み合わせが、アクティビティ ロジックの実装になります。次に、プラットフォームベースおよびフレームワーク主導の開発を通じてこれらのコンポーネントを統合したいと考えています。同時に、フレームワークおよびプラットフォームレベルでは、アクティブコンポーネントの動作に対して、高い信頼性、高性能、過負荷保護、水平拡張機能を備えたフレームワークサポート環境が提供されます。

アクティビティ コンポーネントは独自のビジネス ロジックをカプセル化するだけでよく、コア機能フレームワークが自動的にそれをサポートするため、アクティビティの操作と開発の完全な自動化が実現します。

AMS が取り組むべき課題は、この計画を実現することです。対処する必要がある主な問題は 3 つあります。

（１）効率的な業務開発モデルの構築（業務開発自動化）

（２）高信頼性・高可用性を備えた運用支援プラットフォームを構築する。

（３）イベント運営の安全を確保する。

2. 効率的な活動運営・開発モデルの構築

2012 年初頭、AMS が登場する前は、アクティビティ開発モデルは比較的カジュアルで、厳密かつ完全なフレームワークのサポートはなく、コンポーネントの再利用度も十分に高くありませんでした。そのため、アクティビティの開発には 1 週間以上かかることがよくあります。当時の開発活動の特徴の 1 つは、「それぞれが自分のことをする」ということでした。各運用・開発学生は、フロントエンドとバックエンドのコンポーネントを一括して制作し、CGI レイヤーもルールの異なる多くのエントリを生成しました。これらのコンポーネントの構造は乱雑で、体系化されておらず、保守が困難です。最も重要なのは、このようなコンポーネントは使用が複雑で、アクティビティ開発での再利用率が低いため、開発効率が比較的低くなることです。

当時はイベント運営の需要がある程度蓄積されており、人手が足りない需要も多く、プロダクト担当の同僚からもイベントの立ち上げが遅いと感じられていました。

1. システムアーキテクチャの階層化と統合

この問題に基づいて、私たちが最初に考えた解決策は、フロントエンドとバックエンドのコンポーネントを統合し、明確で統一されたシステムを再構築することでした。システムのインターフェースの階層化、再利用、簡素化の原則に基づいて、完全なシステムが徐々に構築されます。さらに、私たちの開発の観点からは、アクティビティ開発の作業負荷を軽減し、開発者を解放し、研究開発の効率を向上させることが最も重要な目標です。

当社のフロントエンド コンポーネントは、Zero と呼ばれるフレームワークを通じて統合されています。各フロントエンド機能はコンポーネントの形で表示され、統一された方法で保守および再利用されます。 CGI レイヤーはコードの再構築が行われ、フレームワーク駆動型開発が実装され、各ビジネス ロジック機能が単一の入り口と統一されたシステムに統合されました。コア機能フレームワークは自動的にサポートされ、既存のアクティブな機能コンポーネントを直接構成して使用できます。新しい機能が追加されない場合、運用開発では、コードを記述せずにバックエンドの機能ロジックを完了するために、単純なパラメータ セットを構成するだけで済みます。基本的なサポート サービスは、プラットフォーム ベースで管理され、アクセスとメンテナンスが統一されています。

システム構造の調整が完了した後、アクティビティ構成を通じてフロントエンドコンポーネントとバックエンドコンポーネントの組み合わせを制御できることにようやく気付きました。各条件、出荷、その他のアクションは、自由に動的に組み合わせることができます。参加条件は、「and」、「or」、「not」などを介して組み合わせることができ、対応するアクションを選択してアクティビティ機能ロジックを実現します。

それ以来、アクティビティの開発ははるかにシンプルになり、記述する必要があるコードの量は大幅に削減され、基本的に「パラメータを埋める」という作業になりました。アクティブなプロジェクトのコードは、1,000 ～ 2,000 行から 100 行未満に削減されました。

例えば、下の図に示すように、当初は大量のロジックコードを記述する必要があったギフトパッケージは、フロントエンドでは 1 行のパラメータだけになりました。

明確な構造によりシステムの保守性が向上し、さらに重要なことに、アクティビティ開発の効率も大幅に向上します。

開発人員は従来通りですが、イベント開発の効率が大幅に向上し、製品需要の滞留も効果的に緩和されました。

2. 視覚的にわかりやすい開発モード（自動操作）

しかし、2014年、「モバイルインターネット」の急速な発展と徐々に成熟するにつれて、「モバイルゲーム爆発」の時代も到来しました。モバイルゲームの開発サイクルが速いため、ほぼ毎月多くの新しいモバイルゲームがリリースされ、すぐにモバイルゲームイベント運営の需要が爆発的に増加しました。 AMS が行う活動の需要は、月間 60 件以上から 200 件に急増しました。このような背景から、開発人員は再び手薄になり、需要の滞留はさらに悪化しました。

人材育成の話なので、現在の活動プロジェクトモデルを紹介しなければなりません。テンセントは成熟したインターネット企業です。R&D プロセスの各リンク (設計、再構築、開発、体験/テスト、リリース) は、それぞれ異なる独立した役割によって完了します。通常のモバイルイベントプロジェクトに必要な時間は、最も速く理想的なモードに従って計算されます：設計に1日、再構築に1日、開発に2日、体験/テストに1日。少なくとも5営業日かかり、R＆Dサイクルは少なくとも1週間になります。理想は美しいが、現実は常に残酷だ。実際のプロジェクト実施プロセスでは、さまざまなリソースの調整や外部要因により、このような完璧な調整を達成することは通常不可能であるため、通常の活動のR＆Dサイクルは1週間を超えることがよくあります。

突然 100 を超える新しい要件が追加されると、どのチームにとっても大きなプレッシャーになります。

そのため、イベント運営を考える上で別の考え方を取り入れる必要があります。開発人材に投資しないようにすることはできないでしょうか。私たちはこれを「自動運用」と呼んでいます。自動化の本質は、運用スタッフが自らアクティビティの開発を完了できるように、十分に強力なプラットフォームとツールサポートを構築することです。

先ほど、通常のアクティビティを開発する場合、各機能ポイントは単純な構成になっており、アクティビティ開発の作業はこの構成のアクティビティパラメータをページボタンに入力することであると述べました。ビジュアルツールを実装し、設定を入力する作業をボタンをドラッグする機能に変えれば、「コードを書く」という作業と完全にお別れできます。

最終的な結果として、視覚的なドラッグ アンド ドロップ アクティブ テンプレート システムが作成されました。運用スタッフは、使用方法を学ぶために適切なトレーニングを受けるだけで済みます。まず、運用チームがアクティビティ設計図をアップロードし、テンプレートシステムが自動的に図面を切り取ります（再構築作業が完了します）。次に、ボタン機能コンポーネント（基本的にはdiv透明マスク）をドラッグして、アクティビティ機能を設定し、ページに挿入します。次に、「エクスペリエンスとリリース」をクリックして、アクティビティの起動を完了します。当社の機能コンポーネントは運用スタッフに提供される前に厳密にテストされているため、通常、技術テスト スタッフによるテストは必要ありません。

なぜなら、それ以降、運用部門の同僚が開発、再構築、テストの作業を大規模に代替するようになったからです。しかし、彼らは技術的な詳細を理解していない人々の集団であり、活動を開始するリスクも目に見えない形で増大していました。そのため、このアクティビティ テンプレートの実装に加えて、AMS プラットフォームの特性に基づいた一連のサポート プラットフォームとツールも構築しました。

つまり、「ヒューマンエラー」を回避するためには、ヒューマンエラーは人間自身によって回避することはできず、プラットフォームやプログラムによって保証され、検出される必要があるのです。そのため、私たちは構成チェックとアクティビティ データ監視の強力でインテリジェントなシステムを構築しました。たとえば、リソース プールにギフト券が 100 枚ありますが、運用スタッフが誤って 200 枚に設定してしまったとします。このとき、プラットフォームは設定が間違っていることを検出し、運用スタッフに通知します。

自動化された操作により、R&Dプロセスレベルでの最適化が実現しました。アクティビティR&Dプロセスでは、再構築、開発、テストのプロセスが削減され、アクティビティプロジェクトのR&Dサイクルが大幅に短縮され、アクティビティプロジェクトのR&D効率が飛躍的に向上しました。モバイルゲーム運営ニーズのバックログ問題が根本的に徹底的に解決されました。

効率的なイベント展開モデルの完成により、AMSプラットフォーム事業規模も急成長を遂げています。 2015 年 10 月には、毎月 400 件を超えるアクティビティ プロジェクトが開始され、そのうち 80% 以上は、運用部門の同僚が「開発した」テンプレート アクティビティでした。

3. 信頼性とパフォーマンスをサポートする構造

効率的なイベント開発モデルを構築することで、過去3年間でAMS運用プラットフォームのビジネス規模とトラフィック規模が100倍に拡大し、1,000件以上のイベントが同時にオンラインになりました。同時に、AMS プラットフォームの信頼性と安定性も最も重要な指標の 1 つになっています。プラットフォームに問題が発生した場合、影響は非常に広範囲に及びます。

AMS プラットフォームのアーキテクチャは、エントリ レベル、ビジネス ロジック レベル、サービス レベル、ストレージ レベル (CKV の NoSQL ストレージ)、オフライン サービスおよび監視システムの 4 つのレベルに分かれています。

1. 信頼性

イベント運営事業は、多くの高額ギフトパッケージの配布を伴い、その中には決済リンクも含まれるため、プラットフォームの信頼性に非常に敏感です。安定性が最も重要です。

可用性を確保するために、次のことを行います。

• すべてのサービスとストレージ、ステートレス ルーティング (L5)。これを行う主な目的は、単一ポイントのリスクを回避すること、つまり、サービス ノードに障害が発生した場合にサービス全体が麻痺するのを防ぐことです。実際、マスタースレーブ特性（メインマシンに障害が発生した場合、バックアップマシンへの切り替えをサポートする）を備えた一部のアクセスサービスでさえ、信頼性が十分ではありません。結局のところ、マシンは 2 台しかないため、両方に障害が発生する可能性は依然としてあります。当社のバックエンド サービスは通常、マシンのグループの形式で提供され、マシン間に状態関係はなく、リクエストのランダムな割り当てをサポートします。
• 並列拡張をサポートします。トラフィックが多い場合は、マシンを追加することで容量を拡張できます。
• 異常な機械を自動的に除去します。当社のルーティング サービスでは、サービス マシンに異常が見つかった場合、自動的に削除され、回復後に再度追加されます。
• アラームを監視します。成功率はリアルタイムでカウントされ、成功率が一定の閾値を下回ると、サービス管理者に通知するアラームが発行されます。

アラーム監視の面では、AMS プラットフォームの構築はより厳格です。当社は、マルチチャネルアラーム (rtx、 WeChat 、電子メール、SMS) と多次元監視 (L5、モジュール間呼び出し、自動テストケース、AMS ビジネス監視ディメンションなど) の提供に努めています。一部の監視ディメンションが失敗した場合でも、まず問題を検出することができます。もちろん、システムの問題を真に発見しながら迷惑を最小限に抑えるために、アラームのサイクルとアルゴリズムも制御します。

信頼性に関するもう 1 つの課題は、過負荷保護です。システムに何台のマシンがあっても、「フラッシュセール」や「スケジュール開始」などのプロモーションなど、特定の特別なシナリオでは過負荷になるリスクが常に存在します。 AMSは現在、同時に1,000以上のオンライン活動を行っていますが、これはすでに多すぎます。これらの活動の中には、常に大規模なトラフィックのプロモーションが時々あり、ビジネス側は私たちに気付いていません。どのようなシナリオであっても、AMS プラットフォーム自体が「崩壊」しないようにする必要があります。クラスターに障害が発生すると、すべてのユーザーに影響します。過負荷保護は一部のユーザー要求を破棄するだけで、ほとんどのユーザーは通常のサービスを受けることができます。

過負荷保護に関しては、いくつかの簡単な対策を講じました。

• プラットフォーム入口での過負荷保護。ビジネス特性とマシン操作経験に基づいて、Apache サービス プロセス/スレッドの最大数を設定し、この数以下ではマシンがクラッシュしたり、サービスがクラッシュしたりしないようにします。
• 多数のバックエンド配信インターフェースの保護。 AMS プラットフォームの背後には何百ものバックエンド サービス インターフェイスがあり、そのパフォーマンスはさまざまです。 AMS プラットフォームの内部電流制限により、弱いバックエンド インターフェイスを保護します。なぜなら、過負荷になると、特定の種類のインターフェースが完全に使用できなくなるからです。
• サービスの低下。データ レポート サービスなどの重要でないパスをバイパスします。
• コア サービスは独立して展開され、物理的に分離されています。すべての卵を一つのカゴに入れないでください。物理的な分離の目的は、企業間の相互影響を回避し、他のサービスの正常な運用を保護することです。

2. フラッシュセールシナリオにおけるビジネス保護

フラッシュセールはイベント運営の一般的な参加形式ですが、トラフィックへの影響の問題に加え、高同時実行時のビジネスロジックのセキュリティ問題などの課題ももたらします。現時点では、これらの問題を回避するために適切なロック機構を導入する必要があります。これはスレッドセーフティと同じタイプの問題です。

1 つ目は、ユーザーのセッション ロックです。つまり、同じサブアクティビティ機能では、前の配信要求が完了する前に、同じユーザーが 2 番目の要求を行うことが禁止されます。これを実行する理由は、同じユーザーが 2 つの同時リクエストを開始すると、重要な時間内に複数のギフト パッケージが送信される可能性があるためです。

たとえば、下図のユーザー A の場合、最初のリクエストが参加成功フラグを正常に書き込む前に、2 番目のリクエストが「条件判定」に合格して配送段階に入ることができます。この場合、ユーザー A は 2 つのギフト パッケージを受け取る可能性があります。

複数ユーザーのフラッシュセール保護ロックに基づくロックもあります。シナリオはセッションロックに似ていますが、複数の同時ユーザーが同じギフトパッケージをリクエストすることになります。同様に、ギフトパッケージの残り数を判断する重要な時間に、「過剰発行」（ギフトパッケージが多すぎる発行）が発生する可能性があります。

問題は明らかであり、ロックを使用することで確かに解決できますが、どのようなロック メカニズムを使用するかは、検討する価値のある別の問題です。ビジネスシナリオが異なるため、選択するソリューションも当然異なります。フラッシュセールの実施メカニズムを3つの異なる観点から解説します。

• キューサービス。これは比較的シンプルな実装アイデアです。フラッシュセールのリクエストを直接キューに入れて、マルチスレッドを強制的にシングルスレッドに変換するのと同じように、キュー内のリクエストを 1 つずつ実行します。ただし、同時実行性の高いシナリオでは、リクエストが非常に多いため、キュー メモリが瞬時に「バースト」し、システムが異常な状態に陥る可能性があります。あるいは、巨大なメモリ キューを設計することも選択肢の 1 つです。ただし、システムがキュー内のリクエストを処理する速度は、通常、キューに殺到するリクエストの数とは比較になりません。つまり、キュー内のリクエストはどんどん蓄積され、キューの後ろのユーザー リクエストは「応答」を取得するのに長い時間待たなければならなくなり、ユーザー リクエストに対するリアルタイムのフィードバックを実現できなくなります。
• 悲観的なロックのアイデア。悲観的ロックは、排他性と排他性が強いロックです。ユーザーからのリクエストが来たら、ロック リソースの取得を試みる必要があります。ロック リソースの取得リクエストは実行できます。取得に失敗した場合は、次の取得を待機します。ただし、同時実行性の高いシナリオでは、このようなスナッチ要求が多数発生し、増加し続けるため、サーバー上でこのような要求のバックログが発生します。リクエストの大部分はリクエストを正常に取得できず、待機状態になっています (スレッドの「飢餓」に似ています)。また、ユーザーはリアルタイムの応答やフィードバックを得ることもできません。
• 楽観的なロックのアイデア。 「悲観的ロック」と比較すると、より緩やかなロック機構を採用し、バージョン番号の更新を使用します。実装では、このデータに対するすべてのリクエストは変更対象（配信プロセスの実行）となりますが、データのバージョン番号を取得します。バージョン番号が一致するもののみ正常に更新できます（バージョンが一致しない場合は、特定のリクエストによって正常に変更されたことを意味します）。他のユーザー リクエストは、すぐに購入失敗を返し、ユーザーはリアルタイムのフィードバックも得ることができます。これの利点は、ユーザー要求のバックログを発生させることなくロック メカニズムを実装できることです。

配信プロセスの 1 つには通常 100 ミリ秒以上かかるため、ビジネス ロックは楽観的な方法で実装されています。同時実行性が高い場合、リクエストのバックログが生成されやすく、リアルタイムのフィードバックを提供することが不可能になります。私たちの実装により、フラッシュセールのリクエストが成功したかどうかに関係なく、ユーザーは 500 ミリ秒以内にリアルタイムのフィードバックを得ることができます。さらに、この実装はさまざまなフラッシュセールや急ぎの購入に広く使用されており、1秒あたり50,000件のフラッシュセールをサポートし、非常にスムーズかつ安全に実行されています。

IV. ビジネスセキュリティシステムの構築

事業規模が拡大するにつれ、AMS プラットフォームから毎日送信される出荷業務の数も増加します。休日以外は毎日5,000万点以上、ピーク時には2億点以上が出荷されます。同時に、ここでのアクティビティには、iPad、iPhone、高価な仮想小道具など、多くの高価値のアイテムが含まれており、一部のアクティビティでは現金ギフトパッケージ（Tenpay 経由で支払われる）の使用も促進されています。

したがって、当社のビジネス セキュリティ要件は、通常のインターネット製品よりも高く、厳格です。

1. 従来のセキュリティ攻撃の様相と悪意のあるユーザー

成熟したインターネット企業は通常、独自のセキュリティチームを持っています。通常、データモデリングを通じて悪質なユーザーのブラックリストのデータベースを構築し、悪質なアカウントや IP アドレスなどの情報を継続的に維持してデータを更新します。次に、このサービスをそれに接続します。悪意のあるスタジオは多数のアカウントと IP を保有しており、私たちはこの悪意のあるデータベースを通じてそれらを傍受します。

しかし、データ モデリング アルゴリズムがどれだけ洗練されていても、実際のユーザーを誤って殺してしまうことを防ぐためには、ヒット率の問題が常に存在します。通常、悪意のあるリクエストをすべて阻止することはできず、網をすり抜けてしまうリクエストが必ずいくつか存在します。

私たちが考えているのは、この基盤にビジネスを融合し、新たなセキュリティ保護戦略を追加することです。参加基準を追加することでさらなる保護を実現できるのかと疑問に思う人も多いかもしれません。例えば、従来のセキュリティ取り締まり戦略をベースに、活動参加条件をスーパー会員（月額20元の有料会員）に設定するなどの業務制限を加え、より高い閾値で悪意のあるリクエストを阻止します。

長い間、私はこのアプローチは参加のハードルを上げたので信頼できるはずだと考えていました。ある時、私たちは数万の悪意のあるQQ番号（すべて非常に長い数字のジャンク番号）を捕獲しましたが、それらはすべてスーパー会員でした。悪意のあるスタジオは実際に多額の費用をかけて、月額20元でスーパー会員を開設しました。その頃から有料会員の制限も当てにならないことがわかってきました。

スーパー会員のステータスは、これらの悪意のある番号にさらなる利便性をもたらし、より多くの高価値のギフトパッケージを取得する機会を与えることができます。これは現金に変換され、悪意のあるスタジオの「投資コスト」をカバーできます。

2. ビジネスセキュリティ支援システムの構築

AMS は、多次元的かつ総合的なセキュリティ サポート機能を構築します。これらのセキュリティ構造は、次の 4 つの次元に分類されます。

• ポータル セキュリティ: ユーザーに接続し、悪意のあるリクエストや攻撃リクエストをフィルタリングし、ビジネス ロジックのセキュリティを保護する CGI ポータル。
• 人的エラー: 開発および運用担当者が管理側で誤った操作や設定エラーを起こす可能性があります。人的エラーは人間が保証できるものではありません。代わりに、プラットフォーム レベルの権限管理とインテリジェントな検出を構築して、人がミスを起こさないようにする必要があります。
• 運用監視: 業務状況を多角的に監視し、問題を迅速に発見します。
• セキュリティ監査: 制御性と追跡可能性を確保するために、機密性の高い権限を完全に収集、管理、監視します。