daliy

NewRelic (FutureStack Seoul)

no-easy-ray 2022. 10. 13. 23:52

지난 10월 5일 뉴렐릭 코리아에서 진행하는 FutureStack Seoul에 다녀온 내용에 대해서 기록을 남겨보려고 합니다.

 

참여 이유

현재 저는 회사에서 EKS에서 운영되는 서비스들의 Monitoring을 위하여 NewRelic을 사용하고 있습니다.

이번에 뉴렐릭 세션에 참여해보고 싶었던 이유는 다른 회사들은 뉴렐릭을 어떻게 사용하는지를 알고 싶었습니다.

종종 메가존 클라우드와 뉴렐릭 코리아와의 미팅을 통해 뉴렐릭에 대한 가이드와 신규 기능들에 대해 소개를 해주시지만 일종의 가이드일 뿐 실제 사례에 대한 내용들이 부족하다고 느꼈고, 이러한 궁금증들이 어느 정도 해결이 될 거라는 기대로 참여하게 되었습니다.

 

행사 목차

오전 세션

  • Open Telemetry FOK (핸즈온 워크샵 - 랩탑 지참)
  • Observability as a code (핸즈온 워크샵 - 랩탑 지참)

 

오후 세션

  • 옵저버빌리티를 통한 IT 전략의 변화
  • 뉴렐릭 솔루션 Overview (Observability and M.E.L.T)
  • 코빗(Korbit) 사례 공유
  • How NR operates Kubernetes at scale as an Observability platform
  • How to Troubleshoot your Full Stack in Context (Infra, NPM, Logs)
  • How to accelerate innovation to develop & operate service using AWS Marketplace (AWS Marketplace)

 

모든 목차에 대해서 소개하기보다는 행사에 참여하면서 개인적으로 경험해보고 인상 깊었던 내용들을 정리해 보려고 합니다.

 

 

Monitoring vs Observability

NewRelic은 Monitoring 툴이 아닌 Observability 툴 이라고 설명하는 점이 가장 인상 깊었고, 주로 사용되는 DataDog 등이 어떤 설루션인지에 대한 이해도가 증가했던 것 같습니다.

 

간단히 정리하자면

Monitoring은 현재 상태를 진단하는것이라고 볼 수 있습니다.

예시로 동네 병원에서 간단한 진료받는것을 생각해보면 이해가 쉬울 것 같습니다. 현재 내가 코로나가 걸렸는지 안 걸렸는지 현재 상태만을 보고 검진하여 판단을 내리게 됩니다.

 

하지만 Observability 는 보다 확장된 개념이라고 볼 수 있습니다.

뉴렐릭 측에서는 과거의 상태 현재의 상태 종합적인 정보들을 활용하여 미래를 예측 및 대비할 수 있는 것이라고 정의합니다.

예시로 종합병원에서 전문적인 건강검진을 받는것을 생각해볼 수 있습니다. 과거의 내 몸의 상태가 어땠는지? 지금까지의 식습관은 어땠는지? 현재의 상태는 어땠는지 등 다양한 정보를 수집하여 앞으로 조심해야 하는 행동들과 일어날 수 있는 상태들을 예측할 수 있게 됩니다.

 

이러한 부분에 있어서 Monitoring과 Observability의 차이점이 존재하고, 뉴렐릭은 Observability를 도와주는 솔루션이라고 소개해 주었습니다.

 

 

Observability as Code

이번 행사에서 개인적으로 가장 큰 임팩트가 있다고 생각했던 부분 중 하나입니다.

 

확실히 Terraform이 트렌드라는 것을 확인할 수 있었고(행사장에서 Terraform을 거의 대부분의 회사가 사용한다는 점을 느낄 수 있었습니다.), Terraform은 IaC(Infra as a Code)로서만 사용된다고 생각했는데 이제는 다양한 SaaS의 형상까지 관리하게 되었다는 게 놀라웠습니다.

 

APM을 제외한 모든 부분, DashBoard, Alert, Log DropFilter, synthetics 등 뉴렐릭에서 사용자가 직접 손으로 만들 수 있는 모든 부분을 이제는 Code로서 관리할 수 있다는 점이 개인적으로는 맘에 들었던 것 같습니다.

 

