Nabe International | Takeru Boost >> Takeruを回せ! >>

Galaxyをわかりたい! (5) Galaxy内部の動き

前回までの記事 Galaxyをわかりたい!(1) Galaxyのキホン Galaxyをわかりたい!(2) Galaxyの拡張機能紹介 Galaxyをわかりたい!(3) Dockerイメージをカスタマイズして使えるPythonやRStudio Galaxyをわかりたい!(4) Galaxyでのユーザー管理について 今回は管理者向けの内容となります。Galaxyのバックエンドのお話です。

Galaxyの構成

開発元からダウンロードしたGalaxyには以下の要素が含まれています。
  • webUIとデータの受け渡しを行うwebサーバー
  • ユーザーやジョブ等の情報を格納するデータベース
  • ジョブを実行するジョブマネージャー
いずれもGalaxyを起動するだけで使えるようになりますが、さらに高機能なものが必要な場合にはApacheやNginxをwebサーバーにしたり、データベースにpostgresqlを使うこともできます。またGalaxyはジョブマネージャーを経由してコマンドラインツールを実行しますが、Univa Grid Engineなどのジョブスケジューラとの連携にも対応しています。

アップロードしたデータセットはどこにあるのか

webUIからファイルをアップロードするとウィンドウ 右側のヒストリーパネルに表示されます。ヒストリー上の一つ一つのデータをGalaxyではデータセットと呼んでいます。このデータセットは、ホスト上では
[galaxyインストール先]/database/files
というディレクトリ 以下に配置されています。たとえば/home/galaxy/galaxyにインストールした場合、/home/galaxy/galaxy/database/filesです。パスはGalaxyの設定ファイルgalaxy.ymlで変更することができます。
$ ls /home/galaxy/galaxy/database/files/000
dataset_1.dat dataset_2.dat dataset_3.dat dataset_4.dat dataset_5.dat dataset_6.dat
dataset_7.dat dataset_8.datdataset_9.dat
格納されているファイル名はアップロードしたファイル名やヒストリーパネル上の名前ではなく、dataset_XX.datというファイル名となっています。XXはGalaxyの管理上のIDです。コマンドラインで直接ファイルを開くことも可能ですが、データセットはGalaxyデータベース上にメタデータがあり管理されています。たとえば実ファイルをrmコマンドで直接削除してしまうと、Galaxyデータベースとの不整合が生じてしまいます。 データセットやヒストリーをGalaxyのwebUI上でコピーするときは、ホスト上で実際にコピーするのではなく、Galaxyデータベース上のメタデータのみ新規に作成し、実ファイルは同じものを参照しています。それにより、余分なコピー時間がかからなくてすみ、ディスク容量の節約にもつながっています。

ツールはどこにあるのか

Galaxyにおいてtoolshedからツールをインストールすると、ツール定義するファイル、呼び出される実行コマンド群がGalaxyの定義するディレクトリ ツリー以下に配置されます。いずれもデフォルトでは以下のディレクトリ です。
[galaxyインストール先]/database/shed_tools
[galaxyインストール先]/database/dependencies
bowtie2ツールの定義ファイル(toolshedからダウンロードされる)
$ pwd
/home/galaxy/galaxy/database/shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/bowtie2/749c918495f7/bowtie2
$ ls
bowtie2_macros.xml test-data tool_data_table_conf.xml.sample
bowtie2_wrapper.xml tool-data
bowtie2の実行コマンド(condaを使ってインストールされている)
$ pwd
/home/galaxy/galaxy/database/dependencies/_conda/envs/mulled-v1-5bee08a20f60a5597c4ecd54735d608dc6a44caf6f433cd52f23c80aa5a38d02/bin
$ ls bowtie2
bowtie2

ジョブ実行時のワーキングディレクトリ

webUIからジョブをsubmitすると、ジョブ実行のためのワーキングディレクトリ が生成されます。デフォルトでは以下の場所です。
[galaxyインストール先]/database/job_working_directory
ジョブごとに一意のIDが付与され、そのIDの数字のサブディレクトリ が生成されます。そこに環境変数や入力データの情報、ジョブスクリプト、中間データ、exit codeなどが格納されます。 ワーキングディレクトリ は一時的なディレクトリ で、ジョブ終了に削除するかどうかを galaxy.ymlで設定することができます。中間データを残しておくとツールがうまく実行されない場合のエラー分析の際に便利です。3つの選択肢があるので、運用上のバランスを考えて設定するとよいでしょう。
  • Always: ジョブの正常終了・エラーに関わらず常に削除する。(デフォルト)
  • Sucess: ジョブが正常終了した場合のみ削除する。
  • Never: ジョブの正常終了・エラーに関わらず常に残す。

