Honor of Kings の同時接続率の高さの裏にある物語

まとめ

中国で最も人気のあるモバイルゲーム「Honor of Kings」には、数億人のユーザーと4億人の毎日のアクティブユーザーがいます。ビジネス上の緊急事態に対して、迅速かつコスト効率よく保護するにはどうすればよいでしょうか?この記事では、この問題から始めて、問題に対応する解決策について説明し、その効果をまとめます。

背景

「Honor of Kings」は巨大なユーザーベースを持ち、高いアップデート頻度を維持している国家レベルのモバイルゲームです。このビジネス シナリオではバーストが非常に頻繁に発生しますが、ビジネス経験が重要であり、CDN の使用が不可欠です。同様に、速報ビデオ、大規模なライブ イベント、人気の TV シリーズや映画の公開、人気のゲーム、その他のアプリケーションのリリースなど、帯域幅のバーストが発生するシナリオも頻繁にあります。同時に、家庭用帯域幅とモバイル ネットワークの急速なアップグレードにより、バースト帯域幅の規模はますます大きくなり、Tb レベル、さらには 10Tb に達することもよくあります。ビジネス上の緊急事態に対して迅速かつコスト効率よく保護する方法は、CDN にとって大きな課題となっています。

2007 年、Tencent は最初の事業である Tencent.com に接続する独自の CDN を立ち上げました。 CDN 帯域幅は数十 Gb から数十 Tb に増加しました。単一サービスの帯域幅も増加しています。ほとんどのサービスは数百 Gb の一定帯域幅を持ち、一部のバーストサービスは 10 Tb に達しています。ネットワークの急速なアップグレード、モバイル ユーザーの爆発的な増加、オンデマンドやライブ ブロードキャストなどのビデオ サービスの増加により、ビジネス バーストが頻繁に発生し、バースト帯域幅がますます高くなり、CDN に対する要件も高まっています。

テンセントの事業の急成長のおかげで、自社構築の CDN はゲームのダウンロード、ストリーミング ビデオの高速化、春節の紅包など、テンセントの社内ビジネスを次々とサポートしてきました。 2014 年、Tencent はすべての CDN 機能を開放し、Tencent Cloud CDN 製品となりました。社内業務の遂行に加え、Kuaishou On-DemandやDouyu Liveなどのサードパーティ顧客との連携も開始しました。上記のビジネスはすべて、緊急事態と強いコスト要求を抱えています。 Tencent CDN は、低コストでビジネス上の緊急事態を確実に回避する方法について豊富な経験を蓄積してきました。次に、課題と問題点、解決策、効果を分析します。

1. 課題と問題点

以下では、事業特性から始めて、現在の課題と問題を分析します。

1. 事業特性と課題

CDN のシナリオが多様であるということは、新しいサービスには必ず多くの課題が伴うことを意味します。バースト サービスは、大量、多様なシナリオ、不規則性が特徴です。

a) 大容量: ほとんどのバースト サービスの帯域幅は Tb を超え、10T に達するものもあります。

b) 多様なシナリオ：人気ドラマや最新ニュースをオンデマンドで配信。 LOL/KPL/DOTA2などのゲーム、NBA/ワールドカップなどのスポーツ、コンサートなどのバラエティ番組のライブ放送。アプリケーションのダウンロードにおけるHonor of Kingsなどのゲームのダウンロード。静的 Web ページの高速化におけるレッド エンベロープ アクティビティと電子商取引のプロモーション。

c) 不規則性: 突発的な出来事の中には予測できないものもあり、ニュース速報など、始まる直前またはすでに始まっているまで知ることができません。

規模が大きいため、準備にはより多くのリソースが必要です。多様なシナリオには、異なるリソース要件を満たす必要があります。そして、その不規則性により、拡張効率に対する要求が高まります。

2. 現在の問題

突然のビジネスニーズに対応するためだけに大量のリソースを予約するのはコストがかかりすぎ、リソースの大きな無駄につながります。したがって、私たちは通常、リソースを再利用することでビジネス上の緊急事態に対処します。ただし、リソースを直接再利用することには 2 つの問題があります。

