HighLoad++, Mikhail Tyulenev(MongoDB): 인과적 일관성: 이론에서 실제까지

다음 HighLoad++ 컨퍼런스는 6년 7월 2020일과 XNUMX일에 상트페테르부르크에서 개최됩니다.
세부정보 및 티켓 링크. HighLoad++ 시베리아 2019. "크라스노야르스크" 홀. 25월 12일 00:XNUMX. 논문과 제출.

실제 요구 사항은 상용 제품에 중요한 측면이 고려되지 않는 이론과 충돌하는 경우가 있습니다. 이 강연에서는 상용 제품의 요구 사항을 기반으로 한 학술 연구를 기반으로 인과 일관성 구성 요소를 만들기 위한 다양한 접근 방식을 선택하고 결합하는 프로세스를 제시합니다. 청취자는 논리적 시계, 종속성 추적, 시스템 보안, 시계 동기화에 대한 기존 이론적 접근 방식과 MongoDB가 특정 솔루션을 선택한 이유에 대해 배우게 됩니다.

미하일 튜레네프(이하 MT): – 인과적 일관성에 대해 이야기하겠습니다. 이것은 우리가 MongoDB에서 작업한 기능입니다. 저는 분산 시스템 그룹에서 일하고 있습니다. 우리는 약 XNUMX년 전에 일했습니다.

그 과정에서 이 기능은 꽤 잘 연구되었기 때문에 많은 학문적 연구에 익숙해져야 했습니다. 프로덕션 애플리케이션에 존재할 수 있는 매우 구체적인 요구 사항으로 인해 프로덕션 데이터베이스에 필요한 내용에 맞는 기사가 하나도 없는 것으로 나타났습니다.

저는 학술 연구의 소비자로서 우리가 그로부터 무언가를 준비하여 사용자에게 편리하고 안전하게 사용할 수 있는 기성품으로 제공할 수 있는 방법에 대해 이야기하겠습니다.

인과적 일관성. 개념을 정의해보자

우선, 인과적 일관성이 무엇인지 일반적인 용어로 말하고 싶습니다. 두 명의 캐릭터가 있습니다 - Leonard와 Penny(TV 시리즈 "The Big Bang Theory"):

Penny가 유럽에 있고 Leonard가 그녀에게 깜짝 파티를 열고 싶어한다고 가정해 보겠습니다. 그리고 그는 그녀를 친구 목록에서 제외하고 모든 친구들에게 피드에 대한 업데이트를 보내는 것보다 더 나은 것을 생각할 수 없습니다. "페니를 행복하게 합시다!" (그녀는 유럽에 있는데, 자는 동안에는 이 모든 것을 보지 못하고 거기에 없기 때문에 볼 수도 없습니다). 결국 그녀는 이 게시물을 삭제하고 피드에서 삭제한 후 액세스 권한을 복원하여 아무것도 눈치채지 못하고 스캔들이 발생하지 않도록 합니다.
이것은 모두 훌륭하지만 시스템이 분산되어 있고 상황이 약간 잘못되었다고 가정해 보겠습니다. 예를 들어, 사건이 원인과 결과로 관련되지 않은 경우 이 게시물이 표시된 후 페니의 접근 제한이 발생한 경우가 발생할 수 있습니다. 실제로 이는 비즈니스 기능을 수행하기 위해 인과적 일관성이 필요한 경우(이 경우)의 예입니다.

실제로 이것은 데이터베이스의 매우 사소한 속성입니다. 이를 지원하는 사람은 거의 없습니다. 모델로 넘어 갑시다.

일관성 모델

데이터베이스의 일관성 모델은 정확히 무엇입니까? 이는 분산 시스템이 클라이언트가 어떤 데이터를 어떤 순서로 수신할 수 있는지에 대해 제공하는 보장 중 일부입니다.

원칙적으로 모든 일관성 모델은 분산 시스템이 예를 들어 노트북의 한 노드에서 실행되는 시스템과 얼마나 유사한지에 따라 결정됩니다. 이는 지리적으로 분산된 수천 개의 "노드"에서 실행되는 시스템이 원칙적으로 모든 속성이 자동으로 수행되는 노트북과 얼마나 유사한지 보여줍니다.

따라서 일관성 모델은 분산 시스템에만 적용됩니다. 이전에 동일한 수직 확장으로 존재하고 작동했던 모든 시스템에서는 이러한 문제가 발생하지 않았습니다. 버퍼 캐시가 하나 있었고 항상 여기에서 모든 것을 읽었습니다.

강한 모델

실제로 첫 번째 모델은 Strong(또는 종종 상승 능력 라인이라고 부름)입니다. 이는 모든 변경 사항이 발생했음이 확인되면 시스템의 모든 사용자가 볼 수 있도록 보장하는 일관성 모델입니다.

이는 데이터베이스에 있는 모든 이벤트의 전역 순서를 생성합니다. 이는 매우 강력한 일관성 속성이며 일반적으로 매우 비쌉니다. 그러나 매우 잘 지원됩니다. 가격이 매우 비싸고 느리기 때문에 거의 사용되지 않습니다. 이것을 상승 능력이라고 합니다.

Spanner에서 지원되는 또 다른 강력한 속성인 외부 일관성(External Consistency)이 있습니다. 그것에 대해서는 조금 나중에 이야기하겠습니다.

인과

다음은 인과관계(Causal)입니다. 바로 제가 말했던 것입니다. Strong과 Causal 사이에는 내가 언급하지 않을 하위 수준이 몇 가지 더 있지만, 모두 Causal로 귀결됩니다. 이는 모든 모델 중에서 가장 강력하고 네트워크나 파티션이 있을 때 가장 강력한 일관성을 갖기 때문에 중요한 모델입니다.

인과관계는 실제로 사건이 원인과 결과의 관계로 연결된 상황입니다. 매우 자주 그들은 고객의 관점에서 귀하의 권리를 읽는 것으로 인식됩니다. 클라이언트가 일부 값을 관찰한 경우 과거의 값을 볼 수 없습니다. 그는 이미 접두사 수치를 보기 시작했습니다. 그것은 모두 같은 것으로 귀결됩니다.
일관성 모델로서의 인과 관계는 모든 클라이언트의 이벤트가 동일한 순서로 관찰되는 서버 이벤트의 부분 순서입니다. 이 경우에는 Leonard와 Penny가 있습니다.

