Please stop calling databases CP or AP #

-- 데이터베이스를 CP 혹은 AP라고 말하는 걸 멈춰주세요.

• 원문: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html Published by Martin Kleppmann on 11 May 2015.
  

This blog post has been translated into Russian, Japanese, and Chinese. For more detail on problems with CAP, and a proposal for an alternative, please see my paper A Critique of the CAP Theorem.
-- 이 블로그 글은 러시아어, 일본어 및 중국어로 번역되었습니다. CAP 관련 문제 및 다른 의견에 대한 좀 더 자세한 내용은 내 논문 CAP이론 비평을 참조하세요.

In his excellent blog post Notes on Distributed Systems for Young Bloods, Jeff Hodges recommends that you use the CAP theorem to critique systems. A lot of people have taken that advice to heart, describing their systems as "CP" (consistent but not available under network partitions), "AP" (available but not consistent under network partitions), or sometimes "CA" (meaning "I still haven’t read Coda’s post from almost 5 years ago").
-- Jeff Hodges의 훌륭한 블로그 글 초보를 위한 분산시스템에 대한 노트에서 그는 여러분이 시스템을 평가하는데 CAP 이론을 사용하기를 권고하고 있습니다. 많은 사람들이 그들의 시스템을 CP(분리된 네트워크하에서 일관성은 있지만 가용성은 없는), AP(분리된 네트워크하에서 가용성은 있지만 일관성은 없는) 때로는 CA("난 아직 거의 5년전의 Coda의 게시글을 아직 읽지 못했다")로 설명하는 지침을 중요하게 받아들여왔습니다.

I agree with all of Jeff’s other points, but with regard to the CAP theorem, I must disagree. The CAP theorem is too simplistic and too widely misunderstood to be of much use for characterizing systems. Therefore I ask that we retire all references to the CAP theorem, stop talking about the CAP theorem, and put the poor thing to rest. Instead, we should use more precise terminology to reason about our trade-offs.
-- 나는 Jeff의 모든 다른 시각에 동의하지만 CAP 이론 관련해서는 동의 할 수 없습니다. CAP 이론은 너무 단순화된 설명이며 시스템의 특성을 설명하기 위해 너무나 많이 잘못 이해된 채로 사용되어지고 있습니다. 그래서 나는 우리가 CAP 이론에 대한 모든 참조를 버리고 또한 그것에 대해 말하는 것도 멈춤으로써 그 불쌍한 것이 쉴 수 있게 되기를 바랍니다. 그 대신, 우리는 절충안을 도출해내기 위해 좀 더 정확한 용어를 사용해야합니다.

(Yes, I realize the irony of writing a blog post about the very topic that I am asking people to stop writing about. But at least it gives me a URL that I can give to people when they ask why I don’t like them talking about the CAP theorem. Also, apologies if this is a bit of a rant, but at least it’s a rant with lots of literature references.)
-- (예, 사람들에게 쓰지 말아달라고 말하는 바로 그 주제에 대한 블로그 글을 쓴다는게 아이러니하다는걸 알고 있습니다. 하지만 적어도 이 블로그 글은, 내가 왜 CAP 이론에 대해 말하는걸 좋아하지 않느냐고 사람들이 질문할 때 내가 줄 수 있는 URL을 가지고 있습니다. 또한 이 글이 약간 무례하다면 사과드립니다. 하지만 많은 문헌적인 참조가 있는 글입니다.)

-- CAP은 매우 좁은 정의를 사용합니다.

If you want to refer to CAP as a theorem (as opposed to a vague hand-wavy concept in your database’s marketing materials), you have to be precise. Mathematics requires precision. The proof only holds if you use the words with the same meaning as they are used in the proof. And the proof uses very particular definitions:
-- 만약 당신이 CAP을 (데이터베이스 마케팅 자료에 있는 모호한 개념이 아닌) 이론으로서 참조하고자 한다면, 당신은 정확히 해야할 필요가 있습니다. 수학에는 정밀함이 필요합니다. 증명이란 그 증명에서 사용된 의미와 동일한 의미를 가진 단어를 사용할 때만 성립됩니다. 그리고 그 증명은 매우 상세한 정의를 사용합니다.

• Consistency in CAP actually means linearizability, which is a very specific (and very strong) notion of consistency. In particular it has got nothing to do with the C in ACID, even though that C also stands for “consistency”. I explain the meaning of linearizability below
  -- CAP에서 일관성이란 실제 선형성을 의미합니다. 그것은 일관성에 대한 매우 구체적인 (그리고 매우 강한) 개념입니다. 특히 ACID에서 C와는 전혀 관련이 없습니다. 비록 그 C가 일관성을 뜻한다고 할지라도 말입니다. 아래에서 선형성을 설명하겠습니다.
  
  
