Azure Container Apps の Resiliency Policy ① - リトライ・タイムアウト・サーキットブレーカー・コネクションプールの構成の概要

# 本記事について

2023年11月に [**Azure Container Apps**]() で、新機能である [**Relisiliency Policy (レジリエンシーポリシー)**](https://techcommunity.microsoft.com/t5/azure-developer-community-blog/resiliency-policies-now-available-in-azure-container-apps/ba-p/3978864) がプレビューリリースされました。

https://techcommunity.microsoft.com/t5/azure-developer-community-blog/resiliency-policies-now-available-in-azure-container-apps/ba-p/3978864

これを使うことで、コンテナーアプリ間や Dapr を介した通信について、アプリケーション側ではなく Contaiener Apps 側で**リトライ**・**タイムアウト**・**サーキットブレーカー**・**コネクションプール**を実装できるようになります。

本稿では、複数ある Container Apps での Resiliency Policy を整理し、それぞれの使いどころと注意点を見ていきます。次稿以降では、各ポリシーの基本的な使い方を見ていきます。

# Container Apps の Resiliency Policy とは？

Container Apps 間の通信や Container Apps に統合した Dapr Component に対して、**リトライ**・**タイムアウト**・**サーキットブレーカー**・**コネクションプール**についての、設定値をポリシーとして定義し、割り当てることができます。

これにより、Container Apps 側の基盤から、内部的に管理している **Envoy** や **Dapr** の**サイドカーコンテナー**の仕組みを介して、基盤側でそれぞれの処理を行います。

ユーザーは、**アプリケーションコード側でそれぞれリトライなどを組み込むのではなく**、**Container Apps 側の設定で統合してレジリエンシーを実装**することができます。

# 2種類の Resiliency Policy

この Container Apps の Resiliency Policy には、Container Apps が内部的に実装しておりユーザーからは完全に隠蔽された Envoy を介して Container Apps 間通信に適用される「**サービス検出のレジリエンシー**」と Container Apps でオプションとしてユーザーが利用できる Dapr Component にレジリエンシーを構成する「**Dapr コンポーネントのレジリエンシー**」の２種類があります。

それぞれ、適用可能な対象を下記にまとめてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/68972da0-b0f8-9c83-cb25-10ef1bd20371.png)

注意点として、2024年3月時点では、Dapr を介して Container Apps 間の通信を構成している場合、サービス検出のレジリエンシーは未対応で、Dapr も Dapr コンポーネントを利用していないため利用できないことがあります。

次に、それぞれのポイントをまとめます。実際の構成例や実装結果は次稿以降でご紹介します。

# 1. サービス検出のレジリエンシー

サービス検出のレジリエンシーは、2つの Container Apps 間の HTTP/TCP 通信でリトライやサーキットブレーカーなどを組み込みたいときに利用します。名前の通り、Container Apps 環境で提供されているサービスディスカバリを介して、レジリエンシー機能が提供されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/70a99577-fda5-445f-9634-ad9f96aa8a03.png)

このポリシーを作って割り当てておくと、Container Apps が内部的に利用している (が、ユーザーには隠蔽されて見えない) Envoy を介して、Container Apps のサービス側でそれぞれの処理が行われます。注意点として、上記の絵が示している通り、ポリシーは要求を受け付ける側に割り当てるということがあります。そのため、その Container Apps に対して通信要求を行うすべての Container Apps に対してポリシーが適用されます。

# 2. Dapr コンポーネントのレジリエンシー

Dapr のコンポーネント (Component) とは、Dapr の中で提供される様々な機能をモジュール化したものです。主な対象機能としては、例えばステートストアや Pub/Sub ブローカー、バインディングやシークレットストアなどが挙げられます。

https://docs.dapr.io/concepts/components-concept/

Container Apps の中で統合された Dapr のコンポーネントを利用できますが、Resiliency Policy はそのコンポーネントにポリシーを割り当てる形で、リトライなどを利用することができます。

https://learn.microsoft.com/ja-jp/azure/container-apps/dapr-component-connection

https://learn.microsoft.com/ja-jp/azure/container-apps/dapr-component-resiliency?tabs=bicep

例えば、Service Bus との接続を、Dapr コンポーネントを介して実装している場合、Container Apps と Service Bus 間の接続に対して、リトライやタイムアウト、サーキットブレーカーを組み込むことができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/79ae4252-0b6a-de0b-8dc6-b0a5892114a5.png)

# 最後に

[次の記事](https://qiita.com/YoshiakiOi/items/e95dffc376eaf01c877a)では、サービス検出のレジリエンシーでのリトライについて、サンプルアプリケーションで挙動を見ていきます。また[記事③](https://qiita.com/YoshiakiOi/items/5c6b4a7edb9956ab2ce1)では、サーキットブレーカーをご紹介します。

https://qiita.com/YoshiakiOi/items/e95dffc376eaf01c877a

https://qiita.com/YoshiakiOi/items/5c6b4a7edb9956ab2ce1

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。