OpenStack HA 복구 자동화
복구 흐름을 Java로 다시 구성하고, HA·우선순위·보안·폐쇄망 요구사항에 맞게 확장한 프로젝트입니다.
단순 API 연동이 아니었습니다. 50대 이상 VM을 관리하는 환경에서, 장애 노드 한 대에 속한 5~10대의 VM을 감지-판별-재기동까지 약 3~5분 안에 순차 복구할 수 있도록, 더 강한 보안·접근통제·폐쇄망 요구사항까지 만족하도록 복구 동작 자체를 바꾼 작업이었습니다.
- Python 중심 흐름이라 현재 서비스 구조와 맞지 않았습니다.
- 정부기관 환경의 접근통제와 폐쇄망 요구를 그대로 반영하기 어려웠습니다.
- 모든 VM을 동일하게 다루는 복구 방식으로는 운영 중요도를 반영할 수 없었습니다.
- Java 중심 복구 구조로 재구성해 기존 서비스와 자연스럽게 연결했습니다.
- 계정별 접근권한, 폐쇄망 운영, 대규모 HA 제약을 제품 기능으로 반영했습니다.
- 우선순위 기반 복구를 도입해 더 중요한 워크로드가 먼저 복구되게 했습니다.
기본 OpenStack 복구 기능을 얇게 감싼 것이 아니라, 기존 서비스 구조에 맞게 복구 워크플로우 자체를 재구성했습니다.
모든 VM을 같은 순서로 복구하지 않고, 운영 중요도에 따라 복구 순서를 제어할 수 있도록 만들었습니다.
계정별 접근권한, 폐쇄망 운영, 더 큰 규모의 HA 복구 안정성까지 고려해 기본 기능을 제품 수준으로 확장했습니다.
6개월간 진행된 팀 프로젝트에서 OpenStack API 연동, 장애 VM 판별, 복구 대상 노드 선정, 우선순위 처리, 복구 결과 기록까지 HA 복구 로직의 백엔드를 처음부터 끝까지 직접 맡았고, 50대 이상 VM 환경에서 실제로 검증했습니다.
복구 흐름
OpenStack 오픈소스 복구 동작을 분석하고 고객 요구와의 차이를 파악합니다.
기존 서비스 환경에 맞춰 복구 워크플로우를 Java로 재구성합니다.
계정별 접근권한과 고객 특화 운영 제약사항을 반영합니다.
중요 워크로드가 먼저 복구되도록 우선순위를 설정합니다.
직접 맡은 범위
OpenStack 복구 API를 연동하고, 복구 흐름의 시작점이 되는 장애 VM 판별 로직을 구현했습니다.
정상 노드를 복구 대상으로 선정하는 기준을 직접 설계하고, 기존 Python 기반 흐름을 Java 중심 구조로 다시 구성했습니다.
장애 노드 한 대에 속한 5~10대의 VM 중 중요도가 높은 워크로드가 먼저 복구되도록 우선순위 기반 복구 설정을 구현했습니다.
먼저 궁금할 만한 질문들
한국에서는 클라우드 인프라 제품을 개발하며 커리어를 시작했고, 캐나다에서는 비즈니스 고객을 위한 실서비스 웹 개발과 결제 흐름 구현을 맡아왔습니다.