최종의

세 번째 모델은 최종 일관성입니다. 이것은 절대적으로 모든 분산 시스템이 지원하는 것이며 전혀 의미가 있는 최소 모델입니다. 이는 다음을 의미합니다. 데이터에 일부 변경이 있으면 어느 시점에서는 일관성이 유지됩니다.

그런 순간에 그녀는 아무 말도 하지 않습니다. 그렇지 않으면 그녀는 외부 일관성으로 변할 것입니다. 그것은 완전히 다른 이야기가 될 것입니다. 그럼에도 불구하고 이것은 매우 인기 있고 가장 일반적인 모델입니다. 기본적으로 분산 시스템의 모든 사용자는 최종 일관성을 사용합니다.

몇 가지 비교 예를 제시하고 싶습니다.

이 화살표는 무엇을 의미하나요?

• 지연 시간. 일관성 강도가 증가함에 따라 분명한 이유 때문에 더 커집니다. 더 많은 레코드를 만들어야 하고 클러스터에 참여하는 모든 호스트와 노드로부터 데이터가 이미 있다는 확인을 받아야 합니다. 따라서 최종 일관성은 가장 빠른 답변을 제공합니다. 원칙적으로 이를 메모리에 커밋할 수도 있고 원칙적으로 이것으로 충분하기 때문입니다.
• 유효성. 이것을 네트워크 중단, 파티션 또는 일종의 오류가 있을 때 시스템이 대응할 수 있는 능력으로 이해한다면 일관성 모델이 감소함에 따라 내결함성은 증가합니다. 왜냐하면 하나의 호스트가 동시에 존재하는 것으로 충분하기 때문입니다. 시간이 지나면 데이터가 생성됩니다. 최종 일관성은 데이터에 대해 전혀 보장하지 않으며 무엇이든 될 수 있습니다.
• 이상. 동시에 이상 현상의 수도 증가합니다. Strong Consistency에서는 거의 존재하지 않아야 하지만, Eventual Consistency에서는 무엇이든 될 수 있습니다. 문제가 발생합니다. 이상이 포함되어 있으면 사람들이 최종 일관성을 선택하는 이유는 무엇입니까? 대답은 최종 일관성 모델이 적용 가능하고 예를 들어 짧은 시간 내에 예외가 존재한다는 것입니다. 마법사를 사용하여 일관된 데이터를 읽고 어느 정도 읽을 수 있습니다. 강력한 일관성 모델을 사용하는 것이 가능한 경우가 많습니다. 실제로 이는 효과가 있으며 종종 이상 현상의 수가 시간에 따라 제한됩니다.

CAP 정리

일관성, 가용성이라는 단어를 보면 무엇이 떠오르나요? 맞습니다 - CAP 정리! 이제 저는 그 신화를 불식시키고 싶습니다... 제가 아닙니다. 훌륭한 기사, 훌륭한 책을 쓴 사람은 Martin Kleppmann입니다.

CAP 정리는 일관성, 가용성, 파티션 중 두 가지를 선택하면 세 가지를 선택할 수 없다는 2000년대에 공식화된 원칙입니다. 그것은 특정한 원칙이었습니다. 이는 몇 년 후 길버트와 린치에 의해 정리로 입증되었습니다. 그런 다음 이것이 진언으로 사용되기 시작했습니다. 시스템은 CA, CP, AP 등으로 나뉘기 시작했습니다.

이 정리는 실제로 다음과 같은 경우에 입증되었습니다... 첫째, 가용성은 0에서 수백까지의 연속 값으로 간주되지 않았습니다(100 - 시스템이 "죽음", XNUMX - 빠르게 응답함. 우리는 그렇게 생각하는 데 익숙함) , 그러나 모든 실행에 대해 데이터 반환을 보장하는 알고리즘의 속성입니다.

응답 시간에 대한 단어는 전혀 없습니다! 100년 후에 데이터를 반환하는 알고리즘이 있습니다. 이는 CAP 정리의 일부인 매우 놀라운 사용 가능한 알고리즘입니다.
둘째, 이러한 변경 사항의 크기를 조정할 수 있음에도 불구하고 동일한 키 값의 변경 사항에 대한 정리가 입증되었습니다. 이는 모델이 최종 일관성, 강력한 일관성(아마도)이 다르기 때문에 실제로 실제로 사용되지 않음을 의미합니다.

이게 다 뭐죠? 더욱이, 증명된 것과 똑같은 형태의 CAP 정리는 실질적으로 적용 가능하지 않으며 거의 ​​사용되지 않습니다. 이론적 형태에서는 어떻게든 모든 것을 제한합니다. 직관적으로는 정확하지만 일반적으로 입증되지 않은 특정 원리가 밝혀졌습니다.

인과적 일관성이 가장 강력한 모델이다

지금 일어나고 있는 일은 파티션을 사용하여 일관성, 가용성이라는 세 가지를 모두 얻을 수 있다는 것입니다. 특히, 인과적 일관성은 파티션(네트워크 중단)이 있는 경우에도 여전히 작동하는 가장 강력한 일관성 모델입니다. 이것이 바로 그것이 그토록 큰 관심을 끄는 이유이고, 우리가 그것을 채택한 이유입니다.

첫째, 애플리케이션 개발자의 작업을 단순화합니다. 특히, 서버의 강력한 지원이 존재합니다. 한 클라이언트 내부에서 발생하는 모든 레코드가 다른 클라이언트에 동일한 순서로 도착하는 것이 보장됩니다. 둘째, 파티션을 견딜 수 있습니다.

MongoDB 내부 주방

점심이라는 것을 기억하고 부엌으로 이동합니다. 이런 데이터베이스에 대해 처음 듣는 분들을 위해 시스템 모델, 즉 MongoDB가 무엇인지 알려드리겠습니다.

MongoDB(이하 “MongoDB”)는 수평적 확장, 즉 샤딩(Sharding)을 지원하는 분산 시스템입니다. 각 샤드 내에서는 데이터 중복성, 즉 복제도 지원합니다.

