BatchとStep Functionsでゲノミクスのワークフローに入門してみた

こんにちは。AWS事業本部のKyoです。

生命科学と情報科学の融合領域であるバイオインフォマティクスにAWSの力を使って入門してみました。

これは何？

GitHubはこちら。

本ブログではAWS Step Functions For Genomics Workflowsのサンプルを元にゲノミクスワークフローの構築と実行を行います。 CloudFormationを展開するので、AWSアカウントがあればすぐに試すことができます。

ゲノミクスで扱うデータが大きくストレージを気にされている方、 サーバーの管理を最小限にしたい方、データ量に応じてスケーラブルなワークフローを構築したい方などの参考になると思います。

今回構築するのはゲノミクスのワークフローですが、 ワークフローエンジン + 処理基盤という形になるので、 処理内容を変更することでその他の分野のワークフローとしても転用可能であると思います。

全体像

ゲノミクス観点

AWS Step Functions For Genomics Workflowsの説明を機械翻訳すると以下の様になります。

ワークフローの例は、生のFASTQファイルを染色体のリストを必要とするバリアントを持つVCFに変換する単純な二次分析パイプラインです

この説明ではあまりイメージが持てなかったので、処理内容や実行結果から推測してみました。

次世代シーケンサーから得られたリード配列であるFASTQファイルをインプットとして、これをヒトのリファレンス配列にマッピング、19-22番染色体に対してバリアントコール（変異配列の特定）を行っています。結果はVCFファイルとして保存されるので、アウトプットとしては4つの（圧縮された）VCFファイルが生成されます。

簡単にまとめると以下になります。

• リード
  • NIST7035（をおそらくAWS社でトリミングしたもの。これがFASTQファイル） 2種類
• リファレンス配列
  • hg38（ヒト。Registry of Open Data on AWSより取得）
• 利用ツール
  • BWA: リファレンス配列にリードをマッピング
  • SAMtools: ファイルのバイナリ化およびインデックスの作成
  • bcftools: バリアントコール

アーキテクチャ観点

ここからがAWSの話です。

AWS Step Functions For Genomics Workflowsより引用

ワークフローエンジンとしてStep Functions、解析基盤としてBatchを採用しています。それぞれがどんなものかについては下記のブログをご参照ください。

Batchはコンテナを実行させるので、コンテナレジストリであるECRも必要になります。

図に記載はありませんが、ネットワークリソースも構築します。 Batchのジョブはプライベートなサブネットで実行され、実行結果はVPCエンドポイントを経由してインターネットに出ることなく、S3に格納されます。

また今回の設定においてBatchはEC2起動タイプを利用します。 この際にコストパフォーマンス向上のため、スポットインスタンスを利用できるようになっています。 スポットインスタンスはAWS側の状態で中断される可能性がある購入オプションで、オンデマンドインスタンスに比べて利用料金を最大90% OFFで利用可能です。

• スポットインスタンス

安定稼働が前提のWebサーバーと異なり、オンデマンドでコンピュートリソースが求められる解析基盤との組み合わせは特に相性が良いと言われています。 今回のアーキテクチャでもジョブがない場合はEC2インスタンスが起動せず、ある場合にのみ自動起動、終了時に自動停止することになります。

これらのアーキテクチャによって、ユーザーが解析をリクエストした際に、スケーラブルな形でコンピュートリソースが起動するワークフローを構築できます。

デプロイしてみる

実際にデプロイしてみましょう。デプロイするのは以下の3種類のCloudFormationテンプレートです。

• VPC
• ゲノミクスワークフローコア
• Step Functions関連リソース

内容を見ながら順番にデプロイを行います。 デプロイ時のパラメータは指定のあるもの以外はデフォルトを利用しています。

VPC

ネットワーク系のリソースが展開されます。

• VPC
• インターネットゲートウェイ
• パブリックサブネット
• プライベートサブネット
• NAT Gateway
• S3 VPCエンドポイント

テンプレート ※GitHubレポジトリに含まれていないのでファイルへの直リンクです。

NAT GatewayやVPCエンドポイントは時間単位でも課金が発生するリソースなので検証時にはご注意ください。

