애저 로드밸런서

클라우드 컴퓨팅이 이제 확실하게 대세로 자리잡은 모양이다. 업종을 막론하고 클라우드 컴퓨팅에 대한 논의가 활발하고, 실 서비스를 Windows Azure Platform (이하 애저) 환경에서 제공하고자 PoC 및 실제 개발이 진행되는 사례가 늘고 있다. 다양한 업종의 사람들과 만나 애저 적용을 논의하는 과정에서 생겨나는 문제점이나 이슈를 해결하는 과정에서 알게된 것들을 정리하고자 한다.

마이크로소프트가 클라우드 플랫폼으로서 시장에서 판매하고 있는애저는 개발자나 사용자가 제어하거나 심지어 감지할 수 없지만, 내부적으로 로드 밸런서가 내장되어 있다. 이를 통해 개발자들이 클라우드 플랫폼에 기대하는, 부하 폭주시 대처할 수 있는 확장성이나 부하에 따라서 서비스 인프라를 조절하여 비용을 절감할 수 있는 인프라의 탄력성을 제공하게 된다. 바로 이러한 성격 때문에 플랫폼으로서의 애저는 약간의 제약이 존재하게 된다.

애저는 크게 Windows Azure와 SQL Azure로 구분할 수 있는데, 각각 로드 밸런서가 내장되어 있다. 아래는 Windows Azure에 내장되어 있는 로드 밸런서의 동작 방식을 보여주는 그림이다. 사용자는 Web Role로 사용할 Windows Azure Compute Large (CPU 4 core) 타입 3개를 신청하여 사용 중이며, 이때 애저 내부에서는 아래와 같은 모습으로 사용자의 로지컬 서버가 배치된다. 그림에서 보듯이 Rack Switch를 공유하지 않는 세 곳의 서버에 4 Core VM을 각각 생성하여, 서비스 업데이트 혹은 VM OS 업데이트시에도, 또는 장애 발생시에도 심지어 랙 전체가 장애를 일으키는 경우에도 사용자의 서비스를 유지될 수 있도록 설계 되어 있으며, 이들에게 할당된 IP가 전면에 위치한 로드 밸런서에 등록되어 관리된다.

   

일반적으로 클라우드에 적합한 비즈니스 시나리오가 4가지 있다는 점은 수많은 매체에서도 언급되어서 생략하기로 하고 그러한 시나리오가 제대로 클라우드의 장점을 활용하기 위해서는 클라우드 사업자가 제공하는 서비스의 특징을 파악할 필요가 있다. Windows Azure의 경우 Stateless한 애플리케이션에게 최상의 확장성을 보장할 수 있는 구조이며, 따라서 Web Role이든 Worker Role이든 상태 관리가 필요없는 경우에 가장 유연하게 서비스를 활용할 수 있다. 즉, 같은 사용자가 Windows Azure 상의 서비스를 호출시 이전 호출의 결과에 상관없이 서비스가 유지될 수 있는 그런 타입의 Stateless한 애플리케이션이 가장 적합하다는 것이다.

이를 위해서 Windows Azure는 로드 밸런스의 TCP 타임 아웃을 1분으로 제한하고 있다. 즉 1분이상 TCP 커넥션을 맺어야 하는 상황에서 Windows Azure의 로드밸런서는 이를 자동으로 끊어버린다. 따라서 사용자의 호출이 1분 이상 소요되어 값을 리턴하고자하는 경우 에러가 발생하고, 1분 이상 TCP 소켓을 열어 놓으면 서버쪽에서 자동으로 끊기게 된다. 이는 일반적인 웹 애플리케이션에 가장 적합한 운영 환경이라 할 수 있다. Windows Azure에 내장되어 있는 로드밸런서의 부하 분산 알고리즘은 순차적인 Round Robin 방식이다. (Sticky Round Robin이나 Weighted Round Robin을 지원하지 않는다.)

