[번역] There is No Now

분산 시스템의 시간 및 상태
1. There is No Now 
2. Time, Clocks, and the Ordering of Events in a Distributed System
3. Virtual Time and Global States of Distributed Systems
4. Why Logical Clocks are Easy
5. Hybrid logical clocks

 

There is No Now (지금은 없습니다)

분산 시스템의 동시성 문제

Justin Sheehy
원문

"지금"

제가 이 글을 쓴 시점과 여러분이 이 글을 읽은 시점 사이에는 최소 2주 이상의 시간이 흘렀습니다. 이런 종류의 지연은 우리가 당연하게 여기고 서면 매체에서는 생각조차 하지 않는 것입니다.

"지금"

만약 우리가 같은 방에 있는데 제가 큰 소리로 말했다면 여러분은 더 큰 즉각성을 느낄 수 있을 것입니다. 제가 말하는 것과 정확히 같은 시간에 그 단어를 듣고 있는 것처럼 직관적으로 느낄 수 있습니다. 하지만 그 직감은 틀릴 수 있습니다. 직관을 믿지 않고 소리의 물리학에 대해 생각해 본다면 제가 말하는 것과 여러분이 듣는 것 사이에 시간이 경과했음을 알 수 있을 것입니다. 내 말을 전달하는 공기의 움직임이 내 입에서 당신의 귀에 도달하는 데 시간이 걸릴 것입니다.

"지금"

내가 그 단어가 적힌 표지판을 들고 우리 둘 다 그것을 바라본다고 해도, 표지판에 대한 정보를 전달하는 빛이 각자에게 도달하는 데 걸리는 시간이 다르기 때문에 그 이미지에 대한 우리의 인식은 같은 순간에 일어나지 않을 것입니다.

컴퓨터의 일부가 '가상'이기는 하지만, 컴퓨터는 여전히 물리적 세계에서 작동해야 하며 그 세계의 도전을 무시할 수 없습니다. 최초의 컴파일러를 개발하는 등 이 분야의 가장 중요한 선구자 중 한 명인 그레이스 호퍼 해군 제독은 학생들에게 전기가 1나노초 동안 이동할 수 있는 최대 거리인 11.8인치 길이의 전선 조각을 각각 나눠주며 이 점을 설명했습니다. 정보, 시간, 거리 사이의 관계를 이렇게 물리적으로 표현한 것은 신호(위의 은유적 기호처럼)가 목적지에 도착하는 데 항상 불가피하게 시간이 걸리는 이유를 설명하는 도구로 사용되었습니다. 이러한 지연을 고려할 때 컴퓨터 시스템에서 '지금'이 정확히 무엇을 의미하는지 추론하는 것은 어려울 수 있습니다.

하지만 신중하게 미리 계획을 세운다면 '지금'이라는 공통된 개념에 대해 이론적으로 동의하는 것을 막을 수는 없습니다. (상대성이론은 여기서 문제가 되지는 않지만 방해가 될 수 있습니다. 현재 인류의 모든 컴퓨팅 시스템은 시간에 대한 상대주의적 인식의 차이를 중요하지 않게 만들 만큼 충분히 가까운 기준 프레임을 공유합니다.) 인터넷에서 시스템 간의 시계를 동기화하는 데 사용되는 NTP(네트워크 시간 프로토콜)[14]는 메시지가 호스트 간에 이동하는 데 걸리는 시간을 계산하여 부분적으로 작동합니다. 이 이동 시간을 알면 호스트는 더 신뢰할 수 있는 출처에 맞춰 시계를 조정할 때 이를 고려할 수 있습니다. 해당 네트워크에서 매우 정확한 소스(원자 방사선의 연속 측정에 기반한 시계)를 제공함으로써 NTP를 사용하여 컴퓨터의 시계를 작은 오차 범위 내에서 동기화할 수 있습니다. 전 세계 GPS를 구성하는 각 위성에는 여러 개의 원자 시계가 포함되어 있으며(따라서 하나의 시계가 고장 나더라도 위성이 쓸모없어지지 않음), GPS 프로토콜을 사용하는 수신기만 있으면 모든 변수를 해결할 수 있는 충분한 위성을 볼 수 있기 때문에 수신기 자체의 위치뿐만 아니라 시간도 매우 정밀하게 결정할 수 있습니다.

