Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

Cortex: Prometheus-as-a-Service

지금 참여하고 있는 인프라 스터디에서 책도 보고 있지만 동시에 CNCF에서 지원하는 프로젝트도 하나씩 살펴보고 있다. 돌아가면서 공부해서 발표하는 방식이라 이번에 Cortex라는 프로젝트를 살펴봤다.

Cortex란?

Cortex는 현재 CNCF의 Sandbox 프로젝트로 작년(2018년) 9월에 Sandbox 프로젝트가 되었으니 얼마 되지 않았다. CNCF는 Sandbox - Incubating - Graduated 순으로 진행되므로 Sandbox는 초기 단계라고 할 수 있다. 그래서인지 공식 문서와 자료가 많지 않아서 공부하는데, 시간이 걸렸다. Cortex를 자세히 보진 못했고 간단히 어떤 구조로 되어있어 어떤 역할을 하는 프로젝트 인지만 파악해 봤다.

스터디 전에는 Cortex를 전혀 모르고 있었는데 Cortex를 선택한 것은 (내가 관심 있는 굵직굵직한 프로젝트는 이미 다른 분들이 선점해서이기도 하지만...) 최근에 Prometheus 식으로 로그를 수집하는 Loki를 살펴보고 싶었는데 Loki가 Cortex에서 파생된 프로젝트라고 나와 있었기 때문이다. Loki는 아직 CNCF 프로젝트가 아니기도 했고 그래서 Cortex는 무슨 프로젝트지? 하는 궁금함에 보기 시작했다.

Cortex 로고

Cortex 저장소에 가면 Prometheus-as-a-Service라고 설명하고 있다. 즉, Prometheus를 서비스로 제공하기 위한 프로젝트라는 의미이다.

Cortex provides horizontally scalable, multi-tenant, long term storage for Prometheus metrics when used as a remote write destination, and a horizontally scalable, Prometheus-compatible query API.

위는 좀 더 자세한 설명인데 그 의미를 풀어보면 Prometheus가 보통 한 서버에서 메트릭을 저장하게 되어 있고 샤딩 기반의 확장만 지원하는데, Cortex를 쓰면 수평적 확장을 지원하고 단기간만 메트릭을 저장하는 게 아니라 롱텀 스토리지로 데이터를 오랫동안 보관하고 멀티 테넌트, 즉 여러 서비스나 사용자가 메트릭을 따로 저장하고 관리할 수 있도록 한다는 뜻이다. 저장뿐 아니라 Prometheus 호환 쿼리 API를 지원하므로 수평적 확장을 통해서 메트릭을 읽어오는 것도 가능하다.

What is Cortex?를 보면 자세한 히스토리가 나오는데 weaveworks에서 Kubernetes로 Prometheus를 운영하고 있었는데 Persistent Volume은 사용하지 않아서 재배포할 때마다 데이터가 사라지는 상황이었다. 메트릭이 보통 최근 데이터만 있으면 되므로 처음에는 큰 문제가 안 되다가 이 문제를 해결하려고 Persistent Volume를 고려하다가 고객마다 Prometheus 인스턴스를 운영하고 싶지 않아서 Prometheus-as-a-service로 가기로 하고 수평적 확장을 지원하도록 Cortex를 만들게 되었다. Cortex의 설계는 Amazon Dynamo 논문에 영향을 크게 받았다고 한다.

Prometheus의 remote_write를 이용해서 Prometheus에서 Cortex로 메트릭을 보내서 저장하는 방식이다. 이 remote_write는 Cortex를 만든 Tom Wilkie와 Julius Volz가 Prometheus에 추가했다.

Cortex 아키텍처

아키텍처 문서를 보면 대략적인 구조를 이해할 수 있다.

Cortex 아키텍처 구성도

위 구조에서 Prometheus와 Your Jobs라고 된 부분은 Cortex의 구조에는 안 들어간다. 메트릭을 수집한 Promethues에서 remote_write로 Cortex에 메트릭을 보내는 것을 나타낸 것이다. Frontend라고 된 부분은 회색으로 음역처리가 되어 있는데 Cortex를 좀 띄워 봤을 때는 Cortex 자체의 구성 요소라기보다는 앞에서 nginx같은 웹서버로 라우팅하므로 진입점이라는 의미로 그린 것 같다.

