先月（2015年6月）ついにAzure課金APIが公開されましたが、早速弊社のコンサルタントが実装していましたのでご紹介させて頂きます。 Azure Billing API(課金API)をPowerShellから試してみた （YOMON8.NET）
弊社はアプリケーションライフサイクル管理（ALM）の一環で運用ダッシュボードの実装を手がけておりますが、パブリッククラウドありきの運用管理ダッシュボードKPI策定において課金データは必須要件であり、Azureでは今までなかったこともあってこれが出るのを待ち望んでいました。
本記事では「これからどういう風に弊社のシステム運用に乗せていこうかと考えているか」を弊社のプロトタイプをお見せしながらご説明したいと思います。
弊社の課題
先の記事（第3回 EA Azureサブスクリプション設計：弊社のコスト最適化事例）でもご紹介しておりましたが、下記のような運用における課題がありました。
- 立ち上げる必要がないサーバを落とし忘れていた
- 本来は必要ではない過剰なリソースを割り当てていた
- 計画時は必要だったが、後から不要になった
- 急遽計画外のサーバを立ち上げる必要があった
- パフォーマンスが悪いのでリソースを増強した
3～5は現場の感覚ではまだしょうがないかなとも思うのですが、1,2 はプロとしてご紹介するのがお恥ずかしい限りですが、数が増えてくると必ず起こります。理由は意識していない限り、気づくことができないのです。弊社の場合は、月額費用が確定した後に「なんでこんな増えているんだ？」ということになり、よくよく調べたらそれが原因だったという顛末です。
ということで、弊社としては1と2を何とかしたいのです。
弊社内ではパブリッククラウド上に結構な規模のハイブリッドクラウドのデモ検証環境があり、その中にはSystem CenterやSAP Solution Managerが運用管理システムとして稼働しています。1.の落とし忘れが発覚したシステムについてはAzure AutomationやSCO（System Center Orchestrator）を使って起動停止処理を自動化していますが、それでも数が多くなると設定を一時的に解除した後にの再設定のし忘れなどで漏れがてしまいます。
リソースが無尽蔵にあるため、環境面で節約するという感覚がどうしても薄れますし、数が多くなるとこの環境が「いるのか、いらないのか」、「使っているのか、使っていないのか」の判断が当事者がすぐにつきかねない状況になります。これをSCOMの監視機能とAzure課金APIを使って、Azure上のシステム稼働状況とコスト感をもっと分り易くしてかつ何らかの気づきを与える仕組みを構築したいと思っています。
弊社プロトタイプ画面（画像をクリックすると大きくなります。）
最初にレポートしたい「月」を指定するのですが、上記の画面からは割愛しています。大きく3つの表がありますが、青色の上の表がSCOM標準機能で取ってきた各仮想マシン毎のCPU利用率で、青色の下の表がAzure課金APIを使ってAzure課金データを動的にロードして表示させたものです。
Groupという括りですが、正しくはAzure用語で「クラウドサービス」単位で引っ張ってきています。「クラウドサービス」はAzureのPaaSをお使いの方であればご存じかと思いますが、IaaSメインでお使いだとあまり目にしないかもしれません。仮想マシンを作るときにDNSのところにこの名称が付いたりするのですが、ここでは用途別のひとつの塊りという理解であえて流しておきます。
今回クラウドサービス単位で課金データを取得しているのは、現時点で公開されている課金APIはPreview版のために情報の粒度や取得できる情報が限定されているためです。近々Updateがされるようなのでそれが出るのを弊社も待ち望んでいますが、まずは現状の課金APIの仕様でどこまで出せるかの雰囲気はお伝えしたいと思います。（最新のEAの利用量レポートをみると、Tags、Department Name、Cost Centerといった運用で使いたい情報も付与されているのですが、設定はできるものの取ってこれませんでした。
プロト画面1：
Azure課金APIでは、日単位（Daily）、時間単位（Hourly）で取得することができますが、まずは日単位で各クラウドサービス毎のCPU利用率と仮想マシンの費用を明示しています。下記の画面では7月5～7日の各クラウドサービス毎の平均CPU利用率と仮想マシンの課金情報です。SCOM標準の機能を使って各仮想マシン状況の稼働履歴がSCOMサーバ内にデータが格納されていますので、指定した条件をもとにAzureから動的に課金情報を取得したデータと内部結合させて、最終的にSCOM標準のレポートサービスを使って表示させています。
プロト画面2：
7月5日の1時間毎の各クラウドサービス毎の平均CPU利用率と課金情報を付き合わせています。ここでは、Azure上から情報を時間単位（Hourly）で動的に取得しています。
プロト画面3：
7月5日の1時間毎の仮想マシン毎の平均CPU利用率の課金情報を付き合わせています。
ここまでくると、ようやくサーバ（仮想マシン）を意識することができますので、後はSCOM標準レポート機能はかなりリッチなので、見た目の改善をするとともに、閾値アラートを組み合わせることで現場での気づきとかも与えられそうです。
雰囲気はご理解いただけたでしょうか。我々にとっては、各サーバ（仮想マシン）単位で課金情報が纏められれば後はなんとでもなりそうなので、現時点の課金APIを単純にコールするだけで、それが実現できたのは良かったと思っています。
長文最後までお読み頂きありがとうございました。
