이번 후기에서는 로컬의 SQL Server 데이터를 SQL Azure로 마이그레이션하는 방법에 대해서 간단히 테스트해봤습니다. http://msdn.microsoft.com/ko-kr/library/windowsazure/ee730904.aspx 페이지에 접속해보면 마이그레이션할 수 있는 방법에 대해서 몇가지 나와 있습니다.

 

  • 기존 데이터베이스의 스크립트를 생성하여 SQL 데이터베이스로  마이그레이션
  • Microsoft Sync Framework 2.1을 사용하여 SQL 데이터베이스로 마이그레이션
  • 데이터 계층 응용 프로그램 내보내기 및 가져오기를 사용하여 SQL 데이터베이스로 마이그레이션
  • SQL 데이터베이스로 데이터 이동(SSIS)

 

SQL에서 마이그레이션이라 함은 크게 스키마에 대한 마이그레이션과 데이터 자체에 대한 마이그레이션이 있을 수 있겠죠. 2가지를 한꺼번에 처리해 줄 수 있는 방법도 있고, 스키마 생성 스크립트와 데이터 마이그레이션을 각각 실행하는 다양한 방법들이 있습니다. MSDN 도움말 문서를 참조해가면서 몇가지 테스트를 진행하도록 하겠습니다.

 

이번 후기에서 살펴볼 것은  위에서 안내되는 방법 중 제일 마지막의 SSIS를 사용한 방법 빼고 나머지에 대해서 대략 살펴봅니다.

 

1. 기존 데이터베이스의 스크립트를 생성하여  SQL 데이터베이스로 마이그레이션

MSDN에서는 http://msdn.microsoft.com/ko-kr/library/windowsazure/ee621790.aspx 페이지에서 해당 기능을 설명하고 있습니다만, 전 기존에 로컬에 존재하던 데이터베이스(OCSFTADD)를 사용하여 마이그레이션 해보기로 합니다.

 

a. 스크립트를 생성할 데이터베이스를 로컬 SQL Managemenu Studio에서 선택한 후 오른쪽 마우스를 클릭하여 스크립트 생성 메뉴를 선택합니다.

image

 

b. 다음을 눌러 개체 선택 단계로 이동한 후에 “전체 데이터베이스 및 모든 데이터베이스 개체 스크립팅”옵션을 선택합니다.

image

 

c. 스크립트 생성 및 게시 옵션에서는 파일에 저장/클립보드에 저장/ 새쿼리 창에 저장 3가지 중 아무거나 해도 상관은 없구요. 전 파일에 저장을 선택했습니다. 그리고 “고급”버튼을 선택합니다.

image

 

d. SQL Azure 데이터베이스용 스크립트를 생성하기 위해서는 고급 스크립팅 옵션에서 빨간부분으로 표시했듯이 "UDDT를 기본 형식으로 변환” 설정을 “True”로 하고 “데이터베이스 엔진 유형에 대한 스크립트”항목을 “SQL Azure 데이터베이스”로 지정합니다.

image

 

e. 확인을 누르고 다음페이지에 나오는 요약 페이지에서도 다음을 선택하면 스크립트 생성 진행화면이 나오고, 정상적으로 다 처리가 되면 완료되었음을 알리고 “마침” 버튼을 선택하면 지정한 위치에 스크립트 생성 파일이 생성되어 있는걸 확인할 수 있습니다.

image

 

f. 생성된 스크립트를  SQL Azure 데이터엡이스에서 실행하도록 합니다. 전 로컬에서 Azure에 연결하여 04번 DB에서 새쿼리 창을 띄우고 스크립트를 복사하여 실행하였습니다. 처리 시간은 4분 10초로 생각보다 좀 오래걸리긴 했는데, 아마 정합성 검증 등을 진행하느라 그러지 않았을까 생각됩니다. 결과를 보시면 오류가 몇개 있는데 이건 아래와 같이 외부 DB 를 참조하는 View나 SP이기 때문에 에러가 나타난 것이 당연했던 거구요. 이와같이 사전에 문제가 될 수 있는 스크립트 문은 수정이 필요한 후에 실행하는 것이 맞겠습니다.

image

 

g. 04번 DB 에 테이블 등의 스키마가 정상적으로 생성된 것을 볼 수 있습니다.

image

 

h. 데이터베이스를 내보내기해야 할텐데요. MSDN 문서에서도 이부분 설명이 조금 미약합니다. 스크립트 생성까지만 나와 있고, 데이터베이스 마이그레이션은 그냥 예제 샘플스크립트에 포함되어 있더라구요. 일단 로컬에서 운영중인 샘플 데이터를 기준으로 저는 테스트했기 때문에 기본적으로 데이터내보내기를 통해서 잘 되는지 확인해봤습니다.

image

 

