AWS Batch を使った FastQC 実行環境を AWS マネジメントコンソールだけで構築してみた

はじめに

こんにちは、ほりぐちです。

皆さんは、普段どのような環境で RNA-seq 解析を行っていますか？
研究室のサーバーや個人の PC で行っている方も多いのではないかと思います。

今回は、AWS マネジメントコンソールを使って、AWS 上で FastQC の実行環境を構築する方法をステップバイステップで紹介します。最小限の構成として、データの保存先となる S3 バケットを作成し、AWS Batch で FastQC を 1 ジョブだけ実行してみたいと思います。

研究室のサーバーや個人の PC で行っている解析をクラウド上で実行する場合、どのような構成になるのか、参考になれば幸いです。

注意

• 本記事では公開データ（GATK Test Data）を利用します
• 本記事では、解析結果に対する科学的な解釈は行いません

用語の解説

RNA-seq
細胞の中で、どの遺伝子がどのくらい使われているかを調べる方法です。遺伝子が使われるとき、その情報を写し取った RNA という分子が作られます。RNA-seq では、RNA の配列を読み取り、その量を調べることで、遺伝子の働き具合を推定します。

FASTQ
シーケンサーと呼ばれる装置で読み取った配列は、一般的に FASTQ という形式のファイルに保存されます。FASTQ ファイルには、読み取った配列と、その読み取り品質が記録されています。

FastQC
FASTQ ファイルに保存された配列データに、品質上の問題がないかをグラフや表で確認するためのソフトウェアです。

つまり今回の目的を一言でまとめると
「RNA-seq で読み取った配列データの品質を、AWS 上でチェックしてみよう」
という内容になります。

よろしくお願いいたします。

今回作成する構成

本記事で作成する全体アーキテクチャ

今回はマネジメントコンソールで完結することを目指すため、FastQC のコンテナイメージもローカル PC ではビルドせず、CodeBuild で作成して ECR へ保存します。

今回利用する主な AWS サービスは以下のとおりです。

なお、AWS Batch の Compute environment には Fargate を使用します。
EC2 インスタンスを自分で作成・管理する必要はありません。

1. S3 に入力 FASTQ をアップロードする

それでは、早速始めていきましょう。

最初に、入力データと FastQC の出力を保存する S3 バケットを作成します。
Amazon S3 コンソールを開き、「バケットを作成」を選択します。

※ 従来、バケット名は全 AWS アカウントで一意である必要がありましたが、アカウントリージョナル名前空間を利用すると、同じベース名を別の AWS アカウントやリージョンで使用できます。ただし、同一 AWS アカウント・同一リージョン内では一意である必要があります。

設定は基本的にデフォルトのままとし、「パブリックアクセスをすべてブロック」は有効のままにします。

S3 バケットの作成

次に、バケット内に以下の 2 つのプレフィックス（コンソール上のフォルダ）を作成します。

• input_data/：解析対象の FASTQ を保存
• output_data/：FastQC の結果を保存

S3 バケット内に input_data, output_data フォルダを作成

paired-end データの場合は、例えば次のような構成で入力データを配置します。

input_data/
├── sample1_R1.fastq.gz
└── sample1_R2.fastq.gz

一方、single-end データであれば FASTQ ファイルは 1 つだけになります。

アップロードしたオブジェクトの S3 URI は、後ほど AWS Batch のジョブ定義を作成する際に使用するため、控えておきます。

2. FastQC 用の ECR リポジトリを作成する

2-1. 前提

AWS Batch では、ホスト環境へ解析ソフトウェアを直接インストールするのではなく、必要なソフトウェアや実行手順をまとめたコンテナイメージを使ってジョブを実行します。そのため、まず FastQC、Java、AWS CLI などを組み込んだコンテナイメージを作成する必要があります。

コンテナイメージは、解析に必要なソフトウェアや設定をひとまとめにした実行環境です。FastQC のバージョンや必要なライブラリをイメージ内に固定することで、実行するたびに環境を構築する必要がなく、同じ条件で解析を実行できます。

