今回は実際にサブスクリプションを使って、Azureのコスト最適化を弊社がどのようにやってきたかをご紹介します。ちなみに今回の内容は、
「オンプレからパブリックに移行したら30%コスト削減に成功した!」
「リソースが必要なときに、必要な分だけリソース割り当てた!」
という綺麗な話ではなくて、
「せっかく会社にAzureを使えるよう投資してもらったしと現場で徹底的に使い倒していたら、気がつくとこのままいくと期末まで持たないぞ!サブスクリプションをベースに節約対応してなんとか期末まで延命した。」という泥臭い事例です。;)
2016/1/5追記
本記事執筆時点で未知だったのですが、現在ではアカウントに対して、「コストセンター(CC)」や「部署名」を追加で定義できます。ea.azure.comにエンタープライズ管理者でアクセスすることで請求金額等が閲覧できますが、その際に上記追加定義を使っていると、課金のくくりとして使えるようになっているようです。このあたりをうまく使うことで、もう1階層管理単位を作ることができるようになっているので、より柔軟にコスト管理ができそうです。こちらで試せていませんので、こんな書き方になっていてすいません。(汗;
無尽蔵のコンピューティングリソースありきの現場から要望
Azureのようなパブリッククラウドにはオンプレ環境のようなリソース(CPU、メモリ、ディスクなど)の制限が当然ないわけですが、そうなると現場からは必要に応じて、どんどん利用リクエストを上がってくることが容易に想像できます。
これこれのスペックの仮想マシンをAzure上に立ち上げたいということで、Azure料金計算ツールからひと月にこれくらいかかるというコスト計画は立てることができます。ただ、使った分だけ費用がかかるという現実と料金計算ツールでのざっくり計算結果と現実のコストが異なるということが往々にして起こります。
弊社の場合は主に技術検証、開発用途でAzureやAWS等を利用しておりますが、当初計画範囲外のサービスを利用したり、不要な仮想マシンを落としたり消すことで、当初の想定と実体の差はかなり大きくなりました。
またPaaSサービスは使い方次第で、もはや計画を立てることすら限界があります。弊社ではビジネスで求められるスピード感を重視して、規模が大きくない限りは現場の裁量で解放しています。
サーバは常駐前提で立ち上げっぱなしの場合は、コスト予測と実績がそれほど大きく異なることはないのかもしれませんが、下記のようなことが実際に弊社の現場でも起こりました。
- 立ち上げる必要がないサーバを落とし忘れていた
- 本来は必要ではない過剰なリソースを割り当てていた
- 計画時は必要だったが、後から不要になった
- 急遽計画外のサーバを立ち上げる必要があった
- パフォーマンスが悪いのでリソースを増強した
3~5は現場の感覚ではまだしょうがないかなとも思うのですが、1,2 はプロとしてご紹介するのがお恥ずかしい限りですが、数が増えてくると必ず起こります。
理由は意識していない限り、気づくことができないのです。弊社の場合は、月額費用が確定した後に「なんでこんな増えているんだ?」ということになり、よくよく調べたらそれが原因だったという顛末です。
限られた予算の中で適切にリソース配分するための情報提供と提案は、これからのIT部門に求められる事業部向けサービスファンクションの一つになるのではと考えています。
弊社事例
現場裁量で解放すると当然幾らかかるのかがまったく見えなくなるわけですが、最初は特にしばりなく現場に開放したところ、Azureの月額利用料金は直近1年間で下記のように推移しました。
EAの契約での前払いは、Azure計算ツールをベースにざっくり月額これくらいという形で見積もって契約していましたが、業務利用が増えるにつれどんどん増えていきました。
3月の時点で一気に増えて翌月半分に落ちていますが、これは人為的に落とした結果です。
2月までのトレンドベースでは特に制限をかけていなかったのですが、4月に入った時点でこのままの利用形態でこの後推移すると、契約時の金額には収まらなくなって追加のEA契約購入又は従量課金での精算対応が必要になるということがわかりました。現場的にはなんとかこのまま持たせて、追加費用は避けたいところです。
弊社の場合は、Account(部門)を管理しているアカウントオーナー(部門長)、Subscriptionを管理しているサービス管理者(担当コンサル)に費用を明確に提示し、残り予算をベースにした削減目標を提示した上で、4月中に下記のような具体的な削減策を講じてもらいました。
・不要な環境削除
・止められるシステムは停止(夜間、休日)
・常駐が必要なサーバは、オンプレ環境の空き領域ににリロケート(移設)
このあたりは、第2回で説明しておりました下記のようなSubscription設計がまず前提にあります。
つまり、アカウント、サブスクリプションを環境のオーナーシップをもとにきちっと設計していたからなせる策で、ざるでやっていると目標達成自体が危うかったと思います。
その後、5月はさらに落ちていますが G/W期間中の停止を行う前提で6月の利用想定も加味しながら、ギリギリのラインを狙ってさらに粒度の細かい調整をかけていました。最終的には契約更改タイミングの6月末時点でちょうど3万円オーバーとなり、これだけ従量課金で請求書払いすることでなんとかなりました。
パブリッククラウドを活用した場合の、開発、テスト環境でのコスト最適化の実例として何かの参考になれば幸いです。
長文最後までお読み頂きありがとうございました。
次回は、コスト最適化にあたって利用した管理ツールをご説明します。
- カテゴリ: 技術情報