AWS 2022 summit -2 (DevOpsGuru 활용하기 / Observability 관찰 가능성이란?)

데브옵스를 도입할 때 고객들이 많은 어려움을 겪는다.

 

시작하기가 너무 어렵다.

왜?

 

1. 많은 솔루션 중에서 몇 개를 선택해야 함.

2. 너무 많은 서비스를 결합해야 함.

3. 중앙 집중식 관리가 어려움.

4. 내부 전문성 부족 (많은 자율성을 통제할 규정 준수나 보안 위험을 고려해야 함)

 

데브옵스는 개발자와 운영팀을 더 가깝게 만든다.

개발 및 운영을 더 긴밀하게 연결하면, 팀은 더 적은 오류로 훨씬 더 빠르게 작업할 수 있게 된다.

이를 통해, 소프트웨어 빌더는 더 빠른 개발을 할 수 있고, 애플리케이션 생성 주기를 앞당길 수 있다.

 

그렇다면 데브옵스는 무엇인가?

"데브옵스는 문화이며, 모던 애플리케이션 구축을 위한 기초다."

 

* CI/CD

* Observability (관찰 가능성)

* IaC

* Source/artifact 관리

* 복원력 및 보안

 

오늘은 관찰 가능성에 대해서 알아보겠다.

 

관찰 가능성 :

제어 이론에서, 시스템의 외부 출력에 대한 정보를 가지고 시스템의 내부 상태를 얼마나 잘 추론할 수 있는지를 말한다.

 

이슈가 발생했을 때)

모니터링 : 시스템의 상태 측정 (시스템이 혹시라도 멈췄는가)

관찰 가능성 : 내부 상태 추론 (멈췄으면 왜 멈췄는가)

 

좋은 관찰 가능성은, 우리가 질문을 해야 했지만, 그것이 무엇인지 몰라 질문조차 할 수 없었던 질문에 답할 수 있게 해준다.

 

이슈 타임라인

이슈 시작 -> 탐지  ----- > 식별 -----> 수정 ---> 검증

 

탐지 : 이슈를 발견하기까지 걸리는 시간

ㄴ 이슈 alerting이 잘 되어있느냐에 따라서 시간이 오래 걸릴 수도, 얼마 안 걸릴 수도 있다. 

여기까지 걸리는 시간(탐지)을 MTTD (Mean Time To Detect)라고 한다.

식별 : 탐지된 이슈의 근본 원인

ㄴ 보통 가장 많은 시간을 할애하게 되는데, 이전에 경험이 있으면 과거 경험 기반으로 빠르게 해결할 수 있다.

그러나 대부분의 경우, 특히 분산 시스템의 경우 원인 분석에 시간이 오래 걸린다.

여기까지 걸리는 시간(탐지+식별)을 MTTI (Mean Time To Identify)라고 한다.

수정 : 정확한 이슈 수정 사항을 이해하고 수정.

검증 : 올바르게 수정했는지 검증

여기까지 걸리는 시간(탐지+식별+수정+검증)을 MTTR (Mean Time To Resolve)라고 한다.

 

우리가 줄여야하는 것은, MTTD와 MTTI이다.

문제를 신속히 식별하고 정확히 찾아내기 위해 시스템과 프로세스를 설정하는 등 많은 일을 해야한다.

 

이때 우리는 데이터를 기반으로 의사 결정을 해야 한다.

(실시간 데이터로 실시간 의사 결정)

 

* 로그

* 매트릭

* 트레이스

-> AWS 모니터링 및 관찰 가능성 서비스는 다음과 같은 문제를 감지, 조사 및 수정하여 SLA를 유지하는 데 도움이 된다.

(Availability, Reliability, Latency)

-> Amazon CloudWatch

 

운영에 문제가 생겨 애플리케이션에 다운 타임이 발생하면 결국 비용으로 이어진다.

그래서 가능한 실시간에 가깝게 문제를 식별하고 해결하는 것이 중요하다.

 

따라서 실시간 데이터가 필요하고, 실시간에 준하는 의사 결정이 필요하다.

 

로그

