피터의 개발이야기

ㅁ 개요 ㅇ 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시까지 시간이 연장된다.

ㅁ 개요 ㅇ 운영상 특정 시기에 대량 트래픽일 몰릴 경우 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가 많이 상승할 때가 있..

ㅁ 개요 ㅇ Elasticsearch를 이야기 하면서 개념적으로 헷갈리는 부분이 있어서 정리를 하였다. ㅇ index와 indices, node, Documents에 관한 설명이다. ㅁ 용어 개념 정리 ㅇ 도큐먼트는 가장 기본 단위로 로그 한줄을 말한다. ㅇ index는 도큐먼트의 논리적인 한 묶음이다. ㅇ indices는 언어적으로는 index의 복수형을 뜻하고, index의 물리적인 의미로 저장소 단위 개념이다. ㅇ shard는 indices의 분산저장 단위이다. ㅇ 위의 이미지를 참조하여 설명하면, elasticsearch의 인프라는 3개의 master node와 2개의 data node로 구성되어 총 5개 노드가 있다. ㅇ shard는 5개의 노드 중에서 data 노드에 24개의 indices가 ..

[kubernetes] 모니터링 방법 정리 ㅁ 개요 ㅇ 대량 트레픽 서비스에서 퍼포먼스 향상을 위해서는 트레픽의 응답 시간 체크가 필수적이다. ㅇ 응답이 지연되는 프로세스를 체크하고 퍼포먼스를 향상함으로써 제한된 리소스에서 서비스의 TPS를 높여 고가용성을 얻을 수 있다. ㅇ 고가용성을 높인가는 것은 적은 리소스로 더 많은 요청을 처리하게 되면서 AWS 비용절감과 시스템 병목장애를 예방할 수 있다. ㅇ 그러므로 트레픽 응답 지연 모니터링은 DevOps의 필수적인 요소이다. ㅁ AWS 대상그룹의 대상 응답시간 지표 ㅇ 대부분의 트래픽이 1초 미만인 것을 확인 할 수 있다. 하지만 특정 트래픽은 1초 이상의 것이 확인되고 있다. ㅇ Cloud Watch에 8초 이상에 대해서는 경고를 설정해 두었다. ㅇ 이미..