【Microsoft Azure】ARR Affinityを分かりやすく解説する。構成のプラクティスは?

こんばんは。今日は、Microsoft Azureで登場するARR Affinity (ARRアフィニティ)について理解を深めたいと思います。

ARR Affinityは、例えばAzure Functionsを含むAzure App Serviceの構成設定画面で登場します。

ARR Affirnityとは何か?

まず、言葉の定義と意味を確認しておきましょう。

ARR AffirnityはApplication Request Routing Affinityの略になります。

Affinityは日本語で「親和性」「類似性」という意味があり、転じて、リクエストがクライアントからサイトに入ったときに、それ以降のすべてのリクエストが、アクセスされた最初のクライアントリクエストと同じサーバーに送られるようにする仕組みの名称となっています。

別名、Sticky Session (スティッキーセッション)とも呼ばれる概念です。

また、ARR Affinityの「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

ということで、ARR Affinityという言葉は、Azureのセッション管理の仕組みを表す、Azure特有の用語として使われているようです。

Microsoft Azure – App Serviceの公式ドキュメントでは、ARR Affirnityについて以下のような説明があります。

マルチインスタンス デプロイでは、クライアントがセッションの有効期間を通して同じインスタンスにルーティングされることを確認してください。 ステートレス アプリケーションの場合は、このオプションを [オフ] に設定できます。

https://docs.microsoft.com/ja-jp/azure/app-service/configure-common

機械翻訳で日本語がぎこちないですが、要は、App ServiceやFunctionsで複数のインスタンス(VM)を稼働させているとき、クライアントがセッションの期間中、同一のインスタンス(VM)にリクエストを送り続けることができるようにするための仕組みということです。

詳細は、こちらの記事がとても詳しく分かりやすく書かれていたので、おススメです。

ARR Affinityを使うメリット・デメリット

これはこちらのStack Overflowに良い回答がありました。ARR Affinityに限らず一般的なセッションアフィニティのメリット・デメリットになります。

https://stackoverflow.com/questions/1553645/pros-and-cons-of-sticky-session-session-affinity-load-blancing-strategy

以下、抜粋です。複数のインスタンスで負荷分散している状況で、1つのインスタンスが停止した場合に、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!

こちらにも同じような議論がありましたのでご参考に。

https://docs.microsoft.com/en-us/answers/questions/39015/azure-app-service-arr-affinity-auto-scaling-statef.html

Azure App ServiceにおけるARR Affirnity

ではAzure App Serviceにおいて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を有効化していると、通常動作時にリクエストが複数インスタンスに均等に分散されないため負荷が偏る可能性があり、運用環境では無効化することが推奨されています。

ただし、後半に書かれていますが、その前提としてアプリケーションがステートレス、またはステートフルだったとしてもリモートサービス(キャッシュやデータベース)にセッション情報を格納しているような構成である必要がある点には注意です。

Azure App ServiceでARR Affinityの有効/無効を切り替える方法

Functionsを含むAzure App Serviceでは、このARR Affinityの有効/無効をボタン一つで切り替えることができます。便利です。

「構成」ブレード>「全般設定」から。

Azure Functionsの場合、初版執筆時点では、既定ではオフの模様。

なお、App Serviceの場合は既定で有効のようです。

ARR Affinityを実際に確認してみる

こちらは、かの有名な「しばやん」さんのブログにていろいろな実験がなされているようなので、ご参考にしていただければと思います。

ARR Affinityは、Cookieに「ARRAffinity」というキーで値を保持しているようです。

以上、ARR Affinityについて知りたかった基本的なことをまとめてみました。

本日も最後まで御覧いただきありがとうございました!なお、本記事が少しでもお役に立ちましたら、下のいいねボタンをポチって頂けると励みになります!

おしまい

この記事を気に入っていただけたらシェアをお願いします!
ABOUT US
Yuu113
初めまして。ゆうたろうと申します。 兵庫県出身、東京でシステムエンジニアをしております。現在は主にデータ分析、機械学習を活用してビジネスモデリングに取り組んでいます。 日々学んだことや経験したことを整理していきたいと思い、ブログを始めました。旅行、カメラ、IT技術、江戸文化が大好きですので、これらについても記事にしていきたいと思っています。