1월 31일 Azure CDN 팀에서 23번째 Azure CDN 노드를 모스크바에 개설하고 즉시 서비스에 들어갔다. 국내 글로벌 서비스 고객 가운데는 중앙 아시아를 커버할 수 있는 CDN 노드에 대한 요구가 있었는데, 이로써 어느 정도 해소되지 않을까 기대해 본다. 23개의 CDN 노드 위치는 아래와 같다.

* 미국
Ashburn, VA
Bay Area, CA
Chicago, IL
San Antonio, TX
Los Angeles, CA
Miami, FL
Newark, NJ
Seattle, WA

* 유럽
Amsterdam, NL
Dublin, IE
London, GB
Moscow, RU
Paris, FR
Stockholm, SE
Vienna, AT
Zurich, CH

* 아시아
Hong Kong, HK
Sao Paulo, BR
Seoul, KR
Singapore, SG
Sydney, AU
Taipei, TW
Tokyo, JP

Windows Azure Team 공식 블로그 바로가기

Posted by 장현춘

마이크로소프트의 Windows Azure Platform을 사용하기 위해서 Live ID가 필수이며, 모든 빌링은 이 계정 기반으로 청구가 된다. 하나의 계정을 통해 Windows Azure, SQL Azure, AppFabric 등 다양한 서비스를 Subscription할 수 있으며, SQL Azure인 경우 몇 가지 주의 사항이 있어서 두서 없이 정리하고자 한다.

1. 하나의 계정으로 다수의 SQL Azure를 Subscription할 수 있다.
2. 하나의 Subscription에는 하나의 SQL Azure Server만 생성할 수 있다.
3. 하나의 SQL Azure Server에는 최대 150개의 SQL Azure database를 생성할 수 있다. (master database는 필수이므로 사용자는 149개의 database를 생성할 수 있다.)
4. database 생성시 MAXSIZE로 지정한 한계에 다다르면 더 이상의 insert, update 등 실행시 에러를 발생시킨다. 하지만, read, truncate, drop 등은 가능하며, 공간 확보 후 insert, update 등은 약 15분 가량 후에 시도하여야 한다.
5. 이전과 다르게 이제는 SQL Azure database를 생성한 이후에, database 이름, database 크기, database 에디션을 변경할 수 있다.
ALTER DATABASE database_name
{
MODIFY NAME = new_database_name
|MODIFY (MAXSIZE = {1 | 5 | 10 | 20 | 30 | 40 | 50} GB)
|MODIFY (EDITION = {'web' | 'business'})
}
6. SQL Azure는 database 단위로 과금이 되고 날마다 요금 계산이 이루어져 매달 청구가 되는 구조로 되어 있다. 즉, 하루에 같은 이름의 database를 만들고 삭제하고 또 만들고 삭제하고 반복하면 만들 때마다 에디션에 따라 요금이 계산되어 한달 후에 청구가 된다. 즉, 같은 이름의 database일지라도 하루에 여러 번 만들면 궁극적으로 남은 건 하나의 database일지라도 요금은 만들 때마다 추가됨을 명심하자.
7. 현재 버전의 SQL Azure에서 cross-database 쿼리를 지원하지 않으며 USE (database) 명령어를 지원하지 않는다.
8. SQL Azure 구독시 사용자가 만든 database는 한 벌의 primary, 두 벌의 secondary replica로 복제되어 하나의 Azure 데이터센터 내에서 (Geolocation) 물리적으로 다른 세 대의 서버에, 세 개의 SQL Server database에 각각 분산되어 저장된다. SQL Azure Server란 이러한 분산 데이터베이스의 논리적인 묶음을 의미한다. 모든 사용자의 활동 등 가령, 읽고 쓰는 작업은 모두 Primary replica에서 발생하고, 나머지 secondary replica에 비동기로 싱크된다. 아래 그림에서 화살표가 있는 것은 사용자가 만든 Primary replica이며, 같은 색깔의 화살표가 없는 database가 바로 secondary replica를 의미한다. 만약 USE 명령을 허용한다면, USE를 써서 database를 바꾸는 순간 원하는 database가 물리적으로 다른 서버에 있을 가능성이 있기 때문에 그곳으로 연결이 재설정되어야 한다. 따라서 SQL Azure에서 USE를 허용하지 않는다.

