Amazon Web Services ブログ

AWS でのゲノミクスワークフローに Amazon FSx for Lustre を使用する

 

ゲノミクスのデータセットは、年々大きくなっています。世界中の研究イニシアチブからのデータを組み合わせ、それを迅速に処理する能力を持つことが重要な科学的発見を可能にするメカニズムとして重要であることが、大規模なバイオインフォマティクスおよびゲノミクスのコミュニティによって確認されています。グローバルな規模でのコラボレーションには、世界中からアクセス可能で、可用性が高く、高性能のデータ処理を可能にするデータストレージソリューションが必須です。

Amazon FSx for Lustre は、高性能 POSIX 準拠の共有ファイルシステムの使いやすさと、Amazon Simple Storage Service (Amazon S3) の業界をリードするスケーラビリティとデータ可用性を兼ね備えています。Amazon FSx for Lustre は Amazon S3 とネイティブに連携し、S3 オブジェクトをファイルとして透過的に提示するため、高性能ファイルシステムでクラウドデータセットを処理し、結果を S3 に書き戻すことが簡単になります。データを Amazon S3 に保存することで、Amazon Redshift、Amazon Athena、Amazon EMR、Amazon SageMaker などの分析および機械学習のソリューションによるダウンストリーム分析が可能になります。

このブログ記事では、Amazon FSx for Lustre を簡単に使用して、AWS でのゲノミクスワークフローを簡素化および高速化する方法を示します。

ゲノミクスワークフロー

ゲノミクスワークフローは通常、ファイルの操作用に設計された複数のコマンドラインツールで構成されています。つまり、入力として FASTQ や BAM などのファイルを受け取り、出力として TSV/CSV や VCF などのファイルを生成します。

私たちが使用するゲノミクスワークフローは、二次解析パイプラインです。この特定のパイプラインは、コンテナ化されたツールのセットを使用して、未加工の全ゲノム配列を変形 (標準リファレンスと比較した配列の違い) に変換します。

以前のブログ記事投稿で、AWS Batch および AWS Step Functions を使用して、こうしたワークフローをスケーラブルに構築および実行する方法について説明しました。私たちのリファレンスアーキテクチャでは、データ入出力の耐久性に優れたストレージとして S3 を使用し、AWS CLI を使用してデータをステージングし、それに応じて十分なサイズの EBS ボリュームを持つジョブを計算します。

これは、大量のデータ (多くの場合、サンプルあたり 100 GB を超える) を管理する最もコスト効率の高い方法ですが、コンピューティングノードとの間でデータが転送されている間、ワークフローに多少の遅延が生じる可能性があります。これには、S3 とやり取りできるツールも必要です。コンテナ化されたツールを使用すると、AWS CLI をコンテナイメージに組み込むことも必要です。事前に構築されたコンテナ化ツールが多数ある場合、または公開ソースを利用している場合、多くのイメージを再構築および管理することになります。

たいていのゲノミクスおよびバイオインフォマティクスのツールは、POSIX 準拠のファイルシステムでファイルを操作するように構築されています。さらに、ゲノミクスワークフローで複数回生成されたデータ入力または中間ファイルを使用するのが一般的です。たとえば、参照ゲノムバンドル (通常は最大 10 GB のサイズ) を使用して、ワークフローの 2 つの異なるステップである未加工のサンプル読み取りと呼び出し変形を調整します。ワークフローのステップ全体で共有ファイルシステムを使用すると、以前のステップで収集または生成されたデータに簡単にアクセスできます。

ゲノミクスワークフロー用の Amazon FSx for Lustre

ワークフロー用に AWS Batch によって起動されたすべてのコンピューティングインスタンスにマウントされた高性能の共有ファイルシステムとして Amazon FSx for Lustre を使用できます。また、Amazon FSx for Lustre は、S3 とデータを透過的に同期できるので、並列 POSIX ファイルシステムとしてアクセス可能な S3 へのキャッシュレイヤーが効果的になります。

ゲノムワークフローに Amazon FSx for Lustre を使用するためのアーキテクチャ

Amazon FSx for Lustre およびデータリポジトリタスク API に対する POSIX メタデータの強化により、ワークロードの幅広い種類のセットで S3 データを高速で簡単かつ安価に処理することも可能になります。これには、金融サービス業界でのティッカーデータのストリーミングや金融取引など、多数の小さなファイルの処理を必要とするワークロードが含まれます。さらに関連が深いのは、ヘルスケアおよびライフサイエンス業界でのヒト全 DNA 配列など、機密データへのアクセスコントロールを必要とするワークロードに役立つ可能性があることです。

