The Clouds on Zeppelin：クラウドサービスMail.Ru Groupの作成経験

2012年6月にMail.Ru Cloudの作業を開始しました。1年半の間、最初のプロトタイプから60 Gb / sを超える負荷に耐えることができる公共サービスまで、長い困難な道のりを歩んできました。 今日は、それがどのようにあったかについての話をあなたと共有したいと思います。

どうやって始まったのか覚えていますか

すべては、1つの開発仮想マシンから始まり、その仮想マシン上でメタデータストレージデーモンの最初のプロトタイプが起動されました。 その後、すべてが透明でした。 各ユーザーのアクション（ディレクトリの作成、ファイルの作成、ファイルの削除など）のログを保持し、その結果、仮想ファイルシステムの最終状態に至りました。 ファイルの本文は、すべてのユーザーに共通のディレクトリに保存されていました。 2週間で膝の上に書かれたこのシステムは、数ヶ月間機能しました。

メタデータサーバー

プロトタイプは、メタデータを保存するサーバーを作成したときに食料品版に近づきました。 キーは12バイトのツリー識別子であり、値は個々のユーザーのファイルとディレクトリの階層です。 このツリーを使用して、ファイルシステムがエミュレートされます（ファイルとディレクトリが追加および削除されます）。 サービスと通信するために、最初のクライアントはバイナリセッション指向プロトコルを使用しました。TCP接続が確立され、2つのクライアントが同期できるように変更の通知が行われ、クライアントはこのサポートされた接続にコマンドを書き込みました。 このプロトタイプは数か月間機能しました。



もちろん、クライアントはサーバーへの一定のTCP接続を維持する余裕がないことを完全に理解しました。 さらに、その時点では認証がありませんでした。クライアントを信頼していました。 開発には適していましたが、本番環境にはまったく受け入れられませんでした。

HTTPラッパー

次のステップでは、バイナリプロトコルを構成する個々のパケットをHTTPヘッダーでラップし、HTTP経由でサーバーと通信を開始し、クエリ行でどのツリーを使用するかを指示しました。 このラッパーは現在、メタデータサーバーへのTCP接続をサポートするNginxモジュールを使用して実装されています。 サーバーはHTTPについて何も知りません。



もちろん、そのような解決策はまだ承認チェックを提供しませんでしたが、クライアントはすでに実際の条件に近い条件で作業することができました。たとえば、短期間の切断では、すべてが無駄になりませんでした。



また、この段階で、サードパーティのHTTP通知機能の必要性に直面しました。 Nginx HTTPプッシュモジュール（これは通知用のCometサーバーです）を取得し、メタデータサーバーから通知を送信し始めました。



動作しなかっただけでなく、Cometサーバーのクラッシュと再起動が正常に発生し始めたとき、次の段階に進みました。

ログイン

次のステップは、サーバーとクライアントの両方での承認の導入でした。 Nginx、同様のアクションを実行するモジュールのソースコード、および承認とセッション検証のための内部インターフェイスを操作するためのマニュアルを備えて、承認モジュールを作成しました。 入力で実装されたモジュールはユーザーのCookieを受け取り、出力でこのユーザーの識別子を計算し、電子メールを受け取り、他の有用なアクションを実行しました。



メタデータサーバーを使用する場合と通知サーバーを使用する場合の両方で承認が機能しました。

ローダー

Nginx DAVモジュールはファイルの読み込みに取り組み、ハッシュ付きのファイルを受け取り、1つのディレクトリにローカルに配置しました。 その時点では、何もバックアップされておらず、最初のドライブアウトまですべてが機能していました。 それ以来、それは閉じられた内部テストとはほど遠いものであり、システムは開発者自身によってのみ使用されていたため、このオプションは受け入れられました。 もちろん、完全にデフォルトのトレラントスキームで運用を開始しました。現在、各ユーザーファイルは、異なるデータセンター（DC）の異なるサーバー上の2つのコピーに格納されています。



2012年11月までに、ユーザーディレクトリの階層だけでなく、それが格納するコンテンツも重要であるという事実から私たちがもはや振り返ることができない日が来ました。



ブートローダーの信頼性と機能性を高めたいと考えていましたが、同時に非常にシンプルであるため、ディレクトリ階層とファイル本体の間に華麗な織りを構築しませんでした。 ローダーのタスクを次のように制限することにしました：着信ファイルを受け入れ、ハッシュを計算し、2つのバックエンドに並行して書き込む。 このエンティティローダーを呼び出しましたが、それ以降、その概念はあまり変わりません。 Loaderの最初の実用プロトタイプは2週間で書かれ、1か月後に完全に新しいブートローダーに切り替えました。