각 구성 요소를 살펴보자. 위 그림과 각 구성 요소의 역할을 같이 보면 이해하기가 좀 쉽다.

  • Prometheus

    • 메트릭을 수집해서 Cortex에 넣는 역할을 하는데 이때 remote write API를 사용한다.
    • remote write API는 Snappy로 압축된 Protocol Buffer 메시지를 HTTP PUT 요청을 배치로 사용한다.
    • 쓰기 요청은 Distributor가 받고 PromQL 쿼리를 이용한 읽기 요청은 Query Frontend가 받는다.
  • Distributor

    • Prometheus가 보낸 메트릭을 처리하고 gRPC로 ingester와 통신한다.
    • 상태가 없으므로 필요에 따라 확장할 수 있다.
    • consistent hash ring를 이용해서 어떤 ingester가 메트릭 데이터를 받을지를 결정하고 이 consistent hash ring은 Consul에 저장된다.
    • hash ring 데이터 구조를 Protobuf 메시지로 인코딩된다.
  • Ingester

    • DynamoDB, BigTable, S3, Cassandra 같은 롱텀 스토리지 백엔드에 데이터를 저장하는 역할을 한다.
    • Ingester는 아무것도 공유하지 않고 데이터를 처리한다.(shared-noting process)
    • 약간의 상태를 가지는데 최신 12시간의 메트릭을 유지하고 있으므로 재시작할 때는 데이터를 잃지 않게 조심해야 한다.
  • Ruler

    • alertmanager가 만든 알림을 다룬다.(이번에 살펴볼 때는 자세히 보지 않았다.)
  • Query Frontend

    • Query Frontend는 PromQL로 remote_read를 사용할 때만 띄우면 되고 Cortex 구성에서 반드시 띄워야 하는 것은 아니다.
    • Queuing을 통해 실제 쿼리를 실행하는 Querier가 대형 쿼리를 실행하다가 Out Of Memory를 일으킬 때를 위해 재시도를 보장하고 쿼리를 FIFO로 분산해서 한 Querier가 대형 쿼리를 다수 받지 않도록 하며 서비스 사용자(tenant)가 쿼리를 공정하게 스케줄링해서 DoS에서 사용자를 보호한다.
    • Splitting을 통해 여러 날짜에 걸치 쿼리를 하루짜리 다수의 쿼리로 나누어서 Querier로 보내고 결과를 받아서 다시 합친다.
    • 쿼리 결과를 캐싱하고 이를 재사용한다.
  • Querier

    • 롱텀 스토리지에 저장된 데이터에서 실제 PromQL 평가를 처리한다.
  • Chunk Store

    • Cortex의 롱텀 데이터 스토어다.

데모 실행

프로젝트가 아직 많이 성숙하지 않아서인지 Cortex가 호스팅을 하기 위한 프로젝트라서 인지 프로덕션 설치 문서는 발견하지 못했다. 호스팅이 아니더라도 큰 조직에서는 Cortex가 필요한 때도 있을 것 같은데 저 복잡한 구성을 프로덕션에서는 어떻게 설정해야 하는지는 잘 모르겠다.(자기네 호스팅 서비스 쓰라고?) 대신 개발용으로 Kuberntes로 쉽게 Cortex 환경을 구성할 수 있도록 제공하고 있어서 간단히 실행해 볼 수 있었다.

Cortex 저장소를 클론 받으면 실행해 볼 수 있도록 k8s 디렉터리가 있다. 이 Kubernetes 설정에서 사용하는 이미지는 Quay의 이미지를 사용하는데 지정된 latest 이미지는 없으므로 로컬에서 생성해야 한다. 저장소를 클론 받아서 make 명령어를 실행하면 로컬에 이미지가 만들어진다.

$ kubectl create -f ./k8s

