10 COMPLETELY OBVIOUS TUNING TIPS
CMGではコンピュータキャパシティに関する最新技術や管理手法、事例紹介といった内容のセッションが多いのですが、なかには自らの現場経験を元にした比較的柔らかい内容（？）のものもあります。
このセッションでは、メインフレーム／オープンシステムのチューニングに30年間携わってこられた方が10の経験則を発表されていました。その内容について概要をご紹介いたします。
1.常に全てのデータを
プラットフォームに関係なく、取得できる範囲で全てのデータを収集する必要があります。収集ツールでは24時間×7日間実行させておきます。昔から「測定できないものは管理できない」と言われているように、できる限り全てのものを測定しましょう。無視したリソースがあれば、あとで手痛い思いをすることになってしまいます。
また、データ収集だけで話は終わらず、どのように問題を解決するかが肝心になってきます。そのためにはまず、収集したデータは必ず保管する必要があります。保管場所がなければCDなどに保存して下さい。理想としてはパフォーマンス用データベースを準備して下さい。そうすることでトレンドを把握し、過去データを深堀することで現在と将来を理解することが可能になります。
2.最善を予想し最悪を計画せよ
ビジネス計画はあくまで推測です。成長の数値を与えられたなら、慎重に評価する必要があります。提示された数値をその通りに受け取ると、痛い目に会うかもしれません。パフォーマンスに問題があった場合、誰もビジネスの責任にはしません。それはあなたの責任となるのです。もしあなたが起こるはずもない成長を予想してキャパシティ計画に失敗したなら、金銭問題になりかねません。
このようなことに対応するには、まずあなたの知識と経験をベースに、増加割合の変動パターンを考慮しましょう（クリスマス直前はクレジットカード取引量が急増するなど）。
次に、モデリングツールがあれば、増加割合を変更してどの資源が最初に制限を受けることになるのかを試してみましょう。これは大変重要な情報となります。言うまでもありませんが、必要な資源が把握でき、不要なコストを削減することができるからです。
また、システム監視時には現状から垣間見ることのできる兆候に気を付けましょう。この兆候がキャパシティ計画に関する軌道修正のよい機会となります。
3.ビジネスを知りユーザを知る
もし、あなたの会社がどのようにして収益を上げているかを知らなければ、ビジネスを効率的に管理することはできません。そのビジネスに携わる人との会話や、各アプリケーションがどのようにビジネス要件に関係するのかを理解することは、大変価値のあることです。
ビジネス環境を理解した後は、誰がそのシステムを使用するのかを理解しましょう。今や多くのWebシステムはオープンの状態となっています。そのWebサイトに対して、あなたはどのように感じますか？何か困るようなことはありませんか？目的とする情報に到達するまで時間がかかり過ぎていないでしょうか？
4.ボトルネックはなくならない（移動する）
ボトルネックを完全に取り除くことはできません。次の待ち行列や領域に移動するだけです。始めは良好なレスポンスだとしても、その後は徐々に可用性を失い、レスポンス時間は遅くなります。システムチューニングは継続して行われるべきものなのです。ひとつの修正を行ったら、次のボトルネックに備えなければなりません。
5.全体を見渡す
あるアプリケーションに何か手を加えた場合、他からリソースを奪ってしまうこともあります。全ては相互的に繋がっており、いくつかの他のアプリケーションにとっては、不都合な条件を与える可能性があることに注意しなければなりません。
特定部分（特定アプリケーション）に工数を費やした時などは、一歩下がってシステム全体を広く見る必要があります。
6.1度に1箇所の変更（そしてドキュメント化）
設定変更は、1度に1箇所にしなければなりません。もし複数箇所の変更を1度に行った場合、そのうちどれが有効であったかをどのように知ることができるでしょうか。ある変更が別の変更によって打ち消されてしまうケースもあります。複数箇所を変更する唯一のケースは、それらが完全に関連しない場合のみです。
また、どのような変更でもドキュメントに残しましょう。日付／時間／変更の詳細はもちろん、期待できる効果などを記載するとよいでしょう。変更による実際の影響も記述して下さい。
7.より低コストの方法で
あなたは次の2つのことを理解しなければなりません。「システム資源にどれくらいのコストがかかるのか」「どのようにして資源の圧迫に気付くのか」
あなたがシステム資源のことを理解し、圧迫を受けているリソースを特定することができれば、考えられるトレードオフを見つけることが大切になってきます。
例えばCPUネックとなっている場合の選択肢を考えてみましょう。高負荷の業務をあるLPARから別のLPARに移せないか？別のサーバに移せないか？などの案が考えられます。システム環境全体を管理する場合、資源増強が必ずしも必要という訳ではありません。
8.ベストなI/OはI/Oがないこと
どれだけディスク装置が早くなろうと、CPU速度には勝てません。レスポンス時間の最適化を図る時には、物理I/Oを減らすことを第一に考えましょう。
トランザクションごとに物理I/Oが発生すると、レスポンスタイムはディスク装置やネットワークがどれだけ速いかに依存してきます。もしあなたがI/Oについて深く理解していれば、頻繁にアクセスされ、滅多に変更されないデータはメモリ内に置き、物理I/Oを発生させないようにすることができるでしょう。
物理I/Oを最小化するためにメモリを有効活用する方法を考えましょう。
9.使用しているメトリックと統計を理解する
長い期間パフォーマンス管理に携わっていると、新しいメトリックが次々と出てきます。従来のメトリックの意味が変わる場合もあるかもしれません。あなたが普段使用しているメトリックの意味を明らかにし、ドキュメントに残すようにしましょう。何千という使用可能なメトリックの中で、あなたが本当に理解しないといけないものはそのうちの一部だと思います。ただし、それらについては完全に理解する必要があります。
メトリックを管理することには、統計を理解することも含まれます。標準偏差とは何か？相関関係とは？また、パーセンタイルを理解すると、レスポンス時間やリソース使用要求の数値表現に大変役に立ちます。
過去のCMGの文献も参照してみて下さい。メトリックや統計の利用方法をより効率的に学ぶことができます。
10.コミュニケーション
コミュニケーションによる情報共有で、ビジネスとITの間で強力な連携を取ることができれば、ビジネスの成功をサポートするだけでなく、価値のある架け橋を構築することになります。成功事例を共有し、それをドキュメントに残しましょう。また失敗事例にも同じことが言えます。
コミュニケーションは会話だけではありません。Webレポートやメールで多くの情報コミュニケーションが可能です。自動化することでレポート化の負荷は小さくすることが可能です。
11.常に想定をチェックする
10という数字は区切りがいいのですが、実際には11番目の経験則があります。それは、設定変更時に事前の想定を確認しておくことです。また、その想定をドキュメントに残して下さい。変更事項と事前の想定内容は、実際の設定変更後に大変役に立ってきます。
|
