인프라가 커지면 비용도 커집니다. Elasticsearch Service가 어떻게 비용 효율적으로 확장하는 데 필요한 유연성을 제공하는지 상세하게 설명해드리겠습니다.

<p>수천 명의 고객들이 공식적인 Elastic Cloud의 Elasticsearch Service(ESS)를 기반으로 Elasticsearch뿐 아니라 <a href="/kr/log-monitoring">Elastic Logs</a>, <a href="/kr/apm">Elastic APM</a>, <a href="/kr/siem">Elastic SIEM</a> 등과 같은 독점 제품을 실행합니다. 7년이 넘는 기간 동안 운영되고 있는 ESS는 모든 기능, 모든 솔루션, 소스로부터의 지원을 갖춘 완전한 Elasticsearch 환경을 제공하는 유일한 관리형 서비스입니다. 아울러 이러한 제품을 보완하는 수많은 운영 및 배포 혜택도 제공합니다.
</p>
<p><a href="/kr/blog/remove-the-hidden-network-costs-for-your-logs-metrics-and-apm-data-by-using-elasticsearch-service">이전 포스팅</a>에서는 서비스, 인프라 또는 로깅 장치와 동일한 지역에 있지 않은 SaaS 솔루션 사용 시 숨겨진 네트워크 비용에 대해 설명했습니다. 이러한 경우 상당한 요금을 부담해야 할 수 있습니다. 이 포스팅에서는 Elastic Cloud의 Elasticsearch Service가 어떻게 작업량이 늘어남에 따라 비용을 통제하기 위한 다양한 전략을 선택할 수 있는 유연성을 제공하는지 중점적으로 소개해드립니다.
</p>
<p>어떤 측면에서든 성장하게 되면, 특히 가시성과 보안 공간 측면에서 성장하는 경우, 로그, 메트릭, APM 추적, 그리고 애플리케이션이 생성한 보안 이벤트를 저장하는 데 필요한 인프라가 증가하며, 이것은 추가 비용으로 이어집니다. ESS는 좀더 오랜 기간 동안 의미있는 데이터를 계속 유지하면서도, 그리고 다양한 소스의 데이터 통합, 시각화 옵션, 경보, 이상 징후 탐색 등 Elastic Stack의 유용한 동일 기능을 제공하면서도 비용을 통제하기 위해 데이터를 관리하는 데 도움이 되는 수많은 방법을 제공합니다.
</p>
<p>가시성과 보안 사용 사례 같은 시계열 데이터를 위해 사용할 수 있는 비용 절약 기회를 검토해보겠습니다. 예시를 위해, 사람들이 Elastic Stack을 사용하는 가장 일반적인 적용 분야 중 하나인 인프라 모니터링에 대해 다루겠습니다. Elastic Stack에는 클라이언트에 위치하며 클러스터로 데이터를 전송하는 경량 에이전트 컬렉션인 <a href="/kr/beats">Beats</a>가 포함됩니다. 팀들은 CPU 사용률, 디스크 IOPS, 또는 Kubernetes에서 실행되는 애플리케이션에 대한 컨테이너 텔레메트리 같은 시스템 메트릭을 전송하기 위해 <a href="/kr/beats/metricbeat">Metricbeat</a>를 널리 사용하고 있습니다.
</p>
<p>애플리케이션 사용 공간을 확장함에 따라, 모니터링을 하려면 생성되고 있는 메트릭을 저장하기 위해 더 많은 저장 공간이 필요하게 됩니다. 보존 기간을 정의하는 것은 현재 팀들이 대량의 시계열 데이터를 관리하기 위해 사용하는 한 가지 전략입니다. 현재 ESS와 함께 기본 제공되는 추가적인 저장 공간 효율성 옵션을 탐색해보겠습니다.
</p>
<h2>시나리오</h2>
<p>연속성을 위해, 각 에이전트가 메트릭당 100바이트를 수집하고 10초마다 100개의 메트릭을 수집하며 데이터 보존 기간이 30일인 1,000개의 호스트를 모니터링하는 클러스터를 위한 비용 절약 전략을 알아보겠습니다. 또한 <a href="/guide/en/cloud/current/ec-planning.html">고가용성</a>을 위해 클러스터에 데이터 복제본을 저장하겠습니다. 이것은 노드 작동에 장애가 생길 경우 데이터 손실을 방지해줍니다. 얼마나 저장 공간이 필요하게 될지 계산해보겠습니다.
</p>
<table><colgroup><col></colgroup>
<tbody>
<tr>
	<td>
		<p><code>호스트 1,000개 * 100바이트 * 메트릭 100개 * 60/10 분당 빈도수 * 60*24*30(30일 동안) * 2(복제본당)</code>
		</p>
		<p><code>= 5184000000000바이트 또는 5.184TB</code>
		</p>
	</td>
