Azure使う？使わない？ 〜Azure Functions編〜 その2

はじめに

一般的にサービスの良い面は語られがちですが、残念な面について語られることは少ないですよね。
そこで本記事ではAzureの利用を検討している方々に向けて、Azure Functionsの残念な点をあえて挙げることでAzureを使用するかどうかの判断材料としていただくことを目的としています。

よろしければAzure Functions編 その1も御覧ください。

それではAzure Functionsの残念な点を以下挙げていきます。

障害や不具合が多い

体感ですがAzure Functionsは障害や不具合といったトラブルが非常に多いです。

たちが悪いのはこれらがAzureのインフラ側で障害として検知されないことが多いです。
サービス正常性やリソース正常性という機能でMicrosoft側管理部分の障害ログを確認できるのですが、明らかに障害が起きていたにもかかわらず正常としてログが記録されます。

そして、こういった障害が起こるたびにAzureサポートへ調査依頼と我々開発者側で行うことが出来る対策も聞いているのですが、大抵は調査の結果原因は不明で原因がわからないので対策も無いと返ってきます。

ちなみに障害として検知されない障害はAzure Functionsに限らずAzure全般で発生します。
Azure組み込みの障害対応系の機能があてにならないので、私はそういった機能を自分で作り込むことが多いです（というか作り込まざるを得ない）。

バージョン管理がやたら多い

Azure Functionsでは以下についてそれぞれバージョンがあり我々開発者側でバージョンを設定する必要があるため、これら全てバージョン管理しなければいけません。
ここではNode.jsを例に挙げますが基本的にはどの言語でも同じです。

• Node.jsのバージョン
  これは説明不要ですね。
  
  

• 各種npmパッケージのバージョン
  これも説明不要ですね。
  
  

• Azure Functionsパッケージのバージョン
  ソースコード内でインポートするAzure Functionsのパッケージです。
  このパッケージを利用して実際の処理を書いていきます。
  
  

• 拡張機能バンドルのバージョン
  拡張機能とはいうもののほぼ必須で使用する機能です。
  Azure Functionsが内部で他のAzureサービスと通信するために使用します。
  例えば「Azure Queue Storageにキューデータが登録されたら処理を実行」というAzure Functionsを作成する場合Azure Queue Storageの拡張機能が最低限必要となります。
  
  

• Azure Functionsランタイムのバージョン
  Azure Functionsの基盤のバージョンです。

上2つは当然仕方ないにしても、Azure Functions側のバージョンを3つも管理するのは結構大変です。
後方互換性も低くメジャーバージョンアップすると大抵破壊的変更が発生するため、ソースコードの実装よりもバージョンアップ作業がメインではないかと思うくらいそれに追われることとなります。

もしAzure Functionsでマイクロサービスなアーキテクチャにしたら…もはや考えたくもないですね…。

破壊的変更が多い

1つ前の章でも触れましたがAzure Functionsは破壊的変更が多いです。
中にはアーキテクチャを根本的に変えざるを得ないような変更もあり、バージョンアップ作業もかなり手間がかかります。
詳しい解説はしませんが近年の大きな変更だけでも以下のものがあります。

• 共通 - Azure Functionsランタイム v3 → v4 に伴うAzure Functionsプロキシの廃止（予定）
• Node.js - プログラミングモデル v3 → v4 の変更
• Python - プログラミングモデル v1 → v2 の変更
• C# - インプロセスモデル → 分離ワーカーモデル の変更

特にC#は破壊的変更が多い印象です。
「こいついつも破壊してんな」と思うくらい破壊的変更が多いです。

また、公式ドキュメントのソースコードもこういった変更に追従できていないです。
Azureはユーザの情報発信が少なく唯一の情報源が公式ドキュメントということが多いため結構困りますね。

従量課金プランだと閉域（VNET）を利用できない

Azure Functionsの料金プランは主に 従量課金プラン / App Serviceプラン(固定料金) / Premiumプラン(固定料金+α) の3種類があります。¹

従量課金プランは一般的に想像されるFaaSの料金プランで 〇円/秒 × △秒実行 = ◇円 の料金プランです。
固定料金のプランはVMのように CPU：〇コア / メモリ：△GB を確保してそれに対して料金を払うプランです。

Azure Functionsではこの従量課金プランで閉域（VNET）を利用することはできません。
閉域（VNET）を利用する場合は固定料金のプランにする必要があり料金が高額になりやすいです。
その他の機能でも従量課金だと対応していない・対応しているが制限が厳しいといったものも多いため、基本的に従量課金プランは開発用やライトな本番用での使用に留まります。

これはAzure Functionsに限らず、Azureサービスでは一般的に従量課金プランは下位プランとして位置しています。
また、Azureでは固定料金のプランが一般的なため従量課金プランが存在するAzureサービスがそもそも少ないです。

Node.jsでES Modulesを本番環境で使用できない

Node.jsではv14あたりからES Modulesが正式リリースされていますが、Azure FunctionsのNode.jsでは2025年6月現在いまだにES Modulesがプレビューのままです。

CommonJSとES Modulesはそのままでもある程度は相互運用可能ですが完全に互換性があるとは言えないですよね。
先日npmで週間数百万ダウンロードされているES ModulesオンリーのパッケージをAzure Functionsで使おうとしたところCommonJSではどうやっても動かなかったため使用を断念しました。

Azure Functionsの公式リポジトリやロードマップを見ているとES Modulesの対応に全く手を付けている気配が無いため、我々Azure FunctionsユーザにとってはES Modulesは AGI よりも未来のテクノロジーになるかもしれません。

Azureではこういったプレビューのまま永遠にGAされない機能というのは結構あります。
プレビューからGAせずに廃止される機能も結構あります。

あなたの結論は？

Azure使う？使わない？

1. Flex従量課金という新しいプランがありますが半年前にGAしたばかりで、東日本リージョンも1か月前に対応したばかりです。（西日本リージョンは未対応）
   
   そのため本番運用で必須またはよく使う既存機能にまだ対応しておらず、それらの機能の対応スケジュールも公開されていません。
   そのため今までのAzureの開発速度からいって本番で使えるレベルに成熟するには最低でもあと2, 3年はかかるのではないかと判断して今回の記事からは除外しています。
   
   https://learn.microsoft.com/ja-jp/azure/azure-functions/flex-consumption-plan ↩