Galaxyデータベースにはどんな情報があるのか

GalaxyはSQLデータベースでユーザー・グループの情報、ジョブの情報、ヒストリー・データセット・ツールのメタデータなどを管理しています。デフォルトはsqliteですが、実運用の場合はpostgresqlが推奨されています。 https://galaxyproject.github.io/training-material/topics/admin/tutorials/database-schema/tutorial.html たとえば、[アップロードしたデータセットはどこにあるのか]の項でふれたように、weUIのヒストリーから見えるデータセットの名前は、Galaxyデータベースに格納されています。ホスト上のファイル名(dataset_XX.dat)とは別のメタデータであり、ヒストリーやデータセットのIDと紐づけられているので、Galaxy内でデータセット名が重複しても問題ありません。 psqlを使用してコマンドラインからGalaxyデータベースにアクセスできますが、SQL文に慣れていないとちょっと大変です。Galaxy開発元が提供しているgxadminというユーティリティを使用することで、「ユーザーごとのジョブ情報」「ヒストリー一覧」など管理上よく使用する情報を簡単に得ることができます。 https://training.galaxyproject.org/training-material/topics/admin/tutorials/gxadmin/ tutorial.html たとえば、以下は直近10日間に実行されたジョブの一覧です。
$ gxadmin query recent-jobs 240
id | create_time | tool_id | state | coalesce
----+-------------------------------+---------+-------+----------
29 | 2020-06-10 17:12:35.019636+09 | upload1 | ok | galaxy
28 | 2020-06-10 17:12:34.604904+09 | upload1 | ok | galaxy
27 | 2020-06-10 17:12:33.966389+09 | upload1 | ok | galaxy
(3 rows)
あらかじめ用意されたクエリのほか、自分で作成したクエリを登録しておくこともできます。以下の例は全ユーザーについてヒストリーとデータセットを一覧にするクエリです
$ gxadmin local query-alldatasets |sed -e "s/ //g"
email|history_id|history_name|id_in_the_history|dataset_name|dataset_id|size_or_error|extension|association_id|tool_version
-------------------------------+------------+-----------------+-------------------+-----------------------------------------+------------+------------------------------+-------------+----------------+--------------
beowulf@localhost.localdomain|4|Unnamedhistory|2|c1-r1-r-x_2.fastqsanger|3|13.4MB|fastqsanger|3|
beowulf@localhost.localdomain|4|Unnamedhistory|1|c1-r1-f-x_1.fastqsanger|2|13.4MB|fastqsanger|2|
galaxy@localhost.localdomain|2|test1|9|Text_reformatting.tabular.txt|29|17,559lines|txt|29|
galaxy@localhost.localdomain|2|test1|8|ipython_galaxy_notebook.ipynb|28|JupyterNotebook|ipynb|28|
galaxy@localhost.localdomain|2|test1|7|GSM461176_untreat_single.counts.tabular|27|17,559lines|tabular|27|
--以下省略--

webUIで見られる内部情報

ここまでご紹介した内容は、ホストにログインして確認したものですが、一部はwebUIからわかるものもあります。

データセットの情報

ヒストリーにあるデータのiアイコン(画像右側の青丸で囲まれた箇所)をクリックすると、そのデータに関する詳細な情報が表示されます。GalaxyがつけるIDジョブの情報、ホストにおけるデータファイルの配置場所などです。データファイル名はヒストリーパネル上の名前ではなく管理IDをもとにつけられますので、ホストにログインして実際のデータファイルを探すときに手がかりとなります。

ツールの情報

管理者アカウントでGalaxyにログインすると、管理者用ページのインストールされたツール一覧が見られます。各ツールをクリックすると、そのツールの詳細やプログラムがどこにインストールされているか等の情報が見られます。 今回ご紹介した内容は、通常webUIからは使用する分には意識する必要がありませんが、知っておくと管理運用やエラー分析に役立ちます。次回も管理者・開発者向けの内容として、Galaxy APIを実行するライブラリBioblendをご紹介します。