금주의 Azure 질답 – 201603 둘째주

날씨가 훈훈해지는게 좀 있으면 벚꽃 날리겠지요.
그래도 개발자는 키보드나 도닥거리겠지만요.

요즘은 Service Fabric과 Micro-Service Architecture 공부를 하고 있으며, 4월 16일 Azure Boot Camp 에서 Service Fabric에 대한 발표를 하게 됩니다. (링크:온오프믹스) 자세한 내용은 별도의 글로 공지를 하겠습니다.

이번엔 두 개의 질답만 나누고자 합니다.
Azure가 너무 빨리 바뀌어서 제가 다루는/관심있는 분야 외의 것은 그대로 적기에 확신이 안서거든요.

1. Service Fabric의 State 저장 한계는 얼마나 되나요?

원본링크: http://stackoverflow.com/q/35143475/361100

State는 일종에 데이터 저장소입니다. 모든 인스턴스간에 동일한 정보가 유지되도록 하지요. 대표적으로 모든 인스턴스가 똑같은 딕셔너리 정보를 가질 수 있도록 하지요. 이것은 메모리와 디스크를 모두 유지하고 있습니다.

질문에서 100기가 이상으로 정보가 늘어나면 어떻게 되느냐는건데, Service Fabric을 생성할 때 VM을 선택하므로 더 큰 VM으로 업그레이드하거나 VM에 blob storage를 더 장착하면 됩니다. 정보 자체는 메모리와 디스크 모두에 저장됩니다.

2. D 시리즈의 SSD는 무슨 드라이브인가요? 왜 32기가 뿐이죠?

원본링크: http://stackoverflow.com/q/35979370/361100

D드라이브입니다. 참 쉽죠?

어? D드라이브는 임시디스크라면서요!

네 맞습니다. 임시디스크입니다. VM 리부팅하면 사라질 수 있습니다.
그러니 반드시 백업을 위한 정보를 다른 디스크나 SQL 등 다른 보관소에 저장해야합니다.

어? D12는 200기가 라는데 D드라이브는 32기가에요!
네 맞습니다. 200기가 전체 디스크 용량 중 32기가만 SSD입니다.
아쉽죠? 아쉽습니다.

YJ

Advertisements

금주의 Azure 질답 – 201603 첫째주

1년을 인생의 100으로 치면, 52주 중에 오늘은 11주차입니다.
즉, 벌써 인생에 21%가 지난 셈이죠.
한 주를 보낼 때마다 인생의 2%가 지나는거고요.

그런데 제가 하는 일은 아직 21%가 안되었는데 어떻게하나 싶네요.
뭔가 알 수 없는 조바심도 드는 요즘입니다.

1. Azure Role이 스케일링할 때 리스타트됩니다.

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

상당히 고급스러운 질문입니다. Azure Role은 스케일업을 시작할 때 스케일링하는 원본이 리사이클을 하는 특징이 있습니다. 즉, 복제 직전에 초기화를 수행하는 것이지요.

이것을 방지하려면? 후후…인스턴스 최소를 2개로 하면 됩니다.

하나로 안돼? 두 개 띄우면 그만.
하나로 안돼? 두 개 띄우면 그만.

이런 특징으로, 만일 인스턴스가 2개에서 3개가 된다면, 확장하는 순간에는 인스턴스 1개만 구동하는 셈이 됩니다. 그 순간이 그리 길지는 않을지라도 말이죠. 최악의 경우 리스타트에 10분 가량이 소요될 수도 있습니다.

그러니 결론은! Role을 사용할 경우 최소 2개를 사용하는 것이 안정적인 서비스를 보장한다는 겁니다. 그냥 ‘두 개면 좋잖아’라는게 아닌 이런 인프라의 특성도 있습니다.

2. Azure Role 인스턴스 스케일링에 Topology Blast가 뭔가요?

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

저도 이런 질문을 통해 공부합니다.

Azure 클라우드 설정 파일인 csdef 파일에 topologyChangeDiscovery=”Blast” 속성을 추가하면 뭔가 드라마틱한 변화가 있는데요, Role 하나가 다운된 후 복구되었을 때 모든 인스턴스에 새 인스턴스의 생성을 알려주는 이벤트(RoleEnvironment_SimultaneousChanging/-ed)가 발생합니다.

