【Microsoft Azure】ARR Affinityについて理解する

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

ARR Affinityについては、例えばAzure FunctionsやApp Serviceの構成設定画面で設定できることを確認できます。

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の公式ページでは、以下のような説明があります。

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

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!

ARR Affinityの有効/無効を切り替える方法

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

Functionsの場合は「構成」ブレード>「全般設定」から。(現在、既定ではオフの模様)

App Serviceの場合も同様に「構成」ブレード>「全般設定」から設定可能です。(こちらは既定で有効のようです)

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

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

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

以上、ARR Affinityについて知りたかった基本的なことをまとめてみました。自分がこのあたりにもう少し詳しくなったらもう少し細かい疑問点がいろいろと湧いてきて、このページが充実していくかもしれません笑

本日も最後まで御覧いただきありがとうございました!

おしまい

この記事を気に入っていただけたらシェアをお願いします!

ABOUT US

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