MongoDB(관계형 데이터베이스 아님)의 샤딩은 자동 밸런싱을 수행합니다. 즉, 각 문서 모음(또는 관계형 데이터 측면에서 "테이블")을 여러 조각으로 나누고 서버가 이를 샤드 간에 자동으로 이동합니다.

클라이언트에 대한 요청을 배포하는 쿼리 라우터는 작동하는 일부 클라이언트입니다. 이는 데이터가 어디에 있고 어떤 데이터가 있는지 이미 알고 있으며 모든 요청을 올바른 샤드로 보냅니다.

또 다른 중요한 점: MongoDB는 단일 마스터입니다. 하나의 기본이 있습니다. 여기에는 포함된 키를 지원하는 레코드가 필요할 수 있습니다. 다중 마스터 쓰기를 수행할 수 없습니다.

우리는 릴리스 4.2를 만들었습니다. 거기에 새로운 흥미로운 것들이 나타났습니다. 특히 Lucene(검색), 즉 실행 가능한 java를 Mongo에 직접 삽입하여 Elastica와 마찬가지로 Lucene을 통한 검색이 가능해졌습니다.

그리고 그들은 새로운 제품인 차트를 만들었습니다. 이는 Atlas(Mongo의 자체 클라우드)에서도 사용할 수 있습니다. 그들은 무료 등급을 가지고 있습니다 - 당신은 그것을 가지고 놀 수 있습니다. 저는 차트를 정말 좋아했습니다. 데이터 시각화가 매우 직관적이었습니다.

성분 인과적 일관성

나는 이 주제에 관해 Leslie Lampert가 출판한 약 230개의 기사를 세었습니다. 이제 내 기억을 바탕으로 이 자료의 일부를 여러분에게 전달하겠습니다.

모든 것은 1970년대에 작성된 Leslie Lampert의 기사에서 시작되었습니다. 보시다시피, 이 주제에 대한 일부 연구가 아직 진행 중입니다. 이제 인과적 일관성은 분산 시스템 개발과 관련하여 관심을 받고 있습니다.

제한

어떤 제한사항이 있나요? 이는 실제로 주요 요점 중 하나입니다. 왜냐하면 생산 시스템이 부과하는 제한은 학술 논문에 존재하는 제한과 매우 다르기 때문입니다. 그들은 종종 매우 인공적입니다.

• 첫째, 이미 말했듯이 "MongoDB"는 단일 마스터입니다(이것은 매우 단순화됩니다).
• 우리는 시스템이 약 10개의 샤드를 지원해야 한다고 믿습니다. 우리는 이 값을 명시적으로 제한하는 아키텍처 결정을 내릴 수 없습니다.
• 우리는 클라우드를 가지고 있지만 바이너리를 다운로드하고 노트북에서 실행하면 모든 것이 잘 작동할 수 있는 기회가 여전히 있어야 한다고 가정합니다.
• 우리는 Research가 거의 가정하지 않는 것을 가정합니다. 즉, 외부 클라이언트는 원하는 것은 무엇이든 할 수 있습니다. MongoDB는 오픈 소스입니다. 따라서 고객은 매우 영리하고 화를 낼 수 있습니다. 모든 것을 깨뜨리고 싶어할 수 있습니다. 우리는 비잔틴 페일러(Byzantine Feilors)가 유래했을 것이라고 추측합니다.
• 경계 외부에 있는 외부 클라이언트의 경우 중요한 제한 사항이 있습니다. 이 기능을 비활성화하면 성능 저하가 관찰되지 않습니다.
• 또 다른 요점은 일반적으로 반 학문적입니다. 즉, 이전 버전과 향후 버전의 호환성입니다. 이전 드라이버는 새 업데이트를 지원해야 하며 데이터베이스는 이전 드라이버를 지원해야 합니다.

일반적으로 이 모든 것에는 제한이 따릅니다.

인과적 일관성 구성요소

이제 몇 가지 구성 요소에 대해 이야기하겠습니다. 일반적으로 인과적 일관성을 고려하면 블록을 선택할 수 있습니다. 우리는 특정 블록에 속하는 작업 중에서 선택했습니다. 의존성 추적, 시계 선택, 이러한 시계가 서로 동기화되는 방법 및 보안을 보장하는 방법 - 이것이 제가 이야기할 내용에 대한 대략적인 개요입니다.

전체 종속성 추적

왜 필요한가요? 따라서 데이터가 복제될 때 각 레코드, 각 데이터 변경 사항에는 해당 데이터가 어떤 변경 사항에 의존하는지에 대한 정보가 포함됩니다. 가장 첫 번째이자 순진한 변화는 레코드가 포함된 각 메시지에 이전 메시지에 대한 정보가 포함되어 있다는 것입니다.

이 예에서 중괄호 안의 숫자는 레코드 번호입니다. 때로는 값이 포함된 이러한 레코드 전체가 전송되기도 하고 일부 버전이 전송되기도 합니다. 결론은 각 변경 사항에는 이전 변경 사항에 대한 정보가 포함되어 있다는 것입니다(물론 이 모든 내용은 자체적으로 전달됩니다).

이 접근 방식(전체 추적)을 사용하지 않기로 결정한 이유는 무엇입니까? 분명히 이 접근 방식은 비실용적입니다. 소셜 네트워크에 대한 모든 변경 사항은 모든 업데이트에서 Facebook 또는 VKontakte를 전송하는 등 해당 소셜 네트워크의 모든 이전 변경 사항에 따라 달라집니다. 그럼에도 불구하고 완전 의존성 추적에 대한 많은 연구가 있습니다. 이는 소셜 네트워크 이전에 존재하며 일부 상황에서는 실제로 작동합니다.

명시적 종속성 추적

다음은 더 제한적입니다. 여기서는 정보 전송도 고려되지만 명확하게 종속된 정보만 고려됩니다. 원칙적으로 무엇에 따라 달라지는지는 응용 프로그램에 의해 결정됩니다. 데이터가 복제되면 쿼리는 이전 종속성이 충족된 경우, 즉 표시된 경우에만 응답을 반환합니다. 이것이 인과적 일관성이 작동하는 방식의 본질입니다.

그녀는 레코드 5가 레코드 1, 2, 3, 4에 의존한다는 것을 확인합니다. 따라서 이전의 모든 변경 사항이 이미 데이터베이스를 통과했을 때 클라이언트가 Penny의 액세스 결정에 따른 변경 사항에 액세스할 수 있을 때까지 기다립니다.

