検索クラウドの課題。 Yandexでの講義

インターネット企業は、製造業者から受け取った名目上の仕様だけでなく、この機器で実行される実際の生産タスクも考慮して、データセンター用の機器を選択してテストします。 次に、データセンターの設計、構築、および起動が完了したら、演習が行われます。サービスの知識がなくてもノードがオフになり、そのような状況にどのように準備されているかがわかります。 実際、このような複雑なインフラストラクチャでは、完全なフォールトトレランスを実現することは不可能です。 ある意味では、理想的なデータセンターは、Yandex検索などのサービスを損なうことなくオフにできるものです。





ランタイム検索試験チームの責任者であるOleg Fedorovは、8月上旬に開催されたYandexの大規模検索会議の講演者の一人でした。 彼は、膨大な量のデータの処理に関連するタスクのためにデータセンターを設計するすべての基本的な側面について話しました。 カットの下-Olegのデコードとスライド。



私の名前はオレグです。私は6年間Yandexで働いています。 私は検索品質部門のマネージャーとしてスタートしましたが、今では大規模なデータセンターの運用に関連する問題に関心があります-検索が機能することなどを確認しています。



検索、その他のサービスなどで応答できる10万台の小さなデータセンターを投機的に設計してみましょう。これは非常に単純に、投機的に上部で行います。



検索クラウドの課題。 私たちは何に直面していますか？ 大規模システムを構築するとき、どのような原則に従いますか？







すべての劇場がハンガーから始まるように、サーバーを設計するプロセッサー、これが機能する機器、それがいくらになるかなど、データセンターの構築を開始することができます。このため、3つの簡単な手順を試してみます。 。 機器をテストしたい。 そのような機器を所有するのにどれくらいの費用がかかるかを計算したいと思います。 どういうわけか最適なソリューションを選択したいと思います。 注目を集める画像：







近い将来、データセンターを構築するために、私たちにとって興味深いプロセッサを選択し、1年半の準備ができています。事前にエンジニアリングサンプルを入手する必要があります。 多くの人がこれを知っているのは、大衆市場に出る前に機器をテストしたからです。



どのようにテストしますか？ サーバーで最も頻繁に動作するクラウドの典型的なタスク、検索、インデックスの一部、出力が引き出すもの、他のことを見てみましょう。 これらすべてのサンプルを取り、異常を探しましょう。



鮮明な例がありました。あるメーカーのプロセッサモデルを使用し、描画時間を大幅に短縮しました。 サプライズ 実際、コンパイラに問題がありましたが、それでも異常が発生する可能性があります。 別の例：メーカーが新しいSSE命令のセットを発表し、コードを少し書き直しました-それはずっと速くなりました。 これは私たちのモデルの特定の競争上の優位性です。すべてが順調です。



もう少し詳しく見ていきましょう。 特定のプロセッサセットを選択したとします。 注目を集める私のお気に入りの写真を以下に示します。 これは最近過熱した私のiPhoneです。







地理的な場所。 データセンターは、ロシアのロシア企業向けに構築することも、ロシア以外の国に構築することもできます-さまざまな国、さまざまな気候および地理的ゾーン。 たとえば、赤道では暑いですが、太陽光を使用できます。 北部では、電気ではますます困難になりますが、冷却ではすべてが非常に優れているなどです。どこにでも賛否両論があります。



データセンターのサービスについて考える必要があります。 寒冷地や、予測できない管理リソースがある奇妙な国にコンポーネントを配送することは困難です。 一部のコンポーネントは非常に困難な場合などにのみ入手可能になります。



各プロセッサのインフラストラクチャの残りを計算してください。 160ワットの熱を放出するプロセッサを使用する場合、おそらく冷却について考える必要があります。より強力なヒートシンク、より強力なサーバーが必要です。



この場所で業界はどこに向かっていますか？ 私たちは、他の皆と同じように、外気で冷やしていきたいです。 通りの外の気温を取り、サーバーを吹き飛ばし、冷却します。 したがって、最終的な計算にはできるだけ多くのエネルギーを使用し、サービスインフラストラクチャにはできるだけ少ないエネルギーを使用するようにします。



