- Python 중심 흐름이라 현재 서비스 구조와 자연스럽게 맞지 않았습니다.
- 정부기관 환경의 접근통제와 폐쇄망 요구를 그대로 반영하기 어려웠습니다.
- 모든 VM을 같은 방식으로 복구하면 운영 중요도를 반영할 수 없었습니다.
OpenStack HA 복구 자동화
복구 흐름을 Java로 다시 구성하고, HA·우선순위·보안·폐쇄망 요구사항에 맞게 확장한 프로젝트입니다.
6개월간 진행된 팀 프로젝트에서 OpenStack API 연동, 장애 VM 판별, 복구 대상 노드 선정, 우선순위 처리, 복구 결과 기록까지 HA 복구 로직의 백엔드를 처음부터 끝까지 직접 맡았고, 50대 이상 VM 환경에서 실제로 검증했습니다.
- Java 중심 복구 구조로 재구성해 기존 서비스와 자연스럽게 연결했습니다.
- 계정별 접근권한, 폐쇄망 운영, 대규모 HA 제약을 제품 기능으로 반영했습니다.
- 우선순위 기반 복구를 도입해 더 중요한 워크로드부터 먼저 복구되게 했습니다.
기본 기능 위에 얇은 래퍼를 씌운 것이 아니라, 기존 서비스 구조에 맞게 복구 워크플로우 자체를 다시 만들었습니다.
모든 VM을 동일하게 복구하지 않고 운영 중요도에 따라 복구 순서를 제어할 수 있도록 만들었습니다.
정부기관 환경에서 필요한 계정별 접근권한과 폐쇄망 운영 제약을 고려해 기본 복구 동작을 확장했습니다.
Animated Architecture
장애 감지부터 VM 복구 완료까지 15초로 보는 HA 흐름
원래 다이어그램의 핵심 레이블과 흐름은 유지하면서, 제3자가 더 빠르게 이해할 수 있도록 설명형 애니메이션으로 단순화했습니다.
단순 API 연동이 아니었습니다. 50대 이상 VM을 관리하는 환경에서, 장애 노드 한 대에 속한 5~10대의 VM을 감지-판별-재기동까지 약 3~5분 안에 순차 복구할 수 있도록, 더 강한 보안·접근통제·폐쇄망 요구사항까지 만족하도록 복구 동작 자체를 바꾼 작업이었습니다.
프라이빗 클라우드 복구 플랫폼
이 작업에 사용한 핵심 기술입니다.
먼저 궁금할 질문들
01기본 OpenStack 복구 기능으로는 어떤 한계가 있었을까?
02정부기관 환경에 맞추기 위해 무엇을 다시 설계해야 했을까?
03우선순위 기반 복구는 어떤 운영 문제를 해결했을까?
질문별 상세 보기
궁금할 만한 질문들을 중심으로 풀어봤습니다
위에는 빠르게 훑어볼 수 있는 요약을 두고, 아래에는 자연스럽게 떠오를 질문을 따라 상세 내용을 정리했습니다.
01이 프로젝트를 가장 먼저 보여주는 이유는 무엇인가요?
세 프로젝트 중 판단이 가장 많이 개입된 작업이기 때문입니다. GPU 모니터링은 파이프라인을 잘 연결하는 문제였고, 결제 시스템은 혼자서 빠르고 안전하게 배포하는 문제였다면, 이 프로젝트는 오픈소스 위에 '장애 노드 안의 VM 중 무엇을 먼저 살릴 것인가', '어떤 기준으로 재기동 대상 노드를 고를 것인가'처럼 정답이 정해져 있지 않은 문제를 직접 설계해야 했습니다. 50대 이상의 VM을 관리하는 환경에서, 장애 노드 한 대에 속한 5~10대의 VM을 감지-판별-대상 노드 선정-재기동-상태확인까지 약 3~5분 안에 순차 복구하도록 만든 것이 그 결과이고, 이 판단 과정을 가장 구체적으로 설명할 수 있는 프로젝트라 먼저 보여드립니다.
02이 프로젝트에서 제가 직접 책임진 범위는 어디까지였나요?
- OpenStack 복구 API를 연동하고, 복구 흐름의 시작점이 되는 장애 VM 판별 로직을 구현했습니다.
- 정상 노드를 복구 대상으로 선정하는 기준을 직접 설계하고, 기존 Python 기반 흐름을 Java 중심 구조로 다시 구성했습니다.
- 장애 노드 한 대에 속한 5~10대의 VM 중 중요도가 높은 워크로드가 먼저 복구되도록 우선순위 기반 복구 설정을 구현했습니다.
- VM별 복구 결과를 기록하고, 50대 이상 VM을 관리하는 환경에서 고객 납품 전 확장된 복구 흐름을 테스트했습니다.
03이 프로젝트의 강점을 뒷받침하는 근거는 무엇인가요?
50대 이상 VM을 관리하는 환경에서, 장애 노드 한 대에 속한 5~10대의 VM을 감지-판별-순차 복구까지 약 3~5분 안에 처리합니다.
장애 노드 안에서도 중요도가 높은 워크로드가 먼저 복구되도록 우선순위 처리 기능을 추가했습니다.
정부·공공기관 및 엔터프라이즈 고객이 요구하는 폐쇄망 운영과 계정별 접근통제까지 고려해 복구 흐름을 확장했습니다.
04여기서 핵심이 된 기술적 판단은 무엇이었나요?
고객 요구사항을 보면 OpenStack API를 그대로 노출하는 것만으로는 부족했습니다. 복구 워크플로우를 고객 환경에 맞는 내부 기능처럼 바꾸고 확장해야 했습니다.
규모가 커질수록 모든 VM을 같은 긴급도로 복구하면 안 됩니다. 우선순위 설정을 통해 모든 장애를 똑같이 처리하지 않고 운영 중요도를 반영하도록 했습니다.
여러 노드와 더 넓은 VM 범위에서도 복구 로직이 안정적으로 동작하도록, 상태 처리와 조정을 위해 Raft 기반 접근을 활용했습니다.
05실제 시스템 흐름은 어떻게 이어졌나요?
OpenStack 오픈소스 복구 동작을 분석하고 고객 요구와의 차이를 파악합니다.
기존 서비스 환경에 맞춰 복구 워크플로우를 Java로 재구성합니다.
계정별 접근권한과 고객 특화 운영 제약사항을 반영합니다.
중요 워크로드가 먼저 복구되도록 우선순위를 설정합니다.
더 큰 규모의 VM 복구를 위해 HA 복구 동작을 조정합니다.
납품 전 테스트를 통해 전체 복구 흐름을 검증합니다.
06무엇을 포기하고 무엇을 선택했나요?
| 옵션 | 장점 | 단점 | 선택 |
|---|---|---|---|
| 오픈소스 기본 동작을 그대로 사용 | 초기 연동이 가장 빠름 | 고객 특화 보안 및 네트워크 요구를 만족할 수 없음 | 실제 운영환경에 맞게 복구 흐름을 확장하고 재구성함 |
| 단순 순차 복구 | 구현이 쉬움 | 워크로드 중요도와 규모 문제를 반영하지 못함 | 우선순위 기반 복구 동작을 도입함 |
| 기본 API 동작 성공에만 집중 | 초기 개발 비용이 적음 | 폐쇄망 및 HA 중심 고객 환경에서 버티기 어려움 | 실제 고객 납품 환경을 기준으로 설계함 |
07결과적으로 무엇이 달라졌나요?
결과적으로 50대 이상 VM을 관리하는 환경에서 검증된 Java 기반 HA 복구 워크플로우를 만들었습니다. 장애 노드 한 대에 속한 5~10대의 VM을 약 3~5분 안에 감지하고 순차 복구하며, 단순한 OpenStack API 사용을 넘어 정부·공공기관 및 엔터프라이즈 고객의 보안·네트워크·우선순위 요구사항까지 만족시켰습니다.