Azure Serverless のパフォーマンスとコストを最適化

Global Azure 2024 in Fukuoka

Tatsuro Shibamura @shibayan

🆔 私について

芝村 達郎 @shibayan

🆘 Azure が 2024 年 4 月から約 20% 値上げ 🆘

😱 20% 値上げの衝撃は思ったより大きい 😱

個人で使ってる Microsoft 365 Personal も値上げされてた

💰 コストは下げたい、しかし節約はしたくない 💰

必要な場面ではちゃんとコストをかけるのが重要

🤔 どのような手順でコストを最適化するとよいのか 🤔

失敗例：いきなりアプリケーションの構成を変える

🏆 コスト最適化には正しい手順がある

1⃣ 使われていない、不要なリソースを特定し削除する
2⃣ リソースの設定を変更し、パフォーマンスを改善する
3⃣ 過剰に割り当てられているリソースを適切なサイズに変更、集約する
4⃣ アプリケーションを改善する
5⃣ コンピューティングのリザーブドインスタンスを購入する
6⃣ アーキテクチャレベルから再設計する

📝 Azure Serverless のリソース単価は割高な設定

  • 素の VM と比べると機能が多く、付加価値が乗っている
  • 内部では複数のサービスが使われているのでその分のコストが乗る
    • 例: App Service は VMSS x 2 / SQL DB / Storage / File Server など
  • 上手く利用すると管理・運用コストは劇的に下がる
    • 一番高額な人間のコストを下げられる
  • 単価が高いからと言って PaaS / Serverless を避けるのは間違っている

1⃣ 不要なリソースの特定と削除

  • 意外に検証用のリソースが大量に残っているケースが多い
    • 各々が作りっぱなしで放置されたリソースグループ
  • オーナーや作成した経緯が不明なリソースも多い
    • 孤立してしまった App Service Plan などが代表例
    • 環境ごとにサブスクリプションを分けると把握しやすい
  • Cost Analysis を利用すると特定が簡単

📝 サブスクリプションを環境ごとに分けて運用

  • 検証・開発・本番の環境向けにサブスクリプションを用意する
    • RBAC を使ったアクセス制限、コストの把握がしやすい
  • 開発向けでは Dev / Test サブスクリプションを使うことも検討したい
    • コンピューティング系リソースのコストが大幅に割り引かれる
  • EA 契約の場合はやりやすい、はず

✅ リソースの定期的な棚卸は重要、運用変更も検討 ✅

不要なリソースの削除だけで 20% 削減を達成することも

2⃣ リソースの設定変更でパフォーマンスを改善

  • App Service / Azure Functions
    • Session Affinity を無効化する
    • HTTP/2 の有効化を検討する
    • 可能な場合は Linux の App Service Plan を利用する
  • Cosmos DB
    • Burst Capacity を有効化する
    • Dynamic Scaling Per Region and Per Partition の有効化を検討する
  • Front Door
    • キャッシュを有効化する
    • HTTP 圧縮を有効化する

📝 PaaS / Serverless は設定が多い

  • 提供する機能が多いので、その分だけ設定値も多くなっている
    • 適切な設定になっていないことも多々ある
    • 設定値が多いので IaC の導入が必須
  • アップデートで随時パフォーマンス、コスト最適化に役立つ機能が追加
    • キャッチアップが重要になってくる
    • 公式のアナウンス、ブログ（ブチザッキなど）を参照する

✅ 設定の変更だけで改善するものは確実に利用する ✅

特に Cosmos DB については忘れずに有効化しておきたい

3⃣ リソースの適切なサイジングを行う

  • 漠然とした不安から過剰なリソースを割り当ててしまうケースが多い
    • 1 つの App Service Plan に 1 つだけ Web App / Azure Functions を載せる
    • Cosmos DB の RU 設定を多めにプロビジョニングする
    • インスタンス数、サイズを過剰に割り当ててしまう。など
  • Azure Monitor を利用して、過剰にリソースを割り当てていないか確認
    • PaaS / Serverless はスケーリングが自由
    • オートスケールを活用する