9. SQL Azure는 대규모 data node로 구성된 분산 시스템으로 SQL Server 기반으로 구성되어 있으며, 각 data node는 하나의 SQL Server 인스턴스가 구동된다. 이 SQL Server 인스턴스에는 하나의 커다란 데이터테이스가 존재하는데, 이는 다시 650개의 파티션으로 구분되고, 아래 그림에서 처럼 각 파티션에는 SQL Azure에서 사용자가 생성한 primary replica 혹은 secondary replica가 하나씩 배정된다.  하나의 data node에 호스팅되는 650개의 파티션은 하나의 로그 파일을 공유한다.

10. SQL Azure에서 commit은 quorum commit 정책을 따른다. 즉, 모든 사용자의 읽고 쓰는 활동은 primary replica에 이루어지며 트랜잭션 커밋을 결정할 때는 primary replica와 적어도 하나의 secondary replica가 트랜잭션 로그가 정상적으로 기록되었다는 것을 보장해야만 트랜잭션이 commit된다. (거의 실시간으로 2PC가 이루어진다는 것인지... HA를 위해서 최소 두 개 머신에 로그를 남기는 것은 알겠는데, 실시간 2PC라면 부하가 만만치 않을 듯....)
11. 2010년 11월 기준 SQL Azure의 data node에 사용되는 서버 사양은 32GB RAM, 8 cores, 12 disks 으로 약 $3,500 짜리 중간 정도의 성능을 가진 머신으로 구성되어 있으며, 이는 Windows Azure에 사용되는 머신과 동일하여 서로 호환된다.
12. 고장된 하드웨어를 다른 것으로 교체하면서 그 안에 들어 있는 수많은 replica를 다른 머신에 살려내는 작업을 Reconfiguration이라고 하는데, 이를 위해 노드에 문제가 발생했다는 사실을 감지하는 체계가 있다. SQL Azure에 저장되는 사용자의 데이터는 한 개의 primary replica와 두 개의 secondary replica로 복제되는 데, HA를 위해서 이들 세 replica는 모두 서로 rack 스위치를 공유하지 않는 머신에 할당된다. 더 나아가 노드의 문제 발생을 감지하기 위해서 주변의 여섯 노드들이 서로를 감시하도록 되어 있는데, 이들 역시 rack 스위치를 공유하지 않도록 설계되어 있다. 즉, 특정 노드에서 문제가 발생할 시 주변 여섯 노드 (Neighbor) 중 어떤 것이라도 문제 발생을 보고하게 되며 이때 Partition Manager가 개입되어 해당 노드에 저장되어 있는 사용자의 replica들을 하나 하나 살려내는 작업이 진행된다. (하나 노드에 최대 650개의 파티션이 있으니, 작업량을 추측할 수 있다.)
13. SQL Azure는 HA를 위해 두 가지 기능을 제공한다. 하나는 Engine Throttling이며, 다른 하나는 Load Balancer이다. Throttling을 통해 SQL Azure는 하나의  SQL Server에 들어있는 수많은 replica들이 하나의 SQL Server 자원을 효율적으로 활용할 수 있도록 제한을 둔다. Engine Throttling 기능은 각 replica가 사용하는 로그 사이즈, 로깅 시간, CPU 사용률, 물리적인 database 사이즈 제한 등을 모니터링하게 된다. 특정 replica가 이 제한을 넘어서게 되면, 리소스를 공유하는 다른 replica를 위해 해당 replica의 읽기, 쓰기 접근을 10초간 거부한다.
14. SQL Azure의 디폴트 Isolation Level은 SQL Server와 마찬가지로 READ_COMMITTED이다. 또한, READ_COMMITTED_SANPSHOT과 ALLOW_SNAPSHOT_ISOLATION 옵션을 허락함으로써 SQL Azure는 READ_COMMITTED with Optimistic Concurrency가 디폴트 값으로 지정되어 있다. SQL Server의 디폴트 값인 READ_COMMITTED with Pessimistic Concurrency로 변경은 불가능하다. Isolation Level 변경은 커넥션에 대해 SET TRANSACTION ISOLATION LEVEL 명령을 통해 가능하다.

좀 더 상세한 정보는 아래 원문에서 확인할 수 있다.
http://social.technet.microsoft.com/wiki/contents/articles/inside-sql-azure.aspx


기타 아래 정보도 한번쯤 둘러볼 필요가 있다.
SQL Azure에서 지원하지 않는 SQL Server 기능들 : http://msdn.microsoft.com/en-us/library/ff394115(v=MSDN.10).aspx
SQL Azure 보안 가이드라인 : http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=4322517e-9d80-4ad3-8a75-bf0a10aa64d9

Posted by 장현춘

