데이터 수집 최적화로 New Relic 비용 50% 절감하기

안녕하세요.

숨고 Platform Chapter의 DevOps Engineer Ted 입니다.

이번 포스팅에서는 숨고에서 사용하는 Full-stack Observability Platform인 New Relic을 사용하며 New Relic 사용 비용을 획기적으로 절감한 경험을 공유하고자 합니다.

Monitoring vs. Observability

흔히 ‘서비스를 모니터링한다’와 같이 우리나라에서는 모니터링(Monitoring)이라는 단어가 다양한 분야에서 사용되고 있습니다. 본격적인 포스팅의 시작에 앞서 원활한 논의를 위해 Monitoring과 Observability를 아래와 같이 구별하여 정의하고자 합니다.

• Monitoring(모니터링) : 현재 상태를 진단하는 것
• Observability(관찰 가능성, 관측성, 또는 옵저버빌리티) : 과거의 상태, 현재의 상태 종합적인 정보들을 활용하여 미래를 예측 및 대비할 수 있는 것

* 이 내용은 Platform Chapter DevOps Engineer이신 Ray께서 정리해주신 New Relic 컨퍼런스의 내용을 참고하였습니다. 감사합니다. Ray!

개발자마다 정의는 다를 수 있지만 일반적으로 Monitoring이 현재 상태에 대한 진단에 초점을 맞춘다면 Observability는 단순히 현재 상태를 진단하는 것을 넘어 과거와 현재 정보를 활용하여 미래를 예측하는 개념이라고 생각하면 좋을 것 같습니다.

New Relic의 기능 중에는 이전에 쌓인 데이터를 바탕으로 에러나 장애를 예측하는 기능도 제공하고 있어 단순한 Monitoring Tool이 아닌 Full-stack Observability Platform이라고 말씀드릴 수 있을 것 같습니다. 다만, 저희가 이번 포스팅에서 소개하는 New Relic을 활용하여 진행한 일련의 task들에 대해서는 보다 쉬운 이해를 위해 ‘모니터링’으로 표현을 통일하였습니다.

숨고가 New Relic을 사용하는 이유

숨고의 서비스들은 흔히 MSA로 잘 알려진 마이크로서비스 아키텍처로 구성되어 있습니다. 이름에서 알 수 있는 것처럼 서비스가 작게 분해되어 있기 때문에 개발과 배포가 용이하고 장애 전파를 최소화할 수 있다는 장점이 있지만 그에 반해 관리 포인트가 늘어난다는 단점도 있는데요. 때문에 마이크로서비스 아키텍처 기반의 서비스에서는 모니터링을 하는 것보다 모니터링을 '잘' 하는 것이 중요합니다.

New Relic은 Client(일반적으로 사용자) 경험을 추적할 수 있는 Browser Monitoring부터 Backend 서비스의 상세한 메트릭을 보여주는 APM, 그리고 Database, Cache, Queue 등의 Storage 등의 다양한 기능을 통해 서비스의 End-to-End를 추적할 수 있도록 도와줍니다. 그 외에도 Alerts를 통해서 상태를 즉시 전달받을 수 있고, AIOps 서비스를 통해서 New Relic 자체 AI 모델로 서비스의 상태를 예측하는 기능도 제공하고 있습니다.

예를 들어 숨고에서는 Kubernetes 클러스터 전체에 대한 모니터링 뿐만 아니라, Application Performance Monitoring(이하 APM)을 활용한 각 서비스 단위의 상세 모니터링도 함께 진행하고 있습니다. APM에서는 개별 서비스의 CPU, 메모리(RAM), 스토리지의 사용량이나 트래픽과 쓰루풋(Throughput), 응답 속도(Response time), 트랜잭션과 슬로우 쿼리, 에러 트래킹과 로그 등의 다양한 지표와 활동을 모니터링하고 있습니다.

사용 중인 기능들

숨고 서비스에서 New Relic을 사용하고 있는 모습을 간단하게 표현하면 아래와 같습니다.

그림을 보면 New Relic이 숨고 서비스의 여러 영역을 바라보고 있음을 알 수 있습니다. 이번 포스팅의 내용이 비용 최적화에 대한 것이기 때문에 개별 기능에 대한 자세한 내용보다는 숨고가 사용 중인 New Relic의 기능 중 일부에 대해서만 간단하게 짚고 넘어가도록 하겠습니다.