私たちのゲノミクスワークフローでは、以下の 3 つのファイルシステムを作成します。

1 つ目はリファレンスデータ用です。つまり、hg38 リファレンスヒトゲノムです。これは、ブロード研究所が提供し、AWS パブリックデータセットプログラムによってホストされるパブリック S3 バケットを使用します。

2 つ目はソースデータ用です。ここでは、デモ用にサイズを小さくしてパブリックバケットに配置した未加工のシーケンスファイル (FASTQ) をいくつか使用しています。現実の世界のシナリオでは、おそらくこれにプライベートバケットを使用します。つまり、組織がゲノミクスデータレイクとして使用するバケットです。

3 つ目であり最後のファイルシステムは、作業データ用です。このファイルシステムは、ワークフローによって生成された出力を保存するために使用されます。このデモ用に作成したばかりのプライベート S3 バケットに関連付けられます。現実の世界のシナリオでは、このバケットは研究グループに関連付けられたものになる可能性があります。

必要なストレージとコンピューティングインフラストラクチャをプロビジョニングするために、以下を作成する AWS CloudFormation テンプレートがあります。

  • コンピューティングリソースを分離する Amazon VPC
  • ワークフローの出力用の Amazon S3 バケット
  • リファレンス、ソース、出力の各データ用に必要な Amazon FSx for Lustre ファイルシステム
  • ワークフローステップを実行する AWS Batch ジョブキューとコンピューティング環境

テンプレート内の Amazon FSx for Lustre リソースを見てみましょう…

Resources:
    ...
  FSxLustreReferenceFileSystem:
    Type: AWS::FSx::FileSystem
    Properties:
      FileSystemType: LUSTRE
      LustreConfiguration:
        ImportPath: !Ref S3ReferencePath
      StorageCapacity: !Ref LustreStorageCapacity
      SecurityGroupIds:
        - !Ref EC2BatchSecurityGroup
      SubnetIds:
        - !Sub "${VpcStack.Outputs.PrivateSubnet1AID}"
  
  FSxLustreSourceDataFileSystem:
    Type: AWS::FSx::FileSystem
    Properties:
      FileSystemType: LUSTRE
      LustreConfiguration:
        ImportPath: !Ref S3SourceDataPath
      StorageCapacity: !Ref LustreStorageCapacity
      SecurityGroupIds:
        - !Ref EC2BatchSecurityGroup
      SubnetIds:
        - !Sub "${VpcStack.Outputs.PrivateSubnet1AID}"

  FSxLustreWorkingFileSystem:
    Type: AWS::FSx::FileSystem
    Properties:
      FileSystemType: LUSTRE
      LustreConfiguration:
        ImportPath: !Ref S3WorkingPath
        ExportPath: !Ref S3WorkingPath
      StorageCapacity: !Ref LustreStorageCapacity
      SecurityGroupIds:
        - !Ref EC2BatchSecurityGroup
      SubnetIds:
        - !Sub "${VpcStack.Outputs.PrivateSubnet1AID}"
    ...

「作業用」ファイルシステムだけにエクスポートパスがあり、これがインポートパスと同じであることに注意してください。したがって、「作業用」ファイルシステムは、Amazon FSx for Lustre が S3 にデータを書き戻すことができる唯一のファイルシステムです。これは、リファレンス用およびソースデータ用の他の 2 つのファイルシステムが S3 の観点から読み取り専用であることも意味します。

次に、AWS Batch リソースの設定を見てみましょう。

ここでは、1 つのジョブキューを作成し、1 つのコンピューティング環境だけに関連付けています。このコンピューティング環境はスポットインスタンスを使用するので、コンピューティングコストの節約を最大化するのに役立ちます。

