OpenStack 컨트롤러 노드 장애 진단 및 복구 전략

OpenStack 컨트롤러 노드 장애는 겉으로 보이는 증상보다 실제 원인이 한 단계 뒤에 숨어 있는 경우가 많습니다. Horizon이 멈췄다고 해서 Horizon만의 문제는 아니고, API 500 에러가 난다고 해서 무조건 Keystone이나 Nova API부터 재시작할 일도 아니더라고요. 제가 현장에서 가장 자주 봤던 패턴은 VIP는 살아 있는데 백엔드가 죽어 있는 경우, API 프로세스는 active인데 MQ나 DB 때문에 요청이 끝까지 처리되지 않는 경우, 그리고 클러스터는 떠 있으나 쿼럼이 깨져 상태 변경이나 쓰기가 막히는 경우였습니다. 그래서 OpenStack 컨트롤러 노드 장애는 서비스 이름보다 의존성의 방향으로 봐야 훨씬 빨리 풀립니다.

운영 중이면 마음이 급해서 전체 재시작부터 누르기 쉽습니다. 그런데 그 한 번이 원인 추적 단서를 지워버리고, Galera나 RabbitMQ처럼 합류 상태가 중요한 구성요소는 오히려 더 꼬이게 만들 때가 많거든요. 제 경험상 복구 속도를 가장 크게 좌우하는 건 기술 스택 지식의 양보다, VIP → API 엔드포인트 → 인증 → MQ → DB → 스케줄링 순서로 범위를 줄이는 습관이었습니다. 이번 글은 그 순서를 기준으로, 실제 운영자가 바로 복붙해 확인할 수 있는 명령과 함께 OpenStack 복구 판단 기준을 정리한 버전입니다.

컨트롤러 노드의 API, 메시지 큐, 데이터베이스, 가상 IP 흐름을 한눈에 보여주는 개요 이미지입니다.

왜 OpenStack 컨트롤러 노드 장애가 까다로운가

컨트롤러 노드는 단일 프로세스 집합이 아니라, 서로 실패를 전염시키는 제어면 묶음에 가깝습니다. 그래서 증상과 원인이 자주 어긋납니다. 예를 들어 사용자는 “로그인이 안 된다”고 말하지만 실제론 VIP가 다른 노드로 넘어가지 못한 경우가 있고, 운영자는 “Nova API가 죽었다”고 판단했는데 실제론 RabbitMQ 인증 불일치 때문에 scheduler와 conductor가 요청을 소비하지 못하는 경우도 있습니다. 이 차이를 빨리 읽어내는 게 OpenStack 디버깅의 핵심이더라고요.

• API 계층: Apache HTTPD 또는 uWSGI 앞단은 떠 있어도 뒤쪽 WSGI 애플리케이션이 DB 세션 고갈, TLS 오류, 엔드포인트 오설정으로 실패할 수 있습니다.
• 메시지 계층: RabbitMQ는 프로세스가 active여도 vhost 권한, DNS, Erlang cookie, 네트워크 분리 문제로 실질적인 메시지 전달이 끊길 수 있습니다.
• 데이터 계층: Galera는 mysqld 프로세스가 떠 있다는 사실보다 Primary 쿼럼과 Synced 상태가 중요합니다. 여기서 어긋나면 조회 일부는 가능해 보여도 쓰기나 상태 변경이 막힐 수 있습니다.
• 가상 IP 계층: Keepalived, HAProxy, Pacemaker는 각각 정상처럼 보여도 헬스체크 기준, 리소스 제약, fail count 누적으로 트래픽이 없는 노드로 붙어버릴 수 있습니다.

이 구조에서 흔한 실수는 로그를 서비스별로 따로 읽는 겁니다. 실제로는 요청의 흐름으로 묶어 읽어야 합니다. 토큰 발급 실패면 Keystone 로그만 보는 게 아니라, Keystone이 의존하는 MariaDB 연결 오류와 HAProxy 백엔드 상태를 같이 봐야 합니다. 반대로 인스턴스 생성 실패라면 Nova API 로그만 보는 순간 반쯤 틀립니다. scheduler, conductor, RabbitMQ 연결, compute 서비스 heartbeat까지 같이 봐야 맞습니다.

OpenStack 컨트롤러 노드 장애 복구 전에 정할 원칙

