재밌는 코딩세상

1. APM 시스템 구성 APM에서 데이터를 수집하기 위해서는 Agent와 서버가 모두 필요하며 아래와 같은 시스템으로 구성 Elastic APM은 데이터를 수집 하기 위한 APM Agent와 수집된 데이터의 가공을 위한 APM Server로 구성 APM Server를 통해 수집된 데이터는 최종적으로 Elasticsearch에 적제되어 Kibana의 APM UI를 이용하여 조회 가능 APM Agent 실시간으로 Performance 및 error 데이터를 수집 하여 APM Server로 전달 APM 서버 연동 실패시 데이터 저장을 위한 memory buffer가 존재 함 APM Server APM Agent에서 수집된 데이터에 대한 유효성 체크 수집된 데이터를 Elasticsearch의 Document ..

서비스 수준 관련 용어 서비스를 운영하는 데 있어서, 사용자에게 필요한 적정 수준을 정의하고 제공하기 위해, 서비스 제공자와 사용자는 서로 서비스 수준 협약(Service Level Agreements, SLA)을 맺습니다. 하지만 고객과의 약속이라는 것은 "어느 정도의 서비스를 제공해야 제대로 제공했다고 말할 수 있는 것인지"를 정확하게 명시하지 않으면 안 됩니다. -> SRE 엔지니어는 척도를 통한 목표를 이해하고, 실제로 목표를 세우는 방법을 알아야 합니다. SLI (서비스 수준 척도, Service Level Indicator) 서비스 수준을 판단할 수 있는 몇 가지를 정량적으로 측정한 값 응답 속도: 요청에 대한 응답이 리턴되기까지의 시간 에러율: 전체 요청 수 대비 처리량(throughput)..

1. nginx 인그레스 컨트롤러 설치 Helm을 이용해서 설치합니다. (minikube addon을 사용하는 것이 아닙니다) 이때 nginx 인그레스 컨트롤러가 프로메테우스용 메트릭을 노출해야 하므로, helm install 과정에서 반드시 설정해야 하는 옵션이 있습니다. helm install ingress-nginx ingress-nginx/ingress-nginx \ --set controller.metrics.enabled=true \ --set controller.metrics.serviceMonitor.enabled=true 메트릭을 내보내도록 컨트롤러를 구성 controller.metrics.enabled와 controller.metrics.serviceMonitor.enabled 옵션을 ..

Bare Minimum Requirement Prometheus Operator가 설치된 환경에서 nginx 인그레스 컨트롤러를 설치합니다. cozserver (v2)의 디플로이먼트 및 서비스를 배포하고, 인그레스를 만들어서 nginx를 통해 서비스에 접근하게 합니다. Prometheus에서 쿼리를 통해 주요 메트릭을 확인합니다. Grafana에 이미 존재하는 대시보드들을 살펴보고, 어떤 쿼리를 사용하는지 확인합니다. 1. nginx 인그레스 컨트롤러 설치(레퍼런스 2 참고) Helm이 있는 경우 다음 명령을 사용하여 수신 컨트롤러를 배포할 수 있음 helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.i..

어떤 조직의 SLO가 다음과 같습니다. "GET 호출의 99%는 10ms 이내에 수행되어야 한다" 그렇다면, 이러한 SLO를 달성하려면 어떤 메트릭을 수집하고 어떻게 계산해야 할까요? (척도는 표준화된 범용 지표를 사용합니다) SLO (서비스 수준 목표, Service Level Objectives) 서비스 공급자 와 고객 간의 SLA(서비스 수준 계약)의 핵심 요소. -> SLI에 의해 측정된 서비스 수준의 목푯 값, 또는 일정 범위의 값을 의미 SLO는 서비스 제공자의 성과를 측정하는 수단으로 합의되며, 오해에 기반한 두 당사자 간의 분쟁을 피하기 위한 방법으로 요약. 해당 SLO를 달성하기 위해 수집하고 계산해야 하는 메트릭은 다음과 같다. GET 호출의 응답 시간 : GET 호출의 시작부터 응답을..