• Kubernetes & Pixie

  숨고 서비스들은 Kubernetes 클러스터에서 서비스 중이므로 Kubernetes 메트릭과 로그들을 수집하여 New Relic에 전달해야 합니다. 이를 위해 New Relic에서 제공하는 Kubernetes Integration 설치 가이드에 따라 helm을 설치해서 사용하고 있습니다.

• Infrastructure Monitoring

  전체 서비스가 AWS에서 운영되고 있는 숨고 서비스 특성상 AWS의 메트릭들 또한 New Relic을 통해 확인이 가능해야 합니다. APM의 기능 중 하나인 Service Map을 통해 AWS 서비스까지 연결된 맵을 활용할 수 있습니다. 주로 Backend 서비스에 연결된 RDS, ElastiCache, OpenSearch(Elasticsearch) 등 여러 지표를 서비스 지표와 연계하여 볼 수 있습니다.

  그 외에도 Infrastructure Monitoring 중 Third-party services에 대한 지원이 있어 외부 솔루션이나 SaaS와의 매끄러운 연동도 가능합니다. 예를 들어, 여러 Third-party services 중 Nginx의 경우 숨고의 여러 서비스들이 사용하고 있는데, 이에 대한 지표도 New Relic으로 수집해 활용하고 있습니다.

• Application Monitoring

  앞서 말씀드린 것처럼 개별 서비스들의 상세한 모니터링을 위해서는 디테일한 APM 설정이 필요합니다. 이 또한 APM 설치 가이드에 따라서 언어별로 설정할 수 있습니다. 특히 APM Agent의 개별 언어의 특정 버전부터 Log를 자동으로 수집하도록 되어 있어 보다 쉽게 세팅이 가능한 것도 특징입니다.

• Alerts

  설치된 Infrastructure, APM Agent, AWS, Third-party services에서 수집한 메트릭과 로그들을 이용해서 특정 수치가 임계치에 도달하는 경우 New Relic의 Alerts이 Slack으로 알람을 보내줍니다. 이를 통해 빠르게 장애에 대응하여 사용자에게 더 만족스러운 사용 환경을 제공하고 있습니다.

• Dashboard

  New Relic에는 수집된 데이터들을 보다 쉽게 확인할 수 있는 대시보드 기능도 갖추어져 있습니다. New Relic 자체적으로 정의된 쿼리 문법인 New Relic's Query Language(이하 NRQL)를 이용하여 여러 데이터를 Dashboard로 표현하거나 반대로 표현된 Dashboard를 NRQL로 변환할 수 있다는 것이 장점입니다.

  또한 New Relic의 Add Data 기능을 통해서 탬플릿화 된 대시보드를 빠르게 만들 수 있을 뿐만 아니라, 만들어진 대시보드의 NRQL을 수정하여 사용 목적에 맞추어 자유롭게 커스터마이징을 할 수도 있습니다.

New Relic 과금 체계

이렇듯 New Relic이 제공하는 서비스도 많고, 실제로 숨고에서 사용하는 서비스의 종류도 상당하기 때문에 과금 체계가 복잡하다고 생각하실 수도 있습니다. 하지만 New Relic의 과금 체계는 상당히 간단한데요.

New Relic에 수집된(Ingest) 데이터의 양과 사용자(Full User)의 수에 따라 금액이 결정됩니다. 보통 사용자는 큰 변화가 없는 경우가 많기 때문에 수집되는 데이터의 양이 과금액과 직결된다고 볼 수 있습니다.

때문에 New Relic에 수집되는 데이터의 양을 최소화하게 된다면 비용 최적화가 자연스럽게 이루어질 것이라고 생각하였습니다.

비용 최적화 과정

New Relic Agent가 수집하는 데이터의 양을 줄이는 방법은 여러 가지가 있습니다. 그 중 이번에 설명드릴 내용들은 다음과 같습니다. 아래의 작업들 외에도 New Relic 비용 최적화를 위한 방법은 여러가지가 있으니 각 조직에 맞는 다른 방법을 고민해보셔도 좋겠습니다.

• lowDataMode & interval 조정
• namespaceSelector 제외 처리
• Nginx Interval 조정
• 운영 환경 외 APM 데이터 수집 차단

lowDataMode & interval 조정

