Monitoring
IT 서비스에 장애가 없으면 좋겠지만 장애가 발생하지 않는 IT 서비스는 존재하지 않습니다. "우리 회사의 서비스는 장애가 난적이 없습니다." 라고 누군가 당당히 말한다면 그것은 "우리 회사에는 실패를 경험한 사람이 한명도 없습니다." 라고 이야기 하는 것과 동일합니다. 실패를 경험하고 극복하는 과정에서 좋은 회사가 되는 것처럼 IT 서비스 또한 성장 과정에서 장애를 경험하고 극복하는 과정이 필요합니다.
다시 말해 우리의 인생에서 실패를 빼놓을 수 없듯이 IT 서비스에서 장애를 없앨 수 없으므로 우리는 장애를 어떻게 관리할 지 고민해야 합니다. 그런 의미에서 Micro Service Architecture는 매우 중요한 의미를 가집니다.
Micro Service Architecture는 대규모 소프트웨어 개발에 적용하기 위한 것으로 단독으로 실행 가능하고 독립적으로 배치될 수 있는 작은 단위로 기능을 분해하여 서비스하는 것입니다. MSA의 특징은 작은 단위로 분할 할 때 수평 방향의 계층적 절단이 아니라, 수직 방향의 기능별 절단을 사용한다는 것입니다. 이런 Micro Service Architecture가 장애 관리에 있어서 중요한 것은 MSA가 독립적으로 실행되도록 구성되어 있어 장애의 확산을 막아 준다는 것입니다. 반면 MSA를 도입하면서 생기는 문제는 서비스 별로 작은 장애들이 많이 발생한다는 것입니다. MSA를 도입한 많은 기업들이 이 부분에 대해 매우 조심스럽게 생각하곤 하는데요. 장애 관리차원에서 생각한다면 "장애 - 모니터링 - 반응 - 학습 - 공유" 이라는 과정을 통해 조직이 한단계 성장할 수 있는 기회라고 볼수 있습니다.
장애 예방보다는 장애 관리에 초점을 맞추는 것이 중요하다고 말씀드렸는데요. 극단적인 사례로 넷플릭스가 있습니다. 넷플릭스는 서비스에 미친 원숭이를 풀어놓는 일을 하기 도 합니다. 이 미친 원숭이는 근무시간에만 돌아다니며 서비스를 망치는데요. 깃허브에 프로젝트가 Chaos Monkey 라는 이름으로 공개되어 있습니다. 넷플릭스가 이런 환경을 마련하는 이유는 장애를 겪지 않은 조직은 대규모 장애와 마주하게 되기 때문입니다.
Micro Service Architecture는 장애의 발생 여지가 높지만 장애의 규모 또한 서비스의 격벽에 한하기 때문에 장애 관리 면에서 좋은 아키텍처라고 이야기 했습니다. 하지만 장애의 빈도가 높아지기 때문에 Micro Service Architecture를 도입하는데 가장 중요한 요소는 장애를 대하는 문화입니다. 왜냐하면 Micro Service Architecture가 기존 아키텍쳐보다 더 많은 장애를 발생시키는 상황에서 장애를 발생시킨 조직이나 사람을 문책하기 시작하면 조직은 더욱 움츠려 들고 서로 비판하고 견제하는 분위기가 만들어 지기 때문입니다. 그렇기 때문에 Micro Service Architecture를 도입하게 되면 장애를 학습하는 문화를 만들어 가는 것이 매우 중요합니다. 장애가 발생하면 "모니터링 - 반응 - 학습 - 공유" 하는 프로세스를 만들어 가야 합니다.
관련 자료