彼は、ファイルを受信し、ハッシュを読み取り、フロントエンドのローカルハードドライブにファイルを保存せずにストアに送信する、必要なすべての方法を知っていました。



たとえば、ギガバイトの映画が即座にクラウドにあふれたという絶賛のレビューを得ることがあります。 これは、クライアントアプリケーションがサポートするアップロードメカニズムによるものです。アップロードする前に、ファイルのハッシュをカウントし、クラウドにそのようなハッシュがある場合はローダーに「尋ねる」。 いいえ-アップロード、はい-メタデータを更新します。

ツェッペリン：Python vs C

ローダーの作成中に、最初に、1つのメタデータサーバーでは、オーディエンス全体が十分にアクセスできないことを認識しました。 第二に、メタデータも重複して存在していると便利です。 第三に、Nginxモジュール内の目的のメタデータサーバーにユーザーをルーティングする必要はありませんでした。



解決策は明白なように見えました：デーモンをPythonで記述してください。 誰もがそれを行います。流行であり、人気があり、最も重要なのは、迅速です。 デーモンのタスクは、ユーザーが住んでいるメタデータサーバーを見つけ、そこにすべてのリクエストをリダイレクトすることです。 データサーバーでユーザールーティングを行わないために、Twistedにレイヤーを作成しました（これはPythonの非同期フレームワークです）。 しかし、Pythonを調理する方法がわからないか、Twistedブレーキがかかっているか、またはその他の不明な理由がありますが、このことは1秒あたり1,000を超えるリクエストを保持していません。



それから、ハードコアな人として、Metadフレームワークを使用してCで記述することを決定しました。これにより、非同期コードを同期的に記述することができます（ 状態スレッドのように見えます）。 Zeppelinシステムの最初の動作バージョン（連合チェーン-飛行船-Zeppelinがこの名前を選択するよう導いた）は、1か月以内にテストサーバーに登場しました。 結果は非常に期待されていました。利用可能な1秒あたり1.5〜2000件の要求は、プロセッサ負荷がほぼゼロで簡単かつ自然に処理されました。



Zeppelinの機能は時間の経過とともに拡大し、今日ではMetadでのリクエストのプロキシ、Webリンクの操作、Metadとfiledb間のデータの調整、および承認を担当しています。

サムネイルジェネレーター

さらに、サムネイルを表示するようにCloudに指示したかったのです。 サムネイルを保存するか、その場で生成し、一時的にRAMにキャッシュするという2つのオプションを検討し、2番目に解決しました。 ジェネレーターはPythonで作成され、GraphicsMagickライブラリを使用します。



最大速度を確保するために、ファイルが物理的に配置されているマシンでサムネイルが生成されます。 多くのストーリーがあるため、サムネイルの生成にかかる負荷はほぼ均等に「分散」し、私たちの感覚によると、ジェネレーターは非常に高速に動作します（16,000 x 16,000ピクセルのファイルが要求される場合を除きます）。

最初のストレスフェーズ：クローズドベータ

私たちの決定の真剣なテストは、クローズドベータテストの開始でした。 ベータは人々のように始まった-予想よりも多くの人々が来て、彼らは予想よりも多くのトラフィックを作り出し、ディスクの負荷は予想以上だった。 私たちはこれらの問題を英雄的に戦い、1年半から2か月の間に多くの問題を克服しました。 すぐに10万人のユーザーに成長し、10月に招待を削除しました。

第2ストレスフェーズ：一般公開

2番目の主要なテストは公開リリースでした。ディスクの問題が返され、再度解決しました。 やがて興奮は薄れ始めましたが、それから新年が明け、私たちはテラバイトを全員に配ることにしました。 この点で、12月20日は非常に明るいことがわかりました。トラフィックはすべての予想を上回りました。 当時、約100のストーリーがあり、そこには約2,400個のディスクがありましたが、個々のマシンへのトラフィックはギガビットを超えていました。 合計トラフィックが60 Gbpsを超えました。



もちろん、これは予想していませんでした。 市場の同僚の経験に基づいて、1日あたり約10 TBが注がれると想定できます。 ピークがすでに眠っている今、私たちの国では100 TBが注がれ、最もストレスの多い日に150 TB /日に達しました。 つまり、10日ごとにペタバイトのデータを処理します。