아직 정보가 너무 많아서 속도가 느려지므로 이는 우리에게도 적합하지 않습니다. 또 다른 접근법이 있습니다 ...

램포트 시계

그들은 아주 오래되었습니다. Lamport Clock은 이러한 종속성이 Lamport Clock이라는 스칼라 함수로 접혀 있음을 의미합니다.

스칼라 함수는 추상 숫자입니다. 흔히 논리적 시간이라고 부른다. 각 이벤트마다 이 카운터가 증가합니다. 현재 프로세스에 알려진 카운터는 각 메시지를 보냅니다. 프로세스가 동기화되지 않을 수 있고 완전히 다른 시간을 가질 수 있다는 것은 분명합니다. 그럼에도 불구하고 시스템은 어떻게든 그러한 메시지와 시계의 균형을 맞춥니다. 이 경우 어떻게 되나요?

명확하게 하기 위해 큰 조각을 두 개로 나눴습니다. 친구는 컬렉션의 일부가 포함된 한 노드에 살 수 있고 Feed는 이 컬렉션의 일부가 포함된 다른 노드에 살 수 있습니다. 그들이 어떻게 줄을 벗어날 수 있는지 분명합니까? 첫 번째 피드에는 "복제됨"이라고 표시되고 그 다음에는 친구가 표시됩니다. 시스템이 Friends 컬렉션의 Friends 종속성도 전달될 때까지 피드가 표시되지 않는다는 일종의 보장을 제공하지 않으면 제가 언급한 상황과 정확히 일치하게 됩니다.

Feed의 카운터 시간이 논리적으로 어떻게 증가하는지 확인하세요.

따라서 이 Lamport 시계 및 인과 관계 일관성(Lamport 시계를 통해 설명됨)의 주요 속성은 다음과 같습니다. 이벤트 A와 B가 있고 이벤트 B가 이벤트 A*에 의존하는 경우 이벤트 A의 LogicalTime은 다음보다 작습니다. 이벤트 B의 LogicalTime

* 때때로 그들은 A가 B보다 먼저 일어났다고 말합니다. 즉, A가 B보다 먼저 일어났다는 것입니다. 이것은 일반적으로 발생한 전체 사건 집합을 부분적으로 정렬하는 특정 관계입니다.

그 반대는 올바르지 않습니다. 이것은 실제로 Lamport Clock의 주요 단점 중 하나인 부분 주문입니다. 동시 사건, 즉 (A가 B보다 먼저 일어났음)도 아니고 (A가 B보다 먼저 일어났음)도 아닌 사건에 대한 개념이 있습니다. 예를 들어 Leonard가 다른 사람을 친구로 추가하는 경우가 있습니다(예를 들어 Leonard가 아니라 Sheldon도 마찬가지입니다).
이것은 Lamport 시계로 작업할 때 자주 사용되는 속성입니다. 그들은 기능을 구체적으로 살펴보고 이로부터 아마도 이러한 이벤트가 종속적일 수 있다고 결론을 내립니다. 한 가지 방법이 사실이기 때문에 LogicalTime A가 LogicalTime B보다 작으면 B는 A보다 먼저 발생할 수 없습니다. 그 이상이라면 아마도요.

벡터 시계

Lamport 시계의 논리적 발전은 벡터 시계입니다. 여기에 있는 각 노드에는 자체 별도의 클럭이 포함되어 있으며 벡터로 전송된다는 점이 다릅니다.
이 경우 벡터의 1번째 인덱스는 Feed를 담당하고 벡터의 첫 번째 인덱스는 Friends(각 노드)를 담당한다는 것을 알 수 있습니다. 그리고 이제 그들은 증가할 것입니다: 글을 쓸 때 “Feed”의 2 지수는 3, XNUMX, XNUMX으로 증가합니다:

벡터 클럭이 더 나은 이유는 무엇입니까? 이를 통해 어떤 이벤트가 동시에 발생하는지, 언제 다른 노드에서 발생하는지 파악할 수 있기 때문입니다. 이는 MongoDB와 같은 샤딩 시스템에 매우 중요합니다. 그러나 우리는 이것을 선택하지 않았습니다. 비록 그것이 훌륭한 일이고 훌륭하게 작동하며 아마도 우리에게 적합할 것입니다...

샤드가 10개인 경우 압축하거나 다른 것을 생각해내더라도 10개의 구성 요소를 전송할 수 없습니다. 페이로드는 여전히 이 전체 벡터의 볼륨보다 몇 배 더 작습니다. 그러므로 우리는 마음과 이를 악물고 이 접근 방식을 포기하고 다른 접근 방식으로 전환했습니다.

스패너 트루타임. 원자시계

스패너에 대한 이야기가 있을 거라고 했어요. 이것은 XNUMX세기에 나온 멋진 일입니다. 원자 시계, GPS 동기화입니다.

무슨 아이디어야? "Spanner"는 최근 사람들이 사용할 수 있게 된 Google 시스템입니다(SQL이 추가되었습니다). 각 거래에는 타임 스탬프가 있습니다. 시간은 동기화*되므로 각 이벤트에 특정 시간이 할당될 수 있습니다. 원자 시계에는 대기 시간이 있으며 그 후에는 다른 시간이 "발생"하는 것이 보장됩니다.

따라서 간단히 데이터베이스에 쓰고 일정 시간 동안 기다리면 이벤트의 직렬화가 자동으로 보장됩니다. 그들은 원칙적으로 상상할 수 있는 가장 강력한 일관성 모델을 가지고 있습니다. 이것이 바로 외부 일관성입니다.

* 이것이 Lampart 시계의 주요 문제점입니다. 분산 시스템에서는 결코 동기화되지 않습니다. 그들은 갈라질 수 있으며 NTP를 사용하더라도 여전히 잘 작동하지 않습니다. "Spanner"에는 원자 시계가 있으며 동기화는 마이크로초인 것 같습니다.