今回は AWS のマネジメントコンソールで完結することを目的としているため、ローカル PC で Docker を操作せず、AWS CodeBuild を使って FastQC 用のコンテナイメージを作成します。作成したイメージは Amazon ECR に保存し、AWS Batch でジョブを実行する際に Fargate が ECR から取得します。

2-2. ECR リポジトリの作成

それでは、実際に FastQC のコンテナイメージを保存する ECR リポジトリを作成していきましょう。

Amazon ECR の「リポジトリを作成」から、プライベートリポジトリを作成しました。
今回のリポジトリ名は次のようにしました。

rna-seq/fastq-test

リポジトリ名には / を含められるため、プロジェクト名と用途を階層的に表現できます。

ECR リポジトリの作成画面

作成後、ECR リポジトリの URI を控えておきます。

AWSアカウントID.dkr.ecr.us-east-1.amazonaws.com/rna-seq/fastq-test

後ほど AWS Batch のジョブ定義でこの URI を使用します。

3. CodeBuild で FastQC コンテナを作成する

CodeBuild プロジェクトは次のような設定で作成します。

CodeBuild プロジェクトの基本設定

CodeBuild プロジェクトの環境設定

特権モードを有効にする

CodeBuild の環境設定では、特権モードを有効にします。
「環境」セクションの最下部にある「追加設定」を展開し、特権付与の欄にチェックを入れます。

CodeBuild の特権付与設定

特権モードとは

CodeBuild のビルド環境自体もコンテナで動作しています。今回は、その中でさらに次のコマンドを実行します。

docker build
docker push

CodeBuild 内で docker build などの Docker イメージを操作するコマンドを実行するために特権モードを有効にする必要があります。

なお、特権モードと IAM 権限は別のものです。

Docker build などを実行するために必要
 → 特権モード
ECR に push するために必要
 → CodeBuild サービスロールの IAM ポリシー

特権モードと適切な IAM ポリシーの両方がそろって初めて作成した Docker イメージを ECR へ push できます。

環境変数を設定する

CodeBuild プロジェクトには、次の環境変数を設定しました。

CodeBuild の環境変数

ECR_REPOSITORY には ECR の URI 全体ではなく、リポジトリ名だけを設定します。
今回は FastQC 0.12.1 を使用するため、イメージタグを 0.12.1 としています。

コンテナ起動時に実行する処理

今回作成するコンテナは、起動すると次の処理を行います。

• S3 から FASTQ をダウンロード
• FastQC を実行
• HTML と ZIP を S3 へアップロード

今回は Dockerfile とシェルスクリプトの内容を Build commands 欄へ 1 行で入力するため、それぞれ Base64 形式にエンコードしました。ビルド時に base64 -d でデコードし、ファイルとして出力する形としています。

Build commands 欄に設定したコマンドは以下のとおりです。

