統合には、文字通り1ミリ秒ごとの遅延、インフラストラクチャのアップグレード、コンテンツ配信テクノロジーの開発という苦労が伴いました。これらは、私たち自身が名前を考え出す必要がありました。仕事の過程で遭遇したこと、最終的に何が起こったのか、そしてなぜユーザーがそれを必要とするのかをお伝えします。
クラウドをCDNと統合する理由
まず第一に、パブリッククラウドはスケーラブルな容量です。これらは、サービスの開発とテスト、およびデータの保存と処理など、あらゆる方法で使用できます。G-Core Labsは昨年クラウドを立ち上げ、すでに高負荷のプロジェクトでクラウドを使用することができました。たとえば、長年のクライアントであるWargamingは、このソリューションを一度に複数のタスクに使用します。
- さまざまなプロジェクトの新機能とサービスをテストします。
- 分離されたカスタムおよび制御されたリソースへのアクセスを必要とする外部開発者と一緒にテストプロトタイプを準備します。
- 仮想マシンでのオンラインゲーム「Caliber」の操作。
クラウドは上記のすべてに一気に対処しますが、作業はそれだけではありません。これらまたはそれらの容量が何に使用されているかに関係なく、それらの作業の結果は、目的のポイントに配信される必要があります。オンラインゲームや実際の軍隊など、それが何であれ、ここで問題が発生します。マルチトンの軍事装備を備えた遠隔地に大量のデータを迅速に配信することは非常に困難です。このタスクは、クラウドをコンテンツ配信ネットワークと統合することで簡素化できます。 CDNの助けを借りて、転送可能な部分（静的データ）を「空中」で直接宛先にスローできます。残っているのは、クラウドから「特大」の動的データを送信することだけです。このアプローチでは、統合により、より高速な競合他社が世界中に重いコンテンツを配信できるため、他の大陸でも安全に作業を開始できます。
, , : CDN
詳細に取り掛かりましょう。重いコンテンツをクラウドから直接リモートリージョンに配信するには長い時間がかかり、負荷の増加に応じてインフラストラクチャの容量を絶えず増やすにはコストがかかる可能性があることを私たちは直接知っています。幸いなことに、パブリッククラウドに加えて、私たちは独自のCDNを作成しました。これは、ギネスブックオブレコードにも登録され、ピーク時にWorld ofTanksを中断することなくプレイできるようになりました。
1つの石で2羽の鳥を殺すには、それを雲と統合する必要がありました。そうすれば、インフラストラクチャのアップグレードよりもコストがかからず、リモートリージョンへのデータ配信を高速化できるソリューションをユーザーに提供できるようになります。そこで、作業の最初のフェーズを開始し、主要な問題を解決しました
。1。クラウドサービスに一定の負荷がかかっていた。高負荷プロジェクトのユーザーは、クライアントのクラウドにコンテンツを定期的に要求しました。これにより、高負荷と長いデータリターンが発生しました。ソースへの参照の数を簡単に減らすことができるソリューションが必要でした。これを行うために、パブリッククラウドサーバーとCDNキャッシュサーバーを統合し、これらのサービスを管理するための単一のインターフェイスも作成しました。その助けを借りて、ユーザーは静的データをネットワーク上の目的の場所に移動できます。このため、クラウドへの呼び出しは、コンテンツの最初のリクエストでのみ発生します。これは標準的な方法で機能します。CDNはソースからデータを取得し、それをユーザーと最も近いキャッシュサーバーに送信し、そこからコンテンツが後続のリクエストで配信されます。
2.データはクラウドとCDNの間で長時間転送されました。クラウドとコンテンツ配信ネットワークを組み合わせることで、データ配信の待ち時間を短縮できることに気づきました。貴重なミリ秒をできるだけ節約するために、バックボーン内のキャッシュサーバーとクラウド間のトラフィック交換を実装する必要がありました。
3.ソースへの負荷が不均一でした。 CDNを接続した後でも、クラウドへの残りの要求は非効率的に分散されました。これをHTTP（S）バランサーで修正しました。これで、コンテンツリクエスト時に、どのソース（仮想マシンまたはクラウドストレージバケット）からデータをキャッシュ用に取得するかを決定します。
4.重いコンテンツがユーザーに届くまでに長い時間がかかりました。待ち時間を短縮するために、CDNプレゼンスの容量と地理を絶えず増やしました。これで、ユーザーはコンテンツが世界中の途中で届くのを待つ必要がなくなりました。連絡時に、コンテンツ配信ネットワークは5つの大陸で最も近い100の拠点を選択します。その結果、世界中の平均応答時間は30ミリ秒以内です。
これらの問題に対処した後、私たちはすでに作業が終了したと考えています。しかし、CDNを使用したクラウドには他の計画がありました。
これが鋼の焼き戻し方法です。インフラストラクチャを最新化しています
ある時点で、古いハードウェア構成を使用している間は、すべての努力の効果を完全に発揮できないことが明らかになりました。サーバーとその上でホストされているアプリケーションの動作を改善し、コンテンツの転送を高速化するには、インフラストラクチャのアップグレードが必要でした。空の星は今年初めに収束しました。第2世代のIntelXeonスケーラブルプロセッサラインがリリースされるとすぐにアップグレードを開始しました。
これで、標準のサーバー構成は次のようになります。
- Intel Xeon Gold 6152、6252、および5220プロセッサで実行されるクラウドサービスには、最大1 TBのRAMと、トリプルレプリケーションを備えたSSDおよびHDDがあります。
- CDNキャッシュサーバーには、Intel Xeon Platinum、CPU上の仮想RAID、およびSSDD3-S4610が装備されています。
アップグレードの結果、パフォーマンスが大幅に向上したため、一部のサーバーを放棄し、それらの運用コストを削減しました。上記のすべては、どのプロジェクトの作業にも十分すぎるように思われました。しかし、ある日、これでは十分ではありませんでした。
シールド、シャーディング、地理的配布：極端な条件でのコンテンツ配信の加速
不幸は決して一人ではありません。これは、グローバルプロジェクトに関しては特に当てはまります。地理的に分散したインフラストラクチャの欠如、世界中からの多くのユーザーによる高負荷、および迅速に配信する必要がある大量の異種データ-クライアントの1つである大規模なメディアリソースは、これらすべての複雑さに一度に対処する必要がありました。いくつかの詳細：
- コンテンツは長い間ユーザーに届きましたが、大きな遅延やネットワークの問題のためにまったく届かないこともありました。困難なのは、データを含むサーバーの大規模なプール全体が1つの地理的なポイントに配置されていたことです。
- コンテンツソースには世界中のユーザーがアクセスしたため、インフラストラクチャの負荷が増大し、サービスコストが高くなり、データ配信が遅くなりました。
- ユーザーは、各地域に固有の絶えず更新される大量のコンテンツを配信する必要がありました。
ここでは、クラウドとCDNの統合の基本的な機能が不可欠でした。追加のソリューションの開発を開始しました。
地域のシールドをどのように思いついたのか
特にコンテンツソースのリモート性の問題を解決するために、この概念を導入し、現在は既存のサービスを導入しています。すべてのクライアントのサーバーが1つの地理的ポイントに配置されていたため、それらのサーバーからのデータが世界のさまざまな地域のユーザーに到達するまでに長い時間がかかりました。常に更新されるさまざまなコンテンツをさまざまな地域に配信する必要があるという事実により、状況は複雑になりました。エッジサーバーでの単純なデータキャッシングでは問題は解決しません。それでも、世界中の途中でソースにアクセスすることがよくあります。
さまざまな大陸の人気のあるトラフィック交換ポイントにキャッシュサーバーの大規模なプールを展開することで、問題を解決しました。「地域シールド」は、ユーザーの国のソースサーバーとエッジサーバーの間の一種のレイヤーになっています。これで、世界の対応する地域で要求されたすべてのコンテンツが最初にそれらに分類され、次にキャッシュサーバーに送信されました。したがって、シールドにより、クライアントのソースへの負荷が一度に減少し、エンドユーザーへの遅延が減少しました。次に、クライアントは、世界のさまざまな地域で同じコンテンツを持つ複数のサーバープールをホストすることを節約しました。これは、この作業原則では1つのデータソースで十分だったためです。
コンテンツシャーディングが必要な理由
地域のシールドは、世界のさまざまな地域へのコンテンツの長期配信の問題を解決しました。しかし、今度は新たな問題が発生しました。クライアントには大量のデータがあり、常に更新されていたため、ユーザーがアクセスしていたエッジサーバーのキャッシュに保存されませんでした。これにより、キャッシュサーバーからの大量のリクエストが常に地域のプールに注がれ、1つのグループの数は20〜30個に達しました。この負荷の一部をシールドから取り除き、コンテンツをユーザーにさらに高速に配信するために、プール内の最も近いエッジサーバーから必要なデータを取得する機能を追加しました。
現在、プレゼンス領域のキャッシュサーバーは、グループ全体にデータがない場合にのみシールドにアクセスし始めました。さらに、これらの場合でも、コンテンツはそれを含むサーバーからすぐに要求されました。シャーディングのおかげで、エッジサーバーは特定のファイルがどこにあるかを事前に「知って」おり、これについて地域シールドのプール全体をポーリングしませんでした。この動作原理により、プールへのリクエスト数が減り、各サーバーにデータのコピーを保存する代わりに、プール全体にコンテンツを効率的に配信できるようになりました。その結果、シールドにはより多くのコンテンツが含まれ、その結果、クライアントのソースにかかるストレスが少なくなりました。
このようなインフラストラクチャの作成には、もう1つの困難が伴います。グループ内のキャッシュサーバーの数を考えると、それらのどれもが失敗する可能性がないと仮定するのはばかげています。このような状況では、プールに新しいサーバーを追加する場合のように、グループ内のキャッシュを最適な方法で再配布する必要がありました。これを行うために、nginxのアップストリームブロックに一貫したハッシュアルゴリズムを使用してシャードキャッシュの編成を実装しました。
upstream cache_servers {
hash $cache_key consistent;
server edge1.dc1.gcorelabs.com;
server edge2.dc1.gcorelabs.com;
server edge3.dc1.gcorelabs.com;
}
プール内の使用できないサーバーの出現にも、別の問題がありました。他のサーバーは引き続き要求を送信し、応答を待ちました。この遅延を取り除くために、プール内のそのようなサーバーを検出するためのアルゴリズムを作成しました。現在、アップストリームグループで自動的にダウン状態に移行されるため、非アクティブなサーバーにアクセスできなくなり、サーバーからのデータを期待できなくなります。
これらの作業の結果、クライアントのサービスコストを削減し、独自のインフラストラクチャを編成するための深刻なコストからクライアントを救い、すべての困難にもかかわらず、ユーザーへのデータの配信を大幅に加速しました。
CDNでクラウドが必要な人
統合作業は終了し、お客様はすでに製品を使用しています。どれがこれを最大限に活用するかを共有します。
すぐに、このソリューションがすべての人に役立つわけではなかったとしましょう。他に何も期待していませんでした。ストレージと仮想マシンだけで十分なものもあれば、コンテンツ配信ネットワークで十分なものもあります。たとえば、プロジェクトのオーディエンス全体が同じ地域にいる場合、CDNをクラウドに接続する必要はほとんどありません。この場合、遅延を最小限に抑えるには、ユーザーからそれほど遠くない場所にあるサーバーで十分です。
統合は、多くのユーザーに重いコンテンツをすばやく遠くに提供する必要があるときに、その栄光のすべてで明らかになります。 CDNを備えたクラウドがさまざまなプロジェクトにどのように役立つかの例をいくつか示します。
- 待ち時間とバッファリングに不可欠なストリーミングサービスは、安定した動作と高品質のブロードキャストを保証します。
- オンラインエンターテインメントサービスは、重いゲームを世界のさまざまな地域に迅速に配信し、ピーク時を含むサーバーの負荷を軽減します。
- メディアプロジェクトは広告の読み込み時間を短縮し、トラフィックが急増してもアクセス可能な状態を維持します。
- オンラインストアは、プロモーションや販売中など、さまざまな国でより速く読み込まれます。
私たちは、彼らがCDNでクラウドをどのように使用しているかを正確に確認し続けています。私たちはあなたと同じように、インフラストラクチャの負荷がどれだけ軽減されるか、特定の地域でユーザーがコンテンツをどれだけ速く受信するか、統合がどれだけお金を節約するのに役立つかなどの数値に関心があります。これらすべてを将来のケースで共有します。