마이크로소프트의 Public cloud 솔루션인 Windows Azure platform은 현재 전세계 41개국에 출시되었지만 한국에는 아직 정식 출시되지는 않았다. 하지만, Public cloud 솔루션을 고민하는 많은 국내 기업에서 Windows Azure platform에 대한 관심이 그 어느 때보다 높고 실제 POC가 활발히 진행 중이다.
기업이 클라우드의 도입을 검토하게 되면, 먼저 기업내 수많은 시스템 가운데 클라우드로의 이행이 용이한 것과 어려운 것을 찾아내고 가급적 쉽게 이행 가능한 부분에 적용을 결정하게 된다. 이행이 결정된 시스템은 POC를 수행하기 위해 적절한 범위를 선정하고 적용 가능한 클라우드 솔루션 및 서비스를 검토한다. 검토를 통해 선정된 클라우드 솔루션은 POC 과정을 통해 기업이 갖춘 인프라와 기업이 가져다 쓰는 3rd party 솔루션, 가용한 인적 자원 등의 제약 사항 등의 영향을 감안하면서 진행하고 향후 적용 및 확산에 대한 실마리를 찾아낸다. POC라는 과정은 일반적으로 전체 시스템을 관통하는 아키텍처 관점에서 대단한 중요한 시니리오를 선정하여 진행하는 것이 바람직하며 여기에는 비기능적인 요구 사항도 포함된다. 성공적인 POC 이후에는 상부의 sponsorship을 얻기 위한 보고서 작성이 수반되고 여기에는 클라우드 도입의 가장 큰 이유 가운데 하나인 비용 절감 효과를 기술하게 된다.
하지만, 클라우드 기반의 시스템이 취하는 과금 방식이 예전 시스템 운영 방식과는 너무 다르고, 과금되는 요소들이 세분화되다 보니 고객이 예상되는 비용을 산정하는 것이 쉽지만은 않다. 하여, 많은 클라우드 사업자들이 예상 비용 산출 툴을 제공하거나 이를 전문적으로 제공하는 서비스가 출현하기에 이르렀다. 마이크로소프트의 Windows Azure platform의 공식 싸이트에서도 예상 비용 산정 툴이 제공되지만, POC를 진행하는 고객들은 여전히 어려움을 겪고 있어서 이에 대한 정리를 해 보기로 한다.

일반적인 웹 기반 애플리케이션을 Windows Azure platform에서 구현하고자 할 때 어떤 요소들이 사용되고 어떻게 과금되는 지를 알아보기 위해 가장 일반적인 애플리케이션 형태를 상정해보자. 즉, 사용자와의 인터페이스를 담당하는 웹 애플리케이션이 존재하고, 배치 작업 등을 위한 별도의 백엔드 애플리케이션이 돌고 있고, 이 둘 사이에 필요에 따라서 메시지 기반의 비동기 전송 방식(큐)을 통해 통신을 하고, 처리 결과 등은 RDB에 저장되며, 로깅이나 정적 데이터를 저장하는 용도의 blob 저장소가 존재하며, 정적 데이터의 빠른 전송을 위해 CDN 서비스를 사용하고 있다고 상정해보자.  이를 Windows Azure Platform에 올리게 되면 아래 그림과 같은 Azure의 서비스를 사용하게 된다. 이때 청구되는 비용을 따져보자.
청구되는 항목은 위 그림 순서대로 살펴보면
1. 데이터센터를 들고 나는 데이터 양에 대해, 1GB 당 센터로 유입되는 경우 0.10$, 센터에서 나가는 데이터에 대해 1GB당 0.15$ (아시아의 경우 0.20$)가 과금된다.
2. Windows Azure Compute : 위 그림에서 웹 애플리케이션을 위한 Web Role 2개, 배치 작업을 구현한 Worker Role 2개를 사용한다. 따라서 비용은 Small Instance 기준으로 한다면, 0.12$ (시간당 단가) x 24 (시간) x 30 (일) x 4 (개) 만큼 과금된다.
3. Windows Azure Storage : 위 그림에서 Windows Azure Storage Queue와 Windows Azure Storage Blob을 사용하고 있는데, Windows Azure Storage는 두 가지 관점에서 과금된다. 첫째 과금 기준은 사용하는 데이터 양인데, 한달 기준으로 과금되며 한달 평균 사용량에 대해 과금한다. 한달 평균 사용량 측정은 매시간 가장 많이 측정된 수치를 기록하였다가 이를 더하여 한달 평균 시간 (730시간)으로 나누어 1GB 당 0.15$가 과금된다.
4. Windows Azure Storage의 두번째 과금 기준은 Windows Azure Storage에 대한 트랜잭션 양이다. 즉, Storage에 대해 읽고 쓰고 하는 모든 활동에 대해 10,000건당 0.01$가 추가 과금된다.
5. SQL Azure : SQL Azure는 비교적 명쾌하게 비용을 예상할 수 있다. 두 개 에디션 총 7개 종류에 대해 한달 사용료가 정해져있다. 가장 작은 Web Edition의 1GB 짜리 한달 사용료가 9.99$이며, 가장 큰 Business Edition의 50GB 짜리 한달 사용료가 499.95$이다.
6. CDN Transaction : CDN의 경우에도 Windows Azure Storage에서와 마찬가지로 CDN이 처리하는 모든 요청에 대해 10,000건당 0.01$가 과금된다.
7. CDN Data Transfer : CDN 서비스를 통해 전달되는 데이터 양에 대해 1GB당 미국과 유럽은 0.15$, 아시아는 0.20$가 과금된다.

