[데이터플랫폼] 텔레메트리 조사

[공고] 넷마블 - 모니터링 서비스 백엔드 개발자

• 주요 업무
  • 넷마블의 모든 서비스 모니터링 시스템 개발
• 자격 요건
  • Java (Spring Framework) 경험
  • 대용량 서비스 기본 이해
  • IT 서비스 개발/운영 경험
  • 공통화/모듈화/자동화 설계/구현 능력
  • 컨테이너 기반 서비스 경험
• 우대 요건
  • React or Front-end Framework 경험
  • Prometheus, Grafana, Elasticsearch, OpenTelemetry 경험/이해
  • AWS, GCP 등 클라우드 환경 서비스 운영 경험

https://netmarble.engineering/monitoring-service-team-backed-developer/

[마감]모니터링서비스 백엔드 개발자 - 모니터링서비스팀 - 넷마블 기술 블로그

 

[서비스] IBM Cloud Monitoring with Sysdig

• 클라우드 모니터링 개념
  • 컨테이너 가시성, 서비스 지향적 뷰, 종합적 매트릭을 얻을 수 있음
  • 급증하는 호스트/애플리케이션에 따라 발생하는 기존 모니터링 툴 문제 해결
  • 늘어나는 인프라의 복잡성 관리 및 위협 탐지하여 소프트웨어 라이프 사이클 전체 문제 해결
• 클라우드 모니터링 특장점
  • 성능 인시던트(incidnet) 빠른 진단/해결
  • 모니터링 인프라의 비용 제어
  • 사용자 환경 시각화
  • 동적 마이크로 서비스 모니터링의 중요 쿠버네티스/컨테이너 인사이트 확보
  • 선제적 알림으로 비정상 상황의 영향 최소화
  • 데이터 액세스 제어를 위한 사용자/그룹 관리
  • 애플리케이션/인프라 문제 해결

https://www.ibm.com/kr-ko/cloud/sysdig

 

[기사] 마이크로서비스 모니터링 전략... 'RED'의 개념과 장단점

• 요청 수(Rate), 오류율(Error), 소요 시간(Duration)에 중점을 두는 모니터링 기법
• 'RED'로 최종 사용자 대상의 서비스 동작 파악 가능

 

• 톰 윌키가 구글에서 터득한 토대로 만든 모니터링 방법론
• 구글 SRE(Site Reliability Engineering)팀에서 개발한 '4가지 황금 신호'에서 파생
  • SRE팀이 작성한 무료 책자 : Site Reliability Engineering
  • 4개의 황금 신호 : 지연 / 트래픽 / 오류 / 포화 (참고 사이트)
• USE 기법(RED 기법 이전의 기법)이 최신 소프트웨어 아키텍처의 목표화 일치하지 않음
  • USE : 사용률 / 포화도 / 오류율 확인
  • USE는 하드웨어/인프라에 더 많이 적용됨
  • RED는 애플리케이션 사용자의 경험에 중점
  • 마이크로서비스 아키텍처 / 컨테이너 / 클라우드 인프라 시대에서 하드웨어 메트릭은 서비스 수준 목표 (Service Level Objectives; SLO)가 충족되면 중요하지 않음
• RED 핵심 지표
  • 요청 수(Rate) : 서비스가 초당 처리하는 요청 수
  • 오류율(Error) : 초당 실패한 요청 수
  • 소요 시간 (Duration) : 각 요청에 드는 시간
• RED의 이점
  • 서비스의 문제 이유를 파악하는 인지 부하 감소
    - 각 서비스의 내부 디테일을 전체 아키텍처에서 이해하도록 추상화
  • 사용자/기업의 전체 목표에 부합
    - CPU 사용량 / 메모리 사용량 / 기타 하드웨어 지표를 신경쓰지 않음
• RED의 한계
  • 배치 프로세싱 / 스트리밍 관련 인사이트를 제공하지 못할 수 있음
    - 요청 기반 애플리케이션이 주요 대상
  • 서비스 장애에 얼마나 가까운지 파악이 어려움
    - 트래픽 증가로 응답 시간이 증가할 수 있지만, 그 이유를 파악할 수 있는 내부 애플리케이션 지표가 없을 수 있음

https://www.ciokorea.com/news/213954