금주의 Azure 질답 – 201601 넷째주

한 주간 stackoverflow 또는 Facebook Azure 그룹에서 본 유용한 Azure 질답을 공유하는 글입니다.

오늘은 1월 넷째주, 5년만에 극심한 한파가 왔으니 데이터베이스 관련된 질답을 토픽으로 잡겠습니다.

15년 전, 음원 회사(지금의 멜론같은)에 DBA 알바를 할 때 추운 날씨에 벌벌떨며 책장에 꽂힌 마그네틱 백업테이프를 정리하던 기억이 납니다. 그래서 추우면 데이터베이스 생각이 나…기는 개뿔 그 회사는 망해서 이젠 없네요.

1. SQL Azure와 MSSQL 2008은 뭐가 다른가요?

원문링크: http://stackoverflow.com/q/3235164/361100

SSMS로 SQL Azure에 접속해서 아래 명령어를 실행해봅니다.

SELECT @@version

그러면 아래처럼 나옵니다.

Microsoft SQL Azure (RTM) – 12.0.2000.8
Jan 22 2016 00:27:23
Copyright (c) Microsoft Corporation

빌드넘버 12.0.2000.8은 ‘MSSQL 2014 RTM’입니다.
그렇다고 SQL Azure가 MSSQL 2014와 완전 동일하냐면 당연히(!) 그렇지 않습니다.

대부분은 같고 조금은 다르고 일부는 없습니다. 이 글에서는 실무에서 민감할 수 있는 부분 몇 개만을 추려서 나열하겠습니다. 전체 기능 비교는 공식 문서에 있습니다.

  • 조금 다른 부분
    • Profiler 없지만 SQL Azure 관리자 콘솔에서 부분적인 기능을 제공합니다. 예를 들어 Index Advisor 같은 경우 대시보드에서 바로 확인할 수 있습니다.
    • 최대 1000GB: SQL Azure는 전통적인 용량 기준이 아닌 Federation이라는 방식으로 Scale-out을 합니다. 즉, ‘1000GB 이상은 어쩌냐 빼애액’이 아니라 ‘100GBx100개도 가능 ㅇㅋ?’인거죠.
    • 이메일 직접 전송은 안되지만 SQL Azure 셋팅에 Alert Rule을 설정해서 처리할 수 있습니다.
  • SQL Azure에는 없는 것들
    • Filestream 없음: 오라클을 썼던 분들이 특히 애용하는 blob 저장은 없습니다. Azure Storage에 DB의 키값과 동일한 Guid로 별도 저장하는 것을 추천합니다.
    • Full-Text search는 있지만 서드파티 플러그인 없음: pdf나 오피스 파일 등은 인덱싱이 안됩니다.
    • Cross-Reference로 INSERT, UPDATE, and DELETE 수행 안됨: Database-as-a-Service 형태라서 그런거라 봅니다.
    • .NET Framework CLR integration with SQL Server 안됨: 이것도 서비스 형태라서 그런가봅니다. by-design이랄까.

SQL Azure는 최근에 Full-Text search가 추가되는 등 하루가 다르게 기능 추가와 발전이 일어나고 있습니다. 최근 업데이트 목록을 보면 얼마나 빨리 발전하는지 실감이 가죠.

마이크로소프트가 영혼까지 끌어모아서 기승전-Azure를 외치고 있는지라, DB 쪽도 SQL Azure로 완전 옮기거나 SQL Azure와 병행하는 방향으로 계속 추진하는 것은 기정사실입니다.

그리하여, SQL Azure를 당황하지 않고 적용하는 방법은 주로 두가지입니다.

  • MSSQL VM에서 먼저 구현한 후 서비스가 안정화되면 SQL Azure에 필요 기능을 점검한 후 마이그레이션
  • SQL Azure로 시작해서 적응하기

물론 전자를 더 추천합니다. 서비스 초기엔 모든 것을 투명하게 파악할 수 있는 상태, 기존에 알던 지식을 최대한 활용할 수 있는 상태에서 최대한 서비스 구현에 힘쓰고 그 후에 기능 변동이 적을 때 옮기는 것이지요.

읽기전용이나 덜 중요한 스키마만 옮겨놓을 수도 있겠고요. MSSQL 2016에서는 설치형 SQL과 SQL Azure를 보다 투명하게(seamless?) 연동할 수 있게 되니 마이그레이션 부담이 더 적어질 것입니다.

2. SQL Azure에 import가 너무 느립니다. 뭐가 잘못된거죠?

원문링크: http://stackoverflow.com/q/23313235/361100

SQL Azure는 사용량을 예측하여 성능을 조정합니다. 즉, 갑자기 콰과과곽 들어오는 작업에는 대응이 미쳐 안따라주는 것이지요.

import를 할 때는 tier를 올렸다가 끝난 후 원래의 tier로 내리면 됩니다. 이런 센스는 클라우드 서비스를 사용하는 분들에게는 널리 퍼진 팁이죠?

3. Azure Redis Cache에서 자꾸 Connection TimeoutException이 납니다.

원문링크: http://stackoverflow.com/q/25416562/361100

저도 2일 전에 겪어서 처리한 것입니다. 해결방법은 단순한데, Lazy로 처리하길 Azure에서 권하고 있습니다.

아래처럼 말이죠.

private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() => {
    return ConnectionMultiplexer.Connect("mycache.redis.cache.windows.net,abortConnect=false,ssl=true,password=...");
});

public static ConnectionMultiplexer Connection {
    get {
        return lazyConnection.Value;
    }
}

