엔지니어링 철학: 베르너 보겔스(Werner Vogels)

핵심 요점

• 그의 핵심 원칙은 모든 것은 항상 고장 난다는 것이며, 따라서 고장을 막으려 설계하는 대신 고장을 전제로 설계한다는 것입니다. 2005년부터 Amazon의 CTO를 맡아 온 Werner Vogels는 무뚝뚝한 관찰 하나 – 충분히 큰 규모에서는 구성 요소의 고장이 끊임없이, 통계적으로 보장된다는 사실 – 를 설계 교리로 바꿔 놓았습니다. 모든 디스크, 서버, 네트워크 링크, 의존성이 고장 날 것이라고 가정하고, 고장을 막을 수 있는 척하는 대신 고장을 겪으면서도 가용성을 유지하는 시스템을 만드는 것입니다.¹⁶
• 그는 현대 NoSQL의 바탕이 된 아이디어를 개척한 Dynamo 논문의 공저자입니다. “Dynamo: Amazon’s Highly Available Key-value Store”(SOSP 2007)는 일관된 해싱, 벡터 클록, 느슨한 정족수, 가십 기반 멤버십, 그리고 최종 일관성을 항상 쓰기가 가능한 하나의 저장소에 담아냈고, Cassandra, Riak, Voldemort, 그리고 Amazon 자체의 DynamoDB에 직접적인 영향을 주었습니다.²³
• 그는 최종 일관성의 으뜸가는 전도사입니다. 그의 에세이 “Eventually Consistent”는 가용성 대 일관성의 맞교환을 명료하게 풀어냈습니다. 네트워크가 분할되면 – 그리고 큰 규모에서는 반드시 그렇게 됩니다 – 선택해야 하며, Dynamo는 모든 복제본이 합의할 때까지 차단하기보다 가용성을 유지하면서 곧 수렴하는 쪽을 택했습니다.⁴⁷
• 그는 엔지니어링 문화에 “you build it, you run it”(만든 사람이 운영한다)이라는 문장을 안겨 주었습니다. 2006년의 한 대화에서 그는 개발자가 프로덕션에서 자신의 서비스를 소유하는 – 범위를 정하고, 만들고, 그리고 운영하는 – Amazon의 모델을 설명했고, 만든 사람을 호출기 앞에 그리고 고객 앞에 세우는 것이야말로 품질을 끌어올린다고 주장했습니다.⁵

그 원칙

“Everything fails, all the time.”(모든 것은 항상 고장 난다) – Werner Vogels, Amazon CTO, 신뢰성 있는 분산 시스템 설계에 관하여⁶

대부분의 엔지니어링은 모든 것이 잘 돌아가는 경우에 맞춰 최적화됩니다. 정상 경로를 만들고, 상상할 수 있는 몇 안 되는 오류를 처리하고, 출시합니다. 이 본능은 큰 규모에서 운영하기 직전까지는 살아남습니다 – 그리고 그때 그것은 당신을 배신합니다. 수십만 대의 기계를 운영할 때 “드문” 일은 더 이상 드물지 않습니다. 드라이브당 3년에 한 번 일어나는 디스크 고장이 당신의 플릿 어딘가에서 몇 분마다 일어납니다. 백만 개에 한 개 패킷을 떨어뜨리는 네트워크 링크가 하루에 수백만 개의 패킷을 떨어뜨립니다. Vogels의 가장 유명한 문장은 이것을 네 단어로 압축합니다. 모든 것은 항상 고장 난다.⁶ 고장은 우회 설계해야 할 예외가 아닙니다. 큰 규모에서 그것은 당신이 대비해 설계해야 하는 정상 상태의 조건입니다.

뒤따르는 원칙은 통상적인 원칙의 뒤집음입니다. 고장을 막을 수 없다면 – 그리고 큰 규모에서는 증명 가능하게 막을 수 없습니다 – 막는 것은 잘못된 목표입니다. 올바른 목표는 무언가가 고장 나는 동안에도 가용성을 유지하는 것입니다. 그래서 모든 구성 요소가 죽을 것이라고 가정하고, 어느 하나의 죽음이든 견딜 수 있도록 설계합니다. 하나의 손실이 보이지 않도록 데이터를 여러 기계에 복제하고, 고장 난 의존성이 시스템 전체를 무너뜨리는 대신 한 기능만 저하시키도록 서비스를 API 뒤로 분리하며, 어느 한 결함이든 블래스트 반경을 최소화하여 전체가 다운되지 못하게 합니다. 시스템은 고장 사례를 피하도록 만들어진 것이 아니라, 고장 사례가 지루하도록 만들어진 것입니다.¹⁶

