CAP 정리

IBM® Cloudant® for IBM Cloud® 는 "궁극적으로" 모델을 사용합니다. IBM Cloudant의 한 파트를 갱신하는 경우, 갱신은 결국 시스템의 다른 파트에 의해 표시됩니다.

이 모델이 작동하는 방식 및 이 모델이 IBM Cloudant 사용에서 필수인 이유를 이해하려면 일관성의 의미를 이해해야 합니다.

일관성은 데이터베이스 내에서 트랜잭션을 처리하고 신뢰성 있게 보고하는 데 필요한 네 가지 "ACID" 특성 중 하나입니다.

또한 일관성은 "CAP" 정리에서 세 가지 속성 중 하나입니다. 이들 속성은 일관성(Consistency), 가용성(Availability) 및 파티션 장애 내성(Partition tolerance)입니다. 정리에서는 IBM Cloudant 등의 분산 컴퓨터 시스템에서는 세 개의 속성을 동시에보증합니다.

모든 노드가 동일한 시간에 동일한 데이터를 보는 일관성
모든 요청이 성공 여부에 대한 응답을 수신하는 가용성
시스템의 일부가 손실되거나 고장나도 시스템이 계속해서 작동하는 파티션 장애 내성

세 가지 속성을 모두 동시에 제공하는 것이 불가능하다는 것은 IBM Cloudant가 일관성 속성을 보장하지 않음을 의미합니다. 업데이트가 전파되면 시스템은 완전한 일관성에 "집중"합니다.

결과적 일관성은 성능 면에서 좋습니다. 강한 일관성 모델에서는 쓰기 또는 업데이트 요청이 완료되려면 시스템이 업데이트가 오류 없이 완료되기를 기다려야 합니다. 결과적으로 일관된 모델을 사용하면 쓰기 또는 업데이트 요청은 거의 즉시 리턴될 수 있지만, 시스템에서의 전파는 뒤에서 계속됩니다.

데이터베이스는 이론적 및 실질적인 이유로 이들 세 속성 중 두 가지만을 나타낼 수 있습니다. 데이터베이스의 일관성과 가용성의 우선순위를 정하는 것은 간단합니다. 단일 노드가 데이터의 단일 사본을 저장합니다. 그러나 이 모델은 성능을 향상시키려면 추가 노드를 사용하는 것이 아니라 해당 노드를 업그레이드해야 하므로 스케일링하기 어렵습니다. 그리고 사소한 시스템 장애라도 단일 노드 시스템을 시스템 종료시킬 수 있으며, 모든 메시지 손실은 곧 막대한 데이터 손실을 의미합니다. 고장에 대처하려면 시스템이 더 정교해져야 합니다.

파티션 장애 내성을 우선하여 발생하는 단점

일관성 및 파티션 용인을 우선하는 데이터베이스는 일반적으로 1차-2차 설정을 사용하며, 이 설정에서는 시스템에 있는 많은 노드 중 하나가 리더로 선출됩니다. 오직 리더만 데이터 쓰기를 승인하며, 모든 보조 노드는 리더로부터 데이터를 복제하여 읽기를 처리합니다. 해당 리더의 네트워크 연결이 끊어지거나 시스템의 다른 노드와 통신할 수 없게 되는 경우에는 나머지 노드가 새 리더를 선출합니다. 이 선거 프로세스는 시스템마다 다르며 중요한 문제점의 원인이 될 수 있습니다.

IBM Cloudant에서는 1차-1차 설정을 사용하여 가용성 및 파티션 장애 내성을 우선하며, 이 설정에서는 모든 노드가 데이터 일부에 대한 쓰기 및 읽기를 허용할 수 있습니다. 여러 노드가 각 데이터 부분의 사본을 포함합니다. 각 노드는 다른 노드의 데이터를 복사합니다. 하나의 노드가 액세스 불가능해지면 네트워크가 복구되는 동안 다른 노드가 그 역할을 대신할 수 있습니다. 이러한 방식으로 시스템은 임의의 노드 장애에도 불구하고 데이터를 시기적절한 방식으로 리턴하고 종국적 일관성을 유지합니다. 절대 일관성을 포기함으로써 발생하는 단점은 모든 노드가 동일한 데이터를 보게 되기까지 시간이 소요된다는 점입니다. 따라서, 새 데이터가 시스템 전체로 전파되는 동안 일부 응답은 이전 데이터를 포함할 수 있습니다.

