「Azure Paas環境の負荷試験」

Azure PaaS 環境の負荷試験 株式会社ビヨンド 長谷 竜弥

プロフィール ・名前：長谷 竜弥（ながたに たつや） ・2016 年に 株式会社ビヨンドに入社、現在5年目のW ebエンジニア ・業務内容：W eb サイトのサーバーサイドの開発、ゲームAP I の開発 ・主な開発言語：P HP 、C# ・趣味：野球、アニメ ※彼女募集中！

目次 ・概要と構成 ・負荷試験の目標値 ・負荷試験の流れ ・SQLチューニングについて ・負荷試験の結果 ・オートスケーリングについて ・まとめ

概要 ■案件 ・シングルサインオン（アカウント認証を共通化する仕組み）の開発 ■負荷試験の内容 ・ログインAPI の負荷試験を実施 ⇒今回はこのAP Iのみ ・ツールは Apache J Meter を使用

構成 ■プラットフォーム ・Azure ■サービス構成 ・App Service（P aaS） ・SQL Database（DBサーバ） ■言語 / フレームワーク ・ASP .NET Core（C# ） ※ ログイン認証は ASP .NET Core Identity を使用

App Service とは？ ・Microsoft Azure が提供する P aaS(P latform as a Service) ・W eb Apps、Mobile Apps、AP I Apps、Logic Apps の アプリが用意されている ・アプリケーションの迅速な構築が可能 ・手動/ 自動でのスケールアップ(アウト)が可能 【対応言語】 .NET / .NET Core/ J ava/ Node.js/ P ython/ P HP / Ruby ⇒幅広く対応している

SQL Databaseとは？ ・Microsoft Azure が提供する フル マネージドの P aaS データベース エンジン ・SQL Server をベースにしている ・ほとんどのデータベース管理機能をユーザーの介入なしで処理することが可能 ・自動バックアップ ・自動チューニング ・可用性の担保 ・購入モデルは2種類ある ・仮想コア：処理能力とストレージをそれぞれ選択できるモデル ・DT U：処理能力とストレージがセットになったサイズの選択を行うモデル

システム構成図

サーバ構成図

負荷試験の目標値 ・ピークの時間帯で約96万ユーザー（1時間）のアクセスを想定 ・単純に計算すると秒間 約 270 リクエスト ※ 96 万（ユーザー）÷ 3600（秒）＝266.67 （リクエスト） ・多少バッファをもって 300 RP S を目標に負荷試験を実施 ・データ量（ユーザー数）は 10000 にしている ※ RP S（Request P er Second）：1秒間に処理を行うHT T P リクエストの数

負荷試験の流れ 1. App Service、SQL Database を最小構成にした状態で試験 2. 1の結果から、チューニングを検討し実施する 3. 負荷（CP U使用率、メモリ使用率）の状況を見ながら、 スペック・台数調整を行い、RP S 300 になるまで負荷試験を繰り返す 1. 3の結果から最終的なスペック・台数を決定

負荷試験の結果（最小構成） サービス プラン ｲﾝｽﾀﾝｽ数 コア数 メモリ App Service Basic 1 1 1.75 GB サービス プラン スペック SQL Database Basic DTU x 5 結果 スレッド RampUp ループ エラー率 RPS 10 1 100 2.1% 3.04 ・参考値として最小構成で試験 ・最小構成のため、3.04 RPS となった ・プログラム処理に関しても、500 エラーが2.1%発生 ・この結果から、SQLチューニングを実施

SQLチューニングについて ・ログイン処理で実行されるクエリの洗い出し ・洗い出したクエリの実行計画（Explain）から、クエリ文や Index 等を調整 ログイン処理時間（ms） 1回目 2回目 3回目 4回目 5回目 最大 最小 平均 チューニング前 142 109 141 107 99 142 99 119.8 チューニング後 86 87 92 92 82 92 82 87.8 処理時間が平均 32 ms 短縮

