서버리스 환경 로드 밸런싱을 위한 Elasticsearch 복제본

Elastic Cloud Serverless는 검색 부하에 따라 인덱스 복제본 수를 자동으로 조정하여 수동 구성 없이도 최적의 쿼리 성능을 보장합니다. 이 블로그에서는 복제본이 확장되는 방식, 시스템이 복제본을 추가하거나 제거하는 경우, 이것이 인덱스에 갖는 의미를 설명합니다.

파티가 점점 붐비고 있습니다

여러분이 피자 파티를 주최하는 중입니다. 몇 명의 친구들이 파티 장소의 각기 다른 장소에서 서빙을 돕고 있습니다. 각 친구에게 피자를 한 조각씩 건네주면, 친구들은 도착하는 배고픈 손님들에게 피자 조각을 나눠주기 시작합니다.

처음에는 모든 것이 순조롭게 진행됩니다. 손님 몇 명이 조금씩 들어오고, 친구들이 피자 조각을 나눠 주니, 모두가 만족합니다. 하지만 곧 사워도우 피자에 대한 소문이 퍼지기 시작합니다. 초인종이 계속 울립니다. 손님들이 몰려듭니다. 곧 모두가 먹고 싶어 하는 페퍼로니 피자를 들고 있는 친구 주위로 사람들이 모여들기 시작합니다.

페퍼로니 피자를 든 친구는 어쩔 줄을 모릅니다. 손님들이 기다리고 있으며, 점점 불만이 쌓이고 있고, 긴 대기 줄이 형성되었습니다. 한편, 마르게리타 피자를 든 친구는 한 조각 달라고 하는 사람이 거의 없이 가만히 서 있습니다.

이제 어떻게 할까요?

여러분은 페퍼로니 피자 몇 개를 더 주문하여 다른 친구들에게 건넵니다. 이제 한 명이 아닌 세 명의 친구가 페퍼로니 피자를 들고 있습니다. 인파가 분산되어 갑자기 3배나 많은 손님을 한꺼번에 대접할 수 있습니다.

파티를 더 주최할수록 몇 가지 사실이 분명해집니다.

모든 피자가 똑같이 인기 있는 것은 아닙니다. 어떤 것은 수요가 많고, 다른 것은 수요가 적습니다. 인기 없는 피자는 추가 '사본'이 없어도 됩니다. 대기열이 있는 것만 추가하면 됩니다.
대기열이 너무 길어지기 전에 피자를 더 주문하세요. 친구가 허둥지둥거리고 손님들이 화를 내며 떠나기 시작할 때까지 기다린다면, 너무 오래 기다린 것입니다. 인파가 몰리는 게 보이면 피자를 한 판 더 주문하는 것이 좋습니다.
피자를 너무 빨리 버리지 마세요. 페퍼로니 피자 주변에 5분 동안 인파가 줄었다고 해서 혼잡한 시간이 끝난 것은 아닙니다. 어쩌면 사람들은 음료를 다시 채우고 있거나 서로 대화하고 있을지도 모릅니다(요즘도 그러나요?). 추가 피자를 유지해 주세요. 잠잠한 상태가 한동안 계속된다면, 그땐 피자를 치워도 됩니다.
도와주는 친구 수만큼만 피자를 나눠줄 수 있습니다. 도와주는 친구가 네 명이면 피자를 열 판으로 늘려도 결과는 달라지지 않습니다. 한 번에 네 조각만 제공할 수 있습니다. 피자의 수를 도와주는 인원에 맞춰야 합니다.
친구가 떠나면 피자를 가져오세요. 친구 중 한 명이 떠나야 한다면 즉시 그들의 피자를 가져오세요. 피자를 방치하면 안 됩니다. 다른 사람에게 건네주거나 치워두세요.

피자부터 복제품까지

이것을 다시 Elasticsearch에 매핑해 볼까요.

이 비유에서 피자는 복제본(인덱스 샤드 복사본), 서빙을 돕는 친구들은 검색 노드, 배고픈 손님은 검색 쿼리, 주변에 인파가 모인 인기 있는 피자는 검색 부하가 높은 핫 인덱스입니다.

특정 인덱스에서 검색 트래픽이 증가하면 추가 복제본을 생성하여 검색 노드 전체에 배포합니다. 모든 복제본은 해당 인덱스에 어떤 쿼리든 서빙할 수 있습니다. 마치 페퍼로니 피자를 든 친구가 페퍼로니 피자 조각을 나눠줄 수 있는 것처럼 말이죠. 복제본 수가 많을수록 처리량이 높아집니다. 복제본이 세 개면 복제본 한 개보다 초당 3배 더 많은 쿼리를 처리할 수 있습니다.

