2025年4月よりAzureを触りだしたので、思ったことをつらつらと。

はじめに

Azure Functions を活用したアプリケーション開発において、Cosmos DBとの接続は頻繁に発生します。しかし、Function App が複数に分かれたり、Function数が増えると、Cosmos DBへの接続構成が複雑になり、Private EndpointやDNSの管理が煩雑になります。

そこで本記事では、Cosmos DBアクセス専用のFunctionを1つに集約する設計アーキテクチャについて、その利点・構成・考慮点を解説します。

構成の課題：FunctionごとにCosmos DBへ直接アクセスする場合

各Function Appごとに Cosmos DB への接続が発生
Private Endpoint（PE）をFunctionごとに構成しなければならない
Private DNSのリンク、NSG/UDR設定、コストもFunction数に比例して増加
管理・保守・トラブルシュートが煩雑化

解決策：Cosmos DBアクセス用の専用Functionを1つに集約！

アーキテクチャ構成

+-------------------+     HTTP/API     +-----------------------------+
| Function A        |---------------->|                             |
| Function B        |                 | Cosmosアクセス専用Function  |
| Function C        |---------------->| (PE + DNS構成済)            |
+-------------------+                 +--------------+--------------+
                                                    |
                                                    v
                                              [ Cosmos DB ]

メリット

Private Endpointを最小限（1つ）にできる
データアクセスの責務が明確化し、設計がシンプルになる
他のFunctionからはHTTP/API通信で呼び出すだけなので、Functionの追加・変更が容易
セキュリティポリシーやNSGも集中管理可能

実装上の考慮点

通信方式

Functions間は HTTPまたはManaged Identity経由の呼び出しを推奨
必要に応じてFunction KeyやAPIMなどで認証制御

スキーマ管理

Cosmosアクセス専用Functionは **明確なAPI契約（JSONスキーマなど）**を持たせると運用がスムーズ

ネーミングと設計方針

CosmosProxyFunctionAppなどの名前で明示
/api/cosmos/queryItem や /api/cosmos/upsertDocument のようなREST設計で統一

レイテンシ

Functions間の通信は 同一リージョン＋バックボーン経由ならmsオーダーで影響はほぼない

拡張性と保守性の向上

Function追加時にCosmos接続処理を実装し直さなくてよい
Cosmos DBの構成変更（DB名・パーティションキー等）もProxy Functionのみ修正で済む
将来的に APIMやgRPC、Service Bus経由にリファクタリングしやすい

パフォーマンスとスケーリングの最適化

Azure Functions（特に従量課金型）の課題として知られる「コールドスタート」は、
アプリケーションの応答性に大きく影響します。これを軽減する上でも、Cosmos DBアクセスを1本に集約する構成は効果的です。

コールドスタートとは？

Azure Functions は、一定時間アクセスがないとインスタンスを停止します。
停止状態から再起動する際に、数秒〜十数秒の遅延が発生します。

なぜ集約構成でコールドスタートが起きにくくなるのか？

全てのリクエストが Cosmos DB 専用Function に集中するため、
この Function は 常にトラフィックが流れる「水が流れる構造」 となり、
スケールインされにくく、ウォーム状態が維持されやすいのです。

分散構成との比較：

構成	コールドスタートの可能性	備考
各Functionが分散してDBに直接アクセス	高い	呼ばれないFunctionがコールドになる
Cosmos DBアクセスを1本に集約	低い	常にリクエストが流れているためインスタンス維持されやすい

結果として、応答時間の安定性・パフォーマンス向上にもつながる構成となります。

まとめ

観点	集約型アーキテクチャのメリット
コスト	PEやDNS構成が最小限で済む
運用	Cosmosアクセスを1箇所で管理可能
セキュリティ	NSGや認証制御が一元化できる
拡張性	新規Function追加がスムーズ

Azure Functions が複数ある構成でも、Cosmos DBアクセスは専用Functionにまとめることで、セキュアかつスケーラブルなアーキテクチャが実現できます！

今はベストな整理構成を未来の自分にプレゼントする時代！
設計の一手間が、開発効率と運用安定性を何倍にもしてくれるよ。