echo RlJPTSBwdWJsaWMuZWNyLmF3cy9hbWF6b25saW51eC9hbWF6b25saW51eDoyMDIzCkFSRyBGQVNUUUNfVkVSU0lPTj0wLjEyLjEKUlVOIGRuZiBpbnN0YWxsIC15IGphdmEtMTctYW1hem9uLWNvcnJldHRvLWhlYWRsZXNzIHBlcmwgdW56aXAgd2dldCBhd3NjbGkgZ3ppcCB0YXIgJiYgZG5mIGNsZWFuIGFsbApSVU4gd2dldCAtcSAiaHR0cHM6Ly93d3cuYmlvaW5mb3JtYXRpY3MuYmFicmFoYW0uYWMudWsvcHJvamVjdHMvZmFzdHFjL2Zhc3RxY192JHtGQVNUUUNfVkVSU0lPTn0uemlwIiAtTyAvdG1wL2Zhc3RxYy56aXAgJiYgdW56aXAgL3RtcC9mYXN0cWMuemlwIC1kIC9vcHQgJiYgY2htb2QgK3ggL29wdC9GYXN0UUMvZmFzdHFjICYmIGxuIC1zIC9vcHQvRmFzdFFDL2Zhc3RxYyAvdXNyL2xvY2FsL2Jpbi9mYXN0cWMgJiYgcm0gL3RtcC9mYXN0cWMuemlwCkNPUFkgcnVuX2Zhc3RxYy5zaCAvdXNyL2xvY2FsL2Jpbi9ydW5fZmFzdHFjLnNoClJVTiBjaG1vZCAreCAvdXNyL2xvY2FsL2Jpbi9ydW5fZmFzdHFjLnNoCkVOVFJZUE9JTlQgWyIvdXNyL2xvY2FsL2Jpbi9ydW5fZmFzdHFjLnNoIl0K | base64 -d > Dockerfile && echo IyEvdXNyL2Jpbi9lbnYgYmFzaApzZXQgLWV1byBwaXBlZmFpbAoKOiAiJHtJTlBVVF9SMTo/SU5QVVRfUjEgaXMgcmVxdWlyZWR9Igo6ICIke09VVFBVVF9TMzo/T1VUUFVUX1MzIGlzIHJlcXVpcmVkfSIKSU5QVVRfUjI9IiR7SU5QVVRfUjI6LU5PTkV9IgpUSFJFQURTPSIke1RIUkVBRFM6LTJ9IgoKbWtkaXIgLXAgL3dvcmsvaW5wdXQgL3dvcmsvb3V0cHV0CgpSMV9MT0NBTD0iL3dvcmsvaW5wdXQvJChiYXNlbmFtZSAiJElOUFVUX1IxIikiCmF3cyBzMyBjcCAiJElOUFVUX1IxIiAiJFIxX0xPQ0FMIgpJTlBVVFM9KCIkUjFfTE9DQUwiKQoKaWYgW1sgIiRJTlBVVF9SMiIgIT0gIk5PTkUiICYmIC1uICIkSU5QVVRfUjIiIF1dOyB0aGVuCiAgUjJfTE9DQUw9Ii93b3JrL2lucHV0LyQoYmFzZW5hbWUgIiRJTlBVVF9SMiIpIgogIGF3cyBzMyBjcCAiJElOUFVUX1IyIiAiJFIyX0xPQ0FMIgogIElOUFVUUys9KCIkUjJfTE9DQUwiKQpmaQoKZmFzdHFjIC0tdGhyZWFkcyAiJFRIUkVBRFMiIC0tb3V0ZGlyIC93b3JrL291dHB1dCAiJHtJTlBVVFNbQF19Igphd3MgczMgY3AgL3dvcmsvb3V0cHV0LyAiJHtPVVRQVVRfUzMlL30vIiAtLXJlY3Vyc2l2ZQo= | base64 -d > run_fastqc.sh && ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) && REGION=$AWS_DEFAULT_REGION && ECR_URI=${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com/${ECR_REPOSITORY} && aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin ${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com && docker build -t ${ECR_URI}:${IMAGE_TAG} . && docker push ${ECR_URI}:${IMAGE_TAG}

エンコード前の Dockerfile の内容は以下のようなものです。

FROM public.ecr.aws/amazonlinux/amazonlinux:2023

ARG FASTQC_VERSION=0.12.1

RUN dnf install -y \
      java-17-amazon-corretto-headless \
      perl \
      unzip \
      wget \
      awscli \
      gzip \
      tar \
    && dnf clean all

RUN wget -q \
      "https://www.bioinformatics.babraham.ac.uk/projects/fastqc/fastqc_v${FASTQC_VERSION}.zip" \
      -O /tmp/fastqc.zip \
    && unzip /tmp/fastqc.zip -d /opt \
    && chmod +x /opt/FastQC/fastqc \
    && ln -s /opt/FastQC/fastqc /usr/local/bin/fastqc \
    && rm /tmp/fastqc.zip

COPY run_fastqc.sh /usr/local/bin/run_fastqc.sh

RUN chmod +x /usr/local/bin/run_fastqc.sh

ENTRYPOINT ["/usr/local/bin/run_fastqc.sh"]

FastQC を実行するシェルスクリプトのエンコード前は次の内容です。

#!/usr/bin/env bash
set -euo pipefail

: "${INPUT_R1:?INPUT_R1 is required}"
: "${OUTPUT_S3:?OUTPUT_S3 is required}"

INPUT_R2="${INPUT_R2:-NONE}"
THREADS="${THREADS:-2}"

mkdir -p /work/input /work/output

R1_LOCAL="/work/input/$(basename "$INPUT_R1")"
aws s3 cp "$INPUT_R1" "$R1_LOCAL"
INPUTS=("$R1_LOCAL")

if [[ "$INPUT_R2" != "NONE" && -n "$INPUT_R2" ]]; then
  R2_LOCAL="/work/input/$(basename "$INPUT_R2")"
  aws s3 cp "$INPUT_R2" "$R2_LOCAL"
  INPUTS+=("$R2_LOCAL")
fi

fastqc \
  --threads "$THREADS" \
  --outdir /work/output \
  "${INPUTS[@]}"

aws s3 cp \
  /work/output/ \
  "${OUTPUT_S3%/}/" \
  --recursive

今回は「ソースなし」の CodeBuild プロジェクトを使ったため、Dockerfile とシェルスクリプトを生成してから、Docker イメージをビルドして push するコマンドをビルドコマンド欄に設定しました。

CodeBuild のビルドコマンド設定

補足：ローカル環境でコンテナイメージを作成する場合

今回は AWS マネジメントコンソールだけで作業を完結させるため、CodeBuild を利用して FastQC 用のコンテナイメージを作成しました。

一方、手元の PC で Docker を利用できる場合は、ローカル環境でコンテナイメージを作成し、ECR へ直接 push することもできます。この方法では、CodeBuild プロジェクトや CodeBuild 用の IAM ロールを作成する必要はありません。

なお、ローカルで作成したコンテナイメージを、そのまま AWS Batch へ送ることはできません。AWS Batch から取得できるように、ECR などのコンテナレジストリへ保存する必要があります。

事前に必要なもの
ローカルPCに、次のツールを用意します。

• Docker
• AWS CLI
• AWS CLI で利用するAWS認証情報

Dockerfile と実行スクリプトを配置する
作業用のディレクトリを作り、その中に次の 2 ファイルを配置します。

fastqc-batch/
├── Dockerfile
└── run_fastqc.sh

CodeBuild では、これらのファイルを Build commands 欄へ 1 行で入力するために Base64 でエンコードしました。ローカル環境ではファイルを直接作成できるため、Base64 を使用する必要はありません。

ファイルを配置したディレクトリで、Docker を使ってコンテナイメージをビルドします。

ECR へコンテナイメージを push する
ECR のコンソールで対象のリポジトリを開き、画面右上の「プッシュコマンドを表示」を選択すると、利用中のアカウント ID、リージョン、リポジトリ名に対応したコマンドを確認できます。

ECR へのプッシュコマンド

表示されるコマンドには、ECR へのログイン、コンテナイメージのビルド、タグの付与、ECR への push が含まれています。基本的には、表示された順番に実行することで push を進められます。

デフォルトではイメージタグに latest が使われます。本記事の設定に合わせる場合は、タグを付与するコマンドと push するコマンドの latest を 0.12.1 に変更します。

push が完了したら、AWS マネジメントコンソールで ECR リポジトリを開きます。0.12.1 タグのイメージが表示されていれば成功です。

AWS Batch の Job definition には、CodeBuild で作成した場合と同様に、次の形式のイメージ URI を指定します。

AWSアカウントID.dkr.ecr.us-east-1.amazonaws.com/rna-seq/fastq-test:0.12.1

ECR への push 権限
コマンドを実行する IAM ユーザーまたは IAM ロールには、ECR へイメージを push する権限が必要です。

主に、次の操作に対する権限を使用します。（参照）

ecr:GetAuthorizationToken
ecr:BatchCheckLayerAvailability
ecr:InitiateLayerUpload
ecr:UploadLayerPart
ecr:CompleteLayerUpload
ecr:PutImage
ecr:BatchGetImage

権限が不足している場合は、docker push の実行時に AccessDenied などのエラーが表示されます。

CodeBuild を使う方法との違い

どちらの方法でも、最終的には FastQC 用コンテナイメージが ECR へ保存されます。そのため、ECR への push が完了した後の AWS Batch の設定や実行方法は変わりません。

ローカル PC に Docker を導入済みであれば、ローカルでビルドして ECR へ push する方が手順は短くなります。一方、ローカル環境を変更したくない場合や、ブラウザ上の操作だけで完結させたい場合は、CodeBuild を使う方法が適しています。

4. CodeBuild ロールに ECR への push 権限を付ける

CodeBuild が ECR へイメージを push できるように、CodeBuild のサービスロールへ IAM ポリシーを追加します。
IAM ロールのダッシュボードにある検索欄に "codebuild" と入力し、先ほど「新しいサービスロールを作成」を選択した際に作成されたロールを探し、ロール名をクリックします。

IAM ポリシー設定画面

許可ポリシーのセクション右上にある「許可を追加」→「インラインポリシーを作成」をクリックしてポリシーエディタを開きます。
ポリシーエディタ右上の「JSON」タブを選択し、ポリシーの内容を記述します。

今回は次のようなポリシーを設定しました。

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "GetEcrAuthorizationToken",
     "Effect": "Allow",
     "Action": [
       "ecr:GetAuthorizationToken"
     ],
     "Resource": "*"
   },
   {
     "Sid": "PushFastqcImage",
     "Effect": "Allow",
     "Action": [
       "ecr:BatchCheckLayerAvailability",
       "ecr:GetDownloadUrlForLayer",
       "ecr:BatchGetImage",
       "ecr:InitiateLayerUpload",
       "ecr:UploadLayerPart",
       "ecr:CompleteLayerUpload",
       "ecr:PutImage"
     ],
     "Resource": "arn:aws:ecr:us-east-1:AWSアカウントID:repository/rna-seq/fastq-test"
   }
 ]
}