접근법 변경

하나의 일관된 데이터 보기를 유지하는 것은 관계형 데이터베이스가 이 작업을 대신 수행해 주므로 논리적이며 이해하기 쉽습니다. 보통은 데이터베이스 시스템과 상호작용하는 웹 기반 서비스가 이러한 방식으로 동작할 것으로 예상됩니다. 그러니 이러한 예상이 실제로 적용되지 않는 경우도 있습니다. 일관성은 처음부터 주어지는 속성이 아니며, 접근법을 변경하려면 약간의 노력이 필요합니다.

사실 일관성은 많은 엔터프라이즈 클라우드 서비스에서 반드시 필수적인 속성은 아닙니다. 사용량이 많은 대규모 시스템에서는 시스템 일부가 고장날 확률이 더 높습니다. 가용성과 결과적 일관성을 우선하는 필요성을 중심으로 설계된 데이터베이스가 애플리케이션을 온라인 상태로 유지하는 데 더 적합합니다. 애플리케이션 데이터의 일관성 문제는 사후에 처리할 수 있습니다.

엔터프라이즈 입장에서의 애플리케이션 가용성 대 일관성

인기 웹 기반 서비스에 대한 연구는 사람들은 이미 고가용성을 기대하고 있으며, 보통 자신이 그렇게 행동하고 있음을 깨닫지 못한 상태에서 결과적으로 일관된 데이터를 위해 이 가용성을 기꺼이 포기할 것임을 보여줍니다.

많은 애플리케이션은 가용성 때문에 사용자를 혼동시키는 경우가 많습니다. ATM을 고려합니다. 일관성 없는 은행데이터는 왜 여전히 이의 실현 없이 돈을 당좌 대월하는 것이 가능한 이유입니다. 전체 금융 시스템에서 사용자의 계정 잔고에 대한 일관된 보기를 표시하기 위해 네트워크의 모든 노드가 정지한 후 이 숫자를 기록해야 한다면 이는 비현실적입니다. 시스템을 고가용성 시스템으로 만드는 것이 더 바람직합니다.

금융 업계에서는 이를 1980년대에 깨달았지만 많은 IT 조직에서는 여전히 가용성을 위해 일관성을 희생시키는 것에 우려를 표했습니다. 판매 팀에서 CRM 앱에 액세스할 수 없을 때 걸려오는 지원 통화의 수를 생각해 보십시오. 이제 판매 팀에서 데이터베이스 업데이트가 애플리케이션 전체로 전파될 때까지 소요되는 몇 초를 인식이라도 할 지 생각해 보십시오.

가용성은 많은 면에서 일관성보다 중요합니다. 온라인 쇼핑 장바구니 시스템, HTTP 캐시 및 DNS는 이 중 몇 가지 예에 불과합니다. 조직에서는 사용자의 실망, 생산성 손실 및 놓친 기회와 같이 가동 중단 시간으로 인해 발생하는 비용을 고려해야 합니다.

이론에서 구현으로

클라우드 애플리케이션에서는 고가용성을 구현하는 것이 매우 중요합니다. 그렇지 않은 경우에는 글로벌 데이터베이스 일관성이 스케일링에서 주요 장애물로 남게 됩니다. 고가용성 애플리케이션은 데이터가 최신 상태가 아닌 경우에도 해당 데이터와의 상시 연결을 유지해야 합니다. 그것이 결과적 일관성의 개념이며, 우려할 필요는 전혀 없습니다. 대규모에서는 완벽히 올바르지는 않은 응답을 제공하는 것이 응답을 전혀 제공하지 않는 것보다 나은 경우도 있습니다.

데이터베이스 시스템은 다양한 방법으로 가용성 대 일관성으로 인해 발생하는 복잡성을 숨기지만 이러한 복잡성은 항상 존재합니다. IBM Cloudant, CouchDB 및 기타 NoSQL 데이터베이스 팀에서는 개발자가 디자인 프로세스의 초기 단계에 이러한 복잡성을 해결하도록 요구하는 것이 최선의 정책이라고 믿습니다. 어려운 작업을 먼저 수행하여 애플리케이션을 스케일링할 준비를 갖춤으로써, 예상치 못한 상황이 발생하는 경우를 줄일 수 있습니다.