OpenStack 복구는 “무엇을 고칠까”보다 “무엇을 아직 건드리지 말까”를 먼저 정하는 편이 안전합니다. 저는 장애가 나면 아래 다섯 가지부터 메모합니다. 이 습관이 생각보다 진짜 편하더라고요.

1. 영향 범위 먼저 고정: 로그인만 실패하는지, 새 VM 생성만 안 되는지, 기존 VM 네트워크까지 영향이 있는지 적어둡니다. 복구 중 증상이 바뀌면 그 변화도 기록합니다.
2. 단일 장애점 후보를 분리: VIP 문제, 인증 문제, MQ 문제, DB 쿼럼 문제를 한 바구니에 넣지 않습니다. 동시에 여러 계층을 건드리면 원인과 결과가 섞입니다.
3. 재시작은 마지막 수단: 상태 확인 없이 systemctl restart를 반복하면, 장애 전 최초 오류 시점과 후속 오류가 뒤섞여 로그 해석이 더 어려워집니다.
4. 클러스터는 프로세스가 아니라 합의 상태를 본다: Galera는 Primary, RabbitMQ는 노드 합류와 큐 소비 여부, Pacemaker는 리소스 위치와 fail count가 핵심입니다.
5. 복구 완료 기준을 기능으로 잡는다: 프로세스 active는 통과선이 아니라 시작선입니다. 최소한 토큰 발급, 서비스 목록 조회, 테스트 생성 요청까지 확인해야 진짜 정상입니다.

특히 HA 환경에서는 “한 대는 살아 있다”가 별 의미가 없을 때가 많습니다. VIP가 다른 노드에 남아 있거나, HAProxy가 헬스체크 기준 때문에 백엔드를 모두 제외한 상태라면 사용자는 전체 장애로 봅니다. 그래서 저는 컨트롤러 장애에서 먼저 리더를 찾는 게 아니라 현재 트래픽이 어디로 흘러야 하는지부터 확인합니다.

실전 1단계: OpenStack 컨트롤러 노드 장애 범위 빠르게 좁히기

처음 5분은 세부 원인보다 장애의 모양을 분류하는 시간입니다. Horizon만 안 열리는지, CLI도 안 되는지, 토큰은 발급되는데 특정 리소스 조회만 실패하는지 확인하면 절반은 끝납니다. 제가 자주 쓰는 1차 점검 묶음은 아래입니다.

source admin-openrc

openstack token issue
openstack endpoint list
openstack service list
openstack compute service list
openstack network agent list
openstack hypervisor list

여기서 해석 기준이 중요합니다.

• openstack token issue 실패: Keystone 자체, Keystone DB 연결, Keystone 뒤단 VIP/TLS 문제를 먼저 의심합니다.
• token issue는 성공하지만 compute service list 실패: Nova API 또는 Nova DB/MQ 경로를 좁혀봅니다.
• CLI 전체가 타임아웃: VIP, HAProxy, 방화벽, DNS, 인증서 체인부터 봅니다.
• 조회는 되는데 생성만 실패: 대체로 MQ, scheduler, conductor, compute heartbeat 쪽이 더 유력합니다.

그다음엔 각 컨트롤러에서 서비스 상태를 넓게 훑되, “실패한 유닛 목록”과 “최근 30분 로그”를 같이 봅니다. active만 보면 놓치는 경우가 많아서요.

sudo systemctl --failed
sudo systemctl status apache2 httpd haproxy keepalived mariadb rabbitmq-server
sudo journalctl -u haproxy -u keepalived -u mariadb -u rabbitmq-server --since "30 minutes ago"
sudo journalctl -u openstack-keystone -u openstack-nova-api -u openstack-nova-scheduler -u openstack-nova-conductor -u neutron-server -u httpd --since "30 minutes ago"

배포판별 차이도 미리 염두에 두는 게 좋습니다. Debian/Ubuntu 계열은 apache2, RHEL 계열은 httpd를 많이 씁니다. 패키지 방식에 따라 Keystone 서비스명이 다를 수 있고, WSGI 배치라면 개별 API 데몬보다 웹서버 로그가 먼저 단서를 줄 때도 있습니다. 이런 차이를 모르고 “서비스가 없다”고 오판하는 경우를 꽤 봤습니다.

