Status of Data Archive System at KEK Injector Linac
Takuya Kudou #,A), Shiro KusanoA), Kazuro FurukawaB) , Masanori SatohB)
A)
Mitsubishi Electric System & Service CO., LTD.
2-8-8 Umezono, Tsukuba, Ibaraki, 305-0045
B)High Energy Accelerator Research Organization
1-1 Oho, Tsukuba, Ibaraki, 305-0801

Abstract
In the KEK injector linac, the control system utilizes the Channel Archiver based on EPICS framework developed at
SNS for storing a lot of device information, and it has stably works well for daily beam operation. However, the index
file of Channel Archiver has been often broken. If the file size of archived data is getting larger, the consumed time tocorrect the broken index information takes much longer time than one day. For this reason, we evaluate CSS-based
Archiver system originally developed at DESY as a candidate of new archive system. In this paper, we present the statusof the new archive systems in detail.

KEK 入射器における加速器情報蓄積システムの現状
1.

はじめに

2.

旧情報蓄積システム

KEK 入射器（以下、入射器）では、各制御機器
2.1 システム概要の状態監視を目的として、設定値および出力値の変入射器においては、制御機器への設定値・出力値化情報履歴を蓄積している。当初は、機器ごとに特などの変化履歴は、機器毎に開発された専用ソフト
化した専用の履歴ソフトウェアを用いていたため、変化情報のフォーマットが統一されていなかった。 ウェアにより蓄積・管理してきた。制御システムにこのため、異種機器間における履歴相関解析が困難 用いられる機器の数および種類が増加するにともなであった。これは、ビーム運転障害の迅速な原因特 い、履歴ソフトウェアの種類も増加し、保守性およ定に支障をきたすものである。近年、入射器制御シ び拡張性に欠いたものとなった。また、変化情報のス テ ム で は 、 Experimental Physics and Industrial フォーマットは統一されておらず、グラフツールもControl System（EPICS）の導入が精力的に進められ 個別に開発されてきたため、異種機器間でのパラてきた。このため、2004 年には、Spallation Neutron メーター相関解析が困難であった。
2004 年頃より、入射器独自開発の制御システム
Source（SNS）で開発された EPICS ツールのひとつを、EPICS経由で制御するための EPICS Gateway[1]である Channel Archiver を導入した。これにより、各機器の履歴を一元的に管理することが可能となり、 が構築されたため、EPICS Channel Archiver を導入
複数機器の変化情報の相関を容易に取れるように し 、 運 用 を 開 始 し た 。 本 シ ス テ ム は 、 登 録 し たなった。本システムは、導入以降安定に運用されて EPICS レコードの情報を、EPICS の通信プロトコルきたが、原因不明のインデックスファイル破損によ である Channel Access を介して収集し、それらをバる障害が度々発生した。インデックスファイルの修 イナリ形式でファイルに保存する。このように保存復には 24 時間以上を要する場合も有り、その間は されるデータファイルとは別に、読み出しを高速化するためのインデックスファイルを有している。
変化情報の閲覧が不可能となる。
こ の よ う な 不 具 合 か ら 、 Control System Studio データの読み出しには、Extensible Mark-up Language（CSS）の一部である CSS Archiver を導入し、試験 Remote Procedure Call によるデータサーバが用意さ運用を開始した。CSS は、DESY で開発され、現在 れており、Web ブラウザのみならず、Java および多くの研究機関が共同開発している Eclipse ベース Python による履歴データ表示が可能である。の制御システムツールである。CSS Archiver に蓄積された情報は、CSS のツールである Data Browser で参照が可能だが、端末毎に CSS のインストールが必要となる。しかしながら、機器担当者は、居室あるいは実験室などに設置された複数の端末を利用するため、利便性を考慮し、Web ブラウザ上で動作する表示ツールを Adobe Flash を用いて開発した。本稿では、Channel Archiver の障害、CSS Archiver の導入運用、新規開発した表示ツールの詳細について報告する。
図１：旧 Archiver システムの概略図___________________________________________#

kudoh@post.kek.jp

2.2

3.2

問題点
[2]

旧システムは導入以降、安定に運用されてきたが、原因不明のインデックスファイル破損により、データの読み出しが出来なくなるという障害が度々発生した。インデックスファイルの再構築により復旧可能だが、再構築時間は蓄積したデータサイズに比例する。このため、連続運用開始から 7 年経過した 2011 年には、破損したインデックスファイルの復旧に 24 時間以上を要することとなった。また、本システムの開発は既に終了しており、今後のサポートも見込めなくなった。

3.

新情報蓄積システム

3.1

データベース管理用 Web アプリケーション

バックエンドデータベースには、収集する履歴データに加え、収集対象となる EPICS レコード名、レコードごとのデータ取得間隔など Archive Engineが動作するために必要な設定データも記録されている。これらの変更は、データベース上で SQL 文を発行することにより可能であるが、利便性を考慮し、Web ブラウザ上で動作可能な phpPgAdmin[4]を使用している。設定変更を反映させるためには、ArchiveEngine を再起動する必要があるが、Archive Engineは web ブラウザからの再起動が可能である。これにより、設定変更から反映まで web ブラウザ上で管理することが可能となり、管理面の利便性が飛躍的に向上した。

