Real-World Windows Azure Development - SQL Azure에 대해 착각하면 안되는 것

Windows Azure Platform을 활용해봤던 경험이 있는 많은 사용자들이 클라우드에 대한 이상을 포기하게 되는 가장 큰 부분이 바로 SQL Azure의 현실적인 문제들입니다. 클라우드에 대해서 장밋빛 미래를 이야기하면서도 막상 SQL Azure는 우리가 생각하는 무제한의 와이드 서비스와는 사실 매우 거리가 멀다고 해야 할 것입니다. 오늘은 SQL Azure의 한계와 그 대처 방안들에 대하여 짚어보는 시간을 가지려고 합니다.

SQL Azure 데이터베이스는 여러분의 로컬 데이터베이스가 아닙니다.

SQL Azure 데이터베이스는 여러분의 로컬 데이터베이스가 아닙니다. 여기에는 상당히 많은 의미가 포함되어있는데, 그 중에서도 가장 첫 번째의 의미는 모든 것이 Microsoft의 관리 체계 아래에 놓여있다는 것입니다.

전통적으로 우리가 업무 중에 사용하는 데이터베이스는 정말 미세한 요소 하나하나에 영향을 받습니다. 같이 실행 중인 프로세스들, 하드 디스크의 입/출력 상태, 네트워크 회선 상태 등 Care해야 할 요소가 굉장히 많습니다. Mission Critical Application을 지원하는 데이터베이스라면 이러한 요소들로 인하여 승패가 갈릴 수도 있다는 의미가 되겠습니다.

Microsoft가 제시하는 클라우드 데이터베이스의 모습은 물론 SLA (Service Level Agreement)를 완벽히 준수하여 중단이 없고 항상 일정한 성능을 보장하는 것을 목표로 합니다. 그러나 우리는 이미 클라우드 기반 서비스들이 의외로, 정말 의도하지 않게 중단될 수도 있다는 것을 자주 접해왔고 인정하고 있습니다. Microsoft를 비롯하여 모든 클라우드 서비스 업체는 SLA를 최고 수준까지 보장할 수 있도록 노력한다는 것은 틀림이 없지만 그렇다고 해서 여러분의 Mission Critical Application을 지원할 수 있다는 것이 아님을 분명히 이해하고 있어야 합니다. 여러분의 Mission Critical Application은 단순히 서비스 가동률에 대한 것만이 아니라 운영 비용, 속도와 같은 부분에도 영향을 받을 것입니다.

SQL Azure 데이터베이스가 항상 인터넷 위에서 실행 중이라는 사실을 잊으면 안됩니다.

우리 나라에서도 유명했던 인터넷 대란 중에 SQL Server의 취약점을 대상으로 대규모로 유행했던 Worm Virus가 있었다는 것을 기억하시는 분들이 계실 것입니다. 방화벽의 필요성에 대한 인지도가 낮았을 뿐만 아니라 지금보다는 꽤 취약했던 것이 사실입니다. 물론 지금은 이런 문제점이 기본적인 보안 수준의 향상으로 상당히 개선된 것은 사실이지만 언제 어떤 형식으로 문제가 다시 도래할지는 아무도 장담하지 못합니다.

SQL Azure 데이터베이스는 기본적으로 인터넷 위에서 실행되는 데이터베이스입니다. 물론 보통의 SQL Server 연결때와 마찬가지로 암호화되지 않은 연결을 허용하는 것은 아닙니다. 오로지 암호화된 연결만을 사용할 수 있게 되어있습니다. 그러나 이것이 모든 보안 문제로부터의 완벽한 격리를 뜻하는 것은 아닙니다. 왜냐면, "인터넷 위에서 실행 중"이기 때문입니다. SQL Azure 데이터베이스로 연결을 하기 위해서 필요한 연결 문자열 안에는 서버의 주소, 사용자 계정 정보 등이 포함되는데, 필연적으로 서버의 주소는 인터넷 상의 호스트를 가리켜야 하므로 FQDN (Fully Qualified DNS Name)일 수 밖에 없으며 ID와 비밀 번호도 데이터베이스에 설정된 그대로를 이용할 수 밖에 없습니다. 즉, 연결 문자열의 보안에 관한 부분도 응용프로그램에서 관리하지 않으면 안된다는 의미입니다.

연결 문자열의 보호 수준은 전적으로 여러분이 실행하는 응용프로그램의 종류나 환경, 사용 조건에 맞게 관리되어야 합니다. 서버 응용프로그램이라고 해서 방심할 수 없는 것은, 규모가 큰 기업이거나, 서버 응용프로그램이 재배포 가능한 형태의 패키지인 경우도 포함이 되기 때문입니다.