우리는 수십 년 동안 이러한 프로토콜을 이해해 왔기 때문에 이러한 종류의 문제를 극복했으며 시계가 동기화되어 있다고 가정하는 시스템을 구축할 수 있어야 한다고 생각하기 쉽습니다. 원자시계, NTP, GPS 위성은 정보가 이동하는 데 걸리는 시간을 고려할 수 있는 지식과 장비를 모두 제공합니다. 따라서 모든 시스템이 '지금'에 동의하고 시간의 진행 상황에 대한 공통의 단일 관점을 공유할 수 있어야 합니다. 그러면 네트워크와 컴퓨팅의 모든 범주의 어려운 문제를 훨씬 쉽게 해결할 수 있습니다. 관심 있는 모든 시스템이 시간에 대해 정확히 동일한 인식을 가지고 있다면, 관련된 호스트 중 일부에 장애가 발생하더라도 많은 문제를 추적할 수 있게 됩니다. 하지만 이러한 문제는 여전히 존재하며, 이러한 문제를 해결하는 것은 지속적으로 활발한 연구 분야일 뿐만 아니라 실제 분산 시스템을 구축할 때 주요 관심사이기도 합니다.

시간을 이해하는 데 사용할 수 있는 성숙한 메커니즘을 보면 연구자와 시스템 구축자가 불필요한 작업을 엄청나게 많이 하고 있다고 생각할 수 있습니다. 동기화 방법을 알고 있는데 왜 시계가 다를 수 있다고 가정하고 문제를 해결하려고 할까요? 대신 시간 소스와 프로토콜을 적절히 조합하여 시계가 일치하도록 만들고 이러한 문제를 넘어가면 어떨까요? 이러한 접근 방식은 불가능할 뿐만 아니라 이러한 문제를 정면으로 마주해야만 하는 이유 중 하나가 바로 모든 것이 깨진다는 점입니다.

실제 문제는 한 장소에서 다른 장소로 정보를 전송하는 데 시간이 필요하다는 이론적 개념이 아닙니다. 실제 문제는 컴퓨팅 시스템이 상주하는 물리적 세계에서 구성 요소가 종종 실패한다는 것입니다. 시스템, 특히 분산 컴퓨팅 시스템을 일반 컴퓨터와 네트워크에 구축할 때 가장 흔히 범하는 실수 중 하나는 기본적인 물리적 현실에서 벗어난다고 가정하는 것입니다. 빛의 속도는 그러한 현실 중 하나이지만, 더 치명적이고 보편적인 현실도 있습니다. 우리는 절대 고장 나지 않는 완벽한 기계를 만들 수 없습니다. 이러한 비동기성과 부분적인 장애라는 현실이 결합되어 분산 시스템 구축을 어렵게 만드는 것입니다. 개별 구성 요소의 장애를 계획하고 고려하지 않으면 결합된 시스템의 장애를 보장할 수밖에 없습니다.

분산 시스템 이론에서 가장 중요한 결과 중 하나는 불가능 결과로서, 실패할 수 있는 세상에서 작동하는 시스템을 구축하는 능력의 한계를 보여줍니다. 이는 일반적으로 FLP 결과라고 불리며, 저자인 피셔, 린치, 패터슨의 이름을 따서 명명되었습니다[8]. 분산 컴퓨팅 분야에서 가장 영향력 있는 논문으로 2001년 Dijkstra 상을 수상한 이들의 연구는 호스트가 동일하거나 공유 시계를 가진 "동기" 모델에서는 달성할 수 있는 일부 계산 문제가 더 약한 비동기 시스템 모델에서는 불가능하다는 것을 결정적으로 보여주었습니다. 이와 같은 불가능 결과는 자체 시스템을 설계할 때 막다른 길로 가지 않도록 안내할 수 있으므로 매우 중요합니다. 또한 스네이크 오일 탐지기를 제공할 수 있으므로 제품이 불가능하다고 주장하는 사람에 대한 의심이 정당하다고 느낄 수 있습니다.