Resources:
    ...
  BatchSpotComputeEnv:
    Type: AWS::Batch::ComputeEnvironment
    Properties:
      ComputeEnvironmentName: !Sub 
        - spot-${StackGuid}
        - StackGuid: !Select [ 2, !Split [ "/", !Ref "AWS::StackId" ]]
      ServiceRole: !GetAtt IAMBatchServiceRole.Arn
      Type: MANAGED
      State: ENABLED
      ComputeResources:
        MinvCpus: 2
        DesiredvCpus: 2
        MaxvCpus: 256
        LaunchTemplate:
          LaunchTemplateId: !Ref EC2LaunchTemplate
        InstanceRole: !GetAtt IAMBatchInstanceProfile.Arn
        InstanceTypes:
          - optimal
        SecurityGroupIds:
          - !Ref EC2BatchSecurityGroup
        SpotIamFleetRole: !GetAtt IAMBatchSpotFleetRole.Arn
        Subnets:
          - !Sub "${VpcStack.Outputs.PrivateSubnet1AID}"
          - !Sub "${VpcStack.Outputs.PrivateSubnet2AID}"
        Type: SPOT
        Tags:
          Name: !Sub
            - batch-spot-worker-${StackGuid}
            - StackGuid: !Select [ 2, !Split [ "/", !Ref "AWS::StackId" ]]

  BatchDefaultQueue:
    Type: AWS::Batch::JobQueue
    Properties:
      JobQueueName: !Sub
        - default-${StackGuid}
        - StackGuid: !Select [ 2, !Split [ "/", !Ref "AWS::StackId" ]]
      Priority: 1
      State: ENABLED
      ComputeEnvironmentOrder:
        - Order: 1
          ComputeEnvironment: !Ref BatchSpotComputeEnv
    ...

また、コンピューティング環境は、UserData スクリプトを備えた Amazon EC2 LaunchTemplate を使用して、lustre-client をインストールし、Amazon FSx for Lustre ファイルシステムをマウントすることによって起動するインスタンスをプロビジョニングします。

Resources:
    ...
  EC2LaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateName: !Join ["-", [!Ref LaunchTemplateNamePrefix, !Select [2, !Split ["/", !Ref "AWS::StackId" ]]]]
      LaunchTemplateData:
        ...
        UserData:
          Fn::Base64: !Sub |-
            MIME-Version: 1.0
            Content-Type: multipart/mixed; boundary="==BOUNDARY=="

            --==BOUNDARY==
            Content-Type: text/cloud-config; charset="us-ascii"

            packages:
            - lustre-client
            - amazon-ssm-agent

            runcmd:
            - start amazon-ssm-agent
            - mkdir -p /scratch/reference /scratch/data /scratch/working
            - mount -t lustre ${FSxLustreReferenceFileSystem}.fsx.${AWS::Region}.amazonaws.com@tcp:/fsx /scratch/reference
            - mount -t lustre ${FSxLustreSourceDataFileSystem}.fsx.${AWS::Region}.amazonaws.com@tcp:/fsx /scratch/data
            - mount -t lustre ${FSxLustreWorkingFileSystem}.fsx.${AWS::Region}.amazonaws.com@tcp:/fsx /scratch/working

            --==BOUNDARY==--

この場合、Amazon FSx for Lustre ファイルシステムはすべて、/scratch のパスにマウントされます。具体的には:

  • /scratch/reference は、リファレンスデータのファイルシステム
  • /scratch/data は、未加工の入力データのファイルシステム
  • /scratch/working は、ワークフローの出力データのファイルシステム

それでは、ワークフローのツールを作成しましょう。

ここで、ワークフローは以下を使用する単純なものです。

  • 配列データを調整する BWA-mem
  • アライメントをソートおよびインデックス化する SAMtools
  • バリアント呼び出しを行う BCFtools

ワークフローを構築するために、以下を作成する CloudFormation テンプレートがあります。

  • ワークフローツールのコンテナイメージと ECR イメージのリポジトリ
  • ワークフローツールの AWS Batch ジョブ定義
  • ワークフロー用の AWS Step Functions ステートマシン

AWS Batch で、いずれかのツールのジョブ定義を見てみましょう。注意すべき重要な部分は、すべての Amazon FSx ファイルシステムがマウントされるホスト上のスクラッチ場所を指すジョブのボリュームマウント仕様を作成したことです。

{
    "jobDefinitionName": "bwa",
    "type": "container",
    "parameters": {
        "command": "mem",
        "reference_name": "Homo_sapiens_assembly38",
        "sample_id": "NIST7035",
        "input_path": "./data"
    },
    "containerProperties": {
        "image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/bwa:aws",
        "vcpus": 8,
        "memory": 64000,
        "command": [
            "Ref::command",
            "Ref::reference_name",
            "Ref::sample_id",
            "Ref::input_path"
        ],
        "volumes": [
            {
                "host": {
                    "sourcePath": "/scratch"
                },
                "name": "scratch"
            }
        ],
        "mountPoints": [
            {
                "containerPath": "/scratch",
                "sourceVolume": "scratch"
            }
        ]
    }
}

私たちが使用している Step Functions ステートマシンは、bwa-mem、samtools、bcftools をチェーン接続する単純な線形ワークフローです。

ワークフローの最後に、追加のタスクがあります。生成された結果を S3 に同期させるためのデータリポジトリタスクを作成するタスクです。

