안녕하세요, 대용량 데이터 검색엔진 구축을 위해 Elasticsearch를 도입했습니다. 1. 개발환경 및 Spec 설명On-premise Kubernetes 환경에 Helm 배포를 통해 Master, Coordinating, Data Node 각각 4, 4, 10대로 Elasticsearch 클러스터를 구성했습니다.(HA 구성을 위해 Data Node는 모두 다른 Kubernetes Node에 배포되며, statefulSet을 통한 Rolling Update 방식입니다.)예상되는 클러스터 전체 Data Usage는 50TB 수준이고, primary shard와 replica shard의 개수는 각각 10과 1로 둘 예정입니다. 하나의 shard 용량은 10~20GB 수준으로 유지할 예정입니다. 현재는 초기 적재를 위해 replica shard 개수를 0으로 설정한 상황입니다.)pod container의 limit resource는 8core, 64Gi이며, ES_JAVA_OPTS 값으로는 -Xms30g -Xmx30g 옵션을 통해 Elasticsearch의 Heap Memory로는 30GB를 할당했습니다. 32Bit 포인터 관리 방식에서 object 그 자체가 아닌 object의 offset을 참조하는 Compressed OOP 사용을 위해, Elasticsearch의 Heap Size는 32GB를 권장하고 있습니다. 여기에 시작 주소를 0으로 두는 Zero-based 까지 고려하여 보수적으로 30GB를 사용했습니다.위와는 독립적인 권장 사항인 'JVM의 50%을 ES에 할당하라' 조건까지 고려하여 JVM Heapsize를 64Gi 로 두었습니다. 2. issue데이터 색인(bulk가 아닌 일반적인 PUT API) 중, kibana를 비롯하여 Elasticsearch 클러스터 전체에 503 에러가 발생했고 쿠버네티스 클러스터에 배포된 pod(Master, Coordinating Node 전부, 그리고 Data Node는 2대를 제외한 나머지 8개)가 restart 없이 죽었습니다. (원인은 CircuitBreaker입니다.)NAME READY STATUS RESTARTS AGE edms-p01-srep01-coordinating-0 0/1 Running 0 37h edms-p01-srep01-coordinating-1 0/1 Running 0 37h edms-p01-srep01-coordinating-2 0/1 Running 0 37h edms-p01-srep01-coordinating-3 0/1 Running 0 37h edms-p01-srep01-data-0 0/1 Running 0 37h edms-p01-srep01-data-1 0/1 Running 0 37h edms-p01-srep01-data-2 1/1 Running 0 37h edms-p01-srep01-data-3 0/1 Running 0 37h edms-p01-srep01-data-4 0/1 Running 0 37h edms-p01-srep01-data-5 0/1 Running 0 37h edms-p01-srep01-data-6 1/1 Running 0 37h edms-p01-srep01-data-7 0/1 Running 0 37h edms-p01-srep01-data-8 0/1 Running 0 26h edms-p01-srep01-data-9 0/1 Running 0 37h edms-p01-srep01-es-exporter-8457b87fb7-wsshd 1/1 Running 0 39h edms-p01-srep01-kb-84dcb6d7f7-gdhd9 0/1 Running 0 39h edms-p01-srep01-master-0 0/1 Running 0 37h edms-p01-srep01-master-1 0/1 Running 0 37h edms-p01-srep01-master-2 0/1 Running 0 37h edms-p01-srep01-master-3 0/1 Running 0 37h  Data Node의 경우 빈번한 Young GC, 그리고 Old GC가 발생했지만 점차 확보하는 Memory 양이 적어지다가 CircuitBreakingException이 발생했습니다.Master와 Coordinating Node는 Old GC 없이 Young GC만으로 heap size가 잘 관리되다가 모든 Data Node 메모리 부하가 심해지니 Pod가 죽었는데, 유추하기로는 처리되지 못한 색인 데이터의 transport가 loop 되다가 Master/Coordinating 메모리에도 영향을 준 것으로 보입니다. CircuitBreakingException이 발생 전의 한 Data Node의 stats은 아래와 같습니다. (GET _nodes/stats) "mem" : { "heap_used_in_bytes" : 28558120848, "heap_used_percent" : 88, "heap_committed_in_bytes" : 32212254720, "heap_max_in_bytes" : 32212254720, "non_heap_used_in_bytes" : 191720344, "non_heap_committed_in_bytes" : 201515008, "pools" : { "young" : { "used_in_bytes" : 771751936, "max_in_bytes" : 0, "peak_used_in_bytes" : 19243466752, "peak_max_in_bytes" : 0 }, "old" : { "used_in_bytes" : 27784679400, "max_in_bytes" : 32212254720, "peak_used_in_bytes" : 32129130920, "peak_max_in_bytes" : 32212254720 }, "survivor" : { "used_in_bytes" : 1689512, "max_in_bytes" : 0, "peak_used_in_bytes" : 1520169584, "peak_max_in_bytes" : 0 } } }, ... "gc" : { "collectors" : { "young" : { "collection_count" : 226, "collection_time_in_millis" : 15603 }, "old" : { "collection_count" : 1, "collection_time_in_millis" : 6322 } } } 3. 의문점Data node 역할을 담당하는 pod가 죽은 것은 그럴 수 있다 쳐도 색인과 관련 없는 Coordinating/Master Node 역할의 pod에까지 영향을 미치는 이유는 무엇인가요?(위의 pod metric을 살펴보아도 OOM과는 전혀 거리가 멀어보이긴 합니다만) Elasticsearch가 분산시스템이지만 위와 같이 Kubernetes 노드에 문제가 없는 상태에서 pod만 죽어버리니 고가용성이 무색해지는군요... 앞서 말씀드린 것처럼 색인 데이터의 transport 내부 동작이 영향을 미쳤을까요?위와 같은 CircuitBreakingException에 대응하는 방법에는 ES_JAVA_OPT의 Heap Memory 용량을 증설하거나, 클러스터 세팅 indices.breaker.total.limit 값은 이미 95%입니다. (indices.breaker.total.use_real_memory가 true 이므로) 이때, 이미 Heap이 30GB라면, Compressed OOP의 조건인 32GB를 넘는 수준의 ES_JAVA_OPTS 설정을 시도하려면 어느 정도로 높게 하는게 좋을지 고견을 여쭙습니다.(Container의 jvm memory 자체에는 큰 제약이 없는 개발환경입니다. 즉, 128GB, 256GB처럼 높은 수준의 resources.limit 설정도 가능합니다.) 

