앱의 복원력 강화를 위한 개발 및 테스트

Red Hat OpenShift on IBM Cloud 가 제어 플레인 유지 관리를 어떻게 처리하는지, 유지 관리 업데이트가 실행 중인 워크로드에 어떤 영향을 미치는지, 그리고 높은 복원력을 확보하기 위해 애플리케이션을 테스트하고 아키텍처를 설계하는 방법을 알아보세요.

클러스터 아키텍처 및 역할 개요

Red Hat OpenShift on IBM Cloud는 관리 Kubernetes 서비스입니다. 모든 클러스터에서 아키텍처는 [서로 다른 소유권 책임을](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service) 가진 두 개의 계층으로 나뉩니다:

제어 플레인
IBM 에서 운영합니다. Kubernetes API 서버( etcd ), 컨트롤러 관리자 및 스케줄러가 포함되어 있습니다.
데이터 플레인
여러분이 직접 관리합니다. 여기에는 워커 노드, 애플리케이션 포드, 스토리지 구성 및 네트워킹 애드온이 포함됩니다.
클러스터 제어 플레인 및 데이터 플레인에 대한 소유권 책임
비행기 관리자 컴포넌트
제어 플레인 IBM API 서버, etcd, 컨트롤러 관리자, 스케줄러
데이터 플레인 사용자 워커 노드, 애플리케이션 포드, 스토리지, 네트워킹 애드온

IBM 제어 플레인에 정기적으로 패치 버전 업데이트를 적용합니다. 이 패치들은 보안 취약점을 해결하고, 중요한 버그 수정 사항을 적용하며, 클러스터가 ‘ IBM ’ 보안 요구 사항을 지속적으로 준수하도록 보장합니다. 이러한 패치가 어떻게 적용되는지 이해하면 애플리케이션 아키텍처에 대해 정보에 입각한 결정을 내리는 데 도움이 됩니다.

클라우드 환경에서 실행되는 애플리케이션은 일시적인 네트워크 중단, 호스팅 인프라 유지보수, 타사 서비스 지연 등 다양한 동적 상황에 노출됩니다. 모든 환경에서 복원력을 고려하여 설계하고 테스트함으로써 신뢰할 수 있는 프로덕션 워크로드를 보장합니다.

IBM 가 제어 플레인 패치를 적용하는 방법

모든 Red Hat OpenShift on IBM Cloud 클러스터의 제어 플레인 구성 요소는 고가용성(HA) 구성으로 실행됩니다. 각 구성 요소의 여러 복제본이 독립적인 가용 영역에 분산 배치되어, 제어 플레인 내에 단일 장애 지점이 존재하지 않도록 합니다.

패치 업그레이드가 적용될 때, IBM 은 롤링 재구성 전략을 사용합니다. 복제본은 순차적으로 업데이트됩니다:

  • Kubernetes API 서버는 업그레이드 과정 내내 계속 접속 가능합니다.
  • 스케줄링, 자동 확장, 상태 확인과 같은 클러스터 운영은 중단 없이 계속됩니다.
  • IBM 포드가 제거되기 전에 진행 중인 연결이 완료될 수 있도록 점진적인 종료 지연 시간을 제공합니다.

컨트롤 플레인 패치 업그레이드는 데이터 플레인에서 실행 중인 사용자 애플리케이션에 아무런 영향을 미치지 않도록 설계되었습니다. 이 과정 전반에 걸쳐 포드, 서비스 및 워크로드는 워커 노드에서 정상적으로 계속 실행됩니다.

제어 플레인 업데이트 시 워크로드에 미치는 영향

데이터 플레인은 사용자가 직접 관리하므로, IBM 제어 플레인 패치는 사용자 측의 워커 노드나 실행 중인 애플리케이션 포드를 재시작, 재스케줄링하거나 수정하지 않습니다.