모니터링 시스템에는 메트릭 수집을 위한 두 가지 방식의 메커니즘이 존재합니다. 바로 Pull 방식과 Push 방식입니다. 프로메테우스는 어떤 방식의 메커니즘을 사용하나요? 또한 Pull 방식과 Push 방식은 어떻게 다르며, 장단점은 무엇인지, 또한 해당 방식을 사용하는 모니터링 도구는 어떤 것들이 있는지 연구해 보세요. Metric 수집 방식: Pull vs Push pull 기반 모니터링 시스템은 능동적으로 지표를 획득하는 모니터링 시스템으로, 모니터링이 필요한 오브젝트에 원격으로 접근할 수 있어야 한다. push 기반 모니터링 시스템은 모니터링이 필요한 오브젝트가 적극적으로 지표를 푸시한다. -> 두 가지 방법에는 여러 측면에서 차이점이 크다. 모니터링 시스템의 구축 및 선택을 위해서는 두 가지 방..

Prometheus 모니터링 시스템 프로메테우스는 오픈소스 모니터링/알림 시스템입니다. -> 프로메테우스는 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있습니다. -> 쿠버네티스를 지원하고 관리하는 재단인 CNCF에서 프로메테우스 역시 관리하고 있으며, -> 이 두 도구를 비롯해 시각화를 담당하는 Grafana와 함께 세 도구 조합은 정석적으로 널리 사용되고 있습니다. 프로메테우스 구성 요소 프로메테우스는 시계열(time series) 데이터를 저장합니다. 프로메테우스 서버는 다양한 exporter로부터 각 대상의 메트릭을 pull 하여 주기적으로 가져오는 모니터링 시스템입니다. 예를 들어, 쿠버네티스 관련 메트릭을 가져오고 싶다면 쿠버네티스 exporter를, mongoDB 관련 메트릭을 가져..

쿠버네티스의 경우 클러스터 안에 다수의 노드, 그리고 그 안에 파드를 비롯한 다양한 워크로드가 많게는 수백 개가 실행되는 형태로 구성되어 있습니다. 단일 노드의 경우 리눅스 명령어를 이용하여 하드웨어의 상황을 파악하고, 각 프로세스 모니터링을 했다면, 쿠버네티스의 경우 각 노드는 전적으로 컨트롤 플레인에 의해 관리되므로 우리는 모니터링에 대해 다른 접근 방법을 가져야 합니다 클러스터 환경에서의 문제 해결의 어려움 단일 노드와 비슷하게, 클러스터 모니터링에서도 노드가 사용하는 리소스를 확인할 수 있습니다. 대표적으로 kubectl top 명령어가 있습니다. 이 명령어는 노드와 파드가 각각 얼마만큼의 CPU/메모리 리소스를 사용하고 있는지 확인할 수 있습니다. 한편 쿠버네티스 환경에서는, 여러 개의 마이크로..

Getting Started 0. terraform 기본 정의문 작성 1. vpc autoscaling에 사용할 vpc 생성 2. subnet와 라우팅 테이블 생성 1. autoscaling에 사용할 public subnet 생성 2. 라우팅 테이블에 연결할 인터넷 게이트웨이 생성 3. 라우팅 테이블 생성 4. public subnet과 라우팅 테이블 연결 4. security-group 생성 3. Autoscaling 시작 템플릿 구성 ASG를 위한 시작 템플릿 구성은 다음을 따릅니다. 그룹 정보 원하는 용량: 1 최소 용량: 1 최대 용량: 3 시작 템플릿은 다음 구성을 따릅니다. Ubuntu Server (LTS) t2.nano 기존 혹은 신규 키 페어를 사용합니다 보안 그룹: 인바운드 HTTP 및..

CI/CD 파이프라인의 마지막 Stage는 운영입니다. 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표될 수 있습니다. 그렇다면 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까요? 메트릭이란? 메트릭은 시간에 따라 측정한 결괏값입니다. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 합니다. 예를 들어, 시간당 CPU 사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 합니다. 시간이 아닌 다른 차원(예를 들어, 서비스 별 매출)을 기준으로 삼을 수도 있습니다. 모니터링의 목표 모니터링을 통해 얻고자 하는 것은 다음과 같습니다. -> 시간을 기준으로 측정되는 주요 메트릭을 최소화하여 고가용성을 달성 -> 사용량을 추적하여, 배포에 앞서 세..