</tr>
</tbody>
</table>
<p>따라서 이 메트릭을 저장하려면 5.2TB의 저장 공간이 필요합니다. 간단히 하기 위해, Elasticsearch 클러스터 운영에 필요한 저장 공간은 무시하겠습니다.
</p>
<p>요약하자면,
</p>
<table style="width:100%">
<tbody>
<tr>
	<td>모니터링되는 호스트
	</td>
	<td>1,000개
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>매일 수집되는 양(GB)
	</td>
	<td>86.4GB
	</td>
</tr>
<tr>
	<td>보존 기간
	</td>
	<td>30일
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>복제본 개수
	</td>
	<td>1개
	</td>
</tr>
<tr>
	<td>필요한 저장 공간(복제본 포함)
	</td>
	<td>5.184TB
	</td>
</tr>
</tbody>
</table>
<h2>hot-warm 배포와 인덱스 수명 주기 관리를 이용한 더욱 효율적인 저장 공간
</h2>
<p>로깅과 메트릭 같은 가시성 사용 사례에서 데이터의 활용도는 시간이 지남에 따라 줄어듭니다. 통상적으로 팀들은 최근 데이터를 활용하여 시스템&nbsp;사고, 네트워크 트래픽의 갑작스러운 사용량 급증 또는 보안 경보를 신속하게 조사합니다. 데이터가 오래되면, 클러스터에 계속 위치하며 클러스터의 나머지 부분처럼 동일한 컴퓨팅, 메모리, 저장 공간 리소스를 사용하지만 쿼리 요청 빈도는 점점 더 줄어듭니다. 이로 인해 결과적으로 두 개의 뚜렷이 다른 데이터 액세스 패턴이 나타나지만 클러스터는 빠른 수집과 요청이 빈번한 쿼리에만 최적화되어 있으며 그리 자주 액세스되지 않는 데이터의 저장에는 최적화되어 있지 않습니다.
</p>
<p>Elasticsearch Service에 <a href="/kr/blog/deploying-a-hot-warm-logging-cluster-on-the-elasticsearch-service">hot-warm 아키텍처</a>를 적용해봅시다. 이 배포 옵션은 동일한 Elasticsearch 클러스터에서 두 개의 하드웨어 프로필을 제공합니다. hot 노드는 새로 들어오는 모든 데이터를 처리하며, 신속하게 데이터를 수집하고 검색할 수 있도록 더 빠른 저장 공간을 사용합니다. warm 노드는 저장 공간 밀도가 더 높으며, 데이터를 더 장기간 보존하는 데 보다 비용 효율적입니다.
</p>
<p>Elasticsearch Service에서 hot 노드의 경우 통상적으로 로컬로 연결된 NVMe SSD를 1:30의 메모리-대-디스크 비율로 프로비저닝하며, warm 노드의 경우 고밀도 HDD를 1:160의 비율로 프로비저닝합니다. 이 강력한 아키텍처는 또 다른 중요 기능인 <a href="/guide/en/elasticsearch/reference/current/index-lifecycle-management.html">인덱스 수명 주기 관리</a>(ILM)와 밀접한 관련이 있습니다. ILM은 시간이 지나면서 인덱스 관리를 자동화하는 방법을 제공합니다. 이를 통해 인덱스 크기, 문서의 개수, 또는 인덱스가 오래된 정도와 같은 특정 기준에 따라 데이터를 hot 노드에서 warm 노드로 간편하게 이동시킵니다.
</p>
<p>이 두 기능을 함께 작동시키면, 클러스터에서 두 개의 구분되는 하드웨어 프로필을 얻게 되며, 인덱스 자동화 도구를 통해 계층(Tier)&nbsp;간에 데이터를 이동시킬 수 있습니다.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt87a7937a28252849/5db2fe272140ec675d690487/ESS-hot-warm-moving-tiers-blog.png" data-sys-asset-uid="blt87a7937a28252849" alt="hot-warm 배포" style="display: block; margin: auto;">
</p>
<p>이제 hot-warm 배포로 마이그레이션하고 ILM 정책을 구성해보겠습니다. ESS에서 새로운 <a href="/guide/en/cloud/current/ec-getting-started-templates-hot-warm.html">hot-warm 배포</a>를 생성하고 선택에 따라 다른 클러스터의 스냅샷을 복원할 수 있습니다. 이미 기존의 높은 I/O 배포가 있는 경우, 클러스터에 warm 노드를 추가하여 간단히 <a href="/guide/en/cloud/current/ec-migrate-templates.html">hot-warm 배포로 마이그레이션</a>할 수 있습니다. ILM 정책을 사용하여 7일 동안에는 데이터를 hot 계층에 보관하고 그 다음에는 데이터를 warm 노드로 이동시킬 것입니다.
</p>
<p>내부적으로, 데이터가 warm 단계로 이동되면 더 이상 여기에 인덱스를 작성할 수 없습니다. warm 노드에서는 복제 데이터를 저장하지 않도록 선택할 수 있기 때문에 이것은 비용을 절약할 수 있는 또 다른 기회를 제공합니다. warm 노드 작동에 장애가 생기면, 복제본이 아니라 저장된 최신 스냅샷에서 복원하게 됩니다.
</p>
<p>이러한 접근 방법의 단점은 스냅샷에서 복원하는 것이 통상적으로 속도가 더 느리며 장애 후 문제를 해결하는 데 시간이 더 오래 걸릴 수 있다는 점입니다. 그러나 warm 노드는 통상적으로 쿼리 요청 빈도가 적은 데이터를 포함하고 이로 인해 실제적인 영향은 감소하기 때문에 많은 경우 이런 정도는 용인할 수 있습니다.
</p>
<p>마지막으로 우리의 원래 보존 정책에 따라 30일의 데이터 보존 기간에 이르면 이 데이터를 삭제하겠습니다. 위에서 한 것과 비슷한 수학을 사용해 이 접근 방법을 요약하면 다음과 같습니다.
</p>
<table style="width:100%">
<tbody>
<tr style="background-color:#E8F6FE;">
	<td>
	</td>
	<td style="text-align: center;"><strong>일반 클러스터</strong>
	</td>
	<td style="text-align: center;"><strong>hot-warm + ILM</strong>
	</td>