システム概要3.3 旧システムとの比較
2014 年に運転開始を予定している SuperKEKB の前述の通り、新システムはバックエンドデータ制御システムでは、CSS の導入が予定されている。
CSS は、DESY で開発が開始され、多くの研究機関 ベースに一般的な RDBMS を採用している。これらが共同開発している Eclipse ベースの制御システム の RDBMS は、数多くのプログラミング言語インタツール群である。CSS では、制御システムに要求さ フェースをサポートしており、履歴データの読み出れる標準的なコンポーネントが豊富に用意されてい しをおこなうアプリケーションを容易に構築するこるため、短期間でのソフトウェア開発が可能である。 とができる。また、これらの RDBMS 向けに開発さSuperKEKB の運転開始以降は、互いのデータの相 れた phpPgAdmin のようなツールも数多く存在し、関を取る場合も想定されるため、リングおよび入射 それらを導入することで、独自の開発を経ずとも管器制御システムの親和性を考慮し、CSS のツールの 理面での利便性の向上を図ることができる。
し か し な が ら 、 一 般 的 な RDBMS は デ ー タ の一つである CSS Archiver を導入した。
このシステムは、EPICS の通信プロトコルである ACID 性（原子性、一貫性、独立性、および永続
Channel Access を 介 し て 情 報 を 収 集 す る Archive 性）を保証する設計となっている。このため、非Engine、およびそれらを記録するバックエンドデー RDMS を基盤としたシステムと比較した場合、データベース部から構成される。バックエンドデータ タの読み出しおよび書き込み速度が劣ることとなる。
ベースは、Oracle、MySQL、あるいは PostgreSQL な 表２は、新旧システムにおける読み出し速度の評価
ど一般的なリレーショナルデータベース管理システ 結果をまとめたものである。表２に示す通り、新シム（RDBMS）から選択可能である。入射器では、 ステムはデータの読み出しに、旧システムの約 15運用実績 [3]、近年の目覚ましい性能向上、日本語文 倍の時間を要するなど、読み出し速度では大きく書によるマニュアルおよび導入事例情報の豊富さな 劣っている。
どから、PostgreSQL を採用した。CSS には、蓄積した変化情報を表示するための Data Browser が用意されているため、履歴情報の蓄積から表示まで、新たなソフトウェア開発を必要としない。
表１は、入射器におけるデバイスごとの記録点数およびデータ取得間隔をまとめたものである。CSSには、旧システムである Channel Archiver からの移行ツールが用意されているため、約 9000 点にのぼる設定の移行もスムーズにおこなうことが出来た。
表１：デバイスごとの記録点数と記録間隔デバイス点数

データ取得間隔

クライストロン

858

10 秒

電磁石

3514

1,10 秒

真空351

10 秒

タイミング

2695

10 秒, 変化時

安全系

257

変化時

温度、その他

192210 秒

表２：新旧システムの読み出し速度比較履歴データ(24 時間分)の読み出し速度
旧システム

1.521 [sec]新システム

22.158 [sec]3.4

Viewer web アプリケーションの開発

CSS Archiver に蓄積された情報は、CSS のツールである Data Browser で参照が可能である。機器担当者は居室で参照する場合もあるが、参照したい端末
へ CSS をインストールする必要があり、利便性に欠 け る 。 そ こ で 、 Web ブ ラ ウ ザ 上 で 動 作 す る
Viewer web アプリケーションを Adobe Flash を用いて開発した。Flash アプリケーションは、単純なHTML で記述されたページに比して操作性および表現力に優れており、Flash Player が動作する計算機環境であれば OS を問わず動作可能である。Flash アプ
リケーションの開発は、リッチインターネットアプリケーションの開発環境である Adobe Flex SDK[5]を用いておこなった。

バックエンドデータベースと表示ツール間の通信
現在、運用に向けデータの移行中であり、2012
部には、ActionScript Message Format と呼ばれるバイ 年 秋 以 降 は 、 パ ー テ ィ シ ョ ニ ン グ 機 能 を 用 い た
ナリフォーマットを使用する amfphp を用いている。 Archiver の運用する予定である。
これにより、軽量かつ高速に通信をおこなうことが可能となり、アプリケーションのパフォーマンス向上に大きく寄与している。
本アプリケーションは、複数のデータのグラフ化、マウス操作によるグラフの拡大が可能となっており、複数データの相関解析が容易である。データ読み出し期間は、日時指定に加え、相対的な指定も可能となっており、自動更新機能と組み合わせることで、最新の履歴情報を自動で表示することができる。これにより、機器の状態監視が容易におこなえるようになった。

図２：パーティショニング概要
4.2

読み出し用サーバ設置

