왁뮤 3.0 출시 및 장애 대응 기록

2024년 9월 7일(토), 왁타버스 뮤직 3.0 출시와 함께 발생한 장애를 포함한 이벤트들을 타임라인 순으로 기록하려고 합니다.

 

출시 일정

우선 출시 계획은 다음과 같았습니다.

오후 5시: 서버에서 진입 금지 플래그 설정
오후 5시 30분: 앱 배포
오후 6시: PV영상 공개 & 서버 진입 금지 플래그 제거

컨텐츠 유출을 막기 위해 서버에서 진입 금지 플래그를 설정해두고, 실제 앱 공개시간인 오후 6시로부터 30분 정도 여유를 두고 배포를 누르기로 했습니다.
그리고 6시에 PV 영상이 공개됨과 동시에 진입 금지 플래그를 제거해 유저들을 받을 계획이었습니다.

 

오후 5시 배포 시작

완벽한 계획과는 달리 시작부터 문제가 발생했습니다.
배포 당일에 계획이 수정되었지만, 예약 출시 시간을 변경하지 않아 5시에 배포가 시작되게 됩니다.

배포는 5시에 시작되었지만 앱스토어에 반영되기까지는 시간이 걸리기에,
오후 5시 16분에 앱스토어에 반영되었습니다.

하지만 서버에서 진입 금지 플래그를 설정해두었기에, 유출이 되는 문제는 막을 수 있었습니다.

 

오후 6시 PV영상 공개 및 진입 허용

그리고 오후 6시 PV영상이 공개되었고, 1시간 만에 2만 조회수를 찍을 만큼 반응이 좋았습니다.

궁금하신 분들을 위한 유튜브 PV 링크!

감사하게도 왁타버스 뮤직을 기다려주었던 팬들이 많아, PV영상을 통해 출시하자마자 사용자를 모을 수 있었습니다.

 

 

오후 6시 08분 앱 진입 불가 확인

오후 6시 08분 팀원으로부터 앱 진입이 안된다는 상황을 공유 받았고,
애널리틱스를 확인해보았는데 마침 비정상 종료가 찍혀있었습니다.
(사용자와 비정상 종료 수가 버그 제보 글과 활성 사용자 수에 비해 적어보이는데 이유는 모르겠습니다..?)

왁타버스 뮤직 iOS 앱은 앱 실행시 아래와 같은 흐름을 갖습니다.

앱 실행 -> 런치 스크린 -> 애니메이션 시작 -> 권한 확인 -> 앱 및 서버 상태 확인 -> 애니메이션 완료 -> 첫 화면 진입 

 

이 중 앱 및 서버 상태 확인은 서버에 API 요청을 보내고, 상태를 응답받는 형태로 구현되어 있습니다.
그리고 API의 기본 요청은 10초의 타임아웃을 가지게 되는데,

func defaultRequest(_ api: API) -> Single<Response> {
        return provider.rx.request(api)
            .timeout(.seconds(10), scheduler: MainScheduler.asyncInstance)
            ...
    }

앱을 실행시키면 약 10초 정도 뒤에 에러 팝업이 나타났습니다.

이를 통해 서버에서 응답이 도착하지 않아 타임아웃이 났음을 유추할 수 있었고, 서버에 문제가 있다고 의심할 수 있었습니다.

 

오후 6시 10분 서버 문제로 확인

오후 6시 10분경 백엔드 개발자님으로부터 서버 문제임을 전달받았습니다.

 

오후 10시 경 문제 해결 중..

도움이 되고 싶은데 백엔드에 대해 무지해 도움을 드릴 수 없어 슬펐습니다..

 

추가) 오후 10시 57분 문제 해결

닉네임 변경 로직에 문제가 있었던 걸로 확인 후 문제를 해결했다고 합니다ㅎㅎ

대 코코아..

 

장애 대응을 해보고 느낀 나의 생각

어디선가 그런 이야기를 들은 적 있습니다.
"장애 대응을 할 때 클라이언트 단에서 주로 하는 일은 서버에서 응답 확인을 요청하면 어떻게 넘어온다고 알려주는 일이 대부분이다."

 

실제로 경험해보니 그럴싸하다고 느껴졌습니다..😂

 

서버 문제라는게 확인이 된 이후부턴 크게 할 일이 없더라구요..ㅎ

 

제가 나름대로 나서서 한 일은, 애널리틱스를 확인하며 사용자가 얼마나 되는지, 비정상 종료가 얼마나 되는지 모니터링하고 데이터 수집이 정확하지 않을 수 있으니 카페나 베타테스터 채널의 사용자 반응을 보고 팀에 공유한게 전부였습니다.

(적고보니 꽤나 그럴싸하네요 🤔)

 

그래서 GPT에게 물어보았습니다.

Q: iOS개발자가 앱 배포일에 장애 대응을 위해 대기한다면, 어떤 일을 해야해?

A:

오.. GPT에 따르면 전 1, 3번 역할을 수행한 것 같네요..

 

사실 별거 없는 장애 대응을 기록한 이유는 문서화가 중요하다는 걸 느껴 적게되었습니다.
3.0 배포를 준비할 때 리젝을 미리 대응하기 위해, 2.0 배포의 히스토리가 궁금할 때가 있었습니다.

분명 당시에 리젝도 당하고, 저작권 관련 서류도 준비하며 많은 우여곡절이 있었던 것 같은데 기억이 흐릿했습니다ㅠㅠ

그 때 문서화의 중요성을 느끼고 적어야겠다 생각했습니다.

지금봤을 땐 별 내용이 아니더라도 시간이 지나며 기억이 흐릿해질 때 쯤 빛을 발할거라고 생각합니다.

더군다나 실제 현업에선 팀원의 교체가 잦고, 신규입사자들은 히스토리를 알아야하는데, 그럴 때 문서화가 되어있지 않으면 사수가 구두로 설명할 수 밖에 없기 때문에 히스토리들을 문서화하여 참고하도록 하기 위해서라도 문서화는 중요한 것 같습니다ㅎㅎ