HAQM OpenSearch Service OR1 인스턴스 내부 구조 알아보기

이 글은 AWS Big Data Blog에 게시된 ‘HAQM OpenSearch Service Under the Hood’를 번역 및 개선했습니다.

HAQM OpenSearch Service는 Optimized Instance(OR1)를 제공하고 있습니다. 이 새로운 제품군은 벤치마크 테스트에서 기존 메모리 최적화 인스턴스보다 가격 대비 성능이 최대 30% 향상되었습니다. 이는, OR1 인스턴스는 내부적으로 HAQM S3를 활용하기 때문이며 이러한 특징으로 OR1 인스턴스는 11 9s의 뛰어난 데이터 내구성을 제공합니다. OpenSearch Service는 이 혁신적인 인스턴스 제품군을 통해 AWS의 첨단 기술을 접목하여 클라우드 환경에서 보다 효율적으로 데이터를 색인하고 저장하도록 새로운 메커니즘을 도입했습니다.

오늘날 여러 상용 워크로드의 분석 영역에서 OpenSearch Service를 널리 사용하고 있습니다. OpenSearch는 대량의 데이터를 수집하는 동시에 풍부하고 상호 작용적인 분석을 제공하기 때문이며, 이러한 이점을 제공하기 위해 OpenSearch는 데이터를 색인하고 요청을 처리하는 여러 개의 독립적인 인스턴스를 갖춘 대규모 분산 시스템으로 설계되었습니다. 물론, 경우에 따라서 운영 분석 데이터의 속도와 데이터 양이 증가하면 병목 현상이 발생할 수 있습니다. 이를 해결하기 위하여 대량의 색인을 처리하도록 볼륨을 지속적으로 지원하고 내구성을 제공하기 위해 OR1 인스턴스 제품군을 구축했습니다.

이 게시글에서는 새롭게 재구성된 데이터 흐름이 OR1 인스턴스에서 어떻게 작동하는지, 그리고 새로운 물리적 복제 프로토콜을 사용하여 높은 색인 처리량과 내구성을 제공할 수 있는지에 대해 설명합니다. 또한, 정확성과 데이터 무결성을 유지하기 위해 해결한 몇 가지 문제도 자세히 살펴봅니다.

OpenSearch 색인 프로세스에 대한 이해

OpenSearch Service는 내부적으로 Lucene Segment를 분리 저장하는 방식으로 운영 됩니다. 각 샤드별로 문서 의 변경이 이루어지는 경우 Translog(트랜스로그) 파일에 먼저 해당 내용을 기록합니다. 이후 Lucene으로 전달되며 이 정보는 주기적으로 새로고침되면서 세그먼트 파일을 생성합니다. 이러한 과정이 반복되면 트랜스로그 파일이 점점 커지게 되고 일정 크기 이상으로 커지면 Flush 작업을 통해 해당 내용이 물리 디스크에 쓰여집니다. Flush 작업이 완료되면 트랜스로그가 삭제되며, 새로운 로그부터 다시 쌓기 시작합니다.

다음 다이어그램은 OpenSearch의 세그먼트와 트랜스로그 저장 흐름을 보여줍니다.

11 9s의 내구성을 가진 높은 처리량을 위한 설계

OpenSearch Service는 수만 개의 OpenSearch 클러스터를 관리합니다. 이러한 대규모 클러스터 관리 경험을 바탕으로 높은 처리량과 내구성 목표를 달성하기 위해 고객이 사용하는 전형적인 클러스터 구성에 대한 통찰력을 얻었습니다. 높은 처리량을 달성하기 위해 고객들은 복제 대기 시간을 줄이기 위해 복제본을 삭제하여 운영하는 방식을 선택하는 경우가 많습니다. 그러나 이러한 구성은 가용성과 내구성을 희생하는 결과를 낳습니다. 하지만, 높은 내구성을 필요로 하는 고객들은 여러 개의 복제본을 유지해야 하기에 데이터 저장 비용이 높아집니다.

