高木TF

ここでは、2011年から2012年に掛けて、遺伝研(DDBJ)で行われた、計算機システム、ネットワーク、DDBJ業務、アプリケーションプログラム、運用体制などの見直し・再構築に関する活動を、高木TaskForceチームメンバーの目線で記したものである. 従って、以下の活動は高木TFメンバーのみが行ったものではなく、DDBJの教員・アノテータ・エンジニア・スタッフ、管理部門(特に施設チーム・調達チーム)、電子計算機委員会、節電対策委員会、スパコン・ネットワーク業者などが深く関わっている. 活動のひとつひとつをこれらの関係者毎に細分化することが困難であるため、あたかも高木TFが主体であるかのような記述になってしまっていることがあるかもしれない. また、実際の活動作業量や成果の大きさと、本文書における記述量や詳細さは必ずしも一致していない. これらはいずれも筆者の表現力不足によるものであり、あらかじめお詫び申し上げたい.

計画停電と節電対応

 * 2011年3月11日、東日本震災と原発事故発生
 * 東京電力の計画停電対応
 * 遺伝研で一番の電力消費はスパコンセンター
 * 利用度合いの低いスパコンサーバの運用停止
 * スパコンサーバ室内空調機設定温度変更(18℃→24℃)
 * スパコンは24時間運用が基本. 週に何回も停電があることを想定していない
 * 業務アプリケーションシステムの軽量化と、外部VPSサーバ上に移植


 * 代替策の検討→結果的に東京電力の「弾力供給」に
 * スパコンシステムの外部データセンター(特に東京電力管外)への設置
 * 震災直後はデータセンターへの問い合わせが殺到し、完全な売り手市場
 * 当初、東京電力管外であれば電力不足の影響は受けないと考えていたが、その後、中部電力浜岡原発の運転停止命令や、国内各原子力発電所の定期点検からの運転再開ができない状況などから、2011年夏季には他電力管内においても電力不足が懸念される状況となった
 * ガスエンジンによる自家発電
 * 自家発電装置には、使用する燃料によって、都市ガス(天然ガス)を用いるものと、石油(軽油/重油)を用いるものに大別できる
 * 石油を用いる場合には、燃料タンクの大きさによって消防法の規制を受けること、定期的にタンクローリー等で燃料補給をする必要がある
 * 一方、都市ガスの場合は、すでに静岡ガスによって遺伝研までガス配管設備があることから、ガスによる自家発電を候補として検討
 * コジェネレーション(電熱併用)であれば、エネルギー効率及びガス単価でも有利であるが、遺伝研においては熱利用需要が少なく、コジェネの利用は困難
 * 独立系電力供給事業者(IPP)からの電力供給
 * IPPからの電力供給を受ける場合でも、配電系統設備は東京電力の設備を利用するため、以下のような制約事項があることが判明
 * 東京電力からの電力供給とIPPからの電力供給を併用することはできない
 * 東京電力の計画停電時には、変電所単位での計画停電となるため、IPPから受電していても、やはり停電となる


 * 遺伝研における電力使用の実情調査と見える化
 * 建屋別電力使用推移
 * サーバー調査
 * フリーザー調査
 * 建屋内温度、外気温度測定
 * 本館各階廊下及び屋上
 * 本館A314フリーザ室
 * 電子計算機室


 * 関連サイト
 * 遺伝研の電力使用量推移
 * DDBJの節電対応

スパコンシステム更新

 * 関連サイト
 * Replacing SuperComp 2012
 * 新スパコン構築風景

DDBJ業務アプリ移行

 * スーパーコンピュータシステム更新を機会に、抜本的な見直し
 * ベンダー固有製品から、オープンソースソフトウェア利用へ
 * HiRDB、Synfoware(以上、RDBMS)、shunsaku(検索エンジン)から、PostgreSQL(RDBMS)、BerkeleyDB(KVS)、Solr/Lucene(検索エンジン)へ


 * 業務アプリケーションの優先度付け
 * 1) j-DDBJの受付～査定～公開・三極連携
 * 2) w-DDBJの整形～公開
 * 3) w-DDBJの検索(entry-retrieval, keyword-serrch)
 * 4) w-DDBJの解析(homology-serach, sequence-alignment)
 * 5) etc. (ie. annotation-pipeline, secondary-database, WebAPI,,,)


 * アプリケーション移行用テンポラリ利用サーバの導入
 * 現スパコンシステムと新スパコンシステムのレンタル期間には重複期間がない
 * 新業務アプリケーションソフトの開発・検証用環境を新旧スパコン以外に用意しないと、業務運用停止期間が長くなってしまう


 * 関連サイト
 * NIG,DDBJ移行計画案[]
 * DDBJ daily update & release 作成
 * キーワード検索 (ARSA & GetEntry)
 * DDBJスパコン移行作業時期に使用するテンポラリサーバ

