Like始めまして、IBMテクニカルセールス、Turbonomic担当の中島洋平と申します。こちらには初めての投稿になります。今後、Turbonomicの担当者として皆様のお役に立つ情報を発信していければと思います。はじめに:早速ですが、Turbonomicをお試し頂いたお客様の99%から頂くであろうご質問に「Tubonomicってパフォーマンスの最適化をどんどん提案してくれるが、そもそも何を"最適"と判断しているのか?」というものがあります。いうのが、その根拠になります。パーセンタイルとは...?正直、あまり聞きなれない言葉ですね。(pfa.or.jp)計測値の分布(ばらつき)を小さい数字から大きい数字に並べ変え、パーセント表示することによって、小さい数字から大きな数字に並べ変えた計測値においてどこに位置するのかを測定する単位。計測値として100個ある場合、5パーセンタイルであれば小さい数字から数えて5番目に位置し、50パーセンタイルであれば小さい数字から数えて50番目に位置し、95パーセンタイルであれば小さい方から数えて95番目に位置する。いう事は、↑に記載の通り、取得した統計情報(メトリック)の小さい方から数えて95番目に位置する値が最適な値、として判断される事になります。一つ例を見てみましょう。クラウド上のとある仮想マシンで以下の様なCPU利用率の推移があったとします。このグラフからは29日前に一度90%程度の使用率に達した事がありますが、それ以外については概ね50%以下の利用率に収まっている事が分かります。(例えば、この仮想マシンに修正プログラムを適用した際の突発的なピークだったのかもしれません)この場合、適切なCPUの使用率を90%と判断してしまうと、あまりにも無駄が多い事になります。※もちろんアプリケーションによっては必要なケースもありますが、一般的には無駄なリソースが割り当てられている状況と言えます。(*注1)一旦この数値を小さい方から順番に並べ替えてみます。ここから100等分した場合の95番目に当たる数値がいくつであるか?考えてみます。この場合、小さい方から29個目の値:CPU使用率55%のタイミングが該当します。従い、この環境のCPU利用率の過去1カ月の"95番目のパーセンタイル値"は55%という事になります。これは同時に統計期間全体の95%については、この使用率以下しか利用されていない事になりますので、突発的なピークを除外するという観点では、かなり現実的な数値である事がお分かり頂けるかと思います。この程度のCPU需要を満たすリソースを割り当てる事が、Turbonomic観点でのパフォーマンスの最適化という事になります。(*注2)...では現状の55%分のCPUがあればよいか?いいえ、話はもう少し複雑です。一般的に、CPUにしてもメモリにしてもストレージにしてもネットワークにしても、その上限値(使用率100%)に近づくにつれて、徐々に本来のパフォーマンス(レスポンスタイムなど)に影響が出てくる事は皆さんご認識かと思います。これは以下のようなグラフで表す事が可能で、多くの環境では概ね70%程度までの使用率であれば特に問題の無いレスポンス(緩やかな上昇)で動作しますが、70-80%を超えたあたりから二次曲線的にレスポンスの劣化が見られるようになります。前述の95パーセンタイル値で割り出した最適なCPUの割り当てが、その時点での使用率100%になってしまってはやはりパフォーマンスに影響が出ると考えられます。Utilization)はどこに置くべきか?という議論となりますが、この点、Turbonomicでは、世界中のお客様環境での実績も踏まえ、例えば対象がクラウド上の仮想マシンである場合、そのDefault値を70%としており、この70%に可能な限り近づく様、各種アクションをリアルタイムで繰り返し提案・実行し続ける事になります。https://www.ibm.com/docs/en/tarm/latest?topic=cloud-vm-policies従い、例えば対象の仮想マシンが16vCPU構成であった場合、単純計算では以下の様なロジックが用いられている事となります。減らす・最終的に生成されるアクション:13vCPUを満たす最適なインスタンスタイプに変更まとめ今回は一例として仮想マシンのCPU割り当ての最適化の背景についてご紹介させて頂きましたが、この考え方はCPUだけではなく、Turbonomicのあらゆるパフォーマンスのメトリックの判断に於いて類似したロジックが用いられています。etc...)も含めた情報をリアルタイムに多次元分析する事によって、最適なアクションを提案・実行し続けている、という事になります。10や20程度であれば人手でもどうにかなりそうですが、100以上の対象、ましてやマルチ・ハイブリッドやk8s環境なども入って常時実行し続けるとなると、、、信頼性のあるアクションを提案する事は容易ではない事、ご想像頂けるかと思います。あるべき姿に近づけるプロアクティブなアプローチとなりますので、管理者様の運用負荷を抜本的に軽減する事にも繋がります。なりますが、例えば重要な本番システムなので、より厳しい値(パーセンタイル値を上げたい)といった場合や、逆に、検証環境なのでもっとアグレッシブにリソース割り当てを制限したい(パーセンタイル値を下げたい)といった場合は、運用に合わせて変更頂くことが可能です。期間のDefault値になります。値が存在し、この期間内のメトリックからパーセンタイル値が計算されます。従い、メトリック収集開始後、Defaultでは最短で4時間が経過した後、メトリックを元にしたアクションが生成される事になります。24ポイント)のメトリックが採取され、その95thパーセンタイル値からアクションが生成されます。平岡さんからこのBLOGを紹介して頂きました。Memberに紹介します。ありがとうございました。