스터디에서 에러 바운더리를 얘기하면서, Sentry를 위해 에러 바운더리를 도입했다는 이야기를 접하였습니다.
에러 바운더리를 활용한 에러 처리
에러 바운더리: 리액트 컴포넌트 트리에서 에러가 발생할 때 공통으로 에러를 처리하는 리액트 컴포넌트
- 에러 바운더리를 사용하면 리액트 컴포넌트 트리 하위에 있는 컴포넌트에서 발생한 에러를 캐치하고, 해당 에러를 가장 가까운 부모 에러 바운더리에서 처리하게 할 수 있다.
- 에러 바운더리는 에러가 발생한 컴포넌트 대신에 에러 처리를 하거나 예상치 못한 에러를 공통 처리할 때 사용할 수 있다.
이때, Sentry 자체를 처음 접하게 되어, 추가로 공부해 알아보고 싶었습니다.
스터디 발표 차례에서 이를 정리해 발표하면 좋을 것 같아 kakao에서 발표한 Sentry 도입 영상을 정리해보았습니다.
# Kakao가 겪어야 했던 상황들
-
특정 이슈 감지, 원인 파악, 해결까지 많은 시간이 소요됨
-
이때, 대부분의 시간을
원인 파악에 소요함 -
이는 좋지 않은 사용자 경험을 제공함
⇒ 에러 추적을 개선해보자!
# Frontend에서의 에러
-
데이터 영역에서의 에러, 화면 영역에서의 에러는 충분히 조심하고 방어할 수 있다.
-
그러나 외부요인(네트워크, 브라우저 등)에 의한 에러, 런타임 에러는 예측하기 힘듦.
-
이런 에러들을 트래킹하고 신속하게 대응해 UX를 개선할 수 있지 않을까 생각함
# 에러 추적을 개선해보자!
에러 추적을 위해 다음과 같은 흐름으로 개선 작업을 진행함
1. 에러 데이터 쌓기
프론트엔드 모니터링 툴 중, Sentry를 사용함
Sentry
- 실시간 로그 취합 및 분석 도구이자 모니터링 플랫폼
- 로그에 대한 다양한 정보를 제공하고 시각화 도구를 통해 발생한 이벤트들을 쉽게 분석할 수 있도록 도와줌
- 다양한 플랫폼을 지원
Sentry는 기본적으로 두 가지 이벤트 전송 api를 제공함.
-
captureException
- 에러 객체나 문자열을 전송
-
captureMessage
- 문자열만 전송
이렇게 수집한 에러 데이터는 검색도 어렵고 구분하기도 어려웠음
⇒ Sentry 자체에서 제공하는 기능들이 다양함. 이를 활용해보기로 함.
Scope
Sentry는 기본적으로 scope 단위로 데이터를 관리함
스코프는 자동으로 관리되지만 잘 활용한다면 이벤트마다 추가 정보를 전송할 수 있음
-
configureScope
-
글로벌 스코프와 비슷한 맥락
-
공통 정보를 데이터 전송에 활용할 수 있음
-
현재 범위 내에서 데이터를 재구성하는데 사용
-
-
withScope
-
로컬 스코프와 비슷한 맥락
-
복제본을 생성해서 추가 정보를 병합한 뒤에 이벤트를 전송함
-
한 번의 범위 내에서 데이터를 재구성할 때 사용
-
Context
-
이벤트에 임의의 데이터를 연결할 수 있는 context를 이용해 추가 정보를 전송
-
검색은 할 수 없고 해당 이벤트가 발생한 이벤트 로그에서 확인 가능
Cusomized Tags
-
에러 추적을 신속하게 하기 위해 검색이 중요한 요소임
-
tag는 키와 값이 쌍으로 이루어진 문자열
-
tag는 인덱싱이 되는 요소 ⇒ 이벤트에 빠른 접근 가능 ⇒ 이슈 검색 및 트래킹을 신속하게 진행할 수 있음
~> 태그 값은 검색 뿐만 아니라 알람 설정에도 활용 가능
Level
-
이벤트마다 level을 설정하여 이벤트의 중요도를 식별할 수 있음
-
fetal, error, warning, log, info, debug, critical로 severity를 설정할 수 있음
예제 1. API 인터널 서버 에러
-
중요도를 높여 추적하기 위해 Error 등급으로 설정
-
전송된 이벤트는 시각화 도구에서 확인 가능
예제 2. API 타임아웃 에러의 레벨 설정하기
- 인터널 서버 에러보다는 중요도를 낮춰 식별해야 함
⇒ Warning 등급으로 설정
⇒ 에러 유형에 따라 중요도를 설정하게 되면 이슈 그룹핑이나 알람 조건을 세분화하여 설정하는데 도움이 됨
Issue Grouping
-
각각의 이벤트들은 내재화 된 그룹화 알고리즘에 의해 생성된 fingerprint를 가지고 있음
-
fingerprint가 동일한 이벤트는 자동으로 하나의 이슈로 그룹화되며 재설정할 수 있음
-
간혹 이슈가 예상과 다르게 보여 재설정이 필요한 경우가 있음
← ex: API 응답이 서로 다른 상태값을 가지게 되어도 내재화된 알고리즘에 의해 그룹화됨
이렇게 에러 데이터를 쌓는 작업 후 에러 상황을 빠르게 감지하기 위해 Severity 기준 설정과 그에 따른 모니터링이 필요함
2. Severity 기준 설정 및 모니터링
알람 조건 설정하기
-
When : 모니터링할 이슈의 유형 지정
-
If : when 조건이 충족된 후, if 조건의 필터를 확인해 이슈를 트리거함
-
Then : when과 if 조건이 충족되면 슬랙과 같은 툴로 알람을 전송함
EX: API 에러에 대한 알람 조건 설정하기
~> 위의 조건들을 조합하여 아래와 같이 설정 가능함.
3. 에러 데이터 분석
에러 데이터 수집 전 세웠던 가설
-
api에 대한 에러가 대부분일것이다 ⇒ 가설 적중
-
apiNotFoundError의 경우 약속된 에러 케이스들이 섞여 있었음
⇒ 이는 빈번하게 발생할 수 있기 때문에 무분별한 수집은 데이터 분석에 방해가 될 수 있다는 인사이트를 얻을 수 있었음
~> 유의미한 데이터를 수집하자
⇒ 언제 에러데이터를 쌓는 것이 좋을지 생각해보게 되었음
유의미한 데이터를 수집하자
-
chunk load 에러나 network 에러는 사용자에 환경에 따라 발생할 수 있기 때문
-
timeout 에러는 수집하는데, cs를 대응하거나 사용자 경험을 개선할 수 있는 지표를 체크하기 위함임
서버와의 로그 분석 정합성 높이기
-
견고한 추적을 위해 추가적인 작업 진행
-
서버와 약속된 custom header를 추가하여 API를 요청함
-
이는 에러 상황 시 서버 로그와 프론트엔드에 남은 데이터를 서로 대조하여 분석의 정합성을 높일 수 있음
4. 분석 결과에 따른 개선
-
QA 과정에서 발생하지 않았던 특정 기기와 특정 브라우저 버전에 대한 에러 발견
⇒ 폴리필을 추가하는 등의 대응이 가능 ⇒ 사용자 경험 개선
-
장애 탐지 시간, 원인 파악, 해결까지의 시간이 줄어들었음
-
오류 추적 시 디바이스 디버깅으로 특정 상황을 재현하지 않고도 로그를 통해 빠른 파악이 가능
⇒ 개발자 경험도 좋아졌으며 특히 QA 이슈를 해결할 때 많은 도움이 됨
-
빈번하게 발생하는 오류에 대한 분석의 필요성을 느끼게 됨
-
임계치에 대한 고민이 생김
-
어느 정도의 수치가 적절하며
-
어느 수치 이상부터 장애 상황으로 보아야 할지
-
