[끄적끄적] SQL Azure에서 연결 끊기는 경우

SQL Server 2008로 구현된 클라우드 기반 RDB 서비스인 SQL Azure는 분산 데이터베이스로서 다수의 사용자가 물리적 서버를 공유하는 multi-tenant 구조를 가지고 있다. 따라서 공유하는 물리적 서버 자원을 한 사용자가 독점하여 다른 사용자의 데이터베이스 성능에 지장을 주지 못하도록 모니터링하며 필요에 따라서는 데이터베이스 연결 자체를 끊는다. 이러한 SQL Azure의 Throttling에 관해 공개된 정보가 있어 소개하고자 한다.

SQL Azure가 데이터베이스 연결을 끊는 경우는 아래와 같다.

• 한 세션이 1백만개 이상의 lock을 사용할 때..
• 로그 크기 1GB 이상 넘어가는 트랜잭션..
• 로그 파일 기준으로, 커밋 안된 트랜잭션과 현재 트랜잭션 사이의 길이가 전체 로그의 20%를 넘는 트랜잭션.. (장기 트랜잭션)
• 시스템 운영에 필요한 리소스를 20초 이상 잡고 있는 트랜잭션..
• TempDB의 크기가 5GB를 넘는 트랜잭션..
• 3번과 비슷한데, 메모리 경합(Memory contention) 발생시, 메모리 16GB 이상을 20초 이상 잡고 있는 세션들이 있으면, 가장 오래된 세션부터 차례로..
• SQL Azure 구독시 신청한 데이터테이스 크기를 초과할 경우, 요청된 Update/Insert 트랜잭션.. (ALTER DATABASE 명령으로 크기 변경 가능)
• 데이터베이스 연결이 30분간 IDLE 상태인 경우 해당 데이터테이스 연결.. (커넥션 풀에 있을지라도)
• 24시간 이상 경과하는 모든 트랜잭션..
• DoS 방지 차원에서 같은 IP 주소로부터 반복되는 로그 실패 명령시 해당 IP 차단..
• 한 머신 기준으로 CPU 사용량, IO 반응속도, 활성화된 worker의 수가 정해진 수를 초과할 때.. (busy worker 숫자 현재 300개로 세팅)

위의 여러 상황 가운데, 어느 경우에는 전혀 에러를 발생치 않는 경우도 있지만, 에러를 발생하는 많은 경우에는 서로 다른 에러 코드를 제공하기 때문에 SQL Server에 대한 지식이 있다면 쉽게 에러를 알아낼 수 있다. 아울러 모니터링 기능이나 쿼리를 통해서 현재 상황을 알아내는 것도 가능하다.

에러 상황을 회피하기 위해 개발자가 할 수 있는 방법은 방어적인 프로그래밍이며, 이 글에 언급된 사항에 대한 좀 더 상세한 설명이나 대처 방법, 코드 및 라이브러리에 대한 사항은 아래 원문을 참고하면 좋을 듯 하다.

SQL Azure : Connection Management in SQL Azure