확장성을 고려하여 Elasticsearch 데이터 스토리지 아키텍처를 설계하는 방법

Elasticsearch를 사용하면 대규모의 정형 및 비정형 데이터를 저장, 검색 및 분석할 수 있습니다. 이러한 속도, 확장성 및 유연성 덕분에 Elastic Stack은 시스템 통합 가시성, 보안(위협 헌팅 및 방지), 엔터프라이즈 검색 등 사양한 사용 사례에 적합한 강력한 솔루션이 될 수 있습니다. 이 유연성 때문에 확장성을 고려하여 배포 데이터 스토리지의 아키텍처를 효과적으로 설계하는 것이 매우 중요합니다.

모든 Elasticsearch 사용 사례가 다른 것은 당연합니다. 고유한 사용 사례/배포/비즈니스 상황에는 총 소유 비용, 수집 성능, 쿼리 성능, 백업 수/크기, 평균 복구 시간 등과 같은 특정 허용 범위와 임계값이 있을 것입니다.

이러한 여러 가지 요소를 고려할 때 다음 3가지 질문을 숙고하면 자칫 복잡해질 수 있는 의사 결정 매트릭을 간소화할 수 있습니다.

• 사용 사례/배포에서 어느 정도의 데이터 손실을 허용할 수 있는가?
• 비즈니스 목표에서 성능이 차지하는 비중은 어느 정도인가?
• 프로젝트에서 수용할 수 있는 가동 중단 시간은 어떻게 되는가?

이 블로그에서는 사용 가능한 몇 가지 데이터 스토리지 옵션을 살펴보고 각 옵션의 장단점을 알아보겠습니다. 이 블로그를 다 읽고 나면 확장성을 고려하여 자체 Elasticsearch 배포 데이터 스토리지의 아키텍처를 설계하는 방법을 더 잘 이해하실 수 있을 것입니다.

이런 문제로 골치 아프기 싫으시다고요? 반가운 소식은 Elastic Cloud의 Elasticsearch Service를 도입하시면 저희가 확장성을 고려한 아키텍처를 대신 설계해 드린다는 것입니다.

옵션 요약

다음은 Elasticsearch 데이터 스토리지의 아키텍처를 설계할 수 있는 옵션을 요약한 표로 이 블로그에서 다루게 될 내용입니다. 이어서 각 옵션의 장단점과 데이터 손실, 성능 및 가동 중단 시간과 관련하여 예상되는 사항에 대해 자세히 설명하겠습니다.

디스크 용량 확장을 고려할 때 선택할 수 있는 좋은 옵션들이 몇 가지 있습니다. 이러한 옵션을 살펴보고 각각의 장단점을 알아보겠습니다. 모든 상황은 각기 다르므로 모든 사용자에게 효과가 있는 한가지 접근 방식은 없습니다.

RAID 0

RAID는 수십 년 동안 여러 디스크를 결합하는 데 초석이 되어 왔습니다. RAID에는 미러링, 스트라이핑 및 패리티라는 3가지 구성 요소가 있습니다. RAID의 각 숫자는 이러한 구성 요소의 고유한 조합을 나타냅니다.

RAID에서 숫자 0은 스트라이핑을 의미합니다. 스트라이핑은 데이터를 청크로 분할하고 볼륨의 모든 디스크에 이러한 청크를 쓰는 작업입니다.

성능 및 용량

스트라이핑하면 모든 디스크에 병렬로 쓸 수 있으므로 읽기/쓰기 성능이 향상됩니다. 실제로 이렇게 하면 어레이에 있는 디스크 수에 비례하여 쓰기 및 읽기 성능이 증가합니다. 따라서 RAID 0 어레이에 6개의 디스크가 있는 경우 읽기/쓰기 속도가 최대 6배 빨라집니다.

복구

RAID 0은 복구를 제공하지 않으므로 Elasticsearch는 스냅샷이나 복제본을 통해 복구를 처리해야 합니다. 디스크 크기와 데이터를 어레이에 복사하는 데 사용되는 전송 메커니즘에 따라 복구 처리에 시간이 상당히 많이 걸릴 수 있습니다. 복구 작업 중에는 네트워크 트래픽 및 다른 노드의 성능이 영향을 받습니다.