負荷試験の結果（パターン1） サービス プラン ｲﾝｽﾀﾝｽ数 コア数 メモリ App Service S1 10 1 1.75 GB サービス プラン スペック SQL Database Standard DTU x 200 CPU 使用率 スレッド RampUp ループ 10 10 エラー率 結果 2000 0% ・それぞれプランを1ランク上げて試験 ・結果は 101.91 RP S で 200RP S の 2 分の 1 程度 ・App Service のCP U使用率が 100 % ・DT U を下げApp Service のプランを上げ再度試験 App Service SQL Database 100% 47% RPS 101.91

負荷試験の結果（パターン2） サービス プラン ｲﾝｽﾀﾝｽ数 コア数 メモリ App Service P1V2 5 1 3.50 GB サービス プラン スペック SQL Database Standard DTU x 100 CPU 使用率 スレッド RampUp ループ 10 10 エラー率 結果 2000 0% App Service SQL Database 94% 100% ・App Service のプランを 1 ランク、インスタンス数を 1/ 2 の 5 に設定 ・SQL Database の DT U を 1/ 2 の 100 に設定 ・結果は 105.58 RP S でパターン1と大きな変化なし ・DB の CP U 使用率 が100％ ・DT Uを上げて再度試験 RPS 105.58

負荷試験の結果（パターン3） サービス プラン ｲﾝｽﾀﾝｽ数 コア数 メモリ App Service P1V2 5 1 3.50 GB サービス プラン スペック SQL Database Standard DTU x 200 CPU 使用率 スレッド RampUp ループ 10 10 エラー率 結果 2000 0% App Service SQL Database 88% 58% ・SQL Database の DT U を倍の 200 に設定 ・結果は 144.63 RP S で目標の 1/ 2 程度 ・App Service、DB 共に CP U 使用率 が 100 % を下回った ・この構成をベースとし App Service、DBのスペックを倍にして再度試験 RPS 144.63

負荷試験の結果（最終） サービス プラン ｲﾝｽﾀﾝｽ数 コア数 メモリ App Service P1V2 10 1 3.50 GB サービス プラン スペック SQL Database Standard DTU x 400 CPU 使用率 スレッド RampUp ループ 10 10 エラー率 結果 3000 0% App Service SQL Database 76% 39% RPS 296.08 ・App Service インスタンス数を倍の 10 に設定 ・DB の DT U を倍の 400 に設定 ・結果は 296.08 RP S で、目標値である 300 RP S を捌ける構成となった ・負荷もApp Service、DB 共に安定していたため、この構成を最終のものとした

オートスケーリングについて ・先ほどまでの負荷試験はあくまでもピーク時に耐えれる構成 ・常時この構成では、コスト面での不安が大きい ⇒オートスケーリングを考慮する必要がある ・App Service にはオートスケーリング機能が備わっている ・最終構成をベースとして、スペックをある程度下げた状態を デフォルトとし、CPU使用率が高くなればオートスケーリングで 性能を上げる形で調整を行った ※ SQL Databaseのオートスケーリング機能はデフォルトの機能では 備わっていない

SQL Database のオートスケーリングについて ・デフォルトでオートスケーリング機能が備わっていない ・Azure Automation を使って疑似的にオートスケールを行うことが可能 ※導入方法についてはビヨンドHP のブログを参照 ■URL https:/ / beyondjapan.com/ blog/ 2020/ 07/ sql-database-automation-auto-scale/ または「ビヨンドブログ SQL Database オートスケール」で検索

まとめ ・PaaS の負荷試験も通常の負荷試験と同様に実施することができる ・App Service にはオートスケーリング機能が備わっている ・SQL Database は Azure Automation を使うと疑似的に オートスケーリングができる ・P aaS でのW ebアプリケーション構築は LAMP に比べ 環境を簡単に構築することができる

・PaaS の負荷試験も通常の負荷試験と同様に実施することができる ・App Service にはオートスケーリング機能が備わっている ・SQL Databas ご清聴ありがとうございました！