i. 해당 기능이야 다 아실텐디 원본 선택은 소스가 되는 “COSFTADD”를 선택하구요. 중요한게 대상 데이터베이스 선택화면입니다. 서버이름은 SQL Azure의 데이터베이스 서버 Full 주소를 적습니다. 그리고 사용자 이름은  아이디@서버명” 과 같은 형식으로 입력해야 하더군요.

image

 

j. 다음 버튼을 눌러 이후 작업을 진행했더니 진행 도중 아래와 같은 에러가 떨어지네요. 마이그레이션이 쉽지는 않은 것 같습니다.

image

 

k. 그래서 이번에는 SQL Server 에서 SQL Azure로 Migration하는 Codeplex Tool을 잠깐 테스트해보기로 했습니다. 아래 Codeplex에서 Zip 파일을 다운로드 받고 압축을 해제하면 나오는 실행파일을 선택합니다.

image

 

l. 최초 실행 화면입니다. 매뉴얼이나 그런 것 안보고 일단 그냥 직관에 맡기고 “Analyze/Migrate”  항목의 “Database”를 선택했습니다.

image

 

m.  Source 서버를 선택하고 다음을 진햏하여  Destination 서버도 마찬가지로 선택합니다. DB명은 선택상자에 뜨는게 아니라 직접 입력을 해줘야 하더군요.

image image

 

n. 다음 단계를 진행하여 “EXecute Script”를 실행하면 아래와 같이 마이그레이션이 정상적으로 완료되었다고 뜨더군요.

image

 

o. 소스에 문제가 있는건지 아니면 제가 매뉴얼을 안 읽어 보고 한거라서 그런지 03번 서버에 스키마는 정상적으로 만들어져 있는데, 데이터까지 마이그레이션되지는 않았더군요. 다만 로컬 폴더에 각 테이블별로 dat 파일이 만들어진 것으로 보아 마이그레이션 과정 중에 이를 export해줘야 하는데 뭐가 문제가 있었나봅니다. 일단 운영 DB 에 대한 SQL Azure로의 마이그레이션은 시간 관계상 여기까지에서 마무리하기로 했습니다.

image

 

 

2. Microsoft Sync Framework 2.1을 사용하여 SQL 데이터베이스로 마이그레이션

MSDN 문서에 나와 있는 두번째 마이그레이션 방법은 Microsoft Sync Framework 2.1을 사용한 마이그레이션입니다. SyncFramework는 회사 프로젝트 때문에 초기 버전일때 얼핏 살펴본 이후로 직접 실무에서 만져보지는 못했습니다. 어찌 보면 마이그레이션  툴보다는 이름 그대로 동기화 프레임워크이니깐요. 깊이 살펴보지는 못하고 문서상으로 제공하는 간단한 샘플을 통해서 로컬 SQL Server의 DB를 SQL Azure로 마이그레이션해보도록 하겠습니다.

가이드 문서는 http://msdn.microsoft.com/ko-kr/library/ff928514(SQL.110).aspx 페이지를 기본으로 진행합니다.

 

a. SyncFramework 2.1 버전을 다운로드 합니다. [SyncFramework 2.1 다운로드 ] 링크에 들어가면 32/64비트 다운로드가 제공됩니다. 전 64비트를 설치진행했습니다.

image

 

b.  다운로드 후 설치를 진행하면 아래와 같이 간단히 설치가 가능합니다.

image imageimage image

 

c. 테스트를 위한 데이터베이스를 생성합니다. [데이터베이스 공급자용 설치 스크립트 방법 항목] 페이지의 첫번째 스크립트를 복사하여 로컬에서 실행합니다.  가이드 상에서는 “데이터베이스 공급자용 설치 스크립트 방법 항목의 "SQL Server 공동 작업 시나리오를 위한 테이블" Transact-SQL 스크립트를 실행합니다. 이 스크립트는 첫 번째 데이터베이스에 일련의 테이블이 포함된 3개의 데이터베이스를 만듭니다.” 이와 같이 나와 있고, 3개의 데이터베이스가 생성된다는 말에 조금 헷갈렸습니다.  해당 페이지로 이동하게 되면 4개의 샘플 스크립트가 존재하는데, 첫번째가 2개, 네번째가 3개의 DB를 만들게 됩니다.

테스트 해보니 결과적으로는 첫번째 스크립트가 맞는 것 같습니다만 지금도 헷갈리긴 하네요. 일단 첫번째 네번째 스크립트를 실행합니다.

image

 

d. Visual Studio 에서 “SQLAzureSyncTest”라는 콘솔 어플리케이션 프로젝트를 신규로 생성합니다. Sync Framework는 프로그램 모드에서 실행되어야 하기 때문에 개발작업이 조금 들어가게 됩니다.

image

 

d. [데이터엡이스 공급자용 설치 스크립트 방법 항목.]  페이지에서 Utility Class복사하여 위에서 만든 프로젝트에 추가합니다.

image

 