</tr>
<tr>
	<td>모니터링되는 호스트
	</td>
	<td>1,000개
	</td>
	<td>1,000개
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>매일 수집되는 양(GB)
	</td>
	<td>86.4GB
	</td>
	<td>86.4GB
	</td>
</tr>
<tr>
	<td>보존 기간
	</td>
	<td>30일
	</td>
	<td>
		hot: 7일
		<br>
		warm: 30일
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>필요한 복제본
	</td>
	<td>1개
	</td>
	<td>
		hot 노드: 1개
		<br>
		warm 노드: 0개
	</td>
</tr>
<tr>
	<td>저장 공간 요건
	</td>
	<td>5.184TB
	</td>
	<td>
		hot: 1.2096TB(복제본 포함)
		<br>
		warm: 1.9872TB(복제본 없음)
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>대략적으로 필요한 클러스터 크기
	</td>
	<td>232GB RAM(6.8TB SSD 저장 공간)
	</td>
	<td>
		hot: 58GB RAM, SSD 사용
		<br>
		warm: 15GB RAM, HDD 사용
	</td>
</tr>
<tr>
	<td>월 클러스터 비용
	</td>
	<td>$3,772.01
	</td>
	<td>$1,491.05
	</td>
</tr>
</tbody>
</table>
<p>이 접근 방법은 여전히 검색 가능하며 복원력이 있는 데이터를 보유하면서도 월 비용에서 60%라는 상당한 금액을 절약하게 해줍니다. ILM 정책을 미세 조정하여 이상적인 롤오버 기간을 찾아내면 warm 노드에서의 저장을 최대한 이용하는 데 도움이 될 수 있습니다.
</p>
<h2>데이터 롤업으로 더 많은 저장 공간 확보</h2>
<p>고려해볼 수 있는 또 다른 저장 공간 절약 옵션은 <a href="/kr/blog/how-to-create-manage-and-visualize-elasticsearch-rollup-data-in-kibana">데이터 롤업</a>입니다. Elasticsearch의 단일한 요약 문서로 데이터를 “롤업”함으로서 롤업 API는 데이터를 요약하여 보다 작은 크기로 저장할 수 있게 해줍니다. 그러면 원본 데이터를 아카이브로 보관하거나 삭제하여 저장 공간을 확보할 수 있습니다.
</p>
<p>롤업을 생성할 때, 향후 분석을 위해 관심이 있는 모든 필드를 선택하게 되고 바로 그 롤업된 데이터만 이용해 새로운 인덱스가 생성됩니다. 이것은 계속해서 시간 경과에 따른 추세를 보여주면서 분당, 시간당 또는 매일과 같이 분할 단위가 큰 설정에서 손쉽게 요약될 수 있는 숫자 데이터를 주로 다루는 모니터링 사용 사례에서 특히 유용합니다. 요약된 인덱스는 Kibana 전체에 걸쳐 제공되며 기존 대시보드와 함께 손쉽게 추가되어 모든 분석 작업에서 장애로 인해 중단되는 경우를 피할 수 있습니다. 이것은 모두 Kibana에서 직접 구성할 수 있습니다.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltecada94734b9a556/5e55331906f84d0d618daa52/ess-cost-savings-rollups-blog.jpg" data-sys-asset-uid="bltecada94734b9a556" alt="롤업 작업 생성" style="display: block; margin: auto;">
</p>
<p>위의 시나리오를 계속 진행하면서, 고가용성을 위한 복제본 세트를 포함해 1,000개의 호스트로부터 30일분의 메트릭 데이터를 저장하기 위해 5.2TB의 저장 공간이 필요했던 것을 기억해봅시다. 그 다음으로 hot-warm 배포 템플릿을 사용하는 시나리오를 설명했습니다. 이제 데이터 롤업 API를 사용해 데이터가 7일이 되면 수행할 롤업 작업을 구성하겠습니다. 훨씬 더 많은 저장 공간을 확보하면서 분할 단위의 크기는 좀더 커지게 됩니다.
</p>
<p>데이터 롤업 작업을 설정하여 10초의 메트릭 데이터를 시간당 요약된 문서로 롤업하겠습니다. 이를 통해 여전히 시간당 간격으로 더 오래된 메트릭을 쿼리하고 시각화할 수 있으며, Kibana와 Lens에서 데이터의 추세와 다른 중요한 순간을 나타내기 위해 이를 사용할 수 있습니다. 다음으로는 방금 롤업한 원본 문서를 삭제해 클러스터에서 대량의 저장 공간을 확보하겠습니다. 계산을 해본다면, 방금 롤업한 데이터에 대해 얼마의 저장 공간이 필요한지 계산할 수 있습니다.
</p>
<table><colgroup><col></colgroup>
<tbody>
<tr>
	<td>
		<p><code>호스트 1,000개 * 100바이트 * 메트릭 100개 * 60/3600 분당 빈도수 * 60*24*23(23일 동안)</code>
		</p>
		<p><code>= 5520000000바이트 또는 5.52GB</code>
		</p>
	</td>
