형식에서 무형식으로

By
Adrien Grand

5.0부터 Elasticsearch에서 형식을 제거하기 위한 준비 작업을 해왔고, 7.0에서 마침내 사용이 중단되었습니다. 형식의 목표는 단일한 인덱스 내에서 멀티테넌시를 제공하는 것이었습니다. 그러나 이것은 Lucene과 호환이 되지 않습니다. 아쉽게도 형식이 해결하는 문제보다 더 많은 문제를 야기하는 것으로 드러났습니다. 형식당 고유한 필드를 사용하거나 내부적으로 형식당 하나의 인덱스를 갖는 식으로 이 사안을 피하며 작업해야 하는지 여부를 놓고 오랫동안 논의를 거쳐 우리는 그 대신 형식에 대한 지원을 중단하기로 결정했습니다. 사용자가 보다 손쉽게 이행할 수 있도록, 우리는 네 개의 메이저 버전에 걸쳐 변경을 진행했습니다.

  • 5.0은 여러 형식에서 동일한 이름을 공유하는 필드가 호환되는 매핑을 갖도록 적용하기 시작했습니다.
  • 6.0은 새 인덱스가 하나 이상의 형식을 갖지 못하도록 했으며 _default_ 매핑의 사용을 중단했습니다.
  • 7.0은 형식을 허용하는 API의 사용을 중단했고, 새로운 무형식 API를 도입했으며, _default_ 매핑에 대한 지원을 폐지했습니다.
  • 8.0은 형식을 허용하는 API를 제거하게 됩니다.

무형식 API

URL 경로, 요청 본문 또는 응답 본문에서 형식을 허용하는 모든 API는 새로운 “무형식” 등가물을 갖게 됩니다. 이것은 인덱스 큐레이션, 인덱스, GET API 같이 아주 흔한 일부 API의 경우입니다. 실제 예를 하나 보여드리는 것이 천 마디의 말보다 더 효과적일 것입니다. 다음 예를 보시면, 7.0 클러스터가 무형식 API와 어떤 식으로 상호 작용하는지 볼 수 있습니다. 

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"
      }
    }
  }
}

무엇을 해야 할까요?

일부 변경 사항은 끊기기 때문에, 사용자는 7.0으로 업그레이드하기 전에 클러스터에 변경을 해야 합니다. 일부 다른 변경 사항은 8.0으로의 업그레이드에 대해서만 요구되며, 7.0으로 업그레이드한 후에 수행해야 합니다.

업그레이드에 앞서

6.8을 사용 중인지 확인

가동 중단 시간 없이 단계적으로 업그레이드할 계획인 경우, 먼저 6.8로 업그레이드해야 합니다. 6.8은 include_type_name 매개변수에 대한 지원 같은 일부 기능을 갖는 유일한 6.x 릴리즈이며, 7.0으로 순조롭게 업그레이드하려면 꼭 필요합니다.

_default_ 매핑 사용 중지

_default_ 매핑은 7.0에서 중단됩니다. 기존의 일부 6.x 인덱스가 _default_ 매핑을 갖는 경우, _default_ 매핑은 새 인덱스에서만 거부되기 때문에 괜찮습니다.

인덱스 템플릿과 애플리케이션 코드를 업데이트해야만 이러한 매핑을 _default_ 매핑에 포함시키는 대신 실제 형식에 추가할 수 있습니다. 형식의 이름이 중요하지 않은 경우, _doc을 사용할 것을 권장합니다. 이것은 앞으로 더 손쉽게 무형식 API로 이행할 수 있게 해줍니다.

include_type_name=true를 인덱스 생성, 템플릿, 매핑 API로 전달

무형식 API로의 이행은 요청 본문이 형식을 필요로 하는 API가 이제 다른 형식을 예상하게 된다는 뜻입니다.

  • 인덱스 생성
  • 매핑 넣기
  • 템플릿 넣기

응답 시 형식을 반환하는 다른 API는 다른 응답 포맷을 갖게 됩니다.

  • 인덱스 가져오기
  • 매핑 가져오기
  • 필드 매핑 가져오기
  • 템플릿 가져오기

이러한 변경으로 인해 지장을 받지 않으려면, 애플리케이션이 include_type_name=true를 이러한 API 호출에 전달하도록 해야 합니다. 이것은 6.x에서는 no-op이며, 6.x에서 그렇게 했던 것처럼 7.x가 이러한 API를 동작시키도록 알려줍니다. 예를 들어, 다음은 이 매개변수를 이용하는 인덱스 생성 호출입니다. 6.8과 7.x에서도 동일한 방식으로 작동합니다. 

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"
        }
      }
    }
  }
}

업그레이드 후

권장되는 업그레이드 전 단계를 따랐다면, 모든 것은 잘 작동해야 합니다. 그러나, 이 단계에서 여전히 형식을 허용하는 API를 사용하고 있다면, 이것은 사용 중단 경고를 트리거합니다. 이 경고를 제거하려면, 무형식 API로 이행해야 합니다.

인덱스 생성, 템플릿과 매핑 API의 경우, URL 매개변수에서 include_type_name=true를 제거하고, 요청 본문이나 응답 포맷에 대한 예상을 변경해야 합니다. 여기에 더 이상 형식이 포함되지 않기 때문입니다. 일반적으로, 요청 본문이나 응답에 매핑이 포함되면, 다음과 같이 보이는 섹션을 갖습니다. 

{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}

이것이 더 이상 형식 이름을 포함하지 않도록 업데이트되어야 하며, 이제 다음과 같이 보이게 됩니다. 

{
  "properties": ...
}

인덱스, GET, 또는 업데이트 API 같은 다른 API의 경우, URL의 형식 이름을 _doc으로 바꿔야 합니다. 이것은 인덱스 형식의 이름과 상관없이 작동하게 됩니다. 예를 들어, 형식 이름이 my_type인 인덱스에 대해 인덱스 호출을 수행하기 위해 사용한 경우, 인덱스 호출은 다음과 같이 보였습니다. 

PUT index/my_type/1
{
  "@timestamp": "2019-02-20"
}

이것은 다음과 같이 바뀌어야 합니다. 

PUT index/_doc/1
{
  "@timestamp": "2019-02-20"
}

자세히 보기

형식 제거와 무형식 API로의 마이그레이션 방법에 대해 더 자세히 알고 싶으시면, 형식 제거 설명서를 참조하실 것을 권해 드립니다. 이 설명서에서는 이러한 변경의 의미와 변경 준비 방법에 대해 훨씬 더 상세하게 살펴봅니다.

7.0.0을 다운로드하셔서, 이 새로운 무형식 API를 사용해 보시고, 어떻게 생각하시는지 토론 게시판을 통해 알려주세요.