Pandorama BigDataインフラストラクチャのアーキテクチャとそのデータを障害から保護する

Googleのマントラが「ワンクリックで世界中のすべての情報を検索する」のように聞こえる場合、ロシアの若いプロジェクトPandoramaのマントラは「クリックすることなく、興味のあるすべての情報を見つけます。」

Pandoramaアプリケーションは、読者が友人の「タグ」、「カテゴリ」、「いいね」を操作する必要なく、個人情報の好みに基づいて「無限の」パーソナライズされたニュースフィードをユーザーに提供します。 最初に、いくつかの面白いパンダに関するいくつかの質問に答える必要があります。次に、提案されたテープを読むだけです。 読んだニュースはシステムによって自動的に分析および処理されるため、将来的にはフィードにそのようなニュースが増え、ニュースは少なくなります。

Pandoramaはすでに世界中で4万人以上のユーザーを結び付けており、この数は常に増加しています。 この記事では、 Veeam Backup＆Replication Cloud Editionを使用して構築された、24x7モードで動作するこのプロジェクトのBigDataインフラストラクチャ、フォールトトレランスを確保し、データを障害から保護するメカニズムについて説明します。

それでは、Pandorama Webサービスはどのように機能しますか？ 彼のロボットは毎日、ネットワーク上の多くのページをバイパスして、常に新しい情報を探しています（毎日約3万5千のソースが分析されています）。 見つかった各記事は独自の言語アルゴリズムを使用して処理され、その後、コンテンツに応じて「iPhone 5s」などの1つ以上のタグが自動的に割り当てられます。 エンドユーザーは、パンドラマシステムによって識別された個人的な興味に基づいて編集されたパーソナライズされた記事フィードを受け取ります。 Pandoramのプロジェクトは元々、創立者によって国際的に大衆市場向けに計画されていたため、ニュースフィードの言語として英語が選択されました。

図1. Pandoramaの登録ウィンドウ

Pandoramaは現在、30台以上の仮想マシン（VM）が展開された4台の専用物理サーバーをレンタルしています。 スケーラビリティとフォールトトレランスを提供するために、次の一連のテクノロジが適用されます。

• イーサネットネットワーキング（LACP）
• Web負荷分散（HAProxy）
• ネットワーク接続バランス（DNSラウンドロビンとNLB）
• 画像と静的リソース（CDN）の地理的に分散したキャッシュ
• シャーディングとミラーリングを含むNoSQL（MongoDB）
• SQLミラーリング
• Veeam Backup＆Replication Cloud Editionを使用したVMレプリケーションとVMバックアップのローカルおよびクラウドへのバックアップ

詳細については、以下で説明します。

パンドラマインフラストラクチャ

他のスタートアップと同様に、Pandoramaの予算は非常に限られているため、チームはインフラストラクチャを含め、あらゆるものに可能な限り効率的にお金を投資しようとしています。 最初に、いくつかのホスティングオプションが検討されました。 まず第一に、彼らはアマゾンについて考えました、しかし予備的な計算はこのオプションが高すぎることを示しました。 一般に、多くの場合、アーキテクチャが小さく複製されたモジュールで構築されている場合、Amazonは良い出発点です。 ただし、Pandoramaの場合、このスキームは機能しませんでした。プロジェクトインフラストラクチャには、言語分析に関与するいくつかの「重い」サーバーが含まれています。 ここでは、大量のメモリと高速ディスクが重要であり、そのような仮想マシンのレンタル（追加のフォールトトレランス手段を考慮に入れた）は、Pandoramaにとって高すぎます。 別のホスティングオプションは、独自のVMをインストールして物理サーバーをレンタルすることです。 このパスは、価格により適していることが判明しました。

現時点では、現在の物理レベルでは、パンドラマは次のインフラストラクチャです。

図2. Pandoramaインフラストラクチャの概略図-物理サーバーとネットワーク接続

システム全体は負荷の点でバランスが取れており、フォールトトレランスのために保存データの量に冗長性があります。 たとえば、VMの1つに障害が発生した場合、データは失われず、他のVMが負荷を引き継ぎます。 どこかでこれは、VMを複製することによって、どこかでVM内のアプリケーションによってデータを複製することによって達成されます（たとえば、MongoDBの場合）。 既に述べたように、Pandoramaインフラストラクチャには単一のストレージ（高価）はありませんが、すべてのVMは物理サーバー間でバランスよく分散されます。