우리는 왜 선택하지 않았나요? 우리는 사용자에게 원자 시계가 내장되어 있다고 가정하지 않습니다. 모든 노트북에 내장된 시계가 나타나면 일종의 매우 멋진 GPS 동기화 기능이 있을 것입니다. 그렇다면 그렇습니다... 하지만 현재로선 가능한 최고는 Amazon, 베이스 스테이션입니다. 광신자를 위한... 그래서 우리는 다른 시계를 사용했습니다. .

하이브리드 시계

이는 실제로 인과적 일관성을 보장할 때 MongoDB에서 확인하는 사항입니다. 그들은 어떻게 하이브리드입니까? 하이브리드는 스칼라 값이지만 두 가지 구성 요소가 있습니다.

• 첫 번째는 Unix 시대(“컴퓨터 세계의 시작” 이후 몇 초가 지났는지)입니다.
• 두 번째는 약간의 증분이며 역시 32비트 unsigned int입니다.

실제로 그게 전부입니다. 다음과 같은 접근 방식이 있습니다. 시간을 담당하는 부분은 항상 시계와 동기화됩니다. 업데이트가 발생할 때마다 이 부분이 시계와 동기화되어 시간이 항상 어느 정도 정확하다는 사실이 밝혀지며, 증분을 통해 동일한 시점에 발생한 이벤트를 구분할 수 있습니다.

이것이 MongoDB에 왜 중요한가요? 특정 시점에 일종의 백업 레스토랑을 만들 수 있기 때문에, 즉 이벤트가 시간별로 색인화됩니다. 이는 특정 이벤트가 필요할 때 중요합니다. 데이터베이스의 경우 이벤트는 특정 시간 간격으로 발생한 데이터베이스의 변경 사항입니다.

가장 중요한 이유는 당신에게만 알려드릴게요(아무에게도 말하지 마세요)! 우리가 이렇게 한 이유는 이것이 MongoDB OpLog에서 조직화되고 인덱싱된 데이터처럼 보이기 때문입니다. OpLog는 데이터베이스의 모든 변경 사항을 포함하는 데이터 구조입니다. 먼저 OpLog로 이동한 다음 복제된 날짜 또는 샤드인 경우 스토리지 자체에 적용됩니다.

이것이 주된 이유였습니다. 하지만 데이터베이스를 개발하기 위한 실제적인 요구 사항도 있습니다. 즉, 데이터베이스는 단순해야 합니다. 즉, 코드가 적고 다시 작성하고 테스트해야 하는 손상된 항목이 가능한 한 적어야 합니다. 우리의 oplog가 하이브리드 시계에 의해 색인화되었다는 사실은 많은 도움이 되었고 올바른 선택을 할 수 있게 해주었습니다. 그것은 정말 큰 성과를 거두었고 첫 번째 프로토타입에서 마법처럼 작동했습니다. 매우 멋졌습니다!

시계 동기화

과학 문헌에는 여러 가지 동기화 방법이 설명되어 있습니다. 저는 두 개의 서로 다른 샤드가 있을 때의 동기화에 대해 이야기하고 있습니다. 하나의 복제본 세트가 있는 경우 동기화가 필요하지 않습니다. 이는 "단일 마스터"입니다. 모든 변경 사항이 포함되는 OpLog가 있습니다. 이 경우 모든 것이 이미 "Oplog" 자체에 순차적으로 정렬되어 있습니다. 하지만 두 개의 서로 다른 샤드가 있는 경우 여기서는 시간 동기화가 중요합니다. 이것은 벡터 시계가 더 도움이 된 부분입니다! 하지만 우리에겐 그런 것들이 없습니다.

두 번째가 적합합니다. 이것은 "Heartbeats"입니다. 단위 시간마다 발생하는 일부 신호를 교환하는 것이 가능합니다. 하지만 하트비트가 너무 느려서 클라이언트에 대기 시간을 제공할 수 없습니다.

물론 진정한 시간은 놀라운 것입니다. 그러나 다시 말하지만, 이것은 아마도 미래일 것입니다... Atlas에서 이미 수행할 수 있지만 이미 빠른 "Amazon" 시간 동기화 장치가 있습니다. 하지만 모든 사람이 이용할 수 있는 것은 아닙니다.

험담은 모든 메시지에 시간이 포함되는 경우입니다. 이것이 대략 우리가 사용하는 것입니다. 노드, 드라이버, 데이터 노드 라우터 사이의 모든 메시지, MongoDB의 모든 것은 일종의 요소, 즉 실행되는 시계를 포함하는 데이터베이스 구성 요소입니다. 그들은 어디에서나 하이브리드 시간의 의미를 가지고 전달됩니다. 64비트? 이것은 가능합니다.

이 모든 것이 어떻게 함께 작동합니까?

여기에서는 좀 더 쉽게 만들기 위해 하나의 복제 세트를 보고 있습니다. 초등과 중등이 있습니다. 보조는 복제를 수행하며 항상 기본과 완전히 동기화되지는 않습니다.

특정 시간 값으로 "Primery"에 삽입이 발생합니다. 이 삽입은 내부 개수를 11만큼 증가시킵니다(이것이 최대값인 경우). 또는 시계 값을 확인하고 시계 값이 더 크면 시계에 동기화합니다. 이렇게 하면 시간별로 정리할 수 있습니다.

그가 녹음을 하고 나면 중요한 순간이 일어난다. 시계는 "MongoDB"에 있으며 "Oplog"에 쓰는 경우에만 증가됩니다. 이는 시스템 상태를 변경하는 이벤트입니다. 모든 고전 기사에서 이벤트는 메시지가 노드에 도달할 때로 간주됩니다. 즉, 메시지가 도착했으며 이는 시스템 상태가 변경되었음을 의미합니다.

이는 연구 중에 이 메시지가 어떻게 해석될지 완전히 명확하지 않기 때문입니다. 우리는 그것이 "Oplog"에 반영되지 않으면 어떤 식으로든 해석되지 않으며 시스템 상태의 변경은 "Oplog"의 항목일 뿐이라는 것을 확실히 알고 있습니다. 이는 우리에게 모든 것을 단순화시킵니다. 모델은 이를 단순화하고 하나의 복제본 세트 내에서 구성할 수 있도록 하며 기타 많은 유용한 기능을 제공합니다.

