IBM i のウンチクを語ろう
～ その21： サーバー比較の観点から見たIBM i -2
皆さんこんにちは。前回は「ダウンサイジング」という名の元に、基幹業務アプリケーションにおけるサーバー勢力図の塗り替わりが進んだ経緯を見てまいりました。ベンダーや機種を問わずに連携処理を行える「オープンシステム」は、その言葉の明るい響きと初期導入コストの低さを武器にして、市場でのシェアを伸ばしました。言葉の響きが明るいとは、本来は論理ずくめであるべきITの世界には相応しくない情緒・感情ですが、意外と根深く人々の意識の中に居座っているようです。これに対してどのようにしてオープンシステムの一員ではないIBM i のメリットに納得いただければ良いのか、生半可な論理ではなかなか通用しないので、説明者の立場としては常に苦労するわけですが。
当時のダウンサイジングを定義するとしたら、単一の大型サーバー上で稼働していたアプリケーションとシステム機能を、複数の機能単位に分割し、プログラムの書き換えやパッケージ利用による移行作業を行い、それぞれにオープンな小型サーバーを割り当てて全体を連携・連動させ（分散化）、その後の保守を行う、といったところでしょうか。何だか聞いただけでもややこしそうです。ここで、アプリケーション・プログラムは何とか移行するにしても、オープンシステムには元々備わっていないミドルウェア機能、すなわちデータベースやシステム管理、通信、セキュリティなどを自力開発するのは困難なので、パッケージを利用することになります。これをビジネス・チャンスと捉えた多くのパッケージ・ベンダーが市場に参入したわけですが、一方のレガシーシステムは元々これら機能を標準的に備えるので、パッケージの必要性は低く、それだけ見た目の品揃えは劣ります。システムとして元々備えている機能範囲に差があるので、単純にパッケージの多寡を議論しても、あまり意味のある事ではなさそうです。
さてミドルウェア機能や一部のアプリケーションはパッケージに置き換えられ、別個のオープン・サーバー上に展開され連携します。かつてはマシンのパワーが十分ではなかったので、一台集約はまず不可能でした。仮に十分なパワーがあったとしても、運用上の都合から集約される事はまずありません。個々のパッケージを実装するための前提条件、すなわちオペレーティング・システムのバージョンやサービスパック、考慮するべき個別の修正プログラムや設定するべき構成条件が、完全に一致する事は期待できないので、環境を分離する方が運用上便利というよりもむしろ安全です。そして最後に、分散されたサーバー群をうまく統合（Integrate: インテグレート）してテストを行い、実稼働させるわけです。この作業を専門に行うのがSIer、すなわちSystem Integratorですね。余談ながら、これの省略形は英語の綴りに従うならば、SIerではなくSIorであるべきような気もしますが。
さて、システム全体の構成要素は、機能に応じて配置された複数のサーバー、負荷分散や万一に備えたバックアップ・サーバー、それらを繋ぐネットワーク、という具合に比較的複雑なものになります。明らかにそれとわかる製品の障害であればまだ良いのですが、製品間の相性に起因する障害が発生すると厄介です。それぞれの開発元は、製品はスペック通りに稼働している事を主張・証明できるかもしれませんが、それでもうまくいかない事があります。筆者の個人的な経験では、スペックに原因がある事が多いようです。業界で誰もが準拠するべきオープンなスペックというのは、謳い文句としては素晴らしいのですが、いざ個別の製品において実装しようとすると解釈に幅が生じる場合があります。製品開発者は意識せずにスペックを都合の良いように解釈するかも知れません。スペックの責任者に問い合わせたとしても、彼等・彼女等は中立を貫かなければなりませんので、問合せ者の意向だからと言って、明文化されていない事柄を追加のスペックであると勝手に補正するわけにはいきません。不備はいずれ修正されるかも知れませんが、解決まで時間がかかりそうです。
仮に問題箇所が特定されたとしても、オープンシステムのサポートポリシーはレガシーシステムのそれとは異なる事が多いので、注意が必要です。これまでは新規の問題に対して個別のフィックス（修正プログラム）を作ってもらえたのに、今後は定期的にリリースされるサービスパックを待たねばならないかもしれません。
ユーザーからすると、誰でも良いから早く製品を修正して欲しい、もしくは運用の仕方を工夫する事で不具合を回避する方法を知りたい、となります。自力で個々のベンダーに要求をあげて交渉したり、回避策を確立するのは困難なので、多くはSIerに依存する事になります。
無事にシステムとして稼働するようになったとしても、製品には寿命、すなわちメーカーがいつまで製品として公式にサポートしてくれるのかという期限があります。複数メーカーの複数製品で構築されたシステムだと、その期限にはばらつきが生じますので、継続的にメーカーのサポートを得るためには、随時バージョン・アップグレードを行う必要があります。そうなるとシステム構築時に経験した製品間の相性の懸念が再浮上します。決して推奨される事ではないのですが、ユーザー自らリスクを負って、もしくはSIerのサポートを背景に、期限切れのままに製品を使い続ける事もあります。SIerのサポートとは言ってもメーカーのそれとは違いますので、既知の情報に基づくガイドに限定されたり、新規トラブルには対応できないなどの制約がありがちです。そしてサーバーの種類や台数が増えると、それ相応に作業量が増加します。
一連の作業や懸念事項まで考慮した時、果たして導入時のコスト削減がどこまで効果的だったのかという疑念が生じてきます。新規導入時のハードウェア、ソフトウェアとそれらの保守料金、さらにはSIerへの支払い額はあらかじめ明確に把握できますが、被るかもしれない様々な不自由や、それに対応するための追加作業を数値化するのは極めて困難です。どうせ雇っているのだから、社員がどれだけ働いたとしてもコストは変わらない、と「豪語」する方もかつてはいらっしゃいましたが、いつまでも通る理屈ではありません。年を追う毎に製品の価格性能比が改善され製品の価格が下がる一方で、人件費が下がる事はまずありません。結果的に全ITコストの構成要素の中で、相対的に人件費の占める割合が大きくなります。選択するサーバーや環境によってばらつきはありますが、75％を超える例も報告されています。ITは今や人件費の固まりなのです。
ITコストの削減に取り組もうとしたら、人件費を何とかしなければなりません。そう簡単に単位時間あたりの給料を下げるわけにはいかないので、作業量・時間を減らす工夫をする必要があります。サーバーを分散させた事が作業量増加に結び付いたのだとしたら、再度統合してその台数を減らせば良いはずです。次回はこのあたりを見ていく予定です。ではまた