e. 프로젝트 참조에 아래의 5개 dll 에 대한 참조를 추가합니다.

imageimage

 

f. [방법: SQL Azure와의 동기화 구성 및 실행] 페이지의 하단에 있는 전체 예제 샘플을 복사합니다. 해당 내용은 Program.cs 파일입니다.

image

 

g. 프로젝트의 Program.cs 파일을 위의 복사한 내용으로 덮어쓰고, Namespace 항목은 원래 값으로 다시 수정해줍니다. 전 “SQLAzureSyncTest”라는 이름으로 프로젝트를 만들었기 때문에 아래와 같이 다시 수정해줬습니다.

image

 

h. SQL Azure로 데이터엡이스를 프로비저닝하기 위해 Utility.cs 파일을 열고, 아래와 같이 “ConnStr_SqlAzure_Server”메서드로 이동합니다.

image

 

i. 프로비저닝하고자 하는 SQL 데이텅베이스의 연결문자열을 아래와 같이 포털의 대시보드 화면에서 확인합니다. “연결문자열” 항목을 누르면 4가지 샘플 연결문자열이 나오는데 그 중에 젤 위에 있는 ADO.NET 부분을 복사합니다.

image

 

j. 프로젝트에서 앞서 Utility.cs에서 해당 연결문자열 부분을 복사한 내용으로 변경하고 암호를 맞게 수정합니다.

image

이후 빌드 과정에서 위와 같이 연결문자열을 복사하여 그대로 사용했더니 연결에 실패했다는 에러가 뜨더군요. 결국 해당 메서드에 적용될 연결문자열은 다른 연결문자열과 비슷한 형태로 아래처럼 입력해야 하더군요.

@"Data Source=rl0lm8we8j.database.windows.net;User ID=rlaaudfuf01;Initial Catalog=rlaaudfuf01;Password={사용자암호};Persist Security Info=True";

k. Utility.cs  의 경우 클래스 부분만 복사했더니 상단의  using 구문에 일부 추가가 안된 참조파일들이 있어서 최종적으로 아래와 같은 using 구문이 되었습니다.

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlServerCe;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

 

l. 일단 위와 같이 구성 후 빌드를 하게 되면 몇가지 에러가 아래와 같이 발생합니다.

image

 

m. 첫번째 오류는 “MaxiumApplicationTransactionSize” 부분에서 발생하는데 2.1 버전이 되면서 변경이 발생했나 봅니다. 크게 중요한 것 같지 않아서 일단 해당 라인은 주석처리를 해줍니다.

image

 

n. 다음 발생 에러는 중복되서 몇개가 발생했는데요. “UserDescription”속성이  “UserComment”로 변경이 되었나 봅니다. 아래와 같이 오류 발생 부분을 “UserComment” 로 변경해주었습니다. 5개 중 3개의 오류가 이 부분이었습니다.

image

 

o. 마지막으로 발생한 오류 부분역시 2.1이 되면서 변경이 된 듯한데. 일단 해당 부분을 아래와 같이 Aborted  한 라인만 빼고 모두 주석처리해주었습니다.

image

 

p. 위와 같이 수정하고 빌드하면 에러 없이 빌드가 가능했습니다. 이후 프로젝트를 실행하게 되면(최초엔 Azure 연결 문자열을 복사해서 그대로 사용했었기 때문에) 연결 실패 에러메시지가 발생했습니다.

image

 

q. 그래서 연결문자열을 앞서 나왔던 내용처럼 수정 후에 다시 실행을 하게 되면 이번엔 새로운 에러 메시지가 뜨게 됩니다.

image

SyncFramework의 경우 First Provision하는 부분이 있어서 발생하는 문제이구요. 앞서 나왔던 로컬의 샘플 DB 스크립트를 아예 다시 실행했습니다.(해당 스크립트의 경우 기존 DB를 지우고 다시 만들게끔 되어 있습니다)

위와 같이 오류가 발생하는 것은  Program.cs  파일 중

DbSyncScopeDescription customersScopeDesc = new DbSyncScopeDescription("customers");

위와 같은 내용이 있는데, 여기에 “ customers”라는 범위명을 사용하여 SyncFramework 에서 사용하는 scope 테이블 등에 해당 정보가 이미 등록되어 있기 때문에, DB 연결문자열 수정 후 재실행했을 때 이미 동일한 이름이 존재한다는 에러가 발생되는 것입니다.

 

r. 다시 프로젝트를 실행하게 되면 또 아래와 같은 에러 메시지 창이 저를 반겨주더군요. 구글에서 검색을 해보니 프로젝트가 64비트가 아닌 경우(전 SyncFramework를 64비트를 다운 받아 설치했습니다) 발생한다고 하네요.

image

 

s. 프로젝트 빌드 항목을 살펴보니 역시나 AnyCPU이긴 하지만 디폴트로는 32비트 모드로 돌게끔 되어 있는 것 같아서 아래와 같이 64비트로 명시적으로 변경하였습니다.