오늘날 개발자들에게 FLP보다 더 잘 알려진 관련 결과는 일관성, 가용성 및 파티션 허용 오차에 대한 CAP 정리입니다. 이 정리는 에릭 브루어에 의해 비공식적으로 처음 제안되었고[5], 나중에 세스 길버트와 낸시 린치[9]에 의해 공식 버전이 증명되었습니다. 분산 시스템 이론의 관점에서 CAP 정리는 FLP보다 덜 흥미롭습니다. 공식 버전의 CAP를 "이기는" 반례는 FLP보다 훨씬 더 약하고 적대적인 세계 모델을 가정하고 그 모델 내에서 더 많은 것을 달성해야 한다고 요구하기 때문입니다. 어느 쪽이 다른 쪽의 하위 문제인 것은 아니지만, FLP가 더 강력하고 흥미로우며 어쩌면 더 놀라운 결과일 수도 있습니다. FLP에 이미 익숙한 연구자라면 CAP 아이디어가 다소 지루하게 느껴질 수도 있습니다.

하지만 CAP의 가치는 분산 시스템에 대한 문헌에 익숙하지 않은 사람들이 더 쉽게 접근하고 더 쉽게 이해할 수 있도록 하는 데 있다고 생각하는 것이 합리적일 것입니다. 이는 칭찬할 만하고 가치 있는 일이지만, 지난 몇 년 동안 수십 개의 기사와 블로그 게시물을 통해 (기본 개념을 심각하게 오해하는 경우가 많은) CAP의 개념이 안타깝게도 오늘날의 개발자들이 분산되고 불완전한 세상에서 프로그래밍하는 현실을 받아들이기 쉽지 않다는 것을 보여줬습니다. CAP의 관점이든 FLP의 관점이든 또는 다른 어떤 관점이든 현실은 빌딩 블록으로 사용하는 구성 요소의 불완전성을 가정해야 하는 세계입니다. (CAP나 FLP와 같은 이론적 '불가능 결과'는 태생적으로 시스템 모델과 연관되어 있습니다. 이것은 결과가 의존하는 세계의 이론적 모델입니다. 이러한 결과는 합의와 같은 어떤 목표가 일반적으로 불가능하다고 말하는 것이 아니라 특정 모델 내에서 불가능하다는 것을 의미합니다. 이는 실무자가 어떤 경로가 막다른 길인지에 대한 직관을 개발하는 데 매우 유용할 수 있지만, 결과가 적용되는 맥락을 배우지 않고 결과만 배우면 오해의 소지가 있을 수 있습니다.)

진짜 문제는 그것이 망가진다는 것입니다. FLP와 같이 여기서 언급된 문헌은 모두 구성 요소가 실패할 것으로 예상되는 시스템을 다루는 것에 관한 것입니다. 이것이 문제라면 그냥 고장 나지 않는 것을 사용하고, 견고하다고 가정할 수 있는 구성 요소로 더 나은 시스템을 구축하면 어떨까요?

지난 몇 년 동안 이러한 가정을 뒷받침하는 근거로 Google의 Spanner 시스템이 자주 언급되었습니다[6]. 이 시스템은 앞서 언급한 기술(NTP, GPS, 원자 시계)을 사용하여 Spanner를 구성하는 호스트의 시계를 조정하고 이러한 시계 간의 차이에 대한 불확실성을 최소화하고 측정하는 데 도움을 줍니다(제거하지는 못함). Spanner 논문은 문서화된 시스템과 함께 단일 시간 보기로 분산 시스템을 구축할 수 있다는 주장을 뒷받침하는 데 자주 사용됩니다.

구글을 지목하고 권위 있는 기관의 주장을 인용하는 것이 매력적이지만, 이러한 주장을 하는 사람들은 모두 틀린 주장을 하고 있습니다. 사실, 동기화가 '해결되었다(solved)'는 증거로 스패너를 인용하는 사람은 거짓말을 하고 있거나 실제로 그 논문을 읽어보지 않은 사람입니다. 이러한 주장에 대한 가장 간단하고 명확한 증거는 바로 Spanner 논문 자체입니다. Spanner의 TrueTime 구성 요소는 단순하고 통합된 공유 타임라인을 제공하지 않습니다. 대신 시스템 시계 간에 인식되는 시간의 차이에 대한 불확실성을 직접적으로 드러내는 API를 매우 명확하게 제공합니다. 현재 시간을 요청하면 단일 값을 제공하는 것이 아니라 '지금'을 중심으로 다양한 가능성을 설명하는 한 쌍의 값을 제공합니다. 즉, TrueTime은 이 근본적인 문제를 해결하는 것과는 정반대로 작동합니다. 작동 중인 분산 시스템에서 '지금'에 대한 단일 절대값이 의미 있는 척하는 대신 불확실성에 직접 직면하고 불확실성에 대해 명시하는 용감하고 매혹적인 선택이 필요합니다.

