基于Graviton2处理器构建容器化基因分析工作负载

概述

很多医疗和生信行业的客户都在云上运行他们的基因分析任务，基因分析是一个典型的高性能计算（HPC）工作负载，极度依赖于算力，一个项目经常会需要用到几千核的CPU用于计算，所以性能和成本就成为了客户非常关注的点，他们希望能有更好的性能和更低的成本。

相对于基于传统x86架构的处理器来说，AWS设计的基于ARM架构的Graviton处理器为EC2中运行的云工作负载提供了更佳的性价比。基于 Graviton2 的实例支持广泛的通用型、突发型、计算优化型、内存优化型、存储优化型和加速计算型工作负载，包括应用程序服务器、微服务、高性能计算 (HPC)、基于 CPU 的机器学习 (ML) 推理、视频编码、电子设计自动化、游戏、开源数据库和内存中的缓存等。由Graviton2 处理器支持的EC2实例 (M6g、C6g、R6g和T4g) 在中国区已经上线一段时间，本文以土壤微生物宏基因测序为例，来演示如何利用AWS Batch服务调用基于Graviton2处理器的实例用于基因分析，并且验证Graviton2相对于x86架构的处理器能够给用户带来的收益。

先决条件

您需要一个AWS帐户来完成本演练，其它条件包括（本篇不再描述其具体使用方式）:

AWS CLI v2安装和配置
完成VPC的设置，包括公有子网、私有子网和NAT的配置等
熟悉EC2服务的使用，熟悉EFS、S3等存储服务的使用
熟悉Batch服务的使用，包括计算环境、任务队列、任务定义的配置
熟悉生信软件（bwa，samtools，coverm）的安装配置
熟悉容器的使用

整体架构

本文演示了一个基于AWS Batch服务来进行任务调度的方案，Batch是AWS托管的一个批量计算服务，用户可以通过它运行任意规模的容器化工作负载，目前已经广泛应用于基因分析、药物研发等高性能计算的场景。本方案整体架构及用到的服务如下：

方案描述：

Batch 批量计算任务调度，启动大量计算节点用于计算
S3 存储输入和输出数据
EFS 映射到容器中，用于存放运行脚本
DynamoDB 保存输入数据的信息及处理状态，运行脚本从中读取需要处理的文件列表并更新处理状态
ECR 作为容器镜像仓库
CloudWatch 监控性能指标及查看日志
开源软件goofys，挂载S3存储桶到容器中，简化S3上数据读取方式，优化S3到EC2的数据读取性能
跳板机，用于操作云上资源

软件适配

把原先在x86架构下的工作负载迁移到ARM架构下，首先我们要在ARM架构下完成软件的适配。本次演示主要用到bwa，samtools和coverm三个软件，以下演示如何在ARM架构下完成对这些软件的编译并且构建容器镜像。

EC2

启动一台EC2使用作为开发环境，AMI：Amazon Linux2，实例类型t4g.medium(必须是Graviton机型)。若在中国区编译coverm碰到网络问题，可在Global区域启动该EC2，做完容器镜像后直接推送回中国区的ECR。

安装Docker

sudo yum update -y
sudo amazon-linux-extras install docker -y
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -a -G docker ec2-user

登录EC2安装docker后，退出，再重新登录以接受新的 docker 组权限

AWSCLI v2

curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

配置好中国区AK/SK，为了后续推送容器镜像到国内ECR

基础镜像

docker pull centos

创建一个目录用于保存后续构建容器镜像需要的文件

mkdir docker
cd docker

bwa

wget https://github.com/lh3/bwa/releases/download/v0.7.17/bwa-0.7.17.tar.bz2
wget https://gitlab.com/arm-hpc/packages/uploads/ca862a40906a0012de90ef7b3a98e49d/sse2neon.h

samtools

wget https://github.com/samtools/samtools/releases/download/1.15.1/samtools-1.15.1.tar.bz2

coverm

起一个容器编译coverm

docker run --name coverm -v /home/ec2-user/docker:/data -itd centos

进入容器

docker exec -it coverm bash
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-* 
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
yum install git gcc cmake3 -y
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
git clone https://github.com/wwood/CoverM
cd CoverM
cargo build --release

复制可执行文件到外部存储

cp target/release/coverm /data/coverm

goofys

goofys用于将S3存储桶映射到容器中，简化S3文件读取，将文件直接从S3读取到EC2内存，无需落盘，从而加快文件读取速率

编译

yum install go
git clone https://github.com/kahing/goofys.git
cd goofys
GOOS=linux GOARCH=arm64 go build

复制可执行文件到外部存储

