엔지니어링

리더 팔로우: Elasticsearch에서 클러스터 간 복제 소개

By
Jason Tedor

수많은 사용자의 요청

하나의 Elasticsearch 클러스터에서 또 다른 Elasticsearch 클러스터로 데이터를 기본 복제할 수 있는 기능은 가장 많이 요청을 받은 기능이며, 사용자가 오랫동안 원해온 기능이기도 합니다. 필요한 토대를 마련하고, 새로운 기본 기술을 Lucene으로 빌드하고, 초기 디자인을 반복하고 개선하는 등 다년 간의 엔지니어링 노력 끝에, 클러스터 간 복제(CCR)가 이제 Elasticsearch 6.7.0에서 프로덕션 준비 완료 상태로 제공된다는 기쁜 소식을 전해드립니다. 앞으로 연재할 시리즈 중 첫 번째인 이 포스팅에서는 그동안 구현해 왔던 작업과 CCR의 기술적 배경 일부에 대해 간단히 소개해 드리겠습니다. 향후 포스팅에서는 구체적인 CCR 사용 사례를 심층적으로 다룰 예정입니다.

Elasticsearch의 클러스터 간 복제를 이용하면 Elasticsearch와 Elastic Stack 내에서 다음과 같이 다양한 중요 업무용 사용 사례 작업이 가능합니다.

  • 재해 복구(DR)/고가용성(HA): 데이터 센터나 지역의 가동 중지를 버텨내는 허용 한도는 수많은 중요 업무용 애플리케이션의 필수 요건입니다. 이 요건은 전에는 Elasticsearch에서 추가적인 기술을 통해 해결되었습니다. 그러나 추가적인 기술을 통한다는 것은 추가적인 복잡성과 관리 오버헤드가 더해진다는 뜻이기도 했습니다. 데이터 센터 간 DR/HA 요건 충족을 이제는 추가적인 기술 없이 CCR을 활용하여 Elasticsearch에서 직접 해결할 수 있습니다.
  • 데이터 지역성: Elasticsearch에서 데이터를 복제하여 사용자나 애플리케이션 서버에 더 가까운 곳으로 옮기면, 비용 부담이 되는 대기 시간을 줄일 수 있습니다. 예를 들어, 제품 카탈로그나 참조 데이터 세트를 전 세계 20개 이상의 데이터 센터로 복제하여 데이터와 애플리케이션 서버 사이의 거리를 최소화할 수 있습니다. 또 다른 사용 사례로는 런던과 뉴욕에 사무소를 두고 있는 증권사를 들 수 있습니다. 런던 사무소의 모든 거래는 현지에서 작성되어 뉴욕으로 복제될 수 있고, 뉴욕 사무소의 모든 거래는 현지에서 작성되어 런던으로 복제될 수 있습니다. 양쪽 사무소에서 모든 거래를 전체적으로 조회할 수 있습니다.
  • 중앙화된 보고: 규모가 작은 다수의 클러스터에서 중앙화된 보고 클러스터로 데이터를 복제합니다. 이것은 대규모 네트워크에서 쿼리가 효율적이지 않을 수 있을 때 유용합니다. 예를 들어, 대규모의 글로벌 은행은 각 은행 지점마다 하나씩 전 세계적으로 100개의 Elasticsearch 클러스터를 갖추고 있을 수 있습니다. 우리는 CCR을 사용해 전 세계 모든 100개 은행의 이벤트를 다시 중앙 클러스터로 복제하여 현지에서 그 중앙 클러스터를 이용해 이벤트를 분석하고 집계할 수 있습니다.

Elasticsearch 6.7.0 전에는, 이러한 사용 사례가 서드 파티 기술을 이용해 부분적으로만 처리될 수 있었습니다. 따라서 번거롭고 복잡하며 관리 상의 오버헤드가 많고 상당한 단점이 있었습니다. Elasticsearch에 기본 통합된 클러스터 간 복제를 이용하면, 사용자가 복잡한 솔루션을 관리해야 하는 부담과 단점을 없애주며, 기존 솔루션이 제공할 수 있는 것 이상의 장점(종합적인 오류 처리 등)을 제공할 수 있고, CCR 관리와 모니터링을 위해 Elasticsearch와 Kibana의 UI 내에서 API를 제공합니다.