ネットワーク更新

 * 老朽化した遺伝研所内基幹ネットワーク
 * 補正予算で導入後8年以上を経過、保守契約なし
 * 機器の老朽化による故障が発生
 * 故障時にはスポット保守を依頼するも、保守部品も入手困難になりつつある
 * 2009年度に一部機器のみ更新
 * 機器更新後の旧機器を保守部品獲り用として再利用するなど、現場の工夫も限界


 * 実状にあわないネットワーク構成
 * SINET～F/W～基幹SW間は2Gbps(光)、基幹SW～建物SW間は10Gbps(光)、建物SW～オフィスSWは1Gbps(光)、オフィスSW～末端は1Gbps(メタル)
 * 遺伝研内の部署間相互の通信(建物SWを跨ぐ通信)が多い場合には適しているが、実際には所外(インターネット)との通信が主体
 * 300台以上のオフィスSWまで光ケーブル配線
 * 光インターフェースを持った機器はまだまだ高価
 * オフィスSWは床下や屋根裏に設置されており、保守性が悪い
 * 所内すべての機器(サーバ、クライアント共)に、グルーバル固定IPv4アドレスを付与
 * 世界的にIPv4アドレスが枯渇している時代に、1000人以下の組織でBクラスのIPv4アドレス(65,000個以上)を保有し、贅沢に使用
 * 固定IPアドレスなので、端末(PC)を移動して使うような場合に不便
 * 野良無線LAN APの乱立、野良メールサーバの乱立
 * 野良無線LAN APの乱立により、電波の混線・輻輳のリスクやセキュリティリスクも


 * 過去何世代ものネットワーク機器とケーブルが残置
 * ネットワーク運用管理体制・責任の所在が不明確
 * 管理部門(施設T)、電子計算機委員会、DDBJ(シス管T)
 * シス管Tは、現行ネットワーク機器の設置状況と設定情報はわかるが、ネットワーク配線は分からない
 * 施設Tにも、最新のネットワーク敷設状況を記した図面がない


 * ネットワーク機器の更新だけでなく、ネットワーク構成の根本的見直しから
 * オフィスSW(約300台)をフロアSW(約50台)に集約
 * 建物SW～フロアSW間をメタルケーブル配線に
 * 無線LAN、DHCPの本格的運用により、将来のグルーバルIPアドレス回収への布石


 * 関連サイト
 * 遺伝研のネットワーク
 * 2011遺伝研ネットワーク刷新事業
 * ネットワーク運用管理作業項目(案)[]

Gmail移行

 * Google Apps for Education
 * 教育機関向けに無償で利用できるGoogle Apps for Educationの調査と申し込み


 * サブドメインの統合
 * address@lab.genes.nig.ac.jpとaddress@genes.nig.ac.jpのふたつのサブドメインメールを、address@nig.ac.jpに統合する方針に基づき、統合方法を検討
 * lab.genes.nig.ac.jpと、genes.nig.ac.jpを、nig.ac.jpのドメインエイリアスとして登録


 * メーリングリストの移行
 * メーリングリストは、Google Groupへ移行することを基本方針として決定
 * 過去1年間にメール配信実績のないメーリングリストは移行対象から除外
 * 部門・役職・窓口などで、個人と同様なメールアカウントを発行し、アカウントの共用や引継ぎを行っているようなメールアカウントについては、メーリングリスト(Google Groups)へ移行する方針を決定
 * DDBJ業務用メーリングリスト
 * DDBJ受付・査定・構築業務と密接に結びついた業務運用フローを行っているため、メール管理・メール共有シスムの利用を検討
 * mail Dealer http://www.maildealer.jp/
 * DDBJメールマガジン配送用(宛て先が大量のためGmailの上限に抵触する可能性)に、メール配信システムの利用を検討
 * 配配メール http://www.haihaimail.jp/


 * 所内独自メールサーバへの対応
 * 所内研究室等で構築・運用している独自メールサーバへのメール配信方法の検討
 * 配送専用MTAサーバの構築を検討中(2012/1時点)


 * 関連サイト
 * 次期メイル

