On Genome annotation Pipeline

H.Sugawara & A. Ooyama (Insilico biology)

１．バイオにおける解析の性質に応じてPCクラスターを　最適かつ動的に運用できるようにしたい.
＃　スパコンの仕様も以下の考えもいれて策定されたと理解していますが 注）分類すると同然その中間的なものが発生する たとえば、pairwiseはA)とB)の中間、ClustalWは b)とc)の中間
 * 1) A) ごく短時間（sub second）で終了するジョブを多数実行する　→　小規模なコアで十分
 * 2) *例　Glimmer, MGA等の遺伝子予測 ORF単位ではSub Secondですが、１つのゲノム上の全ORF予測では、数分間はかかります. いずれにしても、大きな負荷にはなりえません.
 * 3) B) 数分かかるジョブを多数実行する →　多数のコアが必要
 * 4) *　例　blast
 * 5) C) 数時間かかるじょびを少数実行する　→　大メモリが必要
 * 6) *例　Velvet

２．MiGAP、GTPSその他のアプリケーションと、それらが使う部品との関係
(ooyama)昨日はBlastだけと申し上げましたが、MiGAPではMetaGeneAnnotator, rRNAmmer, AUGUSTUS等すべての処理をSGE経由で投入していますので、それらもWrapper経由にする必要があります.
 * 1) 〇異なるアプリケーションが使う共通の部品がある（例　blast, 参照DB）
 * 2) 〇各アプリケーションが必要な部品をそれぞれ用意するのは効率が悪い.
 * 3) 〇部品を共通化するためには、何が必要か？
 * 4) *・ 部品からみると異なる複数のアプリケーションから呼ばれることになるので、この要求が交通整理されている必要がある.
 * 5) *・　アプリケーション側から見ると、交通整理の仕方や部品の使い方を意識することなく、単に要求を送ればよいだけになっていてほしい.
 * 6) 〇部品の運用とジョブ制御は、アプリケーションに依存しない形で共通化できるはず. 　→　４日はwrapperを作る、ということで話が進みました.

３．MiGAPから見た場合

 * 1) 〇部品の用意から制御まで組み込んであるので、今後のメンテにも　コストがかかる. 環境が変わると、制御系の方が大きく影響をうけますが、変わらなければコストは発生しない可能性もあります.
 * 2) 〇部品の運用とジョブ制御の共通基盤があれば、MiGAPを含む アプリケーションの運用コストは大幅に削減できる見込み.
 * 3) 〇しかし、システム設計と開発に初期投資が必要なので、初期投資と５年間の運用経費を足したものが、本当に節約になるのか十分な検討が必要

４．項目１から３をまとめると、

 * 1) 〇部品となるプログラムの設定とその性質の分類
 * 2) 〇それぞれの性質にあったノード群を割り当て
 * 3) 〇複数のアプリケーションからの要求を最適にさばくようなジョブ制御を行う （タイプA)にはSunGridEngineで十分対応可能）
 * 4) 〇アプリケーションから見たときに、部品の機能が抽象化されていること
 * 5) 〇部品の共通基盤ができれば、MiGAPとGTPSがそれぞれ動いていてもかまわない（パイプラインから作り直す必要は無い）.
 * 6) 〇ただし、MiGAPは（ある意味で逆に）部品のメンテや制御の部分を切り離すための改造が必要

５．ＤＤＢＪにおけるシステム開発の共通ポリシー
参画エンジニアがポリシーを共有することがきわめて重要（それがないと、また、建て増しを繰り返した老舗温泉旅館状態になる）

６．参照ＤＢについて

 * 1) 〇TreMBLやNRなどのDBはメモリーに乗ることが重要. 試算では５年後には20Gのメモリーが必要　（blast DBの大きさとして）
 * 2) 〇参照DBは一括管理して、各ノードからNSFマウントすることでよいのではないか. NFS接続が問題となるのは、ＤＢがメモリーに常駐するほどの頻度より少し小さい頻度でアクセスされる場合です. しかし、このような頻度が発生するのは、多種のＤＢがあり、それらに対して、一様なアクセス要求がある場合です. このようなアクセスが今後発生するかどうかはもう少し考えてみます.

７．おまけ
SunGridEngineのような基盤こそDBCLS（あるいはアカデミアが共同で開発してOpenSourceとして公開してほしいもの

(大久保）これまではmiGAPにはおそらく一定のリソースを占有していただいていたと思いますが次期スパコンではアカウント管理は一括でその下でキューイングシステムでクラスタを使っていただくことになります. そのような方法に対応するのは可能でしょうか？それとも　当面クラスタの切り分けにしか対応不可能でしょうか？ （菅原）　MiGAPの要求に波があることからも、大山さんとはかねがね「ＰＣクラスターのノードを動的に利用できるとよい」という話をしていましたので、システムの方向性については異議ありません. 　一方で、移行作業の内容とスケジュールについて急ぎ検討する必要が出てきました. 例えば：　SunGridEngineからの移行　データベース参照の方法など　以上、言い換えますと、 今回の移行で、添付の図の「サービス解析」のバーの上と下が切り離されれば個々のアプリケーションのメンテナンス作業が簡略化されることになりますが、MiGAPに限っては、図の左下にあるSGE(SunGridEngine)やＤＢ参照など作りこんでしまった部分を、いわば切り出す作業が必要になります.

http://farm8.staticflickr.com/7001/6828507575_45e8c7d6f2_z.jpg

Kaminuma Pipeline