그렇지 않은 기본 설정은 하나가 다운된 후 복구되었을 때 IP 갱신이 동기화가 늦어서 인스턴스간 통신에 오류가 발생할 수도 있습니다.

그림으로 보면 아래와 같습니다.

일반적인 인스턴스 복구 상황
일반적인 인스턴스 복구 상황

위 그림은 IN_1이 잘못된 IN_2 내부ip를 가지고 있기 때문에 인스턴스간 통신이 필요할 때 문제가 발생할 수 있습니다.

Topology Blast 모드가 적용된 복구 상황
Topology Blast 모드가 적용된 복구 상황

하지만 위 그림은 일종에 코디네이터(Fabric Controller)가 모든 인스턴스에게 변경 이벤트를 보내고 참조 ip를 변경합니다.

그러면 이렇게 질문할 수 있습니다. 왜 불안한 설정이 기본값인가요? 제 생각에 그 이유는, 롤이 리스타트 되는 경우가 잦을 경우 (개발자의 코드 오류 등) 끝없이 정상적인 인스턴스들에게 변경이벤트가 전달되기 때문이라고 봅니다. 충분히 안정화된 다음에 적용하는게 좋다는거죠.

실제로 롤을 처음부터 안정적으로 운영하는 경우는 거의 없습니다. 안정화가 되기 전까진 계속 강제 리스타트를 시킬 일도 있지요. 저 역시 과거에 그런 문제를 겪었고요.

MSDN 문서의 마지막엔 “절대로 Blast 모드의 변경 이벤트에는 RequestRecycle(≒인스턴스 리스타트 수행) 코드를 넣지 말라”고 적혀있는데요.

만일 변경이벤트에 리사이클 코드가 들어가있다면 [인스턴스 하나 죽음 → 토폴로지블라스트! → 모든 인스턴스 리스타트 → 토폴로지블라스트! → 모든 인스턴스 리스타트 → 토폴로지블라스트! → …]

그리고 서비스는 무한리부팅으로 멸망했다
그리고 서비스는 무한리부팅으로 멸망했다

3. PHP로 Azure WebApp에서 업로드가 안됩니다

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

PHP든 ASP.NET이든 이 질문이 많습니다. 답을 말하기 전에, 만일 지금 하려는 시도가 단지 이미지 저장 같은 전통적인 것이라면, Azure Storage에 저장하도록 로직을 수정하는 것이 좋습니다. 아니, 그래야만 합니다. (단호)

WebApp 내부 공간은 정말 임시로 저장할 때만 사용해야 합니다. 만일 임시로 저장하는 용도가 아니거나, 삭제 로직이 없다면 WebApp 자체 용량이 가득차서 파일 입출력 전체에 문제가 발생합니다.

경로는 임의로 설정하지 마시고 Azure WebApp이 미리 가지고 있는 환경변수를 이용하세요.

%HOME%이 WebApp의 홈 디렉토리이며, d:\home 입니다. 웹사이트의 홈 디렉토리는 d:\home\site\wwwroot 입니다. 이 경로의 파일은 모든 인스턴스가 공유합니다. 이 공간은 Azure Storage에 기록하는 형태로 구현되어있기 때문입니다. Free/Shared tier의 경우 1기가를 제공하며, Basic tier 10기가, Standard 50기가를 제공합니다.

한편, 임시 디렉토리의 경우 인스턴스간 독립적입니다. 하지만! WebApp을 리스타트하면 모두 사라집니다. 그러므로 절대로 저장 용도로 사용하지 마시기 바랍니다. 용량은 Free/Shared tier는 인스턴스마다 300메가가 제공되며 그 외는 ‘꽤 많이 제공된다’라고만 나와 있습니다.

YJ

금주의 Azure 질답 – 201602 넷째주

추위도 점점 사라져갑니다. 벌써 2월의 마지막이네요. 곧 벚꽃이 날리겠죠.

