レベル: 初級 2006年 04月 14日 WebSphere® Serviceability Team には、お客様の事業所を実際に訪問して複雑な状況の解決に当たる機会がしばしばあります。このような状況は通常の業務ではありませんが、現場でのサポートがどうしても必要な場合には、適用範囲を拡大してサービスをご提供しています。訪問後には毎回、現場で取った措置や観察された事態を文書にまとめています。さらに、お客様のトラブルの経緯と原因を判別できるように、頻繁にデータベースを見直しています。
このホワイト・ペーパーでは、お客様を支援する中で観察された慣行やパターンについて説明します。この情報は、皆さんの意識の向上に役立つものです。トラブルの経緯と原因をより的確に理解できるように、実際の事例を紹介します。また、それぞれの慣行に対応した可能な対策についても説明します。
WebSphere® Application Server for distributed
WebSphere Application Server for z/OS®
バージョン 3.5 ～ 6.0
IBM® Corporation
WebSphere Serviceability Team - SWAT
Katie Barrett (katie@us.ibm.com), Manager, WebSphere Serviceability, IBM Austin Lab
Yasuko Bryan (ybryan@us.ibm.com), WebSphere Serviceability, IBM Austin Lab
Alan Booth (aebooth@us.ibm.com), Manager, WebSphere Customer Support, IBM Raleigh Lab
David Cai (davecai@us.ibm.com), WebSphere Serviceability, IBM Pittsburgh Lab
Melinda Carter (mlcarter@us.ibm.com), WebSphere OS/390® - Level 2 Support, IBM Poughkeepsie Lab
Mark T. Schleusner (schleus@us.ibm.com), WebSphere Serviceability Development, IBM Rochester Lab
Rex Simmons (simmonre@us.ibm.com), WebSphere Knowledge Engineering, IBM Austin Lab
William Wentworth (wkwentw@us.ibm.com), WebSphere Information Development, IBM Austin Lab
このホワイト・ペーパーへの貢献に対し、以下のメンバーに深謝いたします。
David Burdine、John Bukiewicz、Paul Griffiths (WebSphere Application Server の失敗例について)
Copyright ®2006, IBM Corporation バージョン日付:2006 年 4 月 14 日
目次
要約
はじめに
プロジェクト・ライフ・サイクルにおける間違い行為
間違い行為の定義
計画策定段階 (要件 - 機能と制約)
1. 処理能力/スケーラビリティー計画の不備
2. 教育の不備
3. 現行のアーキテクチャー計画の不備
開発段階 (設計、実装)
4. アプリケーション・エラーの見過ごし
検証段階
5. 実動トラフィック・プロファイルの不備
6. 負荷/ストレス・テストの不備
7. 実稼働環境とテスト環境の同等性の不備
8. 実稼働環境に対する、変更内容の直接適用
実稼働中/稼動後段階
9. マイグレーション計画の不備
10. 変更の記録の不備
全段階共通
11. コミュニケーションの断絶
2005 年度に WebSphere SWサービス のエンゲージメントで観察された間違い行為の割合
所見:
間違い行為別の事例と可能な対策
計画策定時の要件 - 機能と制約
1. 処理能力/スケーラビリティー計画の不備
2. 教育の不備
3. 現行のアーキテクチャー計画の不備
開発 - 設計と実装
4. アプリケーション・エラー
検証による、ソフトウェアがニーズに合致していることの確認
5. 実動トラフィック・プロファイルの不備
6. 負荷/ストレス・テストの不備
7. 実稼働環境とテスト環境の同等性の不備
8. 実稼働環境に対する、変更内容の直接適用
実稼働中/稼働後
9. マイグレーション計画の不備
10. 変更の記録の不備
全段階共通
11. コミュニケーションの断絶
稼働停止がビジネスに及ぼす影響
まとめ
付録
要約
WebSphere Serviceability Team (以下SWサービス)には、お客様の事業所を実際に訪問して複雑な状況の解決に当たる機会がしばしばあります。そうした状況への対応は通常の業務ではありませんが、現場でのサポートがどうしても必要な場合には、適用範囲を拡大してサービスをご提供しています。訪問後には毎回、現場で取った措置や観察された事態を文書にまとめています。さらに、お客様のトラブルの経緯と原因を判別できるように、頻繁にデータベースを見直しています。
このホワイト・ペーパーでは、お客様を支援する中で観察された慣行やパターンについて説明します。この情報は、皆さんの意識の向上に役立つものです。トラブルの経緯と原因をより的確に理解できるように、実際の事例を紹介します。また、それぞれの慣行に対応した可能な対策についても説明します。
はじめに
子どもの頃、母親から「ハサミを持って走ってはいけません」、「歯は磨いたの」などと、うるさく言われた経験はないでしょうか。ハサミを持ったまま走り回るのは悪いことです。歯を磨くのはよいことです。このホワイト・ペーパーのテーマが子育てだとしたら、ハサミを持ったまま走り回ることは「間違った行為 (malpractice)」と呼ばれるものでしょう。間違い行為とは行ってはならないものであり、その行為を何度も繰り返していると最終的には自らを傷付ける危険性がある慣行のことです。それに対して歯磨きは、繰り返し実行することが自分の利益につながるものであるという点で、ベスト・プラクティスを表現していると言えます。
このホワイト・ペーパーでは、情報テクノロジー (IT) 企業のコンテキストにおける間違い行為について論じます。記載されている情報は、緊急事態に陥ったお客様に対する最近 5 年間の支援作業から得られた所見に基づいています。企業が事業運営の一環として Web サイトに依存する度合いは増大し続けています。いかなるダウン時間も経済的損失に直結してしまうため、時間的にも気分的にもまったく余裕がなくなっています。Web サイトを迅速に稼働させることが不可欠な状況なのです。しかし、間違い行為を犯しながら Web サイトを稼働させていると、いつかは痛い目に遭うことになります。拡張保守サービス・エンゲージメントによる支援対象となったお客様の 3 分の 2 に、少なくとも 1 項目の間違い行為が観察されました。ただし、同じく拡張保守サービス・エンゲージメントの対象となった残り 3 分の 1 のお客様には、間違い行為がまったく観察されませんでした。
当チームでは、「ある朝目覚めたら、自分たちの行為が実際には間違い行為であることがわかった」という事態に皆さんが陥ることを想定しているわけではありません。また、皆さんが意図的に、ここで紹介する間違い行為の 1 つか 2 つ、あるいは 11 項目すべてを企てているとも考えていません。皆さんはおそらく、どの間違い行為も犯したことはないでしょう。しかし注意は必要です。誰かが何らかのショートカットを試みようとしていたら、それが間違い行為となる可能性があるからです。
Katie Barrett
Manager, IBM WebSphere Serviceability Team
プロジェクト・ライフ・サイクルにおける間違い行為
当チームのエンゲージメントにおいて観察された間違い行為は 11 項目ありますが、当チームでは WebSphere Application Server(以下WAS) のライフ・サイクルの中に位置付ける形でそれらの間違い行為を分類しました。WAS のライフサイクルは、以下の 4 つの段階に区分されます。
下図に示すように、各段階ごとに最も一般的に見られる間違い行為をリストアップしました。この所見は、WAS 全プラットフォーム (分散システムと z/OS を含む) を網羅するものです。
間違い行為の段階
処理能力/トランザクション計画の不備
教育の不備
現行のアーキテクチャー計画の不備
アプリケーション・エラー
実動トラフィック図の不備
負荷/ストレス・テストの不備
実稼働環境とテスト環境の同等性の不備
実稼働環境に対する、変更内容の直接適用
マイグレーション計画の不備
変更の記録の不備
全段階共通 --------->コミュニケーションの断絶
間違い行為の定義
このセクションでは、さまざまな種類の間違い行為を定義します。
計画策定段階 (要件 - 機能と制約)
アプリケーションの最終的動作とリソースの割り振り方法は、すべての基本となるこの段階で決定されます。アプリケーションのライフ・サイクル全体にわたる主要計画が策定されますが、必要な計画の見落としが発生するのもこの段階です。
- 処理能力/スケーラビリティー計画の不備
計画段階の一環として、アプリケーションに流れ込み、その中を通過し、そこから流れ出していくデータの量が決定されます。時間の経過とともに、データの種類やデータ量は増大していきます。以下に示すのは、処理能力/スケーラビリティー計画を持たないお客様の環境で見られる問題点の例です。
- 実稼働環境で必要とされる処理能力や応答時間について、予測がなされていない
- どのようなトランザクションがどのような組み合わせで、またどの程度の頻度で発生するかということについて、予測がなされていない
- 各トランザクションの長さが考慮されていない
- どの程度の人数のユーザーが実動システムを利用するかということについて、予測がなされていない
- 市場の変化 (休暇シーズンなど) に応じた定期的な計画更新がなされていない
- 教育の不備
研修に参加したり教材で学習したりすることについて時間上およびリソース上の制約があると、以下に関する知識が制限されてしまいます。
- 現行のアーキテクチャー計画の不備
アーキテクチャーに関して、以下のいずれかの状況が見られます。
- 各種のソフトウェア製品間におけるアプリケーションの流れを示す図が存在しない
- それらの製品がトポロジー内で占める位置を示す図が存在しないため、IBM DB2® の配置場所、WAS の配置場所、クラスターの内容などがわからない
- 現行のアーキテクチャー図が存在しない一方で、4 年前のアーキテクチャーに基づく図は存在する
開発段階 (設計、実装)
開発段階とは創造の段階であり、実稼働段階のための基盤がここで構築されます。アプリケーションの最初の開発作業だけでなく、アプリケーションに対するあらゆる機能強化や変更作業も、この段階で行われます。
- アプリケーション・エラーの見過ごし
いくつかの一般的な問題点について以下に説明します。
- 大規模なオブジェクトの割り振りが原因で、ヒープ・サイズが大きくなり過ぎている
- 冗長な計算呼び出しが原因で、CPU 使用率が増大している
- 無限ループが原因で、CPU 使用率が増大している
検証段階
このテスト・フェーズでは、複雑な環境においてアプリケーションが計画どおりに機能しているかどうかが検証されます。ここでは、ネットワーク、ハードウェア構成、バックエンド・データベース、負荷などに関して、実稼働環境と同様の環境が使用されます。
- 実動トラフィック・プロファイルの不備
- ネットワーク、ルーター、スイッチ、ハブの配置を示す図が存在しない
- ネットワークまたはネットワーク・セグメントの処理能力に関するデータが存在しない
- 負荷/ストレス・テストの不備
- 負荷/ストレス・テストが実施されていない
- 負荷/ストレス・テストは実施されているが、そのテストには実動時の負荷が反映されていない
- トランザクション・パターンが、実動時のトランザクション・パターンを正確にシミュレートしたものになっていない
- 負荷は正確にシミュレートされているが、バックエンド・データベースのサイズが極端に小さい
- 実稼働環境とテスト環境の同等性の不備
- テスト環境の規模が小さ過ぎるか、必要時に利用できない
- テストで使用されるハードウェア、ネットワーク、ソフトウェアが、実稼働環境のものと異なる
- 同一マシン上または同一ネットワーク上の z/OS LPAR が、実動システムから隔離されていない
- テスト・システムの構成関連の設定値が、実動システムの設定値と異なる
- 実稼働環境に対する、変更内容の直接適用
- 構成に対する変更と修正が実動システムに直接適用され、後になって、その変更の動作に問題があることが発覚する
- 本来なら問題点や負荷のシミュレーションに利用することが可能な、実稼働環境と同等のテスト環境が存在しないため、お客様は変更内容を実稼働環境内で実地にテストすることを余儀なくされている
実稼働中/稼動後段階
この段階は、アプリケーションのライフ・サイクルにおける重要部分であり、最初のアプリケーション開発段階よりもはるかに長期間に及びます。とはいえ、この段階の問題が看過される可能性はあります。この段階ではアプリケーションが既に実稼働しているため、ここで問題が発生すると、その影響は一般の利用者まで含めたかなりの広範囲に及び、多大な損失を招いてしまいます。
アプリケーションの基盤となるソフトウェアは、日々進化しています。したがって、相互前提条件となるパッケージについては、アップグレードと統合テストが必要となります。ハードウェアとオペレーティング・システムをまずアップグレードしたうえで、アプリケーション自体を拡張したり、追加アプリケーションとのインターフェースを取ったりする場合もあります。こららの変更全般に際して、適切な計画策定、文書更新、計画遂行が必要となります。これに関連して観察された問題点を以下に示します。
- マイグレーション計画の不備
- マイグレーションを実施するための十分な時間が割り当てられていない
- 新しい Java 2 Platform, Enterprise Edition (J2EE) 仕様がシステムに及ぼす影響について判定するための調査時間が十分に取られていない
- 開発担当者が、相互に必要となるソフトウェアの要件について認識していない
- 変更の記録の不備
- 変更内容の記録が作成されていないストレスがかかる中で変更作業が行われている
- 複数のグループが、記録を残すことも互いに連絡を取り合うこともなしに、同じ環境に対して変更を加えている
全段階共通
- コミュニケーションの断絶
変化の激しい今日のビジネス環境において、コミュニケーションは非常に重要です。適切な人員同士が明確かつ公正な方法でコミュニケーションを取ることが鍵となります。連絡に不備があると、他者の不満が募るだけでなく、見当違いの作業に労力が浪費される結果を招きかねません。いくつかの事例においては、お客様相互間、IBM とお客様との間、およびお客様と各ベンダーとの間で、効果的なコミュニケーションが観察されませんでした。
2005 年度に WebSphere SWサービス のエンゲージメントで観察された間違い行為の割合
WAS のお客様のうち、WebSphere SWサービス が支援を提供したお客様の数はさほど大きな割合ではありません。とはいえ、サンプルとなったそれらのお客様の中ではごく普通に間違い行為が発生しており、お客様が陥って初めて気付くような状況に直接関係する事例が数多く見られました。以下に示すグラフは、2005 年度の WebSphere SWサービスのお客様について、各種の間違い行為が観察された頻度を示したものです。
注意:このサンプルは WAS のお客様から取られたものですが、これらの間違い行為は WAS に特有のものではありません。例えば、WAS に対してストレス・テストが実行されていないのであれば、同じ環境内のそれ以外の製品やアプリケーションに対してもストレス・テストが実行されていない可能性があります。
所見:
- 危機的な状況に陥ったお客様の中で最も発生頻度の高い間違い行為は、「実稼働環境とテスト環境の同等性の不備」です。
- 2 番目に頻度が高いのは「アプリケーション・エラーの見過ごし」です。
- そして 3 番目に頻度が高いのは「教育の不備」です。
「実稼働環境とテスト環境の同等性の不備」は多くの場合、「実稼働環境に対する、変更内容の直接適用」および「負荷/ストレス・テストの不備」を引き起こす原因となります。
間違い行為別の事例と可能な対策
計画策定時の要件 - 機能と制約
- 処理能力/スケーラビリティー計画の不備
処理能力計画は絶対不可欠なものではありませんが、成長を必要とする e-ビジネスにとってはやはり必要となる計画の 1 つです。この計画は、これまでより大きいハードウェアを 1 台購入するといった単純なものではありません。当座は単純な計画でも役立つでしょうが、それがアプリケーションの処理能力を向上させる最も有効な手段にならないのはほぼ確実です。
優れた処理能力計画が配備される場合、その中には優れた高可用性 (HA) 計画が組み込まれています。HA 計画が必要となるのは、特に珍しいことではありません。どのような企業でも、営業日は終日、最低限の量のハードウェアで最大限の業務をこなしたいと考えています。企業が HA と処理能力の計画を配備せずにそうした目標を達成することは不可能です。アプリケーション全体がたった 1 台のハードウェア上に置かれている場合でも、しばらくの間なら所定の処理能力を発揮できるかもしれません。しかし、万一その 1 台のハードウェアがダウンしたとしたら、アプリケーション全体のトラフィック処理が停止し、企業の収入の道も途絶えてしまいます。そこで、その 1 台のハードウェアの代わりに、より小型の 2 台のハードウェアを使用して同じ処理容量を持たせれば、ハードウェア・コストは依然とほぼ変わらなくても、アプリケーション全体が失われる確率ははるかに低くなります。この思考過程をさらに進めて細部まで検討することが、1 組の処理能力計画と HA 計画を策定するための適切な出発点となります。
事例:
ここで、調査の行き届いた優秀な処理能力計画の重要性を示す事例を紹介します。クライアントのワークロードが適切に分散されていないために処理能力の問題が発生していると考えているお客様がいました。このお客様は、十分なハードウェアに対応した計画を事前に立て、その処理能力計画の中に優れた HA 計画を組み込んでいました。ところが、需要が増えるにつれて、アプリケーションの処理能力が追いつかなくなりました。CPU、メモリー、ネットワーク使用率のすべてに問題があるように思われました。
そこで、アプリケーションのコード・レビューを実施したところ、アプリケーション内に問題点が発見されました。クライアントがセルを有効範囲とする Java Naming and Directory Interface (JNDI) 呼び出しを実行しているのですが、そこではすべてのクライアントがデプロイメント・マネージャーを介してエンタープライズ Bean を検索していました。この状態では、アプリケーションが 6 個のノードに分散していても、デプロイメント・マネージャーが問題となってしまいます。
ここでの要点は、処理能力計画とは単なるハードウェア計画ではないということです。処理能力計画を策定する際には、アプリケーションやそのデプロイメント、さらにはアプリケーション・クライアントの使用状況などを考慮に入れる必要があります。複数のクラスター・メンバーに分配するようにネーミング呼び出しを再構築したところ、問題点は解消され、アプリケーションはより多くのトラフィックを処理できるようになりました。この問題点から得られた教訓により、開発チーム では、クライアント呼び出しに対してネーミングのキャッシングをより戦略的に行うようになりました。
可能な対策と予防措置:
処理能力計画を取りまとめる際には、ハードウェアとアプリケーションの両方の処理対象についての計画であるということを忘れないでください。処理能力計画における最大の誤りは、アプリケーションの見落としです。アプリケーション設計を適切に調整すれば、ハードウェアのコストを節減できます。アプリケーションの使用対象を見落としてはなりません。
この間違い行為を予防するには、以下のチェックリストを使用します。
- バックエンド・データベース用の処理能力計画には、追加の負荷について何を処理できると記述されていますか。
- ネットワーク・ルーターは、ネットワーク・トラフィックの増大について何を処理できますか。
- Lightweight Directory Access Protocol (LDAP) サーバーは、ユーザー認証について何を処理できますか。
- アプリケーションが広域ネットワーク (WAN) 全体に分散している場合、リモート呼び出しは最小限に抑えられていますか。
- ハードウェアの一部は、災害時回復用またはHA 用としても使用されていますか。
- ハードウェアの使用率が最大でどの程度に達したら、追加ハードウェアの提供が必要となりますか。
- 各オブジェクト・タイプは、処理能力の増大に応じて次のように適切に用いられていますか。
- エンティティー・エンタープライズ Bean には、クライアントによるデータベース読み込みの大半に対応するキャッシング・ポリシーが設定されている
- ステートフル・エンタープライズ Bean は、あらかじめ非活性化されて高速ストレージ・デバイスに格納されている
- 教育の不備
WAS は、オープンながら発展途上にある標準に準拠するものとして構築されています。また WAS の新規リリースはいずれも、アプリケーション・サーバー用の後継 J2EE 標準に準拠したものとなっています。標準に変更があれば、WAS の後続リリースにもそれに応じた変更が加えられます。
お客様は一般にアプリケーション・サーバーの初回導入時にはその学習のための時間を取りますが、残念なことに、後続リリースにおける変更に関して初回と同等の学習時間を割くことはほとんどありません。例えば以下の機能がそれに当たります。
- 新たに組み込まれた機能
- 非推奨となった機能
- 削除された機能
教育に投資しない理由としては、「部内の人材を社外研修に送り出せるだけの時間がない」、「今は教育についてとやかく言わないでほしい」、「当社には、重要な人材を現場から外せるような余裕はない」などが挙げられます。しかし、教育が不足すると実稼働環境に以下のような危機的状況が生じます。
- マイグレーションに関する問題:Application Server の各リリースは、先行するリリースから進化してきました。新規リリースの環境下でアプリケーションを効率的に稼働させるには何らかの変更が必要となるかもしれませんが、変化に応じたアプリケーション見直しを行わないお客様は、以下の問題に遭遇する可能性があります。
- パフォーマンスに関する問題:n 回目のリリースで効率的だった仕様が、n + 1 回目や n + 2 回目のリリースでは最適でなくなっている可能性があります。
- 機能に関する問題:
- n 回目のリリースで使用されていた機能が、n + 1 回目のリリースでは非推奨となり、n + 2 回目のリリースでは削除されている可能性があります。
- 新機能が使用されていないと見なされることがあります。個々の機能拡張にはお客様によって要請されて J2EE 新規標準に組み込まれた機能が反映されているため、新機能を使用する機会が見逃される可能性があります。
- 元のアプリケーションが J2EE 準拠でないのに、お客様が移行したリリースでは J2EE 準拠のアプリケーションのみが処理されることがあります。
- 統合に関する問題:前提条件または相互必要条件となるソフトウェアの明示的レベルは、リリースごとに確立されています。その確認をせずに前提条件および相互必要条件となるソフトウェアに移行した場合、何らかの問題が生じたり、アプリケーションのパフォーマンスに影響が出たりする可能性があります。
- フラストレーションが発生することがあります。通常これは、WAS がお客様の期待どおりに動作しないときに現れる問題です。
事例:
ある玩具メーカーが、WAS バージョン 3.5 を使用して自社のオンライン・サイトを立ち上げました。そしてバージョン 3.5 の Web サーバー・プラグインを使用し、アプリケーションの変更なしにバージョン 4.0 に移行することに成功しました。現在、バージョン 4.0 のサポートは終了しています。その後、オンライン・ビジネスが成長したという事情もあって、バージョン 5.1 またはバージョン 6 の追加性能が必要となりました。そこで、WAS の単一バージョン・レベルとして、より長期間継続的に使用できる点を考慮し、バージョン 6 に移行することを決定しました。
同社では、WAS バージョン 6 を購入してインストールしたうえで既存のアプリケーションをデプロイしようとしました。ところが、アプリケーションはデプロイされず、まったく機能しません。そこで複数の Problem Management Resolution (PMR) レポートを提出し、IBM のサポート部門に対して、「以前はアプリケーションの動作に問題はなく、アプリケーションには何も変更を加えていないのだから、今回の問題の原因は WAS にあるに違いないと確信している」と伝えてきました。同社は不満を募らせていました。
しかし WASバージョン 5.1 とバージョン 6.0 が J2EE 標準に準拠しているという認識はこのお客様にあったのでしょうか。実はその認識自体はありました。ところが、アプリケーションが同じく J2EE 準拠であるバージョン 4.0 上で稼働していたことから、問題の原因が WAS の側にあるに違いないと信じ込んでしまったのです。
このお客様は、移行先のバージョン・レベルである WAS バージョン 6 に組み込まれている仕様について調査したのでしょうか。また、バージョン 4 プラグインからバージョン 6 に移行する場合に必要となるすべての変更点について、確認したのでしょうか。その答えはノーです。
このお客様は、WAS の機能強化および変更点について学習するために、ある程度の時間を見込んでいたでしょうか。その答えはノーです。
では、それらの機能強化および変更点について学習する予定は立てていたのでしょうか。その答えもノーです。
可能な対策と予防措置:
以下の変更点について定期的にアプリケーションの見直しを行うための時間を見込みます。
- 現行のアーキテクチャー計画の不備
現行のアプリケーションは、何をどのように処理するものでしょうか。どこからデータを取得し、結果をどこに出力するのでしょうか。また、その間に行われる処理全般はどうなっているのでしょうか。新機能が追加された場合、後任の担当者は、機能を安全に追加する方法をどのようにして知ればよいのでしょうか。ソフトウェアであれハードウェアであれ、環境内で何らかのシステムの追加、削除、交換が行われた場合、どのようにして環境を再調整すればよいのでしょうか。これらのどの作業を行う場合でも、重要なのは、最新の状況を反映した現行のアーキテクチャー計画を保持することです。すべてを把握している専門家がいれば便利ですが、それだけでは十分ではありません。元のアーキテクチャー計画のラフ・スケッチがあれば、使い勝手はよいでしょうが、6 カ月後にはそれほど役に立たなくなってしまいます。
変更というのは必ず起こるものです。実践可能な最善の方策は、変更をより簡単に自力で行うための計画を立てることです。アーキテクチャーに関して言うと、最新のアーキテクチャー計画を保持していれば、稼働停止を回避しやすくなるうえ、システムが停止した場合でも、問題判別に要する時間を数週間から場合によっては数カ月も短縮できます。
事例:
ある大規模小売企業では、WAS を利用してオンライン・ビジネスを展開しています。この事業の立ち上げに際して、同社は WebSphere SWサービス のコンサルタントと契約してアーキテクチャー開発作業の支援を依頼し、必要な機能を組み込みました。その結果、アーキテクチャーの定義、文書化、実装は順調に行われました。
その後、この会社は他社の買収を進め、買収した事業を既存のオンライン・ショッピング・アプリケーションに追加する計画を立てました。また、店舗用クレジット・カードの入会手続きや個人のサービス予約など、他のサービスもオンライン・ビジネスの Web サイトに追加しました。これらの要請は社内の各部門から中央の IT 部門へ送られ、そこで 1 名の担当者が機能追加作業を行っていました。これらの追加機能のうち、あるものはメモとして、またあるものはノート上の記録として残され、元のアーキテクチャー計画に対する補足として正式に文書化されたものも 1 件ありました。
そして 3 年が経過し、数多くの変更が行われた後になって、稼働停止が発生しました。しかし、社内では誰もその問題の原因を突き止めることができません。そこでこのお客様は、WAS について重大度 1 の PMR を提出し、その中で「何も変更していないのにシステムが停止した」と状況を説明しました。お客様の現場に派遣された IBM のエンジニアは、データの流れを把握するために、アーキテクチャー計画の開示を求めました。お客様はアーキテクチャー計画を探しましたが、見つかりませんでした。計画が最後に更新されたのは 2 年前のことであり、その最終版ですら、元の設計が完成した後の更新情報を 3 件だけ組み込んだものにすぎませんでした。この状況から、最近 2 年間に行われた機能追加の大部分が元のアーキテクチャー計画にはまったく追加されていないという事実が明らかになりました。お客様の現場には、アプリケーションがどのような流れになっているのか、あるいは本来どのように流れるべきものなのかを正確に把握している人はいませんでした。
この状況を受けて、お客様と IBM の双方が 2 週間集中的に作業に当たり、アプリケーションはその後何度もインスタンスの停止を繰り返しました。結局、問題の原因は、数カ月前に追加されたクレジット・カード関連の新機能にありました。その新機能と従来のクレジット・カード課金機能との関わりによって、データベースがロックしていたのです。具体的には、顧客の四半期毎の課金計算の最中にこの機能がアクセスされた場合に問題が発生していました。ところが、実際に四半期毎の課金サイクルが開始され、新事業の買収によって顧客が追加されるまで、このエラーは表面化しませんでした。
今もなお不明なのは、アプリケーション内にまだ他にも処理の流れを止めるような潜在的エラーが残っているかどうか、あるいは新たな機能追加によってまた新たな問題が発生するかどうかということです。現行のアーキテクチャー計画がなければ、アプリケーションの流れとデッドロックを判別するために長時間かけてデバッグ作業を行わなければなりません。アーキテクチャー関連文書を最新の状態に維持するためのプロセスを配備しない限り、次々に変更が加えられたり人事異動が行われたりしているうちに、文書の有用性はどんどん失われていってしまいます。
可能な対策と予防措置:
ここでの重要事項は自らに自己規律を課すことです。アーキテクチャー関連文書を最新状態に維持することを優先させてください。それには、少なくとも以下の疑問に答えられるアーキテクチャー関連文書を保持するようにします。
- 誰が何をいつどのような理由で変更したか
- データはどのように流れているか
- ハードウェアとソフトウェアの両方を含め、環境はどのようになっているか
- 内部構造はどのようになっているか
さらに、現在使用している WAS のバージョン・レベルに対して推奨されているアーキテクチャー・パターンの 1 つを利用することも可能です。それらのアーキテクチャー計画は、IBM Redbook で定義されています。このパターンに関する推奨事項は、WAS のバージョン・レベルによって異なる場合があります。また、それらの事項によって自社のインストール済み環境に関する文書を保守管理する責任が免除されるわけではありませんが、確固たる出発点となることは確かです。IBM Redbook の詳細については、以下の Web サイトをご覧ください。
http://www.redbooks.ibm.com/
開発 - 設計と実装
- アプリケーション・エラー
アプリケーション・エラーは、IBM がお客様との共同作業の中で数多くの問題点に遭遇する領域の 1 つです。そうした問題点は、WAS の問題点であると考えられてしまうことがよくあります。ところが実際には、前セクションで取り上げたような現行のアーキテクチャー計画が存在しないことがアプリケーション・エラーを引き起こしている場合のほうが多いのです。アーキテクチャーの最重要部分はアプリケーションであると言っても、まず間違いはないでしょう。アプリケーションがなければ、e-ビジネスはあり得ません。その点だけでも、アプリケーション・ライフ・サイクルをきめ細かく追跡することの理由としては十分です。ここで問題となるのは、アプリケーション・ライフ・サイクル管理の重要性が忘れられがちであることです。アプリケーションがデプロイされて稼働が開始されると、アプリケーション・ライフ・サイクルを適切に管理することを忘れてしまうお客様はさらに増えます。そしてアプリケーション・エラーは、多くの場合、アプリケーション・ライフ・サイクルの管理を怠ったことの結果として発生します。
事例:
ある米国系大手企業が新たな事業分野に参入しましたが、同社のアプリケーションに大きな問題点がいくつか発見されました。それらの問題点はアプリケーションの実稼働開始日を延期せざるを得ないほど重大なものであり、同社にとってはまさに深刻な事態でした。そして最終的には、このままアプリケーションの実稼働を開始しても、問題点に対処しない限りは毎日稼働停止が起こる状態が続くだろうという結論に達しました。問題は、WAS が勝手に再始動してしまうことでした。
このアプリケーションはあるサード・パーティー企業が開発したものであり、アプリケーションにはそれ以外の複数の会社が作った部品も組み込まれていました。お客様によるアプリケーション設計レビュー工程では特に問題は発見されず、そのレビューには IBM も参加していました。このアプリケーションには徹底した単体テストが実施され、良好なアプリケーション・ライフ・サイクルが維持されていました。その後このアプリケーションは、想定される実際の負荷をシミュレートする場である実動前テスト環境で使用されました。ところが、この実動前テスト環境で、WAS が勝手に再始動してしまう問題が発生したのです。
IBM とお客様は、長時間を費やして Application Server と Java Virtual Machine (JVM) からトレース情報を収集しました。そこで判明したのは、サード・パーティー企業が構築したアプリケーションの一部に場違いなコードが組み込まれていて、それが WAS の再始動を招いているということでした。サード・パーティー企業ではその場違いなコードが特に害を及ぼすことはないと考えていましたが、実際にはそのコードが原因で JVM がページ・フォールトをヒットし、強制終了シグナルをスローして、Application Server が再始動していたのです。その場違いなコードをアプリケーションから削除したところ、この問題点は解消されました。
可能な対策と予防措置:
アプリケーション・ライフ・サイクルに関して、以下の各項目について自問する習慣を徹底させましょう。
- アプリケーションは本来の意図に応じた処理を行っているか
すべてのアプリケーションは、何らかの課題の解決を目的として作成されています。課題の範囲は、販売する製品を提供することから医学上の謎の解明を支援することまで、多岐にわたる可能性があります。要するに、アプリケーションは 1 つの課題の解決を目的として作成されているのです。問題は、時間の経過とともにその要点が忘れられてしまうことにあります。アプリケーションは、「小さな機能をここに、また別の小さな機能をそこに」というように追加を繰り返しているうちに、次第に複雑化していきます。そしてふと気付いてみれば、医学上の謎に関する書籍を販売するとともにその医学上の謎の解明の支援も行うといったアプリケーションが出来上がってしまいます。
アプリケーションの独自性を維持し、本来の目的である処理に対してアプリケーションを使用するよう努めましょう。複数の機能 (書籍販売と研究実施など) をアプリケーションで処理する必要がある場合は、その機能を複数のアプリケーションに分割します。そうすれば、アプリケーションに問題が生じた場合に問題点を隔離しやすくなり、ビジネスへの影響を軽減することができます。ビジネス全体が単一のアプリケーションに組み込まれていると、その単一アプリケーションに何らか問題が生じた場合、ビジネス全体が問題を抱えることになってしまいます。
- アプリケーションはモデリング言語を用いて設計されているか
アプリケーションの品質はまず、そのアプリケーションが意図しているところのアイデアの品質によって決まります。そしてそのアイデアの設計が、高品質アプリケーションの作成における次のステップとなります。紙ナプキンに走り書きしたアプリケーション設計と、Unified Modeling Language (UML) を用いたモデリング・ツールで作成したアプリケーション設計とを比較した場合、その違いは完成後のアプリケーションに現れることになります。何かに対する適切なチェックが行われなかったために発生する NullPointerException 例外よりも高いレベルでアプリケーションに問題が発生するというのは、よくあることです。
問題点はアプリケーション設計時に発生する可能性があり、実際、その時点で発生しています。問題点がアプリケーション設計レベルで発生した場合、保守性の観点から問題点を発見することが非常に難しくなるうえ、修正も困難を極めます。したがって、堅固な設計を行うよう心がけなければなりません。設計のレビューを繰り返し、最新の状態を維持しましょう。技術上の見落としが原因で設計の変更が必要になった場合は、設計を更新するとともに、アプリケーションのそれ以外の部分にその変更がどのように影響するかを判別します。アプリケーションがデプロイされて既にトラフィックに応答している段階になって、ようやく変更による影響の内容が判明するというのは、タイミングとして望ましくありません。
- アプリケーションのコード・レビューは、コード作成者以外の人員が行っているか
アプリケーション設計と同様に、設計実装の品質もまた、アプリケーションが設計意図に応じてどの程度的確にタスクを実行するかということに影響します。設計実装フェーズは、数多くの問題点が発生するフェーズでもあります。100 人のプログラマーに設計を見せれば、その 100 人のプログラマーが 100 通りの方法で設計を実装する可能性が非常に高いということは、誰もが知っている事実です。このような実装の多様性は、設計上の不備の結果としてではなく、各プログラマーがそれぞれ独自の解釈と実装の流儀を有していることから生じるものです。
コード・レビュー時には、設計からコードに変換された内容がどのように実装されているかという点にも注目します。最適なデータ構造が最も効果的に使用されている部分はどこでしょうか。オブジェクト自体は、メモリー・リークを防止するよう適切に管理されているでしょうか。
コードが設計と合致していることを保証する最善の方法は、第 2 または第 3 の個人またはチームに、設計からコードに変換された内容をレビューしてもらい、比較してもらうことです。また、それらの個人またはチームにコードの技術的正確性を確認してもらうことも必要です。このプロセスにより、設計以外の部分にアプリケーションの問題が生じる後々のフェーズにおいて、作業時間が大幅に短縮されます。
- アプリケーションの保守は容易か
コード・レビュー時に、保守性の観点に立ったコード・レビューが行われているでしょうか。プログラマーは一般に、自分が書いたコードに問題が生じるはずがないと考えているものです。しかし、もしそれが真実ならば、皆さんがこのホワイト・ペーパーを読むこともないはずです。
コードの保守性はきわめて重要です。WAS とその上で稼働するアプリケーションの両方が、優れた保守性を備えていなければなりません。純粋にアプリケーションに起因する問題点を発見し、そのトラブルシューティングを行って解決を図ろうとするときに、WAS の高い保守性が役立つケースは多々あります。そのような事例では、アプリケーション開発者は、保守性に優れたコードをアプリケーションに組み込んでいなかったのです。
アプリケーション・エラーを解決するための最後の防衛手段は、アプリケーションのロギングです。以下のことを自問してみましょう。
- プログラマーの作業時間をほんの数時間短縮することは、プログラマーの人件費を削ってまで行うほど重要か
- e-ビジネスを急いで再開することは、e-ビジネスが利用不能な状態に陥っている間に売上が生じないことによる損失を覚悟してまで行うほど重要か
検証による、ソフトウェアがニーズに合致していることの確認
- 実動トラフィック・プロファイルの不備
この間違い行為は、ルーター、ネットワーク、スイッチ、ハブの配置を示すネットワーク図が存在しないことに関連するものです。また、ネットワークやネットワーク・セグメントの処理能力についてのデータが欠如していることにも関連しています。
まだ見ぬ土地に行くとしたら、どのような手段を取るでしょうか。誰かに道を聞きますか。それとも地図を使いますか。そのプロセスは実際にどの程度役立つでしょうか。道順を間違ったり交通渋滞に巻き込まれたりした場合、どのようなことが起こるでしょうか。Web アプリケーション開発に関する記事でこうした質問をするのは愚かだと感じられるかもしれませんが、実はコンピューター・ネットワーク上のデータと自動車との間にそれほどの違いはないのです。幹線道路の混雑が進み、処理できないレベルの交通量に達すると、車の流れは完全に止まってしまいます。このような状況はコンピューター・ネットワーク内でも常に発生しています。そうした事態の発生はわかっており、その防止方法も周知されていますが、現実には予算や納期の制約があるため、常に適切なタイミングと方法で介入できるわけではありません。
幹線道路の設計者は、建設する道路の規模をどのようにして決定するのでしょうか。どこに停止信号を新設すれば人身事故を防止できるかを、どのようにして判断しているのでしょうか。幹線道路沿いへの出店を計画している店舗経営者は、ドライバーの目に付きやすい立地場所をどのようにして判別しているのでしょうか。地方自治体は、新たな幹線道路インフラに投資するにあたり、複雑な交通調査を実施して将来の成長のモデルを作成します。このプランニング手法があって初めて、地方自治体が将来の成長を見越した計画を立案し、以後何十年にもわたって住民の便宜を図ることが可能となるのです。エンタープライズ・レベルの Web アプリケーションを構築する際にも、この種の調査や細部への注意が必要となります。
コンピューター・ネットワーク上のデータは、ある領域から別の領域への移動方法をどのようにして知るのでしょうか。ルーティング・テーブルは道路地図になぞらえることができます。ルーティング・テーブルは「正確ではあるが、さほど詳しくはない道路地図」なのです。本当の意味でデータを制御するためには、このプロセスをさらに一歩進める必要があります。すなわち、ネットワーク・トポロジーの詳細なビューが必須となります。
事例:
ある保険会社が、WAS の構成でハング状態が発生すると訴えてきました。そこで IBM SWサービス のアナリストが問題の解明に当たりましたが、ソフトウェア内では明らかにそれとわかるハング状況は報告されませんでした。オペレーティング・システムも、問題点を一切報告しませんでした。問題判別の結果、ネットワーク内を除くすべての問題の可能性が排除されました。
この問題のトラブルシューティングの支援に当たっていたシステム・アナリストは、問題の原因がネットワーク内にあるのではないかと考え、ネットワーク・フロー・チャートの検査を要請しました。ところが残念なことに、現行のネットワーク図が存在しなかったのです。そこでアナリストは、ネットワークの保守に共同責任を負っている各チームへの聞き取り調査を行いました。その結果、最近ネットワークに新しいハブが追加されたという事実が徐々に明らかになってきました。このハブは別の領域とトラフィックを共有する目的で使用されていたのですが、このハブによってネットワークのそれ以外の部分の処理速度が WAS がハングしているように見えるほどに低下していたというわけです。
可能な対策と予防措置:
ネットワーク図を作成し、最新の状態に維持してください。たとえ最も無害であると思われる変更であっても、予想もしないほどの多大な影響を及ぼす可能性があります。ネットワークへのハードウェアの追加はあくまでも慎重に進め、その計画をチーム全体に伝達するようにしましょう。
ここでは、以下の情報が必要となります。
- ルーターおよびファイアウォールの配置場所
- 各ネットワーク・セグメント上のサーバーの配置場所
- 各サーバーにおける、予想されるトラフィック処理量
- トラフィックを処理するための十分な帯域幅の確保
ネットワーク設計を予想されるトラフィックと合致させることは、技術であると同時に科学でもあります。経験とデータを組み合わせることにより、ネットワークがプレッシャーにどれほど耐えられるかを知ることができます。
- 負荷/ストレス・テストの不備
機能テスト終了後、アプリケーションを実動システムに移行させる前に、ユーザーはアプリケーションに対して徹底的で過酷な負荷/ストレス・テストを実施する必要があります。負荷/ストレス・テストでは、アプリケーションの部品をすべて組み込んで現実世界のワークロード・パターンやユーザー・パターンをシミュレートするという方法が理想的です。この負荷/ストレス・テストの目的は、システムを極限状況に置いた場合のパフォーマンス上の影響について判別することと、機能テスト時に発見されなかったプログラム・エラーをすべて発見することにあります。実稼働環境に近い、真の堅牢性を問う一連のテストを繰り返し実行することは、Java アプリケーションの「緩慢な」メモリー・リークを識別するために非常に役立つ可能性があります。パフォーマンスを測定し、さらにメモリー使用量から各種の測定値を割り出すことは、アプリケーションによるメモリー・リークを的確に識別することにつながります。アプリケーションを実稼働環境に移行させる前にこの種の「緩慢な」メモリー・リークの存在を把握するには、大量のストレス・テストやパフォーマンス・テストを繰り返し実行する必要があります。
このように重要なテストであるにもかかわらず、一部のお客様は負荷/ストレス・テストをバイパスして開発システムから実動システムに直接移行することを選択します。しかし以下に紹介する現実世界の教訓が示すように、その結果は悲惨なものとなる可能性があります。
事例 1:
ある欧州の企業が、zSeries プラットフォーム上の WAS for zLinux に関して、深刻なパフォーマンス上の問題に見舞われていました。使用率の高さが原因でシステムの処理速度が低下し、その結果、ユーザーへの応答に長時間を要していたのです。
そこで IBM SWサービス が綿密な調査を実施し、以下の問題点を発見しました。
- z/OS Virtual Machine (zVM®) が適切に調整されていない拡張ストレージ容量が 2GB に設定されていた (推奨設定値は 4GB ～ 6GB)
- アプリケーションの設計が貧弱で、デッドロックが潜在している可能性があった
- アプリケーションにラージ・オブジェクトが多数組み込まれていた
適切な設定値と潜在的なプログラム・エラーを発見するために、SWサービス では、1 人～ 500 人のユーザーによる利用をシミュレートした負荷テストを実施しました。この負荷テストを通して、IBM とお客様は、最適な設定値とアプリケーション・コード内のデッドロックを特定しました。その後、実動システムに修正を施したところ、アプリケーションはパフォーマンス上の問題を起こすことなく円滑に動作するようになりました。
事例 2:
ある大規模なメディア企業で、カタログ・アプリケーションの速度低下が頻繁に起こり、Web ブラウザーがブランク・ページを返すという問題が発生しました。IBM SWサービス がログ・ファイルを調べたところ、ガーベッジ・コレクターに過剰な活動が見られることが判明しました。
そこで SWサービス が品質保証環境内でストレス・テストを実施した結果、ガーベッジ・コレクターの動作と 1GB を超える大きなファイルのダウンロードとの間に相関関係があることがわかりました。根本原因は、あるサーブレットがサイズの大きなファイルをメモリー内にキャッシュしようとしていることにありました。サーブレットによるキャッシングを無効化したところ、問題は解消しました。
可能な対策と予防措置:
上記の 2 つの事例は、徹底的で過酷な負荷/ストレス・テストを実施することがどれほど重要であるかを示しています。どちらの事例でも、お客様が品質保証環境内で負荷/ストレス・テストを実施していれば、実動システムに移行して実際に稼働停止を引き起こすよりもずっと以前の段階で問題点が発見されていた可能性があります。
まず認識しなければならないのは、単体テストやシステム・テストは負荷/ストレス・テストの代わりにはならないということです。一般に、負荷テストは新規システムがその設計仕様を満足していることを検証する目的で実施されます。またストレス・テストでは、負荷の大きな極限状況におけるシステムの安定性が検証されます。
既存アプリケーション
既存アプリケーションについては、ピーク時の負荷、ピーク期間の長さ、ピークが発生する時間帯などを正確に把握しなければなりません。また、使用パターンの分析も必要となります。使用パターンとは、例えば、同時に何人のユーザーがトランザクションに積極的に関わるか、あるいは何人のユーザーがカタログを参照するかといったことです。これらのパターンは、システムのワークロードに大きく影響する可能性があります。
この知識は、テスト・スクリプトの準備作業に利用できます。現実の使用パターンに則ってピーク負荷に近いレベルにまでワークロードを増大させることができる、テスト・スクリプトを準備してください。できれば、実稼働環境に移行する前に同一の実動システム上で負荷/ストレス・テストを実施するという方法が理想的です。その方法が実現不可能な場合は、実動システムになるべく類似した品質保証システムを用意します。
新規アプリケーション
新規アプリケーションの使用方法がわからない場合は、設計関連文書と常識に従って、テスト・スクリプトの準備を進める必要があります。賢明なのは、最初はなるべく無難な設定を使用し、それとともに最悪のケースのシナリオにも備えるという進め方です。
Java のメモリー・リークに関する有用なリンク:
- 実稼働環境とテスト環境の同等性の不備
実動システムとまったく同一のテスト・システムを別個に用意することが推奨されます。前セクションで説明したように、独立したテスト・システムがあれば、実動システムへの移行前にそのテスト・システム上で負荷/ストレス・テストを実施できます。独立したテスト・システムには、以下の利点があります。
- テスト・システムが実動システムから分離されているため、予定外の稼働中断が防止される
- メジャー・アップグレードの実行に先立って機能性と保全性のテストを実施できるように、そのためのプラットフォームが提供される
WAS ユーザーの大半は、ある種のテスト環境を有しています。ただし、コスト上の理由により、それらの環境は必ずしも実動システムとまったく同一というわけではありません。独立したテスト環境の欠如が稼働停止の原因となった事例はいくつも見られます。
事例:
ある南米の大手銀行で、WAS for z/OS が納税申告の時期に頻繁に稼働停止を起こすという問題が発生しました。この問題が原因で、顧客のオンライン納税手続きが中断されてしまい、この銀行と顧客との関係が損われていました。IBM SWサービス による調査の結果、多数の要因がこの状況を生み出していることが判明しましたが、主に発見されたのは構成上の誤りでした。
誤りの一例としては、WAS 基本バージョンのインストール済み環境 1 つにアプリケーション・サーバーを 2 つ作成していたことが挙げられます。この 2 つのアプリケーション・サーバーのうち、1 つはテスト・サーバーであり、もう 1 つは実動サーバーです。両アプリケーション・サーバーは同じ Application Server 基本バージョン上で稼働しているため、ログは共有されていました。また、ポートは競合を回避するよう慎重に構成されていました。そしてここで最も重要なのは、両者が同じバイナリー・コードのベース上で稼働していることが原因で、Software Development Kit (SDK) に対するあらゆるアップグレードが両方のアプリケーション・サーバーの稼働を中断させていたということです。テスト・システムに対する頻繁な更新は必要ですが、そのたびに実動システムの稼働が中断するという事態はとうてい許容できません。
この誤りが判明したことを受けて、SWサービス は、Application Server のテスト・システムと実動システムを別々の論理分割モード (LPAR) に配置して互いに影響し合わないようにするよう、お客様に対して強く提案しました。この両システムの分離を終えると、その後の問題判別作業は円滑に進みました。
開発者の一部は、実用上または経済上の理由から、独立したテスト・システムの作成を怠ります。確かに、テスト・システムと実動システムをひとまとめにしておけば便利かもしれません。また、テスト専用のシステムを特別に設けることは無駄に見えるかもしれません。しかし、その利便性が結局は高くつき、実動システムの稼働停止は多大な損失を招くということを、しっかり理解しなければなりません。
可能な対策と予防措置:
テスト環境を構築するためのアプローチは数多く存在します。そしてアプローチごとに、コスト、計画策定、リスクが異なります。アプリケーションだけでなくアプリケーション環境をテストする機能を備えていることが必須となります。
テスト環境の構築に際しては、以下のチェックリストを使用します。
- テスト・システムがぜいたく品ではなく必需品であることを理解し、実動システムをテスト目的では使用しないようにします。
- テスト・システムを実動システムから物理的に分離し、できれば、システムを管理するオペレーターも別々の 2 グループ編成とします。
- 別々のセキュリティー ID セットでラベル付けすることによって、テスト・システムと実動システムを明確に区別します。
- テスト・システム上には実動システムとまったく同一のソフトウェアをインストールします。ハードウェアについても、テスト・システムと実動システムとでなるべく似通ったものを使用することが推奨されます。
- WAS およびアプリケーション自体をアップグレードする際には、まずテスト・システム上で実施してから、実動システムをアップグレードするようにします。
以下のリストは、リソースの可用性に基づいて、さまざまなタイプのテスト環境について記述したものです。
- 実稼働環境の完全な複製を維持するもの
- 予想される負荷を複製する負荷生成機能を備えた、実稼働環境より小規模な環境を維持するもの
- 環境のモデルまたはシミュレーションを維持するもの
変更点はすべて、実稼働環境に追加する前に、テスト環境内に実装してテストすることが推奨されます。
- 実稼働環境に対する、変更内容の直接適用
ほとんどの企業がテスト・システムと実動システムの違いを理解していますが、その多くは、テスト・システムを丸ごとバイパスして実動システムに変更内容を直接組み込むほうが便利だと考えています。テスト・システムのバイパスを主張する理由として一般的なのは、実動システムを緊急に更新する必要があったためにシステム管理者が例外的な措置を講じざるを得なかったというものです。
確かに、ときには実動システムに緊急のパッチが必要になることもあるでしょう。しかし推奨されるのはやはり、正式のチャネルを使用することです。例えば、テスト・システムに変更内容を適用し、そこで徹底的なテストを実施したうえで実動システムにその変更内容を移すという方法が望まれます。変更を実動システムに直接適用すると、テスト・システムの存在意義が失われるとともに、文書化されていない変更が実動システムに残されることになります。さらに、実動サーバーを直接更新した場合、1 つのシステム上に WAS のバージョンとパッチ・レベルが複数作り出され、将来の保守作業がまさに「悪夢」となってしまう恐れがあります。
事例 1:
ある大規模なメディア企業が、Web サイトの稼働停止が頻繁に発生するという問題に悩まされていました。IBM チームは、メモリー上の問題が稼働停止の原因であることを突き止めました。アプリケーション・コードがヒープのフラグメント化を引き起こしていたのです。IBM はさまざまなガーベッジ・コレクターの設定を提案しましたが、その結果は一定せず、マシンによってまちまちでした。そこで詳細に調査したところ、WAS の 4 つのインストール済み環境が同一のものになっていないことが判明しました。SDK のレベルや修正パッケージが環境ごとに異なり、暫定修正までもが食い違っていたのです。そのような状態で WAS がともかく動作していたことが、むしろ驚きでした。各インストール済み環境に適切なガーベッジ・コレクターの設定とアプリケーション・コードを組み込み、それぞれ最新バージョンの SDK にアップグレードしたところ、ヒープのフラグメント化の問題は解消しました。
事例 2:
ある大手銀行が稼働停止の原因を究明しようとしていました。IBM チームが設計関連文書を確認したところ、最近 2 年間更新されていないことが判明しました。その間、何の記録も残さずに、実動システムに対して数多くの変更が加えられていたのです。
変更内容を実動システムに直接適用するという方法は確かに便利かもしれません。しかし、それは決してベスト・プラクティスとして推奨されることではなく、むしろ回避すべきことです。大規模なシステムにおいては、複数のシステムに対して同一の更新を適用することは非常に難しいものですが、変更内容を常に記録しておくことはさらに困難を極めます。実動システムに問題が発生した場合、問題判別を実行することは非常に困難です。さらに、実動システムに対して「不用意な」態度で臨めば、重要データのセキュリティーを損ないかねません。
可能な対策と予防措置:
変更内容を実動システムに直接適用することを防止するには、以下のチェックリストを使用します。
- 実動システムに対するあらゆる変更の適用について、厳格な手順を定めます。また、すべての変更内容を記録します。
- 開発チームから完全に独立した形で実動システムに対してのみ責任を負う、実動システム管理グループを編成します。
- 実動システムのパッチと更新を行うための、保守作業専用の時間を確保します。それ以外の時間帯には実動システムに対する変更を一切行わないようにします。
- 緊急の状況、特にセキュリティーに関わる状況においては、実動システムに直接変更を加えてもかまいませんが、その変更内容を必ず詳細に文書化するとともに、それがあくまでも例外的な措置であるという認識を徹底するようにします。また、すべてのシステムが同一であるという状態を維持するため、可能な限り早期にテスト・システムにも同じ変更を適用します。
実稼働中/稼動後
- マイグレーション計画の不備
製品のマイグレーションは、経験豊富な開発者にとっても非常に難しい作業となる可能性があります。J2EE 標準には J2EE サーバーのプラットフォーム依存性とベンダー依存性を軽減する努力が反映されているため、J2EE のマイグレーションは他製品より比較的容易だといえます。
実際に行われる大規模なマイグレーションとしては、以下の種類があります。
- 1 つのメジャー・バージョンから別のバージョンへの WAS のアップグレード (バージョン 4.0 からバージョン 5.0 にアップグレードする場合など)
- 他の J2EE サーバーまたは他のオペレーティング・システムからのマイグレーション
円滑な移行を保証するために、相違点の詳細なリストを作成し、必要に応じてコードを修正します。この措置を怠ると、マイグレーションが実動システムのパフォーマンスと安定性に悪影響を及ぼす可能性があります。
事例:
アジア太平洋地域のある大手銀行が、WAS バージョン 4.0 からバージョン 5.0 へのマイグレーションを実施したところ、パフォーマンスが大幅に低下するという問題に見舞われました。そこで WebSphere MQ Workflow を比較的新しいバージョンにアップグレードしましたが、今度はシステムがランダムにクラッシュするようになってしまいました。
綿密な調査の結果、以下の問題点が明らかになりました。
ここで開発者が行うべきことは明白です。それは、バージョン間の相違点を慎重に分析し、J2EE 仕様およびその他の設定を分析したうえで、アプリケーション・コードかデフォルト設定のいずれかに対して必要な変更を加えることです。J2EE 仕様にはマイグレーションを容易化するための努力が反映されていますが、それですべてに対応できるわけではありません。
可能な対策と予防措置:
マイグレーションの実施に際して開発者は、現行システムに関する既存の文書を参照し、その内容を WAS の新バージョンと比較して、すべての相違点とその調整方法を文書にまとめる必要があります。
以下の各項目に注意することによって、マイグレーションに伴ういくつかの危険要因を阻止してください。
- J2EE 仕様の変更点
- バージョン間でのデフォルト設定の相違点
- ベンダー独自の拡張機能における相違点
- オペレーティング・システム固有の構成に対する変更点
マイグレーションに関する有用なリンク:
- 変更の記録の不備
何を変更したのかは、ほんの数日で忘れてしまうものです。アプリケーションの変更であっても、WAS の構成変更であっても、オペレーティング・システム全体にわたる変更であっても、忘れてしまうという点では変わりません。
実動システムとテスト・システムへのアクセス権を持つ人数が増えるにつれて、変更記録を集中管理することの重要性は増していきます。変更の記録があれば、システムへのアクセス権を持つ誰もが変更内容を追跡し、問題領域の絞り込みに役立てることが可能となります。
事例:
ある製薬会社が、テスト環境内で新規アプリケーションのテストを実施していました。そしてすべてが順調に進み、いよいよ実稼働環境内にその新規アプリケーションをインストールすることになりました。ところがアプリケーション・サーバーは始動せず、ClassCastException の例外が出力されました。テスト・サーバーと実動サーバーの構成は同一です。Application Server、アプリケーション、各パラメーター設定とも、両者に違いはありません。この事態は謎でした。しかし社内の他部門にはテストは順調に進んでいると知らせていたため、何としてもこのアプリケーションを早急に立ち上げる必要がありました。
開発スタッフは、それぞれ自分の頭の中にある変更記録をたどって、何を変更したかを思い出そうとしました。集中管理された変更記録があればよかったのですが、そんなものは存在しません。開発スタッフやシステム管理スタッフの中には、テスト・システムと実動システムの両方へのアクセス権を持つメンバーが複数いました。しかし残念なことに、その全員が休暇のため不在でした。
結局、ある開発者が、テスト環境と実稼働環境では共用ライブラリーのバージョンがわずかに異なっているということを思い出しました。そのライブラリーを変更したところ、すべてが問題なく動作するようになりました。
可能な対策と予防措置:
この間違い行為を予防するには、以下のチェックリストを使用します。
集中管理された変更記録システムを使用し、その管理を厳重に行います。
関係者全員に変更内容を周知させるための厳格なプロセスを策定します。
少し時間を取ってこのプロセスを遂行しておけば後になって大問題が発生して当惑するといったことがなくなるという事実を、しっかりと認識しましょう。
全段階共通
- コミュニケーションの断絶
コミュニケーションの断絶はさまざまな経緯で発生する可能性があります。コミュニケーションは常に双方向なので、口頭と書面など、複数の形式で情報を伝達することによって強化する必要があります。プロジェクト管理では、コミュニケーションを通じて、職務の遂行、情報の授受、結論への到達、合意の形成、関係の構築などが実現されます。コミュニケーションの手法を正しく利用できるかどうかがデプロイメントの成否を決定します。
コミュニケーション関連の障壁となる以下に示す事項について、認識する必要があります。
- 製品の更新を考慮しない製品インストール
- 環境の把握
- 経営陣とのやり取り
- 企業文化に関する問題点の考慮
- デプロイメント時期の決定
- 差し迫ったデプロイメントの影響を受ける製品/サービス所有者との連携
- バックアウト・プランの用意
製品、アプリケーション、ビジネス・プロセスなどのライフ・サイクルを円滑に、そして生産的なものにするためには、誰が誰にいつ何をどのようにして伝達する必要があるかということが重要となります。
事例:
zSeries® マシン上で夜間に在庫処理を行っている、大規模な食料品チェーン企業があります。この企業が、店舗ごとに店内在庫一覧に基づいて納入業者への発注書を生成する Web アプリケーションを新規導入しました。
新規アプリケーションは Java で書かれており、分散マシン上でのテストが完了していましたが、このアプリケーションが実際に稼働したのは zSeries マシン上でした。このアプリケーションでは、発注内容に異常なパターンが検出された場合やアプリケーションにエラーが発生した場合、警告メッセージのリストが出力されます。ごく新しい作りのアプリケーションなので、エラーの出力もアプリケーションの機能として組み込まれていました。
このアプリケーションは、開発部門の要請に従って、納品後 zSeries マシン上にデプロイされました。zSeries マシンの運用に当たる運用グループは、各プログラムの始動や停止、およびシステム・プログラマーとしてのそれ以外の職務を普通に実行していました。z/OS システムから何が出力されるのかについては運用グループも知っていましたが、各アプリケーションの出力先がディスクのみだったため、今回の新規アプリケーションの処理内容についてはまったく認識していませんでした。
アプリケーション開発者の側では、運用グループのメンバーが「システム・プログラマー」と呼ばれていることを知っていたため、その職務がシステム管理ではなくプログラム作成であるものと思い込んでいました。したがって、アプリケーションの動作内容についても、アプリケーションにエラーが発生したり異常なパターンが検出されたりした場合に何をすればよいかということについても、説明することはありませんでした。
この新規アプリケーションが、店舗への補充品の新規発注処理に関して、適切に動作していない様子が認められました。ところが開発者側では、出力を受け取ることがなかったため、問題の存在を認識していませんでした。経営者が開発者に問い詰めたところ、出力を受け取っていないので何も知らないという答えが返ってきました。一方、運用グループのシステム・プログラマーは、出力の目的も実際に出力が行われている理由も知らなかったため、余分な紙が出ていると思って出力紙をそのまま捨てていました。
誰かがアプリケーション開発/デプロイメントのライフ・サイクルを追跡し始めて、ようやくコミュニケーションの断絶が明らかとなりました。この段階になると両グループとも気が立っているため、コミュニケーションの構築に取り組むだけでなく、保身的な態度や昔ながらの悪習をひとまず脇に置いて事に当たることが必要となりました。
可能な対策と予防措置:
コミュニケーションの断絶を予防するには、以下のチェックリストを使用します。
- 何の話題について誰がどの程度まで伝達する必要があるのかを明確にします。
- 現行情報の同期が取れているかどうかを関係者間で確認するためのチェックリストを作成します。
- プロセスを関係者全員が理解していることを確認するために、定期的なミーティングを実施します。
- スタッフの誰かが職務を離れる場合は、バックアップ要員が現状を正確に把握しておかなければなりません。
稼働停止がビジネスに及ぼす影響
Web サイトのダウンは、どのような e-ビジネス・ベンダーにとっても、まさに悪夢となり得る事態です。稼働停止が発生すると、直接的な売上の損失以外に、ベンダーの信頼性が傷ついたり、競合他社に付け入る隙を与えたりといった影響が出ます。多くの e-ビジネス・ベンダーが、製品選択時の最重要要因として安全性を挙げています。ところが大部分のベンダーは、稼働停止が実際に発生した場合のコストについて明確に理解してはいません。
以下のワークシートは、製品の稼働停止時や Web サイトのダウン時に発生する金銭的コストを見積もったものです。それ以外の非金銭的コスト、例えば顧客ロイヤルティーや物品の損失などについては、定量化が難しいためここでは論じません。
オンライン専門の小売業者の場合
| 1 時間あたりの取引件数 | 取引の平均価値 ($) | ダウン時間 (時間) | 稼働停止のコスト ($) |
|---|
| T | V | H | C=T*V*H | | 100 件 (通常時期) | $561 | 12 | $5,600 | | 300 件 (ピーク時期) | $56 | 1 | $16,800 |
オンライン店舗と従来型店舗の両方を展開している小売業者の場合
| 1 時間あたりの取引件数 | 取引の平均価値 ($) | オンライン・ビジネスの割合 | ダウン時間 (時間) | 稼働停止のコスト ($) |
|---|
| T | V | P | H | C=T*V*P*H | | 500 件 (通常時期) | $56 | 50% | 1 | $14,000 | | 1500 件 (ピーク時期) | $56 | 50% | 1 | $42,000 |
1. 米国内の小売業者における取引の平均価値は 56 ドルです。
2. 稼働停止からのリカバリー時間は、通常の業務時間内であれば通常 45 分程度です。ただし稼働停止が業務時間外に発生した場合、復旧にはそれよりかなり長い時間を要することがあります。
上の表では、典型的な中堅規模 e-ビジネス・ベンダーにおける稼働停止コストを示しました。各ベンダーの独自の数値をこの表にはめ込むと、実際の稼働停止コストを算出できます。これらの数値を利用すれば、費用と利益のバランス、提供サービスのレベル (1 日 24 時間 週 7 日か、平日の午前 8 時から午後 5 時までか)、製品の可用性を向上させるために投資すべき金額などを割り出すことが可能です。
ここに示したコストは稼働停止による直接的な損失を示したものに過ぎないということを、心に留めておいてください。例えば、実動サーバーが利用不能になっている間はその分の売上が失われますが、それはこの損失に該当します。しかしそれ以外にも、誠意の喪失、顧客ロイヤルティーの喪失、競合他社の攻勢など、間接的なコストが多数存在します。
大規模なオンライン・ビジネスの場合、直接的な損失よりも間接的な損失の方がはるかに大きくなる可能性があります。稼働停止によって生じた悪評によるダメージは特に深刻です。ただし、その種の損失の金額を正確に算定するのはかなり難しく、この記事で取り扱う範囲を逸脱しているため、ここでは論じません。
まとめ
企業による大規模なコスト削減が節減ではなく損失を招いてしまうことがあります。情報テクノロジー・プロジェクトを成功に導くためには、実稼働環境と同等のテスト環境を配備することが非常に重要です。ところが、変更内容を実稼働環境に適用する前にテスト環境を利用するという手順がしばしば破られています。変動の激しい世界において、綿密な工程に従って変更内容の記録を維持管理することは困難です。それでも、変更内容を追跡することは重要なのです。
付録
付録 A. 教育計画用ワークシート
| 製品またはプロセス | 教育トピック | ソースまたはクラス | 参加者 | 参加日時 | 教育内容の有用性についての評価 1-10* |
|---|
| 1 | | | | | | | 2 | | | | | | | 3 | | | | | | | 4 | | | | | | | 5 | | | | | |
* 評価点は 1 が最低、10 が最高を表します
付録 B. アーキテクチャー計画追跡用ワークシート
| 変更日 | 変更の内容 | 改訂後のアーキテクチャーのロケーション | 改訂版の設計担当者 | 改訂版のレビュー担当者 | 改訂版の承認者 |
|---|
| 1 | | | | | | | 2 | | | | | | | 3 | | | | | | | 4 | | | | | | | 5 | | | | | |
付録 C. 変更内容追跡用ワークシート
| 変更日時 | ホスト名 | 変更の適用範囲(セル、サーバー、アプリケーション、オペレーティング・システム) | 変更の具体的内容 | 変更の理由 | 担当者とその電話番号 | 変更情報の配布先 |
|---|
| 1 | | | | | | | | 2 | | | | | | | | 3 | | | | | | | | 4 | | | | | | |
文書の変更履歴
文書のバージョンについては、フッターの日付で確認してください。
2006 年 4 月 10 日 文書の初稿
2006 年 4 月 14 日 最終リリース
初回発行日
2006/4/14
相互参照情報
| セグメント | 製品 | コンポーネント | プラットフォーム | バージョン | エディション |
|---|
| アプリケーション・サーバー | WebSphere Application Server for z/OS | Java SDK | | 6.0.2, 6.0.1, 5.1, 5.0, 4.0 | | | アプリケーション・サーバー | Java テクノロジー用ランタイム環境 | Java SDK | | | |
著作権と商標に関する情報
IBM、IBM ロゴ、および ibm.com は、International Business Machines Corporation の米国およびその他の国における商標または登録商標です。他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtml の「Copyright and trademark information」をご覧ください。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| PDF版（英語） | Common Malpractice April 25, 2006.pdf | 294KB | HTTP |
|---|
この記事を評価する
| 
