선택의 문제

개발자 세계에는 Trade-off에 대한 몇가지 유명한 선택 문제가 있다. 그 중 하나는 Good, Fast, Cheap 문제이고 다른 하나는 CAP(Consistency, Availability, Partition Tolerance) 문제이다.

전자의 경우 소프트웨어 개발을 할 때 선택할 수 있는 전략이 Good(완성도 있는), Fast(기간이 짧은), Cheap (저렴한) 중 최대 두가지만 선택할 수 있다는 것이다. 그리고 나머지 하나는 분산 네트워크에서 시스템이 선택할 수 있는 전략이 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 내성) 중 두 가지를 선택하는 것이다. 물론 CAP의 경우 CP 혹은 AP 에 중점을 두고 설명한다. P가 보장받지 못하는 것은 분산 시스템의 근본이 없는 것이기 때문이다.

재미있는 이야기

여기 분산 시스템에서 CAP 이론을 재미있게 설명한 글이 있다.

기억의 명수인 나는 Remember Inc.를 설립했다. 회사가 제공하는 서비스는 단순하다. 고객으로부터 기억해야 할 것을 전달받아 그것을 기억한다.

영원히.

Scale up

서비스는 순조롭게 성장해갔다. Y Combinator로부터 투자도 받았다(..). 고객들이 나에게 기억해야 할 것을 알려주면 나는 기억했다. 서비스가 점점 커져서 공책에 기록하기 시작했다.

하지만 서비스가 커질수록 혼자서 감당하기 어려워졌다. 예를 들어 한 명의 고객의 전화를 받는 동안 다른 고객들은 통화 대기 상태로 기다려야 했는데, 고객이 늘어날수록 그들이 기다리는 시간도 점점 길어졌다. 어떤 때는 내가 서비스를 할 수 없는 상황이 되면 고객들은 아무런 서비스를 이용할 수 없게 되었다.

그 때, 나의 아내가 구세주처럼 나의 서비스에 합류하게 되었다. 그리고 아내의 합류와 동시에 새로운 운영 정책을 도입했다.

  1. 대표번호를 신설한다.
  2. 나와 아내의 번호를 대표 번호로 연결한다.
  3. 고객이 대표번호로 전화를 걸면 나와 아내 둘 중 한명에게 연결된다.

처음으로 '나쁜 서비스'가 되다

새로운 시스템을 도입하고 이틀 후, 오래된 고객인 존(Jhon)으로부터 전화가 왔다.

Jhon : 안녕하세요.
나 : 안녕하세요! Remember Inc. 입니다. 무엇을 도와드릴까요?
Jhon : 뉴 델리로 가는 제 비행편이 언제였는지 알려주세요.
나 : 네, 잠시만 기다려 주세요..
(공책을 뒤적인다.)
(존의 페이지가 없잖아!)
나 : 저기, 죄송하지만 착오가 있는 것 같네요. 저희에게 뉴 델리로 가는 비행편에 대해 말씀주신적이 없는 것 같아요.
Jhon : 뭐라구요!? 전 바로 전날에 말씀드렸었다구요! (전화가 뚝 끊긴다.)

어떻게 이런 일이 발생할 수 있었을까? 존이 거짓말을 하는 걸까? 그 때 번뜩 하고 뇌리를 스치는 생각이 있었다. 만약 어제 걸려온 존의 전화를 아내가 받은거라면? 아내의 공책을 펴서 존의 요청 내역을 찾으니 역시나 떡하니 적혀있었다! 나는 이 사실을 아내와 공유했다.

이 얼마나 끔찍한 분산 시스템인가! 우리의 분산 시스템은 일관성(Consistency)을 지키지 못했다. 어떤 고객이 나에게 기억을 요청하고 아내에게 확인하는 일은(그리고 그 반대의 경우도) 얼마든지 있을 수 있었던 것이다.

일관성 문제를 해결하다.

경쟁자들은 이런 문제를 무시할지도 모르지만 나는 그렇지 않았다. 아내가 자는 동안 밤새 문제에 대해 생각했고, 이튿날 아침 아주 아름다운 계획을 떠올렸다. 나는 곤히 자던 아내를 깨워(!) 계획에 대해 말해주었다.

"여보, 오늘부터는 우리 이렇게 일해봐요."

  1. 우리 중 한 명이 업데이트 요청을 받으면, 전화를 끊기 전에(요청을 완료하기 전에) 다른 사람에게도 알려준다.
  2. 전달 받은 업데이트를 각자 자기 노트에 업데이트를 반영한다.
  3. 서로의 공책에 최신 정보를 유지하기 때문에, 기억한 내용을 찾는 요청이 와도 서로에게 확인할 필요가 없다.

이 방법의 유일한 문제는 바로 업데이트 요청을 처리하는 동안에는 병렬로 일처리를 할 수 없다는 것이었다. 예를 들어 내가 업데이트 요청을 받고 아내에게 알려주는 동안 아내는 다른 전화를 받을 수 없었다. 하지만 대부분의 요청이 "검색"이었기 때문에 괜찮을 것이라고 생각했다. 게다가 우리는 어쨌든 틀린 정보를 주지 않아도 되었다.

