Elasticsearch 7.7에서는 이전 버전에서보다 훨씬 더 적은 힙 메모리를 사용하게 되며, 따라서 Elasticsearch 클러스터 안정성이 개선되고 대량의 데이터를 저장하는 비용이 절약됩니다.

<p>Elasticsearch 사용자가 Elasticsearch 노드에 데이터를 저장할 수 있는 용량의 한계까지 최대한 이용하고 있을 때, 디스크 공간이 부족해지기 전에 힙 메모리가 부족해지는 경우가 가끔 발생합니다. 이러한 사용자에게는 무척 실망스러운 상황입니다. <a href="/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster">노드당 가능한 한 많은 데이터를 채우는 것이</a> 종종 비용을 줄이는 데 중요하기 때문입니다.
</p><p>그러나 왜 Elasticsearch는 데이터를 저장하기 위해 힙 메모리를 필요로 할까요? 왜 그냥 디스크 공간만 필요로 하지 않을까요? 몇 가지 이유가 있지만 주된 이유는 Lucene이 디스크의 어디를 찾아봐야 하는지 알 수 있도록 메모리에 일부 정보를 저장해야 하기 때문입니다. 예를 들어, Lucene의 역 인덱스는 정렬된 순서로 디스크 상에서 용어를 블록으로 그룹화하는 용어 사전과 용어 사전에서 빠르게 찾아보기 위한 용어 인덱스를 구성합니다. 이 용어 인덱스는 용어의 접두사를 해당 접두사를 갖는 용어를 포함하는 블록이 시작되는 디스크의 오프셋과 매핑합니다. 용어 사전은 디스크 상에 있지만 용어 인덱스는 최근까지도 힙에 있었습니다.
</p><p>인덱스는 얼만큼의 메모리를 필요로 할까요? 통상적으로 인덱스의 GB당 몇 MB 정도입니다. 이것은 그리 많은 것은 아니지만 사용자가 노드에 점점 더 많은 테라바이트의 디스크를 장착하고 있어, 이러한 테라바이트의 인덱스를 저장하려면 인덱스는 금방 10-20GB의 힙 메모리를 필요로 하기 시작합니다. 30GB의 힙을 초과하지 말라는 Elastic의 권장 사항을 고려하면, 이로 인해 집계와 같이 힙 메모리를 사용해야 하는 다른 요소들을 위한 여유가 빠듯하게 되며, JVM이 클러스터 관리 운영을 위해 충분한 공간을 남겨두지 않는 경우 안정성 문제가 시작되게 됩니다.
</p><p>실제 수치를 살펴봅시다. Elastic은 여러 데이터 세트에 대해 <a href="https://benchmarks.elastic.co">야간 벤치마크</a>를 실행하고, 시간에 걸쳐 다양한 메트릭을, 특히 세그먼트의 메모리 사용을 추적합니다. <a href="https://www.geonames.org/">Geonames</a> 데이터 세트는 흥미로운데, 다음과 같이 <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/geonames/nightly/default/6M">Elasticsearch 7.x에서 발생한 다양한 변경 사항의 영향을 분명하게 보여주기 때문입니다</a>.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb41b157438550179/5ea2ddf2ae23d30cd1dfb100/heap-reduction-7-7-nightly-geonames-blog.png" data-sys-asset-uid="bltb41b157438550179" alt="Geonames 데이터 세트에 대한 야간 벤치마크" style="display: block; margin: auto;">
</p><p>이 인덱스는 디스크에서 약 3GB를 차지하며 6개월 전에는 ~5.2MB의 메모리를 필요로 했었습니다. 이것은 ~1:600의 힙:저장 공간 비율입니다. 따라서 각 노드에 총 10TB를 장착했다면, 10TB / 600 = 17GB의 힙이 필요하게 됩니다. 그래야 Geonames 같은 데이터를 저장하는 인덱스를 계속해서 열어둘 수 있습니다. 그러나 보시다시피, 시간이 지나면서 개선이 이루어졌습니다. 포인트(짙은 파랑색)는 훨씬 더 적은 메모리를 요구하기 시작했고, 그 다음에는 용어(분홍색)가 그 다음에는 저장된 필드(초록색)가 마침내 용어가 다시 큰 요인이 됩니다. 힙:저장 공간 비율은 이제 ~1:4000이며 6.x와 초기 7.x 릴리즈에 비해 거의 7배의 개선을 보여줍니다. 이제 10TB의 인덱스를 계속 열어두는 데 단지 2.5GB의 힙 메모리만 필요하게 됩니다.
</p><p>데이터 세트에 따라 수치는 <strong>엄청나게</strong> 다양한데, 좋은 소식은 Geonames가 힙 사용량이 가장 적게 감소된 것으로 나타나는 데이터 세트 중 하나라는 것입니다. 힙 사용량이 Geonames에서 7배까지 줄어든 반면 <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/nyc-taxis/nightly/default/6M">NYC taxis</a>와<a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/http-logs/nightly/default/6M">HTTP logs</a> 데이터 세트에서는 100배 이상 줄어들었습니다. 다시 한 번 알 수 있지만, 이러한 변화는 Elasticsearch의 이전 버전이 감당할 수 있었을 것보다 노드당 훨씬 더 많은 데이터를 저장함으로써 비용을 줄이는 데 도움이 됩니다.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7c2002e630ac3974/5ea2de1f52608c261aab78aa/heap-reduction-7-7-nightly-taxis-blog.png" data-sys-asset-uid="blt7c2002e630ac3974" alt="NYC taxis 데이터 세트에 대한 야간 벤치마크" style="display: block; margin: auto;">
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb15c6244ebc49571/5ea2de6952608c261aab78b0/heap-reduction-7-7-nightly-http-logs-blog.png" data-sys-asset-uid="bltb15c6244ebc49571" alt="HTTP logs 데이터 세트에 대한 야간 벤치마크" style="display: block; margin: auto;">
</p><p>이것은 어떻게 작동하며 그 함정은 무엇일까요? 동일한 방법을 Lucene 인덱스의 여러 구성 요소에 시간을 두고 적용해 보았습니다. 데이터 구조를 JVM 힙에서 디스크로 이동하고 메모리의 핫 비트를 유지하기 위해 파일 시스템 캐시(종종 페이지 캐시 또는 OS 캐시라고 부름)에 의존하는 것입니다. 이것은 이 메모리가 아직도 사용되며 그냥 다른 곳에 할당되는 것으로 해석할 수도 있지만 현실은 이 메모리의 상당 부분이 사용 사례에 따라 그저 한 번도 사용되지 않았다는 것입니다. 예를 들어 <code>용어</code>의 최종 드랍은 디스크 상의 <code>_id</code> 필드의 용어 인덱스를 옮기는 것 때문이었으며, 이것은 GET API를 사용할 때나 또는 명시적인 ID를 가진 문서를 색인할 때만 유용합니다. 로그와 메트릭을 Elasticsearch로 색인하는 대다수의 사용자는 전혀 이러한 작업을 하지 않으며 따라서 그러한 사용자에게 이것은 리소스의 순이익이 됩니다.
</p><h2>7.7로 Elasticsearch 힙을 줄이세요!</h2><p>Elasticsearch 7.7에서 제공될 이러한 개선 사항에 대해 정말 기대가 됩니다. 여러분도 그러시길 바랍니다. 향후 릴리즈 발표를 지켜봐 주시고, 그 다음에 직접 테스트해 보세요. 여러분의 기존 배포에서 사용해 보거나 Elastic Cloud의 Elasticsearch Service <a href="/kr/elasticsearch/service">무료 체험판을 사용해 보세요</a>(무료 체험판은 언제나 Elasticsearch의 최신판입니다). 여러분의 피드백을 듣고 싶습니다. 어떻게 생각하시는지 <a href="https://discuss.elastic.co/">토론</a> 게시판에서 알려주세요.
</p>

