Azureのコストを30%削減した実証済みの5つの戦術

Ltd.

Consider B-Series virtual machines

While platform-as-a-service (PaaS) offerings have been gaining significant ground over the past few years, virtual machines—be it for legacy reasons or due to specific software requirements—still represent a large portion of cloud usage.

クラウドベースのVMは、コスト管理の点で課題があります。通常、実行には最小限のスペックが必要で、定期的に使用量が急増するアイドル状態になりがちですが、電源が入っている限り、全コストが発生し続けます。

2017年9月に、MicrosoftはBシリーズファミリーの仮想マシン、バーストアブル仮想マシンとも呼ばれる仮想マシンを発表しました。 これらのマシンは、常に利用可能である必要があるが、通常はアイドル状態であり、時折使用のピークがあるワークロード向けに特別に設計されています。 B-Series VM は、使用する OS に応じて、同等の D-Series マシンの価格から 15 ～ 55% のコスト削減が可能です。

おすすめの記事。 Azure コスト削減のヒント: 業界のインサイダーによる注意事項、Leigh Ryan 著

では、既存の VM をすべて B シリーズに変換して大きな節約をするべきでしょうか

気をつけてください! すべてのワークロードをやみくもに B-Series に変換できるわけではありません。 コストと CPU 消費量のバランスをとる必要があります。 B-Series には、ベースライン量の CPU パワーが割り当てられています。 使用量がベースラインを下回っている限り、VMはクレジットを蓄積し、ベースラインを上回るCPUを消費するために使用することができます。

ベースラインとクレジットの制限は、各 B-Series VM のサイズによって異なります。 さらに、VM がパワーダウンされるたびに、蓄積されたすべてのクレジットが失われます。

仮想マシンを安全に B-Series に変換できるかどうかを判断するには、Dave Hall 氏の Azure-Burst-Check スクリプトなどのカスタム スクリプトを実行するとよいでしょう。

アイドル状態のリソースを識別して対処する

Azure のおかげで、組織の新しいニーズを満たすために、いつでも新しい環境を瞬時に立ち上げて実行することがかつてなく簡単にできるようになりました。 Fast-forward a few years, however, and you’ll start noticing a buildup of resources in your Azure subscription that are likely racking up a hefty bill. It isn’t always easy to tell which workloads are still being used and which ones can safely be decommissioned.

The best solution would be to go back in time and implement a basic cloud asset governance plan.

簡単に言うと、作成する各リソースについて、次のことを行う必要があるということです:

• タグおよびその他の戦略を使用して、資産の使用方法 (開発、テスト、プロトタイプなど) を分類します。
• リソースの単一の所有者を指定する (通常はリソースを要求した人)
• リソースの有効期限またはチェックアップ日を決定する (そして、必ずそのスケジュールに従い、不要なリソースを速やかに削除する)

これらの情報があれば、特定のリソースがまだ必要かどうかを判断してそれに従って行動することが非常に容易になります。 Antoine Jagueneau 著「How to start and stop your VMs with Azure Automation」

私はコスト管理計画を持っていません。

Azure では、リソースがどの程度のアクティビティを見ているかを測定する、一連の使用統計にアクセスできます。 これらの値は、Azure ポータルから、Azure API にアクセスしてカスタム コードを使用することによって、または専用のコスト管理ソリューションを通して調べることができます。 これらの使用率を調べることで、どの資産が使われなくなったか（あるいは著しく使用されていないか）を特定し、適切な措置を講じることができます。 また、クラウド コスト ガバナンスは反復的なプロセスであることを覚えておいてください。 Azure では、さまざまな要件 (より多くの RAM、より多くの CPU パワー、SSD ドライブ、GPU など) に対応するために多数のオプションを提供していますが、同じ系列のマシンであっても、正しいサイズを選択することが重要です。

お勧めの記事