요즘 느끼는건, ‘집중력 총량의 법칙’입니다. 웹서핑을 많이 한다고 해서 줄여봤자 다른 딴짓을 그만큼 한다는거죠. 그래서 딴짓을 많이 하는 스스로에게 반성을 많이 하지만 하루가 지나면 ‘나는 언제나 산만하구나’라는 생각도 합니다.

저는 stackoverflow에서 azure 태그로 오는 질문을 이메일로 구독하는데, 작년 중순부터 질문이 급격히 늘어남을 느낍니다. 이용자가 많이 늘어나는 것 같습니다.

1. VMDepot 소개

원본링크: http://stackoverflow.com/q/35646939/361100

Azure든 AWS든 착한 사람들(?)이 미리 만들어놓은 VM 이미지들이 있습니다. 대표적으로 bitnami가 있지요. 이런 이미지들은 포털에 보이는 것 외에도 공유된 곳이 있는데 바로 VMDepot입니다.

공개이미지들 목록: https://vmdepot.msopentech.com/List/Index

대부분은 포털에서도 검색되지만 아닌 것도 있으니 (특히 리눅스 기반 솔루션이라면) VM을 만들기 전에 꼭 한 번 검색해보길 권합니다. Docker 기반으로 만들어진 것도 많습니다.

2. Azure를 무료로 배우고 싶어요

원본링크: http://stackoverflow.com/q/35678468/361100

좋은 질문입니다. Azure는 매우 방대한 기능을 가지고 있으므로 WebApp 하나 올려본다는 식의 대답은 좋은 답변이 아닌 것 같습니다. WebApp을 원하지 않는 유저도 있을테니까요.

직접 사용하면서 배우고 싶은 경우, 링크의 답변(가입 직후 무료 사용권, 에뮬레이터 사용 등) 외에 최근들어 한국마이크로소프트에서는 Azure 크래딧(상품권)을 경품으로 주곤 합니다. 그러니 광화문 한국마이크로소프트에서 하는 각종 기술 행사에 참석하시면 당첨 확률이 높아집니다.

3. WebApp에서 SMTP로 메일 보내고 싶은데 안되나요

원본링크: http://stackoverflow.com/q/29238054/361100

일단, 의도적으로 Azure에서 SMTP를 막는 것도 있습니다. 이유는 이것이 허용되면 세계에서 가장 큰 스팸메일발송기가 될 우려가 있기 때문이지요. 링크의 답은 hotmail을 SMTP로 하면 가능하다는데 언제 막힐지 모르고요.

그래서 SMTP를 서버에서 직접 구성해서 보내는 것은 매우 비추천합니다. Azure에서는 IP가 유동적으로 바꿀 수 있고 SMTP를 위해서 Reserved IP를 하는 것도 용도에 비해서는 과하기 때문입니다.

그 대신 서비스형인 SendGrid 또는 Mailgun, MailChimp 같은 것을 사용하시기 권합니다.

서비스형을 사용하더라도 두 가지를 꼭 하셔야 하는데,

  1. 고정 IP 레벨의 서비스를 사용하셔야 합니다: SendGrid에는 “PRO”라는 과금모델부터 “Dedicated IP”를 제공하므로 이 이상으로 하셔야 합니다. 안해도 되지만 전송 성공률이 한국 서비스(네이버, 한메일 등)에서 매우 떨어지게 됩니다.
  2. KISA에 white domain 등록을 하셔야 합니다: https://www.kisarbl.or.kr/ (놀랍게도 안전하지 않은 인증서오류가 있군요) 사이트로 가셔서 등록하셔야 하는데 IP 주소로 등록하게 됩니다. 위 1번에서 할당받은 IP 주소를 넣으시면 됩니다.

YJ

금주의 Azure 질답 – 201602 셋째주

아…시간 참 빠릅니다.

내가 짜는 코드는 비루하기 그지없는데 시간만 가니까 초조해지네요.
오늘은 VM에 대한 질답 몇 가지를 나눕니다.

1. VM에 고정 IP 할당을 하고 싶어요