deployment.extensions "alertmanager" created
service "alertmanager" created
deployment.extensions "configs-db" created
service "configs-db" created
deployment.extensions "configs" created
service "configs" created
deployment.extensions "consul" created
service "consul" created
deployment.extensions "distributor" created
service "distributor" created
deployment.extensions "dynamodb" created
service "dynamodb" created
deployment.extensions "ingester" created
service "ingester" created
deployment.extensions "memcached" created
service "memcached" created
configmap "nginx" created
deployment.extensions "nginx" created
service "nginx" created
deployment.extensions "querier" created
service "querier" created
deployment.extensions "query-frontend" created
service "query-frontend" created
configmap "retrieval-config" created
deployment.extensions "retrieval" created
service "retrieval" created
deployment.extensions "ruler" created
service "ruler" created
deployment.extensions "s3" created
service "s3" created
deployment.extensions "table-manager" created
service "table-manager" created

이는 Cortex 개발용 환경으로 필요한 모든 구성이 실행된다.(앞에서 말했듯이 프로덕션용 설정 문서는 찾지 못했다.)

$ kubectl get all
NAME                                  READY     STATUS    RESTARTS   AGE
pod/alertmanager-54d9cfd844-z7jnv     1/1       Running   0          7m
pod/configs-84ff5785c-9kldc           1/1       Running   0          7m
pod/configs-db-5f9b64f5cc-wwx48       1/1       Running   0          7m
pod/consul-5c4f79cf47-flmsb           1/1       Running   0          7m
pod/distributor-6b58d9986-hv5nj       1/1       Running   0          7m
pod/dynamodb-68fc4457c6-9c7pq         1/1       Running   0          7m
pod/ingester-7b7b9f8f84-2dftc         1/1       Running   0          7m
pod/memcached-f99cdf957-cdgbq         1/1       Running   0          7m
pod/nginx-7856cc488b-vnk4l            1/1       Running   1          7m
pod/querier-58646d4dc9-vsrg8          1/1       Running   0          7m
pod/query-frontend-59dbb8dd95-x29sg   1/1       Running   0          7m
pod/retrieval-69bd8bdd88-xwc9d        1/1       Running   0          7m
pod/ruler-6fbbb9998b-vdjhg            1/1       Running   0          7m
pod/s3-57dc56ffb4-tl2hp               1/1       Running   0          7m
pod/table-manager-5b474f6685-ll5l8    1/1       Running   0          7m

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)              AGE
service/alertmanager     ClusterIP   10.99.21.8       <none>        80/TCP               7m
service/configs          ClusterIP   10.109.200.199   <none>        80/TCP               7m
service/configs-db       ClusterIP   10.108.43.242    <none>        5432/TCP             7m
service/consul           ClusterIP   10.104.52.73     <none>        8500/TCP             7m
service/distributor      ClusterIP   10.102.76.244    <none>        80/TCP               7m
service/dynamodb         ClusterIP   10.101.128.11    <none>        8000/TCP             7m
service/ingester         ClusterIP   10.109.232.228   <none>        80/TCP               7m
service/kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP              6d
service/memcached        ClusterIP   None             <none>        11211/TCP,9150/TCP   7m
service/nginx            NodePort    10.100.221.142   <none>        80:30080/TCP         7m
service/querier          ClusterIP   10.97.68.116     <none>        80/TCP               7m
service/query-frontend   ClusterIP   None             <none>        9095/TCP,80/TCP      7m
service/retrieval        ClusterIP   10.102.125.39    <none>        80/TCP               7m
service/ruler            ClusterIP   10.111.194.194   <none>        80/TCP               7m
service/s3               ClusterIP   10.102.240.155   <none>        4569/TCP             7m
service/table-manager    ClusterIP   10.107.78.253    <none>        80/TCP               7m

NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/alertmanager     1         1         1            1           7m
deployment.apps/configs          1         1         1            1           7m
deployment.apps/configs-db       1         1         1            1           7m
deployment.apps/consul           1         1         1            1           7m
deployment.apps/distributor      1         1         1            1           7m
deployment.apps/dynamodb         1         1         1            1           7m
deployment.apps/ingester         1         1         1            0           7m
deployment.apps/memcached        1         1         1            1           7m
deployment.apps/nginx            1         1         1            1           7m
deployment.apps/querier          1         1         1            1           7m
deployment.apps/query-frontend   1         1         1            1           7m
deployment.apps/retrieval        1         1         1            1           7m
deployment.apps/ruler            1         1         1            1           7m
deployment.apps/s3               1         1         1            1           7m
deployment.apps/table-manager    1         1         1            1           7m

NAME                                        DESIRED   CURRENT   READY     AGE
replicaset.apps/alertmanager-54d9cfd844     1         1         1         7m
replicaset.apps/configs-84ff5785c           1         1         1         7m
replicaset.apps/configs-db-5f9b64f5cc       1         1         1         7m
replicaset.apps/consul-5c4f79cf47           1         1         1         7m
replicaset.apps/distributor-6b58d9986       1         1         1         7m
replicaset.apps/dynamodb-68fc4457c6         1         1         1         7m
replicaset.apps/ingester-7b7b9f8f84         1         1         1         7m
replicaset.apps/memcached-f99cdf957         1         1         1         7m
replicaset.apps/nginx-7856cc488b            1         1         1         7m
replicaset.apps/querier-58646d4dc9          1         1         1         7m
replicaset.apps/query-frontend-59dbb8dd95   1         1         1         7m
replicaset.apps/retrieval-69bd8bdd88        1         1         1         7m
replicaset.apps/ruler-6fbbb9998b            1         1         1         7m
replicaset.apps/s3-57dc56ffb4               1         1         1         7m
replicaset.apps/table-manager-5b474f6685    1         1         1         7m

개발용이라 상당히 많은 서비스가 실행된다. 앞에 아키텍처 구성과 같이 보면 어떤 서비스가 실행되었는지 알 수 있고 dynamodb나 s3 같은 건 로컬에서 테스트해볼 수 있는 이미지들이다. http://localhost:30080/api/prom/api/v1/query?query=up에 접속해 보면 Query Frontend에 접속해서 PromQL 쿼리를 실행해 볼 수 있다. 여기서는 Cortex에서 실행된 서버(up)를 조회한 것이다.

Cortex에서 up 메트릭을 조회한 결과

여기에 Grafana를 연동해서 확인해 볼 수 있는데 Cortex에서 Grafana의 대시보드 설정을 생성할 수 있도록 이미 제공하고 있다. 로컬에 데이터 템플릿 언어인 Jsonnet을 설치하고 Grafonnet을 클론 받는다. 앞에서 클론 받은 Cortex 디렉터리에서 docs/dashboards에 들어가서 아래 명령어를 실행한다.

$ jsonnet -J ../../grafonnet-lib/ -o cortex-read.json cortex-read.jsonnet
$ jsonnet -J ../../grafonnet-lib/ -o cortex-write.json cortex-write.jsonnet

여기서 ../../grafonnet-lib/는 앞에서 Grafonnet을 클론 받은 디렉터리의 위치이다. 이 두 명령어를 실행하면 cortex-read.json, cortex-write.json 파일이 생성된다. 이 파일은 Grafana 대시보드에서 불러올 수 있는 설정 파일이라고 생각하는데 Jsonnet을 처음 써봐서 자세한 파일의 내용은 모르는 상태이다.

$ docker run -d -p 3000:3000 grafana/grafana

위 명령어로 Grafana를 실행하고 http://localhost:3000에 접속하면 Grafana에 접속할 수 있다.(초기 로그인 정보는 admin/admin이다.) 접속한 후 Import로 앞에서 생성한 cortex-read.json, cortex-write.json를 불러오면 다음과 같이 바로 대시보드가 생성되고 Cortex의 매트릭을 볼 수 있다. 이 JSON 파일의 구조까지는 몰라서 바로 실행했는데 이전 시간의 매트릭정보까지 나오는 이유는 잘 모르겠다. 여기서는 Cortext의 동작을 보는 것이므로 그냥 넘어갔다.