Code로 관리되었을 때 이점은 다음과 같습니다.

  1. 생성과 삭제가 빠르고 깔끔하다.
  2. 코드 리뷰를 할 수 있다. (서로 간의 검증이 가능해진다.)
  3. 리소스 관리가 쉽다. (Terraform에 익숙해졌을 경우)
  4. 변경이력이 남는다. (퇴사자 혹은 신규 입사자에게 도움이 될 수 있다.)

위의 이점들은 뉴렐릭의 기능들을 더 다양하게 사용할수록 더욱더 발휘될 것이라고 생각합니다.

현재의 회사에는 APM을 제외한 NewRelic의 기능들을 사용자(제가...)가 직접 추가하고 있기에, 추후에 NewRelic 기능 사용에 대한 고도화가 이루어진다면 terraform을 사용해보는 것을 어떨까 생각해 볼 수 있었습니다.

 

 

MELT (Metrics, Events, Logs, Traces)

Observability를 위해서 과거와 현재의 다양한 정보들을 확인해야 하는데 이를 위해 확인하는 정보들이 바로 MELT라고 뉴렐릭에서는 이야기합니다.

MELT를 뉴렐릭에서 확인

뉴렐릭을 통해서 위의 데이터를 확인하여 현재 서비스들의 상태를 측정하고 미래를 예측 및 대비할 수 있게 된다.

 

 

Guide or Tip

세션을 진행하면서 스피커로 참여하신 뉴렐릭 코리아 시니어 개발자 분들이 가이드 하는 내용을 정리합니다.

 

Versioning

뉴렐릭 관련 라이브러리, agent의 버전을 항상 최신으로 유지하는 것을 권장한다.

뉴렐릭의 새로운 기능들이 호환되지 않을 수가 있다.

 

Alert

  • workload를 활용하라 (Incident는 추후 지원되지 않을 예정)
  • 모든 APM 리소스에 대해서 Alert를 걸어두는 것이 중요하다. (회색으로 표기된 것이 없어야 한다.)
  • WorkLoad를 이용하게 될 경우 특정 조건이 발생했을 시 다른 정보도 같이 추가할 수 있다.
    (ex: Frontend CPU > 80 알람 발생 시 다른 API의 메트릭 정보도 같이 보내줄 수 있음.)
  • Alert에 대한 채널 관리 및 네이밍에 신경 써라

 

Log

로그를 수집할 때 기본 형태가 아닌 특정 포맷으로 파싱 되어 들어올 수 있도록 설정하는 것을 추천

설정 안 하면 message로 오지만 설정하면 해당 포맷(ex: nginx log format)으로 들어오게 됨

https://docs.newrelic.com/docs/logs/ui-data/built-log-parsing-rules/

 

NRQL

뉴렐릭에 어느 정도 적응이 되었다면 NRQL을 이용해 보는 것이 더 좋을 수 있을 거 같다.

 

Kubernetes Resource optimization

리소스 최적화에 대해서는 끝이 없다.

초기에는 여유 있게 운영 한 되 뉴렐릭을 활용하여 점차 줄이는 방향으로 할 수밖에 없는 것 같다. (뉴렐릭도 그렇게 한다. 대부분 동의하는듯했음)

줄이는 과정에서는 Alert를 활용할 수 있다. 특정 지점에 대한 Alert가 주기적으로 발생되지 않는다면 리소스를 더 줄여도 된다는 의미로 사용한다.

 

NewRelic Pixie

쿠버네티스 모니터링과 APM이 존재하면 크게 사용할 이유는 없으나, 고객 사례로 요청에 대한 패킷 모니터링을 원하여 사용하는 사례가 있다.

 

SRE

SRE관점에서 SLI, SLO를 설정한 뒤, 이를 기반으로 한 KPI를 작성해 볼 수도 있다.

 

소감

여러 기업들의 다양한 사례를 듣고 싶었지만 생각보다 다양하다고 생각되지는 않았던 것 같습니다.

하지만, 뉴렐릭을 좀 더 다양한 방면에서 활용하는 사례를 알 수 있어 좋았고, Terraform이 인프라 외적으로도 더많이 사용되고 있는것(Observability as a Code) 을 체험해볼 수 있어서 신기했습니다.

뉴렐릭 코리아에서 best practice 느낌으로 이야기 해준 가이드 들은 회사에도 적용할 수 있으면 좋겠다고 생각해보는 시간이 되었습니다.