image

 

t.  다시 로컬  DB를 초기화한 후 프로젝트를 실행하면 아래와 같이 Sync 가 성공되었음을 알리는 메시지가 보입니다.

image

하단에 보이는 에러는 확인해보니  로컬 SQL-> SQL Azure로의 마이그레이션이 아니라, SQL Azure의 변경 내용을 로컬의 SQL CE로 동기화하는 부분인 것 같아 주석 처리했습니다.

 

u. 마이그레이션이 잘 되었을까요? 일단 싱크 이전에 캡쳐해놓은 01 DB의 두 테이블 정보는 아래와 같습니다.

image

 

v. 마이그레이션 완료 후 01번 데이터베이스에 대한 2 테이블 쿼리 화면입니다. 로컬 데이터와 같이 Customer테이블은 5개, CustomerContact 테이블은 4개의 데이터가 채워진 걸 확인할 수 있습니다.

image

 

w.  SyncFRamework 2.1 이다보니 로컬의 데이터가 변경된 후 Sync 작업을 하면 어떻게 될까요? 테스트에 들어가봅니다. 아래와 같이 업데이트를 실행합니다(원래 업데이트에 ID조건을 줄려고 했는데 빼먹고 하다보니 전체 변경이 되었습니다). 영역 지정해서 Update를 먼저 실행 후 상단의 Select 를 쿼리한 화면입니다.

image

 

x. Visual Studio의 프로젝트 소스 파일 중 Program.cs 의 내용 중에서 최초 Provision 부분과 SQL CE와 마이그레이션하는 부분을 주석처리한 후에 프로젝트를 실행하면 아래와 같이 정상적으로  Sync되었음을 확인할 수 있구요.

image

 

y. 다시 SQL Azure의 포털에서 데이터를 확인해보면 아래와 같이 이름 값이 모두 변경된걸 확인할 수 있습니다.

image

 

이상으로 Microsoft Sync Framework 2.1을 사용하여 로컬의 SQL 데이터를  SQL Azure로 마이그레이션하는 방법에 대해서 간략히 살펴보았습니다. SyncFramework 부분 역시 깊게 들어가면 기본 아키텍쳐부터 이해하고 확인해야할 부분이 있지만 개발자라면 나름 한번은 사용해볼만하지 않나 생각됩니다.

 

 

3. 데이터 계층 응용 프로그램 내보내기 및 가져오기를 사용하여 SQL 데이터베이스로 마이그레이션

세번째로 나온 방법을 사용하여 로컬 SQL데이터를 SQL Azure로 마이그레이션 해볼려고 했더니, 시간도 부족하고 해서 여기까지는 완벽히 테스트를 해보지 못했습니다. MSDN 문서의 경우도 SQL Azure의 데이터를 동일한 Azure서버로 복사하거나 스토리지로 내보내기 하는 등의 설명이나 가이드 문서는 나와 있는데, 로컬 DB 자체를  데이터계층 응용프로그램 내보내기를 통해서 처리하는 부분은 확인하지 못했습니다.

그래도 혹시나 싶어서 간단히 로컬 SQL에서 해당 메뉴만 실행해보았습니다.

 

a. 마이그레이션을 원하는 DB의 오른쪽 마우스를 클릭하여 “태스크-> 데이터계층 응용프로글매 추출” 항목을 선택합니다.

image

 

b. 데이터 계층 응용 프로그램 추출 화면이 나오구요.(사실 이 메뉴는 이번에 처음 실행해봤습니다. 요즘엔 DB쪽 작업을 크게 할일이 없었나 봐요)

image

 

c. DAC 속성을 설정하는 화면입니다. 기본으로 놔두고 다음 버튼을 클릭합니다.

image

 

d. 유효성 검사 등을 잠시 진행하더니 아래와 같은 결과가 나오는군요. 오류 개체가 있어서인지 다음 단계로 진행은 되지 않았습니다.

image

 

여기까지가 데이터 계층 응용 프로그램 추출을 테스트해본 상황입니다. 하지만 SQL  Azure 서버 데이터에 대해서는 MSDN보시면 알겠지만 관련자료가 꽤 됩니다. Azure 스토어의  Container를 사용한 방법 등이 나와 있습니다만 거기까지는 테스트하지 못했네요.  4번째 방법인 SSIS를 사용한 마이그레이션 역시 이번 체험에서는 진행하지 못했구요.

 

여기까지 “SQL 데이터베이스” 주제로 열린 6차 체험을 마무리해야 할 것 같습니다. 이번 6차때는 다행히 후기를 정리하고 있는 지금시간까지(일요일 오후 10:00) 아직 체험 계정이 열려 있어서 미처 확인하지 못했던 사항들을 볼 수 있어서 좋긴 하네요.

 

