App Service Premium V2 が Public Preview になった - しばやん雑記
あまりアップデートが無かった App Service 周りですが、ここ数日で一気にインフラ周りにアップデートがあって色々と見るのが大変です。割高感しかなかった Premium がついに改善です。 Premium V2 自体は App Service Environment で使える Isolated と同じインスタンスタイプです。具体的には D1-3 v2 が使われるようになりました。 現在利用可能なリージョンは South Central US / West Europe / North Europe / Australia East / Australia Southeast の 5 つだけです。EU と Australia は Premium ユーザーが多かったのかもしれないです。 検証のために、日本から比較的近そうな South Central US を使うことにしました。 ちなみ
ローカル キャッシュ - Azure App Service
Azure App Service のコンテンツは Azure Storage に保存され、コンテンツ共有として永続的な方法で表示されます。 これは多様なアプリが機能するための設計であり、次の特徴があります。 コンテンツは、アプリの複数の仮想マシン (VM) インスタンス全体で共有されます。 コンテンツは永続的であり、アプリを実行して変更できます。 ログ ファイルと診断データ ファイルは、同じ共有コンテンツ フォルダーで使用できます。 新しいコンテンツを直接発行すると、コンテンツ フォルダーが更新されます。 SCM Web サイトと実行中のアプリでもすぐに同じコンテンツを表示できます (通常、なんらかのファイルの変更があった場合、ASP.NET などの一部のテクノロジはアプリの再起動を開始し、最新のコンテンツを取得します)。 多くのアプリはこれらの機能の 1 つまたはすべてを使用しますが、
稼働中 Azure Web Apps に影響を与える操作について (再起動とか) - poke_dev’s blog
Azure ポータルでは Web Apps に関して色々と操作出来るが、その際の稼働中 Web Apps の挙動について説明。 なお、Functions の挙動は異なるので注意 (https://poke-dev.hatenablog.com/entry/2019/11/24/160018)。 ここでは ASP.NET MVC のプロジェクト作成時の状態を Free/Basic プランの 1 インスタンス Web Apps で確認している。 Basic についても「常時接続」設定がオフの場合は、本件の確認内容については Free と本質的に差異はないはず。 また、Basic 以上のプランであれば 2 インスタンス以上にスケールアウトすることが可能だが、スケールアウト時は仮想マシン自体が増加するので、挙動の差異は特にないはず（同じ挙動が全インスタンスで同様に行われるだけ）。 なお、セッション
Azure App Service のスロットのアプリ設定について - poke_dev’s blog
Web Apps や Functions ではスロット機能を利用することができるが、スロットでのアプリ設定周りで注意が必要そうな点について確認する。 スロット新規作成時の初期設定について Web Apps 初期設定としてコピーしたいアプリ設定のスロットを選択できる。未選択も可 Functions Prd (運用) スロットのアプリ設定が常にコピーされる スロット作成後のアプリ操作について (Web Apps, Functions 共通) 新規アプリ設定追加 / 既存アプリ設定削除 / 既存アプリ設定の値変更 当該スロットのアプリ設定としてのみ、追加 / 削除 / 値変更 される ワーカープロセスは再起動する 既存アプリ設定の「デプロイ スロットの設定」値変更 (「デプロイ スロットの設定」値変更のみ) 同名のアプリ設定が存在する全スロットに対して、「デプロイ スロットの設定」値変更が行われ
Azure App Service のスロットスワップ時の挙動について - poke_dev’s blog
Web Apps や Functions の本番運用では、リリース作業時に本番環境のダウンタイム、レスポンス遅延などを最小限に抑えるため、スロットのスワップ機能が利用できる。 スワップ機能を一言で説明すると、「prd スロットをあらかじめ最新化しておいた stg スロットと交換することで、ダウンタイムなしで最新環境にする」となるが、裏ではその実現のために結構色々行われており、その内容を多少は理解してないと、スワップ時に問題が発生する可能性がある。 スワップ時の流れとしては以下となる。 Azure ポータルでスワップ開始 ソーススロット (stg) のアプリ設定を、ターゲットスロット (prd) のアプリ設定に変更する。またこの際、「デプロイスロット設定」も考慮される stg スロットのアプリ設定変更により、stg のワーカープロセス再起動が発生する。新しいアプリ設定で stg スロットが使
App Service Diagnostics で障害調査を楽にする - Qiita
App Serviceを使っていて何か問題が起きたとき、どうやって調査していますか？アプリケーションログを見る、App Insightsを使う、Failed Request Tracing (FREB) logを見る、Kuduを使うなどが主な方法だと思います。本稿では、これらの各種ログを自動で一括して走査し、原因を推定するシステム App Service Diagnostics を紹介します。 背景 もともとは我々開発チームが自分たちでの問題調査用に作ったツールだったのですが、App Service のサポートチームでもそのようなツールが切望されていたことが分かり、サポートチームからのフィードバックを受けながら改善していきました。今ではサポートチームが調査の始めに使うツールとして定着しています。これをさらに発展させ、ユーザ自身にも使ってもらえるようにポータル上にユーザインタフェースを作った
Azure App Service で障害が発生した場合にやること - しばやん雑記
Azure App Service は非常に便利なのですが、アプリケーションに何らかの問題があった場合には VM などと比べると調査方法が若干特殊です。今は公式の診断機能がかなり強化されていますが、逆に多すぎて困ることもあるのでまとめました。 用意されているツール Diagnose and solve problems を使う Support Tools を使う Kudu を使う Application Insights を使う パフォーマンス問題の場合 プロファイリングを実行する メモリダンプを取得する Auto Heal を有効にする 恐らく歴史的経緯によって機能がダブっている部分もあるので、その辺りについても書きました。 用意されているツール Diagnose and solve problems を使う 何が起こっているのかわかっていない場合は、とりあえずこの自動診断機能を使えば大
Azure Functions (App Service) が使用する通信用 IP について - poke_dev’s blog
Azure Functions、と言うよりはその基盤となる App Service の仕組みになるが、通信に使用する IP が、1 つだけ使用するとかの単純な構成ではない。 まず、受信と送信で、別の口が用意されている。受信は 1 つで、送信は 4 つから 5 つの複数個用意されている (スタンプと呼ばれる概念)。このスタンプの中に VM インスタンスを作成して実行する仕組みは、Functions の従量課金プランも App Service プランも同じ。 念の為それぞれの役割を簡単に説明すると、例えば、GET の REST API で処理を受け付け、SQL Database にクエリーを投げて、その結果を返すような Function があったとする。 この場合、まずクライアントからの REST API 呼び出しは受信用の IP で行い、SQL Database とのやり取りは、送信用の I
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Azure Web Apps の IP アドレスとネットワークについて