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

Transcript

1. Azure Serverless のパフォーマンスとコストを 最適化 Global Azure 2024 in Fukuoka Tatsuro Shibamura @shibayan
2. 私について 芝村 達郎 @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
3. Azure が 2024 年 4 月から約 20% 値上げ
5. 20% 値上げの衝撃は思ったより大きい 個人で使ってる Microsoft 365 Personal も値上げされてた
7. コストは下げたい、しかし節約はしたくな い 必要な場面ではちゃんとコストをかけるのが重要
8. どのような手順でコストを最適化するとよ いのか 失敗例：いきなりアプリケーションの構成を変える
9. コスト最適化には正しい手順がある 使われていない、不要なリソースを特定し削除する リソースの設定を変更し、パフォーマンスを改善する 過剰に割り当てられているリソースを適切なサイズに変更、集約する アプリケーションを改善する コンピューティングのリザーブドインスタンスを購入する アーキテクチャレベルから再設計する
10. Azure Serverless のリソース単価は割高な設定 素の VM と比べると機能が多く、付加価値が乗っている 内部では複数のサービスが使われているのでその分のコストが乗る 例: App Service は VMSS x 2 / SQL DB / Storage / File Server など 上手く利用すると管理・運用コストは劇的に下がる 一番高額な人間のコストを下げられる 単価が高いからと言って PaaS / Serverless を避けるのは間違っている
11. 不要なリソースの特定と削除 意外に検証用のリソースが大量に残っているケースが多い 各々が作りっぱなしで放置されたリソースグループ オーナーや作成した経緯が不明なリソースも多い 孤立してしまった App Service Plan などが代表例 環境ごとにサブスクリプションを分けると把握しやすい Cost Analysis を利用すると特定が簡単
12. サブスクリプションを環境ごとに分けて運用 検証・開発・本番の環境向けにサブスクリプションを用意する RBAC を使ったアクセス制限、コストの把握がしやすい 開発向けでは Dev / Test サブスクリプションを使うことも検討したい コンピューティング系リソースのコストが大幅に割り引かれる EA 契約の場合はやりやすい、はず
13. リソースの定期的な棚卸は重要、運用変更 も検討 不要なリソースの削除だけで 20% 削減を達成することも
14. リソースの設定変更でパフォーマンスを改善 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 圧縮を有効化する
15. PaaS / Serverless は設定が多い 提供する機能が多いので、その分だけ設定値も多くなっている 適切な設定になっていないことも多々ある 設定値が多いので IaC の導入が必須 アップデートで随時パフォーマンス、コスト最適化に役立つ機能が追加 キャッチアップが重要になってくる 公式のアナウンス、ブログ（ブチザッキなど）を参照する
16. 設定の変更だけで改善するものは確実に利 用する 特に Cosmos DB については忘れずに有効化しておきたい
17. リソースの適切なサイジングを行う 漠然とした不安から過剰なリソースを割り当ててしまうケースが多い 1 つの App Service Plan に 1 つだけ Web App / Azure Functions を載せる Cosmos DB の RU 設定を多めにプロビジョニングする インスタンス数、サイズを過剰に割り当ててしまう。など Azure Monitor を利用して、過剰にリソースを割り当てていないか確認 PaaS / Serverless はスケーリングが自由 オートスケールを活用する
18. Azure でやってしまいがちな構成 App Service / Azure Functions App Service Plan を数多く作ってしまっている 古い SKU を利用し続けている スケールアップとスケールアウトのどちらが適切かを見誤る Cosmos DB Database Provisioned Throughput を使っていない Provisioned Throughput で大きな RU を割り当てている Front Door (Standard / Premium) Endpoint を使わずに Front Door をたくさん作っている
19. Azure でやってしまいがちな構成（改善策） App Service / Azure Functions スケールによっては App Service Plan の集約を検討する 本番では Premium V3 (P0v3)、開発・検証では Basic の利用を検討する コア数を増やすより、インスタンス数を増やした方が良いケースもある Cosmos DB 25 コンテナーまでは RU を共有できる 一定のリクエストがある場合以外はオートスケールの利用を検討する Front Door (Standard / Premium) Endpoint は複数作っても課金されないためお得
20. Azure の特徴を生かして柔軟なリソース割 り当て デプロイの早いサービスを使っていれば間違いない
21. アプリケーションのコードを改善する 最新のランタイム、フレームワークを利用するように書き換える 特に .NET へのアップデートは効果的 コンピューティング系のコア数を大きく減らせる可能性 Azure SDK も最新バージョンを使うようにする 信頼性とパフォーマンス改善のアップデートが継続的に行われている 最新の PaaS / Serverless 機能を使うために必須なことも
22. APM を使ってパフォーマンスを継続的に改善する アプリケーション実装に問題があれば Azure のコストは上がる アプリケーションのパフォーマンス改善はコスト削減とイコール Application Insights を有効化して、コード内のボトルネックを特定し改善する 本番環境では確実に有効化しておきたい 非効率なクエリ実行や、過剰な外部依存関係の呼び出しが発生していることも Application Insights を使うと可視化される
23. アプリケーション側のチューニングから逃 げない ランタイム、フレームワークのアップデートは特に逃げないように する
24. リザーブドインスタンスを購入する（最終段階） 適切なリソースが確定しないとリザーブドインスタンスを買いにくい 余計な分まで購入するのは無駄になる（返金は出来るが…） 常に使われるリソース分だけを購入して、超える分はオートスケールで対応 一通りの最適化をやり切った後に購入するのを推奨 手っ取り早いのでコストカットの観点では選び勝ち Azure Storage のような容量に対しては早めに購入する価値がある
25. リザーブドインスタンスの対象となるリソース App Service (Web Apps / Azure Functions) Premium V3 / Isolated V2 (ASE) のみ対象 Cosmos DB Provisioned Throughtput が対象 ストレージサイズは対象外 Azure Storage ストレージ容量が対象
26. 早いリザーブドインスタンス購入は問題の 先送り コストを正確に把握して最適化した後に購入する
27. アーキテクチャレベルから再設計する 現在のアーキテクチャでは最適化の限界にぶつかることがある RDB や偽 PaaS と言っても良いサービスを多用した構成 Azure に最適化されておらず、オンプレのような構成と言える Azure のサービスに最適化しないとコスト効率が下がる 要件をまとめて、アーキテクチャから再設計する オンプレと同じ使い方をすると高くなるのは当然
28. Lift and Shift は幻想、Azure に特化した設 計を 仮想マシンを売りたい、使いたい人のセールストークに騙されては いけない
29. 再掲 : コスト最適化には正しい手順がある 使われていない、不要なリソースを特定し削除する リソースの設定を変更し、パフォーマンスを改善する 過剰に割り当てられているリソースを適切なサイズに変更、集約する アプリケーションコードを改善する コンピューティングのリザーブドインスタンスを購入する アーキテクチャレベルから再設計する
30. ご清聴ありがとうございました