코드한입

목표: 서버가 실제로 어느 정도의 요청을 안정적으로 처리할 수 있는지 부하 테스트를 통해 측정하는 방법을 익힌다 결과: k6로 단계적인 부하를 발생시키고 Prometheus·Grafana 지표와 함께 분석해 최대 처리량, 안전 운영 구간, 서버 증설 시점을 판단할 수 있다1. 서버 사양만 보고 처리량을 알 수 있을까?운영 서버를 구축할 때 흔히 이런 질문을 한다.CPU 8코어면 몇 명까지 접속할 수 있을까?RAM 32GB면 초당 요청을 몇 개 처리할 수 있을까?서버 한 대면 충분할까?언제 서버를 한 대 더 추가해야 할까?하지만 CPU와 메모리 사양만으로 정확한 처리량을 알 수는 없다.같은 8코어 서버라도 애플리케이션 구조에 따라 성능은 크게 달라진다.예:서비스 AHTTP 요청→ 메모리 조회→ 응답서비스 ..

목표: SLI, SLO, SLA의 차이를 이해하고 서비스 안정성을 수치로 정의하는 방법을 익힌다 결과: 가용성·응답 시간·오류율을 기준으로 SLO를 만들고 Error Budget을 계산해 배포와 안정성 개선의 기준으로 활용할 수 있다1. CPU 20%면 서비스는 정상일까?지금까지 Prometheus와 Grafana를 이용해 다양한 시스템 지표를 확인했다.예:CPU Usage = 20%Memory Usage = 45%Disk Usage = 38%Load Average = 0.8이 수치만 보면 서버는 매우 정상적으로 보인다.하지만 실제 사용자는 다음과 같은 문제를 겪고 있을 수 있다.로그인 API 응답 시간 = 8초결제 요청 실패율 = 15%파일 다운로드 실패장비 결과 업로드 지연즉 서버 상태가 정상이라고 ..

목표: 운영체제 지표가 아닌 애플리케이션 자체 상태를 Prometheus 형식으로 제공하는 방법을 이해한다 결과: C/C++ 서버에 /metrics endpoint를 추가하고 요청 수, 오류 수, 현재 연결 수, 응답 시간 지표를 수집할 수 있다1. 서버 CPU와 메모리만 보면 충분할까?49편과 50편에서는 Node Exporter를 이용해 다음 시스템 지표를 수집했다.CPU 사용률메모리 사용률디스크 사용률Load Average네트워크 사용량서버 UP/DOWN 상태이런 지표는 서버 전체 상태를 확인할 때 매우 중요하다.하지만 애플리케이션 내부에서 무슨 일이 일어나는지는 알기 어렵다.예를 들어 CPU와 메모리는 정상인데 사용자 요청이 계속 실패할 수 있다.서버 CPU 사용률: 20%메모리 사용률: 45%디..

목표: Prometheus 경고 규칙, Alertmanager, Grafana Alerting이 각각 어떤 역할을 담당하는지 이해한다 결과: 서버 다운, CPU·메모리·디스크 임계치 초과를 자동 감지하고 Webhook, 이메일 등의 알림 경로로 전달할 수 있다1. 그래프를 직접 보고 있어야만 장애를 알 수 있을까?49편에서는 Prometheus와 Grafana를 이용해 다음 지표를 확인했다.CPU 사용률메모리 사용률디스크 사용률Load Average네트워크 송수신량서버 UP/DOWN 상태Grafana 대시보드를 열어두면 서버 상태를 쉽게 볼 수 있다.하지만 운영자가 하루 종일 그래프만 보고 있을 수는 없다.예를 들어 새벽 3시에 서버가 중단됐다면 다음 날 출근한 뒤에야 장애를 발견할 수도 있다.서버 상태..

목표: Prometheus, Node Exporter, Grafana가 각각 어떤 역할을 담당하는지 이해한다 결과: 리눅스 서버의 CPU, 메모리, 디스크, 네트워크 지표를 수집하고 Grafana 대시보드에서 확인할 수 있다1. 장애가 난 뒤 확인하는 것만으로 충분할까?48편에서는 서버 장애가 발생했을 때 다음 명령으로 현재 상태를 확인했다.topfree -hvmstat 1iostat -xz 1df -h이런 명령은 장애가 발생한 순간을 조사할 때 매우 유용하다.하지만 문제가 발생하기 전의 상태는 확인하기 어렵다.예를 들어 사용자가 오전 10시에 서버가 느렸다고 신고했는데, 운영자가 오전 10시 30분에 접속했다면 이미 서버가 정상으로 돌아왔을 수 있다.현재 CPU는 정상현재 메모리도 정상현재 디스크도 정..