はじめに
Storage Account の管理処理において、Logic Apps から Azure Functions Flex Consumption プランに移行することで、月額コストを99%以上削減できました。この記事では、移行の詳細と実際の効果について体験談をお伝えします。
移行前の課題
移行前の Storage Account 管理システムは Logic Apps でコネクタを駆使して構築しましたが、このコネクタがかなりの曲者で Table Storage に対してステータス更新のトランザクションが大量に発生します。それが原因として下記に挙げるような課題が出てきました。
- 高額な運用コスト：従量課金による予想以上の高いコスト
- 処理速度の遅さ：平均90分程度の処理時間
- システムの不安定性：メモリエラーの頻発
- 複雑なワークフロー：環境ごとに5つものワークフローが必要
この場合、ワークフローを「ステートフル⇒ステートレス」へ変更して回避も可能なのですが、その場合は各処理の成功失敗が分からず運用上困ったことになります。また、プライベートネットワークでの構築が要件として入っていたため、従来の Azure Functions や Automation は使えませんでした。そこで、最近出てきた「Azure Functions Flex Consumption」を活用する運びとなりました。
移行後の構成
アーキテクチャの変更
Logic Apps ベースの処理を以下の構成に変更しました：
- Azure Functions（Flex Consumption プラン）：メイン処理エンジン
- Durable Functions：複雑な処理フローの管理
- Logic Apps：Function キック用の軽量ワークフロー
- Storage Account：Function 用の専用ストレージ
コスト構成の内訳
移行後のコスト構成は以下のような比率になりました：
| コンポーネント | コスト比率 |
|---|---|
| Azure Functions | 約45% |
| Logic Apps（キック用） | 約15% |
| Storage Account（Function 用） | 約40% |
Flex Consumption プランにより、実際の処理時間に応じた課金となり、大幅なコスト削減を実現できました。
移行による効果
1. 劇的なコスト削減
移行前
Logic Apps ではコネクタを呼び出すたびにステータス情報を持つ Table Storage へトランザクションが発生するため、膨大な運用コストとなっていました。※１
このことから、Storage Account の管理のように膨大なループ処理を必要とする処理には向いていないようです。
※1 今回のケースでは、1日に数万回の Table Storage トランザクションが発生していました。
移行後
スケジューラーでのキック処理のみ Logic Apps へ残し、Storage Account への管理操作を Azure Functions での Azure PowerShell によるリソース操作へ移行しました。結果として、運用コストを大幅削減（99%以上の削減率）でき月額コストを1/100以下に圧縮できました。
2. パフォーマンスの向上
さらに、コスト削減だけでなく以下のようにパフォーマンス向上を行えました。
- 処理時間の短縮：90分 → 40分（55%短縮）
- 処理の安定化：メモリエラーの解消
- リソース効率化：必要な時だけリソースを消費
3. 運用の簡素化
- ワークフロー統合：コピーと削除を統一
- ワークフロー数削減：環境ごとに5つ → 統合により削減
- 保守性向上：よりシンプルな構成
移行時に直面した課題とデメリット
一方で、今回の移行は一筋縄では進まず、以下のような課題も発生しました。
1. ネットワーク構成の変更
VNet統合やPEの作成に以下の構成変更も必要となりました。
- サブネットの新規作成・設定
- IPアドレスの払い出し
- NSG、AzureFirewallの設定変更
2. 構築の複雑性
現状ではAzure Functions Flex Consumptionは情報も少なく、構築や学習に時間を要しました。
- Durable Functions の学習コストが高い
- 設定が複雑で構築に時間を要した
- 既存 Logic Apps からの移行作業
3. ストレージアカウントの作成
今回は Durable Functions を使用しましたが、オーケストレーターでの設定とステータス保持用の専用 Storage Account が必要となり、新規作成しました。
今回の学び
今回の移行は結果として成功しましたが、課題も多かったです。
事前に以下の準備を進めておくことがスムーズな移行を実現できると考えました。
1. 検証環境での徹底的なテスト
Azure Functions Flex Consumption は意外と制約があります。十分に注意してしっかりとした検証をしましょう。公式の記事としてはこの辺りを見ておきましょう。
ChatGPT4 や Gemini2.5 は従来の Azure Functions と見分けがつかず、ハレーションを起こすことが多かったので注意してください。（2025/10/14現在）
2. パフォーマンス測定とコスト試算
ほとんどのケースの場合、Logic Apps のみの利用よりも Azure Functions Flex Consumption を活用する方がコスト削減効果が見込めます。一方で移行コストもかかるので移行前後のコスト比較を計算しておくことは非常に重要です。上司や投資家への説明責任も果たせます。
Logic Apps のコストを見積もる際は以下を参照してください。
3. 移行手順の詳細な策定
Durable Functions にもともと親しみのあるエンジニアであれば、スムーズに移行できるかと思いますが初めて Durable Functions で構成を作成する場合は、予想以上に学習コストがかかります。検証期間や従来の仕組みとの平行稼働期間などもできれば設けるようにしておきましょう。私のケースでは提案から構築まで数ヶ月を要しました。
結論
Logic Apps から Azure Functions Flex Consumption への移行により、以下の成果を得られました：
- ✅ 99%以上のコスト削減（月額コストを1/100以下に圧縮）
- ✅ 55%の処理時間短縮（90分→40分）
- ✅ システムの安定化とメモリエラー解消
- ✅ 運用の簡素化とワークフロー統合
一方で、ネットワーク構成変更や Durable Functions の学習コストなどの課題もありましたが、得られる効果を考えると十分に価値のある移行でした。
さいごに
Azure Functions（Flex Consumption プラン）について
Azure Functions Flex Consumption プランは、適切に活用することで大幅なコスト削減と性能向上を実現できる優れたサービスです。特に、処理量に変動があるワークロードや、コスト最適化を重視するシステムにおいて、その真価を発揮します。
コスト削減について
クラウド環境を利用する上では、定期的に構成を見直して改善案を考えることが非常に重要だと思いました。Azure Functions Flex Consumptionはここ1年間で日本リージョンにGAしたプランです。つまり、1年前ではできなかったことが今できているということです。Azureでは年間で数百～数千の更新が行われております。こういった最新情報を常に取り入れ、より良いシステムにできないかといった考えを常に持てるエンジニアとなれるよう日々精進していきます。
本記事が、同様の課題を抱えている方の参考になれば幸いです。