Spanner의 프로덕션 환경 내에서 시계 드리프트는 일반적으로 1밀리초에서 7밀리초 사이입니다. 이는 왜곡을 최소화하기 위해 GPS, 원자 시계의 보정 효과, 드리프트가 가장 심한 시계의 퇴거 등을 포함한 후 Google이 할 수 있는 최선의 결과입니다. 일반적인 x86 클럭은 부하, 발열, 전력 등 예측할 수 없는 모든 종류의 환경 요인에 따라 속도가 달라집니다. 심지어 같은 랙의 상단과 하단의 차이로도 스큐의 차이가 발생할 수 있습니다. Google과 같이 비용이 많이 드는 환경에서 할 수 있는 최선이 몇 밀리초의 불확실성을 감수하는 것이라면, 우리 대부분은 자신의 시계가 그보다 훨씬 더 오차 범위가 크다고 가정해야 합니다.

분산 시스템 설계에서 "그냥 괜찮은 척"하는 접근 방식을 정당화하기 위해 종종 제기되는 또 다른 주장은 충분히 고품질의 장비는 고장 나지 않거나 적어도 걱정할 필요가 없을 정도로 드물게 고장난다는 것입니다. 이러한 주장은 잘못된 것이며 장비의 제조업체에서 나온 것으로 이해할 수 있지만, 일반적으로 이러한 주장을 하는 것은 분산 데이터베이스 소프트웨어 설계자와 같은 해당 장비의 사용자입니다. (스패너와 다른 사람들이 의존하는 GPS의 설계자들은 확실히 이런 종류의 주장에 동의하지 않았습니다. GPS 위성은 거의 30개에 달하며, 그 중 4개만 보이면 시스템이 작동합니다. 각 위성에는 중복 원자 시계가 여러 개 있으므로 위성 중 하나가 고장 나더라도 계속 작동할 수 있습니다.)

이러한 주장의 가장 일반적인 변형 중 하나는 로컬 데이터 센터 내 네트워크의 맥락에서 "네트워크가 안정적이다"라는 주장입니다. 많은 시스템에는 정의되지 않은 동작이 있으며 네트워크가 제대로 작동하지 않을 때 재앙적인 동작을 일으킬 가능성이 높습니다. 이러한 시스템을 판매하려는 사람들은 이러한 장애가 극히 드물다고 설명함으로써 현실을 무시하는 자신들의 선택을 정당화합니다. 이렇게 함으로써 그들은 고객에게 두 가지 피해를 줍니다. 첫째, 그러한 이벤트가 드물다고 하더라도, 그러한 이벤트가 비즈니스에 미칠 영향에 대비하기 위해 그러한 이벤트가 발생했을 때 시스템이 어떻게 작동하는지 이해하고 싶지 않을까요? 둘째, 더 심각한 문제는 이러한 주장이 분산 컴퓨팅의 대표적인 8가지 오류[7,15] 중 첫 번째 오류에 해당할 정도로 대놓고 거짓말이라는 점입니다. 이러한 실패의 현실은 이전 ACM 큐 기사[3]에 잘 설명되어 있으며, 그 증거는 매우 명확하고 존재하기 때문에 "네트워크는 신뢰할 수 있다"고 주장하며 소프트웨어 설계 선택을 정당화하는 사람은 컴퓨팅 시스템을 구축하는 데 전혀 신뢰해서는 안 될 것입니다. 일부 시스템과 네트워크가 특정 관찰자가 알아차릴 수 있는 방식으로 실패하지 않은 것은 사실이지만, 시스템의 안전성을 절대 실패하지 않을 것이라는 가정에 기초하는 것은 어리석은 일입니다.