elasticsearch-blog-banner.png

elasticsearch-blog-thumb.png

Coming in 7.7: Significantly decrease your Elasticsearch heap memory usage

7.7의 새로운 기능: Elasticsearch 힙 메모리 사용 대폭 감소

Elasticsearch 7.0에서는 형식을 허용하는 API의 사용을 중단하고, 새로운 무형식 API를 도입했으며, _default_ 매핑에 대한 지원을 폐지했습니다.

<p>5.0부터 Elasticsearch에서 형식을 제거하기 위한 준비 작업을 해왔고, 7.0에서 마침내 사용이 중단되었습니다. 형식의 목표는 단일한 인덱스 내에서 멀티테넌시를 제공하는 것이었습니다. 그러나 이것은 Lucene과 호환이 되지 않습니다. 아쉽게도 형식이 해결하는 문제보다 더 많은 문제를 야기하는 것으로 드러났습니다.&nbsp;형식당 고유한 필드를 사용하거나 내부적으로 형식당 하나의 인덱스를 갖는 식으로 이 사안을 피하며 작업해야 하는지 여부를 놓고 오랫동안 논의를 거쳐 우리는 그 대신 형식에 대한 지원을 중단하기로 결정했습니다. 사용자가 보다 손쉽게 이행할 수 있도록, 우리는 네 개의 메이저 버전에 걸쳐 변경을 진행했습니다.
</p>
<ul>
	<li>5.0은 여러 형식에서 동일한 이름을 공유하는 필드가 호환되는 매핑을 갖도록 적용하기 시작했습니다.</li>
	<li>6.0은 새 인덱스가 하나 이상의 형식을 갖지 못하도록 했으며 <code>_default_</code> 매핑의 사용을 중단했습니다.</li>
	<li>7.0은 형식을 허용하는 API의 사용을 중단했고, 새로운 무형식 API를 도입했으며, <code>_default_</code> 매핑에 대한 지원을 폐지했습니다.</li>
	<li>8.0은 형식을 허용하는 API를 제거하게 됩니다.</li>
