Front End 시점에서의 서비스 대량 트래픽 발생 그리고 대응

Front End 시점에서의 서비스 대량 트래픽 발생 그리고 대응

 

 

 

현재 제가 운영 중인 서비스 MyVenus는 아직 초기이기 때문에 대량 트래픽이 발생하지 않는 수준입니다. 대량 트래픽에 대한 걱정은 사실 평소에 많이 하지 않고 있었습니다.

 

하지 어느 날 운영팀에서 운영 중인 서비스 인스타그램 광고 계정의 하나의 릴스 영상이 1600만 뷰 이상의 조회수가 발생하면서 사건의 발단이 되었습니다.

이 릴스의 광고 효과로 지금까지 경험해보지 못한 대량 트래픽이라고 말할 수 있는 수치를 기록하게 되었습니다. 엄청난 유저들이 앱을 인스톨하고 회원가입 이벤트가 엄청나게 발생한 것이었습니다.

이때 일어난 일들을 Front End 관점에서 기록하였습니다. 물론 서버 쪽의 대응이 더욱더 중요한 시점이었지만 제 포지션은 Front End였기 때문에 프론트엔드에서 일어난 일들과 대응을 기록하게 되었습니다.

 

이 릴스 하나로 운영 중인 서비스에 엄청난 일이 발생했다

 

로그인 • Instagram

 

 

 

 

대량 트래픽 발생과 대응

---

 

대량 트래픽을 경험하고 나서 깨달은 점을 한마디로 말하자면 많이 부족했던 서비스의 허점과 나 자신의 개발 역량의 부족함에 좌절했다고 말하고 싶습니다.

 

 

 

일단 이 대량 트래픽이 발생하였을때 저희 서비스는 Sentry / GCP 라는 사내 에러 로그 모니터링 플랫폼을 사용하여 에러를 추적하고 개선하고 있었습니다. 프론트 / 백엔드 모두 모니터링이 가능한 상황이었습니다.

Application Performance Monitoring & Error Tracking Software

 

https://cloud.google.com/

 

 

 

 

저는 어떻게 이 중요한 내용을 명확하게 보여줄까 고민하다가 주제를 크게 3가지로 나눌 수 있었습니다.

 

1. 프론트단에서의 API의 비정상적인 반복 호출 시점 발견과 최적화 

2. 많은 유저들의 기능 사용으로 알 수 있었던 숨겨져 있던 이슈와 버그

3. 진정 유저들이 원하는점 그리고 개선 지표 발견

 

 

 

 

 

프론트단에서의 API의 비정상적인 반복 호출 시점 발견과 최적화

---

 

발생 이슈

 

유저들이 갑자기 한꺼번에 유입되기 시작하자 처음 앱이 시작하고 등장하는 Home 화면에서 문제가 발생하였습니다. 한 번만 호출하고 그 이후 중복 호출하는 것이 필요 없는 API들이 엄청난 유저 유입으로 인하여 비싼 비용을 치르게 되었던 것이었습니다.

 

그중 하나가 유료 라이브러리의 호출 API가 엄청나게 호출하자 가격 비용이 평소보다 거의 2배 이상 나가게 되었고 굳이 호출하지 않아도 되었던 API였습니다.

또 이 API는 에러 형식의 로그여서 Sentry 및 GCP 등의 로그 모니터링에 에러가 비정상적으로 발생했다는 경고를 받기까지 하였습니다.

이뿐만 아니라 여러 주요 페이지에서 쓸 때 없이 호출하는 API을 발견하게 되었습니다.

 

 

 

대응 그리고 깨달은 점

 

결국 긴급 수정 배포가 이뤄졌고 하지만 이미 배포 후에는 많은 유저가 갔다간 후였습니다. 마치 태풍이 순식간에 모든 걸 파괴하고 지나간 느낌이었습니다.

 

이 이슈를 통해 앞으로 프론트 개발을 할 때 API의 효율성과 실제 프로덕션 환경에 나가 일어날 수 있는 경우를 더 신경 쓰게 되었습니다. 쓸데없는 API 호출을 최대한 줄이고 비용을 줄이는 개발을 하게 되었던 것 같습니다.

 

 

 

 

 

 

많은 유저들의 기능 사용으로 알수 있었던 숨겨진 이슈와 버그

---

 

발생 이슈

 

