일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 오블완
- kotlin querydsl
- IntelliJ
- CKA 기출문제
- Kubernetes
- 코틀린 코루틴의 정석
- 티스토리챌린지
- Elasticsearch
- kotlin
- Pinpoint
- aws
- Linux
- APM
- CloudWatch
- 정보처리기사 실기
- 기록으로 실력을 쌓자
- PETERICA
- mysql 튜닝
- AI
- 정보처리기사 실기 기출문제
- CKA
- AWS EKS
- MySQL
- 공부
- minikube
- Java
- kotlin coroutine
- 정보처리기사실기 기출문제
- kotlin spring
- Spring
- Today
- Total
피터의 개발이야기
[AWS] CloudWatch를 체험하다 본문
이번 글은 AWS를 사용하면서 경험한 소소한 이야기를 나누려고 합니다.
저는 스타트업 회사를 다니고 있는데, 이 AWS를 이용하여 Pass 서비스를 제공하고 있습니다.
AWS의 다양한 서비스 중에 CloudWatch를 실질적으로 경험하고,
제가 처리했던 과정을 함께 공유합니다.
아침 10시 18분에 슬랙으로 cloudwatch의 경고가 전달 됩니다.
이게 무엇인가 아리송한 저는 AWS에 접속하여 CloudWatch를 확인해 봅니다.
해당 경고를 확인해 보니
사용 중인 RDS의 스토리지가 많이 부족하였습니다.
아니 이런 LOG성 데이터들이 이렇게 빨리 차다니?
서비스가 잘되어 트래픽이 폭발한 걸일까요?
아니면 ㅎㅎㅎㅎ 뭔가가 잘못된 것일까요?
그 판단은 비밀입니다.
아무튼,
프론트와 백엔드의 통신이력을 남기고 있습니다.
사용자의 접속 정보와 요청과 응답 데이터가 직렬화되어 저장을 하고 있습니다.
실기간으로 데이터가 쌓이고 있는 테이블이어서
중단없이 테이블을 이관하는 방법을 찾아야만 했습니다.
데이터를 삭제하거나
옮기는 경우에도 DB트레픽이 발생하여 시스템에 영향을 줄 수 있었습니다.
가장 부하가 적고 무중단으로 처리할 수 있는 방법은
테이블 스위치였습니다.
1. 신규 테이블 생성을 해야합니다.
#신규 테이블 생성
create table action_log2
(
log_id int auto_increment
created_at datetime default CURRENT_TIMESTAMP not null,
speed_gun int null
);
2. 테이블 스위치
# 테이블 스위치
RENAME TABLE action_log TO action_log_20201209,
action_log2 TO action_log;
보관기간이 지난 데이터들은 삭제하였습니다.
짜잔 용량을 많이 비웠네요.
AWS가 정말 편리하고 필요한 서비스를 잘 갖추었다고 생각이 들었던 순간이었습니다.
모니터링도 쉽고, 필요한 알람을 추가적으로 더 장착할 수도 있습니다.
스타트업 회사를 다니면 이런 장점이 있는 것 같습니다.
큰 회사엔 조직적으로 세분화되어 있고, 각 담당자가 정해져 있다보면 전문성이 있겠지만,
한편으로는 내가 담당하지 못한 부분은 경험하기가 어렵습니다.
하지만 스타트업 회사에서는 내가 경험해 볼 수 있는 영역이 다양해서
개인적인 개발경험엔 큰 장점이 있습니다.
지금까지 AWS 시니어 개발자의 소소한 경험담이었습니다.
감사합니다.