4つのホストにはそれぞれ128 GBのRAMと2つのXeon E5-2670プロセッサが搭載されています。 ハイパースレッディングを使用すると、32個のvCPUが取得されます。 クイックアクセスを必要としないVMおよびデータをホストするためのSATA-10のRAID-10アレイ。 アクティブなI / Oを備えたVMの場合、SSDの配列。 SSDの寿命を延ばすために、Pandoramaのアーキテクトは、ゲストOSファイルシステムがハイパーバイザーを介してTRIMと連携するようにしました。 もちろん、ドライブ自体のステータスも定期的に確認する必要があります。

各サーバーには（KVM Over IPに加えて）4 x 1GbイーサネットNICがあるため、インフラストラクチャ内に2つのネットワークを編成することにしました。 ホスティングプロバイダーのインフラストラクチャを介した外部ネットワークは、ギガビットチャネルを介してインターネットに接続され、内部は分離されています。 同時に、各ネットワークでLACPを使用して2 x 1Gbが1つの論理接続に結合されます。 内部ネットワークと外部ネットワークを分離することにより、外部「クライアント」トラフィックに対する内部サービストラフィックの影響を便利かつ簡単に排除できました。 また、LACPは同時に（インターフェイス間でTCP接続のバランスをとることにより）パフォーマンスを改善し、チャネルの冗長性を通じてフォールトトレランスを改善します。

論理的にPandoramaインフラストラクチャは、3つの独立したブロックに分割できます。

図3.「モジュール別」のPandoramaインフラストラクチャの概略図

コンテンツ配信コア。 このブロックのワークロードは、回避する必要のあるソースの数（現在では1日あたり約35,000）と、処理する必要のある記事とテキストの数に依存します。 このブロックは、サイトでのユーザー負荷の影響を受けません。 逆に、ユーザーと対話するフロントエンドでは、配信の問題は発生しません。 これらの部分は分離されています。 3番目のブロックであるバインダーは、データを送信して保存します。

Pandoramaは、テキストやグラフィックの収集と処理にさまざまなメカニズムを使用しています。たとえば、

• 無関係なコンテンツを除外して記事をクロールする（ getpocket.comまたはreadability.comに類似）
• 記事の自動タグ付け：これは「ケーキ」に関するものであり、これは「カメラ」に関するものです
• 類似の記事または二重画像の検索

約40のサービスがコンテンツ配信で機能し、そのうちのいくつかはコンピューターベースのトレーニング方法が使用されます（これは別の記事のトピックです:)。 デリバリサービスは、比較的独立して機能するユニットにパッケージ化されます（特定の構成で約40のサービスを含むVMになります）。 さらに、これらのユニットは異なるホストに複製されるため、配信のスケーラビリティと耐障害性が保証されます。

データコアについて少し。 ストレージを必要としない中間データは、RabbitMQバスを介して送信されます。 このタイヤは軽くて気取らないです。 RabbitMQには、いくつかのフェールオーバー機能があります。 メッセージキューをトランザクション対応にすることができます。 それぞれがディスクに強制的に保存されます。 キューミラーリングを使用してクラスターをセットアップできます。 Pandoramaの場合、これらのメカニズムは冗長であることが判明したため、コールドコピー、つまり、隣接ホスト上のRabbitMQからのVM​​のレプリカが作成されました。これは、メインVMの動作が停止すると開始されます。

もう1つはデータベースです。 メインデータベースはMongoDBです。 生産性と信頼性を向上させるために、 シャーディング 、 ミラーレプリカ 、およびバックアップが使用されます。これについては以下で説明します。 1つの問題点は、拡張性の低いSQLデータベースです。 実際のところ、パンドラマにはまだMongoDBで動作するように変換されていないコードがたくさんあります。 そのため、場合によってはSQLが使用され、そのフォールトトレランスはホットリザーブ（ミラーリング）によって実現されました。

そして今、ユーザーが対話するものについて-フロントエンド。

図4.カスタマイズされたPandoramaテープの例。

ここでは、信頼性とパフォーマンスを向上させるために、さまざまなテクノロジーが使用されています。 Webサーバーの2つのクラスターがあります。

• 最初のクラスターはユーザーにサービスを提供し、ユーザーの個人コンテンツフィードを生成します。 障害保護と負荷分散は、HAProxyを使用して実行されます。 同時に、HAProxyインスタンス自体が障害ポイントにならないように、それらのいくつかはDNSラウンドロビンが構成されてデプロイされます。 これは、ユーザーがリストからランダムなIPアドレスを選択したときに機能する古き良きチューブテクノロジーです。 これにより、専用のバランサーなしで負荷を分散できますが、ユーザーセッションはどうですか？ この問題はHAProxyによって解決されます。HAProxyは、クラスターのどのWebサーバーが現在のユーザーにサービスを提供しているかを認識しています。
• 2番目のクラスターは、ユーザーセッションの概念がない静的コンテンツを配信するように設計されています。 これはDNSラウンドロビンが役立つ場所ですが、残念ながら、 Pandoramaで使用されるCDNはまだこのテクノロジーをサポートしていないため、 NLBはPandoramaで構成されています。