cp goofys /data/goofys

退出容器

exit

镜像构建

确保bwa-0.7.17.tar.bz2, samtools-1.15.1.tar.bz2, coverm, goofys, awscliv2.zip和sse2neon.h已经保存到之前创建的docker目录，编辑如下Dockerfile：

FROM centos
ADD bwa-0.7.17.tar.bz2 samtools-1.15.1.tar.bz2 coverm goofys awscliv2.zip sse2neon.h /opt/

WORKDIR /opt
RUN \ 
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-* && \
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-* && \
yum install unzip gcc-c++ make autoconf ncurses-devel bzip2 bzip2-devel xz-devel zlib-devel fuse fuse-devel -y && \
yum clean all && \
#awscli
unzip awscliv2.zip && \
./aws/install && \
rm -rf awscliv2.zip aws && \
#bwa
cd bwa-0.7.17 && \
sed -i -e 's/<emmintrin.h>/"sse2neon.h"/' ksw.c && \
mv /opt/sse2neon.h . && \
make && \
cd .. && \
#samtools
cd samtools-1.15.1 && \
autoheader && \
autoconf -Wno-syntax && \
./configure && \
make && \
make install && \
cd .. && \
#coverm
mkdir tools && \
mv coverm tools && \
#goofys
mv goofys tools

WORKDIR /data

ENV PATH=$PATH:/opt/bwa-0.7.17:/opt/tools/

构建镜像

docker build -t mapping-graviton .

创建ECR镜像仓库mapping-graviton并查看推送命令推送镜像到该仓库

云上环境设置

S3

S3存储桶包含3个目录

source目录存放输入序列，results存放结果数据

ref_data目录存放参考基因组的索引库

DynamoDB

创建一张表用于保存S3上的输入序列信息，投递任务的脚本从表中读取需要处理的基因序列列表，循环投递任务。在任务运行的时候，根据不同的处理阶段，更新表中对应序列的状态值。

参照以下命令向表中插入数据：

aws ddb put reads_graviton '{sample: 'SRR11676645', r1: 'source/SRR11676645_1.fastq.gz', r2: 'source/SRR11676645_2.fastq.gz', status: '0'}'

EFS

创建一个EFS文件系统(fs-0a8685ad57ce63a3f)，开发环境挂载EFS文件系统，在文件系统中创建mapping目录，保存mapping.sh到该目录下（放在容器外面主要是为了调试及修改方便，不用每次都重新构建镜像）

EC2启动模板

修改根卷为gp3，200G（根据实际需要调整大小），设备名称指定自定义值/dev/xvda

在测试阶段，若需要监控内存使用率，可在高级详细信息→用户数据，输入以下CloudWatch Agent配置

在生产阶段，如果有大量任务运行，建议不要配置CloudWatch Agent，因为有可能产生指标数量过多的费用

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
yum install amazon-cloudwatch-agent -y
cat << EOF > /opt/aws/amazon-cloudwatch-agent/bin/config.json 
{
    "agent": {
        "metrics_collection_interval": 30,
        "run_as_user": "root"
    },
    "metrics": {
        "append_dimensions": {
            "InstanceId": "\${aws:InstanceId}",
            "InstanceType": "\${aws:InstanceType}"
        },
        "metrics_collected": {
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 30
            },
            "swap": {
                "measurement": [
                    "swap_used_percent"
                ],
                "metrics_collection_interval": 30
            }
        }
    }
}
EOF
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

--==MYBOUNDARY==--

IAM角色

Batch需要的两个角色，附加合适的权限

ecsInstanceRoleBatchJobRole

计算环境

创建配置文件ce.json：

subnets：配置了NAT网关路由的私有子网

securityGroupIds：默认安全组id

instanceTypes：使用的r6g实例类型
tags：EC2标签

123456789012：换成您自己的12位AWS账户id

{
    "computeEnvironmentName": "env-mapping-graviton",
    "type": "MANAGED",
    "state": "ENABLED",
    "computeResources": {
        "type": "EC2",
        "allocationStrategy": "BEST_FIT",
        "minvCpus": 0,
        "maxvCpus": 2560,
        "desiredvCpus": 0,
        "instanceTypes": [
            "r6g"
        ],
        "subnets": [
            "subnet-03388bca5b37db2b9",
            "subnet-0fafc120e429ec25d"
        ],
        "securityGroupIds": [
            "sg-0468dd9696811b7b8"
        ],
        "instanceRole": "arn:aws-cn:iam::123456789012:instance-profile/ecsInstanceRole",
        "tags": {
            "Name": "batch-mapping-graviton"
        },
        "launchTemplate": {
            "launchTemplateName": "lt-batch-zju",
            "version": "9"
        }
    },
    "serviceRole": "arn:aws-cn:iam::123456789012:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch"
}

