2016年11月7〜8日にモスクワ地方のスコルコヴォで開催されたHighLoad ++会議では、スピーチのトランスクリプトで投稿を続けています。



こんにちは、私の名前はNikita Dukhovnyです。私はOdnoklassnikiプロジェクトの主要なシステム管理者として働いています。



現時点では、Odnoklassnikiのインフラストラクチャは、11,000台を超える物理サーバー上にあります。 モスクワの3つの主要なデータセンターにあります。 CDNプレゼンスポイントもあります。 ラッシュアワーの最新データによると、1秒あたり1テラビット以上のトラフィックをユーザーに提供しています。



システム管理部門では、自動化システムを設計および開発しています。 私たちは多くの研究課題に取り組んでいます。 開発者が新しいプロジェクトを立ち上げるのを支援します。



今日は、ソーシャルネットワークを例に、負荷分散とフォールトトレランスについて説明します。



プロジェクトの夜明けに、Odnoklassnikiは多くのフロントエンド間で負荷を分散するタスクに直面しました。 このプロジェクトは爆発的な成長を遂げたため、次のように決定されました。 ユーザーはwww.odnoklassniki.ru



、 www.odnoklassniki.ru



などの特定のサーバー名へのリダイレクトを受信しました。 この名前は物理サーバーに緊密にバインドされていました。



このアプローチには明らかな欠点があります。 まず、サーバーに問題がある場合、ユーザーはブラウザーでエラーを受け取りました。 次に、サーバーをローテーションから削除する場合、多くのユーザーがこのサーバーの名前をブックマークに追加したという事実に直面しました。 何かを変更する必要がありました。



次に、ロードバランサーのコミッションを決定しました。 レイヤー4バランシングを使用すれば十分でした。 これはどういう意味ですか？ これは、バランサーがIPアドレスとポートを認識していることを意味します。 つまり、仮想IPポート80に到達したユーザーは、実サーバーのポート80に送信され、ポート443に到達し、ポート443に送信されます。



さまざまなオプションを検討しました。 当時は、ソフトウェアとハ​​ードウェアとソフトウェアの両方のプロプライエタリソリューションと、オープンプロジェクトLVS（Linux Virtual Server）のどちらかを選択していました。 テスト結果によると、独自のソリューションに専念する理由は見つかりませんでした。

LVSワークフローの編成方法

ユーザーのリクエストはネットワーク機器にヒットし、リクエストをLVSに送信します。 次に、LVSは要求をフロントエンドサーバーの1つに送信します。 さらに、LVSでは永続化設定を使用します。つまり、次のユーザーリクエストは同じフロントエンドサーバーに送信されます。







LVSクラスターをフォールトトレラントにしたかったため、マスターとスタンバイのペアを編成しました。 マスター/スタンバイペア間で、セッションは常に同期されます。 これは何のためですか？ そのため、マスターサーバーが出発すると、ユーザーはスタンバイサーバーに移動すると、同じフロントエンドに送信されます。



また、サーバー間では、よく知られているキープアライブデーモンを使用してVRRPプロトコルが起動されます。 これは、LVSサーバー自体のIPアドレスがスタンバイに移行するために必要です。 このようなマスター/スタンバイペアがたくさんあります。 それらの間で、ECMPプロトコルによってバランスを取ります。 さらに、当社のネットワーク機器も永続化設定を認識しており、このようにしてチェーン全体が機能します。 ユーザーリクエストは同じLVSペアに送信され、LVSペアは同じフロントエンドに送信されます。



なんらかの方法でバランステーブルを管理する必要がありました。 当時、私たちは人気のあるldirectorソリューションを選択しました。 ldirecorデーモンは、その構成に基づいて実サーバーを分散テーブルに追加します。 また、実サーバーでチェックを実行します。 そして、実サーバーのいずれかがエラーを返し始めた場合、ldirectorはバランステーブルを修正し、このサーバーはローテーションから削除されます。



すべてが順調に見えましたが、サーバーの数は増加していました。 現時点では、各データセンターに200種類のWebタイプのフロントエンドがあります。これらはwww.odnoklassniki.ru



からのリクエストを処理するサーバーです。



実際、ldirectorはチェックをシングルスレッドモードで実行します。 問題が発生した場合、サーバーがタイムアウトより長く応答し始めると、次のことが発生します：要求は最初のサーバーに到着し、タイムアウト（たとえば、5秒）を待機し、その後、検証は2番目のサーバーに進みます。 したがって、大規模な問題では、たとえば、サーバーの半分が影響を受ける場合、この半分の出力には8分以上かかります。 それは受け入れられませんでした。



この問題を解決するために、独自のソリューションok-lvs-monitorを作成しました。 主に2つの利点があります。

