Elasticsearch 사용

VPC 환경에서 이용 가능합니다.

Elasticsearch는 비정형 데이터를 JSON 구조로 저장하여 검색에 특화된 데이터 저장소입니다. REST API를 사용해 질의할 수 있습니다.

Elasticsearch 앱 상세 정보 확인

앱 생성이 완료되면 상세 정보를 확인할 수 있습니다. 앱 상세 정보의 Status가 Stable이면 앱이 정상적으로 구동된 것을 의미합니다.
앱 상세 정보를 확인하는 방법은 다음과 같습니다.

1. 네이버 클라우드 플랫폼의 콘솔에서 Services > Big Data & Analytics > Data Forest 메뉴를 차례대로 클릭해 주십시오.
2. 좌측의 Data Forest > Apps 메뉴를 클릭해 주십시오.
3. 앱을 소유한 계정을 선택해 주십시오.
4. 상세 정보를 확인할 앱을 클릭해 주십시오.
5. 앱 상세 정보를 확인해 주십시오.
   
   • Quick links
     • AppMaster: 컨테이너 로그를 확인할 수 있는 URL. 앱 생성 시 모든 앱은 YARN 큐에 제출되며, YARN은 각 앱의 상세 정보를 확인할 수 있는 Web UI 제공
     • elasticsearch.hosts: Elasticsearch REST API 주소(외부 네트워크)
     • shell-es-coord-0: 코디네이팅 노드의 웹 셸(Web shell) URL
     • supervisor-es-ingest-0: 인제스트 노드 프로세스를 관리할 수 있는 supervisor URL. 이 노드는 기본값 0개로 생성되므로 따로 지정하지 않을 경우 접속 불가
     • shell-es-master-0: 마스터 노드의 웹 셸 URL
     • supervisor-es-coord-0: 코디네이팅 노드 프로세스를 관리할 수 있는 supervisor URL
     • supervisor-es-data-0: 데이터 노드 프로세스를 관리할 수 있는 supervisor URL
     • shell-es-data-0: 데이터 노드의 웹 셸 URL
     • shell-es-ingest-0: 인제스트 노드의 웹 셸 URL. 이 노드는 기본값 0개로 생성되므로 따로 지정하지 않을 경우 접속 불가
     • supervisor-es-master-0: 마스터 노드 프로세스를 관리할 수 있는 supervisor URL
   • Connection String
     • elasticsearch.hosts.inside-of-cluster: Elasticsearch REST API 주소(내부 네트워크)
   • 컴포넌트: 기본 지정된 값이 권장 리소스입니다.
     • es-master: es 서버에서 마스터 역할을 수행하는 컴포넌트
     • es-data: es 서버에서 데이터를 저장하는 역할을 수행하는 컴포넌트
     • es-ingest: es 서버에서 인제스트 파이프라인 역할을 수행하는 컴포넌트
     • es-coord: es 서버에서 코디네이터 역할을 수행하는 컴포넌트

REST API 주소 목록

Elasticsearch의 HTTP REST API 주소는 두 가지입니다. 상황에 따라 적절한 API 주소를 사용합니다.

• elasticsearch.hosts: Data Forest 외부 네트워크에서 Elasticsearch에 접속 시 사용합니다.
• elasticsearch.hosts.inside-of-cluster: Data Forest 앱에서 Elasticsearch에 접속 시 사용합니다. 예) Kibana에서 Elasticsearch 연동 시

Elasticsearch 앱 컨테이너 개수 변경

컨테이너 개수를 조절하는 방법은 다음과 같습니다.

1. 네이버 클라우드 플랫폼의 콘솔에서 Services > Big Data & Analytics > Data Forest 메뉴를 차례대로 클릭해 주십시오.
2. 좌측의 Data Forest > Apps 메뉴를 클릭해 주십시오.
3. 앱을 소유한 계정을 선택해 주십시오.
4. 상세 정보를 확인할 앱을 클릭하고 [Flex] 버튼을 클릭해 주십시오.
5. Flex 변경 창이 나타나면 컨테이너 개수를 수정하고 [수정] 버튼을 클릭해 주십시오.
   