创建计算环境

aws batch create-compute-environment --cli-input-json file://ce.json

任务队列

创建配置文件jq.json:

computeEnvironment：上一步创建的计算环境的arn

{
    "jobQueueName": "q-mapping-graviton",
    "state": "ENABLED",
    "priority": 1,
    "computeEnvironmentOrder": [
        {
            "order": 1,
            "computeEnvironment": "arn:aws-cn:batch:cn-northwest-1:123456789012:compute-environment/env-mapping-graviton"
        }
    ]
}

创建任务队列

aws batch create-job-queue --cli-input-json file://jq.json

任务定义

创建配置文件jd.json：

privileged: 容器中运行goofys需要开启特权模式，设为true

{
    "jobDefinitionName": "jd-mapping-graviton",
    "type": "container",
    "parameters": {
        "r2": "source/SRR11676645_2.fastq.gz",
        "dbtable": "reads_graviton",
        "sample": "SRR11676645",
        "script": "mapping.sh",
        "r1": "source/SRR11676645_1.fastq.gz"
    },
    "containerProperties": {
        "image": "123456789012.dkr.ecr.cn-northwest-1.amazonaws.com.cn/mapping-graviton:latest",
        "command": [
            "sh",
            "Ref::script",
            "Ref::sample",
            "Ref::r1",
            "Ref::r2",
            "Ref::dbtable"
        ],
        "jobRoleArn": "arn:aws-cn:iam::123456789012:role/BatchJobRole",
        "volumes": [
            {
                "name": "efs",
                "efsVolumeConfiguration": {
                    "fileSystemId": "fs-0a8685ad57ce63a3f",
                    "rootDirectory": "mapping"
                }
            }
        ],
        "environment": [
            {
                "name": "S3_MOUNT_POINT",
                "value": "/s3"
            }
        ],
        "mountPoints": [
            {
                "containerPath": "/data",
                "sourceVolume": "efs"
            }
        ],
        "privileged": true,
        "resourceRequirements": [
            {
                "value": "64",
                "type": "VCPU"
            },
            {
                "value": "500000",
                "type": "MEMORY"
            }
        ]
    },
    "platformCapabilities": [
        "EC2"
    ]
}

注册任务定义

aws batch register-job-definition --cli-input-json file://jd.json

任务脚本mapping.sh

实际任务运行所调用的脚本（保存到EFS的mapping目录下）

sample=$1
r1=$2
r2=$3
dbtable=$4
echo 'sample: '$sample', r1: '$r1', r2: '$r2', dbtable: '$dbtable

echo 'mount s3 bucket'
mkdir -p $S3_MOUNT_POINT
goofys --region cn-northwest-1 sun-test $S3_MOUNT_POINT
base_dir=$S3_MOUNT_POINT
ls -lh $base_dir

echo 'job done set status to 1'
aws dynamodb execute-statement --statement "UPDATE $dbtable SET status=1 WHERE sample='$sample'"

echo 'bwa start'
mkdir /result
bwa mem -t 64 $base_dir/ref_data/derep_all.fa $base_dir/$r1 $base_dir/$r2 > /result/$sample.sam
echo 'samtools start'
samtools sort /result/$sample.sam -@ 64 -o /result/$sample.bam
echo 'rm sample'
rm /result/$sample.sam

echo 'job done set status to 2'
aws dynamodb execute-statement --statement "UPDATE $dbtable SET status=2 WHERE sample='$sample'"

echo 'coverm filter start'
coverm filter --min-read-percent-identity 0.95 --min-read-aligned-percent 0.75 -b /result/$sample.bam -o /result/${sample}_filter.bam -t 64
echo 'copy '${sample}_filter.bam' to s3'
mkdir -p $base_dir/results/$dbtable
cp /result/${sample}_filter.bam $base_dir/results/$dbtable/

echo 'job done set status to 3'
aws dynamodb execute-statement --statement "UPDATE $dbtable SET status=3 WHERE sample='$sample'"

echo 'rm result '$sample.bam' from local disk'
rm /result/$sample.bam

echo 'coverm contig start'
coverm contig --trim-max 90 --trim-min 10 --min-read-aligned-percent 70 -t 64 --bam-files /result/${sample}_filter.bam > /result/${sample}_coverage.csv
echo 'copy to s3'
cp /result/${sample}_coverage.csv $base_dir/results/$dbtable

