BEA Guardian
そういえばEclipseベースのこの製品*1をちょろっと触ってみたけど、高い金払ってまで使う価値あるのかね？
っていうのが、正直な感想。
例えば、JDBC接続プールの最小と最大値を揃えた方が『DBとのコネクションを張る』という“重い処理”を起動時にまとめて済ませられるというのは、大きな意味がある。
NW的な障害により、コネクションが全てクローズされた場合には、『予約時にテスト』オプションを使えば、WebAPがRDBとのコネクションをAPサーバへ借りに来た際に、『再試行回数』で指定した数まで、接続を試みて、その間にRDBが復旧すれば、WebAPにエラーが返る事なく、RDBとのコネクションを利用できる。
また、根本的なところで、JavaVMのヒープサイズの最小（-Xms）と最大（-Xmx）の数を揃えることで、大きいクラスファイルのコンパイル時にヒープ拡張に失敗して、OOM*2エラーが発生する事は防げる*3事もJavaを使った人ならわかるだろう。
上記は本当に初歩的で基本的なことだけど、既定の設定では設定されていないことやWebLogic Serverを初めて触った人には、わからないことかもしれない。
また、パッチ情報も「どの機能を使っているから、どのパッチを当てないと危険」だとかも現場の人にはわからないかもしれない。
BEA GuardianはJMXを使ってMBeanの情報を収集することで、BEAのサポートサイトからDLしたシグネチャと実環境の情報を照合し、上記のような『転ばぬ先の杖』とも言うべき知恵と、どのパッチを当てるべきかという勘を働かせてくれるツールの様だ。
“勘”と言ったのは、必ずとも提示されるパッチが正解とは限らないと言うこと。
あくまでも、BEA社のCS*4やエンジニアが手掛けて育んだノウハウベースでシグネチャは更新されているみたいなので、間違いもあれば誤検知もある。
また、それなりにお金を払って、このツールを利用したからと言って、自分たちで作成したWebAPにバグが混在していたら意味がないし、このツール自体が使いづらい。*5
そして、BEA Guardianを利用するのであれば、Web経由でBEA社にアクセスしないとならないというのも、DCなどにサーバを置いている方々にとっては、気になる点だと思う。
結論としては、同じお金を払うならBEA社のPS*6を1,2日雇って、BEA GuardianをPSが利用する契約を結ぶことが出来るのであれば、それで最初に大体のアラを取って、穴を埋める作業をやった方が得だろうと思う。
