금주의 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에서 처리되는 진행률을 표시하는 샘플도 있는데, 저는 이것을 보고 ‘아 이렇게 구현할 수도 있구나’ 했습니다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중