피터의 개발이야기

ㅁ 개요 Redis slowlog를 모니터링하는 중 KEYS가 롱쿼리로 감지되어, SCAN으로 변경하여 Redis Blocking 시간을 최소화한 과정을 정리하였다. ㅁ Redis 모니터링의 필요성 ㅇ 현재 내가 담당하는 시스템은 대량 트래픽을 처리하고 있다. 그래서 메인 디비로 Redis를 사용하고 있다. ㅇ 고성능 고가용성을 위해 쿠버네티스 환경으로 구축되었고, 어플리케이션 내의 개별 프로세스도 비동기형태로 구현되어 있다. ㅇ RDS의 처리 속도가 보장되지 않아 Redis를 사용하고 있기 때문에 Redis의 slowlog확인을 통해 10ms 이상인 것은 지속적으로 튜닝을 해야만 전체 서비스의 TPS를 보장할 수 있다. ㅁ Grafana Slow log 확인 ㅇ HKEYS 명령어가 10ms 이상 발생하..

ㅁ 개요 ㅇ ELB 쪽에서 처리 지연 알람이 발생하였다. 외부에서 연동된 정보를 처리하면서 내부처리 로직의 수행시간이 지연이 되면서 전체 응답속도에 지연이 발생한 것이다.  ㅇ 구체적인 원인은 Redis Scan 명령어 처리 시에 count가 기본 10으로 책정되어 있어서 발생한 문제점이었다. ㅇ 이 문제점을 분석하면서 수행하였던 Scan performance 테스트 과정을 정리하였다.  ㅁ Redis Scan이란? ㅇ  HSCAN key cursor [MATCH pattern] [COUNT count] 명령문으로 사용하고      count를 통해 분할 조회 건수를 조정할 수 있고,       pattern으로 like 조회를 지원한다. pattern은 GLOB style pattern이다.patter..

ㅁ 개요 ㅇ 새롭게 오시 개발자분이 환경 세팅 시 라이트 인스턴스를 사용하여 운영부하를 발생시키는 일이 발생하였다. ㅇ DB사용 시 리더 인스턴스와 라이터 인스턴스는 반드시 구분해서 사용해야 한다. ㅇ 통계 조회 시에는 비교적 부하가 적은 리더 인스턴스에서 작업을 하는 것이 맞다. ㅇ 하지만 Fail Over처리 후에는 디비 인스턴스의 역할이 바뀌는데 이를 모르고 잘못접속하는 실수를 할 수 있다. ㅇ 이를 방지하기 위해서는 리전 클러스터의 엔드포인트로 접속을 하면 된다. ㅁ 디비 인스턴스의 엔드포인트 ㅇ 디비 인스턴스의 엔드포인트는 해당 인스턴스 고유의 엔드포인트이다. ㅇ 디비 접속 정보에 고유 엔드포인트를 통해 접근할 경우 현재 인스턴스의 역할을 반드시 확인을 해야만 한다. ㅁ 리전 클러스터의 엔드포인..

ㅁ 개요 ㅇ Grafana나 다른 APM 툴이 없는 상태에서 Redis를 서버상에서 모니터링하는 방법에 대해서 정리해 보았다. ㅁ Redis 접근 shell 작성 [ec2-user@PRD-PETERICA-BASTION ilovefran]$ cat cli.sh #!/bin/sh redis-cli -h prd-peterica-main.cache.amazonaws.com $@ ㅇ 서버에서 접속하지 않고 명령어를 수행 할 수 있도록 shell를 하나 생성한다. ㅁ Redis 키별 용량 확인 [ec2-user@PRD-PETERICA-BASTION ilovefran]$ sh cli.sh --bigkeys # Scanning the entire keyspace to find biggest keys as well as..

ㅁ 개요 ㅇ 트래픽이 증가 하면서 Redis 부하상태가 발생하였다. ㅇ 원인은 데이터가 적체되면서 lrem의 처리 속도가 저하되었고, 그로 인해 적체 가속도가 증가하여 처리 속도는 더욱 늦어지는 교착상태가 되었다. ㅇ Redis큐의 처리 방향에 따라 처리 속도 지연이 발생했던 문제점을 분석하고 정리하였다. ㅁ LLEM 이란 lrem {키} {건수} {value} 형태로 사용하며 값으로 삭제한다. 건수가 양수이면 value를 리스트 왼쪽부터 찾아서 건수만큼 삭제한다. 건수가 0이면 value 전체를 삭제하고 삭제건수를 리턴한다. 건수가 음수이면 value를 리스트 오른쪽부터 찾아서 건수만큼 삭제한다. ㅁ 큐 방향성 문제 분석 문제점은 큐 처리 방식을 first in last out에서 first in fi..

