눈물겨운 예산 맞추기. Azure 프론트도어 이관하기

백만년만에 새 글이야.

마지막 글이… 8월 22일이네.

해커톤 예선에서 떨어지고, 시간을 갖는다는게 너무 오래 가져버렸다.

8월 말에 출장을 갔다가(도대체 나는 왜 가는건지…) 시간이 좀 남아서 Azure Startup 크레딧 현황을 좀 정리했다.

5000달러 크레딧이 이제는 거의 다 소진되어 1500달러 정도 밖에 안남아있었는데, 대시보드를 돌아다니는 중에 알림이 하나 떴다.

“당신의 스타트업 크레딧이 승인되었습니다. 5000달러 크레딧이 지급됩니다.”

…?

나는 이미 4월에 이 5000달러 크레딧을 받았고, 그 때 당시에는 티어 2로 6개월의 만료 기간을 함께 받았다.

그래서 10월 말에 만료가 되는 일정이었는데… 갑자기 크레딧이 들어왔다는 알림이 떴고, 만료일이 10월에서 내년 4월로 또 6개월 정도가 연장이 되었다.

사실 나로써는 굉장히 기쁜 소식이지만… 뭔가 쎄했다.

왜 지금… 어떤 이유로 받은거지?

그래서 문의를 좀 해보니, 기쁜 소식은 만료일 연장은 실제로 일어난 일인데… 반면에 크레딧은 실제로 지급되지 않았다.

Support 에 따르면, 내가 처음 4월에 이 크레딧을 신청할 때 봇 심사에서 알 수 없는 이유로 stuck이 되고, 다시 문의해서 담당자가 수동으로 크레딧을 넣어줬었다.

그 떄 같이 시작됐어야 할 스타트업 티어2 타이머가 수동 지급으로 인해 시작되지 않았고, 이제서야 문제를 파악해서 시작됐다는 것.

결국 보상의 의미로 만료일을 더 늘려주긴 했지만… 여전히 크레딧은 그대로인 것이다.

---

문제는 여기서 발생한다.

나는 스타트업 마일스톤 티어3를 노리고 있었다.

이건 지금 5000달러 + 6개월인 내 크레딧에서 5개 이상의 워크로드를 60일간 꾸준한 사용을 하면 25000달러 + 2년의 만료일을 다시 주는 일종의 업그레이드다.

내 생각으로 내가 5개 이상의 워크로드를 지속적으로 사용한지 100일은 넘은거 같은데… 이상하게 업그레이드가 안돼서 몇 번 문의를 했었다.

지금 보니… 스타트업 크레딧 타이머가 아예 시작을 안했으니.. 이 마일스톤 3티어 타이머도 같이 멈춰있지 않았다 싶다..

그러니까 진짜 문제는… 지금 시점에 이게 다시 시작된다고 하면, 업그레이드가 될 60일 뒤까지 현재 내 남은 크레딧이 버티질 못한다.

1600달러 정도 남았고, 현재 하루 45달러 정도의 지출이 있다.

대충 계산을 때려봐도… 겨우 한 달 남짓 사용할 수 있는 양이다.

그래서 마일스톤 업그레이드까지 어떻게든 버틸 전략을 좀 짜야했다.

프론트도어: ㅋㅋ;; ㅈㅅ;;

지금 요금 상황을 보면, 네트워킹이 하루 12달러 정도씩 나가는데.. 이게 사실 굳이 이럴 필요가 없다.

내가 이 블로그를 셋팅하면서 컨테이너앱에 커스텀 도메인을 달아야 하는데, 그 도메인의 네임서버가 AWS Route 53 이여서… 그걸 변경해야 하는데, 운영 중인 주주 때문에 나름 우회한다고 앞단에 놓은 건데…

(물론 인증서나 DDos 막아주는 것도 편하긴하다)

문제는 그 때는 이게 프리미엄이 이렇게 비쌀 지 예상을 못했다.

진즉 스탠다드로 바꿨어야 했는데…

친구의 모바일 청첩장, 이 블로그, 주주까지 3개의 서비스가 함께 사용을 하다보니.. 작업 시간 동안의 다운타임이 걸려서 자꾸만 미뤘었다.

한 달만 덜 미뤘어도, 300달러는 아꼈을텐데… 내 게으름이 또 한 건 했다.

그래서 시작된 Front Door 이관.