원문링크: http://stackoverflow.com/q/28454255/361100
VM에 IP를 할당하는 것을 Reserved IP라고 합니다. IP 설정 같은 네트워크 작업은 VM을 생성할 때 만들어주는 것이 가장 속편하겠지요. 하지만 이미 운용 중인 VM인 경우에도 아래 명령어로 처리할 수 있습니다.

New-AzureReservedIP -ReservedIPName "ipname" -Location "West US" -ServiceName "somevm"

위의 스크립트는 새로운 IP를 받아서 만드는 것이고 이미 IP가 있다면 아래 명령어를 이용해서 기존 VM에 설정 가능합니다.

Set-AzureReservedIPAssociation -ReservedIPName MyReservedIP -ServiceName TestService

그래도 안되면? 디스크를 남기고 VM을 새로 생성해보는 것도 방법입니다. VM 운용 중엔 종종 리부팅에서 안깨어나는 문제 등으로 디스크를 남기고 VM만 만들어 붙이는 일이 일어나곤 합니다.

2. VM 리부팅했는데 안깨어나요ㅠㅠ

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

클라우드를 쓰면 어디나 그런 해프닝이 일어나곤 합니다. 해결법은 VM을 다시 생성하는건데, 논리적으로 VM을 ‘다시 생성’하는 것은 여러 방법으로 가능합니다. 원문의 방법은 VM의 사이즈를 변경하는 것으로 처리했군요.

VM 삭제. 파란 동그라미를 체크안한 상태로 두면 디스크는 남겨집니다
VM 삭제. 파란 동그라미를 체크안한 상태로 두면 디스크는 남겨집니다

저는 위 그림처럼 디스크를 남겨놓고 VM을 삭제한 후에 그 디스크로 VM을 새로 만드는 방법을 주로 사용합니다.

이건 사소한 팁인데, Azure는 Ubuntu 쓸 때 VM이 안돌아오는 문제가 종종 있었고 CentOS에서 훨씬 안정적이었습니다. 그러니 Azure에서 리눅스를 선택하실 때 가급적 CentOS를 하세요.

3. VM 껐는데 과금이 되었어요

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

Azure VM을 Stop 하면 과금이 되지 않습니다. 또한, 그 VM을 올린 Cloud Service도 과금이 되지 않습니다. 과금이 되는 것은, 그 VM의 디스크 스토리지입니다. VM의 디스크는 그 VM이 차지한 스토리지 용량의 Page Blob 계산 기준으로 과금됩니다.

Page Blob 과금표: https://azure.microsoft.com/en-us/pricing/details/storage/

YJ

금주의 Azure 질답 – 201602 둘째주

오늘은 Azure WebJob에 대한 내용을 공유합니다. 참고로 WebJob은 Azure WebApp 제품군 내에 있는 백그라운드 워커입니다.

저는 Azure WebJob을 테스트용으로만 쓰고 프로덕션에서는 사용하지 않는데 그럼에도 종종 다루는 이유는 (1) 아직 미숙할 뿐이지 나쁜게 아니라서 관심을 가지는 것은 좋기 때문이며, (2) Azure 팀에서 WebJob에 공을 많이 들이고 발전 속도도 빠르기 때문입니다.

다시 말해, WebApp은 이제 발전할거라곤 모니터링 보강과 프레임워크 버전 향상 말고는 딱히 없는데 WebJob은 MVP들의 의견도 활발히 받고 GitHub 이슈에도 즉각적으로 반응하고 있습니다.

WebJob은 뭐랄까…애증의 존재죠. 아 쫌만 더 좋으면 쓰겠는데 아직 약간 부족한 느낌이 드는. 그 부족한 느낌은, 컨셉이 아닌 모니터링과 관리에 대한 이슈입니다. 이게 도는지 안도는지 확신이 잘 안드는거죠.

1. Azure WebJob에서 지원되는 닷넷프레임워크 버전은 무엇인가요?

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

저도 최신버전이 나오면 별 생각없이 업그레이드 하는 편입니다만, WebJob은 현재 4.6까지 지원됩니다. 최신 닷넷프레임워크인 4.6.1은 안됩니다.

