디자인 및 정책에서의 복원력
“재해 복구”와 관련하여 가장 자주 듣게 되는 문구는 “비즈니스 연속성”입니다. 연속성에는 긍정적인 의미가 있습니다. 재해 이벤트나 범위가 더 적은 것의 범위를 데이터 센터 내부로 제한하는 이상을 말합니다.
그러나 “연속성”은 노력에도 불구하고 엔지니어링 용어가 아닙니다. 비즈니스 연속성을 위한 단일 수식, 방법론 또는 방안은 없습니다. 모든 조직에는 해당 비즈니스 유형 및 방식과 관련된 고유한 모범 사례가 있을 수 있습니다. 연속성은 모범 사례를 성공적으로 적용하여 긍정적인 결과를 얻는 것입니다.
복원력의 의미
엔지니어는 ‘복원력’의 개념을 알고 있습니다. 시스템이 다양한 상황에서 좋은 성능을 유지하는 경우 복원력 있는 시스템이라고 합니다. 위험 관리자는 직면하는 부정적인 영향에 대응할 준비가 된 유사시 대기, 보안 조치 및 재해 절차를 구현한 비즈니스를 잘 준비된 것으로 간주합니다. 엔지니어는 시스템이 “정상”과 “위협”, “안전”과 “재해” 같은 흑백 논리로 작동하는 환경을 인식하지 못할 수 있습니다. 부정적인 상황에서 지속적이고 예측 가능한 서비스 수준이 제공된다면, 엔지니어는 비즈니스를 지원하는 시스템이 제대로 작동한다고 인식합니다.
클라우드 컴퓨팅이 데이터 센터에서 급부상하기 시작한 2011년, ENISA(European Network and Information Security Agency, 유럽 연합의 한 부서)는 정보 수집에 사용한 시스템의 복원력에 대한 인사이트를 요청한 E.U. 정부에 응답하여 보고서를 발행했습니다. 보고서에 따르면, “복원력”의 실제 의미나 측정 방법과 관련해서 ICT 담당자(유럽에서 “ICT”는 통신을 포함하는 “IT”를 가리키는 용어임) 간에 의견이 일치하지 않았습니다.
덕분에 ENISA는 James P. G. Sterbenz 교수가 이끄는 캔자스 대학(KU) 연구 팀이 시작한 프로젝트가 미국 국방부에 배치될 계획임을 알게 되었습니다. 해당 프로젝트는 ResiliNets(Resilient and Survivable Networking Initiative)1라고 하며, 다양한 상황에서 정보 시스템의 복원력 변동 상태를 시각화하는 방법입니다. ResiliNets는 조직의 복원력 정책에 대한 합의 모델의 프로토타입입니다.
KU 모델은 익숙하고 쉽게 설명할 수 있는 여러 메트릭을 활용하며, 일부 메트릭은 이 장에서 이미 소개되었습니다. 여기에는 다음이 포함됩니다.
내결함성 - 앞에서 설명한 대로, 장애가 있을 때 시스템이 예상 서비스 수준을 유지할 수 있는 기능입니다.
중단 허용 범위 - 시스템 자체가 원인이 아닌, 예측할 수 없고 극단적인 운영 상황(예: 정전, 인터넷 대역폭 부족, 트래픽 급증)에서 동일한 시스템이 예상 서비스 수준을 유지할 수 있는 기능입니다.
존속성 - 자연재해를 포함하여 가능한 모든 상황에서 시스템이 항상 공칭은 아니더라도 타당한 서비스 성능 수준을 제공할 수 있는 기능의 평가입니다.
ResiliNets의 주요 이론은 시스템 엔지니어링과 인적 노력을 결합하여 정보 시스템의 복원력을 정량적으로 향상할 수 있다는 것입니다. 사용자가 수행하는 작업, 더 중요하게는 사용자가 일상적으로 ‘계속’ 수행하는 작업이 시스템을 강화합니다.
작전 지역의 육군, 해군 및 해병대가 전술적 배치 원칙을 익히고 기억하는 방법에서 힌트를 얻어, KU 팀은 ResiliNets 실행의 수명 주기를 기억하는 방법으로 냅킨 뒷면 니모닉을 제안했습니다. D2R2 + DR. 그림 9에 표시된 것처럼, 변수는 순서대로 다음을 나타냅니다.**
방어 - 정상적인 작동에 대한 위협으로부터 시스템 방어
탐지 - 가능한 장애와 외부 상황으로 인한 부정적인 영향 발생 탐지
수정 - 영향을 해결하진 못했지만, 시스템에 미칠 수 있는 후속 영향 수정
복구 - 정상적인 서비스 수준으로 복구
진단 - 이벤트의 근본 원인 진단
구체화 - 재발 방지를 위해 필요한 이후 동작 구체화
그림 9: ResiliNets를 활용하는 환경에서 모범 사례 작업의 수명 주기
각 단계에서 사용자와 시스템에 대한 특정 성능 및 작동 메트릭을 얻을 수 있습니다. 해당 메트릭을 결합하여, 유클리드 기하학적 평면을 사용하는 그림 9.10의 차트와 같이 차트에 점을 그릴 수 있습니다. 각 메트릭을 두 개의 1차원 값으로 줄일 수 있습니다. 하나는 서비스 수준 매개 변수 P를 반영하고, 다른 하나는 작동 상태 N을 나타냅니다. ResiliNets 주기의 여섯 단계를 모두 구현하고 반복하면 서비스 상태 S가 차트의 좌표(N, P)에 그려집니다.
그림 10: ResiliNets 상태 공간 및 전략 내부 루프
서비스 목표를 충족하는 조직은 해당 S 상태가 그래프의 왼쪽 아래 모서리에 붙어 있고, 내부 루프 기간에 해당 위치나 근처에 유지됩니다. 서비스 목표가 저하되면 상태가 오른쪽 위를 향해 원치 않는 벡터로 이동합니다.
ResiliNets 모델이 엔터프라이즈의 IT 복원력을 묘사하는 데 보편적으로 사용된 것은 아니지만 일부 조직, 특히 공공 부문에서 채택되어 클라우드 혁신을 촉진한 몇 가지 변화를 트리거했습니다.
성능 시각화. 복원력을 관련자에게 알리기 위해 현재 상태를 자세히 설명할 필요는 없습니다. 사실상 한 단어도 사용하지 않고 복원력을 보여 줄 수 있습니다. 클라우드의 메트릭을 통합하는 최신 성능 관리 플랫폼에는 대시보드 및 효과적인 유사 도구가 포함되어 있습니다.
복구 조치와 절차가 재해 상황에서만 사용되는 것은 아닙니다. 잘 설계된 완벽한 정보 시스템은 방심하지 않는 엔지니어와 운영자가 지속적으로 관리하여 위기 상황의 수정 절차와 거의 차이가 없는 일상적인 유지 관리 절차를 구현합니다. 예를 들어 상시 대기 재해 복구 환경에서 서비스 수준 문제 수정 작업은 실제로 자동화될 수 있으며, 기본 라우터가 영향을 받는 구성 요소에서 다른 곳으로 트래픽을 전송합니다. 다르게 표현하면 오류 대비가 오류 발생을 기다리는 것은 아닙니다.
정보 시스템은 사용자로 구성됩니다. 자동화를 통해 사용자가 더 효과적으로 작업하고, 더 효율적으로 제품을 생산할 수도 있습니다. 하지만 예측할 수 없는 상황 및 환경 변화에 대응하도록 설계된 시스템에서는 사용자를 대체할 수 있는 것이 없습니다.
복구 지향 컴퓨팅
ResiliNets는 세기 전환 직후에 Microsoft에서 만든, ROC(복구 지향 컴퓨팅)라는 개념의 구현 중 하나입니다.2 주요 원칙은 장애와 버그가 컴퓨팅 환경의 영원한 진실이라는 것입니다. 말하자면 환경 정화에 과도한 시간을 허비하는 대신 조직에서 환경의 예방 접종에 기여하는 상식적인 조치를 적용하는 것이 더 유용할 수 있습니다. 20세기 전환 직전에 도입되었으며, 사람이 하루에 여러 번 손을 씻어야 한다는 급진적 개념과 동등한 컴퓨팅 개념입니다.
퍼블릭 클라우드에서의 복원력
퍼블릭 클라우드 서비스 공급자는 모두, 사용하는 이름은 다르더라도 복원력 원칙과 프레임워크를 준수합니다. 그러나 클라우드 플랫폼은 조직의 정보 자산 전체를 클라우드로 가져오지 않는 한, 조직의 데이터 센터에 복원력을 추가하지 않습니다. 하이브리드 클라우드 구현은 최소한의 복원력만 있습니다. CSP 관리자가 성실하게 복원력을 준수할 것이라고 가정할 수 있지만(준수하지 않을 경우 SLA 약관을 위반하게 됨), 전체 시스템의 복원력 유지 관리는 항상 고객의 작업이어야 합니다.
Azure Resiliency Framework
‘비즈니스 연속성 전략’에 대한 국제 표준 지침은 ISO 22301입니다. 다른 ISO(국제 표준화 기구) 프레임워크와 마찬가지로, 준수하는 조직이 전문적인 인증을 받을 수 있는 모범 사례 및 작업 지침을 지정합니다.
해당 ISO 프레임워크는 실제로 비즈니스 연속성이나 복원력을 정의하지 않습니다. 대신 조직의 고유한 컨텍스트에서 연속성의 의미를 정의합니다. 지침 공문에는 “조직은 비즈니스 영향 분석 및 위험 평가의 결과를 기준으로 비즈니스 연속성 전략을 확인하고 선택합니다. 비즈니스 연속성 전략은 하나 이상의 솔루션으로 구성되어야 합니다." 가능하거나 필요한 솔루션을 나열하지는 않습니다3
그림 11은 Microsoft에서 묘사하는 Azure의 ISO 22301 규정 준수 다단계 구현입니다. SLA(서비스 수준 계약) 작동 시간 목표가 포함된 것을 확인합니다. 해당 수준의 복원력을 선택하는 고객을 위해 Azure는 로컬 가용성 영역 내에 가상 데이터 센터를 복제하지만, 지리적 위치가 수백 마일 분리된 별도의 복제본을 프로비저닝합니다. 그러나 법적인 이유로(특히, 유럽 연합의 개인 정보 보호법 준수를 유지하기 위해) 지리적 위치 분리 중복성은 일반적으로 북아메리카 또는 유럽과 같은 “데이터 보존 경계”로 제한됩니다.
![Figure 11: Azure Resiliency Framework, which protects active components on multiple levels, in accordance with ISO 22301. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-11.jpg)
그림 11: ISO 22301에 따라 여러 수준에서 활성 구성 요소를 보호하는 Azure Resiliency Framework [출처: Microsoft]
ISO 22301은 복원력과 관련이 있고 복원력 지침으로 설명되는 경우가 많지만, Azure가 테스트된 복원력 수준은 Azure 플랫폼에만 적용되고 해당 플랫폼에서 호스트된 고객 자산에는 적용되지 않습니다. Azure 클라우드 및 다른 곳에 자산을 복제하는 방법을 포함하여 프로세스를 관리, 유지 관리 및 자주 개선할 책임은 고객에게 있습니다.
Google Container Engine
최근까지 소프트웨어는 하드웨어와 기능적으로 동일하지만 디지털 형식인 머신 상태로 인식되었습니다. 해당 관점에서 소프트웨어는 정보 시스템의 비교적 정적 구성 요소로 인식되었습니다. 보안 프로토콜은 소프트웨어를 정기적으로 업데이트하도록 규정하며, “정기적”이란 말은 일반적으로 1년에 몇 번, 업데이트 및 버그 수정이 제공되었을 때를 의미합니다.
클라우드 역학을 통해 실현되었지만 많은 IT 엔지니어가 기대하지 않았던 것은 소프트웨어가 증분적으로 자주 진화할 수 있는 기능이었습니다. CI/CD(‘연속 통합 및 지속적인 업데이트’)는 서버 쪽과 클라이언트 쪽에서 모두, 자동화를 통해 소프트웨어의 증분 변경 내용을 자주(대체로 매일) 스테이징할 수 있는 새로운 원칙 집합입니다. 스마트폰 사용자는 앱 스토어에서 매주 몇 번씩 업데이트되는 앱 덕분에 CI/CD를 정기적으로 경험합니다. CI/CD를 통해 도입된 각 변경 내용은 사소할 수 있지만 사소한 변경 내용을 어려움 없이 신속하게 배포할 수 있다는 팩트로 인해 바람직하긴 해도 예기치 못한 부작용으로, 훨씬 더 복원력 있는 정보 시스템이 등장했습니다.
CI/CD 배포 모델에서는 완전히 중복된 서버 클러스터가 대체로 퍼블릭 클라우드 인프라에서 프로비저닝 및 유지 관리되며, 새로 생성된 소프트웨어 구성 요소의 버그를 테스트하고 잠재적 장애를 파악하기 위해 시뮬레이트된 작업 환경에 해당 구성 요소를 스테이징하는 수단으로만 사용됩니다. 그러면 해결 방법이 적용, 테스트, 배포 승인될 때까지 고객 쪽 또는 사용자 쪽 서비스 수준에 직접적인 영향을 주지 않는 안전한 환경에서 수정 프로세스를 수행할 수 있습니다.
GKE(Google Container Engine, 여기서 “K”는 “Kubernetes”를 나타냄)는 VM 기반 애플리케이션 대신 컨테이너 기반 애플리케이션 및 서비스를 배포하는 고객을 위한 Google Cloud Platform 환경입니다. 전체 컨테이너화된 배포에는 마이크로 서비스(“μ-서비스”), 워크로드와 별개이며 독립적으로 작동하도록 설계된 데이터베이스(“상태 저장 데이터 세트”), 종속 코드 라이브러리, 애플리케이션 코드에서 컨테이너의 자체 파일 시스템을 활용해야 하는 경우에 사용되는 작은 운영 체제 등이 포함될 수 있습니다. 그림 9.12는 Google에서 실제로 GKE 고객에게 제안하는 스타일의 배포를 보여 줍니다.
그림 12: Google Container Engine에 대한 CI/CD 스테이징 환경으로서의 상시 대기 옵션
GKE에서 ‘프로젝트’는 일반적으로 데이터 센터에 포함되는 모든 리소스를 가상 형식으로 포함하는 것으로 인식된다는 점에서 데이터 센터와 유사합니다. 하나 이상의 서버 클러스터가 프로젝트에 할당되어 있을 수 있습니다. 컨테이너화된 구성 요소는 홈 유니버스(home universe)와 같은 고유한 ‘네임스페이스’에 존재합니다. 각 네임스페이스는 멤버 컨테이너에 액세스가 허용되며 주소 지정 가능한 모든 구성 요소로 이루어져 있으며, 네임스페이스 외부 항목은 원격 IP 주소를 사용해서 주소를 지정해야 합니다. Google 엔지니어는 각 클래스가 동일한 프로젝트를 공유하면서 보안을 위해 고유한 네임스페이스를 활용하기만 하면, 이전 스타일의 클라이언트/서버 애플리케이션(컨테이너 개발자는 “모놀리스”라고 함)과 컨테이너화된 애플리케이션을 함께 사용할 수 있다고 제안합니다.
제안된 배포 다이어그램에는 각각 두 개의 네임스페이스를 이전 소프트웨어와 새 소프트웨어용으로 운영하는 활성 클러스터 3개가 있습니다. 해당 클러스터 중 두 개는 테스트(초기 개발 테스트 및 최종 스테이징)용으로 위임됩니다. CI/CD ‘파이프라인’에서 새 코드 컨테이너가 테스트 클러스터 중 하나에 삽입됩니다. 여기서 스테이징으로 전송되기 전에 자동화된 테스트 모음을 통과하여 비교적 버그가 없음을 증명해야 합니다. 두 번째 테스트 모음이 새 소프트웨어 컨테이너를 기다립니다. 두 번째 계층 스테이징 테스트를 통과한 코드만 최종 고객이 사용하는 라이브 프로덕션 클러스터에 삽입할 수 있습니다.
그러나 여기에도 유사시 대기가 있습니다. A/B 배포 시나리오에서는 지정된 시간 동안 새 코드가 이전 코드와 함께 존재합니다. 새 코드가 사양에 맞게 수행되지 않거나 시스템에 장애를 도입하는 경우 새 코드를 취소하고 이전 코드를 유지할 수 있습니다. 유예 기간이 만료되고 새 코드가 정상적으로 수행되면 이전 코드는 취소됩니다.
이 프로세스는 오류를 초래하는 장애가 도입되는 것을 방지하는, 정보 시스템을 위한 체계적이고 반자동화된 방법입니다. 그러나 프로덕션 클러스터 자체가 상시 대기 모드로 복제되지 않는 한, 그 자체로 재해 방지 설정은 아닙니다. 이 복제 체계가 많은 클라우드 기반 리소스를 사용하는 것은 분명합니다. 그러나 관련 비용은 조직이 시스템 중단으로부터 보호되지 않는 상태일 때 발생하는 비용보다 훨씬 더 낮을 수 있습니다.
참고자료
Sterbenz, James P.G., et al. “ResiliNets: Multilevel Resilient and Survivable Networking Initiative.” https://resilinets.org/main_page.html.
Patterson, David, et al. "Recovery Oriented Computing: Motivation, Definition, Principles, and Examples." Microsoft Research, March 2002. https://www.microsoft.com/research/publication/recovery-oriented-computing-motivation-definition-principles-and-examples/.
ISO. "Security and resilience - Business continuity management systems - Requirements." https://dri.ca/docs/ISO_DIS_22301_(E).pdf.