• Availability in CAP is defined as "every request received by a non-failing [database] node in the system must result in a [non-error] response". It’s not sufficient for some node to be able to handle the request: any non-failing node needs to be able to handle it. Many so-called “highly available” (i.e. low downtime) systems actually do not meet this definition of availability.
  -- CAP에서 가용성은 "시스템의 실패하지 않은 [데이터베이스] 노드는 모든 요청에 대해 반드시 [에러가 아닌] 응답을 해야한다"로 정의됩니다. 일부 노드만이 요청을 처리할 수 있게 되는 것은 충분하지 않습니다: 어떠한 무실패 노드라도 그걸 처리할 수 있어야합니다. (낮은 다운타임과 같은)"고가용성"으로 불리는 많은 시스템은 실제 이러한 가용성의 정의를 충족시키지 못합니다.
  
  
• Partition Tolerance (terribly mis-named) basically means that you’re communicating over an asynchronous network that may delay or drop messages. The internet and all our datacenters have this property, so you don’t really have any choice in this matter.
  -- (끔찍히 잘못 이름지어진) 파티션 톨러런스는 기본적으로 메시지 지연이나 유실이 있을 수 있는 비동기 네트워크상에서 커뮤니케이션하고 있다는 걸 의미합니다. 인터넷과 모든 데이터센터는 이러한 속성을 가지고 있기 때문에 사실 이 문제에 대한 어떠한 선택의 여지가 없습니다.
  

Also note that the CAP theorem doesn’t just describe any old system, but a very specific model of a system:
-- 또한 CAP이론이 어떤 오래된 시스템뿐만 아니라 매우 구체적인 시스템 모델도 설명하고 있다는 것을 주목하세요.

• The CAP system model is a single, read-write register – that’s all. For example, the CAP theorem says nothing about transactions that touch multiple objects: they are simply out of scope of the theorem, unless you can somehow reduce them down to a single register.
  -- CAP 시스템 모델은 단일의 읽기 쓰기 레지스터입니다. - 그게 전부입니다. 예를 들어, CAP 이론은 여러 오브젝트를 건드리는 트랜잭션에 대해서 전혀 얘기하지 않습니다: 단일 레지스터로 축소시킬 수 없다면 이 부분은 CAP 이론의 범위를 벗어납니다.
  
  
• The only fault considered by the CAP theorem is a network partition (i.e. nodes remain up, but the network between some of them is not working). That kind of fault absolutely does happen, but it’s not the only kind of thing that can go wrong: nodes can crash or be rebooted, you can run out of disk space, you can hit a bug in the software, etc. In building distributed systems, you need to consider a much wider range of trade-offs, and focussing too much on the CAP theorem leads to ignoring other important issues.
  -- CAP이론에서 고려되는 유일한 실패는 네트워크 파티션입니다. (즉, 노드는 동작하고 있지만 일부 노드 사이의 네트워크는 동작하지 않는 상태입니다.) 그러한 실패는 절대적으로 발생합니다만 그것이 유일한 종류의 오류는 아닙니다: 노드 크래쉬가 발생하거나 리부팅될 수 있고 디스크 공간부족이 발생할 수도 있으며 소프트웨어 버그를 만날 수도 있습니다. 분산 시스템을 구축할 때, 훨씬 넓은 범위의 트레이드오프를 고려해야 하며 CAP 이론에 너무 집중하는 것은 다른 중요한 이슈를 무시하게 만듭니다.
  
  
• Also, the CAP theorem says nothing about latency, which people tend to care about more than availability. In fact, CAP-available systems are allowed to be arbitrarily slow to respond, and can still be called “available”. Going out on a limb, I’d guess that your users wouldn’t call your system “available” if it takes 2 minutes to load a page.
  -- 또한 CAP 이론은 레이턴시에 대해서도 아무런 얘기를 하지 않습니다. 사람들은 가용성보다 레이턴시를 더욱 신경쓰는 경향이 있습니다. 사실, CAP-가능 시스템은 아무때나 응답이 느려질수 있지만 여전히 "가용한 상태"라고 말할 수 있습니다. 극단적으로, 만약 페이지로드에 2분이 걸린다면 사용자들이 여러분의 시스템을 "가용한 상태"라고 말하지는 않을 거라 생각합니다.
  

If your use of words matches the precise definitions of the proof, then the CAP theorem applies to you. But if you’re using some other notion of consistency or availability, you can’t expect the CAP theorem to still apply. Of course, that doesn’t mean you can suddenly do impossible things, just by redefining some words! It just means that you can’t turn to the CAP theorem for guidance, and you cannot use the CAP theorem to justify your point of view.
-- 사용하는 단어가 증명의 정확한 정의와 일치한다면 CAP이론은 적용됩니다. 하지만 만약 일관성이나 가용성이란 단어가 약간 다른 개념으로 사용되는 경우에는 CAP이론이 적용될것이라 기대할 수 없습니다. 물론, 그저 단어 몇 개를 재정의한다고 갑자기 불가능한 것을 할 수 있게 된다는걸 의미하지는 않습니다. 단지 당신이 지침을 얻기 위해 CAP이론에 기댈 수 없으며 또한 당신의 관점을 정당화하기 위해 CAP이론을 사용할 수 없다는 의미입니다.