これを誤ると、マシンがアイドル状態のときに必要以上の料金を支払うことになるか、CPU 使用率が 100% のマシン (あるいはさらに悪いことに、物理 RAM が不足しているために仮想メモリにスワップしている) になってしまうでしょう。

前もって特定のシステムの要件を把握することは必ずしも容易ではないので、念のため必要以上に高く設定したくなることがあります。

これを避けるにはどうしたらよいのでしょうか。

不必要なリソース消費による無駄遣いを避ける最も簡単な方法は、専用のクラウド最適化ツールでテナントを監視し、リソースの権利化、縮小、または削減の機会があるたびに通知することです。

縮小のタイミング

自分の環境がそうであるかもしれないと思ったとき、あわてないでください! 与えられた VM をダウンスケールすべきかどうかを判断する簡単な方法がいくつかあります。

通常、Azure のインスタンス サイズは、各階層で倍増します。S1 は 1 つの CPU コアと 1.75 GB の RAM、S2 は 2 つのコアと 3.5 GB の RAM になります。

どのような場合でも、長期間にわたって両方の使用統計が 50% 未満であることを確認したら、パフォーマンスを妨げることを心配せずに、自信を持ってインスタンスをダウンスケールすることができます。

DTU 使用率は常に 50％未満なのでこのデータベースは安全に低い階層にダウングレードすることができます。

VM のメモリ使用量を確認できない理由

残念ながら、クラシックまたはマネージド仮想マシンのメモリ パーセントのグラフをすぐに取得することはできません。 この情報にアクセスするには、ゲスト レベルのモニタリングを有効にして、適切なパフォーマンス カウンターをチェックする必要があります。 特にチェックする必要があるのは、MemoryCommitted Bytes です。

未使用ディスクの検出と削除

しばらく Azure を使用していると、かなりの数の仮想マシンを作成および削除してきたことでしょう。 しかし、請求額は増え続けており、その理由はよくわかりません。 特に、削除された仮想マシンのディスクがアカウントに残っていて、毎月のように費用がかかっています。 これは、新しいARMの種類ではなく、従来の仮想マシンを使用している場合は、さらに可能性が高くなります。 その理由は簡単だ。 Azureは、仮想マシンを削除しても、ディスクを系統的に削除しない。 これは、偶発的なデータ損失から保護するためですが、注意しないと、不要になったディスクの代金を払い続けることになります。

この問題は、Azure ポータルから解決できます。 The procedure will be a bit different depending on whether you’re dealing with managed disks or classic disks.

Managed disks

For managed disks, go to the Azure portal, search for Disks in the search bar, and select “Disks”.

This will display all your managed disks. If the Owner column is empty, it means that the disk is not currently attached to anything and you can probably delete it.

To delete the disk, select the row, go to Overview and click Delete in the top bar.

Classic disks

For classic disks, go to the Azure portal, click in the Search bar up top and search for Disks. Select “Disks (classic)”.

You’ll see all of your disks and a column indicating which VM each disk is currently attached to. If you see a disk that isn’t attached to a VM, you can probably delete it safely.

Deleting classic disks is a bit of a process, as the underlying file (the VHD), which is stored in a storage account, will still be there until you manually remove it. Here are the steps:

1. Click on the classic disk and take note of its Storage account and Media link information

2. Click Delete and confirm

3. Azure の検索バーを使用して、手順 1 で指定したストレージ アカウントを検索し、プロパティ ペインを開きます

4. Blobs をクリックし、正しいストレージ コンテナのある行を選択します

5. 正しいファイル名のボックスをチェックし、上部メニューの [削除] をクリックします

Forgotten VHD

これらのすべての手順に従って未装着ディスクを特定したとしてもです。 は、クラシックストレージに放置されたまま忘れ去られている可能性があります。 通常、Azureポータルは、”vhds “コンテナを作成し、ストレージアカウントにそれらを配置します。 それらを見つけるには、各クラシックストレージのアカウントで、Blobsの下にあるvhdsコンテナを確認します。 コンテナの中で、各ファイルの Lease state カラムを確認する。

