「DataSpider Servista 3.1の新機能で問題解決!」
現在の時刻は20時。DSシステム社のオフィスも人影がまばらになってきました。そんな中、最近リリースされたばかりのDataSpider Servista 3.1を使用してスクリプト開発に勤しむ東谷君の姿が。額の油汗から推測するに、どうやら悩んでいるようですが・・・。
謎のエラーが発生!原因は何だ!?
東谷君:
フオォォォ・・・。フオォォォ・・・。
みかさん:
(こ、この波紋を練るかのような呼吸は、東谷くんが悩んでいる証拠・・・。どうしたのかしら?)
東谷君:
あ、みかさん・・・。たっ助けてください!!
みかさん:
ずいぶん悩んでるわね・・・・どうしたの?
東谷君:
「FileNotFoundException」が出てスクリプトが失敗するんですが、対象のファイルは存在しているんですよ・・・。
どうやってもエラーが解消されなくて・・・。俺はもうダメだ・・・。
みかさん:
行き詰まってるようね! ちょっとスクリプト見てみましょうか。
東谷君:
いつもすみません...。
みかさん:
「CSVファイル読み取り」処理でエラーが出てるけど、確かに読み取るファイルは存在するわね。
これはエラーの原因は、実際にファイルが存在するかどうかとは別のことな気がするわ。
東谷君:
というと...?
みかさん:
エラーが間違っているとは思えないから、DataSpiderからは本当にファイルが見えないんじゃないかな。
東谷君:
な、なんですと・・・!?
みかさん:
ファイルシステム上にはファイルがあるけど、DataSpiderからはそれが見えない。ということは、ファイルシステムに何か問題があると思う。大体こういうときは、ハードディスクの空き容量を確認すると・・・。
東谷君:
こ、これは!!ハードディスクの空き容量が0KB!!
みかさん:
こういうとき、こんな感じでDataSpiderからファイルが見えないという事象が起こることがあるのよね。でも何でこんなに容量使っているのかな?
東谷君:
おかしいな...。朝見たときは結構な空きがあったと思うんですが...。
DataSpiderのログレベルに注意!
みかさん:
DataSpiderを使っていて空き容量が無くなったのならば、DataSpiderの処理が影響してこういうことが起こってる可能性が高いわね。DataSpiderのインストールディレクトリの容量を確認してみてもらえる?
東谷君:
あ、はい。あれ、80GBもある・・・。
みかさん:
やっぱりそうみたいね。じゃあどのディレクトリが大きいのか、細かく見て行って原因を切り分けていきましょう。スクリプトが関係するのはserverフォルダ下のetc、home、share、logsといったところかしら。
東谷君:
み、みかさん!判明しました!logsフォルダです!
みかさん:
なるほど。うーん、このXMLログ、1つの容量が5GBよ。これはディスク容量を圧迫するわね。ログファイルの肥大化となるとスクリプトの作りが原因ね。
東谷君:
うーん、やっていることは「繰り返し(データ件数)」処理で分割処理を行って処理をしているだけなんですけどね・・・。
みかさん:
あーでもこれ、ログレベルがDEBUGになっているわね。
みかさん:
入力データの件数はどのくらい?
東谷君:
約1,000万件です。 3.1でスマートコンパイラが導入されたので、 大容量のデータでもメモリを気にせず高速に処理できるんですよ!
みかさん:
(いきなり宣伝口調になったわね・・・。)
スマートコンパイラによって適用されるPSPは以前のバージョンから存在していたけど、専用のPSPスクリプトを作らなければ行けなかったため、ちょっと敷居が高かったのよね。
それがスマートコンパイラによって、通常スクリプトでもPSPの恩恵を受けることができるようになったのは確かに大きいわよね。大容量のデータを使ってみたくもなるよね~。
東谷君:
(みかさんも宣伝口調のような・・・。)
みかさん:
ただ、大容量のデータを処理するときは、ログに気を付けなきゃいけないわ。ログレベルはDEBUGが最も低く、NOTICEが最も高いというのは知っているよわよね。ログレベルが低い(=より詳細)ということは、すなわちログファイルのサイズが大きくなるということ。
東谷君:
ぐぬう・・・。一体どうすれば良いのでしょう・・・。
みかさん:
いろいろ方法はあるけど、開発段階ではXMLログの出力をオフにするというのは1つの手ね。デザイナの実行ログビューでログは追えるから、特にXMLログがなくても問題ないんじゃないかな。
東谷君:
確かにそうですね・・・。でも本番はどうしましょう。
みかさん:
本番環境でも、スクリプトでエラーが発生した場合には ダンプファイルが出力されるから、エラーの詳細を確認することは可能だわ。
ただし、XMLログがないとマイログから ログビューアが開かないので、それが要件定義にあると、別の方法を考えなくちゃならないわね。
東谷君:
あー、お客様はログビューア使えないのは納得されないでしょうね・・・。どうすれば・・・・。
DataSpider Servista 3.1の新機能で解決!
東谷君:
よし、こんなときはこれだ! 教えてくも子!
みかさん:
他力本願!
くも子:
3.1の新機能ガイドを見るクモ!
東谷君:
えっ・・・。まさか3.1から解決する機能が追加されたとか・・・!?
えっと・・・こ、これかっ! 繰り返し処理のログ設定!
みかさん:
そう。3.1では、 繰り返し処理で個別にログ設定を指定できるようになったの。これによって、スクリプトのログレベルは運用標準の「INFO」だけど、特定の繰り返し処理内だけは「NOTICE」にする、もしくはログを出力しない、といったことが可能なのよ。
東谷君:
おおー、これでなんとかなるのか!
みかさん:
これまでは、スクリプトに対してしかログレベルが設定できなかったけど、3.1では各繰り返し処理ごとに設定ができるので、「どういったログが必要になるのか」ということを見極めて設定することで、ログファイルの肥大化を防ぐことができるようになるわ。
東谷君:
なるほどねー。
みかさん:
これにはメリットがもう1つあって、ログ出力のコストが削減できる、ということはパフォーマンスの向上も期待できるということなの。単純な処理だけだとほとんど変わらないかもしれないけど、繰り返し処理の回数が多ければ多いほどパフォーマンスへの影響も大きいから。
東谷君:
うおぉ!いいこと尽くめじゃないですか!
みかさん:
あと、ログファイルはデフォルトではそのままの状態で5日間、ZIP圧縮して5日間の計10日間保存するので、期間を短く変更することでもディスク容量圧迫の防止には効果があると思わよ。
東谷君:
DataSpider Servistaにはいろいろな機能が用意されているんですね・・・まだまだ勉強不足だなぁ。
みかさん:
安心するのはまだ早いわ。このスクリプト内には繰り返し処理が複数あるけど、ログ設定をどのように行うかは、要件定義に沿った形にしなきゃいけないし、ログファイルの保持期間も同様よ。
この辺は、お客様にちゃんと確認する必要があるわね。
東谷君:
了解しました!
みかさん:
スマートコンパイラ、繰り返し処理のログ設定以外にも、DataSpider Servista 3.1でいろいろな新機能がリリースされているわ。一度その辺を確認してみるのがいいと思うよ。
東谷君:
分かりました! 確認して早速明日からいろいろ活用してみよう!楽しみだな。
というわけでみかさんとクモ子に助けられながら、今回も何とか乗り切った東谷君。
DataSpiderマスターへの道は遠く険しいぞ!
次回以降も、さらに新しいことにチャレンジしていきます。
ご期待ください。