가장 약한 고리: 연쇄 의존성이 시스템 위험에 미치는 영향

시스템 위험 시나리오를 평가할 때 "연쇄" 의존성을 간과하기 매우 쉽습니다. 우리는 "이 하나의 항목이 실패할 가능성은 얼마나 되는가"라는 "노드" 수준에서 위험을 바라보도록 훈련되어 있습니다. 하지만 시스템 위험은 그것보다 훨씬 복잡합니다.

대부분의 시스템에는 다른 구성 요소에 의존하는 구성 요소들이 있습니다. 이를 가장 흔히 살펴보는 곳은 서버의 스토리지 설계이지만, 이는 어떤 시스템 설계에서도 발생합니다. 또 다른 좋은 예는 웹 애플리케이션이 기능하기 위해 애플리케이션 호스트와 데이터베이스 호스트가 모두 필요한 것입니다.

연쇄 의존성은 예제를 통해 설명하는 것이 가장 쉽습니다. SAN 스토리지를 이용한 표준 가상화 설계를 살펴보면서 어디에 장애 도메인 경계가 존재하고 어디에 연쇄 의존성이 있으며 중복성이 시스템 수준의 위험 완화에서 어떤 역할을 하는지 이해해 보겠습니다.

가상화를 위한 표준 SAN(스토리지 에어리어 네트워크) 설계에는 가상화 호스트(편의상 "서버"라 부르겠습니다), SAN 스위치(스토리지 네트워크 전용 스위치), 그리고 디스크 어레이 자체가 있습니다. 이 세 "계층" 각각은 전체 시스템이 기능하기 위해 나머지에 의존합니다. 서버 하나, 스위치 하나, 디스크 어레이 하나로 구성된 가장 단순한 세트를 가정하면, 세 개의 장치가 세 개의 별개 장애 지점을 나타냄이 명확합니다. 세 개 중 하나라도 실패하면 전체 시스템이 실패합니다. 어떤 하나도 혼자서는 유용하지 않습니다. 이것이 연쇄 의존성이며 사슬은 가장 약한 고리만큼만 강합니다.

단순화된 예에서 각 장치는 장애 도메인을 나타냅니다. 각 도메인의 신뢰성을 개선하여 위험을 완화할 수 있습니다. 두 번째 서버를 추가하고 가상화 계층 고가용성 또는 내결함성 전략을 구현하여 서버 장애 위험을 줄일 수 있습니다. 이것은 하나의 장애 도메인의 신뢰성을 개선하지만 두 개의 도메인은 이전과 마찬가지로 위험한 상태로 남아있습니다. 그런 다음 중복 스위치를 추가하고 단일 스위칭 경로 손실에 대응하기 위한 멀티패싱 전략을 구성하여 스위칭 계층을 해결할 수 있습니다. 이제 두 개의 장애 도메인이 해결되었습니다. 마지막으로 스토리지 장애 도메인을 해결해야 하며, 이는 마찬가지로 장애 발생 시 투명하게 페일오버할 수 있도록 첫 번째 디스크 어레이에 미러링된 두 번째 디스크 어레이를 통해 중복성을 추가함으로써 이루어집니다.

시스템을 강화했음에도 불구하고 여전히 의존성 체인에 세 개의 장애 도메인이 있습니다. 우리가 한 것은 체인의 각 "고리", 즉 각 장애 도메인을 자체적으로 더 탄력적으로 만든 것입니다. 하지만 체인은 여전히 존재합니다. 이는 전체 시스템이 체인 내의 단일 장애 도메인보다 훨씬 덜 신뢰할 수 있음을 의미합니다. 시작점보다 훨씬 나아졌지만, 여전히 많은 장애 도메인이 있습니다. 이러한 위험들은 누적됩니다.

전체적인 위험을 결정하는 데 어려운 점은 각 항목의 위험을 평가한 다음, 완화 후의 새로운 위험(중복성 추가를 통해)을 결정하고, 전체 시스템의 총 위험을 결정하기 위해 체인 내의 각 장애 도메인의 누적 위험을 찾아야 한다는 것입니다. 위험 완화 방식이 중요한 역할을 하기 때문에 각 장애 도메인 내의 위험을 결정하는 것은 매우 어렵습니다. 예를 들어 스토리지 디스크 어레이 클러스터가 너무 느리게 페일오버하면 스토리지 클러스터 자체가 올바르게 작동한 것처럼 보이더라도 전체 시스템 장애가 발생할 수 있습니다. 따라서 명확한 장애를 정의하는 것조차 어려울 수 있습니다.

