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

Azure Serverless のパフォーマンスとコストを最適化 Global Azure 2024 in Fukuoka Tatsuro
Shibamura @shibayan

私について芝村達郎 @shibayan ZEN Architects Distinguished Engineer Microsoft MVP
for Microsoft Azure Microsoft Top Partner Engineer Award Blog : https://blog.shibayan.jp GitHub : https://github.com/shibayan

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

20% 値上げの衝撃は思ったより大きい個人で使ってる Microsoft 365 Personal も値上げされてた

コストは下げたい、しかし節約はしたくない必要な場面ではちゃんとコストをかけるのが重要

どのような手順でコストを最適化するとよいのか失敗例：いきなりアプリケーションの構成を変える

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

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

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

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

リソースの定期的な棚卸は重要、運用変更も検討不要なリソースの削除だけで 20% 削減を達成することも

リソースの設定変更でパフォーマンスを改善 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 については忘れずに有効化しておきたい

リソースの適切なサイジングを行う漠然とした不安から過剰なリソースを割り当ててしまうケースが多い 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 の特徴を生かして柔軟なリソース割り当てデプロイの早いサービスを使っていれば間違いない

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

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

アプリケーション側のチューニングから逃げないランタイム、フレームワークのアップデートは特に逃げないようにする

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

リザーブドインスタンスの対象となるリソース App Service (Web Apps / Azure Functions) Premium V3
/ Isolated V2 (ASE) のみ対象 Cosmos DB Provisioned Throughtput が対象ストレージサイズは対象外 Azure Storage ストレージ容量が対象

早いリザーブドインスタンス購入は問題の先送りコストを正確に把握して最適化した後に購入する

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

Lift and Shift は幻想、Azure に特化した設計を仮想マシンを売りたい、使いたい人のセールストークに騙されてはいけない

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

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

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

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

Tatsuro Shibamura PRO

More Decks by Tatsuro Shibamura

Other Decks in Technology

Featured

Transcript