물론, 위에서 언급되지 않은 Windows Azure AppFabric의 서비스를 사용하게 되면 해당 서비스 별로 추가 과금된다.

Posted by 장현춘

Windows Azure Platform에 추가된 기능 중에서 실제 현업 개발자들이 자주 질문하는 것으로 Windows Azure 인스턴스에 대해 원격 접속 기능을 통해 접근 가능하다고 하는 이에 대해 알려 달라는 것이다. 특히 VM Role을 선보이면서 기존 개발 환경을 클라우드로 확장할 수 있는 가능성을 열어 주다 보니, 개발자들이 흔히 하고 있는 원격 접속 기능을 써서 Windows Azure내의 인스턴스에 접근하고 싶어하는 것은 당연한 일일 것이다.

원격 접속을 가능하게 하는 방법을 알아보자.
1. 여느 애플리케이션처럼 Web Role을 하나 만들자

2. 로컬에서 테스팅이 끝난 이 Web Role을 클라우드로 Publish하자. 이때 설정할 것들이 있다. 기본적으로 Visual Studio에서 Windows Azure Management Portal에 곧바로 Publish하기 위해서는 인증서 설치가 필요하다. 이 과정은 이 글과 직접 관련이 없으므로 여기서는 생략하기로 한다. (Visual Stuido에서 하라는 대로 따라하여 생성한 인증서를 Windows Azure Management Portal에 등록하는 것까지 마쳤다고 가정한다.) 그런 후 모습은 아래와 같다.

3. Publish를 위한 “Deploy Windows Azure Project” 팝업 화면 아래 부분에 "Configure Remote Desktop connections…”라는 링크를 클릭한다. 새로 뜨는 팝업 "Remote Desktop Configuration"의 “Enable connections for all roles”를 선택하여 화면을 enable시킨다.
  
콤보박스에서 <Create…>를 선택하여 필요한 정보를 기입한다. Account expiration date을 지정하게 되어 있음을 알 수 있고, 이로써 원격 접속을 써서 Windows Azure 인스턴스를 접속하는 기능을 항상 열어 놓고 쓰는 것을 추천하지 않음을 알 수 있다.
 
4. 이로써 인증서가 생성되어 PC에 저장되었으며, 다음 단계는 이 인증서를 Windows Azure Management Portal에 등록하는 것이다. 이를 위해 생성한 인증서를 저장소로부터 export하는 작업이 선행되어야 하는데, 두 가지 방법이 있다.
첫번째 방법은, 위 화면에서 OK를 눌러 화면을 닫기 전에, 콤보박스 옆의 “View” 버튼을 클릭한다. 인증서 팝업의 “Details” 탭에서 “Copy to File…” 버튼을 클릭여 “Certificate Export Wizard”를 실행시킨다.
  
두번째 방법으로는, 윈도우의 시작—>실행창에서 certmgr.msc를 실행시키면 아래와 같은 인증서 관리 화면이 뜬다. 여기서 “Personal –> Certificates”에서 방금 생성한 인증서를 마우스 오른쪽 버튼 클릭으로 export하면 위와 동일한 “Certificate Export Wizard”가 실행됨을 알 수 있다.

”Certificate Export Wizard” 실행화면에서 계속을 선택하면 Private Key를 함께 export할지를 결정하는 화면이 나오는데, 여기서 private key를 함께 export하도록 선택한다. 이어지는 화면에서 자동 선택되어 있는 PFX 포맷을 그대로 선택하고 다음을 누른다.

패스워드와 인증서 사본을 저장할 위치를 입력하면 인증서 저장이 끝나게 된다.

