また、2016年11月7〜8日にモスクワ近郊のスコルコボで開催されたHighLoad ++会議のスピーチのトランスクリプトを公開します。 今日、Evgeny Pivenはクラウド内のバランスソリューションを紹介します。







私の名前はZhenyaです。IPONWEBで働いています。 今日は、負荷の高いシステムのバランスをとるソリューションの開発についてお話します。



最初に、私が操作する概念について説明します。 RTB、リアルタイムビッディング-リアルタイムオークションで広告を表示することから始めましょう。 サイトにアクセスするとどうなるかを示す非常に簡略化された図：







広告を表示するために、リクエストがRTBサーバーに送信されます。RTBサーバーは、広告サーバーにレートを要求し、表示する広告を決定します。

IPONWEBの機能

クラウドにはすべてのインフラストラクチャがあります。 AmazonとGCEを非常に積極的に使用しており、数千のサーバーがあります。 私たちが完全にクラウドに住んでいる主な理由はスケーラビリティです。つまり、インスタンスを頻繁に追加/削除する必要があることがよくあります。



1秒あたり数百万のリクエストがあり、これらはすべてHTTPリクエストです。 これは、他のプロトコルに完全に適用できない場合があります。 非常に短い回答があります。 たぶん、平均1〜数キロバイトの回答ではありません。 大量の情報を扱うのではなく、非常に大量の情報を扱うだけです。



キャッシュは私たちには関係ありません。 CDNはサポートしていません。 お客様がCDNを必要とする場合、お客様自身がこれらのソリューションに取り組んでいます。 非常に強い日内変動とイベント変動があります。 休日、スポーツイベント、季節限定の割引などで表示されます。日当はこのチャートでよく見ることができます。







赤いチャートはヨーロッパの国の通常の標準チャートであり、青いチャートは日本です。 このグラフでは、毎日約12時に急激なジャンプがあり、約1時間でトラフィックが急激に低下することがわかります。 これは、人々が昼食に出かけるという事実と、非常にまともな日本人として夕食時に最も積極的にインターネットを使用するためです。 これは、このグラフで非常にはっきりと見えます。



世界中に幅広いユーザーがいます。 これが、クラウドを使用する2番目の大きな理由です。 迅速に回答することは非常に重要です。サーバーがユーザーから他の地域にある場合、RTBの現実には受け入れられないことがよくあります。



そして、サーバーとユーザーのトラフィックを明確に区別しています。 最初のスライドで示したスキームに戻りましょう。 簡単にするために、ユーザーからプライマリRTBサーバーに送られるのはユーザートラフィックのみで、その背後で発生するのはサーバートラフィックのみです。

なぜバランスを取るのですか？

2つの主な理由は、サービスの スケーラビリティとアクセシビリティです 。



スケーラビリティとは、新しいサーバーを追加するとき、それを処理できない1台のサーバーから少なくとも2台まで成長するときであり、何らかの方法でそれらの間で要求を分散させる必要があります。 可用性は、この単一のサーバーに何かが起こることを恐れている場合です。 もう一度、秒を追加する必要があります。そのため、それらの間で何らかの形ですべての要求のバランスが取れ、それらに応答できるサーバーにのみ要求が分散されます。



バランサーには他に何が必要ですか？ もちろん、これらの機能は、アプリケーションごとに異なる場合があります。 私たちにとって最も重要なのはSSLオフロードです。 仕組みを以下に示します。







ユーザーからバランサーへのトラフィックは暗号化されています。 バランサーはそれを解読し、既に解読されたHTTPトラフィックをバックエンドに分散します。 次に、バランサーはそれを暗号化して戻し、暗号化された形式でユーザーに返します。



また、セッションアフィニティと呼ばれることが多いスティッキーバランシングなども必要です。







なぜこれが私たちに関連するのですか？ ページに広告用のスロットがいくつかある場合、このページを開くと、すべてのリクエストがすぐに1つのバックエンドに届きます。 なぜこれが重要なのですか？ ロードブロッキングなどの機能があります。 つまり、ペプシなどのスロットの1つにバナーを表示した場合、別のスロットでは同じペプシまたはコカコーラのバナーを表示できません。これらは競合するバナーであるためです。



ユーザーに現在表示しているバナーを理解する必要があります。 バランスを取るとき、ユーザーが1つのバックエンドに来たことを確認する必要があります。 このバックエンドでは、セッションの外観を作成しており、このユーザーにどの広告を表示できるかを正確に理解しています。