"Oplog"에 이미 기록된 값이 반환됩니다. "Oplog"에 이미 이 값이 포함되어 있고 시간은 12라는 것을 알고 있습니다. 이제 읽기가 다른 노드(보조)에서 시작되고 afterClusterTime이 전송됩니다. 메시지. 그는 이렇게 말합니다. “적어도 12시 이후나 XNUMX시 동안 일어난 모든 일이 필요합니다.”(위 그림 참조)

이것이 바로 인과관계(CAT)라고 불리는 것입니다. 이론적으로는 이것이 그 자체로 일관된 시간 조각이라는 개념이 있습니다. 이 경우 12시점에 관찰된 시스템의 상태라고 할 수 있다.

이제 여기에는 아직 아무것도 없습니다. 이는 기본에서 데이터를 복제하기 위해 보조가 필요한 상황을 시뮬레이션하기 때문입니다. 그는 기다립니다... 이제 데이터가 도착했습니다. 그는 이 값을 다시 반환합니다.

그것이 모든 것이 거의 작동하는 방식입니다. 거의.

"거의"은(는) 무슨 뜻인가요? 이 모든 것이 어떻게 작동하는지 읽고 이해한 사람이 있다고 가정해 봅시다. ClusterTime이 발생할 때마다 내부 논리 시계가 업데이트되고 다음 항목이 20씩 증가한다는 것을 깨달았습니다. 이 함수는 64줄을 사용합니다. 이 사람이 XNUMX을 뺀 가장 큰 XNUMX비트 숫자를 전송한다고 가정해 보겠습니다.

왜 "마이너스 XNUMX"인가요? 내부 시계가 이 값으로 대체되기 때문에(분명히 이것은 가능한 가장 크고 현재 시간보다 큽니다) "Oplog"에 항목이 발생하고 시계는 다른 단위로 증가됩니다. 최대값이 되어야 합니다(단순히 모든 단위가 있고 더 이상 갈 곳이 없습니다), unsaint int).

그 후에는 시스템에 어떤 것도 절대 접근할 수 없게 되는 것이 분명합니다. 언로드 및 청소만 가능합니다. 많은 수작업이 필요합니다. 전체 가용성:

게다가 이것이 다른 곳에서 복제되면 전체 클러스터가 단순히 다운됩니다. 누구나 아주 빠르고 쉽게 정리할 수 있는 절대 용납할 수 없는 상황! 그러므로 우리는 이 순간을 가장 중요한 순간 ​​중 하나로 여겼습니다. 그것을 방지하는 방법?

우리의 방법은 ClusterTime에 서명하는 것입니다.

이것이 메시지에서 전송되는 방식입니다(파란색 텍스트 앞). 그러나 우리는 또한 서명(파란색 텍스트)을 생성하기 시작했습니다.

서명은 보안 경계 내부의 데이터베이스 내부에 저장된 키에 의해 생성됩니다. 자체가 생성되고 업데이트됩니다(사용자는 이에 대해 아무것도 볼 수 없음). 해시가 생성되고 각 메시지는 생성될 때 서명되고 수신될 때 유효성이 검사됩니다.
아마도 사람들의 마음 속에는 "이것이 얼마나 속도를 늦추는가?"라는 질문이 떠오를 것입니다. 특히 이 기능이 없는 경우에는 빠르게 작동할 것이라고 말씀드렸습니다.

이 경우 인과적 일관성을 사용한다는 것은 무엇을 의미합니까? 이는 afterClusterTime 매개변수를 표시하기 위한 것입니다. 이것이 없으면 어쨌든 단순히 값을 전달하게 됩니다. 버전 3.6부터 험담은 항상 작동합니다.

지속적인 서명 생성을 방치하면 기능이 없어도 시스템 속도가 느려지므로 접근 방식과 요구 사항을 충족하지 못합니다. 그래서 우리는 무엇을 했나요?

빨리 하세요!

꽤 간단한 일이지만 요령은 흥미롭습니다. 공유하겠습니다. 아마도 누군가가 관심을 가질 것입니다.
서명된 데이터를 저장하는 해시가 있습니다. 모든 데이터는 캐시를 통과합니다. 캐시는 특정 시간을 서명하지 않고 범위를 서명합니다. 어떤 값이 도착하면 Range를 생성하고 마지막 16비트를 마스크 처리한 후 다음 값에 서명합니다.

이러한 서명을 수신함으로써 우리는 시스템 속도를 (상대적으로) 65배 향상시킵니다. 훌륭하게 작동합니다. 실험을 수행했을 때 순차적 업데이트를 수행했을 때 실제로 시간이 10배 감소했습니다. 그들이 서로 충돌하면 이것이 작동하지 않는다는 것이 분명합니다. 그러나 대부분의 실제 사례에서는 작동합니다. Range 서명과 서명의 조합으로 보안 문제가 해결되었습니다.

우리는 무엇을 배웠습니까?

우리가 여기서 배운 교훈은 다음과 같습니다.

• 흥미로운 것들이 많기 때문에 자료, 이야기, 기사를 읽어야합니다. 일부 기능을 작업할 때(특히 지금은 트랜잭션을 수행할 때 등) 읽고 이해해야 합니다. 시간이 걸리지만 우리가 어디에 있는지 명확하게 알려주기 때문에 실제로 매우 유용합니다. 우리는 새로운 것을 생각해 내지 못한 것 같았습니다. 단지 재료만 가져갔을 뿐입니다.

  일반적으로 학술회의(예: Sigmon)가 있을 때 사고에는 어느 정도 차이가 있습니다. 모두가 새로운 아이디어에 집중합니다. 우리 알고리즘의 새로운 점은 무엇입니까? 여기에는 특별히 새로운 것이 없습니다. 오히려 참신함은 기존 접근 방식을 함께 혼합하는 방식에 있습니다. 그러므로 가장 먼저 할 일은 Lampart부터 시작하여 고전을 읽는 것입니다.