Elasticsearch 앱 사용 시 주의 사항

노드 장애

Elasticsearch 앱은 하나의 물리적인 노드에 하나의 데이터 노드만 구동합니다. 따라서 replica=1 인 경우, 한 개의 데이터 노드에 장애가 발생하더라도 데이터가 유실되지 않습니다(replica=1 는 원본 1 + replica 1 라는 의미). es-data는 최소 2대가 필요합니다.

Out of Memory

Elasticsearch 앱 생성 시 필요한 리소스(resource/memory)를 지정하게 되는데, 지정된 메모리보다 많은 메모리를 사용할 경우에는 OS의 OOM Killer가 Elasticsearch 프로세스를 종료시킵니다. supervisor로 Elasticsearch 프로세스를 관리하고 있기 때문에 OOM으로 프로세스가 종료되면 supervisor가 Elasticsearch 프로세스를 다시 실행시키지만, OOM이 발생했다면 다시 OOM이 발생할 가능성이 높습니다.
이런 상황이 발생할 경우, Elasticsearch 컨테이너 개수를 늘린 후에 shard를 분할하여 개별 노드의 부하를 감소시키거나 컨테이너의 리소스를 증가시켜야 합니다. 하지만 이미 운영 중인 Elasticsearch 앱 리소스는 변경할 수 없습니다. 리소스를 변경해야 할 경우, 메모리를 증가시킨 Elasticsearch 앱을 다시 생성한 후에 repository-hdfs를 참고하여 HDFS에 백업 후 복구하거나 Reindex from remote 기능을 사용하여 새로운 Elasticsearch 앱으로 인덱스를 이전할 수 있습니다.

Elasticsearch 프로세스가 OOM으로 종료된 후 재시작되었는지를 확인하는 방법은 다음과 같습니다.

• cerebro에서 노드의 uptime 정보를 확인해 주십시오. 다른 노드에 비해 uptime이 짧을 경우 Elasticsearch 프로세스가 재시작되었을 가능성이 높습니다.
• 해당 노드의 supervisord.log를 확인해 주십시오. (로그/설정 확인하기) 로그에 다음과 같은 내용이 있다면 OOM으로 인해 Elasticsearch 프로세스가 재시작되었을 가능성이 높습니다.

  # SIGKILL로 인해 Elasticsearch 프로세스가 종료됨
  2020-04-22 14:44:35,390 INFO exited: elasticsearch (terminated by SIGKILL; not expected)
  
  # supervisor가 Elasticsearch를 다시 실행시킴
  2020-04-22 14:44:36,395 INFO spawned: 'elasticsearch' with pid 508
  2020-04-22 14:44:37,396 INFO success: elasticsearch entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
  

supervisor의 로그는 Elasticsearch 프로세스가 SIGKILL로 종료된 것을 의미하는데 SIGKILL이 발생한 이유는 알 수 없습니다. OOM Killer가 SIGKILL을 사용하고 있기 때문에 OOM Killer에 의해서 종료된 것으로 볼 수 있습니다.

