Sixth Man

마이클 조던과 시카고 불스는 농구 역사에 전설로 남아있다. 같은 팀이었던, 스코티 피펜, 데니스 로드맨 또한 유명하다. 5명이 한 팀으로 출전하는 농구 경기에서 뛰어난 선수가 3명이나 있다는 것은 매우 놀라운 일이다. 그래서 시카고 불스는 엄청난 기록을 세우며 전설이 되었다. 여기서 시카고 불스 팀이 세운 경이로운 기록이 단 한 번의 경기에만 그친 것이 아니라는 것에 주목해 볼 필요가 있다. 각자 개성도 뚜렸했지만 실력도 좋았다. 하지만, 5명의 주전 선수만으로는 모든 시즌 경기를 소화할 수 없다. 시카고 불스가 시즌을 우승하기 위해서는 전설적인 선수도 필요하지만, 장기전을 끌어가기 위한 예비 선수도 필요하다. 교체 선수가 존재하지 않았다면, 주전 선수에게 부상이 발생했을 때 교체 선수가 없다면 팀에 큰 부담이 된다. 한 경기는 이길 수 있을 지 몰라도 장기전을 끌고 갈 수는 없다.

농구 경기의 대체선수를 부르는 여섯 번째 선수(Sixth Man)는 농구의 주전 선수 5명 외에 체력 안배와 비상 상황을 대비한 후보 선수 또는 교체 선수를 의미하는 말이다. 코트를 누비며 경기에 임한 5명만큼 중요하기 때문에 별칭으로 부르고 있다. 우리는 시카고 불스의 교체 선수에 대해서는 잘 기억하지 못한다. 주전 선수들만큼 빛나지 못했다. 그러나 주전 선수들과 호흡을 맞추어 강도높은 훈련을 함께 소화하고, 언제 생길 지 모르는 팀의 위기를 위해 항상 긴장을 늦추지 않고, 팀이 위기에 처했을 때 바로 투입되어 경기의 흐름이 끊어지지 않도록 하는 매우 중요한 일을 했다. 예전부터 복원력(Resilience)을 설명하기 위해서 농구의 여섯 번째 선수를 자주 예시로 들었었다. 마치 교체 선수가 빠르게 투입되어 경기가 진행되도록 만드는 것과 같이 복원력은 분산 시스템에서 발생 가능한 여러 문제에 대해 즉시 대체제를 투입하여 시스템의 연속성과 지속성을 유지 하는 방법이기 때문이다.

