"Burns Cliff"、"Columbia Hills"、"Endeavour"、"Bonneville Crater" と聞くと、よその世界のように感じられるでしょうか。そのとおり、これらは NASA の Mars Exploration Rover（MER）が探査した地理的構造の一部です。ローバーは数年に渡って、この赤い星の高解像度画像など驚くべきデータのコレクションを送信しています。現在、Amazon Simple Workflow Service（Amazon SWF）は、これらのミッションの背後で重要なコンピューティング技術をいくつも投入して、NASA の研究員たちが安心してミッションクリティカルな操作を進められるように、また、宇宙に関して収集、蓄積されていく知識を効率的に処理できるようにしています。
Mars Exploration Rover
NASA のジェット推進研究所（JPL）において、Amazon SWF は火星探査機（MER）、極地における炭素貯留に関する脆弱性実験（CARVE）などの複数のミッションの統合部分として利用されています。これらのミッションからは継続的に大量のデータが発生し、それらのデータは効率的かつ安全に処理、分析、格納しなければなりません。計画的な運用と科学的な分析を実現するには、データ処理のパイプラインにおける各ステップを大規模に実行し、状況に応じて複数マシンでの並列実行を採り入れることが必要です。例えば、ペアの画像から立体視データを生成するときや、火星の地形に没入できる数ギガピクセルのパノラマを画像のつなぎ合わせによって作成するとき、必要に応じてデータをロードするためにそうしたギガピクセル単位の画像をタイリングするときなどです。こうしたデータに依拠しているオペレータや研究員のコミュニティは、世界中に広がっています。このコミュニティは、数時間という短い時間での厳しい計画に沿った運用に携わることもしばしばです。そうしたニーズに応えるために、JPL のエンジニアは火星の画像を数分以内に処理して配布するという目標を設定しました。
JPL は、以前からデータの格納と処理に AWS を使用してきました。この作業の多くは、JPL のクラウド指向アーキテクチャーである Polyphony というフレームワーク内で行われます。このフレームワークは、クラウド内でのデータ処理に関してプロビジョニング、ストレージ、監視、タスク統合をサポートしています。Polyphony が備えているデータ処理および分析のための既存のツールセットには、計算能力を提供する Amazon EC2、ストレージとデータ配布のための Amazon S3、タスクの分配と実行のための Amazon SQS および Hadoop などの MapReduce があります。しかし、ここには大きく欠けている要素があります。大型で複雑なワークフローのタスクを安心して管理できる統合化サービスです。
キューは大規模な並列ジョブを分配するための効果的な手法ですが、エンジニアはすぐにその欠点に突き当たります。キュー内では順序や相互依存性を表すことができないため、複雑なワークフローには向いていないのです。また、キューを使用した場合、JPL のエンジニアはメッセージの複製も処理しなければなりませんでした。例えば、画像どうしをつなぎ合わせる際、1 つの画像をつなげるための複製タスクによって高い負荷の余分な処理が発生し、それにより、パイプラインが処理の完了まで進む間に高負荷の計算がさらに行われます。JPL には、きわめて巨大なデータ処理を行うユースケースや、制御フローを扱うためのメカニズムを必要とするユースケースが大量に存在します。エンジニアは MapReduce を使用してデータ駆動フローを簡単に実装することはできましたが、パイプラインの各ステップをフレームワークのセマンティクスで表すことは困難でした。特に、データ処理の複雑さが高まると、処理ステップ間の依存関係を表すことや分散計算の失敗を処理することが難しくなっていきました。
JPL のエンジニアは、次のような特性を持つ統合化サービスの必要性を認識しました。
- 高可用性: ミッションクリティカルな運用をサポートするため
- スケーラブル: Amazon EC2 インスタンスから発生する数百の処理を同時に実行するため
- 一貫性: スケジュールされたタスクはきわめて高い確度で 1 回実行されることが必要
- 表現力: 開発を進めやすいように、複雑なワークフローを簡潔に表現できること
- 柔軟性: Amazon EC2 以外のワークフローも実行可能で、タスクのルーティングができること
- パフォーマンス: 最小限の遅延でタスクをスケジューリング
JPL のエンジニアは、Amazon SWF を使用して、計画的な運用に向けて火星の画像のデータ処理を受け持つ Polyphony パイプラインとサービスを統合しました。パイプラインの分散実行における、かつてない操作性と可視性が実現されたのです。何よりも重要な点は、複雑なワークフローを表すことに成功しながらも、問題を特定のパラダイムで表す必要がなかったということです。
Mars Science Laboratory とも呼ばれる Curiosity ローバーの高速移動フィールドテストに対応するために、JPL のエンジニアは画像を処理し、立体視画像を生成し、パノラマを作成する必要がありました。立体視画像は、同時に撮影したペアの画像を必要とし、それに基づいてローバーから画像内のピクセルまでの距離と方向がわかる範囲データが生成され、計画に沿って操作する担当者はそれを利用します。左右の画像が同時に処理されますが、立体視の処理はそれぞれの画像の処理が終わるまで開始できません。この典型的な分割結合ワークフローは、キューベースのシステムで表すことは困難ですが、SWF で表す場合は Java の簡単なコード数行と AWS Flow Framework の注釈を組み合わせるだけで済みます。
パノラマの生成も、ワークフローとして実装されています。運用の都合上、パノラマはローバーが停車し、写真を撮影するすべての場所で生成されます。そのため、特定の場所からの写真が届くたびに、パノラマは新しく入手した情報によって大きくなっていきます。パノラマはサイズが大きく、また、できるだけ短時間で生成しなければならないため、問題は複数のマシンに分割し、統合する必要があります。エンジニアが採用したアルゴリズムは、パノラマを複数の行に分割するというものでした。ワークフローの最初のタスクは、その場所で使用できる画像に基づいて各行を生成することです。生成された行は、リモートクライアントによる処理のために複数の解像度にスケールダウンされ、タイリングされます。Amazon SWF が備えている豊富な機能セットを使用することにより、JPL のエンジニアはこのアプリケーションフローを Amazon SWF のワークフローとして表しました。
Opportunity Pancam のモザイク画像（全体のサイズは 11280×4280 ピクセル、77 色）この画像を任意のサイズで表示できるようにするには、6 段階の詳細レベルを持つタイルが必要です。黄色のグリッド線は、各画像に必要なタイルを示しています。Mars Science Laboratory の Mastcam 部分は、1296 の画像で構成され、解像度は 2 ギガピクセルにも及びます。このパノラマ画像を以下に示します。
Amazon SWF によるクラウド上での組織化が可能になったことにより、JPL はその環境内外のリソースを活用し、パブリッククラウドでシームレスにアプリケーションを実行できるようになりました。これにより、JPL のアプリケーションはダイナミックにスケールされ、真に分散された方法で実行可能となったのです。
JPL におけるデータ処理パイプラインの多くは、ファイアウォールで保護されたデータを自動的にアップロードするワーカー、データを並列処理するワーカー、および結果をダウンロードするワーカーとして構成されています。アップロードおよびダウンロードのワーカーはローカルサーバーで実行され、データ処理のワーカーはローカルサーバーと Amazon EC2 ノードの両方で実行できます。Amazon SWF のルーティング機能を使用することにより、JPL の開発者はデータのローカリティなどワーカー固有の利点を活かしつつ、動的にワーカーをパイプラインに組み入れました。この処理アプリケーションは、ローカルワーカーに障害が発生してもクラウドベースのワーカーは引き続き処理を進めるため、高可用性も備えています。Amazon SWF ではワーカーノードの場所に制約がないので、JPL ではジョブを地元のデータセンターだけでなく複数のリージョンでも実行して、ミッションクリティカルなシステムに最大限の可用性が与えられるようにしています。Amazon SWF が複数のリージョンで使用できるようになるのに合わせて、JPL はリージョン間で SWF への自動フェイルオーバーを統合することを計画しています。
JPL における Amazon SWF の利用は、データ処理アプリケーションだけに限りません。Amazon SWF のスケジューリング機能を使用することにより、JPL のエンジニアはミッションクリティカルな操作を正しい時刻に確実に実行する Cron ジョブシステムを構築しました。信頼性に加え、AWS マネジメントコンソールで使用可能な Amazon SWF の可視性機能により、JPL はこれらの分散ジョブを他に例のない形で 1 か所から見られるようになりました。さらに JPL は、重要なデータを MER から Amazon S3 にバックアップするアプリケーションも構築しました。分散 Cron ジョブを使用して、JPL はバックアップを更新するだけでなく、プロジェクトが必要とする頻度でデータの整合性も検査しています。暗号化、S3 へのアップロード、検査するデータのランダムな選択、オンサイトデータと S3 との比較による検査など、このアプリケーションのすべてのステップが Amazon SWF によって確実に統合されます。また、JPL のいくつかのチームは、AWS Flow Framework で提供されているプログラミングサポートを活用することにより、クラウドでの統合を利用するように既存のアプリケーションを短期間で移行しました。
JPL では簡単なデータ処理パイプラインには引き続き Hadoop を使用していますが、処理ステップの間に複雑な相互依存性が存在するアプリケーションを実装する際には、Amazon SWF が現在の自然な選択肢です。また、開発者は開発の途中でアプリケーションのデバッグを行う際、また分散実行の追跡を行う際に、AWS Management Console から利用可能な診断機能および解析機能を頻繁に使用します。Amazon SWF を使用することにより、ミッションクリティカルなアプリケーションの開発、テスト、デプロイに要する時間が、月単位から日単位にまで短縮されました。