이 원칙에는 두 번째 절반이 있으며, 그것이 첫 번째 절반을 실현시킵니다. 네트워크가 분할될 수 있게 되는 순간 완벽한 일관성과 완벽한 가용성을 동시에 가질 수는 없으므로, 선택해야 합니다 – 그리고 Vogels는 가용성을 택했습니다. 네트워크 분할이 복제본들을 서로 끊어 놓을 때, 시스템은 모두가 합의할 때까지 답변을 거부하거나(일관적이지만 가용하지 않음) 가진 것으로 계속 답하면서 나중에 화해할(가용하지만 잠시 비일관적) 수 있습니다. Amazon의 장바구니에서 답변 거부는 받아들일 수 없었습니다 – 분할 중에 “장바구니에 담기”를 거부하는 장바구니는 판매를 잃는 장바구니입니다.⁴ 그래서 Dynamo는 항상 쓰기를 받아들이고 복제본들이 나중에 수렴하게 합니다. 그 대가는 서로 다른 복제본이 서로 다른 답을 돌려줄 수 있는 짧은 시간 창이고, 그 보상은 고객에게 결코 “안 됩니다”라고 말하지 않는 시스템입니다. 그 맞교환 – 모두가 합의할 때까지 차단하기보다 가용성을 유지하면서 곧 수렴하는 것 – 이 바로 최종 일관성이며, Vogels는 그것이 큰 규모에서 올바른 맞교환이라고 평생 주장했습니다.⁴⁷

배경

Werner Vogels는 1958년 10월 3일 네덜란드 에르멜로에서 태어났습니다.¹ 컴퓨팅으로 가는 그의 길은 명문 대학을 거치는 전형적인 직선이 아니었습니다. 그는 헤이그 응용과학대학교에서 컴퓨터 과학을 공부해 1989년에 마쳤고, 한참 뒤에야 암스테르담 자유대학교에서 컴퓨터 과학 박사학위를 받았습니다 – 2003년의 그의 학위 논문 “Scalable Cluster Technologies for Mission Critical Enterprise Computing”은 Henri Bal과 Andrew Tanenbaum이 지도했으며, 후자는 분산 시스템과 운영체제 분야의 토대를 놓은 인물 중 하나입니다.¹ 기억해 둘 만한 세부 사항은 그 박사학위가 실제 시스템 작업의 수년에 앞선 것이 아니라 뒤따랐다는 점입니다. 이론이 실천을 따라잡았습니다.

가장 형성적인 시기는 코넬 대학교에서 왔으며, 그곳에서 1994년부터 2004년까지 그는 확장 가능하고 신뢰성 있는 엔터프라이즈 시스템을 연구하는 연구 과학자였습니다.¹ 코넬에서 그는 Ken Birman의 분산 시스템 그룹 안에 있었습니다 – Isis와 신뢰성 있는 그룹 통신의 계보로, 기계 집합이 어떻게 합의하고, 일관성을 유지하고, 구성원이 고장 나고 복구되는 와중에도 계속 돌아갈 수 있는지를 물은 일련의 작업입니다. 그는 Birman, Robbert van Renesse와 함께 Reliable Network Solutions라는 회사를 공동 창업해 부사장 겸 CTO를 지냈습니다.¹ 이것이 Vogels가 자라난 지적 토양입니다. “어떻게 기계가 고장 나지 않게 할까”가 아니라 “기계의 집단이 그 구성원들이 고장 나는 동안에도 어떻게 올바르고 가용한 상태를 유지하는가”입니다. 훗날 그가 모든 것은 항상 고장 난다고 말했을 때, 그는 즉흥적으로 말한 것이 아니었습니다 – 그는 자신이 10년을 몸담은 신뢰성 있는 분산 시스템 전통의 창립 전제를 진술하고 있었습니다.

그는 2004년 9월 Amazon에 시스템 연구 디렉터로 합류했고, 2005년 1월 CTO로 임명되었으며, 2005년 3월 부사장 직함을 더했습니다 – 그 이후로 줄곧 맡아 온 역할로, 회사 전반의 기술 방향을 이끌고 있습니다.¹ 그의 합류는 Amazon이 현대의 클라우드를 발명하던 시기와 맞물렸습니다. Dynamo 저장 시스템이 이 시기에 만들어지고 정리되었으며, Amazon Web Services가 그 토대가 되는 서비스들을 출시했고, Vogels는 그 모든 것 아래 깔린 아키텍처 원칙들의 공개된 목소리가 되었습니다 – 고장을 전제로 설계하고, 서비스로 분리하고, 최종 일관성을 받아들이고, 서비스를 만드는 사람을 그 운영의 책임자로 세운다는 것이었습니다.²⁴⁵