RDF調査

 * RDFについて
 * 全体としては非構造的データ(の集合体)であるが、部分を見ると構造的(決定的)なデータ(主語、述語(属性)、目的語(属性値)の三つ組 = triple)の集まり
 * 非構造的(「RDBのような正規化」がされていない)データや、暗黙知の表現に向いていると期待されているが、非構造的データ、暗黙知を、断片的ではあっても形式的なデータ・知識のパーツ(tripes)に変換することが必要
 * 上記、パーツ(triples)への変換には、多くの場合、対象分野に関する専門的な知識と人手を必要とする

DDBJフラットファイル 一応、構造化されているものの、主として人間による可読性を重視しており、コンピュータ処理には不向きな形式 利用者は自分に必要なデータを取り出したり加工するために、それぞれが独自にparserを作製する必要がある INSD XML形式 フラットファイルの全ての情報を保持しつつ、コンピュータによる取り扱いを容易にした形式 データ項目はタグで識別されるため、汎用的なXML parserを利用してデータの抽出・加工ができる 一方、人間には読みづらい他、タグの追加によって、データ量(ファイルサイズ)がフラットファイル形式よりも大きくなってしまうという欠点もある XMLの共通的な性質であって、INSD XML固有の問題ではない データ圧縮効率は高いので、圧縮して保管しておくだけならおおきな支障にはならない 情報の単位が、フラットファイルのエントリ(Accsession Number)単位から抜け出しておらず、データの柔軟な利用という観点からは使いづらい場合もある
 * DDBJ RDFについて
 * DDBJフラットファイルから、RDF XML形式に変換したもの
 * subject, predicateを表現するURIは、既存のFT-docの説明ドキュメントなどを参照
 * 既存のドキュメントは、あくまでも人間の理解を助けるためのものであり、厳密さに欠ける
 * 結局、DDBJ(またはINSDC)を知っている人にはわかるが、そうでない人にはやっぱり分からない
 * RDF XMLの形式には正しく従っているが、RDF本来の「文書やデータの意味や構造をメタ記述する」という目的に対しては十分ではない
 * 構造や意味のメタ記述の見直しには、エンジニアだけではなく、アノテータ等のバイオロジストの参画が必須
 * XML形式と同じく、タグの追加や、項目の細分化により、データ量(ファイルサイズ)が大きくなるという欠点もある


 * RDFの格納、提供方法について
 * 現状では、DDBJ RDFは、RDF XML形式データを圧縮し、FTPサイトからダウンロードできるだけ
 * 大量のRDFデータを格納・検索・取り出しができるRDF storeが必要

RDF storeについての考察メモ
 * RDF storeについて

2011/08/26 山田

0.この文書の目的

・RDF storeの基本要件(のドラフト)

1.目的、目標(goal)

・超大規模なRDF(100億triple以上)を安定して格納できるRDF store を実現する. ・想定する格納データは、traditional INSDデータをRDF化したもの

2.要件(requirement)

・大量のRDF tripleを格納できること(100億triple以上) ・パターンにマッチしたRDF tripleを検索し、高速に取り出しできること ・SPARQLの対応はRDF storeの機能としては実装しない ・上位レイヤーでSPARQLエンジンを実現できるための、下位レイヤーAPIを 備えること

・格納するデータの特徴を以下のように想定する

データ件数は非常に多い(100億triple以上) データの追加は多い データの更新/削除はあるが、データ総件数及び追加に比較して 多くはない

3.基本構想(strategy)

・既存のRDBMSまたはKVSのうえにRDF storeを開発する

・RDBMS/KVSは取り替え可能な構造とする ただし、環境構築時を除いて、利用者はRDBMS/KVSを意識する必要が ないこと

3.1 RDF構文

・RDF storeが取り扱う(格納する)RDF構文はN-triples形式とする

理由:(1)RDFの本質は三つ組の集合であり、もっともプリミティブ に表現している構文である (2)KVSやRDBMSのテーブルとの対応がとりやすい (3)他の構文(RDF/XMLやN3など)内では、prefixが利用できるが、 prefixは記述内でローカル定義できるため、同一の実体に 対して異なる表現が可能となる 検索のためには、一意の表現で格納されていることが必要 →フルURI表記→N-triples