"ExportToDataRepository": {
    "Type": "Task",
    "InputPath": "$",
    "ResultPath": "$.fsx.data_repository_task.result",
    "Resource": "arn:aws:states:::batch:submitJob.sync",
    "Parameters": {
        "JobName": "export-to-data-repository",
        "JobDefinition": "${BatchJobDefFSxDataRespositoryTask}",
        "JobQueue.$": "$.defaults.queue",
        "ContainerOverrides": {
            "Vcpus": 2,
            "Memory": 8000,
            "Environment": [
                { "Name": "WORKFLOW_NAME", "Value.$": "$$.StateMachine.Name" },
                { "Name": "EXECUTION_ID", "Value.$": "$$.Execution.Id" }
            ]
        }
    },
    "End": true
}

このタスクの AWS Batch ジョブ定義は、以下のとおりです。

BatchJobDefFSxDataRepositoryTask:
    Type: AWS::Batch::JobDefinition
    Properties:
      JobDefinitionName: fsx-data-repo-task
      Type: container
      ContainerProperties:
        Image: amazonlinux:2
        Vcpus: 2
        Memory: 8000
        Command:
          - /opt/miniconda/bin/aws
          - fsx
          - create-data-repository-task
          - --file-system-id
          - !Ref FSxLustreWorkingFileSystem
          - --paths
          - /scratch/working/$WORKFLOW_NAME/$EXECUTION_ID
          - --report
          - !Sub "Enabled=true,Scope=FAILED_FILES_ONLY,Format=REPORT_CSV_20191124,Path=${S3WorkingPath}"
        Privileged: True
        Volumes:
          - Host:
              SourcePath: /scratch
            Name: scratch
          - Host:
              SourcePath: /opt/miniconda
            Name: aws-cli
        MountPoints:
          - ContainerPath: /scratch
            SourceVolume: scratch
          - ContainerPath: /opt/miniconda
            SourceVolume: aws-cli

バインドは、AWS CLI (miniconda 経由でホストインスタンスにインストールされます) を AmazonLinux2 コンテナにマウントし、作業データ用のファイルシステムで create-data-repository-task API 呼び出しを発行します。これは、このブログ記事でコンテナ実行コマンドとして説明されています。

ワークフローを実行するために、AWS CLI をローカルで使用して、ステートマシンの実行を開始します。

aws stepfunctions start-execution \
    --state-machine-arn arn:aws:states:region:account:stateMachine:<state-machine-name> \
    --cli-input-json file://inputs.json

ワークフローが完了すると (約 10 分かかります)、S3 バケットに「作業用」の Amazon FSx for Lustre ファイルシステムのデータリポジトリとして使用される一連のファイルがあるはずです。また、Amazon FSx for Lustre ファイルシステムは不要になりますので、シャットダウンできます。

考慮事項とまとめ

上の例では、3 つの Amazon FSx for Lustre ファイルシステムを、リファレンス S3 バケットからのデータとワークフローによって生成されたデータの一時的なスクラッチストレージとして使用しました。

コスト面を考えると、3 つのファイルシステムのすべてで最小容量 (1.2 TB) の Amazon FSx for Lustre ファイルシステムを使用すると、ワークフロー全体でのコストは約 0.12 USD になります。

0.000194 USD/1 GB 1 時間 * 1200 GB * 3 ファイルシステム * 10 分 = 0.1164 USD

これと比べて、同じワークフローが S3 データステージングを両方向で直接使用して完了するには、少なくとも 15 分かかります。ワークフローの各ステップのスクラッチスペースとして 1 TB の EBS ボリュームを使用しますが、完了までの時間がさらにかかることを考慮すると、コストは約 0.04 USD になります。

0.10 USD/1 GB 1 か月 / 720 時間/月 * 1000 GB * 15 分 = 0.035 USD

現実の世界のワークフローは、通常、完了するのに 8〜12 時間かかり、より多くの手順が含まれ、より多くのデータを使用します。したがって、コストの観点から見れば、Amazon FSx for Lustre を使用する場合とセルフマネージド EBS ボリュームを使用する場合の違いはそれほど大きくないかもしれません。

ワークフロー開発の観点から見ると、Amazon FSx for Lustre は、AWS でのゲノミクスワークフローの実行を 2 つの方法で高速化し、可能性を拡げます。

  1. POSIX ファイルシステムを想定したツールを引き続き使用して、既存のワークフローをクラウドに簡単に移行することができます。
  2. また、ツールコンテナを更新することなく、データストレージで S3 の耐久性と可用性を活用することもできます。

詳細については、Amazon FSx for Lustre のウェブページにアクセスしてリソースを入手してください。