Grafana에서 Cortex의 조회 관련 서비스 메트릭을 조회한 대시보드

k8s/nginx-config.yaml 파일의 내용을 보면 Cortex가 정보를 받는 라우팅 경로를 볼 수 있다.

location = /api/prom/push {
  proxy_pass      http://distributor.default.svc.cluster.local$request_uri;
}

location ~ /api/prom/.* {
  proxy_pass      http://query-frontend.default.svc.cluster.local$request_uri;
}

/api/prom/push는 메트릭을 저장하는 Distributor로 보내는 경로이고 그 외 /api/prom/.*로 들어오는 요청은 Query Frontend로 전달된다.

이제 Cortex를 실행했는데 Cortex 자체가 Prometheus의 매트릭을 저장하는 역할이므로 Prometheus가 있어야 동작 여부를 제대로 확인할 수 있다. 다음과 같이 prometheus.yml 설정 파일을 생성한다. 이는 기본적인 Promethus 설정 파일이다.

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090']

# Settings related to the remote write feature.
remote_write:
  - url: "http://localhost:30080/api/prom/push"

맨 마지막을 보면 remote_write에서 Cortext에 원격 쓰기를 하도록 설정한 것을 볼 수 있다.


$ ./prometheus --config.file=prometheus.yml

Prometheus를 로컬에 설치하고 위의 설정 파일로 실행하면 http://localhost:9090에 접속해서 확인해 볼 수 있다. remote_write를 설정했으므로 다시 Cortex의 Query Frontend인 http://localhost:30080/api/prom/api/v1/query?query=up에 접속해서 확인해 보면 방금 실행한 http://localhost:9090가 추가된 것을 볼 수 있다. 이는 앞에서 실행했을 때는 없던 메트릭 정보이다.

Cortex에 up 메트릭 조회에 Prometheus 인스턴스 정보가 추가됨

동작을 다시 설명하면 Prometheus가 자신이 수집한 메트릭 정보를 remote_write로 Cortex에 저장하고 이를 조회한 것이다.

앞에서 작성한 prometheus.yml 파일에 아래의 remote_read 설정을 추가해 보자.

# Settings related to the remote read feature.
remote_read:
  - url: "http://localhost:30080/api/prom/read"
    read_recent: true

이 설정으로 Prometheus를 다시 실행하고 http://localhost:9090에 접속해서 up 인스턴스를 조회하면 다음과 같이 Prometheus뿐만 아니라 Cortex에 저장되어 있던 메트릭 정보도 같이 조회되는 것을 확인할 수 있다.

Prometheus에서 Cortex의 메트릭을 같이 조회한 결과

앞에서 설명한 데로 remote_write로 메트릭을 Cortex에 장기로 저장해서 사용할 수도 있는데 Prometheus에서 메트릭 정보를 너무 많이 저장해서 보관할 수는 없으므로 Cortex를 remote_read로 설정하면 Prometheus에서 조회할 때도 Cortex의 정보를 같이 조회해서 보여준다.

이렇게 설정해서 사용한다면 Prometheus에는 필요한 짧은 기간의 메트릭 정보만 보관하면서 사용하다가 긴 기간의 데이터를 조회할 때는 Cortex에서 불러오도록 해서 사용할 수 있다.

2019/02/21 04:05 2019/02/21 04:05

[Book] 클라우드 네이티브 인프라스트럭처:진정한 클라우드 네이티브 컴퓨팅 시대를 위한 아키텍처 패턴과 설계

이 책은 최근에 참여하고 있는 인프라 스터디에서 교재로 사용하면서 읽어보았다. 클라우드와 컨테이너가 대세가 되면서 인프라 관리에 대한 양상도 최근 몇 년간 많이 달라졌는데 그동안 소프트웨어 개발에 쌓인 경험이 인프라 쪽에 많이 적용되고 있다고 생각하는 편이다. 그래서인지 이런 류의 책은 책의 대상 독자가 이전에 인프라를 관리하는 사람과 개발자 두 가지 부류로 나누어져 있는 것 같다. 코드로 인프라 관리하기를 볼 때도 비슷한 느낌을 받았는데 인프라스트럭처에서 소프트웨어 개발 방법을 적용하는 부분은 너무 당연한 내용처럼 느껴지는데 이 책도 그런 부분은 비슷하다고 느껴진다.

전체적인 느낌을 얘기하자면 코드로 인프라 관리하기보다 훨씬 못하다. 사실 전체적으로 무슨 얘기를 하고 싶은 건지 잘 모르겠는데 책의 제목이나 내용을 보았을 때 특정 기술을 다룬다기보다는 클라우드 기반으로 바뀐 인프라스트럭처의 개념 혹은 앞으로 발전해야 하는 개념을 설명하고 싶어하지만 독자들이 특정 도구가 클라우드 네이티브라고 생각하지 않도록 특정 도구나 기술은 최대한 언급하지 않고 추상화된 개념만 설명하고 싶었던 것 같다.

하지만 너무 추상적인 개념만 얘기하다 보니 너무 뻔한 얘기처럼 들리고 핵심이 무엇인지 이해하기가 어렵고 내용이 빙빙 도는 느낌이다. 차라리 구체적인 예시와 함께 설명하는 게 이해가 더 좋지 않았겠나 생각하고 다 읽어보아도 "그래서 클라우드 네이티브 인프라스트럭처가 뭔데?"라는 궁금증만 남았다. 구체적인 예시를 제시하지 않을 거면 Twelve-Factor app처럼 개념이라도 구체적으로 얘기해 주면 좋은데 뻔한 설명이 많아서 나한테는 많이 도움은 되지 않았다.

크게 보면 클라우드 네이티브 인프라스트럭처가 무엇인지를 설명하는데 이는 Infrastructure as Code의 개념보다 하나 더 나아간 Infrastructure as Software의 개념으로 설명하고 있다. 내가 이해한 Infrastructure as Software는 Terraform으로 인프라를 관리하면서 서버와의 상태를 계속 맞춰주고 관리하는 소프트웨어가 있거나 Ansible Tower, Kubernetes와 비슷하게 느껴졌다. 특히 Kubernetes가 인프라 자체를 다 관리하진 않지만, 책을 읽다 보면 Kubernetes가 가장 Infrastructure as Software 개념과 맞아 보인다.

클라우드 네이티브 인프라스트럭처는 클라우드 네이티브 애플리케이션을 효과적으로 실행하기 위해 반드시 필요하다.

그리고 클라우드 네이티브 인프라스트럭처를 구성한다고 끝나는 것은 아니고 거기서 동작하는 애플리케이션도 클라우드 네이티브 애플리케이션이어야 한다고 하는데 클라우드 네이티브 애플리케이션의 설명은 더더욱 무슨 말인지 잘 모르겠다. 다른 애플리케이션과 클라우드 네이티브 애플리케이션이 정확히 어떻게 다른지 잘 이해를 못 했다.

클라우드 네이티브 애플리케이션은 플랫폼에서 실행되도록 설계되었으며, 이를 기반으로 회복성, 애자일성, 운영성, 관측 가능성을 갖추도록 설계되었다. 회복성(resiliency)은 장애를 막아내려 애쓰기보다 포용하며, 플랫폼에서 수행되는 동적 특성을 활용한다. 애자일성(agility)은 신속한 배포와 빠른 반복을 가능하게 한다. 운영성(operability)은 외부 프로세스와 모니터링 시스템에 의존하는 대신 애플리케이션 내에서 수명주기를 제어한다. 관측 가능성(observability)은 애플리케이션 상태에 대한 정보 조회 기능을 제공한다.

개인적으로 "클라우드 네이티브"라는 용어를 좋아해서 기대하고 읽었는데 약간은 실망했다. 물론 클라우드에서 인프라스트럭처와 애플리케이션을 관리하려면 어떻게 접근해야 하는지 전체적인 접근을 다루고 있어서 가볍게 읽는 정도로는 괜찮을 수도 있겠다.

2019/02/17 23:53 2019/02/17 23:53