バックエンドデータベースに使用している
PostgreSQL などの一般的な RDBMS では、ディスクアクセスを減らすことが高速化につながる。メモリ内にデータを全て展開できるサイズの小さなデータベースとは異なり、新システムのような巨大なデータベースでは、ディスクアクセスが発生することは避けられない。現在、バックエンドデータベースのデータは、信頼性の高いネットワークディスク上に保存されており、ディスクアクセスにネットワーク
図２：Viewer web アプリケーションを介するため処理速度が遅くなることが不可避である。
4. 課題
そこで、ローカルディスク上にデータベースを保存する読み出し用サーバの設置を検討している。こ4.1 データベースのパーティショニング化
新システムの試験運用開始から 6 ヶ月で、データ の読み出し用サーバは、PostgreSQL の組み込み機能
ベースサイズは 362 GB まで肥大化した。今後の連 であるストリーミングレプリケーション機能を用い続運用により、さらにサイズは肥大化し、一つの て、ネットワークディスク上のデータと同じものをディスク上に格納できなくなることが予測される。 ローカルディスク上に保持する。これにより、ディ回避策として、一定期間ごとに別データベースとし、 スクアクセス処理が高速化され、ネットワークディ別ディスクに格納することを検討したが、データを スク上のデータ読み出しと比較して、約 10 倍高速に読み出しをおこなうことが可能となった。読み出
参照する側がそれを考慮する必要が出てくる。
そ こ で 、 バ ッ ク エ ン ド デ ー タ ベ ー ス で あ る し用サーバは、現在試験運用中であり、2012 年秋
PostgreSQL のパーティショニング機能を用いて、履 より運用開始を予定している。
歴データテーブルを月単位で分割することを検討している。PostgreSQL は、テーブル毎にデータ格納先を指定できるテーブルスペースと呼ばれる機能を有しており、分割した履歴データテーブルを、複数のディスク上に分散して格納することが可能である。
パーティショニング機能は、分割した複数のテーブルを一つのテーブルとして見せることが可能である
ため、参照側からはテーブルがどのように分割されているか意識することが不要である。
運用に向けて、パーティショニングの試験を重ねてきたが、Archive Engine が起動時に発行するデー
タ最終取得日時を読みだす SQL（MAX 関数）の動作が異常に遅くなるという問題に遭遇した。原因は究明できなかったが、PostgreSQL Ver. 9.1.4 を使用することにより、この現象は回避できた。

図３：読み出し用サーバ概要

4.3

RDBMS 以外のバックエンドデータベース

新システムのバックエンドデータベースである
RDBMS は、データの一貫性を保証するように設計および最適化されているが、本システムのようにデータ追記が主である巨大システムでは、速度性能において不利である。そこで、バックエンドデータベースとしてドキュメント指向データベースである
MongoDB[6] を 使 用 す る こ と を 検 討 し て い る 。
MongoDB は、結果整合性のみを保証するように設計されており、動作速度の向上が期待できるだけでは無く、Sharding と呼ばれるシステムにより水平スケーリングが可能であるため、蓄積データの巨大化にも容易に対応可能である。現在、新システムへの実装方法を検討および試験中である。

5.

まとめ

入射器では、2004 年頃、独自開発の機器情報蓄積システムを SNS にて開発された Channel Archiverに移行し、安定した運用をおこなってきた。しかしながら、原因不明のインデックスファイル破損による障害が度々発生したため、新システムへの移行を検討してきた。
このため、バックエンドデータベースに RDBMSを使用する CSS Archiver を導入した。CSS には履歴情報のグラフ化ツールが付属しているが、利用者の利便性を考慮し、Flash を用いた Viewer web アプリ
ケーションを開発した。新システムは、2011 年 9月の導入以降、安定な運用をおこなっている。2012
年秋には、バックエンドデータベースのパーティショニング化、読み出し用サーバの設置をおこなう予定である。今後も、システムの改良を重ね、機器情報蓄積の安定化および情報解析の簡便性を追求し、入射器ビーム運転の可用性向上を目指したい。

参考文献[1] K. Nakao et al., “Development of Gateway System Using
EPICS for KEKB Injector Linac”, Proceedings of the 29th
Linear Accelerator Meeting in Japan, Funabashi, Aug. 4-6,
2004
[2] S. Kusano et al., “DATA ARCHIVE SYSTEM USINGEPICS TOOL AT THE KEK LINAC”, Proceedings of the
31th Linear Accelerator Meeting in Japan, Sendai, Aug. 2-4,
2006
[3] T. Kudou et al., “UPGRADE OF ELECTRONICLOGBOOK SYSTEM AT KEK INJECTOR LINAC”,
Proceedings of the 8th Annual Meeting of Particle
Accelerator Society of Japan, Tsukuba, Aug. 1-3, 2011[4] http://phppgadmin.sourceforge.net/[5] http://www.adobe.com/jp/products/flex/flex_framework/[6] http://www.mongodb.org/