</tr>
</tbody>
</table>
<p>롤업된 이 문서의 원본 데이터는 7일보다 더 오래되었으며 따라서 hot-warm 클러스터의 warm 노드에 저장되어 있습니다. 1.99TB의 데이터 전체를 간단히 삭제할 수 있습니다. 오른쪽 열은 방금 작업이 끝난 상태를 나타냅니다.
</p>
<table style="width:100%">
<tbody>
<tr style="background-color:#E8F6FE;">
	<td>
	</td>
	<td style="text-align: center;"><strong>일반 클러스터</strong>
	</td>
	<td style="text-align: center;"><strong>hot-warm + ILM</strong>
	</td>
	<td style="text-align: center;"><strong>Hot-warm + ILM, 롤업된 데이터 포함</strong>
	</td>
</tr>
<tr>
	<td>모니터링되는 호스트
	</td>
	<td>1,000개
	</td>
	<td>1,000개
	</td>
	<td>1,000개
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>매일 수집되는 양(GB)
	</td>
	<td>86.4GB
	</td>
	<td>86.4GB
	</td>
	<td>86.4GB
	</td>
</tr>
<tr>
	<td>보존 기간
	</td>
	<td>30일
	</td>
	<td>
		hot: 7일
		<br>
		warm: 30일
	</td>
	<td>
		hot: 7일
		<br>
		warm: 30일
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>단위 크기
	</td>
	<td>10초
	</td>
	<td>10초
	</td>
	<td>
		처음 7일: 10초
		<br>
		7일 후: 1시간
	</td>
</tr>
<tr>
	<td>필요한 복제본
	</td>
	<td>1개
	</td>
	<td>
		hot 노드: 1개
		<br>
		warm 노드: 0개
	</td>
	<td>
		hot 노드: 1개
		<br>
		warm 노드: 0개
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>저장 공간 요건
	</td>
	<td>5.184TB
	</td>
	<td>
		hot: 1.2096TB(복제본 포함)
		<br>
		warm: 1.9872TB(복제본 없음)
	</td>
	<td>
		hot: 1.2096TB(복제본 포함)
		<br>
		warm: 5.52GB(복제본 없음, 롤업된 데이터)
	</td>