Azure는 참 공부할 수록 해야할게 많다는 걸 느낍니다. 눈으로만 관련 문서를 훑어보는 것보다는 지금처럼 직접 코딩도 하고 이것저것 스크립트 실행도 해가면서 되는거 안되는거 확인하고 하면서 나만의 지식으로 만들어가는 것이 좋은 것 같습니다.

 

다음 7차 체험 이벤트가 언제 열릴지는 모르겠지만 계속해서 참여해보고 싶습니다. 4~6차 체험의 외전 격으로 제가 개인적으로 테스트하고 있는 부분은 Azure VM에서 AD 설치 후 해당 AD에 연결하여 Lync 2013서버를 설치한 후 사용자 계정으로 직접 운영테스트까지 하였습니다만, 평가판의 경우 기간 제한이 있다보니 조금 아쉬운 부분이 있더라구요.  Azure VM에서의 AD  설치나 Lync 2013 설치 과정 등에 대해서도 체험후기를 적을까 하다가 일반 VM  에서와 크게 다른 것은 없어서 그냥 안하기로 했었는데요, 개인 블로그에라도 정리 차원에서 올려 놓던지 해야겠네요.

 

아니면 얼마 전에 출시된  Lync2013 CU1 업데이트와 여기에 포함된 UCWA 를 사용한 웹채팅방에 대한 간단한 사용법이라도 정리해봐야겠구요.

 

주말 동안 이거저거 하는 중에 후기 정리하느라 시간이 후딱 가버렸군요. 아쉽지만 다음 체험기회를 또 기다리겠습니다.

 

6차 체험의 주제가 “SQL Azure”이다 보니 관련 자료를 이것저것 찾아보다가, 문득  REST API를 제공한다는 걸 보게 되어 잠깐 이를 테스트해보기로 합니다. 이번 후기에서 살펴볼 내용은 아래와 같습니다.

 

  • 공개/개인 인증서 키 생성 및 등록
  • REST API 사용 검증 샘플
  • 방화벽 Rule 생성 콘솔 어플리케이션 테스트 

 

1. 공개키 인증서 생성. Azure의 관리 기능을 REST나 .NET 등의 개발모듈에서 사용하기 위해서는 Azure에 인증서가 업로드가 되어 있어야 하고, 이 인증서를 사전에 만드는 작업을 진행합니다.

Windows Azure 와 연동할 인증서 파일을 생성해야 하는군요. x.509 v3를 지원하는 인증서 파일을 생성해야 합니다. Visual Studio 가 설치되어 계시다면 “Visual Studio  명령 프롬프트”를 실행한 후 인증서파일을 저장할 경로로 이동하여 아래와 같이 입력합니다.

makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"

[적용 결과]  -> D 루트 드라이브에 StarhuntCert.cer  파일이 생성됩니다.
인증서를 생성하는 방법은 http://msdn.microsoft.com/ko-kr/library/gg432987.aspx 를 참조하시면 IIS를 사용하는 방법도 추가적으로 잘 나와 있습니다.

image

 

2. 개인키 인증서 생성. 방금 만든 공개키 인증서에 매핑되는 개인키가 추가적으로 필요합니다. 이는 REST API를 호출할 때 코드에서 이 개인인증서 파일정보를 사용하게 됩니다.

a. 실행 명령 창에서 “cermgr.msc”를 입력하면 인증서 관리 MMC 창이 뜨게 되고, 개인용 –> 인증서 노드를 보시면 앞서 만들었던 인증서항목이 보이게 됩니다.

image

 

b. 해당 인증서를 선택하고 오른쪽 마우스를 클릭하고 [모든작업 –> 내보내기]를 선택합니다.

image

 

c. 인증서 내보내기 마법사 창이 아래와 같이 뜨게 됩니다. “다음”을 선택하시구요.

image

 

d. “예, 개인 키를 내보냅니다”를 선택하고 다음으로 진행합니다.

image

 

e. 사용할 형식에 개인정보 교환 기본 선택되어 있는 걸로 두고 다음으로 진행합니다.

image

 

f. 암호를 입력합니다.

image

 

g. 개인 키 파일을 저장할 경로와 키파일명을 지정합니다.

image

 

h. 아래와 같이 최종 정보 확인 후 마침을 선택하게 되면 지정된 경로에 파일이 만들어지게 됩니다.

image

 

3. 공개키 인증서를 포탈에 업로드합니다.

a. 애저 포탈에 접속해서 왼쪽 메뉴 중 제일 하단의 “설정”메뉴를 선택하면 첫번째 탭에 관리인증서페이지가 열립니다.

image

 

b. 하단의 “업로드” 버튼을 클릭하고 아래와 같이 파일 찾기 화면에서 앞서 만들었던 공개키 인증서(.cert)를 선택하여 업로드합니다.

image

 

