こんばんは。今日は、Microsoft Azure（App Service, Azure Functions, Application Gatewayなど）で登場するARR Affinity (ARRアフィニティ)という概念について調べて分かったことをまとめておきたいと思います。
Contents
ARR Affirnityとは何か？
まず、言葉の定義と意味を確認しておきましょう。
ARR AffirnityはApplication Request Routing Affinityの略になりますが、一言でいうとARRを使ったセッションアフィニティを実現するために発行されるクッキーのことです。
Affirinityは日本語で「親和性」「類似性」という意味があり、転じて、リクエストがクライアントからサイトに入ったときに、それ以降のすべてのリクエストが、アクセスされた最初のクライアントリクエストと同じサーバーに送られるようにする仕組みを「Session Affirnity」と呼んでいますね。別名Sticky Session (スティッキーセッション）とも呼ばれています。
そして、次に「ARR」ことApplication Request Routingという言葉は、もともとMicrosoftが開発したWebサーバであるIIS (Internet Information Service)で利用されていた用語のようです。
詳しい説明は以下の公式ドキュメントの説明に譲ります。
Application Request Routing (ARR) is an extension to Internet Information Server (IIS), which enables an IIS server to function as a load balancer. With ARR, an IIS server can be configured to route incoming requests to one of multiple web servers using one of several routing algorithms.
https://en.wikipedia.org/wiki/Application_Request_Routing
なお、詳細は、こちらの記事がとても詳しく分かりやすく書かれていたので、リンクを貼っておきます。
https://satonaoki.wordpress.com/2011/12/25/azure-eclipse-session-affinity/
Session Affirnityを使うメリット・デメリット
まず、ARR Affinityに限らず一般的なセッションアフィニティのメリット・デメリットを確認しておきます。これはこちらのStack Overflowに良い回答がありました。
以下、抜粋です。複数のインスタンスで負荷分散している状況で、１つのインスタンスが停止した場合に、ARR Affinity（＝セッションアフィニティ）を有効にしていると、そのインスタンスで通信していたリクエストのセッションが失われてしまいます。（ARR Affinityを無効にしていると、別のインスタンスに即座にリクエストが渡される？）
Pros:
- it’s easy– no app changes required.
- better utilizes local RAM caches (e.g. look up user profile once, cache it, and can re-use it on subsequent visits from same user)
Cons:
- if the server goes down, session is lost. (note that this is a con of storing session info locally on the web server– not of sticky sessions per se). if what’s in the session is really important to the user (e.g. a draft email) or to the site (e.g. a shopping cart) then losing one of your servers can be very painful.
- depending on “sticky” implementation in your load balancer, may direct unequal load to some servers vs. others
- bringing a new server online doesn’t immediately give the new server lots of load– if you have a dynamic load-balancing system to deal with spikes, stickiness may slow your ability to respond quickly to a spike. That said, this is somewhat of a corner case and really only applies to very large and sophisticated sites.
- if you have relatively few users but a single user’s traffic can swamp one server (e.g. complex pages with SSL, AJAX, dynamically-generated images, dynamic compression, etc.), then stickines may hurt end-user response time since you’re not spreading a single user’s load evenly across servers. If you have a lot of concurrent users, this is a non-issue since all your servers will be swamped!
こちらにも同じような議論がありましたのでご参考に。
App Service/Azure FunctionsにおけるARR Affirnityのプラクティス
では続いてApp Service / FunctionsにおけるARR Affirnityの構成プラクティスについても確認しておきます。基本的には上のセッションアフィニティのメリット・デメリットを受けてのことだと思いますが、以下、App Serviceの開発チームによるブログに言及されています。
https://azure.github.io/AppService/2020/05/15/Robust-Apps-for-the-cloud.html
ARR Affinity creates sticky sessions so that clients will connect to the same app instance on subsequent requests. However, ARR Affinity can cause unequal distribution of requests between your instances and possibly overload an instance. For production apps that are aiming to be robust, it is recommended to set Always on to On and ARR Affinity to Off. Disabling ARR Affinity assumes that your application is either stateless, or the session state is stored on a remote service such as a cache or database.
ARR Affirnityを有効化していると、通常動作時にリクエストが複数インスタンスに均等に分散されないため負荷が偏る可能性があり、運用環境では無効化することが推奨されています。
ただし、後半に書かれていますが、その前提としてアプリケーションがステートレス、またはステートフルだったとしてもリモートサービス（キャッシュやデータベース）にセッション情報を格納しているような構成である必要がある点には注意です。
ARR Affinityを実際に確認してみる
こちらは、かの有名な「しばやん」さんのブログにていろいろな実験がなされているようなので、ご参考にしていただければと思います。
ARR Affinityは、Cookieに「ARRAffinity」というキーで値を保持しているようです。
以上、ARR Affinityについて知りたかった基本的なことをまとめてみました。
本日も最後まで御覧いただきありがとうございました！なお、本記事が少しでもお役に立ちましたら、下のいいねボタンをポチって頂けると励みになります！
おしまい
Functionsを含むAzure App Serviceでは、このARR Affinityの有効/無効をボタン一つで切り替えることができます。便利です。
「構成」ブレード＞「全般設定」から。
Azure Functionsの場合、初版執筆時点では、既定ではオフの模様。
なお、App Serviceの場合は既定で有効のようです。