フォールバックもあります。 上記の例では、機能しないバナーが表示され、右側に機能するバナーが表示されます。







フォールバックは、何らかの理由でバックエンドが対処できない状況であり、ユーザーにページを壊さないために、通常は完全に空のピクセルをユーザーに提供します。 ここでは理解のために大きな緑色の長方形で描画しましたが、通常は小さなGIF、200分のHTTPレスポンス、正しいヘッダーセットであるため、レイアウトに支障はありません。



したがって、通常のバランスが取れています。







青い太字の行は、すべてのリクエストの合計です。 多くの場合、これらの小さな行は、各インスタンスのリクエストです。 ご覧のとおり、ここではバランスがとれています。ほとんどすべてがほぼ同じ方法で1つの行にマージされます。



これは喫煙者のバランサーです。 ここで何かがおかしかった。







問題はAmazon側にあります。 ちなみに、これは最近、ほんの2週間前に起こりました。 Amazonバランサーからのトラフィックは、この形式で到着し始めました。



メトリックスは良いと言う価値があります。 ここで、アマゾンはまだ何か悪いことが起こっているとは信じていません。 この一般的なグラフのみが表示され、リクエストの合計のみが表示されますが、インスタンスによって受信されるリクエストの数は表示されません。 まだバランサーに問題があることを彼らに証明しようと努力しています。

DNSバランシング

それで、私たちのプロジェクトの例でバラン​​スを取ることについて話しましょう。 最初から始めましょう。 プロジェクトは若かった、私たちはこのプロジェクトの始まりについてです。







このプロジェクトのトラフィックのほとんどはサーバー側です。 サーバートラフィックを処理する機能：いくつかの問題を簡単に解決できます。 クライアントの詳細がわかっていれば、最後に何かを変更したり、システムを更新したり、何か他のことをしたりして、それら。 別のプールでそれらを選択できます。ある種の問題を抱えている1人のクライアントを別のプールにバインドし、問題をローカルで解決できます。 または、非常に厳しい場合には、禁止することもできます。



最初に使用し始めたのは、通常のDNSバランシングでした。







ラウンドロビンDNSプールを使用します。







DNSを照会するたびに、プールがローテーションされ、新しいIPアドレスが上部に表示されます。 したがって、バランスが機能します。



一般的なラウンドロビンDNSの問題：

• 彼にはステータスチェックがありません。 バックエンドで何か問題が発生したことを理解できず、リクエストの送信を停止します。
• 顧客の位置情報を把握していません。
• サーバートラフィックにとって重要なかなり少数のIPから要求が来た場合、バランシングはあまり理想的ではありません。

Gdnsdバランシング

Gdnsdが助けになります-これはDNSサーバーであり、おそらく多くの人が知っているもので、現在積極的に使用しています。

• 使用するgdnsdの主な機能はDYNAレコードです。 これらは、特定のプラグイン、動的に1つのAレコードまたはAレコードのセットを使用して、リクエストごとに発行されるそのようなレコードです。 内部ではラウンドロビンを使用できます。
• gdnsdはgeoIPデータベースをサポートできます。
• 彼にはステータスチェックがあります 。 TCPを介してホストにいくつかの要求を送信し、HTTPを介して応答を確認し、現在何らかの種類の問題がある使用されていないサーバーをプールからスローできます。

これらのレコードのダイナミズムを維持するには、かなり低いTTLを維持する必要があります。 これにより、DNSサーバーへのトラフィックが大幅に増加します。多くの場合、クライアントはこれらのプールを再クエリする必要があるため、それぞれより多くのDNSサーバーがあります。



しばらくすると、512バイトの問題が発生します。







512バイトの問題は、ほぼすべてのDNSサーバーの問題です。 当初、DNSが設計されたばかりのとき、モデムの最大MTUは576バイトでした。 これは、512バイト+ 64ヘッダー長です。 DNSからのパケットは、歴史的にUDPで576バイトを超えて送信しません。 512バイトより長いプールがある場合、プールの一部のみを送信し、その中の切り捨てられたフラグを有効にします。 次に、クライアントからTCP要求が送信され、このプールを再度要求します。 そして、私たちは彼に完全なプールを、現在はTCPを介して送信します。



