はじめに

技術の細かいことを書いても他と差別化できなそうなので、
まあ、ある程度ゆるい感じで書くのをお許しください。
（Qiitaっぽくない気もしますが）

簡単な自己紹介

初めまして。tsuyomatsuと申します。
最近はコードを書くのも稀になって、ひたすら会社むけの説明資料ばかり作っております（堕落）。
バリバリにコードを書いていた頃は、機械学習とかテキストマイニングが主戦場で、フルスクラッチの受託開発をやっていました。
空前のディープラーニングブームをよそに転職し、今は生命情報系の受託解析をやっている会社におります。

DRY解析を学ぶ

さて、こういう業界に来た以上、まずは解析の勉強しなきゃ、ということで、まずはこのあたりを読んだ上で、手を動かしてみました。

書かれてある通りにやってみれば、実際にちゃんと動くというのは偉大です。
実際に解析のツールをインストールしたりしていて思ったのは、

解析のための環境を準備するのは結構大変
組織としての最適な・効率的なあり方はどうなのか

うちの会社の解析者は、生命情報系（薬学、獣医学とか）のバックグラウンドをもつ研究者がメインなのですが、
システム系のリテラシーがすごく高い訳ではありません。
そのために私のような技術者もいて、彼らをサポートすることになるのですが、
技術者が管理しやすく、解析者が使いやすい仕組みってないかな？と思いました。

Galaxyとの出会い

そんなところ@suecharo 氏が「Galaxy参考になりますよ！」と教えてくれたので、
Galaxyのコミュニティにお邪魔したりして、知見を蓄えていきました。
その後、会社にもGalaxyのサーバを立てて、実案件でも活用しています。

Galaxyのセットアップについて

実サーバにインストールするにせよ、Dockerで動かすのが良いと思います。詳細は、
バイオインフォマティクス解析環境のGalaxyをMacのDockerで動かしてみるの記事が参考になります。

Docker使わず実サーバに入れたこともありましたが、
正直思い出したくないレベルで色々とあったので、ここでは割愛します。。。

Galaxy導入後

解析環境はこうなった

３台の物理サーバが動いています（2019年1月現在）。

解析用メインサーバ（OS：Ubuntu 16.04 LTS）
解析用サブサーバ（OS：Ubuntu 16.04 LTS）
Galaxyサーバ（OS：Ubuntu 14.04 LTS）

「手っ取り早くコマンド叩きたい」ってことはどうしてもあるので、
解析用のサーバが２台、Galaxyのサーバと別にあります。
OSは出来るだけ新しい安定しているバージョンに（でも18はまだ早いだろ）、
と思いつつ、GalaxyのDockerでは14が推奨されており、で結局こういうことに。
16.04だと動かない解析ツールとかもあって、その都度頑張って対応しています。
どのOSにしても簡単に動かないツールは必ずあるのですが。。。

導入して良かったこと

何より分かりやすいですよね。例えばインターンの子に手順を教えるとすると、
実際のコマンドを叩くのだとなかなか覚えてくれないようです。GUIは偉大。
あと、クオリティチェックとか画像まで手っ取り早く出てくれますし、
「俺はもうGalaxyしか使わない」って解析者もいます。

困っていること

データのバックアップ
過去の受託案件のデータも（問い合わせあったりするので）ある程度保存しなきゃいけません。
また、障害が起こるリスクとかもあるので適宜バックアップを取りたい。
が、解析結果のファイルを保存するのが結構厄介だったりします。
（Galaxyの内部IDとファイルが紐づいているようで、単にファイルを保存するだけだと後でなんのファイルか全く分からなくなってしまいます）
そうなると、「全体でバックアップ、削除」みたいなのが難しく、
結局個人がこまめに消していかないと溜まっていく一方なんですよね。。。
大抵ファイルサイズがかなりデカイので、運用で神経を使います。
ジョブ管理
多人数での使用になるので、それがスムーズになればいいなと。。。
きちんと作っていけば出来るのかもしれませんが、例えば適切なジョブ管理とか。
（優先したい処理の割り込みなど）

結論

実際に業務に使ってみて、色々と見えてきました。
「解析の仕組みをどう構築するか」ということを考える上で、良いたたき台になっています。

蛇足

結局最後は「解析業務のあり方」自体をどう設計するか？ということになると思うんです。
単一環境に複数のツールを入れる場合は、どうしても依存性が問題になりそうで、
（Pythonを複数バージョン入れたりとか）
じゃあ個別の処理を小さい単位でコンテナで動かせばいいやん、と思ったりします。
となるとクラウド的なアプローチでジョブ管理、リソース振り分けも柔軟になるはずですが、
解析結果のデータ量が大きすぎるんで、無茶苦茶金かかりそう。
再現性保証されてるから、別途やりゃいいんでしょうが。。。

とか、先人たちが歩んできた道にすっぱりとハマってしまったのでありました。
（車輪の再発明的な辛さを感じる）