📝 Azure でやってしまいがちな構成

  • App Service / Azure Functions
    • App Service Plan を数多く作ってしまっている
    • 古い SKU を利用し続けている
    • スケールアップとスケールアウトのどちらが適切かを見誤る
  • Cosmos DB
    • Database Provisioned Throughput を使っていない
    • Provisioned Throughput で大きな RU を割り当てている
  • Front Door (Standard / Premium)
    • Endpoint を使わずに Front Door をたくさん作っている

📝 Azure でやってしまいがちな構成（改善策）

  • App Service / Azure Functions
    • スケールによっては App Service Plan の集約を検討する
    • 本番では Premium V3 (P0v3)、開発・検証では Basic の利用を検討する
    • コア数を増やすより、インスタンス数を増やした方が良いケースもある
  • Cosmos DB
    • 25 コンテナーまでは RU を共有できる
    • 一定のリクエストがある場合以外はオートスケールの利用を検討する
  • Front Door (Standard / Premium)
    • Endpoint は複数作っても課金されないためお得

✅ Azure の特徴を生かして柔軟なリソース割り当て ✅

デプロイの早いサービスを使っていれば間違いない

4⃣ アプリケーションのコードを改善する

  • 最新のランタイム、フレームワークを利用するように書き換える
    • 特に .NET へのアップデートは効果的
    • コンピューティング系のコア数を大きく減らせる可能性
  • Azure SDK も最新バージョンを使うようにする
    • 信頼性とパフォーマンス改善のアップデートが継続的に行われている
    • 最新の PaaS / Serverless 機能を使うために必須なことも

📝 APM を使ってパフォーマンスを継続的に改善する

  • アプリケーション実装に問題があれば Azure のコストは上がる
    • アプリケーションのパフォーマンス改善はコスト削減とイコール
  • Application Insights を有効化して、コード内のボトルネックを特定し改善する
    • 本番環境では確実に有効化しておきたい
  • 非効率なクエリ実行や、過剰な外部依存関係の呼び出しが発生していることも
    • Application Insights を使うと可視化される

✅ アプリケーション側のチューニングから逃げない ✅

ランタイム、フレームワークのアップデートは特に逃げないようにする

5⃣ リザーブドインスタンスを購入する（最終段階）

  • 適切なリソースが確定しないとリザーブドインスタンスを買いにくい
    • 余計な分まで購入するのは無駄になる（返金は出来るが…）
    • 常に使われるリソース分だけを購入して、超える分はオートスケールで対応
  • 一通りの最適化をやり切った後に購入するのを推奨
    • 手っ取り早いのでコストカットの観点では選び勝ち
  • Azure Storage のような容量に対しては早めに購入する価値がある

📝 リザーブドインスタンスの対象となるリソース

  • App Service (Web Apps / Azure Functions)
    • Premium V3 / Isolated V2 (ASE) のみ対象
  • Cosmos DB
    • Provisioned Throughtput が対象
    • ストレージサイズは対象外
  • Azure Storage
    • ストレージ容量が対象

✅ 早いリザーブドインスタンス購入は問題の先送り ✅

コストを正確に把握して最適化した後に購入する

6⃣ アーキテクチャレベルから再設計する

  • 現在のアーキテクチャでは最適化の限界にぶつかることがある
    • RDB や偽 PaaS と言っても良いサービスを多用した構成
    • Azure に最適化されておらず、オンプレのような構成と言える
  • Azure のサービスに最適化しないとコスト効率が下がる
    • 要件をまとめて、アーキテクチャから再設計する
  • オンプレと同じ使い方をすると高くなるのは当然

✅ Lift and Shift は幻想、Azure に特化した設計を ✅

仮想マシンを売りたい、使いたい人のセールストークに騙されてはいけない

🏆 再掲 : コスト最適化には正しい手順がある

1⃣ 使われていない、不要なリソースを特定し削除する
2⃣ リソースの設定を変更し、パフォーマンスを改善する
3⃣ 過剰に割り当てられているリソースを適切なサイズに変更、集約する
4⃣ アプリケーションコードを改善する
5⃣ コンピューティングのリザーブドインスタンスを購入する
6⃣ アーキテクチャレベルから再設計する

ご清聴ありがとうございました