Skip to content

[Cassandra] Client Request에 대한 동작

2012/02/16

[Cassandra] Client Request에 대한 동작

클라이언트는 클러스터(cluster)의 어떤 노드에 접속하더라도 읽기/쓰기에 대해 요청할 수 있습니다.(MySql의 Master/Slave 구조와는 틀립니다.)

그리고 클라이언트가 접속한 그 노드는 코디네이터(coordinator) 노드라고 하여 다음과 같은 일을 하게 됩니다.

1. 코디네이터는 링(ring 또는 클러스터)에서 클라이언트가 읽기/쓰기를 요청한 로우에 대해 처리할 노드(or replica)를 선별합니다. 이때 선별은 클러스터의 파티셔너(partitioner)와 복제 배치 정책(replica placement strategy) 설정을 바탕으로 하게 됩니다.

2. 코디네이터는 선택한 노드와 클라이언트 간에 프록시(proxy)로 동작하게 됩니다.

쓰기 요청에 대해….

쓰기요청에 대해 코디네이터는 해당 로우가 써져야하는 모든 노드에 쓰기 요청을 전달합니다.

즉, 복제 노드들이 살아 있고 사용 가능하다면 클라이언트가 정한 일관성 레벨(consistency level)에는 상관 없이 모두 요청을 받게 됩니다. 하지만 코디네이터가 클라이언트에게 성공이라는 응답을 리턴하는 기준은 일관성 레벨에 따라 얼마나 많은 복제 노드가 성공응답을 주었는지에 따라 달라지게 됩니다.

예를 들어 아래 그림과 같이 싱글 데이터 센터로 구성된 클러스터에 복제 계수(replication factor)가 3이라고 한다면,

1단계 : 클라이언트의 코디네이터 노드 접속 및 요청

클라이언트가 클러스터의 특정 한 노드에 접속해서 로우(저장할 데이터)에 대한 쓰기 요청을 보내고 해당 노드로 부터 성공여부에 대한 응답을 기달리게 됩니다. 이때 클라이언트는 어떤 노드가 실제 로우를 저장할지 알 필요가 없습니다.

2 단계 : 코디네이터 노드의 복제 노드 선별 및 요청 전달

클라이언트가 접속한 노드가 코디네이터가 되고 코디네이터는 복제 계수에 따라 복제 노드를 판별하여 모든 복제 노드에 쓰기 요청을 전달합니다. 여기선 클라이언트가 노드 10에 접속하였다고 가정하고 노드 10이 코디네이터가 되며, 노드 10은 해당 로우에 대한 복제 노드로 노드 1, 2, 7을 선택하여 3 노드에게 쓰기 요청을 보내게 됩니다.

3 단계 : 복제 노드의 로우 저장 후 코디네이터에 결과 전송 및 코디네이터에서 일관성 레벨에 따라 클라이언트에 응답 전달

복제 노드들은 각각 쓰기 요청을 받았을때 로우에 대해 쓰기를 실행하여 성공 여부를 코디네이터에게 리턴하며, 코디네이터는 일관성 레벨에 따라 클라이언트에게 쓰기 요청에대한 결과를 언제 보낼지 결정하고 전달하게 됩니다.  여기서는 일관성 레벨이 ONE이라고 했을때 노드 7이 가장 먼저 성공이라는 응답을 보냈다면 노드 1,2의 결과는 기달리지  않고 바로 클라이언트에게 성공 응답을 보냅니다.

4 단계 : 예외 상황에서의 복구

일관성 레벨 ONE은 클라이언트는 성공이라는 결과를 받았더라도 세개 복제 노드중 두개의 노드까지는 저장에 성공하지 못할 가능성이 있습니다. 하지만, 해당 로우는 카산드라의 내장 복구 방법( built-in repair mechanisms) : 힌트 핸드오프(hinted handoff), 읽기 복구(read repair), 안티 엔트로피 노드 복구(anti-entropy node repair)에 의해 언젠가 일관성이 맞게 됩니다.

 

읽기 요청에 대해..

읽기 요청이 왔을때 코디네이터 노드는 두가지 타입(direct read request, background read repair request)의 요청을 복제 노드에게 전달합니다.

1 단계 : 코디네이터 노드는 우선 클라이언트에서 정의한 일관성 레벨에 따라 몇개의 복제 노드가 direct read request를 받을지 결정하고 복제 노드중 현재 가장 바로 응답이 가능한 노드를 골라  로우에 대한 읽기 요청을 보내게 됩니다.

2 단계 : 연결된 복제 노드들은 요청에 대해 결과를 리턴하게 됩니다. 만약 여러개의 노드가 연결되었었다면, 각 노드의 결과를 메모리에서 일관성이 맞는지 비교하게 됩니다. 만약 일관성이 맞지 않다면, 코디네이터는 timestamp 를 기준으로 가장 최신의 데이터를 판단하여 해당 데이터를 클라이언트에게 결과로 전달해 줍니다.

3 단계 : 코디네이터 노드는 백그라운드로 모든 복제 노드가 자주 읽는 데이터에 대해 가장 최신 버전을 가지고 있을 수 있도록 하기위해 해당 로우를 가지고 있는 나머지 복제 노드에도 접속해서 해당 로우를 비교합니다. 이때 만약 일관성이 맞지 않다면, 예전 버전의 복제 노드에게 최신의 데이터로 업데이트 하도록 만듭니다. 이러한 프로세스를 읽기 복구(read repair)라고 하며, 읽기 복구는 컬럼 패밀리(column family) 단위로 “read_repair_chance” 를 통해 설정 할수 있으며 기본으로 사용하도록 되어 있습니다.

 

예로, 복제 계수가 3인 클러스터에서 읽기 일관성 레벨이 QUORUM 이라면 3개의 복제 노드중 2개의 노드에 요청을 전달해 결과를 받습니다.

만약 두개의 결과가 다르다고 하면 가장 최신의 로우를 결과로 클라이언트에게 리턴해 줍니다. 그리고 백그라운드로 나머지 세번째 노드에 데이터를 조회하여 앞서 두개의 데이터와 일관성을 비교하여 필요하다면 예전 버전의 노드가 업데이트되도록 만듭니다.

No comments yet

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: