이 글은 2부로 구성된 글의 두 번째 부분으로, Couchbase의 리밸런싱 기술에 대한 자세한 내용을 다룹니다. The 첫 번째 부분 에서는 리밸런싱 프로세스의 기본 메커니즘과 배경을 다루었습니다. 두 번째 파트에서는 재조정 프로세스를 모니터링하는 방법과 재조정 문제를 중지하고 처리하는 방법에 대해 자세히 살펴봅니다.
리밸런싱 모니터링
일반적인 모니터링 외에도 Membase/Couchbase 클러스터의 경우, 리밸런싱 중에 집중해야 할 몇 가지 특정 영역이 있습니다. 이 중 대부분은 웹 UI를 통해 모니터링할 수 있으며, 각 노드에서 사용 가능한 기본 통계를 보면 더 구체적으로 파악할 수 있습니다.
- 특정 노드가 얼마나 많은(그리고 어떤) 브이버킷을 담당하고 있는지 모니터링하고 이를 사용하여 리밸런싱 진행 상황을 파악할 수 있습니다.
- 대량 '백필' 또는 대상 노드로 전송하기 전에 데이터를 RAM에 구체화하기 위한 일회성 읽기로 인한 것일 수 있습니다.
- 정상적인 트래픽 부하와 함께 리밸런싱을 하면 데이터가 디스크로 빠져나가는 속도보다 더 빨리 RAM으로 전송되므로 디스크 쓰기 대기열이 크게 늘어날 수 있습니다. (*현재 해결 중인 버그/설계 결함은 아래 참조).
- 여기에서 꽤 많은 활동을 볼 수 있으며, v버킷이 한 곳에서 다른 곳으로 이동함에 따라 '버스트'가 발생할 수 있습니다.
- 리밸런싱이 예상보다 오래 걸리는 이유를 직접 이해하는 것이 중요합니다. 대상 노드와 관련된 이러한 백오프를 볼 수 있습니다(백오프하라는 지시를 받는 소스 노드와 달리 대상 노드는 전송한 횟수를 기록하기 때문입니다).
리밸런싱이 왜 이렇게 오래 걸리나요?
고객들은 리밸런싱에 얼마나 걸리는지 자주 물어보지만, 저는 정말 모른다고 대답할 수밖에 없습니다. 데이터의 양(개별 개체의 수와 크기), 디스크의 속도(읽기 및 쓰기 모두), 네트워크 부하에 따라 크게 달라질 뿐만 아니라 프로세스 중에 노드 장애 및 기타 예기치 않은 속도 저하가 발생할 가능성도 있기 때문입니다.
점점 더 가변적인 조건에서 리밸런싱에 걸리는 시간을 안정적으로 정량화하기보다는 그 상태를 특성화하고 모니터링하는 것이 훨씬 더 중요하다고 생각합니다. 위에서 언급했듯이 리밸런싱이 애플리케이션에 중대한 영향을 미치지 않는 것이 이상적이기 때문에 시간이 얼마나 걸리든 크게 중요하지 않습니다. 영향이 감지되는 경우에는 재조정 프로세스 자체의 속도를 높이려고 하기보다는 그 이유를 이해하고 해결하는 것이 더 중요할 것입니다.
일반적인 속도 저하의 가장 일반적인 원인은 대상 노드의 디스크가 느려서 TAP 백오프로 이어지는 것입니다.
*현재 버그/설계 결함: 1.7.1.1 이하 릴리스에서는 노드가 새 데이터를 수신하는 중에도 디스크에서 이전 데이터를 삭제하기 시작할 수 있습니다. 초기 테스트에서는 이러한 삭제가 그리 오래 걸리지 않는 것으로 나타났습니다. 실제로 특정 조건(특히 Amazon의 EC2)에서는 예상보다 훨씬 오래 걸릴 수 있다는 사실을 발견했습니다. 안타깝게도 노드는 이러한 삭제와 쓰기를 동시에 수행할 수 없기 때문에 결국 쓰기 프로세스가 '고갈'될 수 있습니다. 이로 인해 매우 큰 디스크 쓰기 대기열이 발생하고 결국 TAP 백오프 기간이 길어집니다. 치명적이지는 않지만 재밸런싱 시간이 크게 길어지고 데이터 안전에 대한 우려가 생길 수 있다는 점에서 사용자에게 당황스러울 수 있습니다. 이러한 상황이 발생하지 않도록 1.7.2에서 이 동작이 수정 중이거나 이미 수정되었습니다.
리밸런싱 중 성능
설계상 리밸런싱은 애플리케이션의 성능에 중대한 영향을 미치지 않아야 합니다. 그러나 실제로는 리밸런싱 작업으로 인해 시스템의 전반적인 부하와 리소스 사용률이 증가하므로 특정 환경에서는 성능이 저하될 수 있습니다. 가급적 애플리케이션의 트래픽 수준이 가장 낮을 때 리밸런싱을 수행하는 것이 가장 좋습니다.
리밸런싱 중 성능 저하의 두 가지 주요 원인은 네트워크 포화 상태와 디스크 경합입니다. CPU 사용률이 또 다른 원인이 될 수 있지만, 트래픽 속도가 가장 높은 경우(초당 수십만 건의 작업이 여러 번 발생하는 경우)를 제외하고는 유일한 원인으로 작용하는 경우는 매우 드물며 일반적으로 디스크 IO 대기 등 일부 근본적인 원인과 관련이 있습니다.
네트워크 포화 상태는 상당히 분명해야 합니다. 애플리케이션이 이미 클러스터를 네트워크 대역폭에 가깝게 밀어붙이고 있는 경우 리밸런싱으로 인해 포화 상태가 더 심해져 시간 초과 및 오류가 발생할 수 있습니다. 현재(향후에는 허용될 수 있지만) 리밸런싱의 네트워크 활동을 스로틀링하는 것은 허용되지 않습니다.
디스크 경합은 보고 특성화하기가 조금 더 어렵습니다. 이는 멤베이스/카우치베이스 서버의 주요 이점 중 하나인 RAM과 디스크 IO의 분리로 거슬러 올라갑니다. 소프트웨어는 RAM에서 가능한 한 많은 작업을 수행함으로써 디스크 IO 수준에서 발생하는 모든 속도 저하를 감춥니다. 디스크는 일반적으로 RAM보다 훨씬 느리지만 디스크에 부하가 증가하면 속도가 더욱 느려집니다. 리밸런싱은 이러한 증가된 부하 중 하나입니다. 애플리케이션이 RAM에서 모든 데이터를 읽고 있는 경우에는 여기에 영향을 미치지 않습니다. 그러나 많은 요청('많은'이란 주관적인 의미)이 RAM에 캐시되지 않아 디스크에서 서비스되는 경우 성능이 저하될 수 있으며 실제로 저하될 수 있습니다. RAM을 더 많이 확보하여 이 문제를 완화할 수 있지만 항상 실용적인 것은 아니므로 때로는 무슨 일이 일어나고 있는지 파악하는 것이 중요합니다.
리밸런싱 중지하기
각 v버킷이 개별적으로 이동되기 때문에 전체 프로세스를 다시 수행할 필요 없이 수동으로 또는 일부 실패로 인해 리밸런스를 중지할 수 있습니다. 리밸런스를 다시 시작하기만 하면 중단된 지점부터 다시 시작됩니다.
소프트웨어의 현재 상태를 고려할 때 여기에는 두 가지 주의 사항이 있습니다:
- 리밸런싱을 통해 노드를 제거하다가 리밸런싱이 중지된 경우, 리밸런싱을 다시 시작하기 전에 노드를 다시 제거해야 합니다. 클러스터는 지난번에 수행한 작업을 "기억"하지 못하므로 이를 상기시키는 것이 중요합니다.
- 리밸런싱을 다시 시작하기 전에 (중단된 이유와 관계없이) 최소 5분 정도 기다리는 것이 좋습니다. 이는 노드 간의 다양한 연결이 제대로 정리될 수 있도록 하기 위한 것입니다. 이후 버전의 소프트웨어에서는 실제로 이 제한이 적용될 것입니다(웹 UI를 통해 원하는 경우 CLI/REST API를 사용하여 재정의할 수 있지만, 저희가 지시하지 않는 한 그렇게 하지는 마세요 ;-).
리밸런싱이 특정 vbucket을 이동하는 도중에 중단되더라도(보통 그렇듯이) 걱정할 필요가 없습니다. 해당 특정 이동은 원래 vbucket을 활성 상태로 두면 "백아웃"됩니다. 그 이상은 필요하지 않습니다.
리밸런싱 실패
리밸런싱이 실패하면 어떻게 해야 하나요? 이상적으로는 리밸런싱이 정상적으로 작동하는 경우 빠른 시일 내에 재시작하는 것이 좋습니다(다시 말하지만 최소 5분 이상 기다리세요). 이는 실패의 성격에 따라 크게 달라집니다. 리밸런싱 실패가 발생하면 원인과 클러스터의 현재 상태를 파악하기 위해 노력해야 합니다.
물론 소프트웨어 내의 모든 버그를 수정하기 위해 노력하고 있지만, 불가피하게 리밸런싱에 실패하는 상황이 발생할 수 있습니다. 가장 일반적인 두 가지 이유는 시간 초과 또는 크래시입니다.
특정 노드의 응답 속도가 느리거나 일정 시간이 지나도 전혀 응답하지 않을 때 타임아웃이 발생하며, 일반적으로 네트워크 또는 디스크 속도 저하로 인해 발생합니다. 노드가 실패하는 경우에도 타임아웃이 표시되지만 상대방이 무슨 일이 일어났는지 알 수 없는 방식으로 실패하는 경우에만 타임아웃이 표시됩니다. 후자의 경우 시간 초과가 실제로 더 심각한 다른 문제를 가릴 수 있습니다.
멤캐시와 같은 내부 프로세스 또는 커널과 같은 외부 시스템 구성 요소의 충돌도 리밸런싱 실패를 초래합니다.
로그에는 실패 자체에 관한 정보가 어느 정도(상당량) 기록될 것입니다. "시간 초과"("멤캐시드 대기 실패"와 동일) 또는 "일부 프로세스가 예기치 않게 종료됨"과 같은 내용이 표시됩니다. 이는 특히 지원팀이 조사하는 데 유용한 정보이지만, 원인은 클러스터의 현재 상태보다 훨씬 덜 중요합니다.
리밸런싱을 재개하기 전에 추가 조치가 필요한지 여부를 즉시 평가하고 싶을 것입니다. 기본 진단은 클러스터의 모든 노드가 여전히 정상이고 데이터를 제공할 수 있는지 여부를 확인하는 것입니다. 정상이라면 다행입니다. 그렇지 않다면 먼저 해당 상황을 해결해야 합니다. 여기서는 이 일반적인 문제 해결 활동에 대해서는 다루지 않겠지만, 대략적인 내용은 이해하실 수 있습니다. 데이터는 안전하므로 안심할 수 있으며 필요한 경우 장애 조치도 가능합니다.
요약
이 글을 읽으셨다면, 그리고 리밸런싱에 대한 첫 번째 게시물 리밸런싱 프로세스에 대해 알아야 할 거의 모든 것을 알고 계실 것입니다. 가장 중요한 것은 이제 리밸런싱의 효과와 필요성, 그리고 이것이 Couchbase 및 Membase 클러스터의 배포와 운영에 어떤 영향을 미치는지에 대해 교육적으로 추측할 수 있는 위치에 있어야 한다는 것입니다.