indexing_pressure.memory.limit 이거를 올려주라는데 혹시 일시적으로 어떻게 올리는 건가요?

1. 현상  fishing 검색시 최소단위로 분절되어 "fish", "ing"로 token  검색이 fishing이나 fish, fishing이 우선순위 없이 결과에 노출됨  *현재 검색은 and 조건에 따라 -> must문으로 처리 2. 원인   형태소 분석기를 통해 분절된 후에 동의어처리가 되면서 같은 단어로 인식   3. 확인 사항  **고객요청) keyword("fishing")를 분절하지 않고 검색에 활용   -> 이렇게 하더라도, fish도 결과에 나와야 한다.  ** 개발팀화인) 사용자 입력 값 자체에 score를 높여 검색 상단위 위치   fishing -10   fish -5   ing -5   -> 사용자 사전에 fish / ing 따로 등록필요하고, 모든 단어에 적용해야 하는 수고가 있음  ** 어떻게 검색에 대해 의사소통을 해야하는지, 기본적은 사항

0:42 $ curl -XPOST http://localhost:9200/classes/class/1/ -H'Content-Type: application/json' -d ' {"title" : "Algorithm", "professor" : "John"}'

elasticsearch 7.x 버젼부터는 curl 리퀘스트에서 헤더를 명확히 설정해주어야하고 또 mappign을 생성할 때에는 include_type_name을 true로 설정해주어야한다고 합니다. 이에 대한 에러문구는 아래와 같습니다.   { "error" : { "root_cause" : [ { "type" : "illegal_argument_exception", "reason" : "Types cannot be provided in put mapping requests, unless the include_type_name parameter is set to true." } ], "type" : "illegal_argument_exception", "reason" : "Types cannot be provided in put mapping requests, unless the include_type_name parameter is set to true." }, "status" : 400 }   그래서 저는 mapping을 생성할 때 아래와 같이 커맨드라인을 날렸습니다.   curl -H 'Content-Type:application/json' -XPUT 'http://localhost:9200/classes/class/_mapping?include_type_name=true&pretty' -d @classesRating_mapping.json   그런데 아래와 같은 에러가 다시 발생했습니다.   { "error" : { "root_cause" : [ { "type" : "mapper_parsing_exception", "reason" : "No handler for type [string] declared on field [professor]" } ], "type" : "mapper_parsing_exception", "reason" : "No handler for type [string] declared on field [professor]" }, "status" : 400 }   이에 대해서 원인을 찾아보니 elasticsearch가 mapping 타입 중 string을 삭제하고 text로 변경하여 사용하고있다고 합니다. 관련 정보 링크 : https://stackoverflow.com/questions/47452770/no-handler-for-type-string-declared-on-field-name 그래서 classesRating_mapping.json에서 type이 string으로 되어있는 부분들을 모두 text로 변경한 후 위 커맨드라인을 다시 실행해보니 정상적으로 실행되었습니다. 혹시 이 강의를 보시는 분들 중 elasticsearch 6.x 이상의 버젼을 사용하여 수강하시는 분들은 이 부분들을 참고해보시면 좋을 것 같습니다.

현재 제가 강좌를 시청하고 있는 시간이 2019년 8월이고강의를 찍으신 시간이 2016년정도이니, 그 부분을 명시해서 앞으로 보는 시청자들에게도 자신의 환경에 맞게 알아서 조절하게끔 알려주어야 할 것 같습니다..!!이것 문제인지 모르고 계속 헤맸네요 ㅠㅠ ㅎㅎ

curl -XPOSt http://localhost:9200/classes/class/1/ -d '{"title" : "Algorithm", "professor" : "John"}' 입력 시 www-form-urlencoded is not supported status 406 에러가 발생합니다. 높은 버전에선 -H 'Content-Type: application/json' 을 추가해줘야 할듯합니다.