a) 一部のリソースのみを再利用できます。CDN サービスでは通常、プラットフォームとリソースの使用をサービス タイプごとに区別します。主な理由は、サービス タイプによってリソース要件が異なるためです。たとえば、オンデマンド サービスではより多くのストレージが必要になります。より多くの https リクエストを含む静的ページでは、より多くの CPU リソースが必要になります。この制限により、リソースを十分に活用することができなくなり、リソースの準備の難易度が増します。たとえば、ビデオバーストでは主にビデオ バッファーが使用されますが、ダウンロード バッファーと Web ページ バッファーは直接使用できないため、バッファーのサイズが制限されます。同じ種類のリソースを再利用する場合でも、複数のビジネスリソースの調整が必要になるため、準備に通常 2 日以上かかり、一時的な緊急事態には対応できません。

b) コストを削減できない: ゲームアプリケーションのダウンロードなど、一部の緊急サービスでは、帯域幅が朝と正午にピークになります。このプラットフォームのリソースのみを使用すると、決済帯域幅が大幅に増加し、コストが増加します。他の事業のピークシフト特性を利用して決済帯域幅を削減することはできません。

2. 解決策

Tencent Cloud CDN は仮想化を通じて既存のリソースを再利用し、すべてのビジネスに共通のバースト プールを構築し、すべてのプラットフォームでバッファーを共有します。バースト プール内のデバイスは Docker 仮想マシンです。仮想マシンはさまざまな仕様があり、ビジネス上の需要がある限りオンデマンドで使用できます。バースト プールの帯域幅予約は 10Tb に達し、基本的にすべてのビジネス緊急需要を満たすことができます。ビジネスで突然の需要が発生した場合、自動シェルフ インターフェイスを使用して 10Tb のバースト プールを 10 分で拡張できます。

1. バーストプールシステムのアーキテクチャ

バースト プール システムのアーキテクチャを図 1 に示します。

図1 バーストプールシステムのアーキテクチャ

a) バースト プール: 各プラットフォーム上の物理マシン上の Docker 仮想マシンで構成されたリソース プール。物理マシンへの影響を防ぐために、CPU/メモリ/ディスクの使用を制限します。元のビジネスは物理マシン上にまだ展開されており、調整する必要はありません。

b) 自動展開および監視システム: 実際のビジネスニーズに基づいて需要を自動的に予測し、容量を拡張できます。突発的な需要も10分以内に拡大可能です。オンデマンド/ダウンロード サービスの場合、ホット ファイルが自動的に配布され、ソースへの帯域幅が削減されます。

c) ディスパッチシステム：突発的な業務の急増と大量処理のため、直通列車はドメイン名ディスパッチシステムよりも有利です。直通列車のスケジュールはより柔軟になり、分単位まで迅速に実行できます。

仮想マシンと物理マシンにレポートエージェントを展開し、業務情報やサーバ負荷を1分ごとに監視システムにレポートします。監視システムは、過去の帯域幅に基づいて値を予測し、それを現在の帯域幅と比較します。現在の帯域幅が予測値の 50% を超えると、バーストと見なされます。帯域幅の増加率に応じて、システムはバースト プールから対応するデータ デバイスの容量を自動的に拡張します。事前に準備された緊急事態に対して、運用側が帯域幅要件を指定でき、システムが自動的にデバイス要件を計算して容量を拡張します。

1 分単位で報告されるサーバー負荷情報は、監視システムがスケジュールを決定するための基礎となります。システムは、コンピュータ室の残り帯域幅、サーバー帯域幅、CPU、IOなどの総合的な情報に基づいて、仮想マシンを急行列車から有効にする必要があるか無効にする必要があるかを判断します。ユーザーが訪問すると、まず直通列車ディスパッチシステムに要求します。直通列車は、ディスパッチ戦略に基づいて 302 アドレスを返します。 302 アドレスには実際の CDN リソース アドレスが含まれます。ユーザーは 302 アドレスにジャンプし、実際のコンテンツを取得します。

2. 技術的な最適化