향후 포스팅에서 이러한 각각의 사용 사례에 대해 상세하고 심층적으로 다룰 예정이니 눈여겨 봐주시기 바랍니다.

클러스터 간 복제 시작하기

다운로드 페이지에서 Elasticsearch와 Kibana 최신 릴리즈를 다운로드받으시고, 시작 가이드를 참조해 직접 사용을 시작해 보세요.

CCR은 플래티넘 수준 기능이며, 30일 무료 체험판 라이선스를 통해 제공됩니다. 이 라이선스는 체험판 시작 API를 통해 또는 Kibana에서 직접 활성화할 수 있습니다.

클러스터 간 복제 기술 소개

CCR은 액티브-패시브 인덱스 모델을 기반으로 설계되었습니다. 한 Elasticsearch 클러스터의 인덱스는 또 다른 Elasticsearch 클러스터의 인덱스로부터 변경 사항을 복제하도록 구성될 수 있습니다. 변경 사항을 복제하는 인덱스를 ”팔로워 인덱스"라고 하고 변경 사항이 복제되는 인덱스를 “리더 인덱스"라고 합니다. 팔로워 인덱스는 읽기 요청과 검색을 처리할 수 있지만 직접 쓰기를 수락할 수 없다는 면에서 패시브합니다. 리더 인덱스만이 직접 쓰기에 대해 액티브합니다. CCR이 인덱스 수준에서 관리되므로, 클러스터는 리더 인덱스와 팔로워 인덱스를 모두 포함할 수 있습니다. 이런 식으로, 사용자는 어떤 인덱스는 단방향으로(예를 들어, 미국 클러스터에서 유럽 클러스터로) 복제하고, 다른 인덱스는 그 반대 방향으로(유럽 클러스터에서 미국 클러스터로) 복제함으로써 일부 액티브-액티브 사용 사례를 해결할 수 있습니다.

복제는 샤드 수준에서 이루어집니다. 팔로워 인덱스의 각 샤드는 리더 인덱스의 해당 샤드로부터 변경 사항을 가져옵니다. 이것은 팔로워 인덱스가 리더 인덱스와 같은 수의 샤드를 갖는다는 뜻입니다. 팔로워는 모든 작업을 복제하며, 따라서 문서 생성, 업데이트 또는 삭제 작업이 복제됩니다. 복제는 거의 실시간으로 이루어지며, 샤드의 글로벌 체크포인트가 진행되자마자 작업은 팔로워 샤드에 의해 복제되기 위한 적격 상태가 됩니다. 팔로워 샤드는 작업을 대량으로 효율적으로 가져와 색인하며, 변경 사항을 가져오라는 여러 요청을 동시에 실행할 수 있습니다. 이러한 읽기 요청은 원본과 그 복제본을 통해 이루어질 수 있으며, 샤드에서 읽기 이외에는 리더에게 어떤 추가적인 부하도 부과하지 않습니다. 이 디자인은 CCR이 프로덕션 부하를 확장할 수 있게 해주며, 따라서 사용자는 Elasticsearch에서 선호하는 (그리고 기대하는) 높은 처리량의 색인 속도를 계속해서 누릴 수 있습니다.

CCR은 새로 생성된 인덱스와 기존 인덱스를 모두 지원합니다. 팔로워가 초기에 구성될 때, 원본으로부터 복제본이 복구되는 방식과 유사한 절차로 리더 인덱스에서 내부 파일들을 복사함으로써 팔로워는 리더 인덱스로부터 자신을 부트스트랩하게 됩니다. 이 복구 절차가 완료된 후, CCR은 리더로부터 모든 추가 작업을 복제합니다. 매핑과 설정 변경은 필요할 때 리더 인덱스로부터 자동으로 복제됩니다.

때때로, CCR이 오류 시나리오(네트워크 장애 등)에 직면할 수도 있습니다. CCR은 이러한 오류를 복구할 수 있는 오류와 치명적인 오류로 자동으로 분류할 수 있습니다. 복구할 수 있는 오류가 발생하면, CCR은 재시도 루프에 진입하며 따라서 장애를 유발한 상황이 해결되자마자 CCR은 복제를 재개합니다.