"괜찮네요" 하고 아내가 말했다. "하지만 당신이 생각한 시스템에는 한 가지 문제가 있어요. 만약 우리 중 한명이 일을 못하는 날은 어떡하죠? 그러면 어떤 업데이트 요청도 완료할 수 없을거에요. 자리에 없는 사람이 업데이트 할 수는 없잖아요. 그러면 가용성(Availability) 문제가 생길거에요. 그러니까 예를 들어 나에게 업데이트 요청이 들어왔을 때 그 요청을 완료할 수 없다는건데, 왜냐하면 그 요청을 내 공책에는 업데이트 할 수 있지만 당신 공책에는 업데이트 할 수가 없을테니까요!"

사상 최고의 해결책을 생각해내다

나는 이제서야 분산 시스템이 왜 생각처럼 간단하지 않은지 깨닫게 되었다. "일관성과 가용성" 모두를 충족하는 시스템을 만드는 것이 이렇게 힘든 일이었나? 다른 사람도 아니고 이 내가!

다음날 아침, 여러분의 경쟁자는 꿈에서도 생각해낼 수 없는 해결책을 찾아내고야 말았다! 그리고 아내를 다시 흔들어 깨웠다(…)

"이것 좀 봐요." 아내애게 말했다. "이렇게 하면 일관성과 가용성을 모두 확보할 수 있어요! 계획은 어제랑 크게 다르진 않아요."

  1. 우리 중 한 명이 업데이트 요청을 받았을 때 우리 모두 일하는 중이라면 예전처럼 전화를 끊기 전에 다른 사람에게도 업데이트 내용을 알려준다.
  2. 만약 다른 한 명이 없으면 업데이트 내용에 대해 메일을 보낸다.
  3. 다음 날 출근하면 이메일을 확인하고 업무를 시작하기 전에 업데이트를 모두 노트에 반영한다.

"이렇게 천재적일수가!" 아내가 말했다. "이 시스템은 흠이 없어요. 바로 이렇게 해 봐요. 우린 이제 일관적이고 언제든 사용 할 수 있는 서비스에요!"

아내가 화났다

얼마간 서비스는 잘 굴러간다. 우리의 시스템은 일관적일뿐 아니라 한 명이 출근하지 않아도 잘 굴러간다. 하지만 우리 둘 모두 출근했음에도 서로에게 업데이트를 알려주지 않으면 어떻게 될까?

지난 며칠간 나의 위대한 아이디어 때문에 아내를 이른 아침마다 흔들어 깨웠던 것을 떠올려보자. 열받은 아내가 나에게 자신에게 들어온 업데이트 요청을 전달해주지 않으면? 나의 아이디어는 완전히 박살난다! 나의 아이디어는 일관성과 가용성에는 좋은 아이디어일지 모르나 분할 내성(Partition tolerance)에는 영 꽝이었던 것이다.

나는 결국 분할 내성을 확보하기 위해 아내와 화해하는 동안은 전화를 받지 않기로 결정했다.. 그리고 시스템은 그 동안 가용성을 잃게되었다…

결론

CAP 이론에 대해 다시 한 번 생각해 보자. 분산 시스템을 디자인 할 때 여러분은 일관성, 가용성 그리고 분할 내성 모두를 확보할 수는 없다. 최대 두 가지만 선택할 수 있는 것이다.

  • 일관성 (Consistency) : 고객이 정보를 업데이트 하면 언제 다시 전화하더라도 가장 최근에 업데이트 된 정보를 얻을 수 있어야한다.
  • 가용성 (Availability) : Remember Inc의 서비스는 나와 아내 모두 결근하지 않는 이상 언제든지 이용할 수 있어야 한다.
  • 분할 내성 (Partition Tolerance) : Remember Inc는 나와 아내 사이에 말이 없어도 이용할 수 있어야 한다!

생각해볼 거리 : 점원을 고용해 결과적 일관성을 확보하기

여기 한 가지 더 생각해볼 거리가 있다. 다른 사람의 공책을 업데이트 해주는 알바를 고용한다고 생각 해 보자. 가장 큰 이점은 이런 작업을 비동기로 처리하기 때문에 나나 아내의 업데이트 요청을 상대에게 동기화 하는 동안 전화를 완료 하지 않을 필요가 없다는 것이다. 이것이 많은 NoSQL 시스템이 동작하는 방식인데, 하나의 노드가 로컬에서 업데이트 되면 백그라운드 프로세스가 다른 노드들과 동기화 한다.

유일한 문제는 가끔 일관성을 잃게 될 수도 있다는 것이다. 예를들면, 나에게 온 업데이트 요청을 점원이 미처 아내에게 전달하지 못했는데 아내에게 그 업데이트 사항을 물어보는 전화가 바로 걸려오는 상황이다. 하지만 이는 일반적인 상황은 아닐 수도 있는 것이, 본인이 기억해 달라고 요청한 것을 5분만에 잊어버리고 다시 전화해서 물어보는 상황은 그리 많지 않을 것이기 때문이다.

뱀다리

CAP 이론에 대한 재미있는 아티클이었다.

출처