Presentation

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

MSA 전환 및 클라우드 네이티브 환경 구축을 고민하고 계신 분들이라면 발표자료를 통해 성공 전략을 꼭 확인해보세요!

2025년 03월 21일

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

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

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

(필수) 개인정보 수집 및 동의
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