재밌는 코딩세상

시스템 성능 지표인 Throughut과 Latency를 바탕으로 개선할 경우, 어떤 부분을 먼저 개선해야 하는지 사례를 통해 알아봅니다. Throughput 개선 고속도로의 예를 다시 빌려, 다음과 같이 세 도시를 연결하는 두 개의 고속도로 중 대구-부산 간 고속도로가 병목을 일으키고 있다고 가정합시다. 이때, 서울-부산 사이의 Throughput은 최소값인, 200대/시간에 불과합니다. 이런 경우에는 도로 확장 공사를 통해 병목을 해결합니다. 확장 공사를 마친 대구-부산 간 고속도로의 Throughput이 800대/시간으로 개선되었습니다. 병목이 아닌 구간(서울-대구)을 개선하는 것은, 전체의 Throughput을 개선하는 데에 전혀 도움이 되지 않습니다. 도리어 대구-부산 간의 정체가 늘어나 Thro..

부하 테스트의 목적 클라우드 환경에서의 부하 테스트 목적 시스템 확장성을 가졌는지 확인 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악 부하가 많이 발생할 때 문제 상황 개선 각 시스템의 병목 지점을 예측하고 진단 및 개선 어떤 부분을 확장할 것인가?: 확장성에 대한 특징 파악 어떤 부분을 확장해야 성능이 높아질지를 고민하기에 앞서, Throughput과 관련한 지표를 먼저 이해할 필요가 있습니다. Throughput: 시간당 처리량으로, 시스템의 성능 지표는 RPS(request per second), TPS(transaction per second)와 같은 단위로 표현됩니다. Throughput은 데이터 전송량에 포커스를 맞춘 성능 지표입니다. 한편 볼륨의 성능을 측정할 경우에는 IOPS(..

가용성과 확장성 평가 가용성 시스템이 정상적으로 사용 가능한 정도를 말합니다. 정상적인 사용시간(Uptime)을 정상사용시간과 사용불가 시간을 합친 전체사용시간(Uptime + Downtime)으로 나눈 값을 표현하며, 예를 들어 가용성 99.95%는 약 1년에 4시간 22분의 다운타임이 됩니다. -> 위의 수식에 따라서 서비스 사용 불가능 시간을 최소로 만들어야 가용성이 올라갑니다. 가용성의 핵심은 바로 단일 장애점(Single Point of Failure)을 없애는 것 즉, 어떤 한 노드가 장애가 발생해도, 동일한 처리 능력을 가진 다른 노드로 대체될 수 있어야 합니다. -> 이를 위해 필요한 것이 바로 시스템 확장임 확장성 확장 가능한 시스템: 요구되는 시스템의 성능에 따라 동적으로 서버 구성이 ..

AWS에서는 인스턴스나 볼륨에 대해서 버스트 기능을 제공합니다. 이는 평소에 사용하지 않을 때의 성능을 모아두고, 부하가 발생할 경우 일시적으로 성능을 올리는 기능입니다. 이것이 어떤 메커니즘으로 작동하는지 연구하세요. 기존 Amazon EC2 인스턴스 유형은 고정된 CPU 리소스를 제공하는 반면, 성능 순간 확장 가능 인스턴스는 기본 수준의 CPU 사용률을 제공하면서 기본 수준 이상으로 CPU 사용률을 버스트 하는 기능을 제공합니다 -> 이렇게 하면 기준 CPU와 추가 버스트 CPU 사용량에 대해서만 비용을 지불하면 되므로 컴퓨팅 비용이 절감됨 기준 사용률과 버스트 기능은 CPU 크레딧에 의해 좌우됩니다 성능 순간 확장 가능 인스턴스는 CPU 사용량에 대해 크레딧을 사용하는 유일한 인스턴스 유형입니다 ..

서비스 수준 관련 용어 서비스를 운영하는 데 있어서, 사용자에게 필요한 적정 수준을 정의하고 제공하기 위해, 서비스 제공자와 사용자는 서로 서비스 수준 협약(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 관련 메트릭을 가져..