1. マルチスレッドモードでチェックを実行します 。 これは、上記の問題により、サーバーが同時にローテーションから削除されることを意味します。
2. ポータル構成システムと統合します 。 以前に、テーブルを変更するために、サーバー上の構成を編集する必要があった場合、アプリケーションの設定を管理するのと同じシステムで構成を編集するだけで十分です。

LVSの運用中に、多くの技術的な問題が発生しました。

• セッションを同期するときに、マスターとスタンバイの間にかなり大きな不一致があるという事実につまずきました。
• 同期プロセスは、最初のプロセッサコアでのみ機能しました。
• スタンバイサーバーでは、このコアの50％以上を消費しました。
• さまざまなささいなことにも気づきました。 たとえば、設定の場合、ipvsadmバランシングテーブル管理ユーティリティはアクティブ/非アクティブセッションを区別しませんでした。

LVSプロジェクトの開発者にバグを報告し、テストを支援し、これらの問題はすべて修正されました。

永続性設定

先ほど、永続化設定を使用することを述べました。 私たちにとってこれは何ですか？



問題は、各フロントエンドサーバーがユーザーセッションに関する情報をメモリに保存することです。 また、ユーザーが別のフロントエンドにアクセスした場合、このフロントエンドはユーザーのログイン手順を実行する必要があります。 ユーザーにとってこれは透過的に行われますが、それでもかなり高価な技術的操作です。



LVSは、クライアントIPアドレスに基づいて永続化を実行できます。 そして、ここで次の問題に直面しました。 モバイルインターネットの人気が高まり、多くの事業者、主にアルメニアで最大の事業者が、わずかなIPアドレスの背後にユーザーを隠しました。 これにより、モバイルWebサーバーの負荷が非常に不均一になり、その多くが過負荷になりました。



ユーザーに設定したCookieの永続性を提供することにしました。 Cookieに関しては、残念ながら、レイヤー4のバランスを制限することはできません。レイヤー7のアプリケーションレベルについて話しているからです。 さまざまなソリューションを検討しましたが、当時はHAProxyが最高でした。 現在人気のあるnginxには、適切なバランス調整メカニズムがありませんでした。







ネットワーク機器に乗るユーザー要求は、同じECMPプロトコル全体でバランスが取れているため、これまでのところ何も変わっていません。 そして、興味深い部分が始まります。永続性なしで、クリーンなラウンドロビン要求がHAProxyサーバーのいずれかに送信されます。 構成内のこれらの各サーバーには、Cookieの値と特定のフロントエンドサーバーの対応が格納されます。 ユーザーが最初に到着した場合はCookieが設定され、2回目以降に到着した場合は同じモバイルフロントエンドに送信されます。



待ってください、つまり、オドノクラスニキはバランサーのクラスターをバランサーのクラスターの後ろに置きますか？ どうやら複雑に見えます。







実際、それを理解しましょう。 どうして？



この状況の場合、HAProxyを通過するトラフィックの割合は、LVS全体を通過するトラフィックの10％未満です。 つまり、私たちにとってこれは高価なソリューションではありません。 しかし、このアプローチの利点は明らかです。



HAProxyサーバーのある種の実験的な再構成を行っていると想像してください。 効果を評価したい。 この場合、このHAProxyサーバーを低回転で起動します。 まず、さらに決定を下す前にすべての統計を収集できます。 第二に、最悪の場合、問題に気付くのはごく一部のユーザーのみです。 小さな部分に正常に適用された後、クラスター全体を継続できます。

データセンターの事故

その歴史の中で「クラスメート」は繰り返し事故に遭遇しました。 データセンターのプライマリとバックアップの両方の光学系が燃え尽きたときの話がありました。 データセンターは利用できなくなりました。 不適切な設計が原因で、データセンターの電気配線が溶け始め、火災につながったという話がありました。 モスクワのハリケーンが屋根の一部を引き裂き、データセンターの冷却システムを無効にしたとき、非常に興味深い話がありました。 過熱が始まったため、どのサーバーをオフにし、どのサーバーをオフにするかを決定する必要がありました。



これらの事故の結果に基づいて、私たち自身のためのルールを策定しました。データセンターのいずれかに障害が発生した場合にOdnoklassnikiは機能するはずです。



どのようにしてこの目標に向かっていったのでしょうか？

• ストレージシステムを準備しました。 データシステムがどのデータセンターにあるかを把握できる機能を実装しました。
• レプリケーション係数= 3を使用します。 これらの2つのポイントを合わせると、各データセンターにデータのレプリカが存在するという事実につながります。
• システムでは、クォーラム= 2を使用します。 つまり、データセンターの1つが出発しても、システムは作業を続行します。

フロントエンドサーバーを3つのデータセンターに分散する必要がありました。 データセンターのフロントエンドが、データセンターが以前に受信したすべてのリクエストを受け入れることができるように、電力リザーブを考慮してこれを行いました。







