고가용성을 위한 권장사항

이 문서에서는 Compute Engine에서 Red Hat OpenShift Container Platform 워크로드로 고가용성(HA)을 달성하기 위한 권장사항을 설명합니다. 이 문서에서는 장애 발생 시 워크로드의 고가용성을 유지하는 데 도움이 되는 애플리케이션 수준 전략에 중점을 둡니다. 이러한 전략은 단일 장애점을 제거하고 자동 장애 조치 및 복구 메커니즘을 구현하는 데 도움이 됩니다.

이 문서는 플랫폼 및 애플리케이션 설계자를 대상으로 하며 OpenShift 배포에 대한 경험이 있다고 가정합니다. OpenShift 배포 방법에 대한 자세한 내용은 Red Hat 문서를 참고하세요.

이 문서는 장애 발생 시 워크로드의 고가용성을 유지하고 신속하게 복구할 수 있도록 하는 애플리케이션 수준 전략에 중점을 두는 시리즈의 일부입니다. 이 시리즈의 문서는 다음과 같습니다.

여러 영역에 배포 분산

한 Google Cloud 리전 내 여러 영역에 OpenShift를 배포하는 것이 좋습니다. 이 접근 방식은 한 영역에서 서비스 중단이 발생해도 클러스터의 컨트롤 플레인 노드가 배포된 다른 영역에서 계속 작동하도록 보장하는 데 도움이 됩니다. 여러 영역에 OpenShift를 배포하려면 Google Cloud install-config.yaml파일에서 동일한 리전의 영역 목록을 지정합니다.

노드가 배포되는 위치를 세분화하여 제어하려면 VM을 동일한 영역의 여러 장애 도메인에 분산시키는 VM 배치 정책을 정의하는 것이 좋습니다. 클러스터 노드에 분산 배치 정책을 적용하면 위치별 중단으로 인해 동시에 영향을 받는 노드 수를 줄이는 데 도움이 됩니다. 기존 클러스터에 대한 분산 정책을 만드는 방법에 관한 자세한 내용은 분산 배치 정책을 만들어 VM에 적용을 참고하세요.

마찬가지로 여러 포드가 동일한 노드에서 예약되는 것을 방지하려면 포드 안티어피니티 규칙을 사용하는 것이 좋습니다. 이러한 규칙은 여러 영역에 애플리케이션 복제본을 분산합니다. 다음 예는 포드 안티어피니티 규칙을 구현하는 방법을 보여줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

웹 프런트엔드 또는 REST API와 같은 스테이트리스 서비스의 경우 각 서비스 또는 경로에 대해 여러 포드 복제본을 실행하는 것 이 좋습니다. 이 접근 방식을 사용하면 트래픽이 사용 가능한 영역의 포드로 자동 라우팅됩니다.

리소스 오버커밋을 방지하기 위해 선제적으로 부하 관리

리소스 오버커밋을 방지하려면 애플리케이션의 부하를 선제적으로 관리하는 것이 좋습니다. 오버커밋하면 부하가 걸릴 때 서비스 성능 저하로 이어질 수 있습니다. 리소스 요청 한도를 설정하여 오버커밋을 방지할 수 있습니다. 자세한 내용은 포드의 리소스 관리를 참고하세요. 또한 수평형 포드 자동 확장 처리기를 사용하여 CPU, 메모리 또는 커스텀 측정항목을 기반으로 복제본을 자동으로 확장 또는 축소할 수 있습니다.

다음 부하 분산 서비스를 사용하는 것도 좋습니다.

포드 중단 예산 정의

중단 예산을 정의하여 유지보수 이벤트나 업데이트와 같은 중단 발생 시 애플리케이션에 필요한 최소 포드 수를 지정하는 것이 좋습니다. 다음 예는 중단 예산을 정의하는 방법을 보여줍니다.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

자세한 내용은 애플리케이션에 중단 예산 지정을 참조하세요.