c. 이번 체험의 경우 구독 종류가 “3개월 무료체험”과 “종량제”가 있는데 현재 만들어진 DB들이 종량제 관련 항목들이라 “종량제”를 선택 한후 완료합니다.

image

 

d. 정상적으로 업로드가 완료되면  아래와 같이 앞서 만들었던 인증서가 리스트에 나타난 걸 확인할 수 있습니다.

image

 

4. REST 연결 클라이언트 검증

SQL Azure의 Rest 호출을 위한 인증서 작업이 마무리 되었기 때문에 간단한 검증용 클라이언트를 만들어 테스트를 진행하였습니다.

a. Visual Studio를 사용하여 간단한 콘솔 어플리케이션을 하나 만들고 아래와 같이 서버 정보를 얻어오는 REST를 호출해보기로 합니다.

image

ClientCertification 정보에 2번에서 만들었던 개인키 정보(파일경로, 암호)를 지정해주는 것이 포인트겠네요. subscriptionid(구독 ID)는 애저 포탈의 대시보드 화면의 오른쪽 아래에서 보시면 확인 가능합니다.

 

b. Break를 걸고 리턴되는 값을 확인해보면 아래와 같이 체험중인 SQL Azure 서버 정보를 잘 받아오는 걸 확인했습니다.

image

 

5.  MS에서 제공하는 REST API 사용 추가 샘플을 사용하여 방화벽 설정을 추가할 수 있는 콘솔 어플리케이션을 만들고 테스트를 진행합니다.

a. Visual Studio에서 “콘솔 응용 프로그램”을 선택하고 프로젝트 이름은 “SQLAzureDatabaseManagement”를 입력하고 진행합니다.

image

 