www.ok.ru



でDNSクエリを実行すると、3つのIPアドレスが与えられていることがわかります。 これらのアドレスはそれぞれ1つのデータセンターに対応しています。



データセンターの事故状況を自動的に処理します。 ここでは、そのようなチェックの例を見ることができます：







最後の20個のチェックのうち10個が失敗した場合、このデータセンターのIPアドレスは与えられなくなることがわかります。 10は非常に多く、データセンターの結論は難しい操作です。 私たちは真実が偶然であることを確信したいのです。 ここでは、20回のチェックのうち20回が成功した場合にデータセンターが自動的にローテーションされることがわかります。 はい、結論は難しい操作ですが、ユーザーを開始する前にすべてが正常であることを確認する必要があります。



推定によると、この手法では5分で聴衆の80％がデータセンターを離れます。 5分という数字はどこから来たのでしょうか？







ネットワーク。 ネットワークレベルでは、かなり興味深いトリックを使用します。 実際、各データセンターの境界ルーターは、世界中のすべてのネットワークをアナウンスします。



ユーザーがIPアドレス217.20.156.159



ます。 ユーザーは、いずれかのデータセンターに移動します。 同じIPアドレスにアクセスしている別のユーザーは、実際には近くのデータセンターにいる可能性があります。 これは何のためですか？ 境界ルーターの1つに障害が発生しても、ユーザーは効果に気付きません。



ここには微妙なポイントがあります。 各データセンターで、サービス用に独自のIPアドレスを用意することをお伝えしましたが、競合する情報を提供しているようです。 そうでもない。 ネットワークのコアレベルでは、各データセンターには依然として独自のネットワークセットがあり、直接接続または独自のリングのいずれかを使用する境界ルーターだけが、目的のデータセンターに要求を送信できます。







ネットワークのコアについて。 私たちと一緒にあるすべてのネットワーク機器は、出発した隣人の負荷を引き受けることができるように、そのような予備電力で予約されています。 ネットワークのコア全体での事故のみが、データセンターからトラフィックを除去しなければならない状況に本当につながるでしょう。

重いコンテンツ

重いコンテンツとは、音楽、ビデオ、写真を意味します。



事実は、オドノクラシニキの聴衆の大部分が首都の住民と同じ品質のインターネット接続を誇ることはできないということです。 まず、私たちの聴衆のほとんどはロシア連邦の外に住んでいます。 多くの国では、外国のインターネットと国内の速度は非常に異なります。 第二に、遠隔地のユーザーは、原則として、安定したチャンネルを自慢できないことがよくあります。 たとえそれが安定していても、遅くないという意味ではありません。



ユーザーがOdnoklassnikiで快適に作業できるようにしたいと考えました。 したがって、私たちは独自のCDNソリューションについて考えました。



CDNのアイデアは非常に単純です。 キャッシングサーバーを使用して、ユーザーの近くに配置します。 CDNを構築する場合、通常、2つの古典的なアプローチのいずれかが使用されます。



IPエニーキャスト 。 その本質は、各サイトが同じネットワーク、同じアドレスを世界に発表するという事実にあります。 また、ユーザーがどのサイトにアクセスするかによって、現在のインターネットトポロジが決まります。 このアプローチの利点は明らかです。ユーザーが最適なサイトに到達するためにロジックを実装する必要はありません。







短所もはっきりと見えます。 ヴォロネジにCDNがあり、それを使って深刻なサービス作業を実行したいとします。 これを行うには、すべてのユーザーを特定のサイト（サンクトペテルブルクなど）に送信する必要があります。 IPエニーキャストを最も純粋な形式で使用すると、これを行うための直接的なメカニズムがありません。 さらに、予期しないユーザーの移行などのイベントの変化に備えてアプリケーションを準備する必要があります。 インターネットトポロジで何かが変更され、ユーザーは次の要求を別のサイトに送信します。



別の古典的な技術は、 ジオロケーションとDNSの使用に基づいています 。 ポイントは何ですか？







静的コンテンツをDNSに送信するサービスの名前を要求するMuscoviteは、応答としてモスクワのIPアドレスを受け取り、モスクワのサイトに送信されます。 同様のリクエストを行ったノボシビルスクの居住者は、ノボシビルスクのサイトのIPアドレスを受け取り、そこに送信されます。



このアプローチの利点は、高度な制御です。 ヴォロネジの居住者を選択したサイトに送信する上記のタスクは、非常に簡単になります。 データベースを編集するだけです。 しかし、このアプローチには欠点もあります。 まず、通常、このアプローチでは、GeoIPなどの位置情報データベースが使用され、地理的な近接性はこのサイトへの最速の接続を意味しません。 第二に、このアプローチでは、インターネット上のトポロジの変更を考慮していません。



