[회고]왁뮤 3.0 출시 및 장애 대응 기록
2024년 9월 7일(토), 왁타버스 뮤직 3.0 출시와 함께 발생한 장애를 포함한 이벤트들을 타임라인 순으로 기록하려고 합니다.
출시 일정
우선 출시 계획은 다음과 같았습니다.
1
2
3
오후 5시: 서버에서 진입 금지 플래그 설정
오후 5시 30분: 앱 배포
오후 6시: PV영상 공개 & 서버 진입 금지 플래그 제거
컨텐츠 유출을 막기 위해 서버에서 진입 금지 플래그를 설정해두고, 실제 앱 공개시간인 오후 6시로부터 30분 정도 여유를 두고 배포를 누르기로 했습니다. 그리고 6시에 PV 영상이 공개됨과 동시에 진입 금지 플래그를 제거해 유저들을 받을 계획이었습니다.
오후 5시 배포 시작
완벽한 계획과는 달리 시작부터 문제가 발생했습니다. 배포 당일에 계획이 수정되었지만, 예약 출시 시간을 변경하지 않아 5시에 배포가 시작되게 됩니다.
배포는 5시에 시작되었지만 앱스토어에 반영되기까지는 시간이 걸리기에, 오후 5시 16분에 앱스토어에 반영되었습니다.
<img src=”/assets/img/post/2024/042.jpeg” width=50%>
하지만 서버에서 진입 금지 플래그를 설정해두었기에, 유출이 되는 문제는 막을 수 있었습니다.
오후 6시 PV영상 공개 및 진입 허용
그리고 오후 6시 PV영상이 공개되었고, 1시간 만에 2만 조회수를 찍을 만큼 반응이 좋았습니다.
<img src=”/assets/img/post/2024/043.png” width=50%>
감사하게도 왁타버스 뮤직을 기다려주었던 팬들이 많아, PV영상을 통해 출시하자마자 사용자를 모을 수 있었습니다.
오후 6시 08분 앱 진입 불가 확인
<img src=”/assets/img/post/2024/044.png” width=50%>
<img src=”/assets/img/post/2024/045.png” width=50%>
오후 6시 08분 팀원으로부터 앱 진입이 안된다는 상황을 공유 받았고, 애널리틱스를 확인해보았는데 마침 비정상 종료가 찍혀있었습니다. (사용자와 비정상 종료 수가 버그 제보 글과 활성 사용자 수에 비해 적어보이는데 이유는 모르겠습니다..?)
왁타버스 뮤직 iOS 앱은 앱 실행시 아래와 같은 흐름을 갖습니다.
1
앱 실행 -> 런치 스크린 -> 애니메이션 시작 -> 권한 확인 -> 앱 및 서버 상태 확인 -> 애니메이션 완료 -> 첫 화면 진입
이 중 앱 및 서버 상태 확인은 서버에 API 요청을 보내고, 상태를 응답받는 형태로 구현되어 있습니다. 그리고 API의 기본 요청은 10초의 타임아웃을 가지게 되는데,
1
2
3
4
5
func defaultRequest(_ api: API) -> Single<Response> {
return provider.rx.request(api)
.timeout(.seconds(10), scheduler: MainScheduler.asyncInstance)
...
}
앱을 실행시키면 약 10초 정도 뒤에 에러 팝업이 나타났고, 타임아웃이 났음을 알 수 있었습니다.
오후 6시 10분 서버 문제로 확인
<img src=”/assets/img/post/2024/046.png” width=50%>
추가) 오후 10시 57분 문제 해결
닉네임 변경 로직에 문제가 있었던 걸로 확인 후 문제를 해결했다고 합니다ㅎㅎ
<img src=”/assets/img/post/2024/047.png” width=50%>
<img src=”/assets/img/post/2024/048.png” width=50%>
장애 대응을 해보고 느낀 나의 생각
어디선가 그런 이야기를 들은 적 있습니다. 장애 대응을 할 때 클라이언트 단에서 주로 하는 일은 서버에서 응답 확인을 요청하면 어떻게 넘어온다고 알려주는 일이 대부분이다.
실제로 경험해보니 그럴싸하다고 느껴졌습니다..😂 서버 문제라는게 확인이 된 이후부턴 크게 할 일이 없더라구요..ㅎ
제가 한 일은, 애널리틱스를 확인하며 사용자가 얼마나 되는지, 비정상 종료가 얼마나 되는지 모니터링하고 데이터 수집이 정확하지 않을 수 있으니 사용자 반응을 보고 팀에 공유한게 전부였습니다.
(적고보니 꽤나 그럴싸하네요 🤔)
그래서 GPT에게 물어보았습니다.
Q: iOS개발자가 앱 배포일에 장애 대응을 위해 대기한다면, 어떤 일을 해야해?
A: 
오.. GPT에 따르면 전 1, 3번 역할을 수행한 것 같습니다ㅎㅎ
사실 별거 없는 장애 대응을 기록한 이유는 문서화가 중요하다는 걸 느껴 적게되었습니다. 3.0 배포를 준비할 때 리젝을 미리 대응하기 위해, 2.0 배포의 히스토리가 궁금할 때가 있었습니다. 분명 당시에 리젝도 당하고, 저작권 관련 서류도 준비하며 많은 우여곡절이 있었던 것 같은데 기억이 흐릿했습니다ㅠㅠ 그 때 문서화의 중요성을 느끼고 적어야겠다 생각했습니다. 지금봤을 땐 별 내용이 아니더라도 시간이 지나며 기억이 흐릿해질 때 쯤 빛을 발할거라고 생각합니다. 더군다나 실제 현업에선 팀원의 교체가 잦고, 신규입사자들은 히스토리를 알아야하는데, 그럴 때 문서화가 되어있지 않으면 사수가 구두로 설명할 수 밖에 없기 때문에 히스토리들을 문서화하여 참고하도록 하는게 좋을 것 같습니다!