OpenSearch Optimized Instance(OR1) 제품군은 HAQM S3에 데이터 복제본을 저장함으로써 비용을 낮추고 내구성을 향상시킵니다. OR1 인스턴스를 사용하면 높은 색인 처리량을 유지하면서 높은 읽기 가용성을 위해 복제본을 여러 개 구성할 수 있습니다.

다음 다이어그램은 OR1의 메타데이터 업데이트와 관련된 색인 흐름을 보여줍니다.

색인 작업이 진행되는 동안 개별 문서는 Lucene에 색인되고 트랜스로그 로그에 추가됩니다. 클라이언트에 색인에 의해 처리 되기 전에 모든 트랜스로그 작업은 HAQM S3가 지원하는 원격 데이터 저장소에 영구 저장됩니다. 복제본이 구성된 경우, 기본 복사본은 정확성 확인을 위해 모든 복제본에 대해 여러 작성자(제어 흐름)의 가능성을 감지하는 검사를 수행합니다.

다음 다이어그램은 OR1 인스턴스에서 세그먼트 생성 및 복제 흐름을 보여줍니다.

새로운 세그먼트 파일이 생성될 때마다, OR1은 그 세그먼트를 HAQM S3에 복사합니다. 전송이 완료되면, 프라이머리 샤드는 새로운 체크포인트를 모든 복제본에 게시하여 새로운 세그먼트를 다운로드할 수 있는 상태임을 전달합니다. 이후에 복제본은 새로운 세그먼트를 다운로드하여 검색 가능하도록 만듭니다. 이 모델은 HAQM S3를 사용하는 데이터 흐름과 노드 간 전송 통신을 통해 발생하는 제어 흐름(체크포인트 게시 및 용어 검증)을 분리합니다.

다음 다이어그램은 OR1 인스턴스에서의 복구 흐름을 보여줍니다.

OR1 인스턴스는 데이터뿐만 아니라 인덱스 매핑, 템플릿, 설정과 같은 클러스터 메타데이터도 HAQM S3에 유지합니다. 이로써 전용 관리자 노드를 구성하지 않은 아닌 일반적인 데이터 노드만 존재하는 클러스터의 쿼럼 손실의 경우에도 OpenSearch가 마지막으로 승인된 메타데이터를 안정적으로 복구할 수 있습니다.

인프라 장애가 발생하면, OpenSearch 도메인은 하나 이상의 노드를 잃을 수 있습니다. 이런 경우, 새로운 인스턴스 패밀리는 최신으로 승인된 작업까지 클러스터 메타데이터와 인덱스 데이터의 복구를 보장합니다. 새로운 대체 노드가 클러스터에 합류하면, 내부 클러스터 복구 메커니즘이 새로운 노드 세트를 부트스트랩한 다음 원격 클러스터 메타데이터 저장소에서 최신 클러스터 메타데이터를 복구합니다. 클러스터 메타데이터가 복구된 후, HAQM S3에서 누락된 세그먼트 데이터와 트랜스로그를 다운로드 받기 시작합니다. 그런 다음, 승인된 작업까지 커밋되지 않은 트랜스로그 작업이 복구되어 손실된 복제본을 복원합니다.

새로운 디자인은 검색 작동 방식을 수정하지 않습니다. 쿼리는 인덱스의 각 샤드에 대해 기본 또는 복제 샤드에 의해 정상적으로 처리됩니다. 데이터 복제가 HAQM S3를 사용하기 때문에 모든 복사본이 특정 시점에 일치하기까지 10초 정도의 더 긴 지연이 발생할 수 있습니다.

이 아키텍처의 주요 장점은 읽기 와 쓰기의 분리, 컴퓨팅 및 저장 레이어의 분리 등과 같은 미래의 혁신을 위한 기초적인 구성 요소로 사용된다는 점입니다.

복제 전략 개선으로 색인 처리량 향상