・他の構文形式(RDF/XML,N3,Turtle,RDF/JASON)からN-Triple構文への 変換(短縮表記やprefixの展開)を行うwrapperを備える wrapperは独自開発ではなく、既存のRDFライブラリの活用を検討する →RDF libraryの調査必要(Jena/Sesame/JRDF etc)

Application Program +- SPARQL API | SPARQL engine ++- RDF store API |  ( RDF libray ) ………+………………………………… (N-triples構文) ＲＤＦ　ｓｔｏｒｅ - SQL / NoSQL API KVS / RDBMS -         Storage System

・入力時に与えられたコメント(#から行末まで)は無視する コメントは格納されないため、いかなる手段でも出力できない

★空白ノードラベルの取り扱い(識別と格納方法)は? →空白ノードラベルは局所一意(グラフローカル)である →追加登録するtriple内に空白ノードラベルがあった場合、 RDF store全体(DB内全体)で空白ノードラベルの一意性を保証するため、 空白ノードラベルの一元管理が必要になる

→グラフローカルの局所範囲指定方法? (特にデータ登録時には)トランザクション類似の範囲指定が必要 になるかも? transaction-start ～ transaction-end(commit) のような

3.2 格納構造

・格納構造は、Binary table形式(predicate毎にテーブルを分割する形式) とする(小笠原先生の資料に従う)

・traditional INSD RDF データをターゲットとすると、 (Subject,Predicate,Object)のtripleの総数は数百億tripleにのぼるが Predicateの種類は限定的(せいぜい数百のオーダ?) 一般的な定義のほかは、Flat File formatと、Feature table definition で記述されているものにとどまる

→binary table形式は、predicateでテーブルを分割するが、上記のとおり テーブル数はたかだか数百レベルなので、KVS/RDBMSとの親和性は高い と思われる

3.3 RDF storeに必要な機能(function)

3.3.1 DB操作

・createDB             新規DBの作成 ・destroyDB            DBの消去(全テーブル削除)

・backupDB             DB全体の退避 ・restoreDB            DB全体の復元

・openDB ・closeDB

3.3.2 登録・更新系

・add(insert) ・replace(update) ・delete(remove)

・add/replace時は、S/P/Oの三つ組で指定 重複を許すかどうかで複数のmethod(またはパラメータ指定)が派生する ・delete時も、S/P/Oの三つ組で指定 複数あったら全て削除でいい?

・外部ファイルからの一括load系は、addをラッパーして実現する ・table生成はadd時に(なければ)自動生成する ・deleteの結果、全レコードがなくなったテーブルは自動的に消去する →createTBL/deleteTBLのようなmethodは不要(内部的にはあるとしても)

3.3.3 検索系 3.3.3.1 pattern matching

RDF storeとしての基本機能はこれだけ

・s/p/oに対するmatching条件の組み合わせにより、以下の8種類の 組み合わせがある

( s, p, o ) → 特定のtriple(booleanしか意味を持たない) ( ?, p, o ) ( s, ?, o ) ( s, p, ? ) ( ?, ?, o ) ( ?, p, ? ) ( s, ?, ? ) ( ?, ?, ? ) → すべてのtripleがmatchする

★8パターン全てが必要か? →SPARQLの文法上からは全パターン必要と思われる

・maching patternは完全一致のみとする→OK? →少なくとも、空白ノードラベルの読み替えは必要になる

3.3.3.2 pattern matching結果の返却(通知)方式

boolean    存在するかどうかを、true/falseで返す 下記のcountがあれば機能的には包含できるが、patternが 存在するかどうかだけなら、ひとつでも存在した時点で pattern matchingを中断できるため、性能面では有利 ただし、必ず速いかどうかは、検索方法とデータの格納状態 に依存するため、保証はできない

count      matched tripleの個数 → この機能は必要か?

triple     matchした(複数の)tripeをすべて一括して通知 subject    matchしたtripleのsubjectをすべて一括して通知 predicate                   predicate object                      object

match件数によっては巨大になる →実用上は、事前にnumberを確認することが必要 下記のiterationしかいらないかも

iteration  matchしたtriple(またはsubject/predicate/object)を 順次通知する

3.3.3.3 matched tripleに対する集合演算や修飾

・RDF storeとしては集合演算や修飾はしない(RDF storeの機能をシンプルに)

★join       RDF storeの機能としては実装しない ★union      RDF storeの機能としては実装しない ★not        RDF storeの機能としては実装しない

★sort       RDF storeの機能としては実装しない ★unique     RDF storeの機能としては実装しない

★offset/    iterationに付加する? limit     実用上はsort(ORDER BY)がないと意味がないため、RDF store としては実装しない

4 検討課題およびアイディア 4.1 トランザクション機能

★データ登録/更新時のトランザクション機能は必要か? KVSはトランザクション機能がないか、極めて弱い →traditional INSD RDF データが対象ならば、トランザクション機能は なくてもOK?

4.2 RDF binary table の KVS/RDBMS への実装上の検討課題

・N-triple構文の主語(S)と述語(P)の組み合わせでは、同じ組み合わせが 複数回出現する可能性がある(例:あるentryのauthorが複数人の場合) →主語(S)をKeyとしてKVSに登録するためには、KVSがnon-unique keyを 許容している必要がある →大概のKVSは一般にnon-unique keyを許すものなのか? BerkeleyDBにはkeyの重複を許すモードがある

・objectに対するpattern matchingは、Secondary Indexや、KVSの場合は Key/Valueの転置形式がないと、検索実効速度は厳しい →何れにしても、必要なストレージサイズは増大する

4.3 表記方法の統一(検討課題)

・N-triples構文において複数の表記方法が認められている場合(があれば) どうする? 下記例はXMLの場合であるが、N-triples構文での規定が不明

例:boolean型 http://www.w3.org/TR/xmlschema-2/#boolean

3.2.2.1 Lexical representation An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0}.