Amazon CloudWatch 에이전트를 통해 API 호출 및 기타 메커니즘을 사용하여 AWS 뿐만 아니라 온프레미스 리소스의 다양한 환경에서 로그를 수집할 수 있다.

그리고 Log Insights에서 제작된 강력한 쿼리 언어를 이용해 여러 로그 그룹에서 로그 데이터를 분석할 수 있다.

(이건 Azure의 경우 Log Analytics 같다.)

 

매트릭

Amazon CloudWatch 에이전트를 통해 하이퍼 바이저의 매트릭 뿐만 아니라, 메모리와 디스크 I/O 같은 매트릭도 수집 가능

 

트레이스

AWS X-ray 에이전트, API 호출 등을 통해 분산 환경에서 트레이스를 수집할 수 있고 필터링, AWS X-Ray Analytics와 같은 강력한 도구를 사용하여 근본 원인, 결함, 대기 시간 소스등을 쉽게 식별할 수 있다.

 

 

 

일반적인 이슈 해결 워크 플로우

앞에 주어진 데이터와 도구들을 사용하여 이슈를 해결할 수는 있겠지만, 우리는 문제 해결을 위해 서로 다른 시간에 발생하는 분석 작업들과 데이터 통합을 위한 데이터의 상관 관계를 찾는 일들을 반복하게 된다.

 

하지만... 정말 강력한 방식으로 이런 문제를 해결하기 위해서는 무엇이 필요할까?

 

전체를 아우를 수 있는 플랫폼이 필요하다.

(아 그러니까, 클라우드를 사용하지 않고 각각 별개의 솔루션들을 사용했을 때를 말하는군)

 

 

 

Synthetic 모니터링 : 인공 신호를 보내서 사용자가 오류를 알아차리기 전에 미리 확인할 수 있다.

Contributor insight로 시계열 데이터를 분석하여 가장 부하가 큰 트래픽 패턴을 찾아 워크 로드에 가장 큰 영향을 끼치는 리소스가 무엇인지 찾아낼 수도 있다.

다양한 인사이트 도구들로 각 매트릭, 로그, 트레이스의 상관 관계를 확인하고 마지막 서비스 랜즈맵으로 각 애플리케이션과 데이터들의 상관 관계를 시각화할 수 있다.

 

기존의 문제 해결 플로우가 어떻게 개선될 수 있는지 본다.

 

 탐지 : 사용자가 오류를 보고할 때까지 기다리거나 우리가 설정한 오류 alert를 받기 전에, Synthetics의 경고를 받거나 수집된 트레이스에서 탐지된 이상을 통해 AWS X-Ray Insight에서 알림을 받을 수 있으므로 잠재적 MTTD 단축

식별 : 서비스 렌즈를 사용해 로그, 매트릭, 트레이스의 상관 관계를 지정할 수 있고, 필요한 경우 컨텍스트나 범위를 전환하지 않고 클릭만으로 심층 분석을 위한 도구로 바로 이동할 수 있다.

-> 근본 원인 식별 시간을 줄여준다.

 

서비스가 커질수록 애플리케이션의 가용성을 유지하고 운영 문제를 더 빠르게 해결하는 것이 어려워진다.

 

위에서 언급한 Observability 도구를 사용함에도 불구하고, 여전히 직면한 문제점들이 존재한다.

 

10대의 서버가 잘 동작하고 있는지 감지 vs 500대의 서버가 잘 동작하고 있는지 감지

+ 갑자기 서버가 100대 더 추가된다면?

 

해결해야 할 문제들?

 

- 대량의 데이터 볼륨, 그리고 이질적인 데이터들 (새롭게 생기는 다른 종류의 많은 데이터를 빠르게 처리해야 함)

- 문제 발생시 사용자는 도구와 데이터간 작업을 수동으로 진행하기 때문에 많은 시간과 노력 필요 (새로운 데이터를 올바른 리소스 혹은 이슈에 연결하는 작업)

- 새로운 서비스가 채택될 때마다 새로운 경보 및 모니터링 절차를 구성하려면 깊은 DevOps/CloudOps 전문 지식이 필요