그 작업

“Everything fails all the time”: 고장을 전제로 한 설계와 최종 일관성

여기서 시작합시다. 이것이 엔지니어링으로 구현된 그 원칙이기 때문입니다. 이 교리에는 두 가지 움직임이 있습니다. 첫 번째는 고장을 전제로 한 설계입니다. 모든 구성 요소를 반드시 고장 날 것으로 취급하고, 시스템이 그 손실을 견디게 만드는 것입니다. 그것은 곧 중복성(어느 한 사본이 사라져도 되도록 복제), 분리(서비스가 API를 통해 대화하여 병든 의존성이 연쇄 붕괴 대신 우아하게 저하), 그리고 블래스트 반경 봉쇄(결함이 퍼지는 대신 작은 셀 안에 갇히도록 시스템을 분할)를 뜻합니다.¹⁶ 설계의 시험대는 “모든 것이 건강할 때 작동하는가”가 아니라 “이 조각이 최악의 순간에 죽으면 어떻게 되는가”이며 – 그 답은 “시스템은 계속 서비스를 제공한다”여야 합니다.

두 번째 움직임은 큰 규모에서 높은 가용성을 가능하게 만드는 것입니다. 최종 일관성입니다. Eric Brewer의 CAP 관찰은 네트워크가 분할될 때 분산 시스템이 완벽하게 일관적이면서 동시에 완전히 가용할 수는 없다고 말합니다 – 하나를 포기해야 합니다.⁷ Vogels의 “Eventually Consistent”는 그 선택을 명시하고 대안을 정밀하게 정의합니다. 최종 일관성 아래에서 “저장 시스템은 객체에 새로운 갱신이 가해지지 않으면 결국 모든 접근이 마지막으로 갱신된 값을 돌려준다는 것을 보장합니다.”⁴ 결국이라는 단어가 그 맞교환의 전부입니다. 가용성을 강조하는 시스템은 “항상 쓰기를 받아들일 수 있지만, 특정 조건에서는 읽기가 최근에 완료된 쓰기의 결과를 반영하지 않습니다.”⁴ 짧고 한정된 시간 창 동안 두 복제본이 서로 다를 수 있지만 – 어느 쪽도 결코 답변을 거부하지 않습니다. 수렴은 배경에서 일어나고, 사용자는 결코 차단되지 않습니다.

엔지니어링으로서 왜 중요한가. 대부분의 개발자가 가진 데이터베이스의 정신 모델은 단일 기계의 것이며, 거기서는 사본이 하나뿐이므로 쓰기가 이후의 모든 읽기에 즉시 보입니다. 그 모델은 큰 규모에서 살아남지 못합니다. 사본 하나는 단일 장애점이고 기계 하나는 처리량의 천장이기 때문입니다. 복제하는 순간 – 가용성을 위해서는 반드시 그래야 합니다 – 사본들이 따라잡는 동안 읽는 사람이 무엇을 보는가 하는 문제를 물려받게 됩니다. Vogels의 기여는 이것이 숨겨야 할 버그가 아니라 신중하게 선택해야 할 설계 차원이라고 주장한 것이며, 엔지니어에게 어휘 – 자기 쓰기 읽기, 단조 읽기, 세션 일관성 – 를 주어 주어진 워크로드가 실제로 얼마만큼의 일관성을 필요로 하는지 정확히 고를 수 있게 한 것입니다. 모든 곳에서 가장 강한 보장의 값을 치르는 대신에 말입니다.⁴

Dynamo 논문과 NoSQL 운동

그 원칙에는 정전과도 같은 산물이 있습니다. “Dynamo: Amazon’s Highly Available Key-value Store”로, Vogels가 공저했으며 이 분야 최고의 운영체제 학회인 SOSP 2007에서 발표되었습니다.² Dynamo는 구체적이고 가혹한 요구에 대한 Amazon의 답이었습니다 – 장바구니는 데이터센터 분할과 디스크 고장 중에도 항상 쓰기를 받아들여야 했는데, 가용하지 않은 장바구니는 곧장 매출을 잃기 때문입니다.²³ 강한 일관성에 맞춰 튜닝된 전통적인 관계형 데이터베이스는 분할 아래에서 그것을 약속할 수 없었습니다. 그래서 Amazon은 일관성을 가용성과 맞바꾼 저장소를 만들고 그 방법을 정확히 적어 두었습니다.

