탑을 쌓자

Altering rule 이란 프로메테우스의 한 기능으로서 PromQL을 기반으로 알람 조건을 정의하고, 외부 서비스에 FIRING 된 알람들을 외부로 전달할 수 있다. 해당 역할을 수행하기 위해서는 2개의 리소스가 필요하다.  1. Altering rule Altering rule은 이전의 Recording rule 처럼 특정 PromQL을 지표로 사용하거나 Recording rule 그 자체를 사용하여, 어떠한 지표를 기준으로 알람을 동작시킬지 정의한다. 알람은 3개의 상태가 있다. - INACTIVE: 설정한 조건을 충족하고 있지 않을 때- PENDING: 설정한 조건을 충족 하지만, 지정한 지속 시간(for) 시간의 임계치 보다 낮을 때- FIRING: Altering rule의 조건을 모두 충족..

취업 당시, 나는 IT 직무에 대해 Front-end와 Back-end 포지션 정도만 알고 있었을 정도로 IT 직무에 대한 지식이 부족했다. Back-end 분야의 수요가 많다는 이야기를 듣고, 그 방향으로 준비하게 되었고, 결국 대학 졸업을 앞두고 1학기가 남은 시점에서 취업에 성공했다. 내가 특별히 바라던 회사는 없었다. 단지, 지금까지 공부한 것을 활용해 일할 수 있는 곳이면 충분했다. 기대 반, 걱정 반의 마음으로 시작한 회사 생활은 나중에 다닐 회사들에 대한 기대를 키워주기에 충분했다. 면접 때 "우리 회사는 사람이 복지야!"라는 말이 실감 날 정도로, 동료들은 나에게 지나치게 좋은 사람들이었다. 그래서 퇴사를 결심할 때 가장 망설여졌던 것은 바로 이런 동료들과의 헤어짐이었다. 하지만, 회사에서..

recording rule 이란 자주 필요한 표현식이나 계산 비용이 큰 표현식을 미리 계산해서, 그 결과를 별도 시계열 셋으로 저장해 둘 수 있는 기능이다. 즉 성능과 재사용성을 높이기 위해서 사용할 수 있다. 예를 들어보자. 원하는 시계열 데이터를 만들기 위해서 5개의 시계열 데이터가 들어가고, 하나의 프롬 쿼리당 1의 리소스가 든다고 가정해 보자. -> 데이터를 요청할 때마다 5의 리소스가 들어가게 된다. 반면에 recording rule을 사용하면, 처음에 5의 리소스가 들어가게 되고, 해당 값을 저장하는 시계열 데이터가 만들어진다. -> 데이터를 요청할 때마다 1의 리소스가 들어가게 된다. 여기서 프롬 쿼리가 복잡하다면 더 많은 차이가 나타나게 된다. 물론 별도의 시계열 데이터로 저장해서, 저장 ..

프로메테우스로 지표를 수집했으면, 해당 지표를 사용하기 위해서는 PromQL을 사용해야 한다. mysql에서 query를 사용하는 것과 비슷한데, 문법과 값들이 조금씩 다르다. 하나씩 알아보자. PromQL 타입 mysql에서 int, string 같은 자료형이 있듯이 PromQL에도 guage, counter, summary, histogram 4가지의 자료형이 존재한다. 예와 함께 살펴보자. Gauge 특정 시점의 값을 표현하는 타입이고, 예시로는 cpu, 메모리 사용량의 현재 시점이 있다. 말했듯이 검색 시점에서 값들을 의미한다. Counter 현재 시점까지의 누적된 값을 표현하는 타입이고, 예시로는 gc를 수행하는데, 걸린 시간을 누적값을 가지고 있는 것을 볼 수 있다. Summary 구간 내에 ..

이제 EKS를 Terraform으로 간편하게 만들고, Prometheus와 Grafana를 적용해 보자. EKS 생성 (With Terraform) Github에서 볼 수 있고 사용 방법은 README를 보기 바란다. 시간이 약 10분 정도 걸리고, 완성된 것을 볼 수 있다. EKS 세팅 (kubectl 설치 가정) 이제 로컬에서 kubectl을 사용할 수 있도록 kubeconfig를 업데이트해줘야 한다. aws eks update-kubeconfig --region region-code --name my-cluster # 서울의 경우 ap-northeast-2 사용하면 ~/. kube로 이동하면 config파일이 업데이트된 것을 볼 수 있다. 이제 EKS를 cli로 다룰 수 있게 도와주는 eksctl을..

EC2 기반 애플리케이션의 프로메테우스 지표를 수집하고, 그라파나로 시각화해볼 예정이다. 프로메테우스, 그라파나 서버 인스턴스 생성 프로메테우스와 그라파나를 docker 컨테이너로 돌릴 예정이다. EC2 인스턴스 하나를 준비하자. 이름을 지정해준다. 이때 이름은 자동으로 Name 태그로 들어간다. 보안 그룹은 다음과 같이 해준다. 3000 포트: 그라파나 대시보드 접근 포트 9090 포트: 프로메테우스 접근 포트 (테스트가 끝나면 닫아도 됨) 8080 포트: 애플리케이션 포트 (같은 인스턴스 내에서 애플리케이션을 돌릴 예정) 22 포트: 해당 cidr은 AWS instance connect를 사용할 때 AWS 측의 IP range다. (key pair 없이 사용할 수 있음) 서버 인스턴스 설정 EC2 연..

