過去2回ほど、20%~30%程度のサーバ削減をやったことがあって、
その時のメモが出てきたので、考え方とかやったことをザックリまとめてみる。
まず例えば、不要なサーバを削減してインフラコストを月額10万円減らしたらどうなるか。
これは運用コストも解約リスクも無い、恒久的な利益になる。
裏返すと以前は恒久的な損失が発生していたということなんだけど、情報をまとめないとだれも気づかない。
なのでどこまでやるかは状況次第だけど、情報をまとめることは最低限必須だと思う。
ということで、『効率化する』、『安く買う』についてはまた次回にして、
今回は『情報をまとめる』、『ポリシーを決める』、『適切なサーバ台数を維持する』ことについて。
基本的にオンプレ環境を前提として考えます。
情報をまとめる
まずは最初に言ったように、必要な情報をまとめる。
そしてだれでも見れるようにする。
これをしないと自分が思いつく範囲の最適化しか実行されないから非効率。
サーバの一覧を作る
ないなら作る。
ここで大事なのは各サーバの用途をちゃんと確認すること。
これだけでけっこうな台数のサーバを減らせることもある。
もうサービスアウトしてたとか、使う予定だったけど結局使ってないとか、けっこうある・・・
コストを見える化する
月額のファシリティ費用とその内訳、HWの購入費用等をだれにでも見えるようにする。
合わせてサーバあたりの概算月額コストも感覚的に覚えてもらう。
例えばこういう条件であれば、約2万円/月とか。
- 1ラックが20万円/月で、平均20台のサーバを搭載：20/20 = 1
- エッジスイッチが18万円×2で、使用期間は5年とする：18 * 2/(12 * 5 * 20) = 0.03
- サーバ1台の平均購入価格は36万円で、使用期間は3年とする：36/(12 * 3) = 1
状況に応じてその他の費用を含めてカスタマイズする。
使用期間は経理上の償却期間とは別に、実運用実績に近い値を設定する。
リソース使用率を見える化する
最低限、Zabbix、munin、mackerel等の一般的なグラフツールが導入されていれば良し。
プログラマブルに数値のリストが取得できればさらにいい。
こんなことしてたころも。
サーバのリソース使用状況レポートを作る
ポリシーを決める
検討に必要なポリシーを決めて、それを要件に落としこんでいく。
例としてCPUバウンドなAPPサーバの台数とピーク負荷がこうなっているとして、台数の妥当性を検討してみる。
- サーバのCPUコア数は4(1コア使い切ると100%として最大400%)
- 各サービスA、B、CのAPPサーバの台数と過去1年の最大CPU負荷
- サービスA : 5台 合計650%(1台あたり130%)
- サービスB : 4台 合計400%(1台あたり100%)
- サービスC : 2台 合計100%(1台あたり50%)
障害点分割
サービス間でどのコンポーネントは共有し、どのコンポーネントは分離するかを決める。
出来る限り複数サービスで共有化したほうがリソース使用率が高くなる。
ただそうすると障害点まで共有化されて信頼性が低くなるので、バランスを取りつつポリシーを決める。
例)
こんな感じで決める。
- NW回線、コアNW機器(L3SW、FW、LB) : 全サービスで共有
- ラック、エッジSW : 事業部単位で分割
- サーバ : サービス単位で分割。ただし売上がXX以下の場合は3サービスまで共有
- ...
その結果、サービスA、B、Cのサーバをこうまとめることになったとする。
冗長度
各コンポーネントの冗長度を決める。
もちろん冗長度が上がると信頼性は上がるがコストも上がる。
例)
例えばこんな感じに決めたとする。
- 回線/NW：Active/Standby構成で2重化
- サーバ：サービス系はN+1構成、非サービス系は冗長化無し(ただしバックアップから3時間以内に復旧可能)
- 電源：冗長化しない
- HDD：全てRAID10で冗長化
- 予備サーバ：...
- ...
サービスA、B、Cは全てサービス系なのでAPPサーバはN+1構成にする。
単体のリソース使用率上限
ラック電力、NW帯域、サーバCPU等、コンポーネント単体の各種リソースの使用上限値を決める。
例)
CPU使用率は70%を上限とする。
※CPU上限はHT(Hyper-Threading)を使う場合は特に、慎重に決める。実際のサービスで特定サーバの振分けを徐々に増やして検証する、ということができればそれが一番確実。
APPサーバ1台あたりのCPU使用率上限は400 * 0.7 = 280%、となる。
サービスごとの最大の合計リソース使用量
各サービスのある機能に、最大どの程度のリソースが必要かを決める。
例)
過去1年の最大負荷に20%のバッファをのせたものを最大合計リソース使用量と決める。
各サービスのAPPサーバのクラスタで必要な合計CPU使用率はこうなる。
- サービスA : 合計780% (650 * 1.2)
- サービスB : 合計480% (400 * 1.2)
- サービスC : 合計120% (100 * 1.2)
適切な台数に調整し、維持する
ここまで決定すると、
必要なサーバ台数が決まる
今回のAPPサーバの例だと、負荷的に必要な台数はこうなって、
- サービスA : 3台 (780 / 280 = 2.78)
- サービスB,C : 3台 (480*120 / 280 = 2.14)
N+1台構成にするとこうなる。
適切な台数になるように調整作業をする
やっと作業だ！！！
今回の例だと台数が減ったけど、冗長度が足りてなかった場合は増えることもある。
まぁたいてい減るかな。
負荷が上がるとアラートなるけど、負荷が減った時は何も起こらなくて対応が放置されがちだから。
繰り返す
PV増減、アプリ変更、最適化作業やサーバリプレース等によって負荷が変動したら、
また調査、調整して、台数を適切な状態に保つ。
ポリシーも適宜見直していく。
まとめ
というわけでインフラのコストを削減する、ということに関して、まずはその前提となる、
- 情報をまとめる
- ポリシーを決める
- 適切なサーバ台数を維持する
についてでした。
『効率化する』、『安く買う』についても近いうちに書く・・・きっと・・・