복제 상태는 전용 API를 통해 모니터링될 수 있습니다. 이 API를 통해 사용자는 팔로워가 리더를 얼마나 긴밀하게 추적하고 있는지 모니터링하고, CCR의 성능에 대한 세부 통계를 보며, 주의를 요하는 모든 오류를 추적할 수 있습니다.

우리는 Kibana 내에서 CCR과 앱 모니터링과 관리를 통합했습니다. UI 모니터링은 사용자에게 CCR 진행률과 오류 보고에 대한 인사이트를 제공합니다.

Elasticsearch CCR Monitoring UI in Kibana

Kibana의 Elasticsearch CCR 모니터링 UI

관리 UI는 사용자가 원격 클러스터를 구성하고, 팔로워 인덱스를 구성하며, 자동 인덱스 복제를 위한 자동 팔로워 패턴을 관리할 수 있게 해줍니다.

Elasticsearch CCR Management UI in Kibana

Kibana의 Elasticsearch CCR 관리 UI

자동 팔로우 기능

수많은 사용자가 주기적으로 새로운 인덱스를 생성하는 워크로드를 가지고 있습니다. Filebeat가 내보내고 있는 로그 파일로부터의 일일 인덱스나 인덱스 수명 주기 관리에서 자동으로 롤오버되는 인덱스 같은 것을 예로 들 수 있습니다. 소스 클러스터로부터 이러한 인덱스를 복제하기 위해 수동으로 팔로워 인덱스를 생성해야 할 필요 없이, 우리는 직접 CCR에 자동 팔로우 기능을 빌드해 넣었습니다. 이 기능을 통해 사용자는 인덱스 패턴을 구성하여 소스 클러스터로부터 자동으로 복제되도록 할 수 있습니다. CCR은 이 패턴과 일치하는 인덱스에 대해 소스 클러스터를 모니터링하고, 그렇게 일치하는 리더 인덱스를 복제하기 위해 팔로워 인덱스를 구성하게 됩니다.

또한 CCR과 ILM도 통합했습니다. 따라서 CCR은 시간 기반 인덱스를 복제하고, ILM은 소스와 대상 클러스터 양쪽을 모두 관리할 수 있습니다. 예를 들어, ILM은 CCR이 언제 리더 인덱스를 복제하는지를 이해하며 따라서 CCR이 복제를 완료할 때까지 인덱스 축소와 삭제 같은 파괴적인 작업들을 신중하게 관리합니다.

작업 기록 관리