SpringBoot 모니터링으로 개념 설명과 로컬에서 띄워본 적이 있다. 1년 반 만에 작성하게 됐는데, 회사 생활과 AWS 인프라가 우선순위가 높았다. 현재는 조금 여유로워져서 이어서 포스팅하려고 한다. 아래의 순서대로 목차를 진행할 예정이다. 1. 다양한 환경 메트릭 수집 - 단일 EC2 기반 - EKS 파드 2. Prometheus 심화 - Promql - 알람, 레코딩 - 고가용성 3. Grafana 심화 - 필요한 부분 추가할 예정 기본적으로 애플리케이션은 SpringBoot고, 각자의 환경에 맞게 구성하면 된다.

EB 정복하기 - 1 EB 정복하기 - 2 EB 정복하기 - 3 EB 정복하기 - 4 EB 정복하기 - 5 EB 정복하기 - 6 EB 정복하기 - 7 EB 정복하기 - 8 EB 정복하기 - 9 EB 정복하기 - 10 테라폼이 유료화가 되면서, 테라폼 프로젝트에서 포그돼 Opentofu라는 프로젝트가 완성됐고 리눅스 파운데이션에 속해있다. 밑의 프로젝트는 테라폼으로 돼있지만, Opentofu로 변경해서 실행해도 무방하다. Github 레포에서 sample-code-version버전을 사용하면 된다. 테라폼은 일반적으로 모듈을 지원하는데, Github와 같이 원격 저장소에 있는 것도 사용할 수 있다. 해당 코드들은 작성자의 레포에서 임포트해서 사용한다. 실행 방법은 매우 간단하다. # 1. sample-co..

EB 정복하기 - 1 EB 정복하기 - 2 EB 정복하기 - 3 EB 정복하기 - 4 EB 정복하기 - 5 EB 정복하기 - 6 EB 정복하기 - 7 EB 정복하기 - 8 EB 정복하기 - 9 환경을 구성하고, 해당 환경을 EBExtensions로 환경을 변경해 본다. 환경 구성 구성한 환경은 아래 캡처를 참고하면 된다. 환경은 도커이고, 고가용성을 선택했다. 현재 구성은 최소 인스턴스 1, 최대 인스턴스 4, 스케일 아웃 인 트리거는 NetworkOut이다. 활용한 EBExtensions 오토 스케일링 크기를 지정하는 ebextension option_settings: aws:autoscaling:asg: MinSize: 2 MaxSize: 4 EC2의 config다. 여기서 좋은 것은 SSHSourc..

EB 정복하기 - 1 EB 정복하기 - 2 EB 정복하기 - 3 EB 정복하기 - 4 EB 정복하기 - 5 EB 정복하기 - 6 EB 정복하기 - 7 EB 정복하기 - 8 이전에 애플리케이션 EB Health Check URL 지정과 환경 변수 지정한. ebextensions 자주 쓸만한 옵션들을 알아보고 다음 포스팅에서 적용해 볼 예정이다. aws:autoscaling:asg 인스턴스의 가용 영역 설정, 스케일링 아웃 다운 휴지기 시간 지정, 용량 리밸런싱, 최소 사이즈, 최대 사이즈가 있다. 간단하게 모든 옵션에 대해서 예시를 적어봤다. 필요에 맞게 설정하면 된다. option_settings: aws:autoscaling:asg: Cooldown: '720' # default 360 MinSize:..

EB 정복하기 - 1 EB 정복하기 - 2 EB 정복하기 - 3 EB 정복하기 - 4 EB 정복하기 - 5 EB 정복하기 - 6 EB 정복하기 - 7 Github Action, CodePipeline 비교 CodePipeline CI/CD를 구현해 보기 앞서 Github Action과 비교해 보자. 1. Trigger Github Action: workflow.yaml 파일 기준으로 merge시 동작 CodePipeline: CodeStar로 Github 레포지토리와 브랜치 연결 merge시 동작 workflow 파일에서 on: push: branches와 마찬가지로 CodePipeline에서도 특정 브랜치를 지정할 수 있다. 물론 다른 방법도 있지만, 자동화하기에 좋은 방법이라고 생각한다. 2. Bui..

EB 정복하기 - 1 EB 정복하기 - 2 EB 정복하기 - 3 EB 정복하기 - 4 EB 정복하기 - 5 EB 정복하기 - 6 우선적으로 EB 정복하기 - 6을 보고, 대략적인 틀을 보고 오자. AWS IAM 사용자 생성, 정책 부여 AWS IAM 사용자를 생성하고, Github Action에서 EB 배포에 사용되는 정책들을 모두 줘야 한다. github-action-deploy 사용자를 생성해 주자. 정책은 생성한 후에 붙여줄 예정이므로 이름만 채우고 바로 생성해 준다. AccssKey는 필요하므로 발급한 후 저장해 준다. (노출되면, 악용될 수 있으므로 노출되지 않게 한다.) 이제 필요한 정책을 알아보자. 1. AdministratorAccess-AWSElasticBeanstalk 해당 정책은 AW..