</tr>
<tr>
	<td>대략적으로 필요한 클러스터 크기
	</td>
	<td>232GB RAM(6.8TB SSD 저장 공간)
	</td>
	<td>
		hot: 58GB RAM, SSD 사용
		<br>
		warm: 15GB RAM, HDD 사용
	</td>
	<td>
		hot: 58GB RAM, SSD 사용
		<br>
		warm: 2GB RAM, HDD 사용
	</td>
</tr>
<tr style="background-color:#F6F7FA;">
	<td>월 클러스터 비용
	</td>
	<td>$3,772.01
	</td>
	<td>$1,491.05
	</td>
	<td>$1,024.92
	</td>
</tr>
</tbody>
</table>
<p>비용 절감의 차이는 엄청납니다. 데이터 롤업을 기존의 hot-warm 클러스터에 추가하면 비용의 31%를 절약할 수 있습니다. 최종 시나리오를 일반적인 단일 하드웨어 계층 클러스터와 비교하면 그 결과는 훨씬 더 증폭됩니다. 73%를 절약할 수 있으니까요!
</p>
<h2>내 방식대로 배포</h2>
<p>각 방법마다 그 나름의 장점과 치러야 하는 대가가 있습니다. 그리고 여러분은 각 전략을 미세 조정하여 필요에 꼭 맞게 만들 수 있는 유연성을 얻을 수 있습니다.
</p>
<p><strong>ILM</strong> 정책을 통해 인덱스 크기에 따라 롤오버 기간, 문서의 개수 또는 문서의 보존 기간을 정의할 수 있으며, <strong>hot-warm</strong> 클러스터에서 이 정책에 따라 데이터가 warm 노드로 이동합니다. warm 노드는 많은 저장 공간을 효율적으로 압축할 수 있어, 컴퓨팅 비용을 줄이는 데 도움이 됩니다. 쿼리 시간은 hot 노드만큼 성능이 좋지 않을 수 있지만, 이로 인해 쿼리 요청 빈도가 많지 않은 데이터에 대해서는 선호하는 접근 방법이 됩니다.
</p>
<p><strong>데이터 롤업</strong>은 분할 단위 크기가 더 큰 문서로 데이터를 요약하며, 이것은 데이터가 오래 되어 해당 시점에 분할 단위가 더 작은 원래의 세분성이 더 이상 필요하지 않은 경우 유용하다는 것이 입증되었습니다. 그리고 나서 소스 문서는 저장 공간 비용을 절약하는 데 도움이 되도록 삭제될 수 있습니다. 사용자는 어느 정도의 크기까지 문서를 요약할 것인지, 아울러 언제 요약할 것인지를 정의할 수 있습니다. 롤업된 데이터가 계속해서 시간에 따른 추세나 트래픽 사용량 급증으로 인한 시스템 동작 같은 주요 분석 정보를 제공할 수 있도록 적절한 균형을 찾으세요.
</p>
<p>Elasticsearch 클러스터의 메트릭 작업량을 최적화하기 위한 기본 전략을 숙지했습니다. 그럼 모든 추가 저장 공간으로 무엇을 해야 할까요? Elastic Stack은 로그, APM 추적, 감사 이벤트, 엔드포인트 데이터 등 수많은 사용 사례에 대해 전 세계적으로 사용됩니다.
</p>
<p>Elastic Cloud의 Elasticsearch Service는 개발자의 운영 전문 지식과 더불어 Elastic Stack에서 전해드려야 하는 모든 것을 제공합니다. 새로운 사용 사례로 확장할 준비가 되지 않으셨다면, 저장 공간 최적화를 활용하여 계속해서 클러스터를 적극적으로 사용할 수 있습니다. 데이터 보존 시간을 확장하고 비슷한 가격대에서 훨씬 더 많이 저장하거나 몇 번의 클릭만으로 가시성을 그대로 유지하면서 클러스터 크기를 줄이고 아울러 비용도 절감하세요.
</p>
<p>Elastic Cloud의 Elasticsearch Service를 시작하려고 하시나요? <a href="/kr/cloud/elasticsearch-service/signup">14일 무료 체험판을 사용해보세요</a>.
</p>

AUTHOR

Articles by Osman Ishaq

Elasticsearch Service를 위한 비용 절약 전략: 데이터 저장 공간 효율성

제품

회사 소개

리소스

솔루션

Elastic (ELK) Stack

새 소식

AUTHOR

Articles by Osman Ishaq

Elasticsearch Service를 위한 비용 절약 전략: 데이터 저장 공간 효율성