パフォーマンス最適化とは、システムを限られたリソースで最適な処理状態にすることです。 何か問題があるということは、現在の状態と目標の状態との間に差があるということです。つまり、現在の状態の測定(又は 確認)結果と目標の 状態の決定(又は 設定)の違いが、問題点ということです。 性能問題も同じ観点で定義されます。現システムについてのテスト又は運用システムをモニタリングすることで現在の状態を測定し目標とする性能を決定することができます。 一般社会の現象においては、問題を正確に認識して目標を正しく設定すれば、その問題の解決は簡単です。 しかし、システムでは現システムの性能状態が正確に測定されても目標を設定するだけではアプローチできない要素が存在します。 突然システムがダウンした場合、現状は異常なシステムダウンであり、目標は安定した運用です。このような 状況では問題の原因を分析する事は困難です。なぜなら問題が数値で定量化されず、yes/no の形態であるため、どの程度改善されたのかがわからず、all or nothingで判断するしかないからです。 この様な状況下において問題を解決することは、コンサルトの立場からすると、ある意味で賭けのようなものです。

システム最適化

性能最適化はシステムを限られたリソースで最適な処理状態にすることです。 最適な性能を発揮させるためには、リソース(CPU,MEM,NETなど)を除く全てのボトルネックが 無く、障害が発生しないことが重要です。リソースの ボトルネックはリソースを増設することで解決できます。(ただし非正常的な リソース使用は除く。) 障害はサービスが不可能な状態を意味し、これはバグによる システムダウンも含みます。 システム最適化は一般的に処理量を最大にするためのチューニングや障害などを解決することです

障害解決

障害はサービス停止又は過度な応答時間遅延による実質的なサービス不可能状態を含みます。したがって障害の解決とはサービス 不能状態の原因を探し出してそれを解決することです。障害の解決には性能テストが必ずしも先行するとは限りません。システムダウン、Out Of Memoryエラーなどは代表的な障害現象ですが、障害は一般的に直感的に把握されるため、分析過程がありません。しかし、人為的な現象再現は重要です。必要な時点で現象再現が可能であれば70～80%は障害を解決できます。特に開発サーバで再現可能であれば、論理的思考さえあれば誰でも障害を解決できます。それほど、障害の解決のためには、現象再現は重要です。

性能チューニング

最適化活動の難しさ

応答時間を改善し、処理量を増やしてシステムダウンの原因を探すことは困難です。最適化は単に技術的な難しさのみならず、状況的、又はアプローチの面でも困難があります。以下のような難しい点があげられます。

• 問題定義が難しい(性能分析が含まれた場合) 何か問題があるのか、それ自体が不明確な場合です。レガシシステムをテストせずに 感覚にたよってシステム性能目標を決定したり、厳しい環境で簡単なテストの結果だけを現システムの性能として規定したりする場合には、問題定義そのものがないということになります。問題の定義が不明確な状態で性能をチューニングするのは、目標が無いのと同じです。

• 原因把握が難しい 運用前又は運用中のシステムに現れるタイプで現象は明確でも原因を探すのが 難しい場合があります。サーバS/W, H/W, パッケージのバグの場合が多いです。

• Follow Up 又は 検証が難しい 運用システムに現れる特徴で、障害原因は把握したがそれを解決することが難しい場合、 又は障害を解決することができたのかどうか確信できなかったり証明できなかったりする場合です。コーディングの標準が 正しくないか、教育が 不十分で修正すべきプログラムが多い場合です。

最適化活動が難しい事例としては以下のようなことがあります。

• 不安でシステムを確認したい =>[まず問題があるのかどうかを確認すべき]　
• 突然何のログもなくダウンした=>[モニタリング・ツールをインストール後、確認する]　
• 解決のために該当コードを全て探して修正する=> [解決に時間、コストが掛かる]　　
• 受講受付の時、発生する。 =>[検証するために6ヶ月待つ]　

最適化活動のためのアドバイス