• 생산 과정에서는 요구 사항이 완전히 다릅니다. 여러분 중 많은 분들이 추상적인 공백 상태의 "구형" 데이터베이스가 아니라 가용성, 대기 시간 및 내결함성에 문제가 있는 정상적이고 실제적인 데이터베이스에 직면하고 있다고 확신합니다.
• 마지막으로 우리는 서로 다른 아이디어를 살펴보고 완전히 다른 여러 기사를 하나의 접근 방식으로 결합해야 했습니다. 예를 들어, 서명에 대한 아이디어는 일반적으로 Paxos 프로토콜을 고려한 기사에서 나왔는데, 비잔틴 실패자의 경우 승인 프로토콜 내부에 있고, 비잔틴 실패자의 경우 승인 프로토콜 외부에 있습니다... 일반적으로 이것이 바로 우리가 하는 것입니다. 하고 끝났습니다.

  여기에는 전혀 새로운 것이 없습니다! 하지만 다 섞자마자... 계란, 마요네즈, 오이가 이미 발명되었기 때문에 올리비에 샐러드 레시피가 말도 안된다고 말하는 것과 같습니다... 거의 같은 이야기입니다.

이것으로 마치겠습니다. 감사합니다!

질문

청중(이하 B)의 질문: – 보고서를 보내주신 Mikhail에게 감사드립니다! 시간에 관한 주제가 흥미롭습니다. 험담을 사용하고 있습니다. 모든 사람은 자신만의 시간이 있고, 모두가 자신의 현지 시간을 알고 있다고 말했습니다. 내가 이해하는 바에 따르면 우리에게는 드라이버가 있습니다. 드라이버, 쿼리 플래너, 샤드 등을 가진 많은 클라이언트가 있을 수 있습니다. 갑자기 불일치가 발생하면 시스템은 어떻게 될까요? XNUMX분 전, 누군가 XNUMX분 늦었나요? 우리는 어디로 갈 것인가?

산: – 정말 좋은 질문입니다! 나는 단지 샤드에 대해 이야기하고 싶었습니다. 질문을 올바르게 이해하면 다음과 같은 상황이 발생합니다. 샤드 1과 샤드 2가 있고 이 두 샤드에서 읽기가 발생합니다. 두 샤드에는 불일치가 있고, 알고 있는 시간이 다르기 때문에 서로 상호 작용하지 않습니다. 특히 oplog에 존재하는 시간입니다.
샤드 1이 백만 개의 레코드를 생성했고, 샤드 2는 아무 작업도 수행하지 않았으며, 요청이 샤드 2개에 왔다고 가정해 보겠습니다. 첫 번째는 afterClusterTime이 백만이 넘습니다. 이러한 상황에서는 앞서 설명했듯이 샤드 XNUMX는 전혀 응답하지 않습니다.

에서 : – 하나의 논리적 시간을 동기화하고 선택하는 방법을 알고 싶었습니다.

산: - 동기화가 매우 쉽습니다. Shard는 afterClusterTime이 그에게 오고 "Oplog"에서 시간을 찾지 못하면 승인을 시작하지 않습니다. 즉, 그는 자신의 시간을 이 값으로 높인다. 이는 이 요청과 일치하는 이벤트가 없음을 의미합니다. 그는 이 사건을 인위적으로 만들어 인과관계에 일치하게 됩니다.

에서 : – 이후에 네트워크 어딘가에서 손실된 다른 이벤트가 그에게 온다면 어떻게 될까요?

산: – Shard는 단일 마스터이기 때문에 다시는 오지 않도록 설계되었습니다. 그가 이미 등록했다면 그들은 오지 않을 것이지만 나중에 올 것입니다. 어딘가에 뭔가가 걸려서 글을 쓰지 않고 이러한 이벤트가 발생하여 인과적 일관성이 깨지는 일은 일어날 수 없습니다. 그가 글을 쓰지 않으면 모두 다음에 와야 합니다(그는 그들을 기다릴 것입니다).

에서 : – 대기열에 관해 몇 가지 질문이 있습니다. 인과적 일관성은 수행해야 할 특정 작업 대기열이 있다고 가정합니다. 패키지 중 하나가 사라지면 어떻게 되나요? 여기에 10일, 11일이 옵니다... 12일은 사라졌고, 다른 사람들은 그것이 실현되기를 기다리고 있습니다. 갑자기 차가 고장 나서 아무것도 할 수 없습니다. 실행되기 전에 누적되는 대기열의 최대 길이가 있습니까? 하나의 상태가 손실되면 어떤 치명적인 오류가 발생합니까? 게다가 이전 상태가 있다고 적는다면 어떻게든 그것부터 시작해야 할까요? 하지만 그들은 그를 밀어내지 않았습니다!

산: – 또한 좋은 질문입니다! 우리는 무엇을하고 있습니까? MongoDB에는 쿼럼 쓰기, 쿼럼 읽기 개념이 있습니다. 어떤 경우에 메시지가 손실될 수 있나요? 쓰기가 쿼럼이 아니거나 읽기가 쿼럼이 아닌 경우(어떤 종류의 쓰레기도 남을 수 있음)
인과적 일관성과 관련하여 대규모 실험 테스트를 수행한 결과 쓰기 및 읽기가 쿼럼이 아닌 경우 인과적 일관성 위반이 발생하는 것으로 나타났습니다. 당신이 말하는 것과 똑같습니다!

우리의 조언: 인과적 일관성을 사용할 때 최소한 쿼럼 읽기를 사용하십시오. 이 경우 쿼럼 레코드가 손실되더라도 아무것도 손실되지 않습니다. 이는 직교 상황입니다. 사용자가 데이터 손실을 원하지 않으면 쿼럼 레코드를 사용해야 합니다. 인과적 일관성은 지속성을 보장하지 않습니다. 복제 및 복제와 관련된 기계를 통해 내구성이 보장됩니다.

에서 : – 우리를 위해 샤딩을 수행하는 인스턴스(각각 마스터가 아니라 슬레이브)를 생성할 때 자체 머신의 Unix 시간이나 "마스터"의 시간에 의존합니다. 처음으로 동기화합니까, 아니면 주기적으로 동기화합니까?

산: – 이제 명확히하겠습니다. 샤드(즉, 수평 파티션) – 거기에는 항상 기본이 있습니다. 그리고 샤드에는 "마스터"가 있을 수 있고 복제본이 있을 수 있습니다. 그러나 샤드는 일부 도메인(샤드에 기본 도메인이 있음)을 지원해야 하므로 항상 녹음을 지원합니다.

에서 : – 그럼 모든 것이 순전히 “마스터”에게 달려 있다는 겁니까? 마스터 시간은 항상 사용됩니까?

