今日は、クラウドコンピューティングとビッグデータの分野における典型的なタスクの1つと、TeamDevで見つかったソリューションへのアプローチについてお話したいと思います。
生物学的研究の結果の保存と分析に関与する企業の1つの公共サービスを開発する際、BigDataの問題に直面しました。 次の段階での顧客の目標は、そのようなデータの特定のセクションをリアルタイムで視覚化することでした。
タスクを形式化してみましょう。
初期データ：数万のファイル。各ファイルは、int型とfloat型のいくつかの関連する行列を表します。 1つのファイルのサイズはさまざまで、約2〜4 GBです。 すべてのデータはクラウドストレージにアップロードされることになっています。
戻り値：高解像度画像を作成するポイントのセット。 処理プロセスには、指定された境界を持つ配列の最大値の合計と検索が含まれるため、CPU時間をかなり積極的に消費します。 結果のサイズは、ユーザーからのリクエストによって異なります-50 KB〜20 MB。 1つの応答を形成するために最初に処理されるデータのサイズは、応答のサイズを30〜200倍超えています。 つまり、100 KBの応答を送信するには、約3〜20 MBを読み取って処理する必要があります。
要件：
- エンドユーザーがブラウザまたはデスクトップアプリケーションを使用してデータをナビゲートする機能。
- ユーザーの地理的位置に関係なく、アクセス速度は同じです。
- 水平スケーリングの可能性がある100人以上のユーザーの同時操作。
- 快適な作業速度での画像レンダリング-画像あたり最大500ms。
開始位置：
クラウドプロバイダーとして、顧客はAmazon S3を「エンドレス」ソースデータストアとして使用し、Amazon EC2を作業ノードのホスティングとして使用するAmazon Webサービスを選択しました。
ブラウザとデスクトップクライアントに画像を提供するフロントエンドは、Javaで記述されています。 Amazon EC2にあります。
データアクセス制御を含むビジネスロジックを定義するバックエンドは、Javaで記述され、異なるEC2インスタンスに配置されます。
データの記述部分（データが存在する場所、データが属するユーザー、データの内容）は、Amazon RDS上のMySQLにあります。
どこから始めますか？
問題を「真正面から」解決しようとしています！ ユーザーからの一連の要求を並行して処理する1つのアプリケーションを作成するとどうなりますか？ S3からデータを取得し、ポイントのセットである何らかの構造を与えるか、完成したイメージをレンダリングすることが提案されています。
一連の問題は明らかです。
- 平均応答サイズは4 MBです。 100の同時またはほぼ同時のリクエストの場合、結果の合計量は4 MBバイト* 100 = 400 MBです。 ソースデータのサイズが応答サイズを30倍以上超えています。 したがって、ストレージから少なくとも30 * 400 MBytes〜12 GBytesをほぼ同時に読み取り、最大で200 * 400 MBytes〜80 GBytesのデータを読み取る必要があります。
- 100の同時リクエストが存在し、それぞれの処理にプロセッサ時間が必要な場合、同等の量のCPUが存在することを示唆しています。
- Amazon S3とEC2インスタンス間の理論上の最大ネットワーク帯域幅は1 GB /秒、つまり125 MB /秒です。 つまり、[実験室の条件で] 12 GBのデータでも読み取るには、約12 * 1024/125〜98秒かかります。
- 1つのインスタンスで、惑星のさまざまな部分のユーザーに同じ速度でサービスを提供することはできません。
Amazon EC2では、さまざまなサイズのインスタンスを作成できますが、最大サイズであるd2.8xlarge（36 x Intel Xeon E5-2676v3、244 GBのRAM）は、1番と2番の問題のみを解決します。 問題No. 3-データをダウンロードする時間-結果を返す予想速度よりも2桁高い。 さらに、このようなソリューションのスケーラビリティはゼロになる傾向があります。
解決策はありますか？
Elastic MapReduce
このような問題を解決するために、AWSはクラウドベースのElastic MapReduceを提供します。これは、ホストされたApache Hadoopとも呼ばれます。 その助けを借りて、クラスターのノード間で負荷を分散するために発生するすべての問題を克服することができます。 ただし、このオプションでは新しい問題が表示されます。
- Hadoopタスクの開始速度-秒。 これは、必要な応答時間よりも数倍遅いです。
- クラスターを予熱し、選択したデータをS3からHDFSにダウンロードする必要。 これには、負荷を分散するためにクラスターを操作するための戦略を選択するために、追加の身体の動きが必要です。
- 結果はS3またはHDFSに配信されますが、エンドユーザーに配信するには追加のインフラストラクチャが必要です。
一般に、Elastic MapReduceは、条件付きで即時の結果を意味しないタスクに適しています。 しかし、主にリクエストが処理されるまでに要件と矛盾するため、問題を解決するためにそれを使用することは不可能です。
アパッチストーム
Apache Stormは 、MapReduceアプローチの利点を維持したまま、処理の結果をほぼリアルタイムで取得できる代替手段として適しています。 このフレームワークはTwitter（分析イベントの処理）のニーズに使用され、数百万のキューを持つタスクフローに適合しています。
AWSクラウドへのStormのインストールは十分に検討されています。システムの実行可能性を維持するために必要なすべてのノードとZookeeperインスタンスを自動的に起動する既製のデプロイメントスクリプトがあります。
ただし、綿密な調査（プロトタイプの作成）を行うと、このようなソリューションにもいくつかの欠点があることがわかりました。
- Stormクラスターの構成の変更（ノードの追加、新しいバージョンのデプロイ）はその場で行われます。 正確に言うと、多くの場合、クラスターが再起動された後にのみ変更が反映されることが保証されています。
- RPCモードのStormでのメッセージ処理の概念には、MapReduceを実装するための少なくとも3つの段階が含まれます。作業の部分への分割、作業の部分の処理、および結果の結合です。 これらの各ステップは通常、独自のノードで実行されます。 これにより、メッセージのバイナリコンテンツの追加のシリアル化と逆シリアル化が行われます。
- 統合テストへの最も簡単なアプローチではありません-テストクラスタ全体を上げるにはリソースと時間が必要です。
- 侵入型API（好みのカテゴリからですが、それでも）。
Stormで構築されたコンセプトは、速度などの要件を満たしました。 しかし、このソリューションを提供する恒久的に発生するタスク（1項と3項）と「不要な」シリアル化による一時的な損失（2項）のため、それを放棄することが決定されました。
弾性豆茎
別のオプションは、Amazon Elastic Beanstalkでホストされる独自のアプリケーションを作成することでした。 このオプションは、CPUとネットワークの負荷を分散するEC2インスタンスのセット、自動スケーリング、メトリック、すべてのノードの実行可能性の維持など、すべての問題を一挙に解決できます。 しかし、よく調べてみると、疑問が生じました。
- ベンダーロックイン。 顧客との議論の後、公共サービスの開発に加えて、彼の計画には同様の機能を備えたボックス化されたソリューションの提供も含まれていることが判明しました。 また、同様の機能を備えたAmazon EC2およびAmazon S3の代替がイントラネット指向の製品（たとえば、Pivotal製品ライン）で見つかる場合、Beanstalkの適切な代替はありません。
- スケーリング設定の柔軟性の欠如。 ユーザーのリクエストに関する統計は、勤務時間の開始に関連する明らかな急増を示しています。 しかし、システムでは、サーバーの予熱を時刻に結び付けることはできませんでした。 [最近では、この機会が現れました ]。
- Beanstalkの最も信頼性の高いAmazon SQSメッセージングサービスの一部ではありません。 Amazon開発者フォーラムには、このサービスのSDKに関する問題がたくさんあります。
- 包括的な展開手順。
主に第一の理由により、このような決定を拒否しました。 しかし、Beanstalkが急速に開発されていることは注目に値します。次のプロジェクトでは、間違いなくそれに注意を向けます。
自転車
私たちの中で2つの意見が広まっています：「すべてが私たちの前に書かれています-あなたは検索できるようにする必要があります」と「あなたが何かをうまくやりたいなら、それを自分でやりなさい」。 検索中に得られた経験に基づいて、サモピスナヤシステムを支持して決定が下されました。
（これについて- 記事の次の部分で ）。