弾性プール データベースの活用

おそらく、以前にオンプレミスまたはプライベート データ センターでホストされていたワークロードを Azure に移動することにより、クラウド移行プロジェクトを開始したと思われます。 これらのワークロードの多くは、おそらく SQL Server データベースを使用しており、クラウドと NoSQL ムーブメントの台頭以前は、ほとんどのソフトウェア プロジェクトのバックボーンであった傾向があります。

以前は、さまざまなプロジェクトや顧客のために、何十、何百ものデータベースをホストするために単一のデータベース サーバーを使用していたかもしれませんが、これらを個別の Azure SQL データベースに分割するコストは、予想よりはるかに高くなる可能性があります。 これは、Azureのデータベースの仕組みに起因するものです。 オンプレミスでは、1台のサーバーの限られたリソースを複数のデータベースで共有するのが一般的でした。 Azure SQLでは、各データベースが予約された量のリソースを持ち、データベースがアイドル状態であっても、その分のリソースが課金されます。 このモデルは、複数のデータベースが一貫して予測可能な使用率で稼働している場合に最適です。 しかし、多数のデータベースがあり、その利用パターンにばらつきがある場合は、この価格設定は魅力的ではありません。

• より大きくより高価なデータベース層を使用して、データベースのピーク使用量を処理する
• ピーク時のパフォーマンスを犠牲にして、低層を使用してコストを削減する

データベース間でリソースを共有するために、Azure の初期の採用者は、SQL Server をインストールした独自の仮想マシンを作成および保守して、オンプレまたはプライベート データセンターで実行していた状況を本質的に再現することを余儀なくされました。

• 内蔵の高可用性 (レプリケーションを構成する必要はありません)
• アクティブなジオ レプリケーション
• ポイント イン タイム復元

これらの機能を独自に展開することは容易ではなく、維持することも困難です。 マネージド インスタンス

Azure は、マネージド インスタンスと呼ばれる、より新しい層の SQL データベース サービスを提供しています。 マネージドインスタンスでは、Azure SQLシングルデータベースサービスに搭載されているすべての機能を利用することはできませんが、オペレーティングシステムやSQL Serverのインストールを管理する必要はありません。 基本的に、構成とメンテナンスがほぼ管理された仮想マシンを手に入れることになります。

ベスト: SQL エラスティック プール

しかし、この共通のシナリオを扱うための別のオプションが Azure に存在します。 それは、SQL エラスティック プールです。 SQL エラスティック プールは、1 つのデータベースに対して一定のリソースを予約するのではなく、いくつかのリソースを予約して、何百ものデータベースで共有できるようにするものです。 このモデルは、Azure SQLのすべての利点を備えており、複数のデータベースでの急激な使用パターンを適切に処理することができます。 エラスティック プールは非常に人気があり、マルチテナント アプリケーションの理想的なオプションです。

しかし、エラスティック プールの使用には慎重を期す必要があります。 プール内の他のデータベースよりも使用量が大幅に多いデータベースが1つ以上ある場合、使用量のピークに対応するために、より高価なエラスティック プールの階層を購入しなければならなくなる可能性があります。 場合によっては、使用率の高いデータベースを単一のデータベースオファリングに分割し（プールから取り出し）、残りの使用率の低いデータベースにはより小さなレベルのエラスティックプールを購入する方がコスト効率に優れていることがあります。 経験則としては、データベースのDTU使用量を見るとよいでしょう。単一のデータベースが常にエラスティックプールのDTUの40%以上を使用している場合、そのデータベースをプールから分離し、プールをより安価なティアにスケールダウンすれば、コストを削減できる可能性があります。

いつものように、データベースの使用パターンを特定するには、Azure ポータルを使用します。

Time to take action and start saving on Azure

By acting on the five areas outlined in this guide, our team managed to shrink our Azure spend by 30%.

Can you do better?