[다운로드] MSA 환경에 Observability가 필수인 3가지 이유

MSA 환경에서 Observability의 필요성과 SRE(Site Reliability Engineering)의 주요 요소, 그리고 이를 효과적으로 구현하기 위한 방법들을 설명합니다.

목차 (Agenda)

MSA 환경에는 왜 Observability가 필수인가?

MSA 환경에서 Observability의 필요성과 SRE(Site Reliability Engineering)의 주요 요소, 그리고 이를 효과적으로 구현하기 위한 방법들을 설명합니다.

클라우드 네이티브 전환 진단 발표 자료 다운로드

쿠버네티스, 개념부터 제대로 잡고 싶다면

배포·확장·복구를 자동화하는 클라우드 네이티브 표준. CNF에서 핵심 개념을 한 번에 정리하고, 필요하면 전문가 상담까지 이어가세요.

(필수) 개인정보 수집 및 동의

MSAP.ai는 오픈마루와 투라인클라우드가 공동 운영하는 브랜드로, 본 서비스 이용 과정에서 수집된 개인정보는 양사(오픈마루 및 투라인클라우드)가 공동으로 수집 및 관리하며, 아래의 목적에 따라 이용됩니다.
※ 오픈마루 및 투라인클라우드는 MSAP.ai 브랜드의 공동 운영사입니다.
개인정보 수집·이용 내역
수집 항목 회사명, 성명, 직급/직책, 연락처, 이메일
수집 목적 - 서비스 이용에 대한 문의 응대 및 관련 정보 제공
- 교육, 세미나, 이벤트 등 참가 신청 접수 및 운영
- 뉴스레터, 제품 안내 등 마케팅 정보 제공
보유 및 이용기간 서비스 이용 문의 접수일로 부터 5년간 보관
* 귀하는 위 개인정보 수집 및 이용에 대한 동의를 거부할 권리가 있으며, 다만 동의하지 않을 경우 서비스 제공 및 관련 안내에 제한이 있을 수 있습니다.

‘MSA 환경에는 왜 Observability가 필수인가?’  발표 영상

‘MSA 환경에는 왜 Observability가 필수인가?’  핵심내용

MSA 환경에서 Observability의 필요성 및 문제점

클라우드 네이티브 전환 진단 결과 예시
  • 서버 관리 수요가 지속적으로 증가하고 있어, Observability는 이제 필수적인 요소로 자리잡고 있습니다.
  • 클라우드 네이티브 환경에서는 애플리케이션당 워크로드와 API 트래픽 흐름이 폭발적으로 증가하고 있습니다.
  • 마이크로서비스 아키텍처(MSA)에서는 전통적인 모니터링 방법이 복잡하고, 모든 서비스를 한눈에 파악하기 어려운 상황입니다.
  • 특히, 연결된 마이크로서비스 수가 500개에 달하는 대규모 애플리케이션의 모니터링은 매우 어려운 과제입니다.
  • 시스템의 비대화와 인력 부족으로 작업량이 증가하는 문제를 겪고 있으며, 배포 시마다 다양한 이슈가 발생할 수 있습니다.

MSA 환경에서의 모니터링과 서비스 운영

클라우드 네이티브 전환 진단 결과 예시
  • MSA(마이크로서비스 아키텍처) 환경에서는 장애가 발생할 수 있다는 인식이 필요하며, 장애 발생 시 빠르게 원인을 찾아 해결하는 것이 중요합니다.
  • 서비스의 목표 설정이 필수적이며, 서비스 안정성을 높이기 위해 Agile하게 개선해 나가는 과정이 중요합니다.
  • 개발팀과 운영팀은 각기 다른 목표를 가지고 있으며, 개발팀은 Agile한 서비스 개발을 중요시하고, 운영팀은 안정적인 서비스 운영에 집중해야 합니다.
  • 따라서, 개발자와 운영자 간의 협력이 필요합니다.

SRE(사이트 신뢰성 엔지니어링)의 개념과 요소

클라우드 네이티브 전환 진단 결과 예시
  • SRE(Site Reliability Engineering)는 소프트웨어 엔지니어가 운영 팀을 설계하도록 요청받았을 때 발생하는 개념으로, 구글의 Benjamin Treynor에 의해 설명되었습니다.
  • SRE는 2003년 구글에서 시작되었으며, 이는 급격한 트래픽 증가로 인해 소프트웨어 엔지니어가 직접 운영을 담당하게 되는 팀을 신설한 데서 비롯되었습니다.
  • SRE는 DevOps 원칙을 실현하는 기술적 방법 중 하나로, 대기업과 클라우드 네이티브 환경에서 표준 운영 방식으로 자리잡고 있습니다.
  • SRE의 7대 요소로는 모니터링과 로깅, 자동화와 CI/CD, 성능 및 확장성, 사고 대응/장애 복구가 포함됩니다.
  • 신뢰성과 가용성 관리에는 SLO(Service Level Objective), SLA(Service Level Agreement), SLI(Service Level Indicator)와 같은 지표를 정의하고 모니터링하는 것이 중요합니다.

SRE의 주요 요소: 사고 대응 및 장애 복구

클라우드 네이티브 전환 진단 결과 예시
  • Incident는 예기치 않게 발생하며 서비스에 가용성, 성능, 신뢰성, 보안에 영향을 미칩니다.
  • SRE에서 Incident 대응 방법으로는 SLO 및 오류 예산 기반 운영과 강력한 모니터링, 자동화된 알림 시스템 구축이 필요합니다.
  • Incident 대응 프로세스는 탐지, 진단 및 분류, 대응 및 복구, 사후 분석(Postmortem)으로 나뉩니다.
  • Observability는 시스템 상태를 파악하기 위한 중요한 요소이며, 클라우드 네이티브 환경에서는 복잡한 문제를 이해하고 해결하기 위해 필수적인 도구입니다.
  • 전통적인 3티어 시스템에 비해, 분산 시스템에서는 장애 발생 위치와 원인을 찾기 어려운 구조적 복잡성이 존재합니다.

Observability의 3요소 및 핵심 도구

클라우드 네이티브 전환 진단 결과 예시
  • Observability는 메트릭, 트레이싱, 로깅의 세 가지 요소가 함께 동작하여 시스템 상태를 정확하게 파악하는 데 필수적인 요소입니다.
  • 트레이싱은 서비스 호출 관계, 발생한 이벤트의 흐름, 성능 병목 등을 기록하여 한눈에 볼 수 있도록 도와줍니다.
  • 주요 도구로는 메트릭 모니터링을 위한 Prometheus와 Grafana, 트레이싱을 위한 Jaeger와 Zipkin, 로깅을 위한 Grafana Loki가 있습니다.
  • Kubernetes 환경에서는 자동화된 수집이 중요하며, 단일 호스트에 하나의 에이전트를 설치하여 효율적으로 모니터링할 수 있습니다.
  • SRE를 위한 모니터링 기능으로는 CPU, 메모리, 디스크, 네트워크 사용량 등이 포함되며, 애플리케이션 성능 모니터링 시 요청 처리 시간, 오류율, 처리량이 중요한 요소로 꼽힙니다.

마무리

  • 문의사항 : hello@msap.ai / 02-6953-5427

컨설팅

우리 인프라, 클라우드 네이티브로 갈 준비가 됐을까요?

현재 인프라 상태를 진단하고 전환 효과와 리스크를 확인해 드립니다.
쿠버네티스·컨테이너·PaaS 전환을 데이터로 판단하세요.

🏆 조달청 디지털서비스몰 등록 플랫폼

Go to Top