문제는 배포 실패로 안뜨고 일단 실행은 되는데 에러메시지가

Job failed due to exit code -2146232576

위에처럼 나옵니다. 하지만 곧 4.6.1이 지원될 예정이랍니다.

2. Azure WebJob을 staging에서는 안돌리고 싶어요.

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

WebApp은 여러개의 deployment slot을 가질 수 있고 이는 staging/production을 swap할 때 유용합니다. staging 상태에서는 돌지 않게 하려면

WEBJOBS_STOPPED = 1

위와같이 configuration을 넣어두면 됩니다.

추가로 이용할 수 있는 Configuration은 아래 링크에 있습니다.
https://github.com/projectkudu/kudu/wiki/Web-jobs#configuration-settings

3. WebJob이 중간에 멈춰요.

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

Triggered-mode WebJob의 실행 허용시간은 기본적으로 60초입니다. trigger로 실행된 WebJob의 경우, 60초 후에 프로세스가 끝났는지를 보고 n초 후에 종료시킵니다. 그래야 다음에 올 트리거를 받을 수 있을테니까요.

조절할 수 있는 시간은 ‘끝났는지 확인하는 60초’를 바꾸는 것이 아니라 ‘안끝났을 때 기다리는 n초’입니다. 최대 얼마까지 가능한지는 문서에 나와있지 않지만 10분은 넘는 것으로 압니다.

Continuous-mode WebJob의 실행 허용시간은 딱히 제한은 없습니다. 무한루프로 구현되기 때문이지요. 다만 어떠한 이유로 중지시킬 때는 미리 알려주는 장치가 있습니다.

WebJob의 환경변수인 WEBJOBS_SHUTDOWN_FILE에 지정된 파일을 작성하는 것이지요. WebJob이 강제종료하기 전에 파일이 생성되고, 우리가 만든 무한루프 로직은 이 파일이 생성되었는지 FileWatcher를 통해 확인한 후 무한루프를 종료하는 방식으로 작성하면 보다 안정적인 WebJob을 구현할 수 있습니다.

Azure 개발팀에 있는 Amit Apple 님의 코드를 빌려오자면 아래와 같습니다.

public class Program
{
    private static bool _running = true;
    private static string _shutdownFile;

    private static void Main(string[] args)
    {
        // Get the shutdown file path from the environment
        _shutdownFile = Environment.GetEnvironmentVariable("WEBJOBS_SHUTDOWN_FILE");

        // Setup a file system watcher on that file's directory to know when the file is created
        var fileSystemWatcher = new FileSystemWatcher(Path.GetDirectoryName(_shutdownFile));
        fileSystemWatcher.Created += OnChanged;
        fileSystemWatcher.Changed += OnChanged;
        fileSystemWatcher.NotifyFilter = NotifyFilters.CreationTime | NotifyFilters.FileName | NotifyFilters.LastWrite;
        fileSystemWatcher.IncludeSubdirectories = false;
        fileSystemWatcher.EnableRaisingEvents = true;

        // Run as long as we didn't get a shutdown notification
        while (_running)
        {
            // Here is my actual work
            Console.WriteLine("Running and waiting " + DateTime.UtcNow);
            Thread.Sleep(1000);
        }

        Console.WriteLine("Stopped " + DateTime.UtcNow);
    }

    private static void OnChanged(object sender, FileSystemEventArgs e)
    {
        if (e.FullPath.IndexOf(Path.GetFileName(_shutdownFile), StringComparison.OrdinalIgnoreCase) >= 0)
        {
            // Found the file mark this WebJob as finished
            _running = false;
        }
    }
}

더 자세한 내용은 WebJob을 개발하고 있는 분의 블로그를 확인해보세요.
http://blog.amitapple.com/post/2014/05/webjobs-graceful-shutdown/#.VNqThvmG8oc

추가로, 아래 링크에서 WebJob을 모니터링하는 방법에 대하여 알려줍니다.

http://jasonhaley.com/post/Monitor-the-Status-of-an-Azure-WebJob

4. Continuous WebJob 실행주기를 설정하고 싶어요.

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

