現在、Microsoft Azureの環境を使用した製品の開発を行っています。
基本的にはローカルで開発を行うのですが、Azureの環境を実際に使って動作確認をしたいケースが存在するため、開発用にAzure環境を作成しています。
複数チームが同時に動いていたり、試験等で同じチームでも複数の環境が必要になったりするので、開発環境では何セットか本番環境と同じリソースを作成しています。
ただ、過剰なスペックや必要のないリソースにより、不要なコストをかけてしまっていることがありました。
開発環境では、本番環境と異なり、必要なときに必要な分のスペックで動作が確認できれば十分です。
基本的には夜間や休日は使用しませんし、ひとつの環境を同時に大人数で使用することも少ないため、基本は最低限のスペックで問題ありません。
そのため、コスト削減の対応として不要な時には自動でリソースを停止したり、スペックを下げたりするスクリプトを実行しています。
こうしたコスト削減の取り組みについて今回は、以下の1と2をご紹介いたします。
目次
- Azure Automationについて
- アプリケーションゲートウェイの自動停止
- VMの自動停止
- App Serviceの自動停止・スペックダウン
- SQL DBの自動停止・スペックダウン
Azure Automationについて
自動化のスクリプトは、Azure Portal上からAzure Automationというサービスを使って実施しています。
Azure Automationは、プロセスの自動化や構成管理、更新管理等の機能を提供するサービスです。
Azure AutomationにはRunbookと呼ばれるものが存在し、Runbookでスクリプトを記載したり、GUIでワークフローを編集したりして、それを実行させることでタスクの自動化を実現できます。 今回紹介するリソースの停止では、RunbookにてPowerShellで停止用のスクリプトを作成し、それを指定した日時に実行させています。
アプリケーションゲートウェイの自動停止
最初に紹介するのは、アプリケーションゲートウェイの自動停止です。
アプリケーションゲートウェイは、主にURLからリソースへのアクセスを振り分けるルーティングを行います。
アプリケーションゲートウェイでは、
- 使用した時間
- 送信したデータ量
に応じて料金が発生します。
動作確認や試験を行わない時には停止しておくことで、動いている時間だけの料金に抑えることができます。
事前準備
開発環境では、アプリケーションゲートウェイに関するRunbookをまとめたAutomationアカウントを作成しており、対象のアプリケーションゲートウェイごとに、共同作成者のロールを割り当てています。
ここではアプリケーションゲートウェイの開始と終了をするRunbookをAutomationアカウントに登録しています。
終了するRunbookでは、引数でリソースグループとアプリケーションゲートウェイ名を受け取った後、Azureへの認証と接続を行い、Stop-AzApplicationGatewayでアプリケーションゲートウェイの停止を行っています。
運用方法
対象のAutomationアカウントの、[スケジュール]で、自動停止する日時を決めることができます。
基本的には、自動停止のスクリプトが毎日夜の23時に動作するように設定しています。
アプリケーションゲートウェイが停止されたかどうかは、対象のアクティビティログやプロパティから確認できます。
戻し忘れの工夫
長期間、動かしたまま試験したいケース等でアプリケーションゲートウェイが止まると困るときは、元々[有効]の欄を[いいえ]に変更していたのですが、戻し忘れによって不要な期間も動いたままでコストがかかるケースがありました。
戻し忘れを防ぐために、現在は説明を記載した上で「開始時」を止まっても良い日時に変更する運用にしています。
おまけ:アプリケーションゲートウェイの開始
停止は夜に自動で行われますが、「必要な時に必要な分だけ」ということで、開始は基本的には手動です。
同じAutomation アカウントのRunbookに、Start-Agwのスクリプトもあるので、「開始」してパラメーターを指定することで対象のagwが開始できます。
必ず毎日使うことがわかっている環境だけ、自動で開始するようになっています。
また、試験期間等で頻繁に使用することがわかっている場合は、以下のように有効期限を決めて、無効にするような運用にしています。
これによって、使わないのにずっと動き続けてコストがかかることがないようにしています。
以上のような取り組みで、アプリケーションゲートウェイのコストを最低限に抑えることができています。
他にもVMやApp Service、SQL DBの停止やスペックダウンも同様に自動化しており、こちらについても投稿する予定です。