용어 번역이 적절한 지 모르겠지만, 실패 단일점(single point of failure)이라는 개념이 있다. 제품이나 서비스의 중단을 초래할 수 있는 유일한 접점을 통칭하는 용어다.
다시말하면, 다른 ‘대체’ 접점이 없어서, ‘유일’한 접점이 ‘끊어’지거나, ‘상실’되는 경우, 제품이나 서비스가 중단된다는 의미다.
IT조직내에는 이러한 실패 단일점들이 존재한다. 그러나, 상당수의 IT조직들은 실패단일점에 대해 관심이 없거나, 잘못 이해하고 있는 경우가 많다.
사례를 통해 IT조직내의 실패 단일점에 대해 얘기해 보겠다.
■데이터센터 정전과 관련된 실패 단일점
다음의 일화를 살펴보자. ‘모 데이터센터에서 정전사고가 발생해서, 센터내의 모든 IT 장비의 동작이 8시간 동안 멈췄다. 데이터센터를 통해 IT서비스를 제공받던 기업들은 업무 처리 지연에 따라, 큰 불편을 겪었다. 정전의 원인은 데이터센터의 주변에서 조경작업을 하던 포크레인이, 전력 인입선을 건드려서 발생한 것으로 밝혀졌다.’
데이터센터는 IT설비를 한꺼번에 모아놓은 중앙집중화된 공간이다. 데이터센터의 정전은 IT조직이 제공하는 대부분의 서비스를 중단시키는 대규모 재해 중의 하나다. 데이터센터에 대해 직간접적으로 알고 있는 사람들은 위의 일화에 대해서 고개를 갸우뚱거린다.
대부분의 데이터센터는 두 개의 전력 소스를 통해 공급받아서, 한 쪽이 끊어지더라도, 다른 쪽으로 전원이 즉시 전환되도록 설계되어 있다고 알고 있기 때문이다. 특히, 많은 돈을 들여서, 두 곳의 변전소로부터 전력을 공급받아, 안전하다고 ‘보고’받아 왔고, 그렇게 믿어왔던 IT조직의 경영층들은, 이런 정전사고에 더 큰 충격과 실망을 하게 된다.
■실패 단일점을 포함하고 있는 이중화 구조
전력 소스가 이중화되어 있어더라도, 실패 단일점은 존재한다. 두 곳의 변전소를 통해 전력이 들어오더라도, 데이터센터의 건물내로 인입하는 공간이 ‘합쳐’지는 지점이 있을 수 있으며, 이것이 실패 단일점이다.
또, 데이터센터 내부의 전력 설비 구조에도 실패 단일점이 존재한다. 두 개의 전력 소스가 분리되어 오더라도, 개별 전력 소스의 중단을 감지하는 설비들 중에는 하나의 ‘몸통’으로 두 개의 전력 소스를 포함하고 있는 실패 단일점이 존재한다. 이런 실패 단일점 설비에 고장이 발생하는 경우, 이중화구조는 ‘무력화’된다.
■서버 이중화에 포함된 실패 단일점
IT조직에서는 중요한 서버에 대해서 이중화로 구성하여 한 쪽 서버가 중단되더라도, 다른 서버가 즉시 동작하도록 설계하고 있다. 이런 이중화구조도, 실패 단일점이 존재할 수 있다. 두 개의 서버를 감시하면서, 한 쪽 서버에 이상이 있다고 판단하면, 다른 쪽 서버로 즉시 넘겨주는 소프트웨어도, 하나의 실패 단일점이다.
또, 서버는 이중화했지만, 서버가 사용하는 데이터베이스는 한 대의 대용량 디스크를 사용하는 경우가 있다. 이 디스크 서버에 장애가 발생하는 경우에도, 서버의 이중화 구조는 아무런 기여를 하지 못하게 된다.
■IT 인력의 실패 단일점
IT조직내의 인력에서도 실패 단일점이 존재한다. IT서비스 운영에 있어, 관련된 정보와 기술 등이 특정 인력에 100% 의존하는 경우, 인력의 실패 단일점이라고 볼 수 있다. 특정 서버들의 도입부터 현재의 운영에 이르기까지의 이력을 알고 있는 담당자가 유일하고, 이 담당자가 어떠한 이유에서건 ‘부재’하는 경우, IT서비스의 중단으로 이어질 수 밖에 없다.
‘프로세스’보다는 ‘개인의 판단’에 의존하고, ‘객관적인 정보’가 아닌 ‘개인의 머리속 경험’에 의존하는 IT조직의 경우, 특히 인력의 실패 단일점들이 다수 존재한다.
■가용성과 실패 단일점의 관계
실패 단일점은 IT서비스의 가용성(availability)과 직접적인 관련을 가진다. 실패 단일점들을 많이 가지고 있는 IT서비스는, 사용자나 비즈니스에게, ‘사용 불가’ 상태를 상대적으로 많이 경험하게 만든다. IT서비스를 구성하는 개별 서버나 장비에 장애가 발생하더라도, 해당 서버나 장비가 실패 단일점이 아닌 경우는, IT서비스가 사용자에게 ‘여전히’ 제공되고 있는 상태다.
따라서, 가용성과 실패 단일점은 모두 ‘사용자’ 관점의 중단을 얘기하고 있다. 실패 단일점은 IT서비스가 사용자에게 제공되는 ‘방법’과 ‘경로’를 정확하게 이해해야만 찾을 수 있다.
■운영 수준이 낮은 IT조직
운영 수준이 낮은 IT조직은, 개별 서버나 장비의 장애 대응에만 매몰되어 있다. 장애 발생과 사용자 입장의 ‘사용 불가’가 분리될 수 있는 개념인지를 이해하지 못한다. 이들 조직에서, IT서비스를 구성하는 장비들의 구조는 계획된 것이 아니라, 랜덤일 뿐이다. 따라서, 실패 단일점의 문제를 어디에서부터 풀어야 할지 난감할 수 밖에 없다. 이런 조직에서 가용성 얘기를 꺼내면, 장애를 잘 대응하고 있다는 말만 되풀이한다.
■현재의 실패 단일점 제거
실패 단일점을 제거하면, 사용자 입장에서의 가용성을 높을 수가 있다. 실패 단일점을 제거하기 위해서는, 먼저 IT서비스에 내재되어 있는 실패 단일점을 찾아내야 한다. 이를 위해서는, IT서비스를 지원하는 IT 구성항목의 관계를 그려내야 한다.
조직내에 IT 구성항목의 관계를 잘 아는 사람이 없거나, 자리를 옮긴 경우도 많이 있다. 집에라도 쫓아가서, 물어볼 필요가 있다. 그렇지 않다면, 말이 없는 IT구성항목들과 오랜 시간 씨름할 각오를 해야 한다. 찾아낸 실패 단일점들에 대해서는 제거할 수 있는 방안을 찾아야 한다. 그런데, 실패 단일점을 제거하는 데는 적지 않은 비용이 들 수 있다.
실패단일점을 제거하는 데 드는 ‘비용’과, 사용자 중단의 ‘피해’를 비교해서, 실패 단일점 제거가 이익이 된다는 것을 입증해내는 노력도, 당연히 필요하다.
■미래의 실패 단일점 제거
현재의 실패 단일점들은, 과거의 IT프로젝트들이 낳은 ‘밉둥이’들이다. 따라서, 현명한 IT조직에서는 IT프로젝트 초기 단계에서부터, 실패 단일점을 고려한 가용성 분석을 실행한다. 이런 IT조직들은 가용성의 수준이, IT에서 ‘자생’한 것이 아니라, 비즈니스와 사용자의 ‘필요’에서부터 온 다는 것을 잘 알고 있다.
그래서, ‘필요’의 높이에 맞는 IT 가용성의 수준을 균형있게 뽑아낸다. 이 과정에서, 실패 단일점들이 제거되게 된다.
■실패 단일점과의 공생
실패 단일점들을 찾아내더라도, 비용이나, 기술적인 문제로 제거할 수 없는 것들이 존재한다. IT조직이 공생해야 하는 실패 단일점들에 대해서는 ‘선택과 집중’이라는 카드를 빼들 수밖에 없다. 실패 단일점들을 집중적으로 관리해야 한다는 것이다.
IT조직이 수행하는 모니터링이나 예방 활동들은, IT조직내에 발생할 수 있는 잠재적인 장애들이 실패 단일점들을 ‘만나지 않도록’ 해주는 데 초점을 맞출 필요가 있다. 이전에는 실패 단일점이 아니었더라도, IT구성요소의 변화에 의해, 실패 단일점으로 변신할 수 있는 경우도 있다.
이런 실패 단일점들이 존재하는 지를 확인하기 위해서는, 정기적으로 실패 단일점을 찾는 활동을 꾸준하게 수행하는 수 밖에 없다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