초기 장애 범위를 줄이기 위해 systemd 상태와 OpenStack CLI를 함께 점검하는 장면을 보여주는 이미지입니다.

실전 2단계: VIP, HAProxy, Keepalived 또는 Pacemaker 확인

컨트롤러가 2대 이상이면 API 장애처럼 보이는 이슈의 상당수가 사실은 진짜 API 장애가 아닙니다. VIP가 안 붙었거나, HAProxy가 헬스체크 실패로 백엔드를 전부 제외했거나, Pacemaker가 fail count 때문에 리소스 이동을 멈춘 경우가 더 실무적입니다. 제 판단 기준은 간단합니다. 토큰 발급도 안 되고 CLI가 아예 timeout이면 가장 먼저 L4/L7 진입점부터 본다입니다.

Keepalived/HAProxy 조합을 쓰는 경우

ip addr show
sudo systemctl status keepalived haproxy
sudo journalctl -u keepalived -u haproxy --since "20 minutes ago"
echo "show stat" | sudo socat stdio /run/haproxy/admin.sock
curl -sk https://VIP:5000/v3/
curl -sk https://VIP:8774/

여기서 보는 포인트는 세 가지입니다. 첫째, ip addr show로 VIP가 현재 노드에 실제로 붙었는지 확인합니다. 둘째, HAProxy admin socket의 show stat에서 프론트엔드는 열려 있지만 백엔드가 모두 DOWN인지 봅니다. 셋째, 단순 TCP 연결이 아니라 실제 API 경로에 curl을 때려 HTTP 응답 코드를 확인합니다. 401이 오면 인증 전 단계까지는 도달한 것이고, 503이면 백엔드 헬스체크나 라우팅 쪽을 더 의심해야 합니다.

실무적으로는 HAProxy 헬스체크 정의가 너무 공격적일 때도 문제가 됩니다. 예를 들어 백엔드 프로세스는 살아 있는데 TLS 체인 오류나 리다이렉트 때문에 헬스체크가 실패하면, 사용자는 전체 장애처럼 보게 됩니다. 이럴 땐 애플리케이션을 고치기 전에 헬스체크가 무엇을 기준으로 down 판정을 내리는지부터 봐야 합니다.

Pacemaker/Corosync 조합을 쓰는 경우

sudo pcs status
sudo pcs resource status
sudo crm_mon -1
sudo pcs resource failcount show
sudo journalctl -u pacemaker -u corosync --since "30 minutes ago"

Pacemaker 환경은 서비스 자체보다 정책이 장애처럼 보일 때가 많습니다. 리소스가 stop 상태인지, 특정 노드에 묶여 있는지, migration threshold를 넘어 fail count가 누적돼 더 이상 움직이지 않는지 확인해야 합니다. 제 경험상 이 구간은 서비스 지식보다 Pacemaker 제약 해석 능력이 복구 시간을 더 크게 좌우합니다. 그래서 운영 인원이 적거나 교대 근무가 잦은 팀이라면, 기능적으로 더 유연하더라도 복잡한 리소스 제약은 줄이는 편이 낫습니다.

실전 3단계: MariaDB/Galera와 RabbitMQ를 분리해서 본다

API 500 에러, 요청 지연, 일부 기능 실패는 DB와 MQ가 비슷한 얼굴로 나타납니다. 그래서 둘을 한꺼번에 “백엔드 문제”라고 묶으면 복구가 느려집니다. 제 방식은 이렇습니다. 인증과 조회 중심이면 DB를 먼저, 생성과 비동기 후속 작업이면 MQ를 먼저 봅니다. 물론 둘 다 봐야 하지만, 시작점은 달라야 합니다.

MariaDB/Galera 확인 포인트

sudo mysql -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
sudo mysql -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';"
sudo mysql -e "SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
sudo mysql -e "SHOW GLOBAL STATUS LIKE 'wsrep_ready';"
sudo mysql -e "SHOW VARIABLES LIKE 'read_only';"
sudo mysql -e "SHOW DATABASES;"

판단 기준은 숫자보다 상태 문자열입니다.

