SSD에서 분산으로 마이그레이션

원본: https://grafana.com/docs/loki/latest/setup/migrate/ssd-to-distributed/ (opens in a new tab)

이 가이드는 Loki의 단순 확장 배포(SSD)에서 분산 마이크로서비스 배포로 마이그레이션하는 지침을 제공합니다. 마이그레이션을 시작하기 전에 고려 사항 섹션을 반드시 읽어보세요.

이 가이드에서는 AWS 배포를 예로 사용합니다. 그러나 기본 데이터 스토리지에 변경이 필요 없으므로 다른 클라우드 제공업체에서도 마이그레이션 프로세스는 동일합니다.

고려 사항

무중단으로 단순 확장 배포에서 분산 배포로 마이그레이션하는 것은 가능하지만 신중한 계획이 필요합니다. 다음 사항을 고려해야 합니다:

Helm 배포: 이 가이드는 Helm을 사용하여 Loki를 배포했다고 가정합니다. 다른 마이그레이션 방법도 가능하지만 이 가이드에서는 다루지 않습니다.
쿠버네티스 리소스: 이 마이그레이션 방법은 SSD 파드를 종료하기 전에 분산 Loki 파드를 시작해야 합니다. 즉, 쿠버네티스 클러스터에 SSD와 분산 Loki 파드를 동시에 실행할 수 있는 충분한 리소스가 있어야 합니다.
데이터: 기본 데이터 스토리지에는 변경이 필요 없습니다. 데이터 손실이나 손상 가능성은 낮지만, 마이그레이션 프로세스를 시작하기 전에 항상 데이터를 백업하는 것이 좋습니다. 클라우드 제공업체를 사용하는 경우 스냅샷/백업을 만들 수 있습니다.
구성: 이 가이드에서는 모든 구성 매개변수를 다루지 않습니다. 변경해야 하는 매개변수만 다룹니다. 다른 매개변수는 그대로 유지할 수 있습니다. 하지만 pattern_ingesters=true인 경우 SSD 인제스터를 종료하기 전에 patternIngesters를 시작해야 합니다. 이는 주로 Grafana Logs 드릴다운 기능에 필요합니다.
영역 인식 인제스터: 이 가이드는 현재 영역 인식 인제스터를 고려하지 않습니다. 현재 권장 사항은 영역 인식 인제스터를 비활성화하거나 Mimir 마이그레이션 가이드 (opens in a new tab)를 참조하는 것입니다. Mimir와 Loki 간의 모든 매개변수가 동일하지는 않다는 점에 유의하세요.

전제 조건

마이그레이션 프로세스를 시작하기 전에 다음 전제 조건을 충족하는지 확인하세요:

kubectl을 통한 쿠버네티스 클러스터 액세스.
Helm 설치.

예제 SSD 배포

이 예제에서는 다음 SSD 배포를 참조로 사용합니다:

이 예제는 변경해야 하는 매개변수에 대한 참조일 뿐입니다. limits_config, gateway, compactor 등과 같은 다른 매개변수가 구성에 있을 것입니다. 이러한 매개변수는 그대로 유지할 수 있습니다.

---
loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: eu-central-1
      bucketnames: aws-chunks-bucket
      s3forcepathstyle: false
  ingester:
    chunk_encoding: snappy
  ruler:
    enable_api: true
    storage:
      type: s3
      s3:
        region: eu-central-1
        bucketnames: aws-ruler-bucket
        s3forcepathstyle: false
    alertmanager_url: http://prom:9093
  querier:
    max_concurrent: 4
storage:
  type: s3
  bucketNames:
    chunks: "aws-chunks-bucket"
    ruler: "aws-ruler-bucket"
  s3:
    region: eu-central-1
deploymentMode: SimpleScalable
# SSD
backend:
  replicas: 2
read:
  replicas: 3
write:
  replicas: 3
# Distributed Loki
ingester:
  replicas: 0
  zoneAwareReplication:
    enabled: false
querier:
  replicas: 0
  maxUnavailable: 0