프론트의 UI/UX 유저 사용 이벤트 버그들을 많이 체크하고 발견하게 되었습니다. Sentry라는 훌륭한 도구가 앱의 비정상 종료 및 유저 사용 이벤트 에러까지 친절하게 모니터링까지 해준 덕분이었습니다.

 

실제 사례를 예로 들자면 React Native의 TextInput 태그의 기능이었습니다. 특정 Android 소프트웨어 버전에서 재현되는 TextInput의 버그를 발견하게 된 것이었습니다.

 

유저가 TextInput을 작성할때 특정 행위 및 특정 OS 소프트웨어 버전에서 앱이 비정상적으로 튕겨버리는 현상을 일으키게 된 것을 이번 대량 트래픽 발생을 통해 알게 된 것이었습니다.

 

 

 

대응 그리고 깨달은 점

이렇개 발견한 이슈들은 에러 로그의 정보를 통해 GitHub 커뮤니티 혹은 구글 서칭을 통해 최대한 RN 버전을 고치지 않고(Side Effect 영향을 최대한 피하기 위해) 해결할 수 있는 방법들을 찾아보며 하나하나 정리 및 고쳐나가며 긴급 배포 혹은 추후 정식 배포를 진행하는 것으로 대응하였습니다.

이렇게 많은 사용자들이 기능을 사용하면서 발생하는 에러들을 체크할 수 있었던 것은 대량 트래픽의 상황이 기회와 계기를 준 것 같았습니다.

 

이러한 이슈들은 여러 주요 기능에서 곳곳에서 많이 발생하였습니다.

그래서 저는 치명적인 이슈들의 에러 로그들을 정리 및 분석하기 위하여 치명적인 이슈 발생 알림 Action 및 Notion에 구체적인 이슈 내용과 버전, 찾은 해결 방법 등등 그때그때 정리해 두는 습관을 들여 더 효율적으로 서비스 운영을 하기 위한 전략을 세우기도 하였습니다.

 

 

 

 

 

 

 

진정 유저들이 원하는점 그리고 개선 지표 발견

---

 

발생 이슈

 

저희 서비스는 에러 로그 분석뿐만 아니라 Google에서 제공해 주는 훌륭한 분석기 구글 애널리스틱스를 사용하고 있었습니다. 이번 대량 트래픽 발생으로 인하여 가설 혹은 검증이 필요한 분석 데이터를 충분히 얻었다는 것이었습니다.

또 문의하기 창구 페이지를 통해 유저들의 불만과 이슈 또한 많은 피드백을 받기도 하였습니다.

유저들이 앱 서비스를 사용하면서 어떤 행동을 가장 많이 하고 가장 많이 방문하는지 어떤 회원들이 이 앱에 더 관심이 많은지 기술적인 부분이 아닌 서비스 운영 / 마케팅 관점에서도 많은 도움이 되었던 것 같았습니다.

저는 직접 이 개선 지표 발견을 관여를 많이 하지 않았지만 서비스 운영 개발을 하는 입장에서 많은 의견을 나누는 것도 가능했던 것 같았습니다.

 

 

Google 애널리틱스  |  Google for Developers

 

 

대응 그리고 깨달은 점

이러한 가치있는 분석 데이터 축적, 고객 유저들의 피드백들은 앞으로의 개발 방향 그리고 기획까지 모두 엄청난 영향이 있었던 것 같았습니다.

이 기능을 추가 하면 좋을 거야 하는 기능들은 사실상 유저들이 쓰지 않았고 오히려 예상치 못한 기능들이 엄청나게 많이 사용한다는 경우도 있었습니다. 이러한 분석 접근 방식은 '그로스 해킹'과 같은 분석과 운영 방식인데 이 개념과 기록은 기회가 되면 정리해 볼 예정입니다.

 

 

 

 

 

 

마무리하며...

---

 

대량 트래픽의 사건은 개발자로서 쉽게 경험해보지 못할 진귀한 경험이었고 앞으로 개발자로서의 많은 발전을 할 수 있도록 발판이 된 사건이기도 하였습니다.

 

자신감이 생기기도 하였지만 운영 / 개발에 대한 불안감과 부담감 또한 있었던 것은 사실이었습니다. 그래도 이 경험이 앞으로 제게 발전의 큰 영양분인 것은 틀림없었던 것 같았습니다.

 

앞으로도 이러한 상황이 온다면 자신 있게 대응하고 운영 개발 하는 개발자가 되기를 바라며 마무리하겠습니다.