プロパティの説明

そのため、現時点では以下を使用しています。



●自己記述データベース。 なぜ独自のベースを書く必要があったのですか？ 最初は、多数の安価なマシンで実行したかったため、開発中に、RAMのすべてのバイト、プロセッサーのすべてのクロックサイクルで戦いました。 JSONを格納するMongoDBのような既存の実装でこれを行うと、バイナリパックされていても素朴になります。 さらに、ユニコードの大文字変換、ファイル操作の実装など、特定の操作が必要でした。



これは、既存のnoSQLデータベースを拡張することで実行できますが、この場合、vfsロジックを既存の強固なコードベースに追加するか、組み込みのスクリプト言語を介してサーバー機能を拡張する必要があります。



従来のSQLデータベースでは、ツリー構造の保存はあまり便利ではなく、非常に非効率的です。ネストされたセットはデータベースを更新します。



Tarantoolにすべてのパスを文字列として保存することは可能ですが、これは2つの理由で不利です。 まず、明らかにすべてのユーザーをRAMに収めることはできません。Tarantoolはそこにデータを保存します。 次に、完全なパスを維持すると、大きなオーバーヘッドが発生します。



その結果、既存のすべてのソリューションでは、ファイルの集中的な改良が必要であるか、リソースの面でかなり貪欲であることが判明しました。 さらに、それらを管理することを学ぶ必要があります。



それが私たちが自転車を書くことにした理由です。 それは非常にシンプルで、私たちが必要とするものを正確に実現しました。 既存のアーキテクチャのおかげで、たとえば、過去のある時点でユーザーのメタデータを見ることができます。 さらに、バージョン管理ファイルを実装できます。



●Tarantoolキー値ストレージ



●Nginxは広く使用されています（ロシアのすばらしい開発、拡張機能を作成するまでは理想的です）



●Mail.Ru Imagineの内部開発用の古い通知機能は、一時的に基礎として使用されます



●3000を超えるディスクペア。 ユーザーファイルとメタデータは、異なるマシンの2つのコピーに格納されます。各マシンには、2 TBまたは4 TBの容量を持つ24個のディスクがあります（すべての新しいサーバーは4 TBドライブでセットアップされます）。

予期しない発見

各リクエストの詳細なログを作成します。 問題を特定して分析するためのさまざまなグラフを作成するアナライザーを作成する別のチームがあります。 グラフはグラファイトで表示され、さらにレーダーやその他のシステムも使用します。

クラウドの使用方法を調査して、いくつかの興味深い発見をしました。 たとえば、クラウドで最も一般的なファイル拡張子は.jpgです。 これは驚くことではありません-人々はfotochkiが大好きです。 さらに興味深いことに、トップ10の人気のある拡張機能には.phpと.htmlが含まれます。 そこに何が保存されているのかわかりません-コードベースまたはホスティングのバックアップですが、事実は残っています。



更新されたMODが表示され、人気のあるオンラインゲームの更新用にリリースされた日にトラフィックが大幅に増加していることに気づきます。 数日のうちに、これらの更新プログラムをダウンロードするために最大30％の訪問が行われるようになりました。

質疑応答

あなたが尋ねたいと思うかもしれない質問のリストについて考えました。



HTTP拡張機能はどうですか？

HTTPプロトコルをどこにも拡張していません。 クラウドの開発を開始したとき、すべてがHTTPSを使用しないオープンデータチャネルで機能していました（もちろん、クライアントとサーバー間のすべてのトラフィックの完全なSSL暗号化を使用して本番環境に入りました）。 そのため、誰かが見出しに何かを引き付けたいと思ったとき、すべてのカスタムヘッダーをカットするワイルドプロキシの脅威がすぐに彼を打ち負かしました。 したがって、必要なのはURLまたは本文に集中することだけです。



ファイル識別子として使用されるものは何ですか？

私たちのファイル識別子はSHA-1です。



サーバー全体またはクラウドのデータセンターが「カバー」されると、ユーザーデータはどうなりますか？

すべてが私たちにとって完全に寛容であり、サーバーまたはDC全体の障害がユーザーの作業にほとんど影響を与えません。 すべてのユーザーデータは、異なるDCの異なるサーバーに複製されます。



今後の予定は？

当面の開発計画では、WebDAVを起動し、すべてをさらに最適化し、すぐに学習する多くの興味深い機能を最適化します。



何かを見逃した場合は、コメントで答えようとします。