주의 사항

Elasticsearch 인덱스는 여러 개의 샤드로 구성되므로 인덱스에 디스크 장애가 발생한 RAID 0 볼륨의 샤드가 포함되어 있는 경우 다른 복제본이 없다면 해당 인덱스도 손상될 수 있습니다. 따라서 백업을 관리할 스냅샷 수명 수기 관리(SLM) 기능이 없거나 복제본을 생성하도록 Elasticsearch를 구성하지 않은 경우 영구적인 데이터 손실이 발생합니다.

장단점

RAID 1

성능 및 용량

RAID에서는 미러링이 숫자 1로 표시됩니다. 미러링은 동일한 데이터를 다른 디스크에 쓰는 프로세스입니다. 사실상 데이터의 복사본을 만드는 것입니다. 데이터가 두 디스크 모두에 작성되만, 대부분의 RAID 구현에서는 읽기에 두 디스크를 사용하지는 않습니다. 따라서 읽기/쓰기 성능은 실질적으로 절반으로 감소합니다. 동일한 데이터가 두 디스크 모두에 작성되므로 용량도 절반으로 줄어듭니다.

복구

RAID 1은 두 개의 디스크로만 확장되도록 만들어졌습니다. 따라서 한 디스크에 오류에 발생하더라도 다른 디스크에 있는 데이터는 보존됩니다. 즉, 성능과 용량을 희생하여 뛰어난 데이터 중복성을 얻을 수 있습니다. 한 디스크에 오류가 발생하는 경우 해당 디스크를 교체하기만 하면 데이터가 새 디스크에 복사됩니다.

주의 사항

RAID 1이 2개의 디스크만 지원하므로 대부분의 경우 RAID 1은 RAID 0과 쌍을 이룹니다. 즉, 여러 RAID 1 볼륨을 스트라이프 RAID 0에 쌍으로 연결하게 됩니다. 이를 RAID 10이라고 하며 디스크가 4개 이상일 때 사용합니다.

이를 통해 RAID 0의 성능 이점과 RAID 1의 중복성을 함께 활용할 수 있습니다. RAID 10의 성능은 어레이에 있는 디스크 수에 따라 달라집니다. RAID 10의 성능은 Nx/2입니다.

장단점

RAID 5, 6

성능 및 용량

RAID에서는 패리티가 2, 3, 4, 5, 6의 숫자로 표시됩니다. 2, 3 및 4는 대부분 다른 RAID로 대체되므로 여기서는 5와 6에 초점을 맞추겠습니다. 패리티는 컴퓨터가 디스크 장애로 인해 누락된 데이터를 수정하거나 계산하는 방법입니다. 패리티는 스트라이핑 작업에 데이터 보호를 추가합니다. 데이터 복구에는 대가가 따릅니다. RAID 5는 패리티를 위해 디스크 1개, RAID 6은 디스크 2개의 용량을 사용합니다.

복구

RAID 5와 6에서 고려해야 할 또 다른 사항은 복구 및 재구축 시간입니다. 재구축은 어레이에서 이전 디스크를 교체하기 위해 새 디스크가 추가될 때 발생합니다. 회전 디스크의 경우 디스크 용량을 추가하는 대신 디스크 수를 추가하십시오. 디스크 수가 많을수록 읽기/쓰기 시간뿐만 아니라 재구축 시간도 늘어납니다. SSD의 경우 고용량 디스크가 읽기/쓰기 성능도 더 빠른지 확인해야 합니다. 대부분의 고용량 SSD 디스크는 읽기/쓰기 성능이 더 뛰어납니다. 이런 경우 고용량 디스크가 읽기/쓰기 성능을 향상하는 데 도움이 됩니다. RAID 5는 디스크 장애를 1개까지 허용하므로 2개부터 어레이에서 데이터가 손실됩니다. RAID 6은 디스크 장애를 2개까지 허용하므로 3개부터 데이터가 손실됩니다.

주의 사항

