戸締り確認をして年末年始をくつろいで過ごそう！～ Azure課金の確認ポイント（初心者向け）～

工藤匡浩 - Microsoft Top Partner Engineer Award

はじめに

こんにちは！NRIの工藤です。本投稿は Microsoft Top Partner Engineer's Advent Calendar の18日目の記事になります。

japan.zdnet.com

年末年始は外に出る機会も増え楽しみも多いですが、外出中に「あれ？家の鍵をきちんとかけたかな・・・？」と頭をよぎってしまうと、もう気になり始めてソワソワしてしまい楽しく過ごせなくなりますよね。

今回は、Microsoft Azure（Azure）の戸締りを確認し休み明けに「想定外の課金が発生していた・・・！」とならずに年末年始を安心して過ごせるよういくつかポイントをご紹介したいと思います。

なお、読者はAzureにちょっと使い慣れてきた初心者を想定しており、今後より柔軟にAzureを使いこなせるようなヒントになればと考えて記載しています。

開発環境を想定しており長期の非稼働日がある前提で記載をしますが、それぞれの環境ではそれぞれの事情が多数あると思いますので、皆様の実態に合わせて読み替えていただければ幸いです。

現状の把握をする

まずは、どこにどれだけ課金が発生しているか確認してみます。
Microsoft Cost Managementから「コスト分析」->「累計コスト」と選び、表示される円グラフを確認します。（カレンダから指定の期間を出すこともできます。）

利用料が大きいものから取り組むと効果が大きいので、この円グラフの結果から取り組むべき順序を決めていきます。円グラフはドリルダウンしたり、メニューから一覧を出力したりすることができるので、合わせて余計なリソースが存在していないかも確認していきましょう。

利用料の割合をある程度把握できたら、これからは検証・開発用に一時的に利用を増やしていないかを確認していくことになるのですが、コストがかかる領域は以下のどこかになることが多いので、ここからは領域ごとに削減できるポイントをお伝えします。

・仮想マシン

・コンピューティング系PaaS

・ストレージ

・データベース

・ネットワーク

仮想マシン

仮想マシンにおいて課金関連で確認すべき点は大きく２つです。

・止められる仮想マシンが無いか

・サイズを小さくできる仮想マシンは無いか

仮想マシンは起動していると課金対象となるため、休み中に稼働が不要な仮想マシンは停止するようにしましょう。該当の仮想マシンのメニューから「停止」を押すことで止めることができます。

なお、休日直前の営業日の最後に慌てて止めると、実は止めてはいけないマシンだった・・・などトラブルを生み、悲しい休日対応になってしまう可能性があるので余裕をもって実施することをお勧めします。

止められる仮想マシンの検討が終わったら、次に、サイズ変更できる仮想マシンが無いかを探しましょう。例えば私が関わっているシステムでは普段はDシリーズを使い、稼働が無い場合はBsシリーズを選びスペックを下げています。
ただし、仮想マシンに乗せているソフトウェア、アプリケーション次第ではCPUをむやみに変更できない場合や、メモリを減らすことができないものもあるため確認の上実施してください。

Virtual Machines の価格についてはこちら Virtual Machines シリーズ | Microsoft Azure

上記2点が、仮想マシン自体の課金で真っ先に確認した方が良い点です。

これ以外に注意すべき点としては、仮想マシン内で稼働し続けているアプリケーションがそのまま放置してよいものなのかは念のためチェックしておきましょう。後ほどネットワークの項目でも出てきますが、特に負荷ツールが稼働しっぱなしになっていると宛先次第ではネットワークコストが発生し続けることになります。

コンピューティング系PaaS

PaaSには色々なサービスがあり個別に考慮すべき点も出てくるのですが、まずは課金体系を見ましょう。何をすると課金を下げられるのかを見て、ご自身の環境でそれが可能なのかを確認していくことになります。（仮想マシンと違い、停止しても課金が止まらないものがほとんどです。）

大抵のサービスにおいて有効なのはインスタンス数の変更です。PaaSはスケールアウト構成になっているものが多く、普段はインスタンス数が2以上で検証・開発をしていることがあると思います。お休み中に利用予定が無ければインスタンス数を下げる課金を抑えることが可能です。（オートスケールの設定が入れられるサービスは設定を入れてAzureにお任せするのも手です。）

図はApp Serviceプランのインスタンス数の変更画面です。メニューの「スケールアウト」からインスタンス数を変更します。

他に有効なことは、仮想マシンと同様にサイズ・SKU（Stock keeping Unit）を下げることです。ただし、仮想マシンの時と比べて特に注意が必要なのは、サイズ・SKUの差による設定の差異の有無です。特定のSKUにのみ可能な設定を施している状態でSKUを下げてしまうと設定が無効化されてしまうケースもあり環境が変わってしまう恐れがあります。そのため事前にSKUを変えても問題が無いリソースなのかを確認したうえで変更を行いましょう。

図はApp Serviceプランの変更画面です。メニューの「スケールアップ」から変えたいプランに変更します。

ストレージ

ストレージはコンピューティング系PaaSと同じく、課金体系を確認することから始めましょう。

単純にデータを置いている分だけ課金されるBlobであれば不要なデータ（テストデータ、一時的な検証データなど）を消すことで課金を抑えることができます。
一方で、Managed Disk、Azure Premium Filesなど先に利用サイズを指定しているものは、その指定分課金が発生するためデータを消しても課金は減りません。

ただし、データの要否の検討やDiskサイズの変更は労力がかかるので、Cost Managementで一番初めに見た通り、本当にストレージ領域についてコストを抑える必要があるのかを見極めたうえで進める方が良いと思います。（他にアプリケーションやデータ連携、追加のバックアップをしない限り、休日中にストレージ利用が急に増えて、休み明けにびっくりするということは少ないのではないかなと思います。）

データベース

データベースも課金体系が様々なものがあるため、課金体系を確認し対応できることが無いかを見ていく形になります。

データベースもサイズ・SKUを選ぶことができるものが多いため、スケールダウンさせることで課金を抑えることができます。注意すべき点としては、Azure SQL Database（SQL Database）では仮想コア数によって最大容量が変わるため、格納しているデータの容量次第では変更ができない点があります。　

図はSQL Database、Azure Synapse Analytics（Synapse Analytics）でのスケール変更の画面です。

またデータベースでも停止することで課金を止められるものがあります。例えば、 Synapse Analyticsの専用SQLプールでは一時停止することで課金を止めることができます。

ネットワーク

ネットワークも、ストレージ同様に環境次第では取り組む必要が無い可能性があります。Cost Managementでネットワークの課金の占める量を確認したうえで取り組むかを決めましょう。

取り組むべきとなった場合、確認すべきはAzureから外に出ていく通信、リージョン間（大陸間）の通信が抑えられるかを確認しましょう。
仮想マシンのところでも触れましたが負荷ツールが動きっぱなしになっていないか、稼働する必要が無いアプリケーションが稼働し続けてAzure外へ通信され続けることがないかが確認した方が良いポイントです。

その他（ログ関連）

意外と課金されているものとしてログ関連があります。安全や身を守るために取得しているのもあるため一概にログ取得を止めるというのは難しいものもあるので検討が必要となりますが、例えば Log Analyticsの日次上限を定めておくことで、仮に休み中に突発的なログ発生が起きたとしても課金が青天井になることを防ぐことができます。