The Antifragile Organization 리뷰

Embracing Failure to Improve Resilience and Maximize Availability

 

서론

 

사람이 만든 하드웨어나 소프트웨어는 failure가 필연적으로 발생할 수 밖에 없고, 이로 인해 cloud를 운영하는 입장에서 예측 불가능한 문제 상황들이 발생함에도 불구하고 어떻게 신뢰할만한 높은 가용성의 서비스를 제공할 수 있을까

 

-시뮬레이션이나 이론적인 분석을 통해서는 한계점이 명확

 

-단위 테스트나 통합 테스트를 잘 짜서 테스트 하는 방식이 있음

이 방식의 경우 large-scale distributed 시스템에서의 자체 회복 능력을 구현하기엔 불충분함. 이러한 시스템을 커버하기 위한 테스트 케이스 작성에 드는 노력보다 오히려 그냥 시스템을 구축하는 노력이 적게 들 수 있음.

 

-failure induction이 또 다른 방법임. 실패를 유도한다는 뜻으로 시스템이 어느정도 failure에 대한 복원력이 갖춰졌다고 가정했을때 오히려 상황을 컨트롤 아래에 둘 수 있는 수준으로 만들게 된다.

 

-resilience란

시스템의 일부분이 failure가 발생해도 전체 시스템이 죽지 않는 일종의 저항력이 resilience임.

예를 들어 개인적으로 영화를 추천해주는 서비스 부분이 fail나면, 그냥 일반적인 모든 사람들에게 추천하는 list를 제공하는 방식도 포함

 

-resilience를 증가시키는 2가지 방법

1. redundancy와 fault tolerance를 고려하여 application 생성

redundancy는 여기서 실행 유닛을 중복되게 두는 것을 의미

 

2. 실패를 야기함으로써 불확실성을 줄임

실패를 유도하고 발생한 실패의 재발을 막기

어떠한 부분에서 실패가 발생하는지를 확인하고 실패가 발생할 수 있을 영역에 대해서 생각해보는 과정에서 전체 시스템에 대한 이해도가 올라가게 됨.

 

THE SIMIAN ARMY

 

실패를 일부로 유도함으로써 시스템을 관리하는 방법의 여러 가지 옵션들

 

-GameDays

화재 대피 훈련과 같이 시뮬레이션을 통한 방식

 

-engineer failure to occur in the live environment

좀 더 자동화된 더 짧은 주기로 진행가능한 방식

자동화된 agents를 시스템상에 풀어서 실패를 유도함

 

-CHAOS MONKEY

public cloud 환경에서 일어날 수 있는 가장 흔한 failure는 vm의 실패임.

파워, disk, network등의 문제로 서비스 제공에 문제가 생길 수 있고 이러한 상황을 일부로 야기함으로써 service를 더 견고하게 할 수 있음

넷플릭스에서 이러한 시도를 처음했고, 사용자 트래픽과 관련된 virtual instance를 그냥 무작위로 종료시켜버렸음.

이러한 부분은 설정에 따라서 강하게 약하게 등 자동화된 처리에 따라 조절이 가능하다.

 

-CHAOS GORILLA

앞선 각각의 instance를 일부로 종료시키는 것으로는 전체 데이터 센터가 다운되는 상황을 대비할 수 없고 이러한 부분에 대한 대비책으로 Chaos Gorilla를 만들게 됨.

Chaos Gorilla는 전체 가용영역에 대해 아래 두가지를 시뮬레이션 함

-Network partition

인스턴스들은 계속 돌아가고 서로 통신이 가능하지만 zone바깥과의 통신이 단절된 상황

-Total zone failure

모든 zone안의 instance들이 불능상태에 빠짐

좀 더 큰 단위의 테스트이므로 자동적으로 이루어지지 않고 메뉴얼하게 이루어지지만 점차 자동화를 지향하는 방향성을 띄긴 함.

 

-CHAOS KONG

한 리전은 여러 data center(가용 영역)들로 이루어지고 이 데이터 센터들은 서로 분리되어 있음.

여러 가용영역에 복제본을 둠으로써 더 견고한 architecture를 가질 수 있음.

그러나 전체 리전이 통째로 다운되는 상황도 발생하긴 함. 이를 대비하기 위해 여러 글로벌한 리전에 걸쳐 배포할 수 있으며, CHAOS KONG을 통해 한 리전을 다 다운시켜보는 수준의 테스트를 목표로 NETFLIX는 노력중임.

 