위험을 "상단에서" 평가하는 방식을 취하고 싶은 유혹이 종종 있는데, 이는 매우 위험하지만 정기적인 위험 평가 실무자가 아닌 사람들에게는 매우 흔합니다. 여기서의 경향은 "최상위" 장애 도메인, 이 경우에는 일반적으로 서버만 바라보고, 그 지점 아래에 있는 위험들을 "내부 구성 요소"로 간주하여 위험 평가의 일부가 아닌 것처럼 무시하는 것입니다. 더 기술적이고 덜 노출되며 잘 이해되지 않는 네트워킹이나 스토리지 같은 구성 요소를 무시하고 상대적으로 이해하기 쉬우며 많이 마케팅되는 최상위 계층의 신뢰성 측면에만 집중하기 쉽습니다. 이 "최상위 관점"은 최상위 수준 아래의 위험이 가려지고 일반적으로 무시되어 위험이 높아지는데도 왜 그런지 잘 이해하지 못하게 됩니다.

연쇄 의존성의 개념을 이해하면 복잡한 위험 완화 전략을 가진 복잡한 시스템이 종종 더 단순한 시스템보다 훨씬 더 취약한 결과를 낳는 이유가 설명됩니다. 위의 예에서 체인을 "축소"하여 전체적으로 더 신뢰할 수 있는 시스템을 만들기 위해 여러 가지를 할 수 있습니다.

가장 명백하게 축소할 수 있는 구성 요소는 네트워킹 장애 도메인입니다. 스위치를 완전히 제거하고 스토리지를 서버에 직접 연결한다면(물론 항상 가능한 것은 아닙니다) 사실상 하나의 전체 장애 도메인을 제거하고 체인에서 하나의 고리를 없애는 것입니다. 이제 세 개의 체인 대신 두 개만 있게 되어 각각 실패할 가능성이 있습니다. 다른 모든 조건이 같다면 단순한 것이 더 낫습니다.

이론적으로 외부 스토리지에서 서버 자체의 로컬 스토리지로 전환함으로써 스토리지 장애 도메인도 축소할 수 있습니다. 이는 두 개의 장애 도메인에서 단일 장애 도메인으로 줄이는 것입니다. 물론 남은 하나의 도메인은 축소 전보다 더 많은 복잡성을 지니게 되지만, 전체 시스템 복잡성은 크게 감소합니다. 다시 말하지만, 이것은 다른 모든 요소가 동일하게 유지될 때의 이야기입니다.

고려해야 할 또 다른 접근 방식은 단일 노드 자체의 신뢰성을 높이는 것입니다. 오늘날에는 더 큰 시스템을 바라보고 낮은 비용의 중복 노드를 추가하여 장애 도메인에 신뢰성을 부여하는 방식으로 위험 완화에 접근하는 것이 트렌드입니다. 하지만 전통적으로 이것이 신뢰성으로 가는 기본 경로는 아니었습니다. 과거에는, 메인프레임 및 유사 클래스의 시스템들의 이전 우세가 보여주듯, 단일 노드에 높은 수준의 신뢰성을 구축하는 것이 훨씬 더 일반적이었습니다. 메인프레임 및 고급 스토리지 시스템은 예를 들어 오늘날에도 이를 수행합니다. 이것은 실제로 매우 효과적인 접근 방식일 수 있지만 많은 시나리오를 해결하지 못하며 일반적으로 매우 비쌉니다. 종종 시스템을 부분적으로 혹은 완전히 벤더가 유지 관리해야 하는 필요성으로 인해 그 비용이 증폭됩니다. 이것은 특수한 틈새 상황에서만 잘 작동하는 경향이 있으며 더 일반적인 범위에서는 실용적이지 않습니다.

따라서 이러한 성격의 시스템에서 고려해야 할 세 가지 핵심 위험 완화 전략이 있습니다: 단일 노드의 신뢰성 향상, 단일 도메인의 신뢰성 향상, 또는 의존성 체인의 장애 도메인(고리) 수 감소. 이것들을 적절하게 결합하면 비즈니스 시나리오에 적합한 위험 완화 수준을 달성하는 데 도움이 됩니다.