이러한 물리적 문제를 무시하는 것과 반대되는 접근 방식은 거의 아무것도 믿을 수 없다고 가정하고 매우 적대적인 세계에 대한 형식적인 모델만 사용하여 설계하는 것입니다. FLP가 증명된 "비동기" 모델은 작동하는 시스템을 구축하는 데 가장 적대적인 모델은 아니지만, 대부분의 개발자가 자신의 시스템이 실행되고 있다고 생각하는 것보다 훨씬 더 적대적인 세계인 것은 분명합니다. 모델링하는 세계가 실제 운영되는 세계보다 더 열악하다면, 모델에서 성공할 수 있는 일이 실제 구현 세계에서도 가능해야 한다는 생각에 따른 것입니다. (참고로 분산 시스템 이론가들은 시스템의 일부가 단순히 충돌하거나 지연되는 것보다 훨씬 더 나쁜 방식으로 실패할 수 있는 "비잔틴" 실패의 가능성을 포함하는 등 성공하기 어려운 모델도 있습니다. 진정한 적대적 네트워크/시스템 모델의 경우, 예를 들어 암호화 프로토콜 이론가들이 사용하는 기호적 모델이나 계산적 모델을 볼 수 있습니다. 이러한 세계에서는 시스템 빌더가 실제로 사용자의 네트워크가 사용자를 공격한다고 가정합니다.)

이러한 맥락에서 우리가 실제로 운영되고 있다고 생각하는 것보다 조금 더 나쁜 세상을 가정하고, 합의와 조정을 위한 가장 잘 알려진 프로토콜인 Paxos[12]가 설계되었습니다. 분산 시스템의 필수 구성 요소인 이러한 프로토콜은 메시지가 임의로 손실되거나 호스트가 다운되는 등 설계자에게 불리하게 작용하는 세계에서도 가장 중요한 보장을 제공할 수 있다는 사실을 아는 것이 유용합니다. (예를 들어, Paxos와 관련 프로토콜에서 가장 강조되는 속성은 "안전성 (safety)"으로, 서로 다른 참여 호스트가 서로 상충되는 결정을 내리지 않도록 보장하는 것입니다.) 이러한 작업의 또 다른 영역은 논리적 시간으로, 벡터 시계, 버전 벡터 및 이벤트 순서를 추상화하는 다른 방법으로 나타납니다. 이 아이디어는 일반적으로 동기화된 시계를 가정할 수 없음을 인정하고 시계가 완전히 신뢰할 수 없는 세계에 대한 순서에 대한 개념을 구축합니다.

물론 네트워크를 포함한 모든 것을 가능한 한 안정적으로 만들기 위해 항상 노력해야 합니다. 이러한 끊임없는 목표를 달성 가능한 완벽한 최종 상태와 혼동하는 것은 어리석은 일입니다. 가장 잘 정립되고 완벽하게 이해된 이론적 모델만이 시스템 구축의 합리적인 출발점이라는 순수주의적 관점도 마찬가지로 어리석은 일입니다. 가장 효과적인 분산 시스템 중 상당수는 가장 일반적인 분산 컴퓨팅 모델에 완벽하게 매핑되지 않는 가치 있는 요소를 기반으로 구축됩니다. 이러한 빌딩 블록의 대표적인 예로 TCP를 들 수 있습니다. 이 거의 유비쿼터스적인 프로토콜은 몇 가지 매우 유용한 속성을 제공하지만, 그 속성은 FLP와 같은 이론적 결과를 개발하는 데 사용되는 일반적인 네트워크 모델과 정확히 매핑되지 않습니다. 이는 시스템 구축자에게 난처한 상황을 야기합니다. 설계할 때 TCP와 같은 현실을 가정하지 않는 것은 어리석은 일이지만, 경우에 따라 분산 시스템 이론이 자신의 작업에 정확히 어떻게 적용되는지 이해하려고 하면 난처한 입장에 처하게 됩니다.

인기 있는 Apache ZooKeeper 조정 소프트웨어의 가장 핵심적인 부분을 구성하는 Zab 프로토콜은 이러한 중간 길을 걷고자 시도한 흥미로운 예입니다[10]. ZooKeeper의 개발자들은 Paxos와 같은 기존 합의 프로토콜에 대해 알고 있었지만, 다음 제안을 시작하기 전에 각 제안이 완료될 때까지 기다리지 않고 한 번에 많은 요청을 처리할 수 있는 기능 등 몇 가지 추가 기능을 갖춘 자체 프로토콜을 만들기로 결정했습니다. 그들은 TCP를 기반으로 구축하면 프로토콜에서 가정할 수 있는 몇 가지 중요한 속성을 제공하는 기본 시스템의 이점을 누릴 수 있다는 것을 깨달았습니다. 예를 들어, 연결된 단일 TCP 소켓 내에서 발신자가 메시지 A에 이어 메시지 B를 생성하는 경우 수신자가 B를 읽으면 수신자가 이전에 A를 읽었다고 안전하게 가정할 수 있습니다. 이러한 "prefix" 속성은 매우 유용하며 비동기 모델에는 존재하지 않습니다. 이는 해당 분야의 연구와 실제로 구축할 수 있는 특정 기술을 무시하지 않고 모두 살펴봄으로써 얻을 수 있는 이점을 보여주는 구체적인 예입니다.

