피터의 개발이야기

ㅁ 개요 ㅇ Amazon S3 버킷에 로그를 저장하고 있다. ㅇ 오래된 로그는 정리 작업을 통해 더 이상 스토리지 요금이 청구되지 않도록 해야한다. ㅇ S3의 과금은 용량에 비례하기 때문이다. ㅇ 로그자동 삭제를 위해 버킷에 저장된 객체들의 수명 주기를 구성할 수 있다. 그 방법에 대해서 정리하였다. ㅁ S3 수명주기 생성 방법 ㅇ 버킷을 선택하고 관리를 클릭한다. ㅇ 생성된 수명 주기의 현재 상태는 Enable ㅇ 수명 주기 규칙 생성을 클릭한다. ㅁ 모든 객체 적용 수명주기 ㅇ 버킷의 모든 객체에 적용하였다. ㅇ 수명 주기에는 현재 버전과 이전 버전 작업이 나뉘어 있다. ㅇ Amazon S3의 버전 관리는 동일 버킷 내에 여러 개의 객체 변형을 보유할 수 있다. ㅇ S3 버전 관리를 사용하면 버킷에 ..

ㅁ 개요 ㅇ AWS로부터 DB OS 업그레이드 안내 메일을 받아서 확인하는 과정을 정리하였다. ㅁ AWS DB OS 업그레이드 메일 안녕하세요, 하나 또는 그 이상의 Amazon 관계형 데이터베이스 서비스 (Amazon RDS) 의 데이터베이스 (DB) 인스턴스에 대한 새 운영 체제 (OS) 업데이트를 할 수 있게되어 연락을 드립니다. AWS 상태 대시보드의 “영향 받는 리소스” 탭에서 대상이 되는 RDS 인스턴스의 목록을 확인 하실 수 있습니다. 이는 필수로 해야 하는 패치입니다. 2022년 8월 30일 이전 까지 OS 를 업그레이드하지 않을 경우, Amazon RDS 는 2022년 8월 30일 또는 그 이후에 예정된 유지 관리 기간 동안 OS 를 자동으로 업그레이드 합니다. 이 OS 업그레이드는 Am..

ㅁ 개요 ㅇ 개발과 검수기의 인스턴스는 주기적으로 파일시스템 관리를 해 주어야 한다. 레드마인과 GIT도 인스턴스로 상시 가동이기 때문에 지속적인 사용에 따른 용량이 증가할 수가 있다. ㅇ 볼륨이 부족하면 EBS 볼륨 크기를 늘리고, Linux에 확장된 볼륨을 마운트시키기 위해 작업이 필요하다. ㅁ 인스턴스 볼륨 수정 ㅇ 볼륨의 수정을 시작하면 modify를 거쳐 optimizing 상태가 된다. 이 때에 파일 시스템의 크기를 조정할 수 있다. ㅁ EBS 볼륨 크기 조정 후 Linux 파일 시스템 확장 ㅇ 이 과정은 AWS 자료를 참조하면 된다. 예제 링크 1. df -hT 명령을 사용하여 사용 중인 파일 시스템을 확인한다. 2. lsblk 명령을 사용하여 볼륨에 확장해야 하는 파티션이 있는지 확인한다...

ㅁ 개요 몽고디비 작업에 데이터를 저장하는 로직에 지연이 발생하여, 결국 몽고디비 볼륨을 증설해야 했다. 볼륨을 증설하는 이유와 PV 볼륨 증설 방법에 대해서 정리하였다. ㅁ 몽고디비의 볼륨을 증설하는 이유는? 몽고 디비에 장기 보관이 필요한 데이터를 저장하는 로직에서 지연이 발생하였다. 몽고디비 저장 Redis Que에 적체현상이 모니터링 되었고, AWS Cloud Watch에서는 몽고디비 볼륨의 디스크IO의 유휴지표가 0로 수준이었다. 다시 말해 처리량에 비해 디스크속도가 부족하였다. 몽고디비 볼륨 유형은 gp2였다. Amazon EBS gp2 볼륨의 한계성은 [AWS] Amazon EBS gp2 vs gp3 비교에서 자세히 설명하였다. 간단히 설명하면, gp2의 경우 IOPS를 놓이려면 디스크 크기..

ㅁ 개요 ㅇ PostMan으로 테스트 시에 인증토큰 값은 변수로 지정하여 사용하면 편리하다. 토큰값을 변수로 지정하면 복사해서 다른 테스트요청에 붙일 필요가 없다. ㅇ PostMan의 Tests를 이용하여 받은 값은 변수로 지정하는 방법을 정리하였다. ㅁ PostMan Tests 탭 var data = pm.response.json(); pm.environment.set("prod_token", data.token); pm.environment.set("prod_refresh_token", data.refresh_token); pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); ㅇ responseBoby를 jso..

ㅁ 개요 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가 많이 상승할 때가 있..