5. 이제, 저장된 인증서를 Winows Azure Management Portal에 등록하는 과정이 필요하다. 이 인증서를 아래 그림에서 보듯이 내가 만든 애플리케이션이 deploy될 “Hosted Services” 밑에 “Certificate”에 저장하여야 한다. 아래 그림의 좌측 메인 메뉴 중에 있는 “Management Certificates” 항목은 위에서 잠시 언급한 Visual Studio에서 직접 deploy하기 위해 필요한 인증서를 저장하는 곳이므로 헷갈리지 않도록한다.
 
좌측 상단의 “Add Certificate” 버튼을 클릭하여 좀 전에 저장한 인증서와 패스워드를 입력하고 “Create”를 클릭하면 인증서 등록이 끝나게 된다.

6. 인증서 관련된 일이 다 끝났으므로 이제 Visual Studio에서 직접 배포하면 된다. 아래는 배포가 진행중인 모습을 보여준다.

7. 배포가 끝났으면 이제 원격 접속을 통해 접근해보자. 특정 인스턴스를 선택한 후 “Connect” 버튼을 클릭한다. RDP 스크립트를 실행할 것인지를 물어보는데, 실행을 선택한다.

보안 팝업이 뜨고 계속 진행하면, 접속 아이디와 패스워드 입력창이 나오는데, 인증서 등록시 지정한 아이디와 패스워드를 입력하면 된다. 다시 한번 보안 경고창이 뜨고 원격 접속을 통한 화면이 보이게 된다.

원격 접속에 성공한 후 모습이다. 썰렁하지 그지 없다.

위 과정에서 보듯이 원격 접속은 Windows Azure Management Portal의 “Connect” 버튼 클릭을 통해서만 가능하다. 위에서 처럼 3개의 인스턴스를 실행할 경우, 내부적으로 Fault Tolerance 기능을 제공하기 위해 반응없는 인스턴스 대신에 새로운 인스턴스를 자동으로 띄우는 기능이 있기  때문에 IP 주소는 변동이 될 가능성이 있기에 IP를 기억하는 것은 무의미하다. 또한 각 인스턴스를 원격 접속해 보면 알 수 있지만, 이 세 인스턴스는 모두 내가 지정한 같은 도메인 이름을 공유하기 때문에, 외부에서는 해당 도메인 이름의 특정 인스턴스를 지정해서 접속할 방법이 없는 것이다. 따라서 항상 Windows Azure Management Portal을 통해서만 접속할 수 있다.

Posted by 장현춘

마이크로소프트가 오는 1월 13일 웹을 하는 새로운 방법, WebMatrix를 공식 출시한다. WebMatrix는 페이지 기반 웹 싸이트 구축을 손쉽게 할 수 있도록 필요한 개발 환경, 즉 ASP.NET Web Pages 및 PHP를 개발할 수 있는 IDE, 웹 서버 IIS, 데이터베이스 SQL 등을 포함하고 있는 웹 개발 스택을 한번의 설치로 모두 제공하는 개발 플랫폼이다. WebMatrix는 Visual Studio에 익숙한 기존의 엔터프라이즈 개발자보다는 웹 에이젼시의 가벼운 웹 개발에 익숙한 개발자들이 익숙한 PHP, ASP 개발 방식과 유사한 방식의 개발을 지원한다. WebMatrix에 대한 소개는 이전 포스팅을 참고하면 좋을 듯하고,  WebMatrix에 관한 상세한 개발 강좌 및 동영상 강좌는 SQLer.com을 참고하시길..

Microsoft WebMatrix 출시는 CodeMesh라는 커뮤니티 행사를 통해 1월 13일 전세계에 실시간 스트리밍을 통해 중계된다. 코드매쉬는 닷넷, 자바, 루비, 파이썬, PHP 등 다양한 언어와 플랫폼에 대한 개발 및 기술 흐름에 대해 폭넓은 논의를 제공하는 장이다. WebMatrix가 닷넷 뿐만아니라, 다양한 기술 배경을 가진 개발자들이 손쉽게 익일 수 있는 점에서 코드매쉬를 정식 출시 행사장으로 선택한 것으로 보인다.

WebMatrix 공식 출시와 연계하여 한국마이크로소프트에서도 아래와 같이 패널 토의를 포함한 세션들을 준비하여 한국 출시 행사를 진행한다. 이름하여.... "다시 웹을 피우기에 좋은 날, 웹의 매트릭스로 어서 오세요."

image

 

image

Posted by 장현춘