多くの人々が知っている：PUE係数があり、誰もが統一のために努力しています。 プロセッサが標準操作を実行する準備ができている量を計算し、所有コストを概算すると仮定します。 プロセッサの名前を具体的に暗号化しました。これらはすべて推測的な数字です。 一般的なアプローチは何ですか？ 原則として、すべてが最高のパフォーマンスを備えたプロセッサが少し先に進み始め、コアパフォーマンスを備えたソリューションの条件付き所有コストが指数関数的に増加するように見えます。 Optimaは道路沿いのどこかに住んでいます。







このルールには常に例外があります。 カーネルで最大のパフォーマンスを得るために待ち時間が非常に重要である一部の非質量アプリケーションが必要です。 または、オンラインで何かを集めたり、絵を描いたりすることもできます。例外的な機器の数パーセントを購入する余裕があります。



他の側面を見てみましょう。 プロセッサ、メモリ、SSD、ディスク、ネットワーク、未発見の測定値など、非常に複雑な多次元空間があります。 私たちは常に拡大しています。 このすべてについて考える必要があります。 モデルは複雑で多次元であり、インターネットは徐々に変化しており、検索に対する私たちのアプローチは変化しています。 これらすべてをモデルに入れて、必ず計算してください。



注目を集める2番目の写真：







おそらく、多くの人が残存放射の分布を認識しました。これが、宇宙がどのように見えるかをコンピューターでシミュレートしようとする方法です。 データはほぼ同じに見えます。 非常にホットなパッチがあります。 たとえば、VKontakteのWebサイトは何らかの理由で誰もが探しています-理由はわかりません。 またはいくつかの子猫。 このデータは非常にホットで、よく使用されます。プロセッサに近い場所のメモリなどに保存したいのです。そして、いくつかのドライバがあります。 私は約10年前に以前のラップトップを所有しており、そのために、古いUbuntuではドライバーが必要でした。 なんらかの理由で、私以外の誰もこのリクエストを長い間受けていません。 私はログを検索しようとしました-誰も興味がありません。 このデータは、おそらく誰にも必要ではありません-遠く離れた場所、小さな複雑な複製などを備えたコールドディスクに保存します。



幸いなことに、私たちはすべてを指数関数的に持っています。 最もホットなデータは不足しており、メモリに到達しようとすることができます。 そして、最も面白くて不必要な韓国のスパムサイトはディスク上のどこかに置いて、それらを忘れることができます。







クラウド内のさまざまなアプリケーションの複雑な要件に関する図。 少し持っているアプリケーションを分類してみましょう。 アナロジーがあります：私は空の水槽を買いました、そこで魚を動かしたいのですが、その前にそこに美しさをもたらす必要があります-大きな小石、城、それだけです。 さらに、水槽には砂と水が必要です。 水を注ぐだけですべてを配置し始めると、汚れてしまい、石などを動かすのが難しくなります。



アプローチは次のとおりです。GPUなどの特定のハードウェアを必要とするクラウド内のアプリケーションを選択しましょう。 各サーバーにGPUを搭載することは夢ですが、かなり高価であることは明らかです。 特定のハードウェアを必要とするアプリケーションを、そのようなハードウェアが利用可能なサーバーに配置します。 これはステップ番号1です。



ステップ2：私たちは砂と主なアプリケーションを取り、しっかりとふるいにかけ、標準化します-彼らが消費するメモリの量、彼らが必要とするプロセッサの量、一日の時間、彼らが必要とするネットワークの量、彼らが自分自身にデータを配信する方法などを見つけます。たとえば、これらのアプリケーションは大規模で、どこでも実行できる状態にあり、要件を遵守することが重要であることを明確に計画および理解してください。



さらに、砂のある種の配置を行ったときに、典型的なバッチタスク（機械学習タスク）をすべての空き領域に埋めます。 私たちが知っているように、夜ロシアの人々のほとんどは眠ります。 したがって、検索で受信される要求が少なくなり、プロセッサが解放されます。使用したいと思います。 夜はバッチの全盛期であり、ユーザーの応答にあまり関係のないさまざまなタスクのルネッサンスです。