하지만 실용주의를 추구할 때는 그 실용주의가 그 자체로 이상한 순수성이 되어 엉성한 작업에 대한 변명이 되지 않도록 주의해야 합니다. 사실상의 참조 구현인 ZooKeeper 내부에 구현된 Zab 프로토콜은 설계된 대로 정확하게 구현된 적이 없습니다[13]. 여러분은 스스로를 "실용주의자"라고 부르며 대부분의 다른 소프트웨어도 공식 사양과 일치하지 않는다는 점에 주목할 수 있으므로 여기서 걱정할 것이 없다고 말할 수 있습니다. 두 가지 이유에서 틀린 생각입니다. 첫째, ZooKeeper와 유사한 소프트웨어의 역할은 다른 소프트웨어와 달리 시스템의 나머지 부분이 강력한 가정을 할 수 있는 기반을 형성하는 필수적인 안전 속성을 제공하기 위해 정확하게 존재합니다. 둘째, 이와 같은 프로토콜의 안전 속성에 문제가 있는 경우, 그 문제가 매우 위험할 수도 있지만 미묘하게 나타나기 때문에 쉽게 놓칠 수 있습니다. 구현이 분석된 프로토콜을 반영한다는 강한 믿음이 없다면 사용자가 시스템을 신뢰하는 것은 합리적이지 않습니다. 일반 사용자가 그 정확성을 평가할 수 없다면 시스템의 "충분한 정확성"이 인기로 입증된다는 주장은 말도 안 됩니다.

이 모든 것은 ZooKeeper를 비방하려는 것이 아닙니다. 실제로 ZooKeeper는 동종 업계에서 가장 우수한 오픈 소스 소프트웨어 중 하나이며, 많은 우수한 엔지니어들이 지속적으로 개선하고 있습니다. 최근 분석에 따르면 ZooKeeper는 경쟁 제품보다 스트레스에 훨씬 더 잘 견디는 것으로 나타났습니다[1]. 저는 이론과 실용성 측면에서 중간 길을 택하는 것의 필요성과 함정을 모두 보여주는 사례로 ZooKeeper를 예로 들었을 뿐입니다. 이론과 실제를 매핑하는 것은 매우 어려울 수 있습니다.

이 중간 길의 또 다른 예로는 논리적 시간의 일반적인 기술과 물리적 시계의 타임스탬프를 통합한 하이브리드 논리적 시계[11]가 있습니다. 이를 통해 사용자는 전체 시스템에서 물리적 시계에 대한 (불완전하지만 여전히 유용한) 뷰를 기반으로 몇 가지 흥미로운 기술을 적용할 수 있습니다. Spanner와 마찬가지로, 이것은 하나의 통합된 타임라인을 만드는 것처럼 보이지는 않지만 시스템 설계자가 클러스터 전체에서 인식되고 전달되는 시간에 대한 최상의 지식을 바탕으로 구축할 수 있게 해줍니다.

Paxos, Viewstamped Replication, Zab/Zookeeper, Raft 등 이러한 다양한 조정 시스템은 물리적 시간을 안전하게 사용할 수 없는 경우에도 분산 시스템에서 이벤트 순서를 정의할 수 있는 방법을 제공합니다. 하지만 이러한 프로토콜은 시스템 전체에 통합된 타임라인을 제공하는 용도로는 절대적으로 사용할 수 있습니다. 조정을 "지금"에 대한 논리적 대리물을 제공하는 것으로 생각할 수 있습니다. 그러나 이러한 프로토콜을 이러한 용도로 사용할 경우, 지속적인 커뮤니케이션이라는 근본적인 공통점 때문에 비용이 발생합니다. 예를 들어, 분산 시스템에서 일어나는 모든 일에 대한 주문을 조정하는 경우, 기껏해야 해당 시스템 내부의 왕복 시간(두 번의 순차적 메시지 전달)보다 적은 응답 대기 시간만 제공할 수 있습니다.

