 |
≫ |
|
|
|
|
Q：お客様がNonStopを選択された理由はどのあたりにあるのでしょう
|
|
|
|
|
|
NonStopの場合には、システムの構成要素をすべてNonStop上にまとめて載せることができるので、性能を追求しやすくなります。NonStopは値段が高いと思われがちですが、Open系サーバを何十台も用意し、ネットワークを構築し、技術者が構築からメンテナンスまで行うとすると、構築コストやランニングコストを全部足していけば、トータルコストはオープン系でもNonStopでも結局変わらないのではないでしょうか。
あるお客様のシステムですが、第1フェーズではオープン系のシステムで構築されたのですが、やはりサーバが何十台にも膨れあがってしまったので、第2フェーズではそれらのサーバ群をNonStopでコンソリデーション（統合）したいというご要望をいただきました。
ある程度の規模以上のシステムになると、NonStopのメリットが大きくなると思います。 |
|
 |
|
|
Q：他にNonStopのメリットと感じるところを教えて下さい
|
|
|
|
|
|
 |
|
NonStopの場合、システムの様々な部分が二重化されているので、障害が発生しても、その障害がアプリケーションに影響を及ぼさない点があげられます。
たとえば、よく障害が発生する部品としてハードディスクがあげられますが、ハードディスクでは他のシステムでも二重化の対応がなされています。しかし、二重化されていないハードウェアに障害が発生すると、ベンダーのCEが現地に伺って交換することになり、お客様側の担当者の作業立ち会いが必要となります。交換作業はどうしても夜間になってしまうので、立ち会いをしているとお客様側の担当者は昼間の仕事ができなくなっていってしまうという弊害があります。 |
|
|
一方、NonStopなら、フォールトトレラントサーバーであるとお客様もご理解いただいていますので、お客様によっては、日中でもハードウェア交換に対し、立ち会いは不要、任せるから交換しておいてと言っていただけます。システムに対する信頼感が非常に高いと感じますね。
また、2005年にItanium版のCPU搭載型が発表され、システムのレスポンスもとても良いと感じます。NonStopという名前の通り、非常に高い負荷率でもきちんとシステムが動き続けてくれます。 |
|
Q：NonStopというと、データベースなどのバックエンドシステムで使われているというイメージが強いのですが？ |
|
|
|
|
|
実はNonStopサーバが日本で販売され始めた当初は、FEP (Front End Processor)すなわちフロントエンドでの利用が多かったのですが、最近またフロントエンドでの利用が増えてきています。オンライン処理や認証系の処理などでも利用されていますよ。
アプリケーションの開発には、Javaも使えるようになっています。WASとしてオープンソースのTomcatが使えますし、もちろんメジャーなBEA社のWebLogicも動きます。
先ほどお話ししたとおり、NonStop1台でフロントエンドからバックエンドまでシステムの全てをカバーできます。システムのチューニングもしやすいので、高いシステム性能の要求にもお応えできます。 |
|
 |
|
|
Q：事例のお話に戻りますが、どの段階から関わられたのですか？ |
|
|
|
|
私がプロジェクトに参加したのは、システム試験を開始する段階からです。お客様から品質について懸念があったので、私は品質強化のために加わりました。
お客様では、すでにNonStopで動作する決済系のシステムを利用されていたのですが、そのシステムの障害対応がよくなかったことも懸念される理由の一つでした。何か障害が発生しても、その対応に2時間から3時間かかっているという状態でした。そのシステムは動き出してから5年ほど経っており、容量不足や性能不足が起き始めており、月に十数件のお問い合わせがありました。障害が発生しても調べ方が分かっていればお客様自身で対応できるのですが、いちいち問い合わせないと分からない、安心してシステムを運用できていない状況でした。 |
|
|
システム運用から5年も経っていることもあり、運用担当者の方が変わられる一方、十分な引き継ぎが行われていない状況でした。そんな時に頼りになるのはドキュメントですが、システムを使う人の立場に立ったドキュメントがない、というのが最も大きな原因だったと思います。
業務パッケージのマニュアルは汎用的なもので、お客様個別の視点では書かれていません。システムの設計書も詳細に記述されているわけではないので、新しいシステム担当者に変わられると、システムの情報がどこにあるのか分からなくなってしまいます。
それまではパッケージと基盤となるシステムは別物という考え方でした。そのため、ドキュメントもそれぞれバラバラになってしまっていました。業務パッケージを開発した会社と日本HPの守備範囲も別々に考えていました。このような問題があることが分かりましたから、新しいシステムでは我々システム基盤を担当する側もきちんとパッケージのことを理解し、誰にでも運用ができるドキュメント作りを目指しました。 |
|
 |
|
|
 |
|
印刷用画面へ