ㅁ 개요 ㅇ 성능 시험을 위해 검수기의 서비스 환경을 운영과 동일하게 업그레이드 하는 과정을 정리하였다. ㅇ 업그레이드는 Node, redis, RDS로 나뉘어서 진행되며, 여기는 Node 업그레이드 과정이다. ㅁ CloudFormation이란? Amazon Web Services(AWS) 리소스를 자동으로 생성해 주는 서비스이다. 사용하려는 AWS 리소스를 템플릿 파일로 작성하면, CloudFormation이 이를 분석해서 AWS 리소스를 생성한다. 이렇게 생성된 리소스를 스택이라고 한다. ㅁ 스택 작업 스택 템플릿에 scale up 설정을 하면, 아래의 정책에 따라 UpdatePolicy: AutoScalingRollingUpdate: MaxBatchSize: 2 MinInstancesInServic..

ㅁ 개요 ㅇ 개발계와 검수계는 비용절감을 위해 오전 9시~ 오후 6시에만 가동되고 있다. ㅇ 필요에 따라 AutoScale 그룹의 시간을 연장하는 방법에 대해서 정리하였다. ㅁ Auto Scaling 그룹 > 자동 조정 ㅇ Auto Scaling 그룹 > 자동조정에서 예약된 작업을 확인할 수 있다. ㅇ 주간 9~18시까지 운영하기 때문에 Auto Start와 Auto Shutdown 예약이 생성되어 있다. ㅇ Auto Shutdown을 선택 후 작업에서 편집을 클릭한다. ㅁ 예약 작업 편집 ㅇ 특정 시작 시간을 연장하고 싶은 시간으로 조정하여 변경 사항 저장을 하면 5월 23일은 오후 10시까지 시간이 연장된다.

ㅁ 개요 Mysql varchar 컬럼의 사이즈에 맞게 문자열을 짤라서 넣어야 되는 상황이었다. JAVA에서 책정한 문자길이와 디비 varchar에서 책정되는 문자길이가 다른점을 발견하였다. 정확히 varchar에 맞게 문자열을 짤라 넣기 위해서는 JAVA와 Mysql의 문자길이 체크 방법을 명확히 알아야만 한다. 그 방법에 대해서 정리하였다. ㅁ 테스트를 위한 TEST 테이블 생성 create table TEST ( TEST varchar(10) charset utf8 not null ); ㅁ Mysql의 length와 char_length 차이 비교 select TEST, CHAR_LENGTH(TEST) charLen, LENGTH(TEST) len from TEST; ㅇ char_length는 영어..

ㅁ 개요 ㅇ 운영상 특정 시기에 대량 트래픽일 몰릴 경우 RDS CUP 사용량이 90%가 넘는 경우가 있다. 이를 대비하기 위해 RDS Aurora의 성능업을 수행하고 반대로 성능다운 작업을 수행하였다. DB 인스턴스 클래스 조정 스케일업 과정을 정리한다. ㅇ 현재 디비는 master와 read 인스턴스, 이중화로 구성되어 있다. 1. Aurora DB 리더인스턴스 스케일업 DB 인스턴스 클래스 조정 -> 계속 버튼 즉시적용 -> DB 인스턴스 수정 버튼 2. DB Status 상태 확인 : 수정중 -> 사용가능 참고로 수정 중일 때에 새로운 DB인스턴스를 생성하고 데이터볼륨을 붙이는 작업을 진행함. 인스턴스 생성이 완료되면, 디비의 파라메터를 설정하는 상태로 변경됨. 3. AWS 대시보드 Replica..

ㅁ 개요 ㅇ Elasticsearch의 data 노드가 사용하는 볼륨에 DISK IO에서 비정상적인 지표가 확인되었다. ㅇ 원인분석을 하였지만, 트래픽도 평균을 유지하였고, Kibana에서 롱쿼리를 날리지도 않은 상태였다. ㅇ pod가 자체적으로 restart를 하는 것이 확인되어 ES data 두 노드를 재기동하였고 증상은 해결되었다. ㅁ Elasticsearch data의 모니터링 이유 ㅇ 144개의 컨테이너 중에서 elasticsearch data의 CPU와 메모리 사용량이 제일 높다. ㅇ 모든 컨테이너들의 로그를 처리하고 있어서 트래픽이 높아지면 elasticsearch의 부하도 함께 증가하기 때문에 모니터링이 필요하다. ㅇ 특히 data의 데이터 저장을 위해 disk IO가 많이 상승할 때가 있..