OpenSearch는 두 가지 복제 전략을 지원합니다. 하나는 논리 복제(document replication), 다른 하나는 물리 복제(segment replication)입니다. 논리 복제의 경우 각 복제본에서 데이터를 개별적으로 인덱싱하므로 클러스터에 중복된 연산이 발생합니다. 반면, 새로운 OR1 인스턴스에서는 물리적 복제 방식을 사용하며, 주(primary) 샤드에서만 데이터를 인덱싱한 후 다른 복제본들은 이 데이터를 주 샤드로부터 복사하여 생성합니다. 그러나 복제본의 수가 많을 경우, 주 복제본이 모든 복제본에게 세그먼트 데이터를 복사하는 과정에서 상당한 네트워크 대역폭이 요구됩니다. 새로운 OR1 인스턴스는 이러한 문제를 해결하기 위해 인덱싱된 세그먼트를 HAQM S3에 원격 스토리지(remote storage)로 영구히 저장합니다. 이를 통해 주 복제본이 병목 현상 없이 많은 수의 복제본을 효과적으로 확장할 수 있습니다.

세그먼트가 HAQM S3에 업로드된 후, 주 샤드는 체크포인트 요청을 보내 모든 복제본에 새로운 세그먼트를 다운로드하라고 알립니다. 그러면 복제본은 증분 세그먼트를 다운로드해야 합니다. 이 프로세스는 복제본의 컴퓨팅 자원을 확보해 줍니다. 그렇지 않으면 데이터를 중복적으로 색인하고 데이터를 복제하는 프라이머리에 발생하는 네트워크 오버헤드를 처리해야 하기 때문입니다. 따라서, 클러스터는 더 많은 처리량을 처리할 수 있습니다. 복제본이 과부하 또는 느린 네트워크 경로로 인해 새로 생성된 세그먼트를 처리할 수 없는 경우, 특정 지점을 초과하는 복제본은 오래된 결과를 반환하지 않도록 실패한 것으로 표시됩니다.

높은 내구성의 어려움

모든 커밋된 세그먼트는 생성될 때마다 HAQM S3에 영구적으로 유지됩니다. 높은 내구성을 달성하는 데 있어 핵심적인 과제 중 하나는 클라이언트에 대한 요청을 승인하기 전에 처리량을 유지하면서 커밋되지 않은 모든 작업을 HAQM S3에 트랜스로그를 동기식으로 기록하는 것입니다.

새로운 복제 전략은 개별 요청에 대한 네트워크 지연 시간을 추가적으로 발생시키지만, 이 전략은 지정된 간격 동안 단일 스레드에서 요청을 배치하고 처리하는 동시에 다른 스레드가 요청 색인을 계속 생성하도록 하여 처리량에 영향을 미치지 않게 합니다. 이렇게 함으로써 OpenSearch는 데이터 내구성을 보장하면서도 시스템의 전체 성능을 유지할 수 있습니다. 결과적으로, 대량 페이로드를 최적으로 배치함으로써 더 많은 동시 클라이언트 연결로 더 높은 처리량을 얻을 수 있습니다.

고가용성 시스템을 설계할 때의 또 다른 과제는 데이터의 무결성과 정확성을 항상 유지하도록 강제하는 것입니다. 네트워크 분할과 같은 이벤트는 드물게 발생하지만, 발생 시 시스템의 정확성을 위협할 수 있으므로 이러한 장애 상황(failure mode)에 대비해야 합니다. 따라서 새로운 세그먼트 복제 프로토콜로 전환하면서 각 복제본(replica)에 다수의 쓰기 주체가 존재하는 상황을 탐지하는 등 프로토콜에 몇 가지 추가적인 변경을 도입했습니다. 이를 통해 클러스터 매니저의 쿼럼에 의해 새롭게 승격된 주 복제본이 새로운 쓰기 요청을 수락하고 있을 때, 다른 쓰기 주체가 중복으로 쓰기 요청을 승인하지 않도록 보장합니다.

새로운 인스턴스 패밀리는 데이터를 복구하는 동안 주 샤드의 손실을 자동으로 감지하고, 데이터가 HAQM S3에서 다시 활성화되고 클러스터가 정상 상태로 돌아오기 전에 네트워크 연결 가능성에 대한 광범위한 검사를 수행합니다.