RAID 5 및 6이 디스크 장애를 허용할 수는 있지만 대가가 따릅니다. RAID 5의 경우 새 디스크가 추가되기 전까지는 사실상 RAID 0만큼 취약해집니다. 실제로 또 다른 디스크에 장애가 발생하면 어레이의 모드 데이터가 손실되고 다른 샤드 또는 스냅샷에서 복구해야 합니다. 디스크 배치는 거의 동시에 고장 날 수 있으므로 RAID 6을 실행하는 것이 좋습니다. 처음에 언급했듯이 성능과 데이터 무결성에 대한 프로젝트 허용 범위를 이해하는 것이 RAID 5와 6중 하나는 결정하는 데 중요합니다.

디스크가 손실되면 어레이가 패리티를 사용하여 디스크에서 읽어오는 데이터를 다시 계산해야 하므로 디스크 손실도 RAID 5와 6 모두의 성능에 큰 영향을 미칩니다.

장단점

Elasticsearch의 다중 데이터 경로(MDP)

Elasticsearch에는 Elasticsearch 데이터 파일의 파일 시스템 위치를 구성하는 데 사용되는 path.data라는 설정이 있습니다. path.data용 목록이 지정되면 Elasticsearch는 여러 위치를 사용하여 데이터 파일을 저장합니다. 예를 들어 elasticsearch.yml에 다음이 포함된 경우,

path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]

Elasticsearch는 여러 파일 시스템 위치에 쓰게 됩니다. 이러한 각 경로는 별도의 디스크일 수 있습니다.

다중 데이터 경로를 정의하면 사용자가 여러 데이터 저장소에서 작동하도록 Elasticsearch를 설정할 수 있습니다.

성능 및 용량

Elasticsearch는 데이터를 샤드로 분할하고 샤드는 여유 공간이 가장 많은 데이터 경로에 작성됩니다. 하나의 샤드가 쓰기 작업 대부분을 수신할 경우 성능이 하나의 데이터 경로 속도로 제한됩니다. 그러나 데이터가 데이터 경로 전체에 균등하게 작성되는 경우 사용되는 모든 디스크의 쓰기 속도를 활용하게 됩니다. Elasticsearch는 쓰기 작업이 여러 데이터 경로에 걸쳐 이루어도록 보장하지 않으므로 성능이 가변적이며 일관되지 않습니다.

MDP는 데이터의 미러링 또는 패리티를 포함하지 않습니다. 즉, 장단점 섹션에서 자세히 설명된 워터마크를 제외하고 모든 디스크 용량을 데이터를 저장하는 데 사용할 수 있습니다. 전체 디스크 용량을 사용하려면 샤드 수가 최소한 데이터 경로 수와 같아야 합니다.

다른 경로에 이미 데이터가 있는 노드에 새 데이터 경로를 추가하면 새 디스크에 워크로드가 집중될 수 있습니다. Elasticsearch는 데이터 경로 간에 샤드 밸런싱 작업을 하지 않으므로 여유 공간이 가장 많은 새 경로로 모든 새 샤드가 전송됩니다. Elasticsearch는 시작할 때만 elasticsearch.yml 업데이트를 읽으므로 디스크를 추가하려면 전체 노드를 다시 시작해야 합니다.

복구

디스크는 언젠가 고장이 납니다. 다중 데이터 경로에 포함된 스토리지 디바이스가 손상되면 노드가 노란색으로 바뀌고 해당 디바이스에 있는 데이터에 액세스할 수 없게 됩니다. 그러나 Elasticsearch는 손상된 데이터 경로에 계속해서 쓰려고 시도하므로 IOException이 발생합니다. 이러한 오류가 발생하지 않도록 하려면 다음을 수행하여 Elasticsearch 노드 구성에서 손상된 데이터 경로를 제거하는 것이 중요합니다.

1. 샤드 할당을 비활성화합니다.
2. 노드를 중지합니다.
3. Elasticsearch config에서 손상된 데이터 경로를 제거합니다.
4. 노드를 다시 시작합니다.
5. 샤드 할당을 다시 활성화합니다.

영구적인 데이터 손실을 방지하려면 복제가 활성화되도록 Elasticsearch를 구성해야 합니다. 기본값은 샤드당 복제본 하나입니다.