-LATENCY MONKEY

일반적인 Chaos Monkey로는 더 이상 시스템에 영향을 주지 못할 때, 새로운 class의 failure가 등장하게 됨. 인스턴스가 그저 다운되어버리는 것은 파악하고 다른 것으로 대체하면 되지만, 인스턴스가 나사가 빠진 상태지만 동작은 하고 있는 상황인 것도 detect할 수 있어야 하는 것으로 어려움.

이러한 경우 서비스가 종종 정상적으로 동작하는 듯이 보이지만 지연시간이 늘어나는 등의 문제점이 발생할 수 있음.

Netfilx는 일부로 restful client-server communication layer에 인공적인 딜레이를 넣어서 이러한 상황을 만들어냈음.

 

MONKEY TRAINING AT NETFLIX

 

사용자에게 이러한 monkey들을 소개할 때 NETFLIX가 문제를 최소화하기 위해 밟는 단계들

 

1.원숭이를 테스트 환경에 풀고, 사용자의 경험을 관찰하고 문제가 보이면 재발을 방지하기 위해 코드 수정

2.한 원숭이가 더 이상 환경에 문제를 일으키지 않아야만 비로소 새로운 원숭이를 투입할 수 있으며, 원숭이는 한 환경을 졸업하고 다른 환경에 또 투입되는 식으로 몇 달동안 운영됨

3.많은 환경에서 졸업하게 되면 이제 opt-out리스트를 제외한 모든 서비스에 투입되게 됨

4.점차 opt-out 리스트에 담겨있는 서비스를 줄여나가면서 발전시킴

 

THE IMPORTANCE OF OBSERVABILITY

 

지속적으로 관찰하고 알람을 통해 상태를 알리는 monitoring은 failure induction과 resilience의 관점에 있어서 2가지 이유 때문에 매우 중요하다

 

1.인위적으로 만들어내는 실패상황(앞전의 monkey들)이 자동화되어 돌아가고 있을 것이지만, 실제 의도치 않은 사용자에게 피해를 입히는 상황이 닥치면 인위적인 상황은 즉각 중단할 수 있어야 하기 때문에 monitoring이 중요하다.

2.resilient system을 구축하기 위해선 시스템의 깊고 내부적인 요소까지 이해하고 왜 fail이 일어나는지를 이해해야 하는데, monitoring은 이러한 깊은 이해에 도움을 줄 수 있다.

추가적으로 monitoring시에 일어나는 시스템에게로의 변화는 모두 기록(record)되어야 한다.

이를 통해 시스템의 상태를 이전으로 돌리는 것도 쉽게 가능해진다.

 

THE ANTIFRAGILE ORGANIZATION

 

resilience는 단순히 failure를 견뎌내는 힘이라면, 이보다 더 높은 목표는 failure를 통해 시스템이 더욱 더 강해지고 나아지는 것이며 이를 antifragile이라는 용어로 표현하고 있음.

 

넷플릭스는 아래와 같은 방법들로 더 antifragile한 방향으로 조직을 만들어내려고 노력함

 

1.’Every engineer is an operator of the service’, 즉 모든 엔지니어, 개발자는 서비스의 실행자이기도 해야한다는 것. DevOps와 연결되는 이야기이며 이렇게 직접 개발한 사람이 배포도 담당하는 시스템은 서비스의 위기 대처 능력을 높일 수 있음.

 

2.’Each failure is an opportunity to learn, generating these questions’, 마치 병사가 싸움을 참여할 수록 더 강해지는 것처럼 failure를 겪고 어떻게 더 빨리 잘 대처할 수 있을지에 대한 고민을 하게됨으로써 system이 더 견고해질 수 있음

 

3.’A blameless culture is fostered’, 즉 조직내에 탓하지 않는 분위기를 형성한다. Netfilx에서는 실수가 나오지 않는 다면 혁신의 속도에 있어 충분히 빨리 가고 있지 않다고 이야기할 정도로 실수를 긍정적으로 바라본다.

 

CONCLUSION

 

Inducing failure, 즉 실패를 야기하는 방식은 시스템을 더 견고하게 만들고 그 서비스의 사용자들로 하여금 더 높은 가용성을 누릴 수 있게 함.