진정한 어려움이 존재하고 앞으로도 그럴 곳은 서로 다른 위험 완화 전략의 비교입니다. 단일 노드의 위험은 일반적으로 어느 정도 확신을 가지고 추정할 수 있습니다. 단일 도메인 내의 중복성 전략의 위험은 추정 가능성이 훨씬 낮습니다. 일부 중복성 전략은 매우 효과적이어서 장애 도메인을 극도로 신뢰할 수 있게 만들지만, 어떤 전략은 실제로 역효과를 낳아 도메인의 신뢰성을 낮출 수도 있습니다. 중복성 전략에 수반되는 복잡성은 항상 예외 없이 존재하며 일반적으로 보상을 받겠지만, 처음에 예상되는 수준의 신뢰성 혜택을 거의 제공하지 않습니다. 의존성 체인의 위험을 추정하는 것은 각 장애 도메인 개별적으로 관련된 위험에 대한 명확한 이해뿐만 아니라 도메인 경계에서 발생하는 장애 기회(앞서 언급한 스토리지 페일오버 지연 장애 등)에 대한 이해도 필요하기 때문에 더욱 어렵습니다.

지금까지 논의한 내용을 바탕으로 동일한 시나리오에 대한 두 가지 매우 일반적인 접근 방식에서 위험을 결정하는 문제를 탐구해 봅시다.

우리가 논의한 상황의 두 가지 극단적인 예는 가상 머신을 호스팅하는 데 내부 스토리지가 있는 단일 서버 대 서버 계층에서 고가용성 솔루션을 사용하는 두 개의 서버, 스위칭 계층에서 중복성이 있는 두 개의 스위치, 그리고 스토리지 계층에서 고가용성을 제공하는 두 개의 디스크 어레이로 이루어진 여섯 장치의 "체인"입니다. 여기서 중요한 요소를 바꾸면 상대적인 위험을 꽤 명확하게 추정할 수 있습니다. 예를 들어 장애 도메인 중 하나라도 신뢰할 수 있는 중복성이 없다면, 단일 서버가 전반적으로 더 신뢰할 수 있는 시스템임을 꽤 명확하게 결정할 수 있습니다. 단일 노드에 극단적인 수준의 단일 노드 신뢰성이 할당되는 경우를 제외하면 이는 일반적으로 재정적으로 비현실적인 전략입니다. 그러나 각 장애 도메인이 중복성을 유지하면 도메인 내 신뢰성(중복 체인)과 도메인 간 신뢰성(축소된 체인, 단일 서버)의 상대적 위험을 비교해야 합니다.

두 개의 완전히 다른 접근 방식에서 두 가지 위험 완화 수단의 비교 위험을 평가하는 합리적인 방법은 없습니다. 일반적으로 광범위한 도메인 내 위험 완화가 있는 여섯 개(또는 그 이상) 노드 접근 방식이 두 가지 중 더 신뢰할 수 있다고 여겨지며, 이는 거의 확실하게 일반적으로 사실입니다. 하지만 항상 그런 것은 아니며, 이 접근 방식이 단일 노드 전략보다 진정으로 상당한 차이로 더 나은 성과를 보이는 경우는 드물고, 단일 서버 전략보다 4~10배나 더 많은 비용이 드는 경우가 흔합니다. 이는 잠재적으로 신뢰성에서의 소폭 향상, 그리고 신뢰성 손실의 작은 잠재적 위험을 위한 매우 높은 비용입니다. 추가되는 각각의 중복성은 사람이 구현, 모니터링, 유지 관리해야 하는 복잡성을 더하며, 복잡성과 인간의 개입이 늘수록 더 많은 위험이 따릅니다. 인적 오류를 피하는 것이 기계적 장애를 피하는 것보다 종종 더 중요할 수 있습니다.

복구 비용도 고려해야 합니다. 장애가 발생하면 단순한 시스템의 장애에서 회복하는 것은 일반적으로 사소한 일입니다. 반면 매우 복잡한 시스템이 장애를 일으킨 경우 작동 상태로 복원하는 데 상당한 노력이 필요할 수 있습니다. 복잡한 시스템은 또한 유지 관리하기 위해 훨씬 더 넓고 깊은 경험과 자신감이 필요합니다.

시스템의 신뢰성을 결정하는 쉬운 답은 없습니다. 현대의 정보 제공 시스템은 너무 크고 복잡하며 모든 경우에 평가할 수 없는 너무 많은 결정 불가능한 요소들을 가지고 있습니다. 그러나 연쇄 의존성에 대한 좋은 이해와 위험 완화 전략에 대한 이해를 가지고 있다면, 대략적인 상대적 위험 수준을 결정하고, 비슷한 위험 시나리오가 비용 측면에서 어떻게 비교되는지 파악하고, 취약성 지점을 식별하고, 장애 도메인과 의존성 체인을 인식하고, 시스템 설계의 변경이 우리를 신뢰성에서 명확하게 멀어지게 또는 가까워지게 이동시킬지 이해하는 실질적인 조치를 취할 수 있습니다.