부하 분산 설정에서 Redis Cache를 사용하여 Azure App Service에서 효율적인 세션 관리

기존 로드 밸런싱 환경의 세션

일반적으로 우리는 모든 웹 애플리케이션에서 메모리 내 세션(RAM에 저장된 데이터)을 사용합니다. 전용 VM이나 공유 호스팅 계획에서 애플리케이션을 호스팅하는 대부분의 기존 호스팅 환경에서 잘 작동합니다.

그러나 트래픽이 증가하면 여러 개의 웹 서버를 생성하고 Load Balancer를 사용하여 트래픽을 제어하여 로드 밸런싱을 계획합니다. 이러한 시나리오에서는 단일 세션과 관련된 요청이 여러 서버에서 처리되므로 세션이 작동하지 않습니다. 단일 세션의 요청을 처리하는 동일한 서버도 가능하지만 권장되지는 않습니다. 해결책은 부하 분산 환경의 모든 웹 서버에서 액세스할 수 있는 SQL Server에 세션을 저장하는 것입니다.

Azure 자동 크기 조정 환경의 세션

이에 대한 이론적인 논의 대신, 세션을 사용하는 작은 프로그램을 개발하여 실제적인 논의에 직접 뛰어들어 Azure에서 세션이 어떻게 작동하는지 살펴보겠습니다.

다음 웹 페이지를 사용하여 웹 사이트(MVC 응용 프로그램도 만들 수 있음)를 만들고 이전 기사 중 하나에 표시된 대로 응용 프로그램을 배포해 보겠습니다.

• Azure App Service - Visual Studio에서 기존 애플리케이션 구성

로그인.aspx

이 페이지에서는 사용자 이름과 비밀번호만 허용합니다. "로그인" 버튼을 클릭하면 세션을 생성하고 로그인한 사용자 이름의 값을 세션에 저장하고 사용자를 "Default.aspx"로 리디렉션합니다.

이 페이지에는 웹사이트가 호스팅되는 가상 머신의 IP 주소 "10.202.116.91"도 표시됩니다.

기본값.aspx

이 페이지에는 세션 값에 따라 다음 메시지가 표시됩니다.

세션에 어떤 값이 있으면 아래 화면 캡처와 같이 "관리자로 로그인한 사용자. 현재 10.202.116.91에 있습니다"라는 메시지가 표시됩니다.

세션에 값이 없으면 아래 화면 캡처와 같이 "Session is NULL. You are in 10.202.116.91"이 표시됩니다.

Login.aspx와 Default.aspx 모두에서 서버의 IPAddress가 동일하다는 점에 유의하십시오. 모든 요청이 동일한 서버로 리디렉션됩니다.

또한 아래 화면 캡처에 따라 세션은 "ASP.NET_SessionID"라는 쿠키를 사용하여 유지됩니다. 이는 우리 대부분에게 친숙할 것입니다.

웹사이트에 대한 트래픽이 증가했고 이를 두 개의 인스턴스로 확장하고 싶다고 가정해 보겠습니다. 계속해서 인스턴스 수를 2개로 늘리겠습니다.

참고: 무료 및 공유 계층에서는 인스턴스 수를 늘릴 수 없습니다. 귀하의 앱 서비스는 "기본", "표준" 또는 "프리미엄" 계층에 있어야 합니다.

다시 로그인 페이지에 액세스하고 페이지를 새로 고쳐 여러 번 액세스해 보겠습니다. 페이지를 여러 번 새로 고쳐도 IP 주소는 변경되지 않습니다.

동일한 웹 서버가 페이지를 제공하고 있음을 알 수 있습니다. 두 개의 인스턴스로 확장을 활성화했지만 App Service는 여전히 한 서버의 요청을 처리하고 있습니다.

로드 밸런싱이 활성화되어 있고 다른 서버가 제대로 활용되지 않는 경우에도 동일한 서버가 요청을 처리하고 있기 때문에 실제 시나리오에서는 문제가 될 수 있습니다.

모든 요청이 처리되는 이유는 아래와 같은 ARR 쿠키 때문입니다. 자세한 내용은 여기를 참조하세요.

간단히 말해서 이 쿠키에는 초기 요청이 처리된 서버 정보가 있으므로 동일한 세션의 모든 후속 요청은 동일한 VM에서 처리됩니다.

아래와 같이 App Service의 애플리케이션 설정으로 이동하여 ARR 쿠키 기능을 비활성화해 보겠습니다.

위 화면 캡처에 표시된 대로 "ARR Affinity"를 끄고 "저장" 버튼을 클릭하여 변경 사항을 저장합니다. 모든 세션을 지우려면 App Service를 다시 시작하세요.

앞으로는 조금 조심하시기 바랍니다. 다음 두 단락은 약간 혼란스럽습니다.

중요

ARR Affinity를 끄면 쿠키 ARRaffinity 쿠키 생성 프로세스가 비활성화됩니다. 따라서 쿠키가 비활성화되면 요청은 사용 가능한 서버 중 하나로 전송될 수 있습니다. 따라서 세션이 제대로 유지된다는 보장은 없습니다. 세션은 요청이 동일한 서버에서 제공되는 경우에만 작동합니다. 세션이 저장된 서버 대신 다른 서버에서 요청을 처리하는 경우 세션은 NULL이 됩니다.

이제 웹 앱으로 돌아와 로그인 페이지로 이동하여 새 IP 주소 "10.202.174.84"를 확인하세요. (귀하의 경우 처음에는 이전과 동일한 IP 주소가 표시될 수 있습니다. 페이지를 새로 고치면 IP 주소가 변경됩니다. 제 경우에는 아래와 같이 페이지를 두 번 새로 고쳐 새 IP 주소를 가져왔습니다.)