</ul>
<h2>무형식 API</h2>
<p>URL 경로, 요청 본문 또는 응답 본문에서 형식을 허용하는 모든 API는 새로운 “무형식” 등가물을 갖게 됩니다. 이것은 인덱스 큐레이션, 인덱스, GET API 같이 아주 흔한 일부 API의 경우입니다. 실제 예를 하나 보여드리는 것이 천 마디의 말보다 더 효과적일 것입니다. 다음 예를 보시면, 7.0 클러스터가 무형식 API와 어떤 식으로 상호 작용하는지 볼 수 있습니다.
</p>
<pre class="prettyprint">PUT index
{
  "mappings": {
    "properties": { // Note how there is no top-level key with the type name
      "@timestamp": {
        "type": "date"
      }
    }
  }
}
PUT index/_doc/1 // _doc becomes the new endpoint for document index, get and delete requests
{
  "@timestamp": "2019-02-20"
}
POST index/_bulk
{"index": {"_id": "2"}} // no _type in the URL or in document metadata
{"@timestamp": "2019-03-01"}
{"update": {"_id": "1"}}
{"@timestamp": "2019-02-21"}
GET index/_doc/2
GET index/_search // unchanged, the `GET index/{type}/_search` endpoint is deprecated however
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-01-01"
      }
    }
  }
}
GET index/_explain/1 // note how the type does not appear in the URL anymore, this would have been "GET index/{type}/1/_explain" in 6.x
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-01-01"
      }
    }
  }
}
</pre>
<h2>무엇을 해야 할까요?</h2>
<p>일부 변경 사항은 끊기기 때문에, 사용자는 7.0으로 업그레이드하기 <strong>전에</strong> 클러스터에 변경을 해야 합니다. 일부 다른 변경 사항은 8.0으로의 업그레이드에 대해서만 요구되며, 7.0으로 업그레이드한 후에 수행해야 합니다.
</p>
<h3>업그레이드에 앞서</h3>
<h4>6.8을 사용 중인지 확인</h4>
<p>가동 중단 시간 없이 단계적으로 업그레이드할 계획인 경우, 먼저 6.8로 업그레이드해야 합니다. 6.8은 <code>include_type_name</code> 매개변수에 대한 지원 같은 일부 기능을 갖는 유일한 6.x 릴리즈이며, 7.0으로 순조롭게 업그레이드하려면 꼭 필요합니다.
</p>
<h4>_default_ 매핑 사용 중지</h4>
<p><code>_default_</code> 매핑은 7.0에서 중단됩니다. 기존의 일부 6.x 인덱스가 <code>_default_</code> 매핑을 갖는 경우, <code>_default_</code> 매핑은 새 인덱스에서만 거부되기 때문에 괜찮습니다.
</p>
<p>인덱스 템플릿과 애플리케이션 코드를 업데이트해야만 이러한 매핑을 <code>_default_</code> 매핑에 포함시키는 대신 실제 형식에 추가할 수 있습니다. 형식의 이름이 중요하지 않은 경우, <code>_doc</code>을 사용할 것을 권장합니다. 이것은 앞으로 더 손쉽게 무형식 API로 이행할 수 있게 해줍니다.
</p>
<h4><code>include_type_name=true</code>를 인덱스 생성, 템플릿, 매핑 API로 전달</h4>
<p>무형식 API로의 이행은 요청 본문이 형식을 필요로 하는 API가 이제 다른 형식을 예상하게 된다는 뜻입니다.
</p>
<ul>
	<li>인덱스 생성</li>
	<li>매핑 넣기</li>
	<li>템플릿 넣기</li>
