내결함성 있는 클라우드 서비스 빌드
데이터 센터 및 클라우드 서비스 관리와 관련하여 신뢰할 수 없는 부분을 기반으로 신뢰할 수 있는 서비스를 디자인하고 유지해야 하는 파트가 상당히 많습니다. 다음 그림은 신입 사원 교육 파트를 보여주며, 대규모 데이터 센터에서 정기적으로 발생하는 여러 가지 유형의 수많은 오류에 대한 아이디어를 제공해야 합니다.
그림 2: 교육 프레젠테이션에 표시된 안정성 문제
오류로 인해 시스템 내의 상태 정보가 잘못되어 시스템 오류가 발생합니다. 시스템에서 발생하는 오류는 일반적으로 다음 유형 중 하나입니다.
- 일시적 오류: 시간이 지나면 스스로 수정되는 시스템의 일시적 오류입니다.
- 영구적 오류: 복구할 수 없는 오류이며 일반적으로 리소스를 교체해야 합니다.
- 간헐적 오류: 시스템에서 주기적으로 발생하는 오류입니다.
오류 때문에 서비스가 중단되거나 시스템 기능이 저하되어 시스템의 가용성에 영향을 줄 수 있습니다. 내결함성 시스템은 시스템에서 오류가 발생하더라도 계속 작동하는 기능을 갖추고 있습니다. 클라우드에서 내결함성 시스템이란 SLA(서비스 수준 계약)에서 허용하는 기준보다 가동 중지 시간이 짧아서 일관적으로 서비스를 제공하는 시스템으로 간주되는 경우가 많습니다.
내결함성이 중요한 이유는 무엇인가요?
대규모 중요 업무용 시스템에서 오류가 발생하면 모든 관련 당사자에게 상당한 금전적 손실이 발생할 수 있습니다. 클라우드 컴퓨팅 시스템은 계층형 아키텍처를 사용한다는 본질적 특성을 갖고 있습니다. 따라서 한 클라우드 리소스 계층에서 오류가 발생하면 상위 계층에서 오류를 트리거하거나 하위 계층에 대한 액세스를 숨길 수 있습니다.
예를 들어 시스템의 하드웨어 구성 요소에 오류가 있으면 시스템에서는 오류가 있는 리소스를 사용하여 가상 머신에서 실행되는 SaaS(Software as a Service) 애플리케이션의 정상적인 실행에 영향을 줄 수 있습니다. 시스템 내 계층의 오류는 각 수준에서 공급자 간의 SLA와 직접적인 관계가 있습니다.
사전 조치
서비스 공급자는 알려진 이슈 또는 예측 가능한 오류를 방지할 수 있는 방법으로 시스템을 디자인하기 위해 여러 가지 조치를 취합니다.
프로파일링 및 테스트
서비스 가용성을 보장하려면 클라우드 리소스의 부하 및 스트레스 테스트를 수행하여 가능한 오류 원인을 파악해야 합니다. 이러한 메트릭을 프로파일링하면 예기치 않은 동작 없이 예상되는 부하를 성공적으로 견딜 수 있는 시스템을 디자인할 수 있습니다.
초과 프로비전
초과 프로비전은 특정 시간에 일반적으로 예상되는 리소스 사용률보다 많은 리소스를 배포하는 것을 말합니다. 시스템의 수요를 정확하게 예측할 수 없는 경우에는 예기치 않은 부하 급증을 처리할 수 있도록 리소스를 과도하게 프로비저닝하는 것이 나쁘지 않은 전략일 수 있습니다.
일년 내내 서버의 부하가 일정하게 평균 수준을 유지하지만, 휴가철에 부하 패턴이 급격히 증가할 것으로 예상되는 전자상거래 플랫폼을 생각해 봅시다. 이러한 피크 시간에는 피크 사용량에 대한 기록 데이터를 기반으로 추가 리소스를 프로비저닝하는 것이 좋습니다. 트래픽 급증은 일반적으로 짧은 시간에 수용하기 어렵습니다. 이후 섹션에서 설명하겠지만, 동적 스케일링과 관련된 시간 비용이 있습니다. 부하 패턴의 변화를 감지하고 새 부하를 수용할 수 있도록 추가 리소스를 프로비저닝하는 단계는 시간이 오래 걸립니다. 이러한 단계는 모두 시간이 필요합니다. 이렇게 조정하는 시간 동안 과부하가 걸릴 수 있으며, 최악의 경우 시스템이 중단되고 운이 좋으면 서비스 품질 저하에서 그칩니다.
초과 프로비전은 공격자가 시스템 오류를 유도하기 위해 대량의 트래픽을 throw하여 시스템에 과부하가 걸리도록 설계된 요청을 생성하는 DoS(서비스 거부 공격) 또는 DDoS(분산 DoS) 공격을 방어하는 전략으로도 사용됩니다. 어떤 공격이든, 시스템에서 공격을 감지하고 수정 조치를 취할 때까지 항상 약간의 시간이 걸립니다. 이러한 요청 패턴을 분석하는 동안 시스템은 이미 공격을 받고 있으므로 완화 전략을 구현할 때까지 트래픽 증가를 견딜 수 있어야 합니다.
복제
추가 하드웨어 및 소프트웨어 구성 요소를 사용하여 중요한 시스템 구성 요소를 복제하면 전체 시스템을 중단하지 않고 시스템의 일부에서 오류를 자동으로 처리할 수 있습니다. 복제에는 다음과 같은 두 가지 기본 전략이 있습니다.
- 활성 복제 - 복제된 모든 리소스가 동시에 활성 상태이며 모든 요청에 응답하고 처리합니다. 즉, 클라이언트 요청과 관련하여 모든 리소스는 동일한 요청을 받고, 모든 리소스는 동일한 요청에 응답하고, 요청 순서는 모든 리소스에서 상태를 유지합니다.
- 수동 복제 - 기본 단위에서만 요청을 처리하고, 보조 단위는 상태만 유지하다가 기본 단위에 오류가 있으면 기본 단위의 역할을 맡습니다. 클라이언트는 주 리소스에만 연결되며, 상태 변경 정보를 모든 보조 리소스에 전달합니다. 수동 복제의 단점은 기본 인스턴스에서 보조 인스턴스로 전환할 때 요청이 삭제되거나 QoS가 저하될 수 있다는 것입니다.
활성 전략과 매우 유사한 반활성이라고 하는 하이브리드 전략도 있습니다. 차이점은 기본 리소스의 출력만 클라이언트에 공개된다는 점입니다. 보조 리소스의 출력은 표시되지 않고 기록되며, 주 리소스가 실패하는 즉시 전환할 준비가 되어 있습니다. 다음 그림은 복제 전략 간의 차이점을 보여줍니다.
그림 3: 복제 전략
복제에서 고려해야 할 중요한 요소는 사용할 보조 리소스의 수입니다. 시스템의 중요도에 따라 애플리케이션마다 다르지만, 다음과 같은 3가지 정식 복제 수준이 있습니다.
- N+1: 정상적으로 작동하려면 N개 노드가 필요한 애플리케이션에서 오류를 대비하여 여분의 리소스를 하나 더 프로비저닝합니다.
- 2N: 이 수준에서는 오류를 대비하여 정상 작동에 필요한 노드마다 여분의 노드를 하나씩 프로비저닝합니다.
- 2N+1: 이 수준에서는 오류를 대비하여 정상 작동에 필요한 노드마다 여분의 노드를 하나씩 프로비저닝하고, 전체적으로 노드를 하나 더 프로비저닝합니다.
사후 조치
사전 조치 외에도, 오류가 발생할 때 시스템에서 사후 조치를 취하고 오류를 처리할 수 있습니다.
확인 및 모니터링
예기치 않은 동작이나 리소스 손실을 확인하기 위해 모든 리소스를 지속적으로 모니터링합니다. 모니터링 정보에 따라 리소스를 다시 시작하거나 새 리소스를 가져오도록 복구 또는 재구성 전략을 설계합니다. 모니터링을 통해 시스템의 오류를 파악할 수 있습니다. 서비스를 사용할 수 없게 만드는 오류를 크래시 오류라고 하며, 시스템에서 비정상적인/잘못된 동작을 유도하는 오류를 비잔틴 오류라고 합니다.
시스템 내의 크래시 오류를 확인하는 데 사용되는 여러 가지 모니터링 전략이 있습니다. 이러한 전략 중 두 가지는 다음과 같습니다.
- Ping-에코: 모니터링 서비스가 각 리소스에 상태를 요청하면 응답할 시간 범위가 주어집니다.
- 하트비트: 트리거 없이 각 인스턴스가 정기적으로 모니터링 서비스에 상태를 보냅니다.
비잔틴 오류의 모니터링은 일반적으로 제공되는 서비스의 속성에 따라 달라집니다. 모니터링 시스템은 대기 시간, CPU 사용률, 메모리 사용률 등의 기본 메트릭을 확인하고 예상 값과 비교하여 서비스 품질이 저하되었는지 확인할 수 있습니다. 또한 일반적으로 중요한 서비스 실행 지점마다 애플리케이션 관련 감독 로그가 유지되며, 이 로그를 주기적으로 분석하여 서비스가 항상 정상적으로 작동하고 있는지(또는 시스템에 삽입된 오류가 있는지) 확인합니다.
검사점 및 다시 시작
클라우드의 여러 프로그래밍 모델은 검사점 전략을 구현하며, 마지막으로 저장된 검사점으로 복구할 수 있도록 여러 실행 단계에서 상태가 저장됩니다. 데이터 분석 애플리케이션에는 종종 테라바이트 단위의 데이터 세트에서 실행되어 정보를 추출하는 장기 실행 병렬 분산 태스크가 있습니다. 이러한 태스크는 여러 개의 작은 실행 청크로 실행되므로, 프로그램 실행의 각 단계에서 전체 실행 상태를 검사점으로 저장할 수 있습니다. 개별 노드가 작업을 완료할 수 없는 오류가 발생하면 이전 검사점에서 실행을 다시 시작할 수 있습니다. 롤백할 올바른 검사점을 확인할 때 가장 큰 문제는 병렬 프로세스에서 정보를 공유하는 시기입니다. 프로세스 중 하나에서 오류가 발생하면 다른 프로세스에서 연쇄 롤백이 발생할 수 있습니다. 다른 프로세스에서 만든 검사점이 사실은 오류가 발생한 프로세스에서 공유하는 데이터의 결과물일 수 있기 때문입니다. 프로그래밍 모델의 내결함성에 대해서는 이후 모듈에서 자세히 설명하겠습니다.
복원력 테스트 사례 연구
대규모 분산 시스템의 그 어떤 단일 구성 요소도 100% 가용성 또는 작동 시간을 보장할 수 없으므로 중복성 및 내결함성을 고려하여 클라우드 서비스를 빌드해야 합니다.
모든 오류(동일한 노드, 랙, 데이터 센터 또는 지리적 중복 배포의 종속성 오류 포함)는 전체 시스템에 영향을 주지 않고 정상적으로 처리되어야 합니다. 경우에 따라 고작 몇 초의 가동 중지 시간 또는 서비스 저하로 인해 백만 단위까지는 아니더라도 수십만 달러의 손실이 발생할 수 있으므로 심각한 오류를 처리하는 시스템의 기능을 테스트하는 것이 중요합니다.
시스템을 강화하고 계획되지 않은 중단이 발생하더라도 대처할 수 있도록 정기적으로 실제 트래픽을 사용하여 오류를 테스트해야 합니다. 복원력을 테스트하기 위해 개발된 여러 가지 시스템이 있습니다. 그 중 하나는 Netflix에서 만든 Simian Army입니다.
Simian Army는 다양한 종류의 오류를 생성하고, 비정상 조건을 감지하고, 시스템이 오류에도 계속 작동하는 기능을 테스트할 수 있는 클라우드의 여러 서비스(원숭이라고도 함)로 구성됩니다. 목표는 클라우드의 보안과 고가용성을 유지하는 것입니다. Simian Army에서 발견된 원숭이 중 일부는 다음과 같습니다.
- 혼돈의 원숭이: 일반적인 오류가 발생해도 클라우드가 고객에게 영향을 주지 않고 계속 실행될 수 있도록 프로덕션 인스턴스를 임의로 선택하여 비활성화하는 도구입니다. Netflix는 혼돈의 원숭이를 “무기를 든 야생 원숭이를 데이터 센터(또는 클라우드 지역)에 풀어 놓으면 닥치는 대로 인스턴스를 때려 부수고 케이블을 물어 뜯겠죠. 그러는 동안에도 고객에게 중단 없이 계속 서비스를 제공한다는 개념”이라고 설명합니다. 구체적인 모니터링과 함께 이러한 종류의 테스트를 사용하면 다양한 형태의 시스템 약점을 노출하고, 그 결과를 기반으로 자동 복구 전략을 수립할 수 있습니다.
- 대기 시간 원숭이: 서로 다른 클라이언트와 서버의 RESTful 통신 간에 지연을 발생시켜 서비스 성능 저하와 가동 중지 시간을 시뮬레이션하는 서비스입니다.
- 의사 원숭이: 비정상 동작(예: CPU 부하)을 보이는 인스턴스를 찾아 서비스에서 제거하는 서비스입니다. 서비스 소유자가 문제의 원인을 찾아 인스턴스를 종료할 수 있는 약간의 시간을 허용합니다.
- 혼돈의 고릴라: AWS 가용성 영역 전체가 사라지는 상황을 시뮬레이션할 수 있는 서비스입니다. 이는 사용자가 볼 수 있는 영향 또는 수동 개입 없이 서비스가 나머지 영역 간에 기능을 자동으로 재분산하는지 테스트하는 데 사용됩니다.