그러나 Kubernetes API를 빈번하고 직접적으로 호출하는 애플리케이션이나 도구(예: 사용자 정의 컨트롤러, 오퍼레이터, CI/CD 파이프라인 또는 클러스터 상태를 모니터링하는 모니터링 에이전트 등)는 일시적인 API 오류를 원활하게 처리해야 합니다. Kubernetes 의 일반적인 모범 사례를 따르십시오:

  • 모든 API 호출에 대해 지수적 백오프 방식을 적용한 재시도 로직을 구현하십시오.
  • 재연결 로직 없이 API 서버에 대한 상시 연결에 의존하지 마십시오.

애플리케이션 복원력을 테스트하기 위한 시나리오 시뮬레이션

애플리케이션 복원력에 대한 신뢰도를 높이기 위해, 예정된 유지보수나 예기치 못한 장애가 발생하기 전에 비운영 환경에서 운영 환경의 장애 상황을 시뮬레이션하십시오.

시뮬레이션이 진행되는 동안 애플리케이션에서 예기치 않은 포드 재시작, 오류 로그의 급증, 응답 시간 저하, 클라이언트 요청 손실 등 장애 징후가 나타나는지 모니터링하십시오. 이러한 관찰 결과를 바탕으로 재시도 로직을 개선하거나, 상태 확인 프로브를 조정하거나, 복제본 토폴로지를 조정하십시오.

클러스터 관리 명령(마스터 새로 고침 또는 워커 풀 크기 조정 등)을 실행하려면 관리자 또는 운영자 수준의 플랫폼 액세스 권한과 클러스터 관리 서비스 권한이 필요합니다. 클러스터 인프라에 접근 권한이 없는 애플리케이션 개발자라면, 클러스터 관리자와 협의하여 이러한 시뮬레이션을 실행하십시오.

제어 플레인 갱신을 통한 제어 플레인 패치 시뮬레이션

컨트롤 플레인 새로 고침을 트리거하면, 패치 업그레이드 시 ‘ IBM ’가 사용하는 롤링 업데이트 프로세스가 시작됩니다. 이 테스트는 애플리케이션과 툴링이 제어 플레인 복제본의 전환을 원활하게 처리하는지 확인합니다.

  1. 클러스터에서 제어 플레인 새로 고침을 실행합니다.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

  2. 애플리케이션이 중단 없이 트래픽을 계속 처리하고 있는지, 그리고 클라이언트에 노출된 엔드포인트가 정상적으로 응답하는지 확인하십시오.

워커 노드를 추가 및 제거하여 네트워크 라우팅 업데이트 시뮬레이션하기

워커 노드를 추가하거나 제거하면 ‘ Kubernetes ’이 클러스터 전반의 내부 네트워크 라우팅 로직을 업데이트하여, 인프라 유지보수 중 노드가 순환될 때 발생하는 상황을 시뮬레이션합니다.

  1. 워커 풀의 크기를 조정하여 임시 워커 노드를 추가하십시오.

    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE

  2. 새로운 워커 노드가 초기화되고 클러스터 네트워크에 가입하는 동안 애플리케이션 로그와 응답 지연 시간을 모니터링하십시오.

  3. 테스트가 완료되면 테스트 워커 노드를 제거하십시오.

    1단계에서 생성된 특정 워커 노드를 선택적으로 제거하려면:

    1. 워커 노드를 삭제하기 전에 해당 노드를 격리하고 데이터를 모두 배출하여 워크로드가 원활하게 재일정되도록 하십시오.
       oc cordon NODE_NAME
   oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. 클러스터에서 워커 노드를 삭제합니다.
       ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. ibmcloud oc worker-pool resize 명령을 사용하여 원래의 --size-per-zone 값을 지정함으로써, 워커 풀의 용량을 원래대로 되돌리십시오.

    대안으로, 보다 포괄적인 접근 방식으로서, 특정 노드를 명시적으로 삭제하지 않고 1단계에서 사용한 ‘ ibmcloud oc worker-pool resize ’ 명령어를 통해 워커 풀의 크기를 원래 크기로 되돌릴 수 있습니다.

워크로드 복원력을 위한 권장 관행

클러스터 이벤트 발생 시 애플리케이션의 복원력은 워크로드의 설계 및 구성 방식에 따라 달라집니다. Kubernetes 워크로드 사양에 다음 권장 관행을 적용하십시오:

모든 워크로드에 대해 여러 개의 복제본을 실행합니다

단일 복제본 배포 환경은 서비스 중단을 허용할 수 없습니다. spec.replicas 을 최소한 2 로 설정하십시오(프로덕션 워크로드의 경우 3 이상으로 설정하는 것이 바람직합니다). 이렇게 하면 단일 포드의 손실이나 재스케줄링으로 인해 다운타임이 발생하지 않습니다.

복제본을 여러 영역과 워커 노드에 분산

배포 구성에서 topologySpreadConstraints 또는 pod anti-affinity 규칙을 설정하십시오. 포드를 여러 가용 영역과 워커 노드에 분산 배치하면, 특정 가용 영역의 장애나 노드 유지보수 작업으로 인해 모든 복제본이 동시에 중단되는 것을 방지할 수 있습니다.

Pod 중단 예산(PDB) 구성

PodDisruptionBudget 리소스는 노드 드레인(node draining)이나 클러스터 업데이트와 같은 자발적인 중단 상황에서도 가용성을 유지해야 하는 포드의 최소 개수 또는 비율을 지정합니다. 모든 중요한 워크로드에 대해 PDB를 정의하여, 관리 작업으로 인해 애플리케이션이 감당할 수 있는 수준보다 더 많은 파드가 강제 종료되는 것을 방지하십시오.

준비 상태 및 활성 상태 확인 메커니즘 정의

컨테이너 사양에서 준비 상태 및 활성 상태 프로브를 구성하십시오:

  • 준비 상태 확인: Kubernetes 가 초기화가 완료되고 요청을 처리할 준비가 된 파드에만 트래픽을 라우팅하도록 보장합니다.
  • 활성 상태 확인: 데드락 또는 비정상 상태에 빠진 컨테이너를 Kubernetes 가 자동으로 재시작하도록 설정합니다.

적절한 리소스 요청 및 한도 설정

각 컨테이너에 대해 현실적인 CPU 및 메모리 요청량과 제한을 지정하십시오. 요청을 통해 Kubernetes 스케줄러가 충분한 용량을 갖춘 노드에 포드를 배치하도록 보장합니다. 제한 사항은 단일 컨테이너가 과도한 리소스를 소비하여 동일한 워커 노드에 배치된 다른 워크로드의 성능을 저하시키는 것을 방지합니다.

원활한 종료 처리 구현

포드가 종료될 때, Kubernetes는 SIGKILL``를 전송하기 전에 SIGTERM 신호를 전송합니다. SIGTERM 예외를 처리하고, 새로운 연결 수신을 중단하며, 진행 중인 트랜잭션을 완료한 후, 정상적으로 종료되도록 애플리케이션을 설계하십시오. 애플리케이션이 트래픽을 완전히 처리할 수 있도록 충분한 시간을 확보하기 위해, 포드 사양에서 적절한 terminationGracePeriodSeconds 값을 설정하십시오.

API 서버와의 장기 연결에 의존하지 마십시오

Kubernetes 시청 요청 및 스트리밍 연결(예: oc exec, 포트 포워딩 또는 사용자 지정 API 클라이언트 시청)은 특정 제어 플레인 복제본에 직접 연결됩니다. 패치 업그레이드 중에 해당 복제본이 사이클을 거치면 연결이 끊어집니다. 워크로드와 툴링은 지수적 백오프(exponential back-off) 방식을 적용한 자동 재연결 로직을 구현해야 합니다.

재시도 로직과 서킷 브레이커를 사용하세요

애플리케이션이 Kubernetes API, 외부 데이터베이스 또는 하위 마이크로서비스와 상호작용할 때는 지수적 백오프(exponential back-off)와 지터(jitter)를 적용한 재시도 로직을 구현하십시오. 상류 또는 하류 종속성이 일시적으로 사용할 수 없게 될 때 연쇄적인 장애를 방지하기 위해 회로 차단기 패턴을 사용하십시오.

다음 단계