3.2.2.2 Canonical representation The canonical representation for boolean is the set of     literals {true, false}.

例:数値型の正負符号、先行ゼロ、小数点以下のゼロなど http://www.w3.org/TR/xmlschema-2/#decimal

3.2.3.1 Lexical representation decimal has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) separated by a period as a     decimal indicator. If totalDigits is specified, the number of digits must be     less than or equal to totalDigits. If fractionDigits is specified, the number of digits following the decimal point must be less than or equal to the fractionDigits. An optional leading sign is allowed. If the sign is omitted, "+" is assumed. Leading and trailing zeroes are optional. If the fractional part is zero, the period and following zero(es) can be omitted. For example: -1.23, 12678967.543233, +100000.00, 210.

3.2.3.2 Canonical representation The canonical representation for decimal is defined by prohibiting certain options from the Lexical representation (§3.2.3.1). Specifically, the preceding optional "+" sign is prohibited. The decimal point is required. Leading and trailing zeroes are prohibited subject to the following: there must be at least one digit to the right and to the left of the decimal point which may be a zero.

4.4 格納データ構造(hash化) ※アイディアレベル

・N-triples形式ではURIをフル表記するため、一般的に長いstring(数十～数百 bytes)となる

★→stringをhash関数を使ってタグ化することで、必要なストレージ容量を削減 できないか hashed tag長は32bitでは不足. 40～48bit程度で足りる (2^32≒43億、2^40≒1.1兆、2^48≒281兆)

例)md5sumは   128bit(16bytes)のhash値を計算する       sha1sumは   160bit(20bytes)のhash値を計算する       sha224sumは 224bit(28bytes)のhash値を計算する

→同じstringが何度も格納される場合や、secondary indexや、KVSの転置 テーブルを作成するなら、ストレージ容量削減に大きな効果があるはず

→hash関数はhashed tagの重複(衝突)の可能性をゼロにはできないため、 hashed tagが重複した場合は、hashed tag + 追番 をkeyとして使用する hashed key (= hashed tag + 追番)とstringの対応を格納するテーブルが 必要になる

副作用としてデータ登録/更新/読出時には hashed tag テーブルへの アクセスも発生するため、レスポンスの悪化が懸念される → hashed tag テーブルを on memory 化するなどの工夫

→すべてhash tag(固定長) + 追番(固定長) とすることで、key/valueともに 固定長となる. RDBMS/KVSの実効性能面で有利になる可能性もある?

5. その他

・1T tripleの登録と検索に成功 Total load was 1,009,690,381,946 triples in just over 338 hours for an average rate of 829,556 triples per second.

http://www.franz.com/about/press_room/trillion-triples.lhtml http://www.w3.org/wiki/LargeTripleStores#AllegroGraph_.281.2BTrillion.29

以上

高木TF会議議事録・資料

 * 参考サイト
 * https://sites.google.com/a/g.nig.ac.jp/takagi-tfgiji-roku/ (アクセス制限あり)

記述ガイドライン

 * 大項目
 * 飛び先
 * ほげほげ
 * 1) 大項目
 * 2) 小項目asdf