로그인 버튼을 클릭한다고 해서 양식이 10.202.174.84에 게시된다는 보장은 없습니다. 제 경우에는 "10.202.116.91"인 다른 서버에 데이터를 게시할 수도 있습니다.

제 경우에는 위 화면 캡처의 '로그인' 버튼을 클릭했을 때 다음 값이 포함된 기본 페이지로 이동했습니다.

• IP 주소는 10.202.174.84입니다(내 로그인 페이지에서도 동일함).
• 세션이 NULL입니다. 그 이유는 로그인을 클릭하면 요청이 내 세션이 저장된 다른 인스턴스('10.202.116.91')로 이동했을 수 있기 때문입니다.
• 페이지를 몇 번 새로 고치세요.
  

다음 사항을 준수하시기 바랍니다.

• 세션에는 "admin"이라는 값이 있습니다.
• IP주소는 10.202.116.91입니다.

따라서 여기서 결론은 자동 크기 조정 기능을 사용하여 Load Balancer를 구성하면 Azure App Service에서 "세션"이 예상대로 작동하지 않는다는 것입니다.

여기 구원자가 오십니다. Redis 캐시 공급자. 아래는 Azure 공식 웹사이트의 정의입니다.

Azure Redis Cache는 널리 사용되는 오픈 소스 Redis 캐시를 기반으로 합니다. 이를 통해 Microsoft에서 관리하고 Azure 내의 모든 애플리케이션에서 액세스할 수 있는 안전한 전용 Redis 캐시에 액세스할 수 있습니다.

다음은 세션이 예상대로 작동하도록 하는 데 필요한 단계입니다.

• Azure 관리 포털에서 Redis Cache를 생성합니다.
• Azure Redis Cache를 사용하도록 애플리케이션을 구성합니다.
• 세션을 사용하세요.

Azure 관리 포털에서 Redis Cache를 생성하세요.

아래와 같이 Azure 관리 포털을 사용하여 Redis Cache 생성을 시작해 보겠습니다.

아래와 같이 Redis Cache의 세부정보를 제공하세요.

위 화면 캡처의 “만들기” 버튼을 클릭하세요. Redis Cache를 생성하는 데 몇 분 정도 걸립니다.

Azure Redis Cache를 사용하도록 애플리케이션 구성

방금 생성한 Redis Cache를 사용하도록 애플리케이션을 구성해 보겠습니다.

위 화면 캡처와 같이 패키지 관리자 콘솔로 이동하여 “Install-Package StackExchange.Redis” 명령을 입력하고 “Enter”를 클릭하세요.

이제 필요한 패키지를 성공적으로 설치했습니다. (.NET 프레임워크는 4 이상이어야 합니다.)

어셈블리를 사용하려면 먼저 Login.aspx 페이지와 Default.aspx 페이지 모두에 다음 네임스페이스를 추가해야 합니다.

StackExchange.Redis 사용;

프로젝트에 "RedisConnection"이라는 새 클래스를 추가해 보겠습니다. 첨부된 프로젝트를 참조하시기 바랍니다.

Redis Cache에 연결하려면 ConnectionMultiplexer.Connect 함수에 다음 정보를 전달해야 합니다. 포털에서 가져오세요.

• Redis 캐시 URL.
• 열쇠.

코드에 키를 저장하지 마세요. 작업을 단순화하기 위해 소스 코드에 키를 저장합니다. 자격 증명을 저장하는 방법에 대한 정보를 제공하는 이 페이지를 참조하십시오.

이제 Redis Cache에 연결하는 데 사용할 수 있는 클래스가 준비되었습니다. 클래스를 사용하여 Redis Cache에 세션을 생성해 보겠습니다.

Login.aspx.cs 파일을 열고 다음 코드 줄을 바꾸세요.

Session["login"] = this.txtUsername.Text.Trim();

와.

IDatabase cache = RedisConnection.Connection.GetDatabase();
cache.StringSet("login", this.txtUsername.Text.Trim());

Default.aspx.cs를 열고 다음 코드 줄을 바꿉니다.

protected void Page_Load(object sender, EventArgs e)
{
 if (Session["login"] == null)
 {
 Response.Write("Session is NULL. You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
 else
 {
 Response.Write("Logged in user is " + Session["login"] + ". You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
}

와.

protected void Page_Load(object sender, EventArgs e)
{
 IDatabase cache = RedisConnection.Connection.GetDatabase();
 string strLoginValue = cache.StringGet("login");
 if (strLoginValue == null)
 {
 Response.Write("Session is NULL. You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
 else
 {
 Response.Write("Logged in user is " + strLoginValue + ". You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
}

Azure App Service에 코드를 배포하고 변경 사항을 검토한 후 아래와 같이 로그인 페이지로 이동해 보겠습니다.

IP 주소를 확인하세요. 10.202.174.84 입니다. 이제 “로그인” 버튼을 클릭하세요. 아래와 같이 Default.aspx 페이지로 이동하게 됩니다.

위 화면 캡처에서 IPAddress는 다르지만 세션이 이제 두 인스턴스 모두에서 액세스할 수 있는 분산 위치 "Redis Cache"에 저장되므로 사용자 이름 "admin"을 볼 수 있습니다.

이제 페이지를 여러 번 새로 고치세요. IP 주소는 변경되지만 사용자 이름 값은 변경되지 않음을 알 수 있습니다.

그게 다야. 로드 밸런싱 환경에서 세션을 저장하는 방법을 배웠습니다. Redis Cache에는 모든 종류의 데이터를 저장할 수 있습니다.

기사를 재미있게 읽으셨기를 바랍니다. 귀하의 의견은 정말 감사드립니다.