デプロイ時のパラメータとして、Availability Zoneにap-northeast-1a, ap-northeast-1cを指定しました。

ゲノミクスワークフローコア

Batchの環境を中心にリソースが展開されます（ジョブ定義やコンテナイメージは含まれません）。 このテンプレートはネストされています。

• Batch コンピューティング環境
• Batch ジョブキュー
• EC2起動テンプレート
• S3バケット
• IAMポリシーとロール

テンプレート

デプロイ時のパラメータとして、S3バケット名はユニークである必要があるためgwfcore-bucket-{アカウントID}を指定しました。 サブネットは先ほどのテンプレートで作成されたPrivate subnet 1A, Private subnet 2Aを指定しました。

Step Functions関連リソース

Step FunctionsおよびBatchのジョブ定義、3種類のコンテナイメージなどが構築されます。 このテンプレートはネストされています。

• Step Functions ステートマシン
• バッチジョブ定義
• コンテナイメージ（CodeBuildでビルドされたもの）
• Step FunctionsがBatchを呼び出すことを可能にするIAMロール

テンプレート

デプロイ時のパラメータとして、GWFCoreNamespaceにゲノミクスワークフローコアスタックの名前（今回はgwfcore）を指定しました。

動かしてみる

環境が整ったので動かしてみます。

方法

Step Functionsの入力となるJSONはStep Functions関連リソース スタックの出力のStateMachineInputにあります。

以下に整形したものを示します。

{
    "params": {
        "queue": "arn:aws:batch:ap-northeast-1:{アカウントID}:job-queue/default-gwfcore",
        "environment": {
            "REFERENCE_NAME": "Homo_sapiens_assembly38",
            "SAMPLE_ID": "NIST7035",
            "SOURCE_DATA_PREFIX": "s3://aws-batch-genomics-shared/secondary-analysis/example-files/fastq",
            "JOB_OUTPUT_PREFIX": "s3://gwfcore-bucket-{アカウントID}",
            "JOB_AWS_CLI_PATH": "/opt/aws-cli/bin"
        },
        "chromosomes": [
            "chr19",
            "chr20",
            "chr21",
            "chr22"
        ]
    }
}

Batchのキューおよび環境、入出力データの定義などを行っています。

Step Functionsの画面からワークフローを起動します。

JSONを貼り付けて実行します。

グラフインスペクターが全てグリーンになったら完了です。

実行には15分程度かかりました。

結果の確認

Batchのジョブが成功していることが確認できます。 ジョブごとにCloudWatch Logsにログが出力されているのでそれを確認することも可能です。

なおBatchのwokerとしてはm4.2xlargeのスポットインスタンスが使われていました。

S3に出力されたファイルを確認してみます。

NIST7035.chr19.vcf.gzをはじめ、19-21番染色体について4つのファイルが生成されました。

所感

あっという間にゲノミクスワークフローが完成しました。 サイズの大きなゲノムデータを楽に扱えるスケーラブルな環境をコードベースで行えるのはクラウドならでは、という感想です。

これをそのまま使えるケースはあまりないと思いますが、テンプレートがコードで提供されているのでカスタマイズにも挑戦しやすいと思います。

今回ワークフローエンジンとしてはStep Functionsを採用していますが、Cromwell、Nextflowといったエンジンを採用する例もAWSから紹介されています。

• Cromwell on AWS Batch
• Nextflow on AWS Batch

それらと比較してStep Functionsを採用する際には以下の特徴があるといえます。

1. AWSのマネージドサービスであるので管理が楽（ワークフローサーバーの面倒をみなくていい）
2. 基本料金は不要で実行回数に依存の課金（詳細はこちら）

なお、Cromwell, Nextflowと同様にStep FunctionsでもワークフローはAmazon States Language(ASL)というJSONベースの独自の言語で記述する必要があります。 最近GAとなったマネージドApache AirflowであればワークフローをPythonで記述できるので場合によってはそちらを検討してみるのも良いかもしれません。

以上、何かのお役に立てれば幸いです。

参考にさせていただいたサイト

• biopapyrus
• macでインフォマティクス