久々に社内向けに勉強会を行いました。
既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。
内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。
発表資料
作りやすくて頼りになるので、
もう、赤さんはテンプレでいいかな、とも思い始めました。
補足
勉強会をするに至った理由
いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて
総合的な知識を得ようとする環境・努力をして欲しいところですが、
意外とコーディング～デプロイまでしかできないエンジニアが多い（らしい）です。
この辺を担当するのがインフラ部署であり、全体を観る、という組織構成もアリですが、
状態変化に対して最も適切な判断をできるのは製作者なので、
自分で作ったモノがどういう環境で動作していて、
サービスの負荷性質はこうで、現状のサーバ負荷がこうで、アラート具合、バックアップに至るまで
ちゃんと自ら手がけるようになってほしいな、という願いを込めてみました。
サーバの増減をする際の政治
サーバを何台増やそう・減らそうという判断は現状の数字を見ればできるのですが、その後にさらに各方面に確認をとりつつ最終判断をすることになります。
各方面とは、
サービスが盛り上がる傾向にあるのか、縮退の方針にあるのか、
数日後にイベントを打つ計画があるのか、どの程度を予定しているのか、
WEB/APサーバの増減は簡単だけど、
データベースの拡張（分割）・縮小（統合）においては運用上、可能な状態にあるのか、
サーバの在庫はあるのか、準備期間と台数についての予定はどのような状態か、
そもそも社内の人員は足りてるのか、他の計画と被っていないか。
といったことを踏まえて、台数と実行計画を立てることになります。
my.cnf
ウチの my.cnf は、私がそれなりにコメントや計算式を書いて整理したものを、サーバスペックに応じて自動編集して設置しています。これは資料には載せなかったので社内の人はサーバで見て、調べてくださいね！
そういえば、my.cnf を公開しようぜ みたいな流れが数ヶ月前にあった気がしますが、
sysctl.conf とか fstab とか秘伝のタレって思ったより少ないなーとか。
結局公開せずにごにょごにょ・・・
iowait
だいぶ適当に感覚値で話したのでご容赦をば。数値が大きかったら、増減の前に根本から解決する施策をとってね！ということです。
削減計画の資料
これは完全に台数や金額を記載した表だったので公開しませんが、一時期サーバ台数が多すぎに感じて主要サービスをまとめて確認しました。
これらの項目をBEFOREとして、CPUやIOPSを見て台数を減らしたAFTERを作成しました。
例えば、
BEFORE
AFTER
のようにキャパが半分を割らないよう、かつ比較的優し目にした台数にゴリゴリ変更していき、結果として通信費が、月額300万が100万に減らせますよーみたいな表を作成し、実際に削減もしていきました。
自社管理のIDCとクラウドの違いでわかりやすいところに、資産管理・イニシャルコスト・拡張性と引き換えに、ランニングコストが高くなる、というものがあります。
ここで何気に忘れやすいのが、クラウドは縮小性にも長けているという部分で、
盛り上がったら安定のためにジャブジャブ突っ込めばいいけど、
過疎ったら利益のためにゴリゴリ減らす、というのが大事です。
（増減を自動でやってくれないクラウドの方が多いので、自前で何かやれればいいのですが・・・）
エンジニア全員が、アプリケーション作成・サーバ負荷・通信費といったこと全部を考える必要はもちろんありませんが、触りの部分だけでも認識しておくと会社全体としてのサービス運用が良質になるはずですので、少しずつそういう風土にしていきたいところです。