Odnoklassnikiにはもう1つのタスクがありました。「Odnoklassnikiへのトラフィックを無料で」などのプロジェクトを立ち上げたかったからです。 つまり、たとえば、パートナーのモバイル接続を選択した場合、Odnoklassnikiモバイルアプリケーションで行うすべての操作はトラフィック消費として考慮されません。 このようなタスクを達成するために、CDNには、パートナーが見たいサイトにそれらのネットワークのみを送信できる機能が必要でした。



このタスクの従来のソリューションは適切ではありません。 私たちは何をしましたか？







CDNサイトで、BGPサーバーはプロバイダーのルートサーバーとの接続を確立し、プロバイダーが見たいネットワークのリストを受信します。 次に、プレフィックスのリストがGSLB DNSに送信され、DNSクエリを処理するユーザーが必要な場所でIPアドレスを取得します。 もちろん、このサイトはすべてのコンテンツをメインのデータセンターから取得します。







サーバー間のサイト内では、かなり単純なアプローチを使用してバランスを取ります。 各サーバーには独自のIPアドレスがあり、両方のIPアドレスはDNSクエリによって提供されます。 したがって、ユーザーはサーバー間でほぼ均等に分散されます。 サーバーの1つが同じVRRPプロトコルを使用して失敗した場合、IPアドレスは別のノードに透過的に転送されます。 ユーザーは何も気付かないでしょう。







もちろん、すべてのサイトのチェックを実施しています。 サイトがOKステータスを返すのを停止した場合、IPアドレスの提供を停止します。 この場合、ノボシビルスクのユーザーはモスクワのデータセンターにアクセスします。 少し遅くなりますが、動作します。



CDNサイトでは、このnginxに加えて、ビデオ、音楽、写真用に社内で開発されたアプリケーションを使用しています。 私たちのアプリケーションに適用される最適化の主なポイントに言及したいと思います。 重いコンテンツを配信する複数のサーバーがあると想像してください。 ユーザーが1つのサーバーにアクセスし、このコンテンツを要求します。 コンテンツはありません。 次に、サーバーはモスクワのサイトからこのコンテンツを取得します。 しかし、次のユーザーが同じコンテンツのために2番目のサーバーにアクセスするとどうなりますか？ サーバーが同じコンテンツをモスクワに再度アクセスすることは望ましくありません。 そのため、まず、彼は近隣のサーバーにアクセスし、そこからコンテンツを取得します。

未来

私たちが行うことに非常に興味を持ち、実装することに非常に興味を持ついくつかのプロジェクトについてお話したいと思います。



たとえば、 www.odnoklassniki.ru



などの各サービスを1つのIPアドレスで引き続き使用したいと考えています 。 何のために？

• データセンターに障害が発生した場合、ユーザーにとってはすべてが透過的になります。
• DNSを提供しなくなったにもかかわらず、出力サイトのIPアドレスを提供し続けるDNSの不正な動作に関する問題を取り除くことができます。
• TTL時間に1回（つまり、この場合は5分に1回）、ユーザーは別のサイトに移動できます。

これは非常に難しい技術的な操作ではありませんが、それでもそれを取り除きたいと思います。 これは非常に野心的なプロジェクトであり、そのフレームワーク内で多くの問題を解決する必要があります。永続設定を提供する方法は？静かにサービス作業を行う方法は？データセンターを表示するには？最後に、イベントのこのような順番にアプリケーションを準備する方法は？これらの問題はすべて解決する必要があります。



別の興味深いトピック。これらは、ユーザー空間で動作するレイヤー4バランサーです。彼らの本質は何ですか？



実際、バランサーがLinuxネットワークスタックを使用する場合、バランサーはユーザースペースとカーネルスペースを常に切り替えます。これはCPUにとってかなり高価な操作です。さらに、ネットワークスタックLinuxはワンストップソリューションです。一般的なソリューションと同様に、この特定のタスクには理想的ではありません。ユーザースペースレイヤー4バランサーは、必要なネットワークスタック機能を個別に実装します。このため、噂によると、すべてが非常に迅速に機能します。



少し秘密をお伝えします。実際、パートナーの1つが私たちのために研究といくつかの改善を行っており、速度の大きな違いを私たち自身で見ることができました。



これらは、私がちょうど名前を付けた可能性のある将来の2つのプロジェクトです。実際、もっとたくさんあります。そしてもちろん、それらのほとんどは、負荷とフォールトトレランスのバランスだけでなく、他のトピックとも関連しています。







この道が私たちを導く場所を見てみましょう。私たちは新しい有力な同僚に会えることを常に喜んでいます。技術サイトにアクセスしてください。私の同僚のスピーチに関する多くの興味深い出版物やビデオがあります。



ご清聴ありがとうございました！





スピーチの最後の9分間で、Nikita Dukhovnyは聴衆からの質問に答えました。