次のステップ。 アプリケーションをクラウドで計画しましたが、アプリケーション間の干渉をどのように回避できますか？ RAMとプロセッサの正しいボリュームを計画したオオカミが、このボリュームを正しく消費したことを確認する方法は？ 貧しい無邪気な子羊に害を及ぼさないようにするにはどうすればよいでしょうか。誰も何も消費すべきではありませんが、メモリリーク、リクエスト数の爆発を経験し、近隣のタスクをプロセッサであふれさせます。 国境、隔壁が必要です。







業界のアプローチは何ですか？ 誰もが聞きましたが、Linuxにラップトップを持っている人は、アプリケーションを保護するために何らかの方法でcgroupを設定し、アプリケーションに制限を設定し、多かれ少なかれすべてを改善しようとしました。



2番目の一般的なアプローチは何ですか？ 各アプリケーションを別々の仮想マシンで簡単に起動しましょう。 もちろん、オーバーヘッドが発生します。無料では何も起こりません。 より多くのプロセッサ、少しのメモリを消費します-実際には、メモリのページを数回カウントすることがあります。 多くの最新のソリューションはすでにこの影響を受けていませんが、特定のプロセッサが必要ですなど。



みんなは何に来ますか？ 小さな薄い層-アプリケーションを囲むコンテナ。



このストーリーをクラウドで開始したとき、Dockerはまだそれほど開発されていませんでした。 そのモダンなバインディングは印象的です-多くの作業が行われました。 とても似たようなことをしました。 彼らはポルトと呼ばれました。 数百-すでに数千-のアプリケーションを簡単に管理したかったので、互いに干渉しないように、構成プロセスが非常に単純であり、ある意味でアプリケーションのすべての制限を説明し、その動作方法、必要なもの、それがどこにあるかを理解しましたデータを保存する必要があります。このアプリケーションの専用IPアドレスは何ですか。 つまり、私たちを多次元空間と結び付けるすべてのものを記述し、このコンテナを起動して、それを忘れる必要がありました。



一方、アプリケーション自体の観点から見ると、実際には仮想マシン内にあります。 彼は自分の小さなchrootを持っており、すべてのプロセッサーとすべてのRAMが見えるわけではありません。 展開システムのシンプルさで利点を得、リソースアカウンティングを取得しました。 アプリケーション自体が内部で行うこと、起動するサブルーチン、データを処理することなどにはあまり関心がありません。このアプリケーションの周りで何が起こったか、つまりコンテナからのカウンターに関心があります。 また、別の素晴らしいボーナスとして、ネストされたサブコンテナを実行する機会がありました。 いくつかのタスクまたは問題に一連のリソースを割り当て、このコンテナに名前を付けました-それだけです。 さらに、アプリケーションは内部のスペースを何らかの方法で再配布し、サブコンテナも分離してサブプログラムを実行できます。 その結果、各コンパートメントが隔離された美しい潜水艦ができました。 誰かがどこかでリークを起こした場合、何かが爆発し、そこではローカルでのみ爆発しました。



そこで、すべてを分離し、すべてをクラスターで計画しました。 そして、アプリケーションインスタンスが機能する場所を見つける方法は？



発見の問題をどのように解決しますか？ いくつかのアプローチがあります。 最も典型的なものの1つは、アプリケーションが起動し、中心点のどこかでノックすることです。 私たちのアプローチはこれに非常に似ています。 監視システムと統合しています。 システムは、特定の種類のアプリケーションがマシン上で実行されていることを認識すると、その中に特定のメタ記述を保存します。 その後、他のアプリケーションが自身のバックエンドのリストを検索するときに、この説明を使用できます。







すべて順調です。 私たちは潜水艦に乗っていて、すべてが絶縁されている、などです。しかし、ここですべてが壊れ始めます。 私たちがタクシー隊で働いていると想像してください。 タクシーは100台あります。 常に次のようになります。1台の車が車輪を下げている、誰も別の車を運転できない、車輪がおかしい、などです。複数の車は常に壊れています。 アプリケーションの数パーセント、つまりシステムノードが常に壊れるという事実に慣れる必要があります。 これは、複製の計算、各ノードの負荷などの段階で設定する必要があります。



