大量公開への対応: システム入替から一年が過ぎて

去る2007年2月に,DDBJではシステムの入れ替えを行い,DDBJ内部の情報システムからサービス提供システムまで(データベースから解析サーバまで)機器を一新して業務に臨んでおります。
DDBJをご利用になる方からは,内部のシステムはなかなか見えて来ることはないかと思いますが,今回はこの内部のシステムの中でも超大量エントリの公開処理についてお話させて頂きたいと思います。

DDBJでは,公開前のエントリ情報が外部から閲覧されることが決して無いように,公開前のエントリ情報を保持しているデータベースと getentry などで閲覧できる公開後のエントリの情報を保持するデータベースとを分離しています。このため,下図に示されるような流れで,一日に一回夜間処理によって,公開前エントリの情報を保持しているデータベースから,その日の公開分のフラットファイルを出力してgetentry相同性検索サービスARSAanonymous FTP などの公開サービスに展開してきました。

flat file release proc

大量のエントリを展開するために,旧システムでは長時間を要していましたが,新システムでは今月(2008年1月),約150万件を無事展開することができました。新システムでも1日目約100万件,2日目約50万件と2日掛かりという超大量件数でしたが,事前にシステムの例外処理を行うこともなく計画通り完了しました。
システムの入れ替え前は,一日の展開は35万件程度が限度でしたので,今回の展開には4日以上かかったことになります。システム入れ替え時に旧システムに対して3倍程度のエントリを処理可能なようにハードウエアとソフトウエアを見直しましたが,今回設計通りの性能を発揮することを確認できました。

しかし,公開処理は安全に行うことが出来たものの,夜間処理の開始時刻の再検討,転送用ファイル作成処理の見直しなど,課題もいくつか見つかりました。

検討の例

(課題1)過去の経験から夜間処理の開始を 01:00 に設定していたが,実は早められるのではないか
==>検討内容: 24:00 開始のバックアップシステムに影響しない方法を再検討する。
(課題2)ファイルの受け渡し時間について,データベース側と公開サービス側とで,若干ずれが生じている。Flat File の作成は毎時30分,Flat File の転送は毎時10分で,約40分のタイムラグが発生している。
==>検討内容:ずれが必要な理由は各サーバで出力された Flat File を1ファイルにしなければならないためで,各サーバで出力されたFlat Fileを公開サービスに直接渡すことが出来れば,30分は時間短縮できる。
(課題3) getentry の反映開始時間は,04:00, 08:00, 12:00 となっているが,12:00 のタイミングで反映開始となると,100万件の反映が完全に完了する時間が 18:30 になる。
==>検討内容:今の件数で 17:00 までに完了するには,10:00 から反映開始をする必要がある。現在,10:00 からは getentry で別の処理が実行されてしているため,タイミングを調整する必要がある。

こうした課題を解決するためには,サーバ同士の連携をさらに強化する必要があるため,システムエンジニアの中で検討を進めているところです。 今回はデータ登録やデータの検索ならびに解析をご利用いただいている方々が意識されるシステムの話題ではありませんでしたが,DDBJから大量公開のお知らせが出た際には特に,円滑なデータ更新のためにシステムエンジニアが知恵を絞っているところを思い浮かべていただければ幸いです。

2008年2月1日