CCR이 변경 사항을 복제할 수 있으려면, 리더 인덱스의 샤드에 있는 작업 기록이 필요합니다. 그리고 어떤 작업이 안전하게 복제될 수 있는지 알려면, 각 샤드의 포인터가 필요합니다. 이 작업 기록은 시퀀스 ID가 관리하며 포인터는 글로벌 체크포인트로 알려져 있습니다. 그러나 컴플리케이션도 있습니다. Lucene에서 문서가 업데이트되거나 삭제되면, Lucene은 문서가 삭제된다는 것을 기록하기 위해 표시를 남깁니다. 향후 병합 작업이 삭제된 문서들을 병합해버릴 때까지 문서는 디스크에 보존됩니다. 삭제된 문서가 병합되기 전에 CCR이 이 작업을 복제하는 경우라면 별 문제가 없습니다. 그러나 병합은 그 수명 주기에서 발생합니다. 이것은 삭제된 문서가 CCR이 작업을 복제할 기회를 갖기도 전에 병합될 수 있다는 뜻입니다. 삭제된 문서가 언제 병합되는지 컨트롤하는 능력이 없다면, CCR은 작업을 놓칠 수 있고, 팔로워 인덱스에 작업 기록을 모두 복제할 수 없을 수도 있습니다. CCR 설계 초기에는 이러한 작업 기록에 대한 소스로 Elasticsearch 트랜스로그를 사용할 계획이었습니다. 이를 통해 문제를 피해갈 수도 있기 때문입니다. 그러나 트랜스로그가 CCR이 효과적으로 수행하는 데 필요한 액세스 패턴을 위해 설계되지 않았다는 것을 곧 깨닫게 되었습니다. 트랜스로그와 함께 트랜스로그에 추가 데이터 구조를 넣어서 우리가 필요한 성능을 얻는 것을 고려해 보았지만 이 접근 방식에는 한계가 있습니다. 한 가지 예를 들자면, 우리 시스템의 가장 중요한 구성 요소 중 하나에 더 많은 복잡성을 더하게 될 것입니다. 이것은 우리 엔지니어링 철학에 부합되지 않습니다. 게다가, 작업 기록에 빌드하려고 하는향후 변경사항에 손이 묶이게 될 것입니다. 작업 기록 상에서 수행될 수 있는 검색 유형을 제한하거나 트랜스로그에 모든 Lucene을 다시 구현해야만 하는 상황이 될 것이기 때문입니다. 이러한 인사이트를 통해, 우리는 작업 기록을 Lucene으로 효과적으로 내보내면서 삭제된 문서가 언제 병합되는지 컨트롤하게 해줄 기능을 Lucene에 네이티브로 빌드할 필요가 있다는 것을 깨달았습니다. 우리는 이 기술을 “소프트 삭제”라고 부릅니다. Lucene에 대한 이 투자는 앞으로 오랫동안 그 결실을 거둘 것입니다. Lucene에 CCR을 빌드해 넣었을 뿐 아니라 소프트 삭제에 우리 복제 모델을 다시 작업하고 있고, 앞으로 나오는 변경 API도 그것을 기반으로 하고 있기 때문입니다. 소프트 삭제는 리더 인덱스에서 활성화되어야 합니다.

그러면 이제 소프트 삭제된 문서가 리더에서 언제 병합되는지에 팔로워가 영향을 미칠 수 있다는 문제가 남았습니다. 이를 위해, 우리는 샤드 기록 유지 리스를 도입했습니다. 샤드 기록 유지 리스를 이용하면, 팔로워는 팔로워가 현재 있는 기록이 속한 리더의 작업 기록에 표시를 할 수 있습니다. 리더 샤드는 해당 표시 아래의 작업은 병합해도 안전하지만 해당 표시 위의 작업은 팔로워가 그것을 복제할 기회를 가질 때까지 보존되어야 한다는 것을 알게 됩니다. 이러한 표시는 팔로워가 일시적으로 오프라인 상태가 되는 경우, 리더가 아직 복제되지 않은 작업을 보존하게 해줍니다. 이런 기록을 보존하는 것이 리더 상의 추가 저장 공간을 필요로 하기 때문에, 이러한 표시는 한정된 기간 동안에만 유효합니다. 그 기간이 지나면 그 표시는 만료되고 리더 샤드는 자유롭게 기록을 병합해 버리게 됩니다. 팔로워가 오프라인 상태가 되는 경우 어느 정도의 추가 저장 공간을 기꺼이 유지할 것인지, 그리고 팔로워가 얼마나 오래 오프라인 상태로 있어야 리더로부터 다시 부트스트랩하도록 할 것인지를 기준으로 이 기간의 길이를 조정할 수 있습니다.

요약

CCR 체험판을 사용해 보고 이 기능에 대한 피드백을 공유할 수 있게 해드려서 기쁩니다. 저희가 즐겁게 만든 것처럼 이 기능을 즐겁게 사용해 주시기 바랍니다. 이 시리즈의 향후 포스팅도 주목해 주세요. CCR의 몇 가지 기능과 CCR이 목표로 하는 사용 사례에 대해 좀 더 상세하게 설명해 드리겠습니다. 그리고 CCR에 대한 질문이 있으시면, 토론 포럼을 이용해 주세요.

이 포스팅과 관련된 미리 보기 이미지의 저작권은 NASA의 소유이며 CC BY-NC 2.0 라이선스에 따라 사용 허가를 받았습니다. 이 포스팅과 관련된 배너 이미지의 저작권은 Rawpixel Ltd의 소유이며, CC BY 2.0 라이선스에 따라 사용 허가를 받았고, 원본을 자른 것입니다.