最適化活動の難しさは技術的問題から来る場合もありますが、未経験の場合には、アプローチ法に対する認識が不十分であることが原因である場合もあります。下記の内容は最適化活動時の注意事項です。

関心の振分けは問題解決の基本である。

初期は巨視的な観点で分析して範囲を絞ります。システム、応用、DB又は networkなど様々な分野に原因がないかどうかを確認する必要があります。 初期に巨視的にアプローチせず、現れた現象一つに執着して問題原因を即断すると多くは誤った結果を招きます。適切な時点に専門家が対応しないでミスが起こると、顧客に誤った情報を与える場合が多く、さらには障害の解決ができず障害解決担当者の信頼が失われかねません。チューニングをはじめる前に予測した原因の９割は正しくないと言えるでしょう。 この様に障害解決初期に見える問題よりは巨視的な観点で原因を分析し、初期に適切な 専門家に依頼する事が重要です。

- Top Down 方法でアプローチ

前項にもありましたが、部分的な現象に執着して原因全体を決定するのではなく、視点を全体において、そこから細分化してアプローチすることが重要です。全体的な観点で常に考えて発見されたことがらを継続的に解析する事でミスを防ぐことができます。

- 一つよりは二つがいい

心から協力できる人が多くいると問題の解決は容易になります。特に、利害関係がない人がお互い協力し合うことは問題解決で一番有効な方法です。そのため、異なる会社の専門家からなる組織の場合、お互いの利害関係により問題解決が遅くなることがよくあります。また、同じ会社内であっても、チームが違うことでこの様な現象が発生する場合もあります。

- 公開された仮説は担当者を保護する

障害原因は簡単に判断できない場合が多く、過度な確信による作業又は密室作業は障害が解決したとしてもシステムの円滑な開発および運用にプラスにはなりません。 過度な確信に基づいて特定部分の問題を解決したあとで、実はそれが原因ではないということがわかった場合、該当部分の担当者と対立が起き、その後の進行にプラスにはなりません。 起こっている現象を観察し、事実と、事実でないことを分離して、それについてチームとして論理的な仮説を立て予め公開する事で、各分野別担当者の関心を高め協力体制を築きあげることは何より重要です。これにより、その後実際に仮説が証明されたときも、迅速な処置が可能になります。

- 目(モニタリング ツール)を閉じると道(解決方法)が見えない。

いくら技術的専門家でも事実を収集しないと障害は解決できません。 このためには、 適切な ログ/モニタリング・ツールが必須です。ユーザに見える現象だけで 障害を解決しようとしたり、 経験/事例をもって解決しようとするのは、かなり無責任です。

- 日程は確約できない。

「三日以内に解決します」「○時間以内に解決します」・・・もちろん、ビジネス的にこのような目標は必要ですが、あくまでも目標です。障害解決又は性能チューニングは可能な限り早くする努力はしますが、確約はできません。

- 問題解決を感覚に依存するな

感覚方法とは、過去の同じような事例から、現システムの障害原因を感覚で決定することです。その感覚が当たれば即解決ということになりますが、違うと被害が大きく時間の無駄になります。また、問題解決担当者が直感を信じて過去の事例を基盤に問題の原因を決定すると初めは顧客 (運用担当者)に興味を持たせることはできますが、その直感が違っていれば、後で信頼を失うことになり、何もできない状態になります。

最後に

最適化活動には様々なタイプがあります。迅速に解決することが何より重要で、プロセス 又は対応方法も重要です。 適切な事例はその経験を組織的に蓄積し開発者/運用者が迅速に障害を解決できる様にするのがベストです。 その後、障害解決TFTを構成して、問題を即断せず担当者の信頼を維持しながら問題を解決することが必要です。

• 最終解決は人
• 分かれ道で選択能力のノウハウ
• 現象が100%解析(=原因把握)されると問題は100%解決
• 正確な決定は経験と事例に比例
• Factの収集(モニタリングが重要)