CDNについて一言。 画像アップロードのトラフィックは、パンドラマを使用した他のすべてのトラフィックよりも何倍も大きくなります。 PandoramaはCDNとしてCloudFlareを使用します。 いくつかのコメントを除き、このサービスは完全に満足しており、トラフィックの85％以上を節約できます。

パンドラマクラッシュデータ保護

データ保護とフォールトトレランスの問題は、サービスインフラストラクチャの設計段階でも発生しました。 フォールトトレランスの観点から、システムは、1台の物理サーバーに障害が発生した場合、残りの3台が自身の負担になるように構成されました。 障害からのデータ保護の観点から、 Veeam Backup＆Replication Cloud Editionは、主要な稼働中の仮想マシンの近隣ホストへのバックアップとレプリケーションを通じてインフラストラクチャの仮想部分を保護します。

パンドラマのデータ保護はどのように調整されますか？

図5.パンドラマのデータバックアップの原理

1. VM内のアプリケーションが組み込みの方法でレプリケーションを許可する場合、この機能が使用されます。 たとえば、これはMongoDBとSQLがミラーリングされ、Webクラスターのイメージキャッシュが同期される方法です。
2. これが不可能な場合、たとえばRabbitMQ VMのように、VM全体が4時間に1回複製されます。
3. レプリケーションに加えて、完全バックアップと差分バックアップが必要です...アプリケーションで組み込み機能を使用してバックアップできる場合、たとえば、SQLの場合やWebサーバーログを個別のファイルとして保存する場合などに使用できます。
4. それ以外の場合は、VM全体のバックアップが作成されます。 たとえば、Pandoramaコマンドは、受け入れ可能なバックアップソリューションがない場合にMongoDBから取得されます。
5. 週に一度、VMバックアップがAmazon Glacierクラウドにアップロードされます。 さらに、Veeam Backupの重複排除と圧縮により、バックアップのサイズが140GB（元のVMのサイズ）から10GBに削減されます。
6. 他のバックアップもクラウドに送信されます。 Veeamは、仮想環境でバックアップを作成するだけでなく、Pandoramaで他のファイルをクラウドにアップロードするためにも使用されることに注意してください。

実際、データ保護の観点から、Pandoramaは3-2-1バックアップルールを正常に実装しました。データコピーは、少なくとも3つのコピー（ソースデータ、ローカルレプリカ、クラウド内の1つのコピー）、2つの異なる物理環境（ローカルにディスク上）クラウドで）、1つのコピーがオフィスから取り出されました。

回復試験

バックアップからのリカバリのテストの関連性については、 この記事の前半で説明しました。 Pandoramaチームは、さまざまな「クラッシュ」の後、システムの復元テストを実施しています。

次のシナリオが考慮されます。

• 1つのVMまたは物理サーバーを無効にします。 チームは、VMを次々に、またはホスト全体を切断するなど、さまざまなイベントをエミュレートし、これがシステム全体にどのように影響するかを観察しました。 同時に、ユーザー負荷シミュレーションが行われていました。 テストにより、後で修正される特定の問題が明らかになりました。
• データセンター全体が焼失しました。 このようなイベントが発生した場合のデータ保護は、Amazon Glacierの単純なバックアップです。 これは最悪のシナリオであり、Pandoramaにとっては、数日以内にシステムの回復が行われることは許容されます。 なぜそう そのような事故からのより低いRTOでの保護は、スタートアップが負担できる以上の費用がかかるため、これは必要ありません。

おわりに

Pandoramaプロジェクトの例は、大量の非構造化データ（BigData）を保存し、それを保護すること、システムフォールトトレランス、およびインターネットサービスへの多数のユーザーの同時アクセスを提供するソリューション-すべてが比較的簡単に、機能的に、高価ではないことをもう一度証明します。

便利なリンク：

• パンドラマ （英語）
• バックアップルール3-2-1
• ホワイトボードロシア！ 仮想化をゼロから （ビデオ、期間1:27）
• 安全な仮想環境の10の原則 （ビデオ、期間1:20）
• 数百の仮想マシン：データ保護ガイドライン
• VMwareを監視するための10のベストプラクティス
• 10億番目の会社を始める場所

著者：Maria Levkina（Veeam）[ vMaria ]、Konstantin Pichugov（Pandorama）、Alexander Shirmanov（Veeam）[ sysmetic ]