- 여러 도구의 경보 및 알림으로 인해 경보 피로가 발생하고, 쏟아지는 경보에서 가장 중요한 문제를 식별하기 힘듦

 

-> 관찰 가능성 도구를 활용해 많은 부분을 자동화해야 함.

 

"Amazon DevOps Guru"는 이러한 문제들을 해결하기 위해 개발되었다.

애플리케이션을 모니터링하여 가용성을 자동으로 개선하고 MTTR을 줄이는 완전 관리형 기계 학습 기반의 서비스

 

Amazon CloudWatch, AWS x-ray, CloudTrail 등으로 수집한 데이터를 기반으로 기계 학습을 활용하여 이슈 발생에 따른 데이터들을 연관하고, 누락되거나 잘못 구성된 정보, 리소스 고갈에 대한 조기 경보, 서비스 중단으로 이어질 수 있는 코드 및 구성 변경과 같은 운영 문제를 자동으로 감지할 수 있다.

** 기계학습 경험이 전혀 없더라도, 기계 학습을 활용한 운영 자동화를 할 수 있다.

(아마존이 경험한 20년간의 노하우를 활용한다.)

 

왜 Amazon DevOps Guru인가?

- 쉬운 사용

- 운영 문제 자동으로 감지

- 빠른 해결 (새로운 워크로드가 추가 되더라도 바로 적용)

- 쉬운 확장

- 경보 피로 감소 (관련된 이상 현상을 자동으로 연관/그룹화, 불필요한 경보 줄여줌)

 

 

Amazon DevOps Guru를 활성화하면 추가적인 세팅 없이, CloudWatch 매트릭이나 로그에서 분석을 위한 운영 데이터 수집을 시작하고, 기계 학습 디텍터를 사용해 이상을 감지한다.

모든 리소스에 대한 대기 시간, 오류율, 요청 비율과 같은 매트릭을 자동으로 분석하여 정상적인 작동 범위를 먼저 설정한다.

그리고 사전 훈련된 기계 학습 모델을 사용하여 설정된 기준과의 편차를 식별한다

이상이 감지되면 CloudTrail 로그를 조회하고, 해당 이상과 관련된 이벤트를 수집하여 상호 연관시키고 규정된 지침에 따라 권장 사항을 구성한다.

그리고 이 모든 정보를 패키징하여 우리에게 Insight를 제공한다.

+ 웹 애플리케이션 지연 시간 급증, 디스크 공간 부족, 잘못된 코드 배포 또는 메모리 누수와 같은 관련 애플리케이션 및 인프라 매트릭에 대한 문제도 연관지어 찾아낸다.

 

이슈가 생겼을 때 SNS를 통한 알람을 받을 수도 있다.

 

이슈의 탐지, 식별 뿐만 아니라 수정, 검증하는 방법까지 제공한다.

 

Amazon RDS (Aurora) 사용하면, 기계 학습 사용해 호스트 리소스의 과도한 사용률, 데이터 베이스 병목 현상, SQL 쿼리의 잘못된 작동과 같은 광범위한 성능 관련 데이터 베이스 문제를 자동으로 식별하고 분석한다.

그리고 발견된 문제를 해결하기 위한 솔루션도 같이 제공한다.

 

-> "이상 탐지 기능"을 이용한다.

 

DB 부하는 평균 활성 세션(AAS) 단위로 측정되며 데이터 베이스 상태를 이해하는 유용한 지표다.

문제가 있는 비정상적인 데이터베이스를 감지하고, 이상한 부분을 찾으면 원인이 되는 부분을 찾는다.

ex. 대기 이벤트 (특정 사용자, 데이터 베이스의 병목 현상을 나타내는 원인이 된다.)

 

이상 현상에 기여하는 상위 SQL문도 분석하며, 문제가 될 만한 매트릭, 디스크 I/O, 메모리도 같이 분석한다.

 

무엇보다 개발자가 빠르게 조치할 수 있도록 각각의 데이터를 확인할 수 있는 대시보드를 제시하고 해결 방법까지 제시한다.