기본적인 백엔드 구축이 끝났기 때문에 모니터링 인프라를 구축하고자 한다. 백엔드 모니터링에는 Grafana를 사용하였다.
IAM
보안 자격 증명 화면으로 넘어가 Grafana를 위한 액세스 키를 생성하였다.
원래는 루트 사용자 명의로 액세스 키를 만들면 안 된다.
혼자 작업하는 사이드 프로젝트이기에 단순함을 위해 이렇게 했지만 모범 지침이 아니므로 최소 권한을 가진 IAM 사용자를 따로 만들어서 작업하자.
Grafana
계정 생성
일단 계정을 생성한다.
Stack URL과 배포할 리전을 선택. 작성일 기준으로 한국 리전이 존재하지 않는 관계로 일본 리전을 사용했다
Cloudwatch 연결
대시보드에서 데이터 소스를 추가해야 한다. 일단 데이터 소스로 cloudwatch를 추가하자.
Save & Test를 눌러 성공을 확인하였다.
대시보드 생성
다음의 정보들을 모니터링하고자 한다:
DynamoDB
- WCU, RCU
- SuccessfulRequestLatency
- ReturnedItemCount
- SystemErrors
Lambda
(각 함수에 대해)
- invocations
- 실행시간
- 에러율
API Gateway
(각 API에 대해)
- 메시지 수 (websocket)
- connection 수 (websocket)
- 호출 수 (rest)
- latency (rest)
- 에러율
Aurora
- ACU
- 커밋 latency
- 커밋 throughput일단 새 대시보드를 만들자.
이어지는 화면에서 데이터 소스로 cloudatch를 선택한다.
일단 DynamoDB 테이블의 ConsumedReadCapacityUnits를 모니터링해 보자.
물론 json 구문을 직접 짜는 방법도 있지만 빌더를 이용해 하나하나 옵션을 지정해 주었다.
입력하고 Run queries를 누르면
이렇게 해당 지표가 넘어온다.
Back to dashboard를 눌러 대시보드로 돌아가고, 다시 Add > visualization을 눌러 다른 지표도 추가한다.
이 과정들을 반복하고, 레이아웃을 바꿔 가며 최종적으로 아래와 같은 대시보드를 구축하였다.
위에서부터 하나씩 살펴보자면,
- rest api의 경우 lateny와 integrationlatency를 비교하여 lambda 실행 시간 외에서 발생하는 불필요한 지연 시간이 길어지지 않는지 확인했다. 해당 값들간 차이가 0.1초 미만으로 충분히 짧음을 확인했기에 API 구조에 있어 더이상의 최적화가 필요하진 않다고 판단하였다.
- 또 4XX 에러와 5XX 에러를 나누어 표시하였다.
-Lambda의 경우 실행 시간 편차가 조금 있는 관계로 Max, Avg, Min을 함께 보도록 표기하였다. - DynamoDB의 경우 온디맨드 사용량이기 떄문에 스로틀링 관련 지표는 불필요
베타테스트 당시 해당 대시보드를 적극적으로 확인하였다. 에러율과 지연 속도를 확인하고 그로서 추가적인 최적화가 어디가 필요한지 참고하는 데에 큰 도움이 되었다.