Dynamo는 분산 시스템 기법들을 항상 쓰기가 가능한 하나의 탈중앙화 시스템으로 조립한 카탈로그이며, 이 논문의 영향력은 그 기법들을 얼마나 깔끔하게 펼쳐 보였는가에서 나옵니다.²³ 일관된 해싱은 데이터를 노드들에 분할하여 링이 모든 것을 다시 섞지 않고도 커지거나 작아질 수 있게 합니다 – “점진적이고, 어쩌면 선형적인 확장성”입니다.³ 벡터 클록은 각 값의 인과 이력을 추적하여 동시 쓰기가 조용히 사라지는 대신 감지될 수 있게 합니다. 느슨한 정족수와 힌트 핸드오프는 일부 복제본에 닿을 수 없을 때에도 시스템을 쓰기 가능한 상태로 유지하며, 정당한 노드가 돌아올 때까지 임시 대역에 쓰기를 맡겨 둡니다. 머클 트리를 이용한 안티 엔트로피는 복제본들이 그 차이를 효율적으로 찾아내고 고칠 수 있게 합니다. 가십 기반 멤버십은 노드들이 중앙 조정자 없이 서로를 알고 고장을 감지하게 합니다 – 이 설계는 의도적으로 대칭적이고 탈중앙화되어 있어, “Dynamo의 모든 노드는 그 동료들과 같은 책임 집합을 가져야 한다”는 것이며, 이는 곧 죽음이 치명적인 특별한 노드가 없다는 뜻입니다.³ 이 선택들 하나하나는 같은 주인을 섬깁니다. 무언가가 고장 날 때 가용성을 유지하는 것입니다.

Amazon은 Dynamo의 코드를 결코 공개하지 않았지만, 논문이 그 일을 해냈습니다 – 그것은 그 10년에서 가장 영향력 있는 시스템 논문 중 하나, NoSQL 운동의 지적 씨앗이 되었습니다.³ Apache Cassandra, Riak, Project Voldemort는 모두 리더가 없고 최종 일관적인 그들의 설계를 그것에 직접 거슬러 추적합니다.³ 그리고 그 이름은 Amazon DynamoDB로 상업적으로 살아남았는데, 이는 내부적으로는 다른 엔지니어링 선택(Dynamo의 순수한 리더 없는 모델이 아니라 단일 리더 복제)을 했음에도 Dynamo의 원칙 위에 지어졌습니다.³ Dynamo의 영향이 주는 교훈 자체도 새겨 둘 만합니다. Amazon의 경쟁적 해자는 코드가 아니라 명료함이었습니다. 어떤 보장을 포기했고 왜 그랬는지 정확히 설명함으로써, 그들은 한 세대의 엔지니어에게 그 맞교환을 어떻게 추론하는지 가르쳤습니다.

AWS, 서비스 지향, 그리고 “you build it, you run it”

Dynamo는 저장 시스템입니다. 더 깊은 Vogels의 기여는 아키텍처적이고 문화적입니다. Amazon의 플랫폼은 오직 API를 통해서만 대화하는 독립적인 서비스들의 그물로 지어져 있습니다 – 커튼 뒤로 손을 뻗는 공유 데이터베이스도, 숨겨진 결합도 없습니다.⁵ 이 규율은 고장에 중요합니다. 서비스들이 단단한 인터페이스 뒤로 분리되어 있으면, 고장 난 하나는 그것이 떠받치는 특정 기능을 저하시킬 뿐 그것에 닿은 모든 것의 데이터를 망가뜨리거나 스레드를 멈춰 세우지 않습니다. 서비스 지향은 아키텍처로 표현된 블래스트 반경 봉쇄입니다. 그것은 또한 AWS를 가능하게 만든 것이기도 합니다 – 일단 내부 시스템이 깨끗하고 API로 주소를 지정할 수 있는 서비스가 되면, 그것을 제품으로서 바깥 세상에 노출하는 것은 자연스러운 다음 단계입니다.