queryFrontend:
  replicas: 0
  maxUnavailable: 0
queryScheduler:
  replicas: 0
distributor:
  replicas: 0
  maxUnavailable: 0
compactor:
  replicas: 0
indexGateway:
  replicas: 0
  maxUnavailable: 0
ruler:
  replicas: 0
  maxUnavailable: 0
# Single binary Loki
singleBinary:
  replicas: 0
minio:
  enabled: false

1단계: Loki 분산 구성 요소 배포

이 단계에서는 SSD 구성 요소와 함께 분산 Loki 구성 요소를 배포합니다. 또한 deploymentMode를 SimpleScalable<->Distributed로 변경합니다. SimpleScalable<->Distributed 마이그레이션 모드를 사용하면 Simple Scalable 아키텍처와 완전 분산 아키텍처 간에 무중단 전환이 가능합니다. 마이그레이션 중에는 두 배포 유형이 동일한 객체 스토리지 백엔드를 공유하면서 동시에 실행됩니다.

다음 표는 어떤 구성 요소가 SSD 구성 요소의 책임을 맡는지 간략하게 설명합니다:

단순 확장 가능 구성 요소	분산 구성 요소
write (Deployment)	Distributor + Ingester
read (StatefulSet)	Query Frontend + Querier
backend (StatefulSet)	Compactor + Ruler + Index Gateway

마이그레이션 중 Loki가 요청 라우팅을 처리하는 방법:

게이트웨이(nginx)는 엔드포인트 유형에 따라 요청 라우팅을 처리합니다:

쓰기 경로 (loki/api/v1/push):
- 초기에는 Simple Scalable 쓰기 구성 요소로 라우팅됩니다.
- 점차적으로 Distributor로 전환됩니다.
- 두 쓰기 경로는 동일한 객체 스토리지를 공유하여 데이터 일관성을 보장합니다.
읽기 경로 (/loki/api/v1/query):
- Simple Scalable 읽기 또는 분산 Query Frontend로 라우팅됩니다.
- 두 아키텍처 모두 동일한 스토리지에서 읽으므로 쿼리 결과는 일관됩니다.
관리/백그라운드 작업:
- 압축, 보존 및 규칙 평가는 백엔드 또는 각 분산 구성 요소에서 처리됩니다.
- 작업은 객체 스토리지 잠금을 통해 조정됩니다.

마이그레이션 프로세스를 시작하려면:

기존 values.yaml 파일의 복사본을 만들고 이름을 values-migration.yaml로 지정합니다.
```
cp values.yaml values-migration.yaml
```

다음으로 아래 주석에 따라 deploymentMode, ingester 및 구성 요소를 수정합니다.

---
loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: eu-central-1
      bucketnames: aws-chunks-bucket
      s3forcepathstyle: false
  ingester:
    chunk_encoding: snappy
    # ingester에 이것을 추가하세요; 종료하기 전에 인제스터가 플러시하도록 강제합니다
    wal:
      flush_on_shutdown: true
  ruler:
    enable_api: true
    storage:
      type: s3
      s3:
        region: eu-central-1
        bucketnames: aws-ruler-bucket
        s3forcepathstyle: false
    alertmanager_url: http://prom:9093
  querier:
    max_concurrent: 4
storage:
  type: s3
  bucketNames:
    chunks: "aws-chunks-bucket"
    ruler: "aws-ruler-bucket"
  s3:
    region: eu-central-1
# 중요: 이것을 SimpleScalable<->Distributed로 변경해야 합니다
deploymentMode: SimpleScalable<->Distributed
# SSD
backend:
  replicas: 2
read:
  replicas: 3
write:
  replicas: 3
# Distributed Loki
# 분산 구성 요소 시작
ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false
querier:
  replicas: 3
  maxUnavailable: 0
queryFrontend:
  replicas: 2
  maxUnavailable: 0
queryScheduler:
  replicas: 2
distributor:
  replicas: 2
  maxUnavailable: 0
compactor:
  replicas: 1