앞서 소개드렸듯 숨고 서비스는 Kubernetes 기반으로 운영되고 있기 때문에 이미 helm을 사용하여 New Relic에 integration을 진행했습니다. 하지만 비용 최적화 옵션의 핵심인 lowDataMode 및 interval 값을 조정하기 위해서는 기존에 사용중이던 helm의 버전 업그레이드가 필요한 상황이었습니다.

이에 helm의 버전을 기존 버전 2에서 버전 4로 업그레이드한 뒤, github에 공개된 New Relic 소스 코드를 전체 clone하여 values.yaml의 설정값을 바꿈으로써 lowDataMode 전환 및 interval 값을 조정할 수 있었습니다.

New Relic 공식 문서에서 소개하는 것처럼 lowDataMode 옵션을 켜게 되면 기본적으로 데이터 수집 주기를 조정할 수 있는 interval 값이 30초로 고정되고, prometheus, log 데이터 수집 시 특정 필드는 수집되지 않아 비용을 효과적으로 줄일 수 있습니다.

하지만 저희는 기본값으로 설정된 interval의 30초가 너무 길다고 판단하였습니다. 30초로 세팅하게 된다면 비용을 큰 폭으로 줄일 수 있지만 메트릭 수집 시점으로부터 30초라는 비교적 긴시간 동안 만약 장애가 일어난다면 이를 빠르게 감지하기 어렵기 때문입니다.

비용을 줄이는 것도 중요하지만 안정적인 서비스를 위해 New Relic을 도입한만큼, 비용에 대한 트레이드 오프를 감수하고 기존 30초로 되어있던 interval 값을 10초로 설정하여 운영하고 있습니다.

이를 반영한 values.yaml 내용 일부는 다음과 같습니다.

global:
  lowDataMode: true
newrelic-infrastructure:
  enabled: true
  common:
    config:
      interval: 10s

namespaceSelector 제외 처리

Kubernetes에는 자체적으로 다양한 서비스 운영에 필요한 Third-party 서비스들이 기동이 되어 있는데, 보통 별도의 네임스페이스에 기동이 되어 있습니다. 숨고 서비스에서 주로 사용하는 Third-party 서비스가 아닌 경우에는 굳이 데이터를 수집할 필요가 없으므로, 더 이상 데이터를 수집하지 않도록 설정해 데이터의 전체적인 양을 줄일 수 있었습니다.

위의 사항을 적용한 values.yaml 내용 일부는 다음과 같습니다.

newrelic-infrastructure:
  common:
    config:
      namespaceSelector:
        matchExpressions:
        - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

소스 코드에서 볼 수 있듯이 newrelic.com/scrape 키에 false 값이 없는 네임스페이스만 설정하는 내용입니다. 이를 위해서 숨고 서비스가 기동되어 있는 네임스페이스를 제외한 모든 네임스페이스의 어노테이션에 newrelic.com/scrape=false 값을 추가해주었습니다.

적용한 네임스페이스의 내용의 일부는 다음과 같습니다.

$ kubectl get ns newrelic -o yaml
apiVersion: v1
kind: Namespace
metadata:
  labels:
    kubernetes.io/metadata.name: newrelic
    newrelic.com/scrape: "false"

몇몇 분들은 ‘데이터 수집이 필요한 네임스페이스에만 어노테이션을 추가해서 수집되도록 하면 되는 것 같은데?' 라는 생각이 드실 수도 있습니다.

저희가 Include(In)가 아닌 Exclude(NotIn)를 사용한 이유는 새롭게 추가되는 네임스페이스에 대해서는 기본적으로 데이터 수집을 활성화하고, 어노테이션을 추가한 특정 네임스페이스에 대해서만 데이터 수집을 막음으로써 의도치않게 데이터 수집이 되지 않는 혼란을 방지하기 위해서 입니다.

Nginx Interval 설정

앞서 설정한 interval 외에도 New Relic의 Third-party 중 Nginx의 메트릭을 수집에 대한 옵션도 별도의 interval을 설정할 수 있습니다. infrastructure interval과 다르게 Nginx의 interval은 30초로 설정해도 주요 메트릭을 추적하는데 무리가 없다고 판단하여 30초로 설정하였습니다.

Nginx에 interval을 적용한 values.yaml 내용의 일부는 다음과 같습니다.

newrelic-infrastructure:
  integrations:
    my-nginx:
      integrations:
        - name: nri-nginx
          interval: 30s