그럼, 상태를 관리해야 하는 경우는 Windows Azure를 사용하지 않아야 할까 ? 이 부분에 대해서는 다음에 논의하기로 하고 SQL Azure에 내장되어 있는 로드 밸런서에 대해 살펴보자.

SQL Azure 내장 로드 밸런서는 아래 그림에서와 같이 Windows Azure와 달리 Sticky 세션을 지원하며 TCP 타임 아웃도 30분이다. 즉 30분 동안 세션을 끊지 않는다. 하지만, 여전히 주의해야 할 사항이 있다.

먼저, 개발 언어를 막론하고 데이터베이스 접근은 대부분 커넥션 풀을 사용한다. 닷넷의 경우 ADO.NET을 통해 기본적으로 제공되는 커넥션 풀을 이용하는데, 이 경우 미리 물리적으로 데이터베이스에 연결을 갖고 있는 커넥션들이 30분 이후에는 서버에서 일방적으로 커넥션이 종료된다. 실제 커넥션을 끊겼지만 커넥션 풀에 들어 있는 커넥션 객체를 애플리케이션이 얻어 쓰려고 하면 당연히 에러가 발생하게 된다. 따라서 이를 회피하기 위해서는 에러 발생시 다시 커넥션을 얻는 시도를 하는 로직을 삽입하는 것이 바람직하다.

또한 SQL Azure에 접근하는 클라이언트가 Windows Azure에 위치할 경우 다른 이슈가 발생할 수 있다. 즉, Windows Azure 의 TCP 타임 아웃이 1분이기에 1분이 경과하면 커넥션이 종료되는 현상을 보고하고 있다. Windows Azure와 SQL Azure를 함께 사용하는 대부분의 경우에 물리적으로 같은 데이터센터에 위치하는 경우가 많아서 크게 1분 이상의 응답이 걸리는 호출이 많지 않을 것이라고 판단은 되지만, 이를 회피하고자 한다면 TCP Keep Alive 옵션을 설정하는 것이 바람직하다.

어느 경우에는 TCP 커넥션을 Idle한 상태에 두지 않는 방안을 강구하라고 조언하기도 한다.

자바의 경우 지난 포스팅에서 JDBC 드라이버를 소개했는데, 이 드라이버를 설치하고 나면 release.txt를 볼 수 있다. 여기에 커넥션 타임 아웃 관련하여 아래와 같은 구문이 있으니, 눈여겨 볼 필요가 있다.

<<KNOWN ISSUES
------------
The following are known issues with the Microsoft SQL Server JDBC Driver 3.0: 
1) PARAMETER METADATA LIMITATIONS WITH THE SQL MERGE STATEMENT 
PreparedStatement.getParameterMetadata() throws an SQLException when used with a parameterized MERGE query.
2) LIMITATIONS OF SSL WITH SQL AZURE 
The hostNameInCertificate connection property must be used to validate an SSL certificate against SQL Azure. 
3) LIMITATIONS OF USERNAME WITH SQL AZURE 
When connecting to SQL Azure, the user name should be specified in the format username@servername.    
4) LIMITATIONS OF DATABASE NAME WITH SQL AZURE 
if you connect to SQL Azure and specify an invalid database name, SQL Azure may block the client application for 5 minutes. 
5) CONNECTION DROPPING WITH SQL AZURE 
When connecting to SQL Azure, idle connections may be terminated by a network component (such as a firewall) after a period of inactivity. To avoid dropping idle connections by a network component, the following registry settings (or their non-Windows equivalents) should be set on the operating system where the driver is loaded:             

           Registry Setting                                                                     Recommended value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime                 30000      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval             1000 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxDataRetransmission      10
>>

참고로 SQL Azure의 내부 동작 방식에 관해서는 이전 포스팅을 참고하길 바란다. 특히 13번 Throttling 관련한 사항은 성능 테스트시 뜻하지 않는 에러의 원인이 될 수 있다.