Galaxy Advent Calendar 2017 の10日目の記事において inutano さんは、Galaxyのネガティブな面として以下の点を挙げていました。

インフラの知識がないとセットアップが難しい

特に大規模なサーバにジョブを分散したい場合など

そこで、本記事ではGalaxyを利用する側のことを考慮しながら実際に研究室等で環境構築・運用に関わるインフラ担当者の立場からGalaxyのセットアップについて取り上げてみたいと思います。

なお、ここで解説する内容は Galaxy Projectの公式サイト内にある Galaxy Administration のページに詳細な説明があります。
また、そのドキュメント自体も Galaxy Project の Github ページで管理されているため、もし疑問点や訂正すべき箇所などを見つけた場合は Issue やプルリクエストを送ることが可能です。

Galaxy の利用形態

Galaxy を利用する形態としては主に2種類があると思います。

Public Server （公共Galaxyサーバ）を利用する
これについては、haruosuz さんが 5,7,8日目の記事でご自身の専門分野の微生物関連を中心に解説されています。
世界中の様々な機関によってGalaxyをインストールしたWebサーバが公開されていますので、これらをアカウント申請してすぐに利用することができます。

自分の環境にGalaxyをインストールして利用する
もう一つは、自分用の専用サーバとして立ち上げる方法があります。
一般的なLinuxやmacOSが入っているマシンであればインストール自体はそれほど難しくはありません。

インターネットにアップロードできないデータを解析したい
自分で必要なツールを追加インストールしたい

といった場合にはこの方法を選択することになります。
国内コミュニティのピタゴラプロジェクトで配布しているVMもこの利用形態に含まれるでしょう。

今回のGalaxyセットアップについての話はこちらの利用形態に関する内容となります。

Galaxyの基本アーキテクチャ

まず最初に、Galaxy の基本的なアーキテクチャについて確認しておきましょう。
Galaxyのアーキテクチャの考え方は、利用者が直接操作するWeb UIの「フロントエンド」側と、データ解析処理を担うサーバ機能としての「バックエンド」側で異なります。それぞれの特徴は以下のとおりです。

フロントエンド
- できるだけシンプルで一貫性のあるユーザ操作を実現できることを原則とする
- 主な対象ユーザは実験系研究者であり、プログラミングやコマンドライン実行の知識・経験を前提としない
- 以下の要素技術が関連している
  - JavaScript driven
  - Backbone for MVC
  - webpack & RequireJS for modules
バックエンド
- プラグイン可能なインタフェースで構成され、多様な技術に適応可能なことを原則とする
- 以下のようなプラグイン可能な構成要素があり、利用するプラットフォームの要件に合わせて組み合わせる（スケールさせる）ことが可能
  - データベース・サーバ (by SQLAlchemy)
  - ジョブマネージャまたはクラスタ・バックエンド
  - ストレージ
  - フロントエンド(Web)プロキシ

もちろん、面倒なことを考えずにとりあえず起動したいという場合は、下図のような All-in-One 構成 での稼働も可能です。

Built in HTTP server (WSGI)
Built in database (SQLite)
Local job manager

単一サーバ構成のGalaxyを起動する

前述のような All-in-One 構成のGalaxyを起動するのは非常に簡単です。
この構成ではGalaxyのジョブはローカルサーバ内で実行されることになります。

実行環境に Python がインストールされた状態で、以下の手順で起動できます。

Galaxy Project の Github からソースコードを取得 git clone する
起動スクリプト run.sh を実行する

$ git clone -b release_17.09 https://github.com/galaxyproject/galaxy.git

Cloning into 'galaxy'...
remote: Counting objects: 320926, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 320926 (delta 1), reused 3 (delta 1), pack-reused 320917
Receiving objects: 100% (320926/320926), 396.37 MiB | 7.69 MiB/s, done.
Resolving deltas: 100% (256293/256293), done.

$ cd galaxy/
$ sh run.sh

Initializing config/migrated_tools_conf.xml from migrated_tools_conf.xml.sample
Initializing config/shed_tool_conf.xml from shed_tool_conf.xml.sample
Initializing config/shed_tool_data_table_conf.xml from shed_tool_data_table_conf.xml.sample
  :

Starting server in PID 6297.
serving on http://127.0.0.1:8080

run.sh コマンドを実行後、必要なソフトウェアパッケージ等をインターネットから取得するためネットワーク環境によっては時間がかかりますが、しばらく待てば Galaxy Web サーバが起動します。
Webブラウザから localhost:8080 にアクセスすれば、いつもの見慣れた Galaxy の画面が見られるはずです。

クラスタ構成のGalaxy環境

単一サーバ構成ではローカルサーバ上でしかジョブが実行されないため、巨大なデータや重い処理を扱うことが困難な場合があります。
バックエンド側のプラグインを設定することで、クラスタ上でジョブ実行できるように構成することが可能となります。

Galaxyではジョブのリモート実行・分散実行のための仕組みとして、すでにある様々な分散リソーススケジューラとの接続をサポートしています。

Univa Grid Engine
Slurm
HTCondor
PBS Professional
その他、DRMAA インターフェース対応製品

クラスタ構成のGalaxyをセットアップする際には、バックエンド側のプラグインとしてどれを選択すればよいか悩むところですが、まずは、オープンソースで最も手軽に利用できる組み合わせを試してみたいと思います。

長くなりましたので、続きはまた明日ということで

Reference

Galaxy Architecture
https://github.com/galaxyproject/galaxy/blob/master/doc/source/slideshow/architecture/galaxy_architecture.md
Galaxy Administration > Subtopics in Configuration > Running Galaxy Tools on a Cluster
https://galaxyproject.org/admin/config/performance/cluster/