오류 및 내결함성
일상적인 담론에서는 시스템이 실패하는 이유를 느슨하게 말하는 경향이 있습니다. 오류, 장애, 실패, 버그, 결함 등의 용어가 동일한 의미로 사용되곤 합니다. 데이터 센터의 전문가는 해당 단어를 혼동하거나 서로 바꿔서 사용하면 안 됩니다. 다음은 내결함성 논의와 관련된 용어의 정확한 정의입니다.
버그는 시스템이 일관성 있게 요구 사항 또는 기대치와 다르게 동작하게 하는 시스템 디자인의 변칙입니다. 어떤 의미에서 시스템 또는 소프트웨어가 기대치를 충족하지 못한 것일 수 있지만, 버그는 시스템 실패가 아닙니다. 실제로 대부분의 버그는 시스템이 의도한 것과 다르게, 설계된 대로 정확히 실행된 산물입니다. 여기서 핵심 단어는 "일관성 있게"입니다. 버그 동작은 시스템의 모든 인스턴스에서 재현될 수 있습니다. ‘디버깅’은 시스템을 다시 엔지니어링하여 버그를 제거하는 행위입니다.
장애는 시스템이 디자인과 다르게 동작하거나 완전히 작동 중지되게 하는 시스템의 변칙입니다. 이 경우 시스템 디자인에는 결함이 없지만 해당 디자인의 구현 또는 인스턴스 하나에서 시스템이 제대로 작동하지 않을 수 있습니다. 결함은 시스템의 다른 인스턴스에서 재현할 수 없는 동작을 초래합니다. 결함을 제거하는 행위를 ‘복구’라고 합니다. 시스템 장애는 다음 세 가지 방식 중 하나로 나타날 수 있습니다.
영구 장애는 해당 구성 요소를 완전히 교체하지 않으면 원인을 복구할 수 없는 시스템 중단입니다.
단기 장애는 일시적이지만 일반적으로 반복되지 않는 시스템 중단으로서 원인을 복구하거나 현재 위치에서 수정하거나 개입 없이 자동으로 해결될 수 있습니다.
일시적인 장애는 일시적이고 일반적으로 반복되는 시스템 중단으로서 대체로 구성 요소의 성능 저하나 부적절한 디자인으로 인해 발생하고 수정하지 않을 경우 영구 장애를 초래할 수 있습니다.
실패는 시스템 전체 또는 일부의 완전한 중단으로서 대체로 해결되지 않은 장애로 인해 트리거됩니다. 이 경우 장애는 원인이고 실패는 결과입니다. FT(‘내결함성’) 시스템은 부정적인 상황에서도 예상대로 또는 SLA(서비스 수준 계약) 기대치에 따라 동작하여, 장애 발생 시 실패를 방지하는 시스템입니다.
결함은 하드웨어 구성 요소 제조 또는 소프트웨어 구성 요소 인스턴스화의 변칙입니다. 작동 시 결함을 초래하고 해당 구성 요소를 구현하는 시스템이 실패할 가능성이 큽니다. 해당 변칙은 교체를 통해서만 수정할 수 있습니다.
오류는 원치 않거나 잘못된 결과를 생성하는 작동의 산물입니다. 컴퓨팅 디바이스에서 오류는 디자인 버그나 구현 장애의 증상일 수 있으며, 곧 실패함을 나타내는 효과적인 지표일 수 있습니다.
내결함성이 있는 시스템을 유지 관리하려면 IT 전문가, 관리자 또는 운영자가 해당 개념을 이해하고 개념 간의 차이점을 파악해야 합니다. 클라우드 컴퓨팅 플랫폼은 정의에 따라 내결함성이 있는 시스템입니다. 장애를 예상하여 설계 및 빌드되었으며 서비스 실패를 방지합니다. 엔지니어링 관점에서 해당 복원력이 “클라우드” 개념의 의미입니다. 전화 엔지니어가 시스템 다이어그램에 클라우드 셰이프를 처음 사용했을 때는 확인되거나 파악되지 않았지만, 서비스 수준을 충분히 신뢰할 수 있어 다이어그램에 포함할 필요가 없고 클라우드로 가려도 되는 네트워크 구성 요소를 나타내었습니다.
엔터프라이즈 IT 네트워크와 같은 정보 시스템이 퍼블릭 클라우드 플랫폼과 연결되면서 해당 플랫폼은 FT 시스템으로 동작해야 합니다. 그러나 통신하는 시스템의 내결함성을 이전보다 개선하지는 않으며, 개선할 수도 없습니다. 내결함성은 면제가 아니며, 시스템에 장애가 없음을 보장하지도 않습니다. 더 중요한 점은 FT 시스템이 장애가 없는 것은 아니라는 사실입니다. 오히려 내결함성은 장애가 있을 때 시스템이 예상 서비스 수준을 유지할 수 있는 기능입니다.
정보 시스템의 목적은 정보를 활용하는 기능을 자동화하는 것입니다. 내결함성은 제한된 수준까지만 자동화할 수 있습니다. 원래 ARPANET으로 구현된 인터넷 자체는 주요 목표 중 하나가 내결함성이었습니다. 재해 발생 시 디지털 통신을 다시 라우팅하여 주소에 더 이상 연결할 수 없는 시스템을 우회할 수 있었습니다. 그러나 인터넷은 자체 유지 관리 머신이 아니며, 사실상 모든 정보 시스템이 마찬가지입니다.
정보 시스템이 서비스 목표를 달성하고 유지 관리하려면 사용자 활동이 지속적으로 필요합니다. 최적 시스템은 사용자 개입 및 수정 작업을 간단하고 즉각적이며 플랜에 따라 수행되도록 하는 것입니다.
클라우드 플랫폼의 내결함성
초기 클라우드 서비스 플랫폼은 설계자가 의도한 것보다 내결함성이 낮았습니다. 예를 들어 고객이 여러 데이터베이스 인스턴스 또는 중복 메모리 캐시와 같이 서비스에 대해 리소스를 과도하게 프로비저닝할 수 있는 기능은 충분히 모니터링하지 않더라도 비효율적인 것이 입증되었으며, 재해 상황에서 백업이나 복제본을 사용할 수 없는 경우도 발생했습니다. 더욱이 과도한 프로비저닝은 클라우드 비즈니스 모델의 기본 원칙 중 하나인 필요한 리소스에 대해서만 요금 지불 원칙에 위배됩니다. 주 VM이 중단될 경우를 위해 추가 가상 머신 인스턴스를 임대한다면 조직에서 운영 비용을 절감할 수 없습니다.
FT 시스템은 중복성을 허용하지만, 현재 시점의 요구 및 리소스 가용성 한도에 맞게 동적으로 신중하게 조정해야 합니다. 클라이언트/서버 시대에는 로컬 데이터 스토리지 및 연결된 네트워크 스토리지 볼륨을 포함한 전체 서버가 정기적인 간격으로 백업되었습니다. “전체 백업”이 회사 윤리가 되었습니다. 퍼블릭 클라우드 서비스가 저렴하고 실용적으로 되면서 조직은 “전체 백업”에 해당 서비스를 사용하기 시작했습니다. 시간이 흐르면서 클라우드가 이전 방법을 영구화하는 것 이상의 기능을 제공할 수 있음을 알게 된 것입니다. 클라우드 플랫폼이 구현된 후 내결함성을 적용하는 대신, 처음부터 내결함성으로 클라우드 플랫폼을 설계할 수 있었습니다.
반응형 기술
아무리 신중하게 시스템을 설계했더라도, 대부분의 내결함성은 시스템과 시스템 관리자가 장애의 첫 번째 증거에 얼마나 잘 대응하는지에 따라 달라집니다. 다음은 조직에서 발생하는 장애를 완화하는 데 사용하는 몇 가지 반응형 기술입니다.
비선점형 작업 마이그레이션
비선점형 작업 마이그레이션 기술은 명백히 장애가 발생한 워크로드의 호스트가 동일한 워크로드를 호스트하도록 다시 할당되지 않도록 합니다. 이 혜택을 통해 “작업”을 보호할 수 있지만, 시스템이 잘 기록된 경로를 통해 보다 간편하게 추적할 수 있는 장애 증거로 반복되는 오류 인스턴스를 수집하기 어렵게 만들 수 있습니다.
작업 복제
많은 분산 정보 시스템은 작업의 여러 인스턴스(또는 Kubernetes 오케스트레이션, ‘복제본’)를 동시에 실행합니다. 시스템 장애가 명확하거나 의심되는 경우 작업을 복제하도록 정책 기반 관리 시스템을 설계할 수 있습니다.
검사점 및 복원 지점
가장 간단한 형태의 검사점 및 복원 지점은 다양한 시점의 시스템 스냅샷을 만든 다음, 복원이 필요한 경우 관리자가 지정된 시점으로 “롤백”할 수 있게 하는 작업을 포함합니다. 애플리케이션이 하나의 단위(“트랜잭션”)로 성공하거나 실패해야 하는 데이터베이스에 대해 둘 이상의 작업을 수행하는 경우와 같이 트랜잭션이 관련된 경우에는 해당 전략이 더 복잡해집니다. 일반적인 예는 한 계정에서 돈을 출금하는 동시에 다른 계정에 입금하는 애플리케이션입니다. 재무 자산이 생성되거나 삭제되는 것을 방지하려면 해당 작업이 하나의 단위로 성공하거나 실패해야 합니다.
트랜잭션된 검사점 복구 시스템에서는 회수 가능한 트랜잭션 레코드가 메모리의 ‘프로세스 트리’에 저장됩니다. 트랜잭션 중 특정 지점에서 사용하는 메모리 리소스가 복제되어 복원 풀에 보관됩니다. 로그 분석을 통해 소프트웨어로 인한 장애가 확인되면, 프로세스 트리가 포크되고 트랜잭션 상태가 이전 지점으로 돌아가며 새 트랜잭션이 시도됩니다. 새 트랜잭션이 장애가 발생한 트랜잭션보다 더 나은 성공을 생성하는 경우(예: 오류 수정 테스트에서 오류가 없는 것으로 표시되는 경우), 이전 프로세스 분기는 정리되고 트리의 해당 지점부터 새 분기를 따릅니다. 엔지니어는 이 동작을 컨텍스트 전환이라고 합니다.1
이 방법론의 고급 버전은 프로세스 트리에 추적 시스템을 구현하여, 오류가 다시 발생할 때 시스템에서 프로세스를 역방향으로 작업하여 오류의 원인을 추적할 수 있게 하는 것입니다. 그런 다음 시스템에서 오류가 트리거되기 전의 적절한 복원 지점이나 “복구 지점”을 선택할 수 있습니다.[2]
SGuard라는 또 다른 구현은 워싱턴 대학과 Microsoft Research 연구원이 대량 데이터 스트림의 내결함성 처리를 위해 만든 것입니다. SGuard는 HDFS(Hadoop 분산 파일 시스템)를 사용하여 처리 중에 데이터 스트림의 스냅샷을 동시에 여러 개 작성하도록 예약합니다. 해당 스냅샷은 필요에 따라 더 작은 부분으로 나뉘고, 스트림 처리도 더 작은 세그먼트로 세분화됩니다. 검사점은 HDFS에 저장됩니다. 시스템은 스트리밍 데이터의 여러 실행 가능한 복제본과 스트리밍 데이터 트랜잭션 레코드를 고도로 분산된 위치에 유지 관리합니다. SGuard를 구현하는 데는 상당한 준비 작업이 필요하지만, 장애 이벤트에 대한 응답으로 기본 작업이 트리거되기 때문에 여전히 반응형 내결함성 기술로 간주됩니다.3
사전 대응형 기술
‘사전 대응형 FT 기술’은 장애가 있다고 표시되기 전에 수행합니다. 의도는 예방 조치를 취하는 것이지만, 최신 구현에서는 슬로건이라기보다 방법론에 더 가깝습니다. 다음은 최신 클라우드 플랫폼에서 현재 사용되는 몇 가지 기술입니다.
리소스 복제
효과적인 리소스 복제 전략의 핵심은 단순히 “전체 백업”이 아닐 수 있습니다. 시스템 분석가는 실패 이벤트 후에 자체적으로 복원될 수 있는 시스템 리소스(예: 데이터베이스 엔진, 웹 서버 또는 가상 네트워크 라우터)와 복구할 수 없는 리소스를 확인할 수 있어야 합니다. 스마트 복제는 내결함성이 있는 시스템의 첫 번째 방어선일 수 있습니다.
리소스 복제를 구현하는 데 사용되는 네 가지 일반적인 전략은 그림 1에 나와 있습니다.
활성 복제 - 복제된 모든 리소스가 동시에 활성화되고, 각 리소스가 고유한 ‘상태’, 즉 작동하는 데 필요한 고유한 로컬 데이터를 독립적으로 유지 관리합니다. 이 속성은 클래스의 모든 복제된 리소스가 클라이언트 요청을 수신하고 모든 리소스가 응답을 처리함을 의미합니다. 그러나 해당 클래스에서 지정된 주 리소스의 응답이 클라이언트에 전달됩니다. 주 노드를 포함하여 한 리소스가 실패하면 다른 노드가 후속 노드로 지정됩니다. 이 시스템에서는 주 노드와 복제본 노드 간의 처리가 ‘결정적’이어야 하므로 설정된 일정에 동시에 수행되어야 합니다.
반활성 복제 - 반활성 복제는 활성 복제와 유사하며, 복제본 노드가 비결정적으로 요청을 처리할 수 있다는 차이점이 있습니다. 즉 주 노드와 동시에 요청을 처리하지 않아도 됩니다. 보조 리소스의 출력은 표시되지 않고 기록되며, 주 리소스가 실패하는 즉시 전환할 준비가 되어 있습니다.
수동 복제 - 주 리소스 노드만 요청을 처리하고, 다른 노드(‘복제본’)는 상태를 유지 관리하면서 실패가 발생하여 주 노드로 지정될 때까지 기다립니다. 클라이언트가 연결된 주 리소스는 상태 변경 내용을 모든 복제본에 릴레이합니다. 클래스에 속하는 모든 원본과 복제본은 그룹의 “멤버”로 간주되며, 실패한 것처럼 보이는 멤버는 실제로 실패하지 않은 경우에도 그룹에서 제거될 수 있습니다. 수동 복제는 정상적으로 작동하는 동안 리소스를 적게 사용하지만, 실패 이벤트 발생 시 대기 시간 또는 QoS(서비스 품질)가 저하될 가능성이 있습니다.
반수동 복제 - 이 방법론은 영구적 주 리소스가 없다는 점을 제외하고 수동 복제와 동일한 관계 패턴을 사용합니다. 대신 ‘코디네이터’ 역할이 각 리소스에 차례로 지정됩니다. 순서 조정은 ‘코디네이터 교대 패러다임’이라는 토큰 배달 모델을 통해 결정됩니다.
그림 1: 복제된 정보 시스템의 클라이언트 노드, 주 노드 및 복제본 노드
부하 분산
부하 분산 장치는 동일한 애플리케이션을 실행하는 여러 서버에 다양한 클라이언트의 요청을 분산하여, 워크로드를 분산하고 시스템 구성 요소의 스트레스를 줄입니다. 부하 분산 장치를 사용할 경우의 긍정적인 부작용은 일부 부하 분산 장치가 응답하지 않는 서버에서 다른 서버로 트래픽을 자동으로 보내기 때문에 완전히 실패할 가능성이 줄어든다는 것입니다. 소프트웨어가 클라우드 플랫폼 전체에 배포되도록 설계된 최신 파생 제품(예: 마이크로 서비스)에서는 워크로드가 개별 기능 간에 세분화되고, 기능 자체는 균등 분산 및 보통 사용률 수준을 목표로 서버 쪽 프로세서 간에 배포됩니다.
가상화(클라우드 컴퓨팅의 핵심 요소)를 사용하면 워크로드를 포팅 가능하게 만들어 사용을 최적화할 수 있는 실제 프로세서로 이동할 수 있으므로 프로세서 간에 워크로드를 보다 균등하게 분산할 수 있습니다. 컨테이너화는 가상화된 워크로드를 가상 프로세서에서 분리하여 운영 체제가 가장 잘 준비된 서버 노드에 상주하게 함으로써 이 기술을 개선합니다. 해당 원칙이 Kubernetes 등의 시스템에서 보여 주는 ‘워크로드 오케스트레이션’의 핵심입니다.
복구 및 재구성
소프트웨어 인스턴스가 장기간 배포되는 정보 시스템에서는 해당 소프트웨어를 재부팅해야 할 수 있습니다. 이전의 일부 클라우드 플랫폼은 시간 경과에 따라 소프트웨어 인스턴스의 서비스 수준을 샘플링하여 재부팅이 필요한 경우를 확인했지만, 이후 제품은 정기적인 재부팅을 예약하는 간단한 방법을 사용했습니다. 재부팅 단계에서 구성 파일 시작은 변화하는 시스템 상황을 고려하거나 시작 후 잠재적 실패를 선점하기 위해 자동으로 조정될 수 있습니다.
선점형 마이그레이션
가상화가 데이터 센터에서 중요한 기술로 처음 자리매김했을 때, 프로세서에 대한 워크로드 할당을 라운드 로빈 방식 등으로 회전하여 서버 하드웨어의 스트레스를 균등하게 하는 방법으로 선점형 마이그레이션이 제안되었습니다. 클라우드 플랫폼은 가상 인프라 간에 워크로드를 자주 재배포하기 때문에 이 방법이 거의 필요 없게 되었습니다. 그러나 최근 토론에서 다양한 정보 시스템의 워크로드 스트레스를 예측하는 인공 지능 방법과 함께 이 토픽이 다시 부각되었습니다. 해당 시스템은 실패 가능성이 더 크게 예측된 서버 노드에서 다른 노드로 중요한 워크로드를 보내기 위한 고유한 규칙을 작성할 수 있습니다.
자동 복구
CDN(콘텐츠 배달 네트워크) 또는 소셜 미디어 플랫폼과 같이 광범위하게 분산된 정보 시스템에서는 개별 서버의 기능이 일반적으로 다른 위치나 데이터 센터에 있는 여러 주소로 분산될 수 있습니다. 자동 복구 네트워크는 트래픽 흐름과 응답성을 위해 성능 관리 플랫폼처럼 정기적인 간격으로 다양한 연결을 폴링합니다. 성능 불일치가 있을 때마다 라우터가 주의 대상 구성 요소에서 다른 곳으로 요청을 조정하므로, 결국 해당 구성 요소를 통과하는 트래픽 흐름이 중지됩니다. 구성 요소의 작동 상태를 테스트하여 오류가 있는지 확인할 수 있습니다. 그런 후에 구성 요소를 다시 시작하여 동작이 지속되는지 확인할 수 있으며, 진단 결과에 장애 발생 가능성이 표시되지 않는 경우에만 구성 요소가 활성 상태로 돌아갑니다. 이 유형의 자동화된 트랜잭션 응답성은 고도로 분산된 데이터 센터에서의 최신 자동 복구 예입니다.4
교환 기반의 프로세스 예약
클라우드 플랫폼(퍼블릭 클라우드 기반 서비스를 포함하며 온-프레미스 인프라도 포함할 수 있음)은 고유한 상태를 보고할 수 있습니다. Amazon이 2009년에 수정된 SaaS 모델 구현을 시작했을 때, 해당 엔지니어는 ‘스팟 인스턴스 예약’이라는 개념을 고안했습니다. 해당 시스템에서 고객을 대신하는 자동 프록시는 지정된 작업의 리소스 요구 사항을 보급하고, 구체적으로 클라우드 플랫폼 전체의 서버 노드에서 일종의 입찰 요청을 브로드캐스트합니다. 각 노드는 시간 및 사용되는 리소스 측면에서 입찰 요구 사항을 충족하는 고유한 기능을 보고합니다. 비용이 가장 낮은 입찰자가 계약을 낙찰받고, 작업의 SI(스팟 인스턴스)로 지정됩니다. 이 예약 방식은 현재 Amazon Elastic Compute Cloud의 옵션입니다.5
참고자료
Ioana, Cristescu. A Record-and-Replay Fault Tolerant System for Multithreading Applications. Technical University of Cluj Napoca. http://scholar.harvard.edu/files/cristescu/files/paper.pdf.
Sidiroglou, Stelios, et al.ASSURE: Automatic Software Self-healing Using Rescue Points. Columbia University, 2009.
Kwon Yong-Chul, et al. Fault-tolerant Stream Processing Using a Distributed, Replicated File System. Association for Computing Machinery, 2008. https://db.cs.washington.edu/projects/moirae/moirae-vldb08.pdf.
Yang, Chen. Checkpoint and Restoration of Micro-service in Docker Containers. School of Information Security Engineering, Shanghai Jiao Tong University, China, 2015. https://download.atlantis-press.com/article/25844460.pdf.
Amazon Web Services, Inc. Spot Instance Requests Amazon, 2020. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html.