Container Apps×Queue駆動で月額のインフラ運用コストを90%削減したブログ基盤設計の話

一回固定の有料モデルが適当かどうか——Azure で間欠的なバッチ処理を動かす際、この課題は避けて通れません。ストレージを組み合わせた非常に時々実行する設計を採用し、月額コストを約90%削減できる覚悟を得ました。定期課金から従量課金への設計転換を行って成立したか、具体的な判断基準と構成を記録します。

こんにちは。monoAIテクノロジーエンジニアのゆーすけです。

背景：担当者のローカルPCから本番環境へ

今回構築したのは、Slack 上にあるナレッジを文書化して、本人が Slack でフィードバック・修正を加えてから公開する人間参加型のワークフローです。当初は担当者のローカル PC 上で定期実行するシステムとして作られていましたが、本番運用のため Azure App Service に載せようと検討を開始しました。

この「間欠的な処理」に対し、従来同様に継続課金されるApp Serviceを選ぶべきか、待機時間分のみ課金される別の選択肢があるか——検討の結果、Azure Container Appsであればよりコンパクトに構築できることがわかりました。処理頻度は1回、都度数分程度。

選択肢の比較：App Service とコンテナー アプリ

Azure 上でコンテナワークロードを動かす代表的な選択肢として、App Service と Container Apps を比較しました。

当初はApp Serviceで「必要な時だけスケールイン」を検討しましたが、最小とりあえず1台の待機時間でも固定費が発生するとわかり、方針を転換します。

設計方針：キュー駆動で処理をバッファし、コンテナアプリを起動

採用した構成は以下の3構成です。

実行パターンは２つ。①マルチ起動で定期的に新規記事を生成、②キューにリライト依頼が入ったら瞬時にコンテナを立ち上げて処理します。どちらも処理完了後はコンテナが終了し、課金も行います。

これからのポイント

Container Appsのスケールルールでは、Queue Storageの深さ（未処理メッセージブロック）をトリガーに設定しました。KEDAがキューの長さを監視し、メッセージが到着すると自動的にコンテナをスケールアウトします。タイマー起動にはCRON式を利用し、深夜帯に記事生成ジョブを実行する設計です。

APIキーは環境変数としてKey Vaultから参照し、コンテナイメージにハードコードを採用しない構成を採用しています。これによりシークレットローテーション時もイメージの再ビルドが不要になります。

コスト試算の結果

試算では約90%削減の覚悟を得ましたが、現在は外部AI APIのクレジット追加とリソース構築を進めている段階で、本格運用はまだ開始していません。実運用前のため実測値はまだ取得しておらず、実際の実行パターン（リライト依頼の頻度、記事生成時間など）によって変動する可能性があります。

現状のリセットと次のステップ

コスト削減効果は試算ベースであり、本格運用開始後に実測コストと処理時間のモニタリングが次の課題となります。また、外部AI APIのクレジット管理については、適切な利用枠設定を行い、ブログ専用のAPIキーを作成する方針で進めています。

まとめ

「間欠的にしか動かない処理」に対してContainer AppsとQueue Storageを組み合わせた設計を採用し、App Serviceの常時課金モデルから脱却しました。最終的に採用した方針は、キューでリクエストをバッファしてイベント駆動でコンテナを起動する仕組みです。

同じAzure上でも、処理パターンに応じてサービスを選ぶだけで大幅なコスト削減の意見もあります。常に実行不要なバッチ処理で固定費に悩んでいる方の参考になれば幸いです。

🔗参考リンク

• Azure Container Apps のスケーリング | Microsoft Learn
• Azure Functions の KEDA スケーリング マッピング (コンテナ アプリ) | Microsoft Learn