indexGateway:
  replicas: 2
  maxUnavailable: 0
ruler:
  replicas: 1
  maxUnavailable: 0
# Single binary Loki
singleBinary:
  replicas: 0
minio:
  enabled: false

변경 사항 분석:

ingester.wal.flush_on_shutdown: true: 종료하기 전에 인제스터가 플러시하도록 강제합니다. 데이터 손실을 방지하는 데 중요합니다.
deploymentMode: SimpleScalable<->Distributed: SSD와 분산 구성 요소가 동시에 실행되도록 합니다.
원하는 복제본으로 모든 분산 구성 요소를 시작합니다.

다음 명령을 사용하여 분산 구성 요소를 배포합니다:
```
helm upgrade --values values-migration.yaml loki grafana/loki -n loki
```
⚠️
다음 단계로 진행하기 전에 모든 구성 요소가 완전히 시작되도록 하는 것이 중요합니다. 다음 명령을 사용하여 구성 요소의 상태를 확인할 수 있습니다:
```
kubectl get pods -n loki
```
다음 단계로 진행하기 전에 모든 구성 요소가 Running 상태에 도달하도록 하세요.

2단계: 분산 구성 요소로 전환

마이그레이션의 마지막 단계는 모든 트래픽을 분산 구성 요소로 전환하는 것입니다. 이는 SSD 구성 요소를 축소하고 deploymentMode를 Distributed로 교체하여 수행됩니다. 이렇게 하려면:

values-migration.yaml의 복사본을 만들고 이름을 values-distributed.yaml로 지정합니다.
```
cp values-migration.yaml values-distributed.yaml
```

다음으로 아래 주석에 따라 deploymentMode와 구성 요소를 수정합니다.

---
loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: eu-central-1
      bucketnames: aws-chunks-bucket
      s3forcepathstyle: false
  ingester:
    chunk_encoding: snappy
    wal:
      flush_on_shutdown: true
  ruler:
    enable_api: true
    storage:
      type: s3
      s3:
        region: eu-central-1
        bucketnames: aws-ruler-bucket
        s3forcepathstyle: false
    alertmanager_url: http://prom:9093
  querier:
    max_concurrent: 4
storage:
  type: s3
  bucketNames:
    chunks: "aws-chunks-bucket"
    ruler: "aws-ruler-bucket"
  s3:
    region: eu-central-1
# 중요: 이것을 Distributed로 변경해야 합니다
deploymentMode: Distributed
# SSD
# SSD 구성 요소 축소
backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0
# Distributed Loki
ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false
querier:
  replicas: 3
  maxUnavailable: 0
queryFrontend:
  replicas: 2
  maxUnavailable: 0
queryScheduler:
  replicas: 2
distributor:
  replicas: 2
  maxUnavailable: 0
compactor:
  replicas: 1
indexGateway:
  replicas: 2
  maxUnavailable: 0
ruler:
  replicas: 1
  maxUnavailable: 0
# Single binary Loki
singleBinary:
  replicas: 0
minio:
  enabled: false

변경 사항 분석:

deploymentMode: Distributed: 분산 구성 요소가 격리되어 실행되도록 합니다.
모든 SSD 구성 요소를 0으로 축소합니다.

다음 명령을 사용하여 최종 구성을 배포합니다:

helm upgrade --values values-distributed.yaml loki grafana/loki -n loki

배포가 완료되면 다음 명령을 사용하여 모든 구성 요소가 실행 중인지 확인할 수 있습니다:
```
kubectl get pods -n loki
```

모든 분산 구성 요소가 실행 중이고 SSD 구성 요소가 제거된 것을 볼 수 있습니다.

다음 단계는 무엇인가요?

분산 모드의 Loki는 본질적으로 SSD 모드보다 복잡합니다. 모든 것이 원활하게 실행되는지 확인하기 위해 Loki 배포를 메타 모니터링하는 것이 좋습니다. 메타 모니터링 가이드를 따라 이를 수행할 수 있습니다.

Alloy로 마이그레이션 TSDB로 마이그레이션