何が壊れるか？ あまり良くないバージョンのアプリケーションを書いた場合、もちろんクラッシュします。 特定の数のリクエストとクラッシュを処理します。 彼らはテストでそれを見つけられませんでした-彼らはそれをクラウドで見ました。 OSが壊れます。 実行時に何も影響を与えない、新しいスーパーセキュリティアップデートを見てみましょう。 それをリリースしましょう-カーネル内の何かにヒットしたため、アプリケーションが落ち始めます。 サーバーが破損します。 彼は2年間アップタイムで働き、すべてが素晴らしかったが、RAMは失われ始め、ディスクはドロップアウトし始めた。



データセンター内のサーバーはラック内にあります。 電源はラックに一元的に供給され、ネットワークはローカルに複数のワイヤで供給されます。 それはすべて失敗する可能性があり、故障します。 ラック全体が破損するという事実に備える必要があります。 インデックスまたはアプリケーションの非常に重要な部分は、クラウドであまり起動されず、1つのラックに置かれず、できるだけ汚れた状態で保存する必要があります。



数十または数百のラックが組み合わされてモジュールになります。 データセンターの耐火部分が形成されているため、誤動作が発生した場合、データセンター全体が破損することはありませんが、モジュールを絶縁できます。



しかし、全体としては、データセンターが壊れます。 年に何回、データセンターがネットワークを介して脱落し、通信チャネルが被害を受けると思いますか？



-...



-なぜ春なの？ いいえ、最新の光学系は非常によく伸縮しています。 春は正しいですが、なぜですか？ 種まき。 農業産業は目覚め、存在しない場所で光学を破壊し始めます。 ビルダーは目を覚まし、冬にはできなかった仕事を始めます。 春には、通信チャネルが被害を受けるなど。



事故の問題を分類してみましょう。 ここで、彼らは衛星を床に落とした、トラブル。







私たちのユニットの1つか2パーセント、機器が故障しました。 これは日常的なタスクです。私たちのタクシー隊では、1、2、3台の車が常におかしくなります。これに備えなければなりません。



深刻な問題は、ノードの5〜7％が故障している場合です。 おそらく、インフラストラクチャコンポーネントの一部のリリースは、期待どおりに動作しませんでした。 ネット上で何かを壊したのかもしれません。 この問題を理解する必要がありますが、それは重要ではありません-私たちのサービスは引き続き機能し、すべてがうまくいくのはインフラストラクチャのこの断片です。



災害-ノードの15〜20％が故障している場合。 ここで明らかに問題が発生しました。プログラムをリリースし、何かを展開し、再構成することは意味がありません。 負荷を取り除き、よりアクティブなアクションを実行する必要があります。 これは現実的な状況ではありません。 おそらく多くの人がこのアプローチに精通しているでしょう。







そのような場合に何ができますか？ 簡単なものから始めましょう。 私たちの車は故障しています。 彼らはちょうどプログラムで壊れることができます。 サーバーがハングします。 これを検出し、IPMI経由でこのサーバーと通信して、サーバーで何かを行うことができる必要があります。 モニタリングシステムの作業、トラブルシューティング、修正の試み、データセンターでのアプリケーションの作成、WALL-Eロボットに関する漫画として提示します。 このようなロボットはクラスター内を移動し、すべてを修正して、私たちに起こっていることを特定の中心点に報告しようとします。 したがって、最初のアプローチは自動修復です。



すべてが常に壊れているという事実に他にどのように対処できますか？ バックエンドの悲観化があります。 アプリケーションAがあり、アプリケーションBの10個のバックエンドに移動するとします。バックエンドの1つは、100ミリ秒の間、大幅に遅い応答を突然開始します。 このバックエンドを冷静に悲観し、多くのリクエストを要求し始めることができます-その状態を監視するために引き続き要求しますが、残りの9つの正常なバックエンドにリクエストを転送します。 何も起こりません-すべて順調です。 私たちは、アプリケーションがきちんとしていること、私たちの下にバックエンドがあり、何かが彼に起こったことを理解できることを教えます。