この IAM ポリシーでは、Resource に ECR リポジトリの ARN を直接指定しています。したがって、リージョン名、AWS アカウント ID、リポジトリ名が先ほど作ったリポジトリと一致している必要があります。

5. AWS Batch 用の IAM ロールを作る

AWS Batch の Fargate ジョブでは、2 種類の IAM ロールを使用します。

名前が似ていますが、用途が異なります。

Execution role は、Fargate が ECR からコンテナイメージを取得し、実行ログを CloudWatch Logs へ送信するために使用します。一方、Job role は、実行中のコンテナから S3 などの AWS サービスへアクセスする際に使用します。

今回の構成では、FastQC コンテナが S3 から FASTQ を取得し、解析結果を S3 へ保存する際に Job role を使用します。

Execution role

Execution role には、次の AWS 管理ポリシーを付与します。

AmazonECSTaskExecutionRolePolicy

ロール名は、例えば次のようにします。

FastqcBatchExecutionRole

それでは、実際にロールを作成していきましょう。
まず、IAM ロールダッシュボード右上の「ロールを作成」ボタンからロール作成画面に入ります。

信頼されたエンティティタイプには、「AWS のサービス」、ユースケースには「ECS Task」をそれぞれ指定します。

許可ポリシーでは、AWS 管理ポリシーの「AmazonECSTaskExecutionRolePolicy」を検索して指定します。