문화적 절반은 Vogels가 “모든 것은 항상 고장 난다”만큼이나 자주 인용되는 문장입니다. “you build it, you run it”(만든 사람이 운영한다). 2006년 Jim Gray와의 대화에서 그는 각 서비스가 그것을 만든 팀에 의해 처음부터 끝까지 소유되는 Amazon의 모델을 설명했습니다. “각 서비스에는 그것과 연관된 팀이 있고, 그 팀이 그 서비스에 대해 완전히 책임을 집니다 – 기능의 범위를 정하는 것에서, 그것을 설계하고, 만들고, 운영하는 것까지.”⁵ 그리고 그 근거는 명시적으로 소유를 통한 품질에 관한 것이었습니다. “당신이 만들면, 당신이 운영합니다. 이것은 개발자를 자기 소프트웨어의 일상적 운영과 접촉하게 만듭니다. 또한 그들을 고객과의 일상적 접촉으로 데려옵니다.”⁵ 코드를 던져 넘길 벽이 없습니다. 서비스를 작성한 엔지니어가 그것의 호출기를 듭니다. 그 효과는 단단한 피드백 루프입니다 – 취약점을 가장 잘 고칠 수 있는 사람이 새벽 3시에 그 고통을 느끼는 사람이고, 그 기능을 설계한 사람이 고객의 불만을 직접 듣습니다. 여기서 소유는 인사 표어가 아닙니다. 그것은 신뢰성 메커니즘입니다. 자기가 만든 것을 운영하는 팀은 고장을 전제로 설계합니다. 고장이 그들을 깨우기 때문입니다.

클라우드 전도하기: 블래스트 반경, 셀, 그리고 잘 설계된 시스템

Vogels의 네 번째 작업 묶음은 하나의 산물이라기보다 지속된 역할입니다. 20년 동안 그는 클라우드를 어떻게 만드는지뿐 아니라 클라우드 위에서 어떻게 만드는지를 성문화한 아키텍트 겸 전도사였습니다.¹⁶ 되풀이되는 주제들은 점점 더 큰 범위에 적용된 그 원칙입니다. 블래스트 반경을 최소화하라. 결함이나 잘못된 배포, 또는 독이 든 요청이 모든 고객이 아니라 고객의 한 조각에만 봉쇄되도록 시스템을 독립적인 셀들로 분할하십시오. 공격적으로 분리하라. 느린 의존성 하나가 호출 경로 전체를 멈춰 세우는 긴밀한 동기 사슬보다, 명시적 계약을 가진 비동기적이고 느슨하게 결합된 서비스를 선호하십시오. 복구를 자동화하라, 문서화하지 말고. 사람이 필요한 런북은 그 사람이 잠들어 있을 때 실행되지 않습니다. 고장을 시험 입력으로 받아들여라. 시스템이 고장을 견디기를 바라는 대신 의도적으로 결함을 주입해 견딘다는 것을 증명하십시오. 이들 각각은 운영 관행으로 바뀐 “모든 것은 항상 고장 난다”입니다 – 강연과 글, 그리고 수년 뒤의 두 번째 ACM 대화에 걸쳐 되풀이된 일관된 메시지로, 회복력은 데모가 작동한 뒤에 덧붙이는 층이 아니라 첫 줄부터 설계해 넣는 속성이라는 것입니다.⁶

그 방법

Dynamo, 최종 일관성, 서비스 지향, 그리고 “you build it, you run it”를 가로질러 읽으면 같은 다짐들이 되풀이됩니다. Vogels의 방법은 표어라기보다 한 묶음의 상시적 습관입니다.

고장 사례를 먼저 설계하라. 큰 규모에서 고장은 예외가 아니라 정상 상태이므로, 질문은 결코 “이것이 작동하는가”가 아니라 “이것의 각 조각이 죽으면 어떻게 되는가”입니다.⁶ 그 교훈은 Amazon의 규모를 한참 넘어 전이됩니다. 정상 경로를 쓰고 오류 처리를 덧대지 마십시오 – 고장 양태를 먼저 열거하고, 이미 그것들을 견디는 시스템에서 작동 경로가 흘러나오게 하십시오. 이는 신뢰성에 적용된 증거의 관문입니다 – “데모에서 작동한다”는 증거가 아니며, “요청 도중에 노드를 죽여도 가용성을 유지한다”는 것은 사람의 개입 없이 다시 수렴하는 네트워크에 Radia Perlman이 심어 넣은 자가 치유와 같은 기준입니다.

일관성을 물려받지 말고 선택하라. Dynamo에서 가장 깊은 움직임은 모든 읽기가 모든 이전 쓰기를 보아야 한다는 기본값을 거부한 것입니다. Vogels는 일관성을 워크로드마다 설정하는 다이얼로 만듭니다 – 올바름이 요구하는 곳에서는 강하게, 가용성이 더 중요한 곳에서는 최종적으로 – 그리고 시스템이 실제로 제공하는 보장이 무엇인지에 대해 정밀합니다.⁴⁷ 그 규율은 당신의 일관성 주장이 정확히 무엇에 기대고 있는지 알고, 워크로드가 필요로 하지 않는 보장의 값을 결코 치르지 않는 것입니다. 이는 Leslie Lamport가 분산 시간에 가져온 올바름에 대한 바로 그 정밀함입니다. 속성을 가정하지 말고, 정확히 정의하고 그것이 언제 성립하는지 알라.