If the CAP theorem doesn’t apply, that means you have to think through the trade-offs yourself. You can reason about consistency and availability using your own definitions of those words, and you’re welcome to prove your own theorem. But please don’t call it CAP theorem, because that name is already taken.
-- CAP이론이 적용되지 않는다면, 그 절충안을 스스로 생각해야함을 의미합니다. 일관성과 가용성에 대해 당신만의 정의를 사용하여 추론할 수 있으며 당신만의 이론을 증명해보는것도 좋습니다. 하지만 그걸 CAP이론이라고 부르지는 말아주세요. 그 이름은 이미 사용되고 있습니다.

-- 선형화가능성

In case you’re not familiar with linearizability (i.e. “consistency” in the CAP sense), let me explain it briefly. The formal definition is not entirely straightforward, but the key idea, stated informally, is this:
-- 선형화가능성에 익숙치 않다면 (CAP에서의 일관성과 같이), 간략히 설명하겠습니다. 공식적인 정의는 전혀 간단하지 않지만 비공식적으로 언급된 핵심 아이디어는 이것입니다:

To make this more tangible, consider an example of a system that is not linearizable. See the following diagram (sneak preview from an unreleased chapter of my book):
-- 좀 더 실감나게 하기 위해 선형화 불가능한 시스템을 고려해보겠습니다. 다음 다이어그램을 보세요(내 책 미공개 챕터 살짝 미리보기)

This diagram shows Alice and Bob, who are in the same room, both checking their phones to see the outcome of the 2014 football world cup final. Just after the final score is announced, Alice refreshes the page, sees the winner announced, and excitedly tells Bob about it. Bob incredulously hits reload on his own phone, but his request goes to a database replica that is lagging, and so his phone shows that the game is still ongoing.
- 이 다이어그램은 앨리스와 밥이 같은 방에서 각자의 스마트폰으로 2014년 월드컵 결승 결과를 확인하는 모습을 보여주고 있습니다. 최종 점수가 발표된 바로 다음, 앨리스는 페이지를 새로고침한 후 우승자를 확인하고 흥분해서 밥에게 이야기합니다. 밥은 미심쩍어 새로고침을 눌러보지만 밥의 request는 랙상태인 리플리카로 들어가고 전화기에는 아직 경기중으로 표시됩니다.

If Alice and Bob had hit reload at the same time, it wouldn’t have been surprising if they had got two different query results, because they don’t know at exactly what time their respective requests were processed by the server. However, Bob knows that he hit the reload button (initiated his query) after he heard Alice exclaim the final score, and therefore he expects his query result to be at least as recent as Alice’s. The fact that he got a stale query result is a violation of linearizability.
-- 만약 앨리스와 밥이 새로고침을 동시에 눌렀다면 그들이 다른 결과를 얻었다는게 놀라운 일은 아닐 것입니다. 왜냐하면 그들의 요청이 서버에서 언제 처리되었는지 정확히 모르기 때문입니다. 하지만 밥은 자신이 새로고침을 누른(query를 시작한)건 앨리스가 외친 최종점수를 들은 이후라는 걸 알고 있습니다. 그렇기 때문에 자신의 결과가 최소한 앨리스 것보다는 최신일것이라 기대할 것입니다. 그가 갱신되지 않은 결과를 받았다는 사실은 선형화가능성이 위배되었다는 의미합니다.

Knowing that Bob’s request happened strictly after Alice’s request (i.e. that they were not concurrent) depends on the fact that Bob heard about Alice’s query result through a separate communication channel (in this case, IRL audio). If Bob hadn’t heard from Alice that the game was over, he wouldn’t have known that the result of his query was stale.
-- 밥의 request가 정확히 앨리스보다 뒤에 일어났다는 사실을 안다는 것(즉 그들이 동시에 요청하지 않았다는 것)은 밥이 앨리스의 결과를 다른 채널(이 경우 IRL audio)을 통해 들었다는 사실에 달려있습니다. 만일 밥이 앨리스에게서 경기가 끝났다는걸 듣지 못했다면 그는 그의 query 결과가 갱신되지 않은 것임을 알지 못했을것입니다.

If you’re building a database, you don’t know what kinds of backchannel your clients may have. Thus, if you want to provide linearizable semantics (CAP-consistency) in your database, you need to make it appear as though there is only a single copy of the data, even though there may be copies (replicas, caches) of the data in multiple places. [[br]-- 만일 데이터베이스를 구축중이라면 당신은 당신의 client들이 어떠한 다른 채널을 가지고 있는지 알지 못합니다. 그렇기 때문에, 만일 당신이

This is a fairly expensive guarantee to provide, because it requires a lot of coordination. Even the CPU in your computer doesn’t provide linearizable access to your local RAM! On modern CPUs, you need to use an explicit memory barrier instruction in order to get linearizability. And even testing whether a system provides linearizability is tricky.