산: - 예. 비유적으로 말할 수 있습니다. "마스터", "Oplog"에 대한 항목이 발생할 때 시계가 똑딱거리고 있습니다.

에서 : – 연결되어 있고 시간에 대해 아무것도 알 필요가 없는 클라이언트가 있습니까?

산: – 전혀 알 필요가 없습니다! 클라이언트에서 작동하는 방식에 대해 이야기하면 클라이언트가 인과 일관성을 사용하려면 세션을 열어야 합니다. 이제 모든 것이 있습니다. 세션의 트랜잭션과 권한 검색... 세션은 클라이언트에서 발생하는 논리적 이벤트의 순서입니다.

이 세션을 열고 인과적 일관성을 원한다고 말하면(세션이 기본적으로 인과적 일관성을 지원하는 경우) 모든 것이 자동으로 작동합니다. 운전자는 이 시간을 기억하고 새 메시지를 받으면 이 시간을 늘립니다. 데이터를 반환한 서버에서 이전 응답이 반환된 응답을 기억합니다. 다음 요청에는 afterCluster("이 값보다 큰 시간")이 포함됩니다.

클라이언트는 아무것도 알 필요가 없습니다! 그에게는 이것이 완전히 불투명합니다. 사람들이 이러한 기능을 사용한다면 무엇을 할 수 있습니까? 첫째, 보조를 안전하게 읽을 수 있습니다. 기본에 쓰고 지리적으로 복제된 보조에서 읽을 수 있으며 작동하는지 확인할 수 있습니다. 동시에 기본에서 녹화된 세션을 보조로 전송할 수도 있습니다. 즉, 하나의 세션이 아닌 여러 세션을 사용할 수 있습니다.

에서 : – 컴퓨팅 과학의 새로운 계층인 CRDT(충돌 없는 복제 데이터 유형) 데이터 유형은 최종 일관성 주제와 밀접한 관련이 있습니다. 이러한 유형의 데이터를 데이터베이스에 통합하는 것을 고려해 보셨나요? 이에 대해 어떻게 말씀하시겠습니까?

산: - 좋은 질문! CRDT는 쓰기 충돌에 적합합니다. MongoDB에서는 단일 마스터입니다.

에서 : - 데브옵스에서 질문이 있습니다. 현실 세계에서는 비잔틴 실패가 발생하고 보호 경계 내부의 사악한 사람들이 프로토콜을 찌르기 시작하고 특별한 방법으로 공예품 패키지를 보내는 예수회 상황이 있습니까?

산: – 경계 내부의 악한 사람들은 트로이 목마와 같습니다! 경계 내부의 사악한 사람들은 많은 나쁜 일을 할 수 있습니다.

에서 : – 대략적으로 말하면 서버에 구멍을 뚫어 코끼리 동물원을 만들어 클러스터 전체를 영원히 붕괴시킬 수 있다는 것이 분명합니다. 수동 복구에는 시간이 걸릴 것입니다… 이것은 간단히 말해서입니다. 잘못된. 반면에 이것은 흥미 롭습니다. 실제 생활에서 실제로 유사한 내부 공격이 발생하는 상황이 있습니까?

산: – 실생활에서 보안 침해가 발생하는 경우는 거의 없기 때문에 발생 여부를 말할 수 없습니다. 그러나 개발 철학에 대해 이야기하면 다음과 같이 생각합니다. 보안을 수행하는 사람들에게 경계선이 있습니다. 이것은 성이자 벽입니다. 경계선 안에서는 원하는 대로 무엇이든 할 수 있습니다. 보기만 가능한 사용자도 있고, 디렉토리를 지울 수 있는 권한을 가진 사용자도 있는 것은 분명합니다.

권리에 따라 이용자가 입힐 수 있는 피해는 쥐가 될 수도 있고, 코끼리가 될 수도 있습니다. 모든 권한을 가진 사용자는 무엇이든 할 수 있다는 것이 분명합니다. 제한된 권리를 가진 사용자는 피해를 훨씬 줄일 수 있습니다. 특히 시스템을 깨뜨릴 수는 없습니다.

에서 : – 보호된 경계에서 누군가 서버를 완전히 파괴하기 위해 서버에 대한 예상치 못한 프로토콜을 생성하려고 시도했으며 운이 좋으면 전체 클러스터가... 그렇게 "좋은" 것을 얻을 수 있습니까?

산: “그런 얘기는 들어본 적이 없어요.” 이런 방식으로 서버가 충돌할 수 있다는 사실은 비밀이 아닙니다. 내부에서 실패하고, 프로토콜에서 인증된 사용자가 되어 메시지에 이와 같은 내용을 쓸 수 있는 경우... 실제로는 계속 확인되므로 불가능합니다. 이를 원하지 않는 사용자에 대해서는 이 인증을 비활성화하는 것이 가능합니다. 그러면 이것이 문제가 됩니다. 대략적으로 말하면 그들은 벽 자체를 파괴했고 거기에 코끼리를 밀어 넣을 수 있습니다. 그러면 짓밟힐 것입니다... 그러나 일반적으로 수리공으로 옷을 입고 와서 끌어낼 수 있습니다!

에서 : – 신고해 주셔서 감사합니다. 세르게이 (Yandex). 몽에는 Replica Set의 투표 멤버 수를 제한하는 상수가 있는데, 이 상수는 7(XNUMX)이다. 이것이 왜 상수입니까? 이것이 일종의 매개변수가 아닌 이유는 무엇입니까?

산: – 40개의 노드가 있는 복제 세트가 있습니다. 항상 다수가 있습니다. 어떤 버전인지는 모르겠지만...

에서 : – Replica Set에서는 투표권이 없는 회원을 운영할 수 있지만 투표 회원은 최대 7명입니다. Replica Set이 3개의 데이터 센터에 분산되어 있는 경우 이 경우 종료 시 어떻게 살아남을 수 있습니까? 하나의 데이터 센터는 쉽게 꺼질 수 있고 다른 시스템은 떨어질 수 있습니다.

산: – 이는 이미 보고서의 범위를 조금 벗어난 내용입니다. 이것은 일반적인 질문입니다. 나중에 그것에 대해 말씀드릴 수도 있겠네요.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com