그리고 SQL Azure에서의 방화벽 정책은 기본적으로 "아무도 연결할 수 없도록 만드는 것"이 최적의 설정입니다. 절대 "모두에게 연결을 허용하는 설정"은 존재하지 않으며 이를 위하여 IP 대역을 넓은 범위로 추가하는 일도 하면 안됩니다. 꼭 필요한 IP 주소만을 정확히 지정하여 관리하는 것이 필요합니다. 만약 불특정 다수에게 데이터베이스의 데이터를 제공해야 한다면 SQL Azure Labs에 있는 SQL Azure OData Services (http://www.sqlazurelabs.com/ConfigOData.aspx)를 검토하거나, 여러분의 IT 인프라 환경 내에 WCF 데이터 서비스를 이용하여 데이터를 제공할 수 있도록 해야 합니다.

SQL Azure 데이터베이스를 백업할 수 있을 것이라는 생각은 하지 않는게 좋습니다.

제목 그대로입니다. SQL Azure 데이터베이스는 백업할 수 있는 것이 아닙니다. 정확히 말하면, 백업을 할 수 있을 만큼 여러분의 예산이 충분한지 검토해야 하고, 백업이 가능한 수준의 데이터를 보관하고 있는 것인지를 묻는 것입니다. 백업을 위하여 소모되는 네트워크 트래픽의 비용은 생각보다 클 수 있으며, 백업을 위하여 시도하는 모든 행위들은, 특히 데이터베이스가 온라인인 상태에서 성능 상의 손해를 크게 입힐 수 있습니다. 그럼에도 불구하고, 불가피한 경우 백업을 할 수 있는 다양한 방안은 Microsoft에 의하여 제공됩니다. 하지만 Full Scan Backup 등은 꼭 필요한 경우가 아니면 택했을 때 문제가 될 수도 있습니다.

그렇다면 여러분의 데이터를 보호하기 위한 관점에서 취할 수 있는 다른 방안은 없을까요? 이 부분에 대해서는 데이터베이스 복제라는 기능을 이용하는 것으로 해결될 수 있습니다. 물론 복제된 데이터베이스에 대한 사용 및 운영 비용은 당연히 발생하지만, Full Scan Backup보다는 저렴하고 성능 상의 손해를 끼치지 않는 것이 가능합니다.

데이터베이스 복제는 같은 서버 내에서 서로 다른 데이터베이스로 하는 것, 그리고 서로 다른 서버 간에 데이터베이스를 복제하는 것 모두 지원되고, 모든 과정은 비동기로 이루어지며 모니터링이 가능합니다. 성능에 영향을 끼치지 않도록 성능 상태를 고려하여 데이터베이스 복제를 천천히 수행하는 경향이 있으며, 복제된 데이터베이스는 트랜잭션 상태가 일관성이 있도록 복제됩니다. 데이터베이스 복제에 대한 자세한 내용은 추후 강좌에서 소개할 수 있도록 하겠습니다.

SQL Azure는 공유 환경에서 실행되고, 용량 제한이 있습니다.

SQL Azure에 대해서 기술적으로 가장 많이 좌절하는 부분이 두 가지가 있습니다. 바로 공유 환경에서 실행된다는 특성과, 용량 제한이 있다는 설정입니다.

우선 공유 환경에서 실행되기 때문에 문제가 되는 것은, 여러분이 로컬 데이터베이스를 다루듯이 해프게 열어서 쓰던 데이터베이스 연결 패턴을 SQL Azure에 그대로 적용하려고 하면, 꽤 높은 확률로 SQL Azure로부터 접속이 차단되거나 예고없이 만들어진 연결이 끊어지는 것을 경험할 수 있습니다. 이는 다른 SQL Azure 사용자에게 성능 상의 손해를 입힐만한 여지가 있다고 판단하는 경우 자동으로 연결을 끊거나 차단하도록 정책 설정이 되어있기 때문입니다. 그래서 SQL Azure를 기존 응용프로그램의 데이터베이스로서 사용하려면 이러한 문제가 일어나지 않도록 연결 풀링을 더 강화해야 하며, 연결 문자열을 SQL Azure에 대해 완전히 하나로 통일할 수 있도록 노력하는 것이 좋습니다.

그리고 용량 제한이 있다는 사실을 기억해야 합니다. 1GB, 5GB, 10 ~ 50GB 사이에서 선택이 가능하며 이 이상의 데이터베이스는 지원되지 않습니다. 따라서, 단일 데이터베이스에 의존하여 데이터를 구축하도록 만드는 설계는 바람직하지 않습니다. 보통은 이러한 한계의 극복을 위해서 Windows Azure Table Storage로 기술을 바꾸거나, 다른 데이터베이스 클라우드를 택하는 경우가 있지만, SQL Azure에 최근에 Database Federation이 추가되어 이러한 불편을 최소화할 수 있게 되었습니다. Database Federation 도입 이전에는 Database Sharding 패턴을 적용하는 방법이 인기있었지만 이는 데이터베이스 관리자의 재량이 아닌 응용프로그램 개발자의 재능에 연관된 기술이었고 관리가 까다로운 문제가 있었습니다.

그럼에도 불구하고 SQL Azure가 필요한 이유

이러한 엄청난(?) 문제점들을 달고 있음에도 SQL Azure는 여러분의 훌륭한 클라우드 기반 데이터베이스 시스템입니다. 여러분이 SQL Azure 데이터베이스에 대해 가지고 있었던 환상이나 오해를 정확히 없애고, 정확한 목적과 계획을 두어 사용한다면 매력적일 수 있습니다.

SQL Azure를 트위터나 페이스북과 같은 I/O가 빈번한 소셜 네트워크 서비스에 대한 데이터베이스로 보는 것은 피해야 합니다. 대신, 참조되는 빈도가 많은 통계형 자료를 보관하는 용도나, 로컬 서버에서 처리하기에 부담스러운 데이터베이스 수준에서의 JOIN 연산 작업들을 수행하기 위한 용도, 혹은 글로벌 데이터베이스로서 지리적으로 멀리 떨어져있는 클라이언트와 데이터를 원활하게 공유할 수 있도록 브랜치 데이터베이스를 만드는 등의 용도로 활용하는 것이 SQL Azure의 정확한 용도가 될 것입니다.

SQL Azure에 대한 더 나은 비전과 활용 방안은 앞으로 SQL Azure에 추가될 업데이트를 통하여 새롭게 발굴될 수 있습니다. 그리고 SQL Server의 차기 버전인 Codename: Denali를 통하여 하이브리드 데이터베이스 구축이 좀 더 완벽한 형태로 만들어질 수도 있을 것입니다.