복원력은 어려운 상황에서 빠르게 복구하는 능력을 말한다. 또한 원래 상태로 되돌아오기 위한 탄력성을 의미한다. 복원력으로 번역할 수 있는데, 보다 쉽게 이해하려면 오뚝이를 생각해 볼 수 있다. 오뚝이는 쓰러지지만, 다시 원래 위치로 돌아오려고 노력한다. 쓰러트려도 다시 원래의 위치에 오려고 움직인다. 세게 넘어트릴수록 더욱 세차게 되돌아 온다. 복원력은 분산 시스템에 문제가 생겨서 작동이 멈추는 상황이 발생했을 때 빠르게 교체 선수를 투입하여 대응하는 것이며, 전체 시스템의 입장에서는 약간 휘청 거렸지만 곧 안정 상태로 돌아오는 것을 말한다. 오뚝이는 분산 시스템 복원에 대한 꽤 괜찮은 비유가 될 수 있다. 복원력을 위해 여러 데이터 센터에 데이터를 복사했고, 복구가 필요한 상황이 되었다고 상상해 보겠다. 복구 해야 할 데이터가 많을 수록 새로운 디스크에 데이터를 다시 옮기는 시간이 비례해서 증가할 것이다. 노트북의 디스크에 있는 자료를 새로운 디스크에 옮기는 것 시간을 상상해 보면 데이터가 많은 수록 복사 시간이 오래 걸린다는 것을 쉽게 알 수 있을 것이다. 이러한 문제를 해결하기 위한 방법은 몇 가지가 있겠지만, 1/ 먼저, 복구 대상을 줄여야 한다. 마이크로서비스 아키텍처(Microservices Architecture)^[각주:1] 또는 셀기반 아키텍처(Cell-based Architecture)^[각주:2]를 통해서 문제 발생 시 영향도를 최소화 해야 한다. (자동)복구해야할 시스템의 범위를 줄여서 장애 전파를 격리하고, 복구해야할 데이터의 크기를 줄여 복구 시간을 줄이는 것이 중요하다. 그리고 2/ 자동 복구되도록 시스템을 설계해야 한다. 컴퓨팅과 스토리지는 각각 다른 특성을 갖고 있는데, 컴퓨팅은 상태정보를 갖지 않도록 설계하여 의존성에 구애받지 않고 정해진 절차에 맞춰 자동 복구하도록 만들고, 스토리지는 알고리즘에 따라 자동으로 데이터를 복제하도록 설계한다. 특히 데이터의 일관성을 유지하면서도 데이터 복구 시간을 줄이기 위해서 처리해야할 데이터의 사이즈를 최대한 작게 만들어야 한다. 모든 종류의 데이터가 다 들어가 있는 관계형 데이터베이스의 테이블을 수정하거나, 디스크 교체를 하는 것은 매우 어려운 일이지만, 작은 사이즈의 관계형데이터베이스의 정보를 다른 데이터베이스로 옮기거나 NoSQL 데이터베이스의 저장소 크기를 늘리는 것은 상대적으로 쉽다. 복사하기/붙여넣기와 같은 간단한 명령이라도 복사해야할 데이터의 크기와 작업 시간이 비례하는 것을 떠올려 보면 너무 당연한 결과이다.^[각주:3] 그리고, 3/ 시스템들을 메시지 브로커 같은 것을 활용하여 느슨하게 연결하도록 만든다.
 
복원력을 가진 시스템은 의존성을 분리하여 비동기 처리 할 수 있고, 데이터는 지속적으로 복제하여 자동 복구가 가능하다. 그리고 느슨한 결합을 통하여 장애 전파 격리, 자율적인 대응이 가능하다. 오뚝이가 세게 넘어트릴수록 크게 휘청거리며 원래 모습으로 돌아오려는 속성을 이해하고 오뚝이를 살짝 넘어트리는 것처럼, 분산 시스템에서 발생할 수 있는 장애의 영향 범위(Blast radius)^[각주:4]를 최소화하는 아키텍처를 채택할 필요가 있다.
 

1. the capacity to recover quickly from difficulties; toughness.
2. the ability of a substance or object to spring back into shape; elasticity.

 
이 처럼 복원력^[각주:5]이 강한 아키텍처를 구축하는 프로젝트 이름으로 Sixth Man을 늘 생각하고 있다. 물론 DevOps, SRE, Chaos Engineering도 같은 목적의 매우 매력적인 이름이기 때문에 어떠한 것을 사용해도 상관 없다. 안정적이고 지속적인 서비스 운영을 위한 복원력 기술이 반영되기만 하면 된다.

---

 

1. https://martinfowler.com/articles/microservice.html [본문으로]
2. https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/ [본문으로]
3. 마이크로서비스 아키텍처가 서비스 사이의 의존성을 줄여서 영향도를 최소화하는 것도 있지만, 각 서비스 특성에 맞게 데이터 저장소를 별도로 가져가면 처리해야하거나 복구해야 할 데이터 사이즈가 작아지기 때문에 유지보수가 쉬워지는 장점도 있다. [본문으로]
4. https://en.wikipedia.org/wiki/Blast_radius [본문으로]
5. 복원력 보다는 회복 탄력이라는 번역을 더 좋아한다. 동적인 행동을 더 강조하기 때문이다. [본문으로]