• wsrep_cluster_status=Primary가 아니면 일단 정상 쿼럼이 아닙니다. 프로세스가 살아 있어도 트랜잭션 경로는 신뢰하기 어렵습니다.
• wsrep_local_state_comment=Synced가 아니면 노드가 합류 중이거나 분리된 상태일 수 있습니다.
• wsrep_ready=ON이 아니면 노드가 애플리케이션 질의를 정상 처리하지 못할 가능성이 큽니다.
• read_only=ON이거나 애플리케이션 쓰기만 실패하면, 클러스터 분할 또는 보호 모드 전환을 의심해야 합니다.
• SHOW DATABASES;는 단순 접속 확인용일 뿐이고, 실제 장애 판단은 wsrep 상태와 쓰기 가능 여부로 해야 합니다.

Galera에서 특히 위험한 순간은 “한 노드는 살아 보이는데 어느 노드가 마지막 정상 상태였는지 확신이 없을 때”입니다. 이때 성급하게 부트스트랩하면 데이터 최신성이 더 중요한 노드를 버리고 오래된 상태를 기준으로 클러스터를 다시 세울 수 있습니다. 그래서 강제 복구는 서비스 복구 명령이 아니라 데이터 기준점 선정 작업으로 봐야 합니다. 이 구분이 없으면 장애는 끝났는데 데이터 정합성 이슈가 남습니다.

RabbitMQ 확인 포인트

sudo rabbitmqctl cluster_status
sudo rabbitmqctl list_queues name messages consumers durable
sudo rabbitmqctl list_connections pid peer_host peer_port state user vhost
sudo rabbitmqctl list_users
sudo rabbitmqctl list_permissions --vhost /
sudo journalctl -u rabbitmq-server --since "30 minutes ago"

RabbitMQ는 “프로세스가 떠 있다”보다 “OpenStack 서비스가 올바른 계정과 vhost로 실제 연결 중인가”가 핵심입니다. 제가 많이 본 실패 모드는 아래와 같습니다.

• 비밀번호 변경 후 부분 반영: 일부 컨트롤러만 새 transport_url을 쓰고 나머지는 예전 값이라, 특정 서비스만 간헐적으로 실패합니다.
• 권한 불일치: 사용자는 존재하지만 vhost permission이 맞지 않아 연결은 되는데 소비가 안 되거나 채널 생성이 실패합니다.
• DNS/호스트명 문제: RabbitMQ 노드 간 이름 해석이 어긋나 클러스터 합류가 불안정합니다.
• Erlang cookie 불일치: 노드 프로세스는 살아 있으나 클러스터 멤버십이 정상 구성되지 않습니다.

list_queues에서 메시지가 계속 쌓이고 소비자가 0에 가깝다면, 그 큐를 읽어야 할 서비스가 죽었거나 인증 문제로 붙지 못하는 경우가 유력합니다. 반대로 연결 수는 많은데 처리량이 안 나오는 상황은 DB 지연, API worker 부족, backend timeout까지 함께 봐야 합니다. 즉 RabbitMQ가 범인인지, RabbitMQ가 병목을 드러내는 거울인지를 구분해야 합니다.

데이터베이스 쿼럼과 메시지 큐 상태를 함께 확인해야 하는 이유를 보여주는 비교 이미지입니다.

재현 가능한 실제 시나리오: API는 살아 보이는데 인스턴스 생성이 실패할 때

이 패턴은 문서보다 현장에서 더 자주 나옵니다. Horizon 로그인은 되고 openstack token issue도 성공합니다. openstack server list도 됩니다. 그런데 openstack server create만 실패하거나, 요청이 accepted로 보였다가 일정 시간이 지나 ERROR로 떨어집니다. 이럴 때 저는 Nova API를 바로 재시작하지 않고, 요청이 메시지 큐를 타고 scheduler와 conductor로 이어지는 경로를 따라갑니다.

1. 사용자가 VM 생성 요청을 보냅니다.
2. Keystone 인증은 통과합니다.
3. Nova API는 요청을 받아 DB와 MQ에 후속 작업을 남깁니다.
4. scheduler 또는 conductor가 MQ 연결 문제, 권한 문제, 이름 해석 문제로 작업을 소비하지 못합니다.
5. 사용자 입장에서는 “API는 사는데 생성만 안 되는 이상한 장애”로 보입니다.

이 시나리오에서 제가 먼저 보는 명령은 아래입니다.

source admin-openrc
openstack server create --flavor m1.small --image TEST_IMAGE --network TEST_NET diag-test-vm
openstack server event list diag-test-vm
sudo journalctl -u openstack-nova-api -u openstack-nova-scheduler -u openstack-nova-conductor --since "15 minutes ago"
sudo grep -R "transport_url\|rabbit" /etc/nova/
sudo rabbitmqctl list_users
sudo rabbitmqctl list_permissions --vhost /

여기서 핵심은 실패 메시지 자체보다 어느 단계에서 멈췄는지입니다. API가 요청을 접수했는데 scheduler 로그가 비어 있으면 MQ 전달 경로를 의심하고, scheduler는 받았는데 conductor가 후속 작업을 못 하면 DB 또는 내부 RPC를 더 봅니다. transport_url은 특히 꼼꼼히 대조해야 합니다. 사용자명, 비밀번호, 호스트, 포트, vhost 중 하나만 틀려도 장애가 “간헐적”으로 보일 수 있습니다. 여러 컨트롤러 노드에서 설정 파일 버전이 미묘하게 다른 경우가 실제론 꽤 많습니다.

다만 환경에 따라 openstack server event list 조회가 정책이나 권한 설정의 영향을 받을 수 있으니, 이벤트 조회가 막혀 있으면 Nova API와 scheduler 로그를 우선 기준으로 잡는 편이 안전합니다.

선택 기준: 어떤 컨트롤러 노드 HA 구성이 복구에 유리한가

컨트롤러 노드 HA는 기술적으로 더 많은 기능을 가진 구성이 항상 더 낫지는 않습니다. 제가 운영 관점에서 따지는 기준은 세 가지입니다. 새벽에 누가 복구하나, 리소스 이동 정책을 팀이 실제로 이해하나, 장애 원인을 10분 안에 좁힐 수 있나입니다. 그 기준으로 보면 선택은 꽤 선명해집니다.

제 추천은 명확합니다. 운영 인원이 적고 장애 대응 절차가 아직 정교하지 않다면 단순한 HA 구성이 더 낫습니다. 반대로 리소스 제어 정책이 서비스 품질에 직접 연결되고, 팀이 Pacemaker 상태 해석에 익숙하다면 그때 복잡한 구성이 제값을 합니다. 기능이 아니라 복구 가능성을 기준으로 고르셔야 합니다.

⚠️ OpenStack 컨트롤러 노드 장애에서 자주 만나는 트러블슈팅 포인트

• 시간 동기화 문제: 토큰 유효성 오류, TLS 검증 문제, 클러스터 노드 간 이상 동작이 전부 시간 어긋남에서 시작될 수 있습니다. timedatectl, chronyc sources -v, chronyc tracking을 같이 보세요.
• 이름 해석 문제: VIP, 컨트롤러 FQDN, RabbitMQ 노드명 중 하나라도 서로 다르게 풀리면 MQ 클러스터, API endpoint, 인증서 검증이 동시에 흔들립니다.
• TLS 인증서 만료 또는 CN/SAN 불일치: 프로세스는 모두 active인데 HTTPS 호출만 실패하는 전형적인 패턴입니다. 단순 ping보다 실제 핸드셰이크 확인이 낫습니다.
• 부분 재시작의 함정: DB/MQ가 불안정한 상태에서 API만 재시작하면 재시도 로그만 늘고, 최초 오류 원인이 뒤로 묻힙니다.
• 쿼럼 없는 강제 복구: Galera 부트스트랩은 마지막 정상 노드 기준이 불명확하면 데이터 정합성 리스크가 생깁니다.

이 항목들은 사소해 보여도 현장에선 매우 자주 원인입니다. 특히 이름 해석과 시간 동기화는 “인프라는 멀쩡해 보이는데 왜 OpenStack만 이상하지?” 같은 상황을 만들어서 더 헷갈립니다. 그래서 저는 컨트롤러 장애 초기에 아래 묶음을 자주 함께 확인합니다.

timedatectl
chronyc sources -v
chronyc tracking
getent hosts controller-1 controller-2 controller-3
getent hosts VIP_FQDN
hostname -f
openssl s_client -connect VIP:5000 -servername VIP_FQDN </dev/null

여기서 인증서 출력은 길지만, 현장에선 세 가지만 봐도 충분할 때가 많습니다. 인증서 만료 여부, 요청한 서버 이름과 SAN 일치 여부, 체인 검증이 중간에서 끊기는지입니다. 애플리케이션 로그에서 SSL 오류만 보고 끝내면, 실제론 LB 앞단 인증서 배치 문제를 놓칠 수 있습니다.