Execution role の作成

Job role

Job role のロール名は次のようにしました。

FastqcBatchJobRole

このロールにも、信頼されたエンティティタイプとして「AWS のサービス」、ユースケースとして「ECS Task」 を指定します。

S3 へのアクセス権限は、AWS 管理ポリシーではなく、インラインポリシーで次のように設定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::バケット名-アカウントID-リージョン-an"
    },
    {
      "Sid": "ReadFastqInput",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::バケット名-アカウントID-リージョン-an/input_data/*"
    },
    {
      "Sid": "WriteFastqcOutput",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::バケット名-アカウントID-リージョン-an/output_data/*"
    }
  ]
}

オブジェクトの読み書き権限については、今回利用するプレフィックスに限定しています。input_data/ には読み取り、output_data/ には書き込みのみを許可します。

6. AWS Batch の Compute environment を作成する

続いて、AWS Batch の Compute environment を作成します。

設定は次のとおりです。

Compute environment の作成画面

最大 vCPU

Compute environment の「最大 vCPU」は、1 つのジョブに割り当てる vCPU 数ではなく、その環境全体で同時に使用できる vCPU 数の上限です。

一方、1 ジョブが使用する vCPU 数は Job definition で指定します。例えば、最大 vCPU が 4 の環境で、1 ジョブあたり 2 vCPU を使用する場合、最大で 2 ジョブを同時に実行できます。3 つ目以降のジョブは、実行中のジョブが終了し、vCPU に空きができるまで待機します。

今回は 1 サンプルの動作確認なので、最大 vCPU は 4 で十分です。

また、最大 vCPU を 256 にしても、256 vCPU が常時起動するわけではありません。
ただし、意図せず大量のジョブを投入すると、その上限までスケールする可能性があります。
コストを考えると、検証段階では小さめにしておく方が安全です。

作成後、Compute environment が次の状態になることを確認します。

状態：ENABLED
ステータス：VALID

作成後の Compute environment の詳細

EC2 は使わないのか？

AWS 上でアプリケーションを動かすことを考えたとき、最初に思いつくサービスは EC2（Elastic Compute Cloud）かと思います。実際、FastQC を 1 回実行するだけなら、 AWS Batch を使わずローカル PC や EC2 上で直接実行する方が簡単です。

本記事で AWS Batch を利用する目的は、単発の FastQC を効率化することではありません。サンプル数が増えたときに、複数の解析ジョブをあらかじめキューへ投入し、利用可能な計算リソースに応じて、ジョブを自動的に実行できる基盤を作ることが目的です。

そのため、最初から AWS Batch を使う前提で環境を作っています。

7. ジョブキューを作成する

次に、ジョブを受け付ける Job queue を作成します。
AWS Batch の左側メニューから「ジョブキュー」を選択し、右上の「作成」ボタンから作成を開始します。

設定は次のとおりです。

Job queue の作成画面

作成後は、次の状態を確認します。

状態：ENABLED
ステータス：VALID

作成後の Job queue の詳細

8. FastQC のジョブ定義を作成する

ジョブ定義には、実行するコンテナイメージや CPU、メモリ、IAM ロール、環境変数などを設定します。
今回は Fargate 用のジョブ定義を作成しました。

イメージには、CodeBuild で ECR へ push したイメージ URI を指定します。

AWSアカウントID.dkr.ecr.us-east-1.amazonaws.com/rna-seq/fastq-test:0.12.1

ジョブ定義のコンテナイメージ設定

環境変数

コンテナへ渡す入力・出力情報は、環境変数として設定しました。
paired-end の場合は、次の 4 つです。

例えば、次のような値になります。

INPUT_R1=s3://バケット名-アカウントID-リージョン名-an/input_data/sample1_R1.fastq.gz
INPUT_R2=s3://バケット名-アカウントID-リージョン名-an/input_data/sample1_R2.fastq.gz
OUTPUT_S3=s3://バケット名-アカウントID-リージョン名-an/output_data/
THREADS=2

single-end の場合は、INPUT_R2 を次のようにします。

INPUT_R2=NONE

ジョブ定義の環境変数

今回は 1 サンプルだけの検証だったため、S3 URI をジョブ定義へ直接設定します。
複数サンプルを処理する場合は、ジョブ投入時に値を上書きできるようにする方が使いやすいと思います。
スケジューリング優先順位は空欄のままにします。

9. FastQC ジョブを投入する

ジョブ定義と Job queue の準備ができたので、AWS Batch の「ジョブ」画面から「新しいジョブを送信」を選択します。

設定する内容は次のとおりです。

ジョブ送信画面

10. CloudWatch Logs で処理を確認する

ジョブの詳細画面からログストリームを開くと、CloudWatch Logs でコンテナの実行ログを確認できます。

今回のログでは、主に次の処理を確認できます。

• S3 から R1 をダウンロード
• S3 から R2 をダウンロード
• FastQC を実行
• S3 へ結果をアップロード

ジョブが失敗した場合も、まず CloudWatch Logs を見ることで、どの処理でエラーが発生したかを確認できます。

FastQC 実行時の CloudWatch Logs

最終的に、AWS Batch のジョブステータスが SUCCEEDED になりました。

ジョブの SUCCEEDED 画面

11. S3 に出力された FastQC レポートを確認する

最後に、S3 バケットの output_data/ を確認します。
paired-end の場合は、それぞれの FASTQ について HTML と ZIP が作成されます。

output_data/
├── sample1_R1_fastqc.html
├── sample1_R1_fastqc.zip
├── sample1_R2_fastqc.html
└── sample1_R2_fastqc.zip

S3 に出力された FastQC ファイル

HTML ファイルをダウンロードし、ローカルのブラウザで開くと、通常の FastQC レポートを確認できます。

ブラウザで開いた FastQC レポート

お疲れ様でした！

これで、AWS マネジメントコンソールから AWS Batch を使った FASTQ ファイルの品質チェックが完了しました
S3 上の FASTQ を AWS Batch で解析し、結果を S3 へ戻すところまで一通り確認することができました。
最初は設定に時間がかかるかもしれませんが、慣れればよりスムーズにできるようになります。

また、詳細は次のセクションで説明しますが、今回作成したリソースの中には、保持しているだけでは料金が発生しないリソースも多くあります。コンピューティング環境やジョブキュー、IAM ロールなどの一部のリソースは再利用できるため、次回は今回より少ない手順で環境を準備できます。

12. 後片付け

検証後は、不要なリソースを削除しましょう。

• CloudWatch Logs のロググループ
• 入力 FASTQ
• FastQC の結果
• CodeBuild プロジェクト
• ECR リポジトリ

ジョブを動かさなければ Fargate の料金は発生しない

Fargate は、実際にジョブが動いている間の vCPU・メモリなどに対して課金されます。
そのため、AWS Batch の Compute environment を残していても、ジョブを実行していなければ Fargate のコンピューティング料金は発生しません。

また、次のリソースは残しているだけでは基本的に料金が発生しません。

• AWS Batch
  • Compute environment
  • Job queue
  • Job definition
• IAM ロールとポリシー
• Default VPC
• サブネット
• セキュリティグループ

一方で、データを保存していると料金が発生する可能性があるのは、主に次のサービスです。

• S3
• ECR
• CloudWatch Logs

NAT Gateway には注意

今回は NAT Gateway を作成せず、Fargate ジョブにパブリック IP を割り当てる構成にしました。
NAT Gateway を作成している場合は、通信がなくても NAT Gateway が存在している時間に応じた料金が発生します。検証後に不要であれば削除が必要です。

まとめ

今回は、AWS Batch と Fargate を使い、S3 上の FASTQ ファイルを FastQC で解析しました。
実施した流れをまとめると次のとおりです。

• S3 へ FASTQ ファイルをアップロード
• ECR リポジトリを作成
• CodeBuild で FastQC コンテナを作成
• ECR へコンテナイメージを push
• AWS Batch 用の IAM ロールを作成
• Fargate の Compute environment を作成
• Job queue と Job definition を作成
• FastQC ジョブを投入
• S3 に出力された HTML レポートを確認

まず 1 サンプルを実行することで、AWS Batch における次の関係を一通り確認できました。

• ジョブ定義：何を、どのリソースで実行するか
• ジョブキュー：ジョブをどこで待機させるか
• コンピューティング環境：ジョブを実際にどの基盤で実行するか

今回は FastQC を組み込んだコンテナイメージを使用しましたが、コンテナに組み込むソフトウェアや実行スクリプトを変更すれば、同じ仕組みをほかのバイオインフォマティクス解析にも応用できます。例えば、リードのトリミングやマッピング、発現定量なども、対応するソフトウェアを含むコンテナイメージを用意することで AWS Batch 上で実行できます。