기본적으로 Continuous WebJob의 인터벌은 5초입니다. 이를 변경하는 방법이 나와있습니다.

사실 이것을 구현하기 위한 방법은 세가지가 있습니다.

  1. 제가 즐겨쓰는건데, Azure Scheduler를 이용해서 WebApp에서 GET을 불러주는겁니다. 네, WebJob을 쓰지 않는거죠.
  2. 전통적인 Thread.Sleep이나 Task.Delay를 쓰는 경우 (링크의 채택된 답변)
  3. WebJob Timer Extention을 이용하는 경우: http://stackoverflow.com/a/34963841/361100 사실 2번 방법인 Thread.Sleep은 기계어 실행을 중지하고 CPU 카운트만 돌리는 것이므로 의도한 지연 실행과는 다른 의미라고 할 수 있습니다. ‘결과가 같은거니 그냥 쓴다’는 셈이죠. 그러므로 WebJob을 위해 만들어진 이 방법을 추천합니다.

YJ

금주의 Azure 질답 – 201602 첫째주

구정 연휴에 스타벅스에서 쓰는 첫 글이군요.
스타벅스에서는 언제나 “오늘의커피+톨사이즈+머그컵에 주세요”라고 주문하는데 다 마신 후엔 뜨거운 물을 담아서 손을 녹이곤 합니다.

아주 초창기의 미숙했던 Azure 부터 믿고 쓰는 것이 몇 개 있는데 Notification Hub, Storage, Service Bus 입니다. 여느 클라우드에도 있는 것들이지만 개발자에게 신뢰할만한 품질을 주는 경험은 어려운 겁니다. 종종 이야기하지만 저는 Azure를 선택한 이유가 (당시엔) Amazon S3가 너무 느렸기 때문이었으니까요.

오늘은 이 중에서 Azure Notification Hub와 Azure Storage 두가지에 대한 가장 흔한 질답 몇가지를 나눕니다.

1. Azure Notification Hub의 tag 갯수는 몇 개까지 만들 수 있나요?

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

Azure Notification Hub(이하 ANH)는 이기종 푸시 서비스를 일원화하여 관리할 수 있는 푸시 미들웨어입니다. 각 디바이스의 토큰을 ANH 자체의 토큰으로 대체하여 발급하고 각 엔트리에는 태그를 이용하여 구분하는 방식입니다.

이로써 얻는 장점은, 태그를 유저 ID로 할 경우 한 번의 전송으로 그 유저의 모든 기기에 동일한 푸시를 전달할 수 있다는 것입니다. 로케일 태그를 붙이면 전체 공지를 각 언어로 구분하여 보낼 때 좋지요. 저희는 그래서 등록과정에 로케일과 유저ID를 필수로 기입합니다.

질문에 대한 답으로, 태그는 총 1만개(10K)까지 등록이 가능합니다.

부가적인 질문으로, (1) “어? 그럼 그 이상은? 유저 10만명 넘으면 푸시 안가는거임?” 그에 대한 답은, “namespace를 다음 것으로 사용하면 됩니다. (=새 ANH를 만드세요)” 즉, 유저넘버 10만 이상은 새로운 ANH를 만들고 그것으로 보내도록 분갈이 해줘야하지요. 별거 문제 없습니다.

unique 태그 갯수는 3천개(3K) 입니다. 또 나올 질문은 (2) “뭐임? 유저 3천명 이상은 안된다는거임?” 그에 대한 답은, “아니요. 5개 이하의 기기에 등록된 태그는 제한이 없습니다”

또 나올 질문은, (3) “응? 그럼 6개 기기가 있는 유저는?” 그에 대한 답은, “마지막 것을 삭제하시면 됩니다” 제 소견은, 한 유저가 기기 6개에 깔아 쓰는건 서비스제공자 입장에서 푸시가 낭비되는 경우라고 생각합니다.

글에 추가된 다른 정보로는, tag에 대한 쿼리는 OR 검색만 있으면 20개까지, 그 외에 AND, NOT이 섞이면 6개까지만 사용할 수 있다고 합니다. 즉, 아래와 같이 필터링 시키는거죠.