블래스트 반경을 봉쇄하기 위해 분리하라. 단단한 API 뒤의 독립적인 서비스들은 고장이 연쇄하는 대신 일어난 자리에 갇힌다는 뜻입니다.⁵ 그 상시적 습관은 최악의 경우가 결코 다운된 시스템이 아니라 저하된 기능이 되도록 경계를 긋는 것입니다 – 모든 의존성에 대해 “이것이 고장 나면 구멍이 얼마나 큰가”를 묻고, 그 구멍을 작게 만드는 것입니다. 이는 최소한의 가치 있는 제품의 아키텍처적 형태입니다. 가장 깨끗한 경계는 정확히 자기 일만 하고 홀로 고장 나는 것입니다.

만든 사람이 운영을 소유하게 하라. “you build it, you run it”는 서비스를 설계한 사람을 그 호출기 앞에 세워, 취약점과 그것을 고칠 수 있는 사람 사이의 루프를 닫습니다.⁵ 그 교훈은 운영의 고통이 존재하는 가장 정직한 품질 신호라는 것입니다 – 프로덕션에서 격리된 팀은 회복력에 과소 투자하게 됩니다. 취약함의 비용이 다른 누군가에게 떨어지기 때문입니다. 소유는 신뢰성 메커니즘이며, 이는 조직도로 만든 품질만이 유일한 변수입니다. 품질을 보장하는 유일한 길은 그 부재의 대가를 만든 사람이 느끼게 하는 것입니다.

맞교환을 공개적으로 설명하라. Dynamo의 영향은 그 코드 – 결코 공개되지 않은 – 에서가 아니라 어떤 보장을 포기했고 왜 그랬는지 명료하게 진술한 논문에서 나왔습니다.²³ 그 습관은 추론을 읽을 수 있게 만드는 것입니다. 맞교환의 이름을 짓고, 당신이 택한 쪽을 정당화하고, 다음 엔지니어에게 결과를 맹목적으로 모방하는 대신 그것을 추론하도록 가르치십시오. 왜에 대한 명료함이 설계가 그 저자보다 오래 살아남게 합니다 – 수십 년 뒤에도 Perlman과 Lamport의 논문을 가르칠 만하게 만든 바로 그 설명의 규율입니다.

영향의 사슬

그를 빚은 사람들

Ken Birman과 코넬의 신뢰성 있는 분산 시스템 전통. 코넬에서의 10년, Birman의 그룹과 Isis/신뢰성 있는 그룹 통신 계보 안에서 보낸 시간이 그의 창립 전제의 원천입니다.¹ 그 전통의 핵심 질문 – 기계의 집단이 그 구성원들이 고장 나고 복구되는 동안 어떻게 올바르고 가용한 상태를 유지하는가 – 이 바로 “모든 것은 항상 고장 난다”가 답하는 질문입니다. 그는 표어를 만든 것이 아니라, 자기 분야의 제1원리를 행성 규모의 청중을 위해 다시 진술한 것입니다. (형성적 영향)

Andrew Tanenbaum과 분산 시스템 학계. 그의 자유대학교 박사학위는 일부분 Tanenbaum이 지도했으며, 그는 운영 및 분산 시스템 분야의 토대가 되는 스승 중 하나입니다.¹ 그 바탕이 드러납니다. Dynamo는 분산 시스템 정전의 작동하는 종합처럼 읽힙니다 – 일관된 해싱, 벡터 클록, 정족수, 가십 – 문헌을 환히 꿰뚫은 누군가가 조립한 것입니다. (형성적 영향)

Eric Brewer와 CAP 맞교환. 최종 일관성에 대한 Vogels의 논거는 분할 내성 시스템이 일관성을 가용성과 맞바꿔야 한다는 CAP 관찰에 명시적으로 기댑니다.⁴⁷ Brewer는 그 불가능성을 틀 잡았고, Vogels는 Amazon의 규모에서 그 선택을 운영화하여 “가용성을 택하고 수렴하라”를 떳떳한 기본값으로 만들었습니다. (직접적 영향)

그가 빚은 사람들

NoSQL 운동 전체. Dynamo 논문은 Cassandra, Riak, Voldemort의 직접적인 조상이자 DynamoDB의 이름의 주인입니다 – 리더가 없고 최종 일관적인 그 설계 패턴은 2007년의 한 논문에서 한 세대 시스템의 데이터 계층으로 번져 나갔습니다.³