검증: 복구 후 무엇을 확인해야 하나

복구는 서비스 프로세스가 올라온 시점이 아니라, 운영자가 다시 제어권을 회복한 시점에 끝납니다. 그래서 저는 확인 순서를 일부러 기능 기준으로 짭니다. 인증, 조회, 생성, HA 상태 재검증 순서입니다.

1. openstack token issue 성공 여부
2. openstack service list와 주요 에이전트 조회
3. 네트워크, 이미지, 플레이버 목록 조회
4. 테스트 포트 또는 테스트 인스턴스 생성 요청
5. 기존 인스턴스의 콘솔, 볼륨, 네트워크 연결 상태 점검
6. VIP, HAProxy 백엔드, Galera, RabbitMQ 클러스터 상태 재확인

source admin-openrc

openstack token issue
openstack network list
openstack image list
openstack flavor list
openstack server list
openstack hypervisor list
openstack compute service list
openstack network agent list

판단은 이렇게 하시면 됩니다. 인증은 되는데 특정 목록만 실패하면 그 서비스 API 또는 그 뒤단 백엔드가 아직 덜 복구된 겁니다. 조회는 되는데 생성이 안 되면 MQ, scheduler, compute 연동을 더 봐야 합니다. 그리고 정말 중요한 부분이 하나 더 있습니다. 복구 직후 5분만 보는 건 부족합니다. 큐 적체가 늦게 풀리거나, Galera가 재합류 후 상태가 흔들리는 경우가 있어서 최소한 짧은 관찰 구간은 두는 편이 안전합니다.

복구 후 단순 프로세스 상태가 아니라 실제 OpenStack 기능이 정상인지 검증하는 장면을 표현한 이미지입니다.

정리 겸 FAQ: 현장에서 바로 결정하는 기준

Q. OpenStack 컨트롤러 노드 장애가 났을 때 가장 먼저 뭘 봐야 하나요?

A. 사용자 영향 범위와 VIP 진입점입니다. CLI와 Horizon이 같이 죽었다면 네트워크, VIP, HAProxy부터 보는 게 빠릅니다. 반대로 로그인은 되는데 특정 기능만 실패하면, 그 API 뒤의 MQ나 DB 의존성을 먼저 좁히는 편이 맞습니다.

Q. 모든 서비스를 재시작하면 빨리 해결되지 않나요?

A. 대체로 아닙니다. 특히 Galera와 RabbitMQ는 “살아났다”보다 “정상 합류했다”가 중요합니다. 합류 상태 확인 없이 재시작을 반복하면 원인도 흐려지고 복구 범위도 넓어질 수 있습니다.

Q. 어떤 구조를 추천하나요?

A. 결론은 분명합니다. 운영 난이도를 낮춰야 하는 환경이면 HAProxy + Keepalived가 더 낫고, 정교한 리소스 제어와 명확한 운영 절차가 이미 있는 팀이면 Pacemaker 기반 HA가 맞습니다. 홈랩이나 비핵심 서비스라면 단일 컨트롤러와 검증된 백업 절차가 오히려 더 현실적일 수 있습니다.

현장에서 제일 빨리 통하는 한 문장을 남기면 이겁니다. OpenStack 컨트롤러 노드 장애는 서비스 이름 순서가 아니라 의존성 순서로 봐야 빨리 끝납니다. CLI 전체가 죽었으면 VIP와 LB부터, 인증만 안 되면 Keystone과 DB부터, 생성만 안 되면 Nova와 RabbitMQ부터 보세요. 그리고 운영 인원이 적다면 복잡한 HA보다 설명 가능한 HA가 더 안전합니다. 밤 2시에 문서 없이도 복구할 수 있는 구조가 결국 가장 좋은 구조더라고요.

비슷한 운영 글을 계속 쓰신다면 Keystone 장애, RabbitMQ 권한 오류, Galera 쿼럼 복구 절차를 각각 내부 링크로 분리해 두는 것도 추천드립니다. 이런 묶음 글이 검색 유입도 잘 받고, 나중에 팀 온보딩할 때도 꽤 유용합니다.

운영 규모에 따라 어떤 복구 전략과 HA 구성을 선택하면 좋은지 요약한 마무리 이미지입니다.