피터의 개발이야기

[kubernetes] 쿠버네티스 목차 [kubernetes] 모니터링 방법 정리 ㅁ 개요 ㅇ EKS에 순단이 발생하여 장애상황이 발생하였다. ㅇ 장애상황을 확인하는데, 정렬되어 있지 않은 EKS 이벤트 확인이 어려웠다. ㅇ EKS 이벤트의 정렬 방법을 정리하였다. ㅁ 소팅 조회방법 kubectl get events --sort-by='.metadata.creationTimestamp' -A kube-system 60m Normal LeaderElection lease/kube-scheduler ip-10-0-96-181.ap-northeast-2.compute.internal_f02cf5ab-2657-4180-ba3c-a2d39f55f3dd became leader kube-system 60m Norm..

ㅁ 개요 ㅇ CloudWatch 볼륨 지표상에서 Elasticsearch Data Node 볼륨의 병목현상이 발견됨. ㅇ 병목현상의 원인 분석 및 해결 과정 정리 ㅁ 병목현상 확인 ㅇ data node의 볼륨 IO가 병목이 발생하여 IO가 100% 상황 발생하였다. ㅁ 원인분석 GET /_nodes/hot_threads?pretty ㅇ 키바나의 Dev Tools를 이용하여 부하가 발생하는 스래드를 찾았다. 100.0% [cpu=71.2%, other=28.8%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[elasticsearch-data-0][write][T#1]' 5/10 snapshots sharing following 30 elements j..

ㅁ 개요 DB 부하지표가 발생하여 원인을 분석하였다. 현재 APM으로 사용 중인 Whatap은 라이센스 문제로 slowquery를 보는데에는 한계가 있 다. 부하를 주는 롱쿼리에 대한 분석과정을 개선하고자 AWS RDS 성능개선도우미를 도입하기로 하였고 그 과정을 정리하였다. ㅁ Cloud Watch RDS 부하 지표 확인 ㅇ 현재 RDS 라이트 인스턴스와 리더 인스턴스로 구성되어 있다. ㅇ 리더 인스턴스에서 롱쿼리가 발생하여 CPU 사용량이 증가 되었고 지표상 롱쿼리라 판단을 하였다. ㅇ 물론 운영상 통계를 추출하면서 롱쿼리가 발생할 수 있지만 이런 경우 모니터링 상 문제가 될 수 있기 때문에 전체 공유를 한다. ㅁ Whatap RDS 지표 확인 ㅇ 와탭 > RDS > 인스턴스 모니터링을 확인하면, 현..

ㅁ 개요 ㅇ AWS 시스템을 모니터링을 하기 위해서 다양한 지표를 확인해야한다. ㅇ 상황에 따라 필요한 지표를 빠르게 CloudWatch Dashboard로 생성하는 과정을 정리하였다. ㅁ 상황에 따른 모니터링 지표 대상 선택 현재 담당하고 있는 시스템에서 트래픽이 일정기간 집중되어 있다. 그래서 RDS Aurora Mysql 경우 특정기간에 scale up, scale down을 하고 있다. 하지만 때로는 특정치 않은 상황에서 대량의 트래픽이 발생할 경우가 있어 Redis 엔진 CPU 사용량, RDS CPU 사용량, 로그와 mongoDB가 사용하는 볼륨의 지표를 모니터링이 필요하다. ㅁ Redis 엔진 CPU 사용량 ㅇ Redis을 메인 데이터베이스로 사용하고 있다. 그래서 트래픽 부하가 증가할 때에 ..

이번 글은 AWS를 사용하면서 경험한 소소한 이야기를 나누려고 합니다. 저는 스타트업 회사를 다니고 있는데, 이 AWS를 이용하여 Pass 서비스를 제공하고 있습니다. AWS의 다양한 서비스 중에 CloudWatch를 실질적으로 경험하고, 제가 처리했던 과정을 함께 공유합니다. 아침 10시 18분에 슬랙으로 cloudwatch의 경고가 전달 됩니다. 이게 무엇인가 아리송한 저는 AWS에 접속하여 CloudWatch를 확인해 봅니다. 해당 경고를 확인해 보니 사용 중인 RDS의 스토리지가 많이 부족하였습니다. 아니 이런 LOG성 데이터들이 이렇게 빨리 차다니? 서비스가 잘되어 트래픽이 폭발한 걸일까요? 아니면 ㅎㅎㅎㅎ 뭔가가 잘못된 것일까요? 그 판단은 비밀입니다. 아무튼, 프론트와 백엔드의 통신이력을 남..