Lazy로 접속 처리를 하면 아래와 같은 장점이 있다고 합니다.

  • thread-safe하게 초기화를 수행합니다. (더 깊게는 제가 모르겠습니다)
  • “abortConnect=false”라고 ConnectionString에 명기합니다. 자동 재시도를 수행합니다. 이것은 Azure에서 만들어주는 접속문자열에 이미 적용되어있습니다.
  • IsConnected로 확인할 필요 없이 ConnectionMultiplexer가 자동 접속 재시도를 합니다.
Advertisements

금주의 Azure 질답 – 201601 셋째주

stackoverflow에 올라온 Azure 질답 중 좋은 정보를 몇가지 공유하고자 작성하는 글입니다.

이번 글은 2016년 1월 셋째주입니다!

  • 1. Virtual Machine: classic과 아닌 것의 차이는 무엇인가요?

    원문링크
    먼저 배경지식을 설명하겠습니다. Azure는 현재 버전1/버전2(이하 v1/v2)로 나뉘고 있습니다. 둘의 차이는 인프라부터 개발자 대쉬보드 UI까지 완전히 벽을 세울 정도로 다릅니다. v2는 프리뷰를 떼고 정식버전이 출시된 상태이며 계속적으로 버그 수정과 발전을 하고 있습니다.

    12540901_10207298301551467_6480107955160008997_n
    v1과 v2 인프라 비교 (출처: channel9 비디오. 김일중님 설명 보충 감사합니다.)

    각설하고, VM 중 v1은 질문에서의 Classic VM을 의미합니다. 그리고 v2는 ARM VM(Azure Resource Management Virtual Machine)이라고도 부릅니다. Virtual Machine(이하 VM) 기준으로 가장 다른 점은 네트워크 리소스의 관리입니다.

    기존에는 Cloud Service라는 VM를 담는 어항이 있고 네트워크는 이에 전적으로 종속되었습니다. Cloud Service는 네트워크 끝점(endpoint)을 관리하고 있었지요. 하나의 독립된 VM을 만들면 무조건 하나의 Cloud Service가 동시에 만들어졌는데 그 갯수 제한 또한 있었습니다.

    하지만 v2에서는 이를 해결하기 위해 ‘리소스(Resource)’라는 거창한 개념을 도입하게 됩니다. 리소스는 VM만 담는 것이 아니라 다양한 서비스를 묶는 용도로 사용됩니다. 그래서 얻는 장점은? (1) 관리의 편리함과 (2) 네트워크 인프라의 유동성입니다. 각 리소스별로 관리자 간에 역할을 나눌 수도 있고(RBAC;Role-Based Access Control 이라고도 합니다) 관리용 외부 API(Azure Resource Management API) 연동을 위한 토큰에도 적용이 되지요.

    결과적으로 리소스는 역할별로 좀 더 세밀한 관리를 할 수 있는 Virtual Network에 연결됩니다. v2 VM(일명 ARM VM)은, 이 virtual network에 꽂힌 서비스 중 하나인 셈이죠. 기존 v1의 경우는 virtual network 설정이 의무적이진 않았습니다.

  • 2. Azure Notification Hub에 등록된 토큰은 언제 만료되나요?

    원문링크
    Azure Notification Hub(이하 Hub)는 푸시메시지의 PaaS모델로 APNS, GCM, 바이두푸시 등을 일원화된 API로 관리할 수 있게 해주는 푸시 미들웨어 서비스입니다. Hub 내에 Key-Value DB가 있어서 각 서비스별 토큰값을 저장하고 있으며 동시에 등록되는 태그를 통해 여러 기기를 가진 유저라고 한 번의 api 콜로 모든 기기에 전송할 수 있게 해줍니다. 물론, broadcast 기능도 기본이지요.

    모든 푸시서비스의 동작 방식은 유사합니다. 단말이 서버에 등록을 하면 토큰을 주고 그 토큰으로 메시지를 송수신 하는 것이지요. Hub는 단말이 받은 각 서비스의 토큰을 1:1 매칭된 새로운 토큰으로 바꿔줍니다. 이렇게 하는 이유는 각 서비스마다 푸시 처리 방식과 토큰 규격 등이 다르기 때문입니다.

    결론을 말하면 Hub의 토큰은 90일 후에 만료됩니다. 중요한 점은, 이 만료기간이라는건 Hub의 토큰 저장 만료를 의미하고 각 서비스의 토큰 만료 시간과는 다르다는 것입니다. 각 서비스의 토큰 만료는 대부분 명시되어있지 않습니다. 그렇다면 어떻게 안정적인 푸시 처리를 할까요? 구조 그대로 두 번(단말-서비스사, 서비스사토큰-Hub)의 단계를 따져야 합니다.

    Hub에는 다행히 언제 만료되는지 알 수 있는 Expiration Date 필드가 있습니다. 이를 이용해서 한 주에 한 번 즈음 모든 토큰에 루프를 돌면서 점검해줘도 되겠지요. 점검은 별거 없습니다. 단말을 어떻게해서든 깨워서(?) 새 토큰을 등록하게 하는거죠.  그 로직이 안드로이드 서비스로 돌든, 이벤트 메시지를 보내서 유저가 앱을 한 번이라도 실행하도록 하든. 이에 대한 처리는 이 글의 주제를 벗어나므로 다루지는 않겠습니다.

    어쨌거나 단말의 도움 없이 Hub만으로는 100%의 푸시 수신은 보장할 수 없습니다. 서비스사의 토큰이 언제 만료되는지는 몰라도, 보통 30일에 1회 정도 리프래시를 해주면 큰 문제는 없는 것으로 압니다.