그러면 Elasticsearch가 다른 노드 간 샤드 밸런싱을 다시 수행합니다. Elasticsearch는 데이터 경로 간 샤드 밸런싱을 수행하지 않습니다. 자세한 내용은 주의 사항 섹션을 참조하세요. 클러스터에 밸런싱을 다시 수행할만한 용량이 없으면 노드는 노란색으로 유지됩니다.

새 디스크를 교체하려면 디스크를 분리하고 모든 LVM 그룹을 비활성화해야 합니다. 그러면 OS가 새 디스크를 적절하게 처리할 수 있습니다. 새 디스크가 설치되면 해당 경로를 다시 Elasticsearch path.data 설정에 추가해야 합니다. 손상된 디스크가 교체되고 나면 Elasticsearch가 새 디스크를 사용하기 시작합니다.

주의 사항

다중 데이터 경로에 지정된 디바이스가 손상되면 다음번 샤드 할당에서 해당 경로가 무시됩니다. 그러나 그다음에 이어지는 할당에서는 해당 경로를 샤드 할당에 적합한 것으로 간주하게 됩니다. 따라서 위에서 설명한 조치를 취하지 않으면 IOExeption 오류가 발생할 수 있습니다.

Elasticsearch는 노드별로 워터마크를 처리합니다. 하나의 데이터 경로가 상위 워터마크에 도달하면 전체 노드가 상위 워터마크에 도달하므로 이 점에 유의해야 합니다. 다른 데이터 경로에 여유 공간이 충분한 경우에도 이 문제가 발생합니다. 즉, 워터마크에 도달한 노드가 더는 새 샤드를 수락하지 않거나, 해당 노드에서 샤드를 적극적으로 이동시키거나, 해당 노드를 읽기 전용 상태로 전환하게 됩니다.

500GB의 데이터 경로가 6개 있는 총 용량 3TB의 노드를 예로 들어 보겠습니다. 단일 데이터 경로가 90%의 디스크 사용률에 도달할 수 있습니다. 그러면 전체 노드가 고수위 워터마크에 도달하여 노드가 읽기 전용으로 전환됩니다. 이러한 현상은 노드에 있는 다른 디스크의 사용률이 50% 미만인 경우에도 발생합니다.

Elasticsearch는 단일 노드 내에서 샤드 밸런싱을 처리하지 않습니다. 즉, 데이터 경로 간 샤드의 균형을 유지하지 않습니다. 따라서 사용자가 다중 데이터 경로를 사용하는 경우 Elasticsearch는 해당 시점에 가장 여유 공간이 많은 디스크에 샤드를 배치합니다. 하나의 샤드가 다른 샤드보다 더 많은 데이터를 수신하고 디스크를 채우더라도 Elasticsearch는 샤드 밸런싱을 수행하지 많습니다. 이러한 특성을 모를 경우 IO 로드가 불균등하게 분산될 수 있습니다. 또한 다른 경로의 데이터가 포함된 노드에 새 디스크를 추가하면 새 경로에 높은 IO 로드가 발생할 수 있습니다.

장단점

결론

데이터가 증가하기 시작하는 시점이 온다는 것은 정말 기쁜 일입니다! 이 블로그에서 다양한 옵션과 도구를 살펴보았지만, 확장성을 고려하여 데이터 저장 공간의 아키텍처를 설계할 때 ‘하나로 모든 요건을 충족하는’ 솔루션은 없다는 것을 기억하시기 바랍니다.

확장성을 고려하여 Elasticsearch 배포 저장 공간의 아키텍처를 설계하는 방법에 대해 여전히 궁금하거나 고민되는 점이 있으시면 토론 포럼에 글을 남겨 주세요. 저뿐만 아니라 계속 확장되고 있는 사용자 커뮤니티에서 도와드릴 것입니다.

직접 모든 것을 관리하고 싶지 않으시다면 앞에서 말씀드렸듯이 Elastic Cloud가 이 모든 것을 대신 관리해 드립니다. 확장은 노드를 하나 더 추가하는 것만큼 쉽습니다. 박스를 열고 랙에 탑재하고 관리해야 할 서버가 없습니다. 또한 이미 사용하고 계신 Amazon Web Services, Google Cloud Platform 및 Microsoft Azur 어디서나 작동합니다. 지금 무료로 사용해 보시는 건 어떨까요?