금주의 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

Advertisements