재밌는 코딩세상

가용성과 확장성 평가 가용성 시스템이 정상적으로 사용 가능한 정도를 말합니다. 정상적인 사용시간(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 관련 메트릭을 가져..

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