最近の Azure App Service について

Transcript

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

2. はじめに • shibayan (Tatsuro Shibamura) • Azure MVP (2018/7-) •

   無職 (2018/8-) • 好きな Azure のサービス – App Service • https://blog.shibayan.jp/

3. 今日話すこと • App Service をざっくり振り返りつつ整理 • Ignite 2018 で発表されたことを少し •

   2018 年らしい App Service の使い方 • デプロイ周りを抑えておけば大体良い（個人の感想）

4. App Service について • 地味に複雑なんですよ • Web Apps • Windows

   / Linux • Web App for Containers (Docker) • Windows / Linux • Mobile Apps • API Apps この二つは開発止まってそうな気配ある

5. App Service を使ったサービス • Azure Functions • もはや説明は要りませんね • QnA

   Maker • アプリ側の実装に Web App が使われている • Mobile Apps • API Apps この二つは開発（ｒｙ

6. 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 ベースなのでもっと速い

7. 選べない Pricing Tier がある • Consumption • Azure Functions のみ

   • Premium • 古い Scale unit で動いている場合のみ • Premium v2 • 新しい Scale unit で動いている場合のみ • Premium Container • Web App for Containers (Windows) の場合のみ

8. VM のスペックについて • Free / Basic / Standard / Premium

   • A シリーズ (昔は AMD Opteron HE、今は Intel Xeon) • Premium v2 / Isolated • Dv2 シリーズ • Premium Container • Dv3 シリーズ (Hyper Threading 有効)

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

10. App Service の選び方 • シンプルな ASP.NET アプリを動かしたい • Web Apps

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

11. Web App for Containers (Windows) は？ • 主に Lift and

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

12. Ignite 2018 での発表 • Linux Consumption Plan が Private Preview

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

13. 2018 年のトレンド • Run From Package を出来る限り使う • 難しい場合は Zip

    Deploy で我慢する • Linux の場合は Docker Image でデプロイする • ACR と組み合わせると便利 • Azure Functions を積極的に組み合わせる • WebJobs の時代はほぼ終わった

14. デプロイが圧倒的進化 MS Deploy を使った場合 • 謎プロトコルで差分だけ • ロールバック不可能 • 失敗したら中途半端な状態に

    • 差分を見るので遅い • ファイルロックされてると死ぬ Run From Package を使った場合 • ファイル一式を zip で上げる • デプロイがアトミックに • 謎テクノロジーでマウント • 高速化、安定性向上 • 1 つの zip を上げるだけなので

15. Run From Package • Zip Deploy と WEBSITE_RUN_FROM_PACKAGE のセット •

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

16. Docker Image の作成 • Multi-stage build ちゃんと使ってますか？ • ACR Tasks

    (元 ACR Build) も便利 • Automate OS / Framework patching は神機能だと思う • もし App Service でスケールが足りない場合も移行が容易 • AKS もあるし、ACI と Virtual Kubelet とかも使える • 他のクラウドベンダーにも移行できる

17. WebJobs より Azure Functions • 理由は圧倒的に便利で安全だから • Azure Functions は

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

18. Azure Functions v2 の GA • これも Ignite 2018 でリリース

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

19. まとめ • Windows は Web Apps を使う • Linux は

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