조정 시스템의 세부 사항에 따라 처리량에도 비슷한 한계가 있을 수 있습니다. 공격적인 성능 요구 사항이 있는 시스템의 설계자는 제대로 작동하고 싶지만 지속적인 조정에 드는 비용이 부담스러울 수 있습니다. 특히 호스트나 네트워크에 장애가 자주 발생할 것으로 예상되는 경우, 많은 조정 시스템이 '최종적인 생존성'만 제공하고 최소한의 문제가 발생하는 시간에만 진전을 이룰 수 있기 때문에 더욱 그렇습니다. 그러나 모든 것이 완벽하게 작동하는 드문 경우에도 지속적인 조율에 따른 통신 비용이 너무 높을 수 있습니다.

성능을 위해 엄격한 조정을 포기하는 것은 CPU 아키텍처, 멀티스레드 프로그래밍, DBMS(데이터베이스 관리 시스템) 설계 등 컴퓨팅의 많은 영역에서 잘 알려진 절충안입니다. 사용자에게 놀랄 만한 동작을 제공하기 위해 얼마나 적은 조정이 필요한지 알아내는 게임으로 변질된 경우가 많습니다. 일부 동시적이지만 로컬 시스템 설계자들은 충분한 조정을 관리하기 위해 꽤 많은 트릭을 개발해왔지만(예를 들어, RDBMS 분야는 흥미로운 성능 해킹의 오랜 역사를 가지고 있으며, 그 결과 종종 생각보다 훨씬 적은 ACID[원자성, 일관성, 격리, 내구성]를 제공하기도 합니다[2]), 일반적인 분산 시스템을 위한 이러한 기술의 탐색은 이제 막 시작되고 있습니다.

분산 시스템 설계에서 이러한 절충점을 어떻게 만들 것인가에 대한 주제가 이제 막 진지하게 연구되기 시작했다는 점에서 매우 흥미로운 시기입니다. 이 주제가 주목받고 있는 곳 중 하나는 캘리포니아 버클리 대학교의 BOOM(Berkeley Orders of Magnitude) 팀으로, 여러 연구자가 서로 다르지만 관련된 접근 방식을 통해 절제된 트레이드오프를 만드는 방법을 이해하고 있습니다[4]. 이들은 '지금'에 신경 쓰지 않기로 안전하게 결정하여 조정 비용을 지불하지 않을 수 있는 시기와 방법을 알아내는 데 새로운 지평을 열고 있습니다. 이러한 연구를 통해 우리는 곧 업무를 수행하기 위해 실제로 동기화된 시간이 얼마나 필요한지 더 잘 이해할 수 있게 될 것입니다. 필요한 모든 안전 속성을 제공하면서도 조정을 줄이면서 분산 시스템을 구축할 수 있다면 더 빠르고, 더 탄력적이며, 더 확장할 수 있을 것입니다.

시간이나 조정에 대해 걱정할 필요가 없도록 하는 또 다른 중요한 연구 분야는 충돌 없는 CRDT(conflict-free replicated data types)과 관련된 것입니다. 이는 업데이트 순서를 정할 필요가 없는 데이터 구조로, 시간 문제를 해결하지 않고도 안전하게 사용할 수 있습니다. 이러한 데이터 구조는 순서에 관계없이 동일한 업데이트 세트를 받은 시스템의 모든 호스트가 동일한 상태를 유지한다는 점에서 강력한 최종 일관성이라고도 하는 일종의 안전성을 제공합니다. 이는 모든 작업이 정류성, 연관성, 무력성과 같은 특정 속성을 가질 때 달성할 수 있는 것으로 오랫동안 알려져 왔습니다. CRDT가 흥미로운 이유는 이 분야의 연구자들[16]이 개발자들이 바로 사용할 수 있는 다양한 데이터 유형을 제공하면서 그 한계 내에서 얼마나 표현력을 발휘할 수 있는지, 그리고 얼마나 저렴하게 그러한 작업을 수행할 수 있는지에 대한 이해를 넓혀가고 있기 때문입니다.