echo 'job done set status to 4'
aws dynamodb execute-statement --statement "UPDATE $dbtable SET status=4 WHERE sample='$sample'"

echo 'rm result '${sample}_filter.bam' from local disk'
rm /result/${sample}_filter.bam

run_mapping.sh

通过run_mapping.sh来读取数据库中序列信息并循环提交多个Batch任务，该脚本可在跳板机或本地执行

dbtable='reads_graviton'
item=`aws ddb select $dbtable --filter 'status = 0' `
count=`echo $item | awk '{print $2}'`
echo 'count: '$count
if [ $count -eq 0 ]
then
        echo 'end'
        break
fi
info=`echo $item | awk '{for(i=10;i<=NF;i=i+9){print $i}}'`
fastq_1=`echo $item | awk '{for(i=6;i<=NF;i=i+9){print $i}}'`
fastq_2=`echo $item | awk '{for(i=8;i<=NF;i=i+9){print $i}}'`

for ((i=1;i<=$count;i++))
do
        sample=`echo $info|awk '{print $'$i'}'`
        echo 'sample= '$sample
        r1=`echo $fastq_1|awk '{print $'$i'}'`
        echo 'r1= '$r1
        r2=`echo $fastq_2|awk '{print $'$i'}'`
        echo 'r2= '$r2      
        jobname=${dbtable}_${sample%.*}
        echo 'jobnane= '$jobname
        aws batch submit-job --job-name $jobname --job-queue q-mapping-graviton --job-definition jd-mapping-graviton:1 --parameters script=mapping.sh,sample=$sample,r1=$r1,r2=$r2,dbtable=$dbtable
done

测试

按照类似的方法再创建一套基于x86架构的Batch计算环境、任务队列、任务定义（不再赘述创建方法），相同的任务分别投递到arm和x86环境，进行对比测试。

单个序列比对任务需要用到的内存为300G+，故使用类型为r6g.16xlarge和r5.16xlarge的EC2实例进行对比测试, 测试结果如下：

CPU/MEM监控-CloudWatch

SRR11676645

SRR11676933

FDMS190655335

在计算阶段，r6g.16xlarge和r5.16xlarge的资源利用率几乎一致，CPU利用率都能到100%，内存利用率都为60%左右

用时

序列	x86 (r5.16xlarge)	graviton(r6g.16xlarge)	时间节约
SRR11676645	1 小时 28 分钟 51 秒	1 小时 14 分钟 11 秒	16.51%
SRR11676933	1 小时 2 分钟 29 秒	51 分钟 28 秒	17.63%
FDMS190655335	3 小时 36 分钟 51 秒	3 小时 2 分钟 31 秒	15.83%

r6g.16xlarge相对r5.16xlarge所需时间大约减少16%左右

EC2价格对比

实例类型	r5.16xlarge	r6g.16xlarge	节约
按需	28.26	22.433	20.60%
RI一年无预付标准	8.799	6.986	20.60%
Spot	8.6084	6.6137	23.20%

r6g.16xlarge相对r5.16xlargeEC2价格大约下降20%左右

结论

基于Batch的任务调度，在计算任务完成之后，Batch会自动终止不再运行任务的EC2实例，所以时间的节约也能带来EC2和EBS的成本节约。根据以上测试结果，在基因测序序列比对这个场景下，使用ARM架构的Graviton实例，相对于5代x86实例，能有：

16%左右时间节约

16%左右EBS成本节约
1 – (1-16%) x (1-20%) = 32.8%左右EC2成本节约

在这篇文章中，我们演示了如何基于Graviton2处理器所支持的EC2实例，在AWS上使用Batch服务来运行基因测序的工作负载。并且根据测试的结果，使用Graviton2处理器用于基因测序的序列比对场景，能够很好的满足用户对于性能和成本的需求。只要您的工作负载所用的操作系统和软件能够适配ARM架构，在AWS上就可以利用Graviton处理器高性价比的特点来达到降本增效的目的。

参考文档

AWS Batch用户指南：

https://docs.aws.amazon.com/zh_cn/batch/latest/userguide/what-is-batch.html

利用 AWS Batch 来为容器化负载调用海量云端算力：

https://aws.amazon.com/cn/blogs/china/use-aws-batch-to-call-massive-cloud-computing-power-for-containerized-loads/

A generalized approach to benchmarking genomics workloads in the cloud: Running the BWA read aligner on Graviton2：

https://aws.amazon.com/cn/blogs/publicsector/generalized-approach-benchmarking-genomics-workloads-cloud-bwa-read-aligner-graviton2/

选择您的 Cookie 首选项

亚马逊AWS官方博客