• dmesg 명령으로 OOM의 발생 여부를 확인할 수 있습니다.

  [magnum@ac3m8x2240.bdp ~]$ dmesg
  
  ...
  [13460863.662062] elasticsearch[e invoked oom-killer: gfp_mask=0x50, order=0, oom_score_adj=1000
  [13460863.662066] elasticsearch[e cpuset=aceca4b30ed9b4af3b3fab0ada711021f05dfecf68ebfdcfcdaa54a0ab516842 mems_allowed=0-1
  [13460863.662069] CPU: 14 PID: 27043 Comm: elasticsearch[e Not tainted 3.10.0-862.14.4.el7.x86_64 #1
  [13460863.662071] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 09/12/2019
  [13460863.662072] Call Trace:
  [13460863.662080]  [<ffffffffb7f13754>] dump_stack+0x19/0x1b
  [13460863.662085]  [<ffffffffb7f0e91f>] dump_header+0x90/0x229
  [13460863.662091]  [<ffffffffb799a7e6>] ? find_lock_task_mm+0x56/0xc0
  [13460863.662096]  [<ffffffffb7a0f678>] ? try_get_mem_cgroup_from_mm+0x28/0x60
  [13460863.662098]  [<ffffffffb799ac94>] oom_kill_process+0x254/0x3d0
  [13460863.662101]  [<ffffffffb7a13486>] mem_cgroup_oom_synchronize+0x546/0x570
  [13460863.662103]  [<ffffffffb7a12900>] ? mem_cgroup_charge_common+0xc0/0xc0
  [13460863.662105]  [<ffffffffb799b524>] pagefault_out_of_memory+0x14/0x90
  [13460863.662108]  [<ffffffffb7f0cac1>] mm_fault_error+0x6a/0x157
  [13460863.662112]  [<ffffffffb7f20846>] __do_page_fault+0x496/0x4f0
  [13460863.662113]  [<ffffffffb7f208d5>] do_page_fault+0x35/0x90
  [13460863.662115]  [<ffffffffb7f1c758>] page_fault+0x28/0x30
  [13460863.662118] Task in /yarn/container_e62_1584425817444_92362_01_000002/aceca4b30ed9b4af3b3fab0ada711021f05dfecf68ebfdcfcdaa54a0ab516842 killed as a result of limit of /yarn/container_e62_1584425817444_92362_01_000002/aceca4b30ed9b4af3b3fab0ada711021f05dfecf68ebfdcfcdaa54a0ab516842
  [13460863.662121] memory: usage 2097152kB, limit 2097152kB, failcnt 1448215
  [13460863.662122] memory+swap: usage 2097152kB, limit 4194304kB, failcnt 0
  [13460863.662123] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
  [13460863.662124] Memory cgroup stats for /yarn/container_e62_1584425817444_92362_01_000002/aceca4b30ed9b4af3b3fab0ada711021f05dfecf68ebfdcfcdaa54a0ab516842: cache:332KB rss:2096820KB rss_huge:0KB mapped_file:320KB swap:0KB inactive_anon:546160KB active_anon:1550660KB inactive_file:8KB active_file:0KB unevictable:0KB
  [13460863.662138] [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
  [13460863.662272] [25374] 20033 25374     3151       67      12        0             0 bash
  [13460863.662274] [25813] 20033 25813    29910     2391      62        0             0 supervisord
  [13460863.662276] [25818] 20033 25818   178152     1221      20        0             0 gotty
  [13460863.662279] [26644] 20033 26644     3184      108      12        0             0 bash
  [13460863.662282] [26703] 20033 26703   954936   519887    1130        0          1000 java
  [13460863.662285] Memory cgroup out of memory: Kill process 27043 (elasticsearch[e) score 1993 or sacrifice child
  [13460863.663561] Killed process 26703 (java) total-vm:3819744kB, anon-rss:2079548kB, file-rss:0kB, shmem-rss:0kB
  

데이터 보존

Elasticsearch 앱 데이터는 /home1/{USER} 하위에 저장되며, 사용자가 앱을 중지하거나 다른 문제로 인해 앱이 종료되더라도 데이터가 삭제되지 않습니다.

다음과 같은 특정 상황에서는 데이터가 유실될 수 있습니다.
중지된 앱을 사용자가 제거(destroy)하는 경우에는 데이터가 삭제됩니다. 중지된 앱을 다시 시작할 경우에는 기존 데이터가 존재했던 노드에 구동되고 데이터가 복구됩니다. 하지만 기존에 구동되었던 노드의 리소스를 다른 작업이 점유하고 있거나 노드가 장애로 제외되었을 경우 yarn.service.placement-history.timeout.ms (기본값: 1시간) 이후에는 기존 노드에서 구동되지 않고 다른 노드에 구동됩니다. 그러므로 yarn.service.placement-history.timeout.ms에서 설정된 시간 동안 구동되지 않은 Elasticsearch 앱 데이터는 유실될 수 있습니다. 중요한 데이터인 경우에는 repository-hdfs를 참고해서 HDFS에 백업해 주십시오.