b. Program.cs 파일을  페이지의 내용으로 변경합니다. 참조한 샘플은 “서버 수준 방화벽 만들기 (http://msdn.microsoft.com/ko-kr/library/gg715280.aspx )” 를 참조하시면 됩니다.

image

 

c. 해당 프로젝트를 빌드한 후 콘솔 창에서 빌드 완료 폴더로 이동하여, 총 7개의 인자를 입력하면 방화벽 설정을 추가할 수 있습니다.

  • CertifilePath : 개인인증서 파일 위치
  • CertfilePassword : 개인 인증서 암호
  • Subscription ID : 구독 아이디
  • ServerName : 애저 포탈 서버 이름
  • Rulename : 방화벽 이름
  • StartIP : 방화벽 허용 아이피 시작 값
  • EndIP :  아이피 종료 값

image

 

d. 정상적으로 실행되었다고 아래와 같이 나타납니다.

image

 

e. 실제 만들어졌는지 확인해봅니다. 먼저 위의 콘솔 실행하기 전의 방화벽 룰 정보를 master DB에서 쿼리한 정보입니다. 현재는 2개의 방화벽 정보만 리턴됩니다.

image

 

f. 콘솔 실행 후 방화벽 정보 쿼리 화면입니다. 방금 추가한 “Command_Add_Rule”이 잘 등록된 것을 확인할 수 있습니다.

image

 

이상으로 SQL Database에서 제공하는 REST API를 사용하기 위한 인증서 생성 및 등록과 콘솔 어플리케이션을 통해 지원되는 REST API의 사용 방법에 대해 간략히 살펴보았습니다.

 

방화벽 룰 설정은 위와 같은 REST 외에도 스토어 프로시저에서 제공하는 아래의 sp를 통해 추가 삭제도 가능합니다.

exec sp_set_firewall_rule N'Example setting 1','0.0.0.2','0.0.0.2'

exec sp_delete_firewall_rule N'Example setting 1'

 

아쉬운건 REST API의 경우 지원되는 기능들이 제한이 있어서 다 지원하지는 않은게 조금 아쉽긴 하네요.

지원되는 REST API 기능이나 관련 자료는 http://msdn.microsoft.com/ko-kr/library/gg715283.aspx  에 잘 나와 있습니다.

image

 

이번 후기는 여기까지입니다. REST API 사용에 대해서 간략히 살펴봤습니다.

 

이번 Window Azure 커뮤니티 연합 온라인 세미나의 메인 체험 주제는 “SQL Azure”입니다. 4차부터 참여하셨던 분들은 아마 4차 체험에서 대부분 SQL Azure의 주요 기능들을 살펴보셨을 텐데요. 그 사이 Azure 포탈이 한글화가 되다보니  4차 때랑은 또 기분이 틀리긴 하네요. 6차 캠프 때는 지난 5차보다도 더 일찍 계정 관련 메일을 받았습니다. 아마 아침 일찍부터 관계자분들께서 고생해주신 것 같네요.

계정 정보를 받자마자 퇴근 전에 간략히 SQL Azure의 기능들을 살펴 보았습니다. 상세한 부분에 대해서는 온라인 세미나 기간 중에 시간이 되면 테스트해보고 아니면 또 주말에 보충수업을 해야겠네요.

오늘 체험기는 SQL Azure의 주요 화면 스샷과 함께 둘러보기입니다.

1. 최초 포탈 접속 화면입니다. 5개의 SQL DB와 SQL 2012 VM이 하나 만들어져 있습니다. 구독타입은 종량제로 되어 있네요.

image

 

2. SQL 데이터베이스 메뉴를 클릭해서 보이는 데이터베이스 정보 화면입니다.

image

 

3. 상단의 서버 탭을 누르면 아래와 같은 화면이 나타나구요.

image

 

4. 다시 데이터베이스 화면으로 가서 첫번째 DB를 선택하고 하단의 “관리” 아이콘을 클릭하면 방화벽 관련 알림이 아래와 같이 뜨게 됩니다.

image

 

5. “예”를 선택하면 자동으로 방화벽 Rule에 현재 접속한 클라이언트 IP를 추가해주고, 다시 관리화면으로 진입할 건지 물어봅니다..

image

 

6. 관리화면에 접속하면 사용자 이름과 암호를 물어보게 됩니다. 6차 캠프 계정정보 안내 메일에는 SQL 연결 암호정보만 있고 사용자 이름이 없었는데요.

image

 

7. 포탈의 DB 01번 대시보드 화면으로 가서 “연결문자열 표시”메뉴를 선택해서 아이디 정보를 확인했습니다.

image

 

8. 연결문자열 정보는 ADO.NET/ODBC/PHP/JDBC 4가지의 샘플을 보여줍니다.

image

 

9. 다시 아이디와 암호를 입력하고 연결을 하게 되면 실버라이트 로딩 화면이 뜬 뒤에 아래와 같은 데이터베이스 온라인 관리 화면이 나타나게 됩니다.

image

 

10. 메인 바탕화면에 있는 각 주요 메뉴를 클릭해봤습니다. 먼저 “퀵 스타트” 메뉴입니다.

image

 

11. “새로운 기능” 메뉴는 아래와 같구요. 해당 메뉴를 클릭하면 관련 URL로 새창이 뜨더군요.

image

 

12. “자세한 내용” 탭에서는 블로그나 커뮤니티 및 기술지원 사이트 URL로 연결이 됩니다.

image

 

13. 앞서 본 퀵스타트 메뉴의 “데이터베이스 만들기”메뉴를 클릭했을 때 화면입니다. (저녁 먹고 퇴근 전에 후다닥 보느라 마음이 급했을 까요? 5개 DB 이외에 추가로 만들지 말라는 메일 내용이 있었음에도 뭐에 홀렸는지 체험기를 작성하고 캡쳐를 해야한다는 생각에 그냥 생각없이 “새 데이터베이스” 생성을 하고 그걸로 이것저것 기능 살펴본 걸 문득 깨닫고 부랴부랴 다시 삭제하는 해프닝을 벌였네요 ㅠ.ㅠ)

하여튼, 새 데이터베이스 만들기에 들어가게 되면 DB 이름과 용량 그리고 데이터정렬 값을 지정할 수 있습니다. 버전은 Web으로 고정되어 나타나는군요.

image

 

14. 추가적으로 후기 작성하면서 좀더 살펴봤는데, 새 데이터베이스 만들기 화면으로 진입하게된 계기가 최초 사용자 아이디를 미리 확인하지 않고 혹시나 싶어 “starhunt9”라는 걸 넣어봤더니 아래와 같은 오류가 떨어졌습니다.

image

 

15. 그래서 취소를 눌렀더니 아래와 같은 로그인 화면이 나타나는데요 처음 화면과의 차이점은 최초 선택했던 1번 데이터 정보가 사라지고 데이터베이스 부분이 비어있게 되는군요. 이 상태로 로그인을 했더니 선택된 데이터베이스가 없어서 “데이터베이스 만들기”라는 메뉴가 활성화되었나봅니다.

image

 

16. 정상적인 케이스에서는 먼저 데이터베이스가 선택되고(최초의 경우에는 아니겠지만요) 그 데이터베이스로 로그인하게 되면 퀵메뉴에서도 “데이터베이스 만들기”라는 메뉴는 보이지 않게 됩니다. 그리고 사전에 데이터베이스 선택이 없이 들어가게 되면 아래와 같은 메뉴에서 데이터베이스 선택이 가변적으로 가능하고 리스트에 보이지 않던 “master” DB도 보이게 됩니다.

image

 

17. Master 데이터베이스를 선택했더니 아래와 같이 권한이 없다고 나오는군요.

image

 

18. 다시 데이터베이스 만들기 화면으로 돌아와서 전 “SqlAzureTest”라는 DB를 5G / Korean_Wansung_CI_AS로 만들었습니다.

image

 

19. 성공이 완료되면 아래와 같이 기본 요약 화면이 나타납니다. 아마 데이터베이스를 선택하고 로그인했을 때 뜨는 화면과 동일할겁니다.

image

 

20. 쿼리 성능 페이지에는 제가 실행한 쿼리가 없었는데도 DB 생성시에 작업이 있었는지 실행된 쿼리에 대한 정보가 나타납니다.

image

 

21. 테이블 화면으로 이동해서 새 테이블 만들기 작업을 해봤습니다.

image

 

22. 인덱스나 키도 바로 설정할 수 있구요. SQL Azure의 경우에는 반드시 클러스터 키가 존재해야 합니다.

image

 

23. 인덱스 추가 화면입니다.

image

 

24. 외래키 관계 추가 화면입니다.

image

 

25. 데이터 탭에서 직접 데이터를 추가할 수도 있습니다. 날짜 필드의 경우에는 아래와 같이 캘린더에서 직접 선택이 가능하네요.

image

 

26. 데이터 입력 후에 쿼리 화면에서 예상 계획 화면입니다. 뭐 아직 데이터 자체가 없기도 하고 쿼리 자체도 특별한게 없지만, 복잡한 구조의 쿼리의 경우에는 어떻게 잘 보일런지 모르겠네요. 탭에서 리스트나 표형태로 확인도 가능한 것 같습니다.

image

 

27. 이번에는 뷰 생성 화면입니다. 간단한 뷰 하나도 만들어 보겠습니다. 처음에 생각없이 Create 구문까지 아래에 적었다가 오류가 나서 이름은 윗쪽에 따로 적고 뷰 정의만 아래에 분리해서 다시 만들었습니다.

image

image

 

28. 뷰의 데이터 확인 화면입니다.

image

 

29. 이번에는 저장프로시저 생성 화면입니다. 초간단 SP를 하나 만들었습니다.

image

 

30. 데이터 화면에서 아래와 같이 인자를 넣어서 직접 실행해볼 수 있습니다.

image

 

31. 이제 뭐가 남았나 하다가 지난 번에도 해봤는데, 그래도 Full로 한번 살펴보고자 해서 로컬 SQL에서 접속해보기로 했습니다. 아래와 같이 로그인정보를 입력하고 연결을 선택합니다.

image

 

32. 정상적으로 연결이 되고 쿼리 또한 잘 실행됩니다. (이 시점에서야 DB를 추가하면 안되는데 내가 Custom DB를 만들었구나라는 사실을 인지하게 되었습니다)

image

 

33. 그런데 여기서 SP를 수정해볼려고 했더니 수정메뉴가 비활성화되어 있어서 조금 이상했습니다.

image

 

34. 부랴부랴 데이터베이스를 삭제하기 위해 관리 포털에 들어가서 삭제 메뉴를 클릭했더니 아래와 같이 회색 화면만 나오고 처리할 수 있는 메뉴가 비활성화되서 멘붕상태에 빠졌더랩니다.

image

 

35. 몇번을 다시 시도해보다가 관리자분께 메일도 보내고, 문득 로컬에서 지워질려나 싶어 아래와 같이 로컬 SQL Manager에서 삭제를 했더니 잘 지워지네요.  SQL Azure의 경우 동일한 DB명으로 만들고 지웠다를 반복해서 최종적으로 하나의 DB 이름이 존재한다고 하더라도 데이터베이스를 만드는 작업 단위로 과금이 된다고 해서 조금 긴장했었습니다.

image

 

36. 삭제 완료 상태입니다.

image

 

37. 저 시점까지 혹시나 싶어 구독 메뉴를 들어가보긴 했는데 아래와 같이 일단 \0 이 나와서 조금은 안심했습니다만 하루 지나서 과금이 될까요? ㅎㅎ

image

 

일단 여기까지가 저녁먹고 간단히 야근작업 마친 후에 후다닥 살펴본 SQL Azure 체험기입니다. 추가 기능 들에 대해서는 시간이 되는데로 한번 도전해봐야겠습니다. 참고로 현재 SQL Azure 버전은 아래와 같습니다.

image

지원되는 기능이나 제약조건들이 서버 업그레이드 버전에 따라서 조금씩 달라지기 때문에 관련 문서는 필히 확인을 해봐야하겠네요.

 

SQL Azure나 Azure WebSite의 경우 역시 공부하는 목적으로 저야 살펴보고 있습니다만 도입하는 기업의 경우, 상시 운영을 대체하기 위해서 Azure로 가는 것은  비용문제 때문에 따져봐야할 것 같아 보입니다.  선거나 특정 이벤트처럼 반짝 기간 동안에 대량 접속 등의 작업이 필요할 때는 유용하지 않을까 생각하네요.

 

블로그 이미지

별아해

카테고리

분류 전체보기 (12)
닷넷 (5)
안드로이드 (1)
데이터베이스 (0)
아이폰 (0)
IT일반 (0)