클라우드 네이티브 아키텍처와 DevOps 문화. “you build it, you run it”는 현대 DevOps의 창립 아이디어 중 하나가 되었습니다 – 전체 서비스 소유, 호출 대기 개발자, 그리고 개발/운영 벽의 해체는 모두 Vogels가 2006년에 설명한 모델에 직접 거슬러 올라갑니다.⁵

한 세대의 클라우드 아키텍트. AWS의 설계 원칙과 그의 지속된 전도를 통해, “고장을 전제로 설계하라”, “블래스트 반경을 최소화하라”, “서비스로 분리하라”는 엔지니어들이 클라우드 위에서 신뢰성 있는 시스템을 만드는 것에 대해 추론할 때 쓰는 기본 어휘가 되었습니다.⁶

관통하는 줄기

Vogels는 이 시리즈의 운영 규모 종석입니다 – 분산 시스템 이론을 가져다가 행성만큼의 기계 위에서 돌린 인물입니다. Leslie Lamport는 분산 시스템에 그 토대를 주었습니다. 시간, 순서, 합의를 어떻게 정밀하게 정의하는지, 그리고 참여자들이 고장 나거나 제멋대로 행동할 때 시스템을 어떻게 올바르게 유지하는지였습니다. Vogels는 그 토대가 블랙 프라이데이의 장바구니를 떠받쳐야 할 때 어떻게 보이는지입니다 – 일관성과 고장에 관한 같은 질문들이지만, 화이트보드 위가 아니라 실제 부하 아래, 가용성 유지에 실제 매출이 걸린 채로 답해졌습니다.⁴ 그리고 Radia Perlman은 고장 사례를 설계의 중심으로 취급하여 사람의 개입 없이 스스로 치유하는 네트워크를 만들었고, Vogels는 바로 그 본능 위에 서비스를 만들었습니다. 스택의 한 층 위에서 – 복제하고, 분리하고, 블래스트 반경을 봉쇄하고, 시스템이 스스로 수렴하게 하는 것입니다. Lamport가 올바름을 정의하고 그것이 고장을 견딤을 증명하라고 말하고 Perlman이 스스로 치유하도록 만들라고 말하는 곳에서, Vogels는 말합니다. 모든 것은 항상 고장 나므로, 그것을 막으려 하지 마라 – 시스템이 고장을 곧장 통과하며 가용성을 유지하도록 설계하고, 그것을 운영하는 만든 사람들이 모든 균열을 느끼게 하라. (시리즈 가교)

내가 여기서 얻는 것

Vogels에게서 내가 간직하는 교훈은 고장을 예외가 아니라 정상적인 경우로 취급하라는 것입니다. 대부분의 만드는 사람처럼 내 본능은 호출이 성공하고, 의존성이 답하고, 디스크가 거기 있는 경로를 쓰는 것입니다 – 그러고 나서 작동하면 try/catch를 덧대는 것입니다. “모든 것은 항상 고장 난다”는 그 질책입니다. 실제의 어떤 규모에서든 고장은 내 시스템에게 일어나는 드문 사건이 아니라, 내 시스템이 그 안에서 사는 끊임없는 조건입니다. 그래서 이제 무언가를 만들 때 – 동기화 작업, API 클라이언트, 큐 컨슈머 – 나는 마지막에 거기 닿는 대신 “무엇이 죽고, 그것이 죽을 때 나머지는 계속 서비스를 제공하는가”에서 출발하려 합니다. “작동한다”의 정직한 버전은 초록색 데모가 아니라, 요청 도중에 의존성을 죽이고 시스템이 쓰러지는 대신 우아하게 저하되는 것을 지켜보는 것입니다. 정상 경로만 견디는 시스템은 내가 아직 설계를 끝내지 않은 시스템입니다.

두 번째 교훈은 가용성과 일관성이 내가 일부러 해야 하는 맞교환이라는 것입니다. 둘 다 갖고 싶은 유혹이 있습니다 – 모든 읽기가 모든 쓰기를 보고, 그리고 시스템이 결코 안 된다고 하지 않는 것 – 그리고 단일 기계에서는 그럴 수 있습니다. 무언가를 복제하는 순간 그 편안함은 사라지며, Vogels의 규율은 습관적으로 모든 곳에 가장 강한 보장을 기본값으로 두는 대신 각 워크로드마다 일부러 한쪽을 택하는 것입니다. 내가 만드는 것 대부분은 읽기가 최신 쓰기를 즉시 반영할 필요가 없습니다. 그것은 고객을 결코 거부하지 않아야 합니다. 최종 일관성은 그것을 무서운 타협에서 정밀한 도구로 다시 틀 잡아 주었습니다. 읽는 사람이 얼마나 오래된 것을 견딜 수 있는지 정확히 이름 짓고, 그 여유로 가용성을 사고, 기능이 결코 필요로 하지 않았던 보장의 값을 그만 치르는 것입니다. 그 기술은 늘 가장 강한 약속에 손을 뻗는 것이 아니라 – 작업이 실제로 요구하는 약속이 무엇인지 아는 것입니다.