一部のお客様のみがこの問題を抱えており、約15％です。 それらを個別にプールに分離し、gdnsdで加重プールを使用することができました。



この場合のボーナス加重プール-破損する可能性があります。 たとえば、100台のサーバーがある場合、それらを5つの部分に分割します。 各リクエストには、これらの小さなサブプールの1つを指定します。このサブプールには、サーバーが20台しかありません。 そして、ラウンドロビンは、新しいプールを発行するたびに、これらの小さなプールを通過します。 プール自体の内部では、ラウンドロビンも使用されます。これらのIPはシャッフルされ、新しいIPが提供されるたびにシャッフルされます。



さらに、gdnsdの重みは、たとえば、ステージングサーバーに使用できます。 弱いインスタンスがある場合は、最初にそれよりはるかに少ないトラフィックを送信し、そこでのみ何かが壊れていることを確認して、かなり小さなトラフィックセットを送信できます。 または、異なるタイプのインスタンスがある場合、または異なるサーバーを使用する場合。 （私たちはクラウドにすべてを持っているので、しばしば「インスタンス」と言いますが、特定のケースではそうではないかもしれません。）つまり、異なるタイプのサーバーを使用し、gdnsdを使用してトラフィックを増減できます。



ここにも問題があります-DNSキャッシング。 多くの場合、このプールに対して要求が行われると、小さなプールのみが提供され、このプールはキャッシュされます。 一部のクライアントは、再度DNSに問い合わせることなく、このプールで生き続けます。 これは、DNSクライアントの動作が悪く、TTLに準拠しておらず、更新せずにIPアドレスの小さな限定セットでのみ動作する場合に発生します。 最初にTCPに関する完全なシートを受け取った場合、これは正常です。 しかし、彼が重み付けされた小さなプールのみを受け取った場合、これは問題になる可能性があります。



しばらくして、私たちは新しい問題に直面しています。







サーバートラフィックの残りの85％は、gdnsdが呼び出すように、通常のマルチプールを引き続き使用します。 それらのいくつかで、問題が始まります。



この問題はAmazon DNSでのみ発生することがわかりました。 つまり、Amazon自体でホストされているお客様は、253を超えるホストがあるプールを解決するときに、NXDOMAINエラーが発生するだけで、このプール全体を完全には解決しません。



これは、約20台のホストを追加したときに発生し、270台のホストがありましたが、この数を253にローカライズすると、この数で問題が発生することがわかりました。 現在、この問題はすでに修正されています。 しかし、その瞬間、私たちは時間をマークしていることに気付き、どういうわけかこの問題をさらに解決する必要があります。



私たちは雲の中にいるので、最初に考えたのは垂直スケーリングを試すことです。 うまくいったので、インスタンスの数を減らしました。 しかし、これも問題の一時的な解決策です。

エルブ

私たちは他の何かを試してみることにしました、そして選択はELBに落ちました。







ELBはElastic Load Balancing、トラフィックを分散するAmazonのソリューションです。 どのように機能しますか？



彼らはあなたにCNAMEを提供します。この場合、これはwww.site.com



下のこの怖い行www.site.com



：elb、numbers、regionなど。 そして、このCNAMEは、バックエンドでバランスを取るいくつかの内部インスタンスIPに解決されます。 この場合、DNSのCNAMEをプールにバインドする必要があるのは1回だけです。 次に、バランサーが分散しているサーバーを追加します。



ELBはSSLオフロードが可能で、証明書を添付できます。 彼はまた、HTTPステータスチェックを知っており、インスタンスがどの程度ライブであるかを理解しています。



ほぼすぐに、ELBで問題が発生し始めました。 いわゆるウォームアップバランサーELBがあります。 これは、1秒あたり20〜3万件を超えるリクエストを開始する場合に必要です。 すべてのトラフィックをELBに転送する前に、Amazonに手紙を書く必要があります。大量のトラフィックを送りたいということです。 彼らはあなたにあなたの交通の特徴、どれだけ、いつ、どれくらいの期間それをすべて支援しようとしているのかについてたくさんの恐ろしい質問を書いた手紙を送ります。 その後、新しいインスタンスをプールに追加し、トラフィックの流入の準備が整います。



そして、予備的なウォームアップでも、問題に遭遇しました。 1秒あたり4万件のリクエストを依頼したところ、約3万件がすべて壊れました。 すべてをすばやくロールバックする必要がありました。



