AWS Batch で BUSCO を実行したときの “Metaeuk did not recognize any genes matching the dataset eukaryota_odb10 in the input file.” エラーの原因と対処方法

AWS Batch で BUSCO を実行していたときに BUSCO のログ（logs/busco.log）に以下のエラーが記録され解析処理に失敗しました。原因と対処方法の一例を紹介します。

logs/busco.log

ERROR:busco.BuscoRunner     Metaeuk did not recognize any genes matching the dataset eukaryota_odb10 in the input file. If this is unexpected, check your input file and your installation of Metaeuk

原因・対処まとめ

ジョブの指定したメモリが不足していたためOutOfMemoryError: Container killed due to memory usageが発生していた。

ジョブの履歴よりジョブの失敗の理由を確認できる

ジョブ実行時のメモリ指定を増やして再実行してOutOfMemoryErrorは解消し、正常に BUSCO の解析処理が完了した。

状況

実行環境

EC2 Spot を利用するコンピューティング環境の AWS Batch で BUSCO コンテナを起動し解析処理を実行していました。

エラーメッセージ

ジョブが失敗したためlogs/busco.logを確認し以下のエラーメッセージを確認しました。

Metaeukはインプットファイル中にデータセット（eukaryota_odb10）にマッチする遺伝子を見分けられない。ということですが、AWS Batch 以外の環境（ローカルPC、Docker on EC2、Docker on ParallelCluster）ですと同じパラメータ指定で BUSCO コマンドを実行して解析できていました。

logs/busco.log

2022-03-11 07:03:35 INFO:busco.busco_tools.Toolset      Running 1 job(s) on metaeuk, starting at 03/11/2022 07:03:35
2022-03-11 07:03:36 DEBUG:busco.busco_tools.Toolset     cmd call: metaeuk easy-predict --threads 24 /mnt/efs/GCF_000001215.4_Release_6_plus_ISO1_MT_genomic.fna /busco_wd/busco_downloads/lineages/eukaryota_odb10/refseq_db.faa /busco_wd/GCF_000001215.4_Release_6_plus_ISO1_MT_genomic.fna_BUSCO5_test/run_eukaryota_odb10/metaeuk_output/initial_results/GCF_000001215.4_Release_6_plus_ISO1_MT_genomic.fna /busco_wd/GCF_000001215.4_Release_6_plus_ISO1_MT_genomic.fna_BUSCO5_test/run_eukaryota_odb10/metaeuk_output/tmp --max-intron 130000 --max-seq-len 160000 --min-exon-aa 15 --max-overlap 15 --min-intron 5 --overlap 1
2022-03-11 07:04:21 INFO:busco.busco_tools.Toolset      [metaeuk]       1 of 1 task(s) completed
2022-03-11 07:04:21 ERROR:busco.BuscoRunner     Metaeuk did not recognize any genes matching the dataset eukaryota_odb10 in the input file. If this is unexpected, check your input file and your installation of Metaeuk

Metaeukとは？から調べていきます。

MetaEuk は真核生物の Metagenomic contigs における大規模な遺伝子の発見とアノテーションするために設計されたモジュールツールキットのことでした。単純に解析ツールが解析できなかったということのようです。

エラーメッセージで検索するとこちらのリンクがヒットし参考になりました。巨大なゲノムを BUSCO で解析かけると一時的にメモリか、ストレージを大量に必要するため AWS Batch で起動したコンテナか、ホストの EC2 のスペック不足が疑われます。

AWS Batch デフォルトのローカルストレージサイズは？

現在、AWS Batch のホストとなる EC2 が Amazon Linux 2 ベースの場合、30 GBのルートボリュームを持っています。

You can modify the 30-GiB root volume size at launch time to increase the available storage on your container instance. T

引用: AMI storage configuration - Amazon Elastic Container Service

ボリュームサイズが不足する場合は以下のエントリを参考にしてください。

AWS Batch ジョブログを確認

ジョブの実行ログを確認すると原因が載っていました。

ジョブのログは左ペインのジョブからジョブキュー（私の環境ではec2-queueという名前）を選択するとジョブ履歴を確認できます。

該当のジョブをクリックして詳細を開き、画面中腹までスクロールすると理由が表示されています。今回の原因はメモリ不足で BUSCO コンテナが落ちていました。

OutOfMemoryError: Container killed due to memory usage

OutOfMemoryError

AWS Batch の実態は ECS on EC2 か、Fargate ですので ECS のユーザーガイドも参照することになります。ECS のユーザーガイドのトラブルシュートページを確認するとOutOfMemoryErrorについての説明があります。

This error occurs when a container exits due to processes in the container consuming more memory than was allocated in the task definition.

引用: Stopped tasks error codes - Amazon ECS

コンテナのメモリ増やして再実行

コンテナで使用するメモリサイズは簡単に指定できます。新しいジョブは4GB指定だったコンテナを16GB指定に変更しました。

実行ログの結果確認

ステータスはSUCCEEDEDと表示され正常されました。実際に BUSCO の解析処理が走りきったことは実行結果から確認しました。

メモリは16GB指定になっているのも確認できます。

おわりに

構築中の動作確認中の出来事だったのですが、従量課金で利用できるクラウドHPCを使っているにもかかわらずスペックをケチると、不必要なトラブルシュートで貴重な時間を失うという過去に何度も経験してきたやつでした。 スポットインスタンスを利用して格安にハイスペックインスタンスを使えるので、動作確認でも計算リソースは過剰にケチらないことを教訓にしたいと思います。