FAQ

“everything fails all the time”(모든 것은 항상 고장 난다)는 무슨 뜻인가요?

그것은 규모에 관한 힘들게 얻은 교훈을 압축한 Werner Vogels의 표현입니다. 충분히 많은 기계를 운영하면 구성 요소의 고장은 드문 예외이기를 멈추고 끊임없는, 통계적으로 보장된 조건이 됩니다.⁶ 한 대의 서버에서는 무시할 만큼 드문 고장 양태가 큰 플릿 어딘가에서는 끊임없이 일어납니다. 실용적 귀결은 통상적인 엔지니어링의 뒤집음입니다. 고장을 막으려 하는 대신, 모든 디스크, 서버, 링크, 의존성이 고장 날 것이라고 가정하고, 고장을 겪으면서도 가용성을 유지하는 시스템을 – 중복성, 분리, 봉쇄된 블래스트 반경을 통해 – 설계하여, 어느 한 결함이든 견딜 수 있고 이상적으로는 보이지 않게 합니다.¹⁶

Dynamo 논문이란 무엇인가요?

“Dynamo: Amazon’s Highly Available Key-value Store”는 Vogels가 공저한 2007년 SOSP 논문으로, 고장과 네트워크 분할 중에도 장바구니 같은 서비스를 쓰기 가능한 상태로 유지하기 위해 Amazon이 만든 저장 시스템을 설명합니다.²³ 그것은 분할을 위한 일관된 해싱, 동시 쓰기를 추적하기 위한 벡터 클록, 고장 아래에서 가용성을 유지하기 위한 느슨한 정족수와 힌트 핸드오프, 복구를 위한 머클 트리 기반 안티 엔트로피, 그리고 탈중앙화된 멤버십을 위한 가십을 결합했습니다 – 모두가 항상 쓰기를 받아들이고 나중에 화해하는 데 봉사합니다. Amazon은 그 코드를 결코 공개하지 않았지만, 논문은 NoSQL 운동에 토대가 되어 Cassandra, Riak, Voldemort, 그리고 Amazon DynamoDB에 직접 영향을 주었습니다.³

최종 일관성이란 무엇인가요?

최종 일관성은 Vogels가 옹호하고 그의 에세이 “Eventually Consistent”에서 정의한 완화된 일관성 모델입니다. “객체에 새로운 갱신이 가해지지 않으면, 결국 모든 접근이 마지막으로 갱신된 값을 돌려준다.”⁴ 복제된 시스템에서 쓰기는 일부 복제본에 다른 복제본보다 먼저 닿을 수 있으므로, 짧은 창 동안 서로 다른 복제본이 서로 다른 답을 돌려줄 수 있지만 – 어느 쪽도 결코 요청을 거부하지 않습니다. 시스템은 모든 복제본이 합의할 때까지 차단하는 대신 가용성을 유지하고 배경에서 수렴합니다. 그것은 CAP 맞교환의 가용성 쪽입니다. 네트워크가 분할될 때 시스템은 일관적(모두가 합의할 때까지 답변 거부)이거나 가용적(가진 것으로 답하고 나중에 화해)일 수 있으며, 최종 일관성은 가용적을 택합니다.⁴⁷

“you build it, you run it”는 무슨 뜻인가요?

“you build it, you run it”(만든 사람이 운영한다)는 2006년 ACM Queue 대화에서 나온 Vogels의 전체 서비스 소유 모델에 대한 묘사입니다. 서비스를 만드는 팀이 “그 서비스에 대해 완전히 책임을 집니다 – 기능의 범위를 정하는 것에서, 그것을 설계하고, 만들고, 운영하는 것까지.”⁵ 개발과 운영 사이에 벽이 없습니다 – 코드를 작성한 엔지니어가 그것의 호출기를 듭니다. Vogels는 이것이 “개발자를 자기 소프트웨어의 일상적 운영과 접촉하게 만들고”, “고객과의 일상적 접촉으로 데려오며”, 그 결과로 생기는 피드백 루프가 품질을 끌어올리는 것이라고 주장했습니다.⁵ 그 아이디어는 현대 DevOps 문화의 창립 원칙 중 하나가 되었습니다.

Sources