운영 환경 외 APM 데이터 수집 차단

New Relic에서 제공하는 APM은 별도의 설정이 없다면 운영 환경 외의 다양한 환경에 대해서도 데이터를 수집합니다. 하지만 비용 최적화 측면에서 운영 환경이 아닌 경우에는 데이터를 굳이 수집할 필요가 없다고 판단, 불필요한 APM 데이터를 수집하지 않도록 하였습니다.

이를 위해 New Relic NerdGraph라는 도구를 활용하였는데요. New Relic One 콘솔이 아닌 별도로 마련된 New Relic NerdGraph API explorer 라는 콘솔에서 특정 데이터를 드랍할 수 있는 규칙을 설정함으로써 데이터 수집을 최적화할 수 있었습니다.

드랍 대상 리스트업

먼저, 데이터 드랍의 대상이 되는 환경을 리스트업했습니다. 각각의 마이크로서비스가 갖고 있는 New Relic Agent 설정 파일인 newrelic.ini 파일에 APM 정보가 기록이 되어 있는데, 숨고에서는 테스트 환경을 표현할 수 있는 Postfix를 붙이고 있기 때문에 운영 환경이 아닌 환경을 리스트업 하는데 도움을 받을 수 있었습니다.

삭제 규칙 지정

상세한 삭제 규칙을 만들기 위해서 mutation이라는 섹션을 별도로 선언하여 NRQL을 통해 삭제 대상을 필터링 할 수 있도록 지정했습니다.

mutation {
    nrqlDropRulesCreate(accountId: 0, rules: [
        {
            action: DROP_DATA
            nrql: "SELECT * FROM Metric WHERE appName RLIKE r'.*[Tt]est.*|.*undefined.*'"
            description: "Drops all staging, testing, ETC, ... APM data except Production"
        }
    ])
    {
        successes { id }
        failures {
            submitted { nrql }
            error { reason description }
        }
    }
}

NRQL로 APM 명칭과 일치하는 appName 에 정규식을 지정하여 일괄 필터링을 할 수 있습니다. 위의 예시에서는 Test, test, undefined 문자열이 포함된 APM의 메트릭은 모두 드랍하는 예시입니다. 위 규칙을 실행한 후 New Relic Query builder에서 실제 수집이 되지 않는 사항을 검토할 수 있는데, 위의 쿼리에 TIMESERIES 키워드를 얹어서 최근 메트릭이 수집되지 않는 것을 확인 할 수 있습니다.

효과

위의 작업들을 통해 New Relic이 가진 이점을 유지하면서도 New Relic을 통한 데이터 사용량이 무려 50% 이상 줄어든 것을 확인할 수 있었습니다. 데이터 사용량의 엄청난 감소에 따라 New Relic의 운영 비용도 이와 비례해서 약 50% 이상 줄일 수 있었습니다. 운영 비용에 대해서는 정확한 금액을 말씀드릴 수 없어, 실제 데이터 사용량의 추이로 대체하도록 하겠습니다.

회고

서비스의 복잡도가 늘어나고 유저와 트래픽이 늘어나게 되면 기존의 사람이 직접 로그를 확인하는 작업을 넘어선 고도화된 모니터링은 필수라고 생각합니다. New Relic을 사용한 이후로 꾸준히 서비스의 상태를 체크하면서 서비스의 안정성을 높일 수 있었고, 이를 통해 유저들에게 더 원활한 서비스를 제공할 수 있게 되었습니다.

또한 단순히 서비스를 사용만 하는 것에 그치지 않고, 여러 방법을 사용해 효율성은 유지하면서도 리소스를 획기적으로 아낄 수 있었다는 점에서 이번 작업의 의의가 적지 않다고 생각합니다. 아직은 과거와 현재를 확인하는 모니터링 위주로 New Relic을 사용하고 있지만, 앞으로 R&D를 통해 다양한 장애와 비정상 상태를 예측하여 선제적으로 대응하는 Observability 관점에서의 서비스 운영을 목표로 하고자 합니다.

긴 글 읽어주셔서 감사합니다.

참고 자료

• https://www.oreilly.com/library/view/observability-engineering/9781492076438/ch01.html
• https://cloud.google.com/architecture/devops/devops-measurement-monitoring-and-observability
• https://newrelic.com/platform
• https://docs.newrelic.com/