데이터 무결성을 위해 모든 파일은 광범위하게 체크섬을 통해 검사되어, 데이터가 읽을 수 없게 되는 네트워크 또는 파일 시스템 손상을 감지하고 방지할 수 있도록 합니다. 또한, 메타데이터를 포함한 모든 파일은 변경할 수 없도록 설계되어 손상에 대한 추가적인 안전성을 제공하고, 우발적인 변경을 방지하기 위해 버전 관리됩니다.

데이터 흐름의 재구성

OR1 인스턴스는 인프라 장애 발생 시 손실된 샤드를 복구하기 위해 HAQM S3에서 직접 복사본을 다운로드합니다. HAQM S3를 사용함으로써, 주 노드의 네트워크 대역폭, 디스크 처리량, 컴퓨팅 능력을 확보할 수 있게 되었고, 따라서 최소한의 주 노드 조정으로 전체 과정을 조율함으로써 보다 원활한 인플레이스 확장 및 블루/그린 배포 경험을 제공할 수 있게 되었습니다.

OpenSearch Service는 매시간 간격으로 스냅샷이라는 자동 데이터 백업을 제공합니다. 즉, 실수로 데이터를 수정하는 경우 이전 시점으로 되돌릴 수 있는 옵션이 제공됩니다. 그러나 새로운 OR1 인스턴스 제품군을 사용하면 데이터가 이미 HAQM S3에 영구적으로 저장된다는 점을 논의했습니다. 그렇다면 이미 HAQM S3에 데이터가 존재하는 경우 스냅샷은 어떻게 작동할까요?

OR1 인스턴스를 사용하면 스냅샷이 체크포인트 역할을 하여 특정 시점에 존재하는 기존 세그먼트 데이터를 참조합니다. 이렇게 하면 추가 데이터를 다시 업로드할 필요가 없기 때문에 스냅샷이 더 가볍고 빨라집니다. 대신, 해당 시점의 세그먼트 보기를 캡처하는 메타데이터 파일을 업로드합니다. 이를 얕은 스냅샷이라고 합니다. 얕은 스냅샷의 이점은 스냅샷의 생성, 삭제, 복제와 같은 모든 작업에 적용됩니다. 다른 관리 작업을 위해 수동 스냅샷을 사용하여 독립적인 사본을 스냅샷할 수 있는 옵션이 여전히 있습니다.

정리

OpenSearch는 오픈 소스, 커뮤니티 중심 소프트웨어입니다. 복제 모델, 원격 백업 스토리지, 원격 클러스터 메타데이터를 포함한 대부분의 기본 변경 사항이 오픈 소스에 기여되었습니다. HAQM OpenSearch Service는 오픈 소스 우선 개발 모델을 따릅니다.

처리량과 신뢰성을 향상시키기 위한 노력은 지속해서 배우고 개선해 나감에 따라 끝이 없는 순환입니다. 새로운 OpenSearch Optimized Instance(OR1)는 기초적인 구성 요소의 역할을 수행하며, 미래의 혁신을 위한 길을 열어줍니다. HAQM OpenSearch Service를 사용하는 빌더들이 어떤 새로운 솔루션을 구축하고 기존 솔루션을 어떻게 개선하는지 지켜보며 신뢰성과 성능을 향상시키기 위해 오픈 소스 커뮤니티는 지속적으로 노력 하고 있습니다. 이 게시글을 통해 새로운 OpenSearch 인스턴스 제품군에 대한 이해가 깊어지기를 바랍니다. 이 새로운 인스턴스가 어떻게 높은 내구성과 더 나은 처리량을 달성하는지, 그리고 비즈니스 요구에 따라 클러스터를 구성하는지 이해하는 데 도움이 되기를 바랍니다.

OpenSearch에 기여하고 싶다면, 깃허브 이슈를 열고 의견을 보내 주세요.