最近の Azure App Service について @shibayan 

はじめに • shibayan (Tatsuro Shibamura) • Azure MVP (2018/7-) • 無職 (2018/8-) • 好きな Azure のサービス – App Service • https://blog.shibayan.jp/ 

今日話すこと • App Service をざっくり振り返りつつ整理 • Ignite 2018 で発表されたことを少し • 2018 年らしい App Service の使い方 • デプロイ周りを抑えておけば大体良い（個人の感想） 

App Service について • 地味に複雑なんですよ • Web Apps • Windows / Linux • Web App for Containers (Docker) • Windows / Linux • Mobile Apps • API Apps この二つは開発止まってそうな気配ある 

App Service を使ったサービス • Azure Functions • もはや説明は要りませんね • QnA Maker • アプリ側の実装に Web App が使われている • Mobile Apps • API Apps この二つは開発（ｒｙ 

App Service Plan について • これも地味に複雑なんですよ • Free (F1) / Shared (D1) / Consumption (Y1) • Basic (B1-B3) • Standard (S1-S3) • Premium (P1-P3) • Premium v2 (P1v2-P3v2) / Isolated (I1-I3) • Premium Container (PC2-PC4) 高くて遅い、選ぶ理由も存在価値もなし Dv2 ベースなので速い Dv3 ベースなのでもっと速い 

選べない Pricing Tier がある • Consumption • Azure Functions のみ • Premium • 古い Scale unit で動いている場合のみ • Premium v2 • 新しい Scale unit で動いている場合のみ • Premium Container • Web App for Containers (Windows) の場合のみ 

VM のスペックについて • Free / Basic / Standard / Premium • A シリーズ (昔は AMD Opteron HE、今は Intel Xeon) • Premium v2 / Isolated • Dv2 シリーズ • Premium Container • Dv3 シリーズ (Hyper Threading 有効) 

Consumption だけは特殊 • 公式には S1 が使われるとなっている、が… 

App Service の選び方 • シンプルな ASP.NET アプリを動かしたい • Web Apps (Windows) を使う • PHP や ASP.NET Core アプリをサクッと Linux で動かしたい • Web Apps (Linux) を使う • 既に Docker を使って開発してるので楽な実行環境が欲しい • Web App for Containers (Linux) を使う 

Web App for Containers (Windows) は？ • 主に Lift and Shift 用だと思っている • 世の中にある ASP.NET アプリの 98% は Web Apps で動く • と思っている、感覚的に • 残りの 2% を PaaS に持っていくために使う • GAC にコンポーネントをインストールしないと動かないやつ • 実行環境をカスタマイズしないと動かないやつ 

Ignite 2018 での発表 • Linux Consumption Plan が Private Preview • 謎テクノロジー感 • Premium Functions が Private Preview • Consumption と App Service Plan の中間的な感じ • VNET Integration の改良 • ExpressRoute や Service Endpoints へのアクセスが可能に • Private IP でのアクセスも可能になるらしい 

2018 年のトレンド • Run From Package を出来る限り使う • 難しい場合は Zip Deploy で我慢する • Linux の場合は Docker Image でデプロイする • ACR と組み合わせると便利 • Azure Functions を積極的に組み合わせる • WebJobs の時代はほぼ終わった 

デプロイが圧倒的進化 MS Deploy を使った場合 • 謎プロトコルで差分だけ • ロールバック不可能 • 失敗したら中途半端な状態に • 差分を見るので遅い • ファイルロックされてると死ぬ Run From Package を使った場合 • ファイル一式を zip で上げる • デプロイがアトミックに • 謎テクノロジーでマウント • 高速化、安定性向上 • 1 つの zip を上げるだけなので 

Run From Package • Zip Deploy と WEBSITE_RUN_FROM_PACKAGE のセット • WEBSITE_RUN_FROM_PACKAGE = 1 の時に挙動が変わる • 0 の時は Zip を wwwroot に展開する • 1 の時は Zip を wwwroot に直接マウントする • URL を指定すると再起動の時に自動で最新版を落としてくる 

Docker Image の作成 • Multi-stage build ちゃんと使ってますか？ • ACR Tasks (元 ACR Build) も便利 • Automate OS / Framework patching は神機能だと思う • もし App Service でスケールが足りない場合も移行が容易 • AKS もあるし、ACI と Virtual Kubelet とかも使える • 他のクラウドベンダーにも移行できる 

WebJobs より Azure Functions • 理由は圧倒的に便利で安全だから • Azure Functions は WebJobs の上位互換と考えてよい • Long-running なタスクはそもそも適切かどうか検討する • もっと最適な処理単位があるのではないか • Durable Functions でいい感じに処理できないか、など • Application Insights でモニタリングが容易に • WebJobs はモニタリングが弱い 

Azure Functions v2 の GA • これも Ignite 2018 でリリース • v1 からの移行が推奨されている • HttpTrigger での比較で 70% スループットが改善 • .NET Standard 2.0 で書く必要があるので注意 • .NET Core 2.1 の Span / Memory は使えない • SocketsHttpHandler も怪しい • パフォーマンス上で不利になるかも 

まとめ • Windows は Web Apps を使う • Linux は Web App for Containers を使う • Zip Deploy / Run From Package を使う • Docker をちゃんと活用する • Azure Functions は最高、v2 に移行する