일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 | 31 |
- 코틀린 코루틴의 정석
- CloudWatch
- Java
- mysql 튜닝
- minikube
- kotlin querydsl
- APM
- Pinpoint
- aws
- 정보처리기사실기 기출문제
- tucker의 go 언어 프로그래밍
- Kubernetes
- 티스토리챌린지
- 기록으로 실력을 쌓자
- 오블완
- docker
- CKA 기출문제
- Spring
- go
- AI
- Elasticsearch
- 정보처리기사 실기 기출문제
- PETERICA
- 공부
- kotlin
- AWS EKS
- kotlin coroutine
- golang
- CKA
- Linux
- Today
- Total
목록DevOps (163)
피터의 개발이야기

ㅁ 개요 ㅇ 로켓챗에 시스템 알람을 표시 하기 위해 Incommong WebHook을 생성하고 알람을 발송하는 과정을 정리하였다. ㅁ Admin Panel로 이동 ㅁ 인티그레이션 ㅇ 인티그레이션을 클릭한다. ㅇ Incoming 선택 후 + New를 클릭한다. ㅁ Incoming Webhook 생성 ㅇ 활성화를 체크한다. ㅇ #MonitoringAlarm 채널을 입력한다. ㅇ peter 작성자를 등록. ㅇ 채널에 표시될 Alias를 넣는다. MonitoringAlarm로 입력하였다. ㅇ 아바타로 👻 를 선택하였다. ㅇ 스크립트 사용을 활성화 한다. /* exported Script */ /* globals console, _, s */ /** Global Helpers * * console - A norm..

ㅁ 개요 ㅇ 로켓챗은 DevOps에서 중요한 역할을 한다. 개발자의 의사소통 및 정보 공유가 빠르며 쉽게 이루어지도록 도와주기 때문이다. ㅇ 로켓챗을 세팅하고 다루어보기 위하여 Docker 기반으로 설치하는 과정을 정리하였다. ㅁ Rocket.Chat 설치과정 ㅇ linux와 ubuntu에 직접 설치하는 과정을 예시도 있지만 제일 간단한 방법은 Docker로 설치하는 방법이다. ㅇ Rocket Chat의 문서를 기반으로 설치하였다. 바로가기 ++ Rocket.Chat Docker 및 Docker Compose 설치 ㅇ기본적으로 Docker와 Docker-compose가 설치가 되어 있어야 한다. ㅇ 원하는 디렉토리를 생성하여 docker-compose.yml를 다운받는다. # docker 버젼확인 doc..

ㅁ 개요 ㅇ nGrinder 도커 환경 구성 후 간단 실행 과정을 정리하였다. ㅁ 간단 실행 방법 ㅇ google을 테스트 URL로 설정하였다. ㅁ 테스트 생성 ㅇ Test for www.google.com이 생성되었다. ㅁ 테스트 설정 ㅇ Agent : Agent수, Controller에 연결승인된 수만큼까지만 지정할 수 있다. ㅇ 에이전트별 가상사용자 : Agent당 가상 유저수, Process와 Thread로 구성한다. ㅇ 스크립트 : 테스트할 스크립트 ㅇ 테스트 대상 서버 : 테스트 대상 호스트 ㅇ 테스트 시간 : 테스트할 시간 ㅇ 실행 횟수 : 테스트 실행 횟수(각 Thread당으로 전체 실행 횟수는 Vuser per agent를 곱한 값이다) ㅇ Ramp-Up 사용 : 트래픽을 서서히 증가하게..

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