また、バランスの取れた応答率もあります。 これは、Amazonバランサーのアルゴリズムです。 彼は、あなたのバックエンドがどれほど速く反応するかを見ます。 彼がそれをすぐに見たら、そこにより多くのトラフィックを送信します。



ここで問題は何ですか？ バックエンドが必死に500（サーバーエラーを示すHTTP 5XXステータスコードを提供する）で対処できない場合、バランサーはバックエンドが非常に迅速に答えを出し、さらに多くのトラフィックを送信し始め、バックエンドをさらに曲げます。 私たちの現実では、これはさらに問題です。すでに言ったように、すべてが悪い場合でも、通常は200番目の回答を送信するからです。 ユーザーにはエラーは表示されず、空のピクセルを送信するだけです。 つまり、私たちにとってこの問題の解決はさらに困難です。



前回のAmazonカンファレンスで、彼らに何か悪いことが起きた場合、例外として、100-200ミリ秒のタイムアウトをラップし、人工的に500番目の回答を遅くして、Amazonバランサーがあなたのバックエンドが対処していないことを理解すると述べました。 しかし、一般的には、良い方法で、正しいステータスチェックを行う必要があります。 その後、バックエンドは問題があることを理解し、ステータスチェックに問題を与え、それを単にプールから捨てます。



Amazonに新しいソリューションが追加されました： Application Load Balancer（ALB） 。 これはかなり興味深いソリューションですが、私たちにとってはあまり意味がありません。何も解決できず、おそらくもっと費用がかかるからです。 ホストシステムはより複雑になりました。



ただし、ALBはパスベースのルーティングをサポートしています。これは、たとえば、ユーザーが/video



にアクセスしている場合、リクエストを1つのインスタンスセットに、 /static



、次に別のインスタンスにリダイレクトできることを意味します。



WebSocket、HTTP / 2、およびコンテナのサポートがあります。 同じインスタンス内にDockerがある場合、それらの間で分散できます。

GLB

GoogleではGLBを使用しています。 これはかなり興味深い解決策です。 Amazonと比較して、多くの利点があります。



まず、IPは1つしかありません。 Googleでバランサーを作成すると、サイトにリンクできる唯一のIPアドレスが与えられます。 つまり、ベアドメインにバインドすることもできます。 CNAMEを第2レベルドメインにバインドできます。







すべての地域に対して1つのバランサーのみを作成する必要があります。 つまり、Amazonでは、このリージョン内のインスタンス間でバランスを取るために各リージョンにバランサーを作成する必要があり、Googleには1つのバランサーと1つのIPのみがあり、異なるリージョン間ですべてのインスタンス間でバランスを取ります。



Googleバランサーは、IPとCookieの両方でスティッキーにできます。 Stickyが必要な理由を説明しました。1人のユーザーを1つのバックエンドに転送する必要があります。 AmazonバランサーはCookieのみを使用できます。つまり、彼ら自身がバランサーレベルでCookieを発行します。 その後、チェックされ、インスタンスの1つに対応するユーザーのCookieが同じインスタンスに送信されることが明らかな場合。 GoogleはIPを使用できますが、これはすべての問題を常に解決するとは限りませんが、私たちにとってはるかに優れています。



Googleバランサーにはインスタントウォームアップがあります。ウォームアップする必要はまったくありません。すぐに最大100万件のリクエストを送信できます。 100万のリクエストは、彼ら自身が確かに約束するものであり、私自身がチェックしたものです。 どういうわけか彼らは自分自身の中で成長し続けていると思います。



しかし同時に、バックエンドの数が急激に変化するという問題があります。 ある時点で、約100の新しいホストを追加しました。 この段階で、Googleバランサーは曲がりました。 Googleのエンジニアと話を始めたとき、彼らは次のように言った。



また最近では、HTTPバランサーで、バランサーの作成時に使用できるポートをカットしました。 以前は、通常の入力フィールドがありましたが、現在は80〜8080ポートの間でしか選択できません。 一部の人にとって、これは問題になる可能性があります。



これらのクラウドバランサーはいずれもSNIをサポートしていません。 複数のドメインと複数の証明書をサポートする必要がある場合は、証明書ごとに個別のバランサーを作成してバインドする必要があります。 これは解決可能な問題ですが、この状況は不便かもしれません。