</ul>
<p>응답 시 형식을 반환하는 다른 API는 다른 응답 포맷을 갖게 됩니다.
</p>
<ul>
	<li>인덱스 가져오기</li>
	<li>매핑 가져오기</li>
	<li>필드 매핑 가져오기</li>
	<li>템플릿 가져오기</li>
</ul>
<p>이러한 변경으로 인해 지장을 받지 않으려면, 애플리케이션이 <code>include_type_name=true</code>를 이러한 API 호출에 전달하도록 해야 합니다. 이것은 6.x에서는 no-op이며, 6.x에서 그렇게 했던 것처럼 7.x가 이러한 API를 동작시키도록 알려줍니다. 예를 들어, 다음은 이 매개변수를 이용하는 인덱스 생성 호출입니다. 6.8과 7.x에서도 동일한 방식으로 작동합니다.
</p>
<pre class="prettyprint">PUT index?include_type_name=true
{
  "mappings": {
    "my_type": {
      "properties": { // Note how there is no top-level key with the type name
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}
</pre>
<h3>업그레이드 후</h3>
<p>권장되는 업그레이드 전 단계를 따랐다면, 모든 것은 잘 작동해야 합니다. 그러나, 이 단계에서 여전히 형식을 허용하는 API를 사용하고 있다면, 이것은 사용 중단 경고를 트리거합니다. 이 경고를 제거하려면, 무형식 API로 이행해야 합니다.
</p>
<p>인덱스 생성, 템플릿과 매핑 API의 경우, URL 매개변수에서 <code>include_type_name=true</code>를 제거하고, 요청 본문이나 응답 포맷에 대한 예상을 변경해야 합니다. 여기에 더 이상 형식이 포함되지 않기 때문입니다. 일반적으로, 요청 본문이나 응답에 매핑이 포함되면, 다음과 같이 보이는 섹션을 갖습니다.
</p>
<pre class="prettyprint">{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}
</pre>
<p>이것이 더 이상 형식 이름을 포함하지 않도록 업데이트되어야 하며, 이제 다음과 같이 보이게 됩니다.
</p>
<pre class="prettyprint">{
  "properties": ...
}
</pre>
<p>인덱스, GET, 또는 업데이트 API 같은 다른 API의 경우, URL의 형식 이름을 <code>_doc</code>으로 바꿔야 합니다. 이것은 인덱스 형식의 이름과 상관없이 작동하게 됩니다. 예를 들어, 형식 이름이 <code>my_type</code>인 인덱스에 대해 인덱스 호출을 수행하기 위해 사용한 경우, 인덱스 호출은 다음과 같이 보였습니다.
</p>
<pre class="prettyprint">PUT index/my_type/1
{
  "@timestamp": "2019-02-20"
}
</pre>
<p>이것은 다음과 같이 바뀌어야 합니다.
</p>
<pre class="prettyprint">PUT index/_doc/1
{
  "@timestamp": "2019-02-20"
}
</pre>
<h2>자세히 보기</h2>
<p>형식 제거와 무형식 API로의 마이그레이션 방법에 대해 더 자세히 알고 싶으시면, <a href="/guide/en/elasticsearch/reference/7.0/removal-of-types.html">형식 제거 설명서</a>를 참조하실 것을 권해 드립니다. 이 설명서에서는 이러한 변경의 의미와 변경 준비 방법에 대해 훨씬 더 상세하게 살펴봅니다.
</p>
<p><a href="/kr/downloads/elasticsearch">7.0.0을 다운로드</a>하셔서, 이 새로운 무형식 API를 사용해 보시고, 어떻게 생각하시는지 <a href="https://discuss.elastic.co/">토론</a> 게시판을 통해 알려주세요.
</p>

Articles by Adrien Grand

7.7의 새로운 기능: Elasticsearch 힙 메모리 사용 대폭 감소

형식에서 무형식으로

제품

회사 소개

리소스