locale='koKR' AND gender='male' AND age='20s' OR age='30s' NOT notification='silent'

2. Azure Notification Hub의 tag 형식은 무엇인가요?

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

저처럼 공식문서부터 읽는 사람들에겐 별로 없을 질문이지만, 일단 코딩해서 돌려보자는 분들에게는 나올 질문이지요.

ANH의 태그 형식은 120자 제한, 알파벳, 숫자, ‘_’, ‘@’, ‘#’, ‘.’, ‘:’, ‘-‘ 허용입니다. 그리고 공식문서에는 표기가 잘 안되어있는데 대소문자를 구분하지 않습니다(case-insensitive).

3. Azure Storage에 있는 이미지파일에 접근 권한을 설정하고 싶어요.

원문링크: http://stackoverflow.com/a/14167775/361100

십여년 전에는 이를 위해서는 웹서버가 요청을 받아서 리퍼러를 체크한 후 이미지 주소를 출력시키곤 했습니다. Azure Storage에는 Shared-Access Signature (이하 SAS)라는 장치가 있습니다. SAS는 코드로 접근 권한을 설정한 후 생성하는 주소로 토큰을 포함하고 있습니다. 예를 들어, 10분 동안 접근 가능한 주소를 접속 때마다 만드는 것이지요.

이에 대한 토큰 생성 방법은 아래의 링크에 있습니다.
https://azure.microsoft.com/ko-kr/documentation/articles/storage-dotnet-shared-access-signature-part-2/

이럴 경우 캐시에 대한 의문이 생기는데 그에 대해서는 캐시 정책까지를 헤더에 포함시키는 설명이 아래 링크에 있습니다.
http://social.technet.microsoft.com/wiki/contents/articles/25528.azure-blob-storage-and-effective-use-of-cache-control-property.aspx

SAS만으로 해결하기 시나리오가 있는데 리퍼러를 체크하는 경우입니다. 최악의 경우엔 야동이 올라오고 10분만에 3만명이 접속해서 보는 경우가 되려나요? 그러니 토큰 관리에 모두 조심합시다.

YJ

금주의 Azure 질답 – 201601 마지막주

아니 벌써 1월이 끝났다니.
이런 기분으로 앞으로 11번 반복하면 1년이 지나겠죠.

WordPress.com이 개편 중에 있다보니 마크다운으로 작성하다가 다시 편집하면 html 태그로 바꿔놔서 긴 글을 쓰기 힘들군요. 저장 직전에 메모장에 복사했다가 수정할 때 다시 붙여넣고 있습니다.

1. Azure Search와 Elastic Search는 뭐가 달라요?

원문보기: social.msdn.microsoft.com/Forums/azure/…

Azure Search는 Search-as-a-Service를 표방하고 나온 Azure의 SaaS(Software-as-a-Service) 중 하나입니다. 그 기반으로는 실제로 Elastic Search(이하 ES)를 사용하고 있습니다.

ES를 한겹 더 감싸서 OData 형식으로 노출하고, 유저들에겐 관리 편의를 제공한다고 보시면 됩니다. 관리 편의 중에서는 샤딩 뿐만 아니라 액세스 관리 등 보안도 포함되지요.

검색을 클라우드로 하는 것은 뭐가 좋은가요? ‘클라우드적인 의사결정’에서 중요한 것이 있다면, 소프트웨어를 구현한 것과 이를 스케일업하는 것은 완전 다른 이야기라는 것입니다. Elastic Search도 소량만 운용하면서 ‘우린 ES로 검색기술을 쓴답니다’하는 것과 스케일업/아웃하면서 모든 것을 차질없이 운용하는 것은 다른 이야기가 되는 것이겠지요.

Azure Search Scalability
Azure Search Scalability. (출처: Channel9)

스케일이나 글로벌 대응을 고려하지 않으면 클라우드는 허세고 카페24같은 로컬호스팅 쓰는게 제일 싸고 좋습니다.