仮想化技術を使用してリソースを再利用するための重要な前提条件は、既存のビジネスに影響を与えないことです。これには、CPU/ディスクなどのリソースと帯域幅の使用を適切に分離する必要があります。実装プロセスにおけるいくつかの問題と解決策を以下に示します。

• 単一マシンの負荷を正確に制御：過度な負荷は業務品質に影響を与えるため、単一マシンの負荷を正確に制御する必要があります。

解決：

a) クォータ システム: Express にはクォータ システムがあり、CPU/IO や帯域幅など、各仮想マシンで使用できるリソースが制限されます。監視システムで報告される情報とクォータ システムを組み合わせることで、サーバーの負荷を分単位の粒度で指定された範囲に制限することができます。

b) 一部のリクエストは 302 を返します: CPU/帯域幅/IO を制限した後、アプリケーションはホスト マシンの現在の負荷に基づいてリクエストを処理するかどうかをリアルタイムで決定できます。負荷が制限内であれば、直接処理されます。負荷が制限を超えた場合は、302 が返され、ユーザーは直通列車のディスパッチ アドレスにジャンプできるため、サービス品質にできるだけ影響を与えることなく、負荷を正確に制御できます。プログラム レベルでの負荷のリアルタイム制御は、クォータ システムを効果的に補完します。

c) ネットワーク カードのトラフィック制御: 極端なケースでは、サービス帯域幅が設定されたしきい値を超えると、仮想ネットワーク カードはホスト マシンへの影響を避けるためにパケットを積極的にドロップします。

• ディスク サイズの制限: Docker は、ext3/ext4 ファイル システムのファイル/ディレクトリ レベルでディスク サイズの制限を設定できません。

解決：

Tencent Cloud CDN サービスは基本的に ext3/ext4 ファイルシステムを使用するため、この場合 Docker はユーザーまたはユーザーグループに基づいてディスクを制限することしかできませんが、ルート環境では既存のネットワークサービスが直接使用されます。ここでは、ディスク サイズの制限の問題を解決するためにループ デバイスを使用します。仮想マシンのバースト サービスはループ デバイスにマウントされたディレクトリを使用するため、間接的にディスク サイズを制限し、過剰なディスク使用が他のサービスに影響するのを防ぐことができます。

• CPU バインディング: すべての CPU はデフォルトでバインドされます。一部の単一 CPU に高い負荷がかかると、マザーマシンのサービスに影響します。

解決：

このスクリプトは、システム内のすべての単一 CPU の負荷を 1 分ごとに収集します。頻繁な調整と不具合の影響を避けるため、15 分間の平均が取得されます。 *** 負荷の低いコアをいくつか選択し、構成ファイル cpuset.cpus を通じて動的にバインドして、仮想マシンがメインマシンの業務に与える影響を最小限に抑え、リソースを最大限に活用します。

効果

緊急プールが立ち上げられてからは、Honor of Kingsのダウンロード、NBAのライブ放送、KPL/LPLの試合のライブ放送など、複数の大規模な緊急活動を効率的にサポートし、2,000万ドルのコストを節約しました。バッファを共有し、バースト プールを構築することで、バースト容量を大幅に向上させ、コストを削減できます。

要約する

Tencent Cloud CDN は Docker テクノロジーを通じてリソースを再利用し、Tb レベルのバースト プールを構築します。これにより、ライブ ブロードキャスト、オンデマンド、静的など、さまざまなビジネス バーストをサポートできます。突然のビジネスニーズを自動で検知し、10 分以内にリソース拡張を完了できます。リリースが速く、コストが低いという特徴があります。リソースの再利用により、リソースの使用率が向上し、サービスに巨大なバースト プールを提供できますが、再利用されたサービスは相互に影響を与えることができないため、サーバーのリアルタイム監視とタイムリーなスケジュール設定が必要になることに注意する必要があります。改善できる点もいくつかあります。たとえば、さまざまなビジネスのチューニングを容易にするために、カーネル パラメータはコンテナーに基づいて分離する必要があります。一部のビジネス クライアントは 302 リダイレクトをサポートしていないため、スケジューリング システムはドメイン名のスケジューリングをサポートする必要があります。