Azure App Service の自動スケールと負荷テスト

loadtest-and-webapps
loadtest-and-webapps

はじめに クラウドの代表的なメリットの1つは、オンデマンドにリソースを確保することができ、その柔軟なスケーラビリティによって、ビジネスの状況に応じて必要かつ十分な処理能力を得られること、それによって単純なコスト削減だけではなく、コストが最適化できることであると考えます。私の日々のお仕事の中で Azure に関してお客様からご相談を頂くときは、Azure といえば PaaS、PaaS といえば Web Apps (App Service)、という話になることが大変多いです。これは App Service が最初に挙げた“クラウドのメリット” を最もわかりやすく体現しているからであると思いますし、非常にうれしい気持ちになります。本記事では App Service のスケーラビリティとその内部的な仕組みを概説し、負荷の増減に応じて自動的にスケールさせる方法、およびその挙動を検証する方法(ロードテスト)についてご紹介したいと思います。 スケーラビリティ あらためてシステムにおけるスケーラビリティとは、簡単に言えば「利用量や仕事量の変化に対して適応できる能力」のことを意味し、多くの場合以下の 2 つの手法によって実現されます。 スケールアウト/スケールイン(水平スケーリング) スケールアップ/スケールダウン(垂直スケーリング) スケールアウト/スケールインとはサーバー台数を増やす(減らす)ことを意味します。スケールアップ/スケールダウンとはサーバーのスペックを大きくする(小さくする)ことを意味します。これによってシステム全体のキャパシティを調整することで状況の変化に対応するわけです。 私はインフラエンジニアの経験がないのであくまでも想像ではありますが、物理サーバーであればその台数を増減させることは、設置場所、ネットワーク、調達等の関係からなかなか容易でないことは想像に難くありません。またマザーボードが保持する CPU やメモリのソケット数、ディスクを接続するインタフェース数の制限等から、スペックアップも限度がありそうです。もちろん仮想化技術が導入されている場合には柔軟性は高まりますが、やはり最終的には仮想マシンホスト、およびそのクラスタ全体のキャパシティに制約されます。 すなわちこういったスケール調整を実施するために、最初からそれを見越して余裕のある設計をするか、状況が変わったらそこから時間をかけて行う必要があるわけです。前者は余剰のコストが発生するリスクを、後者はビジネス機会の損失が発生するリスクをはらんでいることになります。 Azure App Service のアーキテクチャ App Service の利用形態を非常に乱暴に説明すると、複数の利用者がフロントエンドのロードバランサを共有し、その背後で動作する Web サーバーのプールのなかから数台を占有する形になっています。 占有した Web サーバーに対してアプリケーションを配置しておくと、割り当てられた URL へのリクエストがあった際に、ロードバランサーがそのリクエストを各 Web サーバーに振り分けてくれます。この確保した Web サーバーのスペックと台数を表すリソースが、App Service プラン、そこにデプロイするアプリケーションの容れ物が Web Apps(ないしは API Apps、Mobile Apps 等)と呼ばれます…

0

Azure 仮想マシンで送受信するネットワークパケットをキャプチャする

capture
capture

はじめに Microsoft Azure の IaaS(というか 仮想マシン)を使用したシステムを構築する際に、最も頭を悩ませるのがネットワーク周りの設計です(個人の主観です)。ところが先日 Azure Network Watcher の Public Preview が開始されました。こちらを利用することでネットワークパケットキャプチャを取得し、仮想マシンが実際にどんな通信を行っているのか具体的に把握することが出来るようになります。というわけで本記事ではその利用イメージを紹介していきたいと思います。 取得編 パケットキャプチャを取得するために必要な作業は大まかに以下の4つですが、より詳細な手順に関してはこちらのドキュメントをご参照ください。なお 本記事の 執筆時点では Network Watcher が利用できるリージョンが限られているため、お試しいただく際には仮想マシンや仮想ネットワークを当該リージョンに指定する必要がありますのでご注意ください。 Microsoft.Network リソースプロバイダーの Azure Network Watcher 機能を有効化する Azure Network Watcher を利用するサブスクリプションおよびリージョンを選択する キャプチャを取得したい仮想マシンに拡張機能「Network Watcher Agent for Windows/Linux」をインストールする Network Watcher に上記の仮想マシンをターゲットとするパケットキャプチャを追加する 追加したパケットキャプチャが「実行中」となっている間、当該仮想マシンで発生した送受信のログが拡張機能によって取得され、上記の手順4で指定した仮想マシンのローカルファイルとして、あるいはストレージアカウント上のBlobとして保存されます。 解析編 確認したい通信が完了した頃合いを見計らってキャプチャを停止し、ストレージアカウント等に保存されたファイルを解析用の端末のダウンロードします。このファイルは拡張子 .cap のファイルになっており、Microsoft Message Analyzer や Wireshark 等で内容を確認することができます。下記は Microsoft Message Analyzerで実際にキャプチャファイルを読み込んだ画面です。 中段左側に仮想マシン(10.0.0.4)と通信した相手先毎にグループ化されていますので、それらをドリルダウンしていくことで通信内容を確認することが出来ます。このあたりの解析作業などはオンプレミス環境で実際にネットワークに携わっていた方ならお手の物かと思います。 ちなみに上記は仮想マシンを作成しただけでほぼほったらかしの状態で取得したキャプチャなのですが、それでもいろいろと通信が行われていることがわかります。気持ち悪いですね。このうちのいくつかは Azure 仮想マシンを利用するうえで知っておかないと混乱の元になるものですので、いくつかご紹介したいと思います。 操作端末との通信 前述の図でフォーカスされている一番上のグループになるのですが、これは仮想マシンに…

0

EA 契約における Azure 使用状況と料金をタイムリーに把握しよう

EA ポータルで請求金額を確認
EA ポータルで請求金額を確認

コンサルタントからクラウド・ソリューション・アーキテクト(CSA)と言うよくわからない職種にジョブチェンジして早8か月、 ちょっと Blog とかも書いてみようかと思い立ちました。というわけでここ最近よくご相談いただいた「EA 契約のサブスクリプションだと  Azure  ポータルから料金が見えないんだけど?!」というお話です。それほど目新しい話でも無いのですが、まとまった情報が少ないようなので簡単にまとめてみました。

0

Hello world!

Welcome to Developer Network. This is your first post. Edit or delete it, then start blogging!

1