허기 측정

피자를 몇 개나 주문할지 결정하기 전에, 우리는 사람들이 얼마나 배고픈지 알아야 합니다.

Elasticsearch는 모든 샤드의 검색 부하를 추적합니다. 검색 부하는 샤드가 처리하는 검색 활동의 양을 나타내는 지표입니다. 전체 검색 수요를 파악하기 위해 인덱스의 전체 샤드에서 이를 집계합니다.

가장 중요한 것은 상대적 검색 부하입니다. 즉, 프로젝트의 전체 검색 트래픽 중 각 인덱스에 도달하는 비율을 파악하는 것입니다. 한 인덱스가 전체 검색의 60%를 받고 다른 인덱스가 5%를 받는다면, 어디에 용량을 추가해야 할지 알 수 있겠죠.

피자에 숨겨진 수학적 원리

다음 공식에 따라 최적의 복제본 수를 계산합니다.

위치:

L은 인덱스의 상대적 검색 부하(0~1 사이)입니다.
N =프로젝트에서 원하는 검색 노드 개수입니다.
S = 인덱스의 샤드 수입니다.
X = 핫스팟을 방지하기 위한 임계값입니다(기본값: 0.5).

예시: 검색 노드 4개, 기본 샤드 2개를 가진 인덱스 1개, 검색 트래픽의 80%를 수신하는 경우:

이 핫 인덱스는 검색 노드에 분산된 네 개의 복제본을 갖습니다.

임계값 X(기본값은 0.5)가 중요합니다. 복제본이 완전히 과부하될 때까지 기다리지 않고, 용량의 절반에 도달하면 규모를 확장합니다. 손님이 떠날 때가 아니라 인파가 모이기 시작할 때 여분의 피자를 나눠줍니다.

신속한 확장과 느긋한 축소

검색 부하가 증가하면 즉시 복제본을 추가합니다. 사용자를 기다리게 할 이유가 없습니다.

검색 부하가 떨어지면 조치를 취하기 전에 잠시 기다립니다. 낮은 수요가 약 30분 동안 일관적으로 지속되어야 복제본을 줄입니다. (이는 급증하는 트래픽을 처리하기 위한 것이며 조용한 순간이 파티가 끝났다는 의미는 아닙니다.)

복제본을 추가하려면 비용이 들기 때문에 이는 중요한 문제입니다. 새로운 복제본은 데이터를 복사하고 캐시를 워밍한 후 쿼리를 효율적으로 처리합니다. 너무 성급하게 복제본을 제거하면 트래픽의 자연스러운 변동에 따라 지속적으로 이러한 시작 비용을 지불하게 됩니다.

토폴로지 경계 준수

복제본 수는 검색 노드 수를 초과할 수 없습니다. 노드보다 더 많은 복제본을 갖는 것은 아무런 이점이 없습니다(피자 조각을 제공하는 친구의 수만큼만 피자를 제공할 수 있습니다).

프로젝트에서 노드가 제거되면 복제본 수를 즉시 줄여서 노드 수와 일치시킵니다. 할당되지 않은 복제본을 보유할 수 없기 때문에 쿨다운을 기다리지 않습니다. 친구가 떠나는 순간, 그 피자도 제거됩니다.

더 큰 서버리스 그림

검색 로드 밸런싱을 위한 복제본은 다른 자동 확장 시스템과 함께 작동합니다.

검색 자동 확장은 검색 노드 수(도와주는 친구 수)를 조정합니다.
검색 부하 분산을 위한 복제본은 인덱스당 복제본 수(종류별로 필요한 피자 수)를 조정하여 트래픽을 분산합니다.
데이터 스트림 자동 샤딩은 쓰기에 대한 샤드 수를 최적화합니다(각 피자를 자르는 방법은 이전 포스트에서 다뤘습니다).

중요한 설계 원칙: 로드 밸런싱용 복제본은 검색 자동 확장을 직접 유발하지 않습니다. 대신, 검색 요청을 더 많은 복제본에 분산함으로써 검색 노드 전체의 리소스 사용량을 높일 수 있습니다. 이렇게 높은 사용량은 필요한 경우 용량을 추가하도록 기존의 자동 확장 로직을 작동시킵니다. 로드 밸런싱을 위한 복제본은 자동 확장이 제 기능을 수행하도록 하여, 다른 노드가 사용되지 않는 동안 모든 트래픽이 단일 복제본에 병목 현상을 일으키는 대신 검색 노드가 실제로 사용되도록 합니다.