こんにちは、サイオステクノロジー 技術2部 水倉です。
Microsoft Build 2019 2日目のセッション「Closing the key gaps of serverless with Azure Functions」をレポートします。
サーバーレスアプリケーション開発で発生する課題に対して、Azure Functions での対処方法を解説したセッションでした。
サーバーレスアプリケーションの課題
サーバーレスアプリケーションの課題として下記が挙げられていました。心当たりあるやつですね。
- コールドスタートによるレイテンシー上昇
- クラウドベンダーロックイン
- FaaS の制限
- 実行タイムアウト
- ネットワーク分離
- 外部リソース接続用などの秘密情報の管理
- 依存モジュールの管理
- CI/CD
これらの課題の多くは Azure Functions Premium プラン で対応可能であることが示されました。
Azure Functions Premium プランとは?
現在プレビューでの提供です。
より大きなリソース(4 コア、12 GB メモリまで)が使用可能
Pre-Warmed インスタンスによるコールスタートの回避
VNet 統合(プレビュー中の新しい VNet 統合機能)
– 実行タイムアウトが最大 25 分(・・・とセッションでは話されていたと思うのですが、公式ドキュメントではデフォルト30分で、無制限への設定も可能と記載あり)
ちょっと盲点なのは、Premium プランという名称がついていますが、ホスティングプラン(従量課金 / App Service プラン)ではない点です。セッションで App Service プランと Premium プランを比較していたのでてっきりホスティングプランが新設されたのかと思いますが、実際は App Service プランの価格レベル(インスタンスサイズ)として Premium プランが追加された形です。(当然ですが、Azure ポータル上もそんな UI になっています)
Premium プランは、最低 1 インスタンス分の料金が固定でかかります。Pre-Warmed インスタンス(=最低インスタンス)が 1 つ以上必須で、確保した最低インスタンス数分の料金が発生します。リクエスト数が増えてスケールした分は従量課金として扱われます。
Premium プランが提供される OS は Windows のみで、提供リージョンも限られています(日本は西日本のみ)。詳しくはこちらをご確認ください。
また、気になる料金はこちらをご確認ください。要件へのフィット、リクエスト数等を踏まえて、価格をシミュレーションして最適なホスティングプランや価格レベルを選択したいところです。
続いて、サーバーレスアプリケーションの課題に対する対策を 1 つ 1 つ見ていきたいと思います。
サーバーレスアプリケーションの課題への対策
コールドスタートによるレイテンシー上昇
前述の Premium プランの Pre-Warmed 機能により、コールドスタートの軽減をコントロールできるようになりました。
クラウドベンダーロックイン
2018 年に GA リリースされた Azure Functions 2.0 によって、Kubernetes へのデプロイが可能になっています。また、今回の Build 2019 で GA が発表された KEDA(Kubernetes-based Event-Driven Architecture) を利用することで、イベント駆動で Functions をスケーリングすることも可能になりました。
→ KEDAについてはこちらの記事で取り上げていますのでよかったら参考にしてください。
実行タイムアウト
App Service プランによって、長時間の実行時間がサポートされます。
ネットワーク分離
Functions の各プランと App Service Environment(ASE)でサポートされているネットワーク機能は下記のようになっています。
ネットワーク機能 | 従量課金 | Premium プラン | App Service プラン | ASE |
インバウンド IP 制限 | ○ | ○ | ○ | ○ |
アウトバウンド IP 制限 | × | × | × | ○ |
VNet 統合 | × | × | ○ | ○ |
新しいVNet 統合(プレビュー) (※1) | × | ○ | ○ | ○ |
ハイブリット接続 | × | × | ○ | ○ |
プライベートアクセス | × | ○ | ○ | ○ |
(※1) プレビュー中の新しい VNet 統合(ExpressRoute、サービスエンドポイントが利用できる)を指す
Premium プランは新しい VNet 統合をサポートしていますので、
- Functions から VNet 内リソースへアクセスする
- サービスエンドポイントを用いて Functions をプライベートアクセス化する、といったことが可能になりました。以前の VNet 統合は、P2S(Point-to-Site) VPN のため Gateway が必要でしたが、Gateway 不要で実現できるようになりました。
外部リソース接続用などの秘密情報の管理
秘密情報を管理する Azure Key Vault によって、コード中で秘密情報の暴露せずに実装が可能です。また、将来の予定として、自動ローテーション機能を実装する予定とのことでした。
依存モジュールの管理
昨年 GA を迎えた Azure Functions 2.0 が .NET Core 対応し、依存性注入(DI)がサポートされました。
DI 実装イメージ
1. Microsoft.Azure.Functions.Extensions をインストールする。
2. Startup.cs を作成する。
3. Functions を実装し、DI する。
セッション中のサンプルコードではコンストラクタインジェクションでの実装が示されました。(.NET Core の DI 機能を使用しているため、コンストラクタインジェクションのみが可能と思われます)
CI/CD
Functions も Azure DevOps での CI/CD が容易になりました。
- Functions のビルドタスクが GA を迎えた
- az コマンドでパイプラインを作成すると、新規コミットを検知したビルドが自動構成される
- リポジトリは GitHub または Azure Repos (Azure DevOps 提供の Git リポジトリサービス) であれば自動構成される
ちょっとした Functions でも手軽に CI/CD が使えて嬉しいですね。
最後に
最後に サーバーレスコミュニティのライブラリのアピールがあってセッション終了でした。VS Code での開発効率を上げる機能などがあるようですので、今後チェックしてみたいと思いす。
サーバーレスアプリケーションにおける課題への対策が Azure サービス側で大分補完されつつあると感じました。とは言っても、何でもかんでもサーバーレス化すればいいものではないので、メリット/デメリット、システム特性を踏まえて活用していきましょう。
STI 水倉