각설하고, Azure Search는 현재 성숙한 상태는 아닙니다. 그러므로 지원되는 장점보다 지원 안되는 단점이 큰 상태라고 생각합니다. ES에서 되지만 Azure Search에는 없는 것은 아래와 같습니다.

  • Index Schema는 미리 알려줘야 함: 자동으로 인덱싱을 하는 기능이 없습니다.
  • Array 형태는 index 안됨: 지원되는 형태에 없답니다.
  • Re-indexing 안됨: index schema 변경시 re-indexing은 안되고 다시 데이터를 올려줘야 합니다.
  • ES용 플러그인 안됨: Azure Search는 ES를 기반으로만 사용할 뿐이므로 현재 ES에 제공되는 플러그인이 지원되지 않습니다. 하지만 ES 플러그인들의 모방 프로젝트들이 계속 생겨나고 있습니다. 예를 들어, Fluent 형식으로 쿼리할 수 있게 하는 RedDog.Search 프로젝트가 있지요.
  • Form body로 보내는 복잡한 쿼리 안됨

단점을 보면 이것이 적합한 서비스는 (1) 데이터 구조가 단순하고 (2) SQL Azure, DocumentDB 등 Azure 기반으로 축적된 데이터에 검색기능을 넣기 위해 (3) 간단한 검색 요구사항 대비 강력한 기능을 가장 빨리 적용하고 싶을 때 유용하다고 판단할 수 있겠습니다.

Azure Search에 대한 맛보기로는 아래 동영상보다 친절한 것은 없어보이더군요.
https://channel9.msdn.com/Events/Microsoft-Azure/AzureConf-2014/Search-Like-a-Pro-with-Azure-Search?ocid=player

2. Azure WebApp, WebJob에서 그 호스트의 주소를 어떻게 알아요?

원문보기: http://stackoverflow.com/q/35088567/361100

WebApp은 몇 개의 환경변수를 미리 정의하고 있는데 그 중 WEBSITE_HOSTNAME를 사용하면 자신이 호스팅 된 WebApp 주소(*.azurewebsites.net)를 알 수 있습니다. 배포할 때 이용하면 주소를 하드코딩하지 않아도 되므로 좋습니다.

WebJobs는 자신이 실행되는 폴더 경로 등의 환경 변수도 있습니다.

3. Azure WebJob과 WebApp API는 어떻게 통신해요?

원문보기: http://stackoverflow.com/q/31114346/361100

이 질문은 꽤 많이 나옵니다. 그도 그럴 것이, WebApp이라는 것이 사실 WebJob이 한 몸처럼 보이는데 한 몸이 아니기 때문이지요.

WebApp에서 요청받은 쪽(프론트라고 부르겠습니다)이 WebJob을 직접 실행하거나 결과를 즉시 받아서 처리하는 방법은 없습니다. 그 이유는, WebJob은 요청을 받는 프론트와 구조적으로 별개로 동작하기 때문입니다. 즉, 요청받은 쪽에서 WebJob을 트리거하는 방법도 없습니다.

해결 방법 중 대표적인건 Azure Queue를 사용하는 것입니다. 프론트에서 Azure Storage Queue에 값을 넣으면 WebJob이 이를 Trigger로 받아서 처리하는 것이지요.

하지만 여기에도 함정이 있는데, WebJob에서 Azure Queue Trigger로 작성해도 실제로는 트리거가 아니라 polling을 몇 번 하다가 얻어걸리는(?) 것입니다. 그러므로 바로바로 된다고 말할 수 없습니다.

물론 컴퓨터 통신에서 trigger라고 하는 많은 것은 사실 촘촘한 polling이지만, WebJob은 게을러서 트리거 몇 번 해보다가 얻는게 없으면 polling 주기마저도 늦춥니다.

그러므로 시간이 민감한 백그라운드 작업이라면 배포가 느리더라도 WorkerRole을 사용하는 것이 좋습니다. 시간에 민감하지 않은 통계 등에는 WebJob의 가격이 저렴하니 괜찮은 선택입니다.

그 외에 WebJob에서 프론트를 호출하는 방법 중 SignalR을 이용하여 WebJob에서 처리되는 진행률을 표시하는 샘플도 있는데, 저는 이것을 보고 ‘아 이렇게 구현할 수도 있구나’ 했습니다.