別のアプローチがあります。 付録Aは、予想よりもはるかに多くの付録Bへのトラフィックになりました。 その機能の一部を無効にして応答を開始できると便利です。おそらくかなり正確ですが、CPUの観点からははるかに低コストです。 たとえば、検索について説明している場合は、もう少し深く見てください。 私たちは1000のドキュメントを上げるのではなく、900のドキュメントを上げ、ゆっくりと境界線を押し進めます。 これは一種の目に見えませんが、本当に必要なときにスループットを大幅に向上させます。 これは劣化です。



深刻な災害がすでに発生している場合、理解できるステップは、負荷を分散し、取り除くことです。 データセンター全体を含むすべてのノードは、分離できる必要があります。 そこからトラフィックを取得してから、ノードを使用してサービスを提供する必要がある場合があります。



すべてのアプリケーションがこのスキームに従って機能し、動作し、設計されていることをどのように理解しますか？ 定期的な演習を実施する必要があります。ノードの電源オフ、多数のサーバーの電源オフ、データセンターの電源オフ。 これは、これらのアプリケーションのチームで予期せずに発生するはずです。そのため、負荷などを操作しているようなストーリーはありません。 それは正直な普通の事故であるはずですが、すべてを元の状態にすばやく戻すことができます。 春が来るのを待たずに、掘削機で運河の1つを移動します。 自分で無効にし、何が起こるかを確認します。 インフラストラクチャをカットします。何が起こるかを確認します。







ヒューストン、問題があります。 問題を、もはや日常的ではないポイント、つまり問題-5-7％または災害まで診断しました。 これに対処する必要があります。 典型的な検索エンジニアは何を見ていますか？ 現在、リリースまたはローンチはありますか？ おそらく、アプリケーションが数日から数週間機能し、すべてが順調だったのに、突然午後の1時に応答時間が短くなった場合、何かが変更されました。 おそらくリリース、打ち上げが行われました。



私たちは何を見ようとしていますか？ , . , , . 8:30 8:30 . 20% — , - .



. , , . . , , .



. , . , , , , , .



. . Netscape Navigator, , . . , . ? ? , ? . .



. , . , , , . , . .



. 15 , . . , . - . , , - — . — - .







. : 100 , 200 . . , . - . , . , . , , . , .



, . : , - , , , , , . — , .



, -, , , , , , , , .



:

— , ?



:

— , . , , - .



, :

— , . — , , . , . , - — .



:

— , Startup Makers. Google open source solution — Kubernetes. Porto. ?



:

— , , . . - - .



:

— , . , NIH — not invented here. , , . open source , .



Porto — , Docker. .



:

— Docker .



:

— , , , , . , , , — open source.



:

— , Kubernetes. , , , , Google. Service discovery — . , , , — ? , - etcd-, key value, - ?



:

— , , . . — -, , , . — push, call.



:

— , . . - ? ?



:

— . — . .



:

— Kubernetes Kube Dash, , - . そしてそれは動作します。 CoreOS, , . - UI- , AWS , , ?



:

— , . , . : , , , . .



UI . , , , UI . 100 , , , , . .



— , .



:

— , . : « , , ?» , , -, , .



:

— , .



:

— . , , «».



:

— , . . , , , . . , — ?



:

— , . , . . , .



:

— .



:

— . . … , . .



:

— , ?



:

— , .



:

— , . Porto. overhead Porto , ?



:

— Porto , - cgroups . cgroups — Porto.



:

— , « ». . , , ? , — , - , ?



:

— . , , , . .



, , . . , , - .



:

— . , - — - , - … , - , , , . -. .



:

— , , . , 24/7/365, - . - . .



:

— . - ?



:

— . : , . , - , - . : - - 90% , , , 90% - , - . .



:

— — . , , , : - , , , , , — - , . — - . , «». , . - , , - .



:

— . , , , SSD . : , SSD — , , — , .



:

— , « ». , ?



:

— . - , — . — , . .



, , , . — , 50% , , , , 50% .