소프트웨어

[클라우드드리븐인프라] 맨텍솔루션 “재해복구, 쿠버네티스 환경에서 효과 극대화”

이안나 기자

맨텍솔루션 이진현 상무가 3월13일 서울 서초구 양재엘타워에서 열린 ‘클라우드 드리븐 인프라 & 솔루션 2024’ 콘퍼런스에서 ‘클라우드 네이티브 환경의 A-A 센터와 재해복구 구축 전략’을 주제로 발표를 진행하고 있다.
맨텍솔루션 이진현 상무가 3월13일 서울 서초구 양재엘타워에서 열린 ‘클라우드 드리븐 인프라 & 솔루션 2024’ 콘퍼런스에서 ‘클라우드 네이티브 환경의 A-A 센터와 재해복구 구축 전략’을 주제로 발표를 진행하고 있다.

[디지털데일리 이안나기자] 2011년 농협, 2014년 삼성SDS 과천센터, 2018년 KT 아현지사, 2022년 카카오 먹통사태….

10년이 넘는 기간 재해로 인한 정보기술(IT) 중단은 늘 반복됐다. 특히 SK C&C 판교 데이터화재로 전국민 서비스이던 카카오톡 먹통 사태가 벌어지면서 정부는 재개복구 관련 법안을 강화하는 일명 ‘카카오 먹통 방지법’을 통과시켰다. 재해복구가 오래전부터 IT업계 큰 위협이 되고 있음에도 불구하고 효용성이 없는 이유는 무엇일까?

이진현 맨텍솔루션 상무는 서울 서초구 양재동 엘타워에서 열린 ‘클라우드 드리븐 인프라 & 솔루션 2024’ 콘퍼런스에서 “재해복구 효용성이 떨어지는 이유는 비용이 많이 들고 복잡하며 복구가 잘 될지 의구심이 있기 때문”이라며 “이젠 ‘백업’에서 ‘복구’로 초점을 맞춰야 한다”고 강조했다.

실제 IT실무자들이 재해복구에 의구심을 갖게 된 건 통계적 근거가 있다. 백업본을 가지고 있을 때 복구 실패율은 40%에 달한다. 약속한 시간 내 복구를 못하는 경우는 다반사이고, 급한 상황에서 엔지니어를 부르면 전문 인력 역량에 따라 복구 품질이 달라진다.

물론 이런 비용 문제를 해결하기 위해 일각에선 퍼블릭 클라우드 자체를 재해복구 센터로 쓰는 사례들이 늘고 있다. 농협 등 금융권에서도 아마존웹서비스(AWS)를 재해복구센터로 사용 중이다. 하지만 실제 복구 실패율을 높이는 가장 큰 요인은 비용문제 보다도 ‘앱 변경관리’ 때문이라고 이 상무는 꼬집었다.

이 상무는 “그간 재해복구를 하면서 가장 큰 실패요인은 앱 변경관리 문제였다”며 “가령 운영센터에선 앱을 한 번 구축한 후에도 계속 변하고 데이터는 실시간 소산되는데, 재해복구 센터에 있는 건 가만히 두기 때문에 점차 갭이 벌어진다”고 설명했다.

앱 변경문제를 ‘자동화’로 해결할 수 있는 게 바로 쿠버네티스 환경에서 재해복구다. 쿠버네티스 환경에선 운영세터와 재해복구센터 각각 운영체제(OS)나 하이퍼바이저가 달라도 컨테이너 이미지 구동이 가능하다. 쿠버네티스는 컨테이너로 운영되니, 컨테이너 안에 앱 변경 사항들이 모두 들어있다. 실시간 혹은 정기적으로 저장된 컨테이너를 복제만 하면 앱 변경관리 문제가 해결된다.

이 상무는 “쿠버네티스 같은 경우 앱 변경 관리 이슈로 인해 복구가 안 될 확률은 거의 없다”며 “이게 바로 쿠버네티스가 재해복구 관점에서 제공하는 가장 큰 이점이며, 많은 기관들이 재해복구도 클라우드 네이티브, 쿠버네티스 구조로 가려는 이유 중 하나”라고 설명했다.

맨텍솔루션 이진현 상무가 3월13일 서울 서초구 양재엘타워에서 열린 ‘클라우드 드리븐 인프라 & 솔루션 2024’ 콘퍼런스에서 ‘클라우드 네이티브 환경의 A-A 센터와 재해복구 구축 전략’을 주제로 발표를 진행하고 있다.
맨텍솔루션 이진현 상무가 3월13일 서울 서초구 양재엘타워에서 열린 ‘클라우드 드리븐 인프라 & 솔루션 2024’ 콘퍼런스에서 ‘클라우드 네이티브 환경의 A-A 센터와 재해복구 구축 전략’을 주제로 발표를 진행하고 있다.

쿠버네티스 환경에서 재해복구 방식은 크게 ▲웜(warm) 사이트 ▲핫(hot) site ▲미러(mirror) 사이트 3가지로 나뉜다.

웜 사이트는 데이터만 소산을 해두고, 사고가 발생했을 때 머신을 준비하는 방식이다. 재해 발생 시 복구센터 스토리지에 담겨있던 데이터를 백업 솔루션을 써서 소산을 하고, 클러스터 조인 후 파드를 올리면 복구가 끝난다. 평소 데이터만 이동해두기 때문에 복구 목표 시간이 하루 정도가 가능한 경우 웜사이트를 사용한다.

핫 사이트는 애플리케이션에 올려야하는 서버까지 평소 준비를 마쳐놓은 상태다. 재해가 났을 경우 워크로드와 클러스터까지 미리 다 올려놓은 상황이기 때문에 복구 목표시간이 3시간 이내로 빠르게 하고자 할 때 핫 사이트를 사용한다.

미러 사이트는 액티브(Active)-액티브 방식으로 다시 두가지로 나뉜다. 첫째로 운영센터와 재해복구 워크로드를 하나의 클러스터로 묶어 놓는 경우 이는 1기가 BPS 이상 네트워크로 연결이 돼야 한다. 또한 앱을 컨테이너 형태로 배포를 할 때 파드(POD)를 워크 노트 숫자에 맞게 배포를 해야 한다.

클러스터를 분리하는 액티브-액티브 방식도 존재한다. 이는 고속 네트워크로 연결하기 위한 비용이 들지 않는 장점이 있다. 대신 통합으로 관리하는 쿠버네티스 클러스터, 즉 호스트 클러스터를 만들어야 한다. 클러스터가 분리됐을 때 중요한 건 앱을 컨테이너 형태로 배포를 할 때 2개 클러스터로 동시 배포하는 파이프라인을 만들어야 한다는 점이다.

이 상무는 “웜 사이트, 핫 사이트, 미러 사이트 중 무엇이 적절하지는 비용과 업무 중요도에 따라 달라진다”며 “액티브-액티브로 구현하기 힘든 웹, 데이터베이스는 핫 사이트로 구성하고 그 외 중요도 떨어지는 업무들은 웜사이트로 하는 등 융합을 해서 전략을 펼칠 수 있다”고 말했다.

이안나 기자
anna@ddaily.co.kr
기자의 전체기사 보기 기자의 전체기사 보기
디지털데일리가 직접 편집한 뉴스 채널