이러한 주제의 발전이 이제 막 시작되었다는 것을 알 수 있는 한 가지 방법은 일관성, 조정 또는 합의 문제를 처리하는 데 가장 잘 알려진 선택 대신 임시 해킹을 선호하는 인기있는 분산 시스템이 존재한다는 것입니다. 한 가지 예로, 충돌하는 쓰기를 해결하기 위해 "마지막 쓰기가 승리한다"는 정책을 사용하는 분산 데이터베이스가 있습니다. "지금"이 전체 시스템에서 단순한 값이 아닌 것과 같은 이유로 '마지막' 자체가 무의미한 용어라는 것을 이미 알고 있기 때문에, 이것은 실제로 "예측할 수 없이 선택된 많은 글이 손실될 것"이라는 정책이지만 그렇게 하면 데이터베이스가 많이 팔리지는 않겠죠? 아무리 기술이 빠르게 발전하고 있다고 해도 누구나 이보다 더 나은 방법을 찾을 수 있어야 합니다.

"대부분의 쓰기가 손실되는" 데이터베이스 전략만큼이나 끔찍한 또 다른 예는 공식적으로 설립되고 잘 분석된 합의 프로토콜을 사용하는 대신 임시 조정 코드를 통해 클러스터 관리를 해결하려는 선택입니다. 잘 알려진 합의 프로토콜 중 하나가 해결하는 것과 동일한 문제를 해결하기 위해 정말로 다른 것이 필요하다면(힌트: 필요하지 않습니다), 최소한 ZooKeeper/Zab 구현자가 한 것처럼 목표와 가정을 명확하게 문서화해야 합니다. 그렇게 한다고 해서 재앙에서 벗어날 수는 없지만, 적어도 나중에 유골을 조사하러 오는 고고학자들에게는 도움이 될 것입니다.

지금은 분산 시스템을 구축하기에 매우 흥미로운 시기입니다. 여전히 많은 변화가 있을 것입니다. 하지만 몇 가지 진실은 그대로 유지될 가능성이 높습니다. '지금'을 먼 거리에서 의미를 갖는 단순한 값으로 생각하는 것은 언제나 문제가 될 것입니다. 이러한 현실과 함께 살아가기 위한 도구를 개선하기 위해서는 더 많은 연구와 더 많은 실제 경험이 계속 필요할 것입니다. 우리는 더 잘할 수 있습니다. 우리는 할 수 있습니다.

 

References

[1] Aphyr. 2013. Call me maybe: ZooKeeper; http://aphyr.com/posts/291-call-me-maybe-zookeeper.
[2] Bailis, P. 2013. When is "ACID" ACID? Rarely; http://www.bailis.org/blog/when-is-acid-acid-rarely/.
[3] Bailis, P., Kingsbury, K. 2014. The network is reliable. ACM Queue 12(7); http://queue.acm.org/detail.cfm?id=2655736.
[4] BOOM; http://boom.cs.berkeley.edu/papers.html.
[5] Brewer, E. A. 2000. Towards robust distributed systems; http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf.
[6] Corbett, J. C., et al. 2012. Spanner: Google's globally distributed database. Published in Proceedings of the 10th Symposium on Operating System Design and Implementation; http://research.google.com/archive/spanner.html; http://static.googleusercontent.com/media/research.google.com/en/us/archive/spanner-osdi2012.pdf.
[7] Deutsch, P. The eight fallacies of distributed computing; https://blogs.oracle.com/jag/resource/Fallacies.html.
[8] Fischer, M. J., Lynch, N. A., Paterson, M. S. 1985. Impossibility of distributed consensus with one faulty process. Journal of the ACM 32(2): 374-382; http://macs.citadel.edu/rudolphg/csci604/ImpossibilityofConsensus.pdf.
[9] Gilbert, S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33 (2): 51-59; http://webpages.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf.
[10] Junqueira, F. P., Reed, B. C., Serafini, M. 2011. Zab: high-performance broadcast for primary backup systems; http://web.stanford.edu/class/cs347/reading/zab.pdf.
[11] Kulkarni, S., Demirbas, M., Madeppa, D., Bharadwaj, A., Leone, M. 2014. Logical physical clocks and consistent snapshots in globally distributed databases; http://www.cse.buffalo.edu/tech-reports/2014-04.pdf.
[12] Lamport, L. 1998. The part-time parliament. ACM Transactions on Computer Systems 16(2): 133-169; http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#lamport-paxos.
[13] Medeiros, A. 2012. ZooKeeper's atomic broadcast protocol: theory and practice; http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf.
[14] NTP; http://www.ntp.org.
[15] Rotem-Gal-Oz, A. Fallacies of distributed computing explained; http://www.rgoarchitects.com/Files/fallacies.pdf.
[16] SyncFree; https://syncfree.lip6.fr/index.php/publications.