새벽 1시부터 2시간 정도를 잡고 시작했다.

계획은 대충 이랬다.

1. 새 Standard FD 프로파일 만들고 endpoint, origin, route, WAF 준비
2. Gabia 에서 NS 를 Route 53 → Azure DNS 로 옮기고 propagation 대기
3. 트래픽 적은 순서대로 도메인 세 개 이관 (청첩장 → 블로그 → 주주 API)
4. 실기기로 유저 플로우 최종 확인

Standard 쪽 준비랑 NS 이관까지는 예정대로 잘 굴러갔다.

새벽 02:15 쯤 여기까지 끝났고, 나는 “오늘 3시 반이면 다 끝나겠는데?” 라고 생각했다.

이제 본격적으로 기존 FD에서 라우팅과 도메인을 삭제해주고 새로운 FD에 이관하면 끝인데.. 여기서부터가 앱 다운타임이니 조금 쫄리긴 했다.

장비를 정지합니다… 안되잖아?

세 도메인을 옮기는 것 자체는 큰 일이 아니었다.

문제는 옛 Premium FD 에서 기존 도메인이랑 라우트를 삭제하는 것이 도메인 하나당 무슨 30분씩 걸렸다.

route 참조도 다 뗐고, WAF 참조도 다 뗐는데 “Deleting” 상태에서 안 넘어갔다.

Portal 에서 F5 눌러봐도 그대로였다. 20분이 지나고 25분이 지나도 그대로였다…

이미 이전에 정적웹앱에서 커스텀 도메인의 삭제가 3일 동안 안되고, 기술 서포트를 불러서 겨우 해결했던 전적이 있어서…

이 다운타임이 73시간이 될까봐 너무.. 진짜 너무너무 불안했다.

그러다가 딱 30분이 넘어가니까 하나가 삭제됐다.

stuck은 아니라는게 너무 기뻤지만.. 이미 쓴 시간이 1시간이 넘었다.

Standard 쪽에도 조용한 문제가 하나 있었다

블로그를 새 Standard 쪽으로 옮기고 curl 을 쳤더니 이런 응답이 왔다.

HTTP/2 404
x-azure-ref: [ref-id]

파란 배경으로 “Page not found — Oops! We weren’t able to find your Azure Front Door Service configuration” 라고 떴다. Front Door 표준 404 페이지였다.

이상한 게 있었다. x-azure-ref 헤더가 붙어있었다.

즉 요청은 FD 까지는 도달했다는 얘기다.

근데 커스텀 도메인이랑 라우트 매핑이 엣지에 배포가 안 됐다. CLI 로 상태 조회를 하니 deploymentStatus 가 NotStarted 로 찍혀 있었다.

문서를 뒤져보니 route property 를 실제로 변경하면 재배포가 트리거된다고 나왔다. --https-redirect Disabled → Enabled 로 토글해줬더니 30초 뒤에 200이 돌아왔다.

블로그는 이렇게 넘어갔는데, 주주 API 에서는 이 토글이 안 통했다.

• --https-redirect 토글 → 안 통함
• --forwarding-protocol 다른 값도 → 안 통함
• --custom-domains "" 로 detach 시도 → CLI parse 에러

새벽 04시 반이었다. 주주 다운타임이 2시간을 넘어가고 있었다.

마지막 카드로 Portal 에서 수동으로 도메인 체크를 해제했고, 30초 대기했고, 다시 체크했다. 2분 뒤에 200 이 나왔다.

Portal API 랑 CLI API 가 다른 큐를 쓰는 것 같았다.

아오… 그놈의 토글시치;; 뭔 맨날 수동 업데이트를 해줘야하니 뭔… Azure를 많이 안쓰는데는 이유가 있나보다.

마치며

새벽 5시가 됐다. 3 도메인 모두 200이 나왔다. 모바일 앱으로 유저 플로우도 다 확인했다.

계획보다 2시간 30분 정도… 초과했지만, 어쨌든 이관은 끝났다.

침대로 들어갔다. 바로 그 날 오후 2시에 결혼식을 하나 가야하는데… 진심 계좌로만 보낼까 생각했다.

이관하고 나니 월 260달러 정도가 절감됐다.

어찌어찌 내 돈 조금만 태우면 티어3 까지 크레딧 60일 버티기 목표는… 대충 가능할 거 같았다.

마침.