ZzangHo`s History

mmap count 기본적으로 자바 기반의 어플리케이션은 가상머신 위에서 돌아가도록 설계가 되어잇으며 JVM을 통해 할당받은 힙 메모리만 사용할 수 있다. 하지만 루씬의 경우 대용량 세그먼트를 생성하고 관리하기 위해 많은 리소스를 필요하다. 루씬은 내부적으로 자바에서 제공하는 NIO 기술을 활용한다고 한다. 이를 통해 운영체제 커널에서 제공하는 mmap 시스템콜을 직접 호출 할 수 있다. 이로 인해 커널 레벨의 파일 시스템 캐시를 사용할 수 있다. vm.max_map_count는 운영체제가 응용프로그램이 생성할 수 있는 최대 mmap 파일의 수를 지정한다. 엘라스틱서치는 파일시스템 캐시를 적극 활용하기때문에 이 값을 가능한 크게 설정해주어야 한다. swap memory ES는 메모리에 많은양의 데이터를 ..

현재 우리팀에서 사용하는 검색엔진으로 아래 두가지를 사용하고 있다. Solr(Legacy) ElasticSearch 두 가지의 차이점에 대해 간략히 정리해보려고 한다. Solr 사이즈가 큰 데이터 검색에 용이(문서 검색에 적합). ElasticSearch 사이즈가 작은 데이터에 대한 속성검색/연관검색/실시간 검색에 용이하며 상품 검색으로 많이 사용(커머스에 적합) 정리 이름 Solr ElasticSearch 개발사 Apache Software Foundation ElasticSearch 노드 컨트롤 주체 Apache Zookeeper Master Node 샤드 변경 방식 별도의 노드 분할 처리 필요(서버 재기동 필요) 자동 노드 분할(서버 재기동 불필요) 색인업데이트 방식 전체 데이터 캐시로 저장 변경 ..

정의 엘라스틱 서치 및 검색엔진을 사용하기 위해서는 데이터 색인이 먼저 되어야 한다. 프로젝트를 진행하면서 알게 된 색인에 영향을 주는 항목에 대해 정리를 해보고자 한다. 인덱싱 성능 최적화 Refresh_interval 해당 옵션을 사용하게 되면 색인 성능이 올라간다. 그 이유는 엘라스틱서치는 기본적으로 준 실시간(Near Real-Time)으로 1초에 한번씩 데이터를 갱신하여 제공하고 있다. 이 말은 1초에 한번씩 세그먼트 파일에 데이터를 쓴다는 이야기이다. 1초에 한번씩 작은단위로 세그먼트에 계속 데이터를 Write를 하다 보니 전체 색인과 같은 대량의 작업에서는 refresh_interval을 -1로 아에 옵션을 끄던지 아니면 60s나 큰 주기로 한번씩 refresh를 해주는 것이 대량의 색인 작..

이번에는 ElasticSearch를 운영하면서 한번씩 고민해보는 색인, 검색 노드를 나누는 방법에 대해 알아 보도록 한다. 패스트 캠퍼스의 강의를 참고하여 만들어본다. 색인, 검색 노드를 나누는 이유는? 색인과 검색 노드를 따로 나누는 이유는 아마 대부분 검색 서비스에 영향을 주지 않기 위한 안전장치라고 보면 될 것 같다. 색인 노드에서 정상적으로 색인 된 인덱스를 검색 노드로 옮겨주기만하면 되기 때문에 검색 노드로 넘어온 샤드들은 전부다 정상이라고 볼 수 있다. (그렇다고 색인, 검색 노드를 따로 구분하지 않고 사용해도 아직까지는 큰 이슈는 보지 못하였다.) 구성 마스터 노드 1 색인 노드 2 검색 노드 2 위와 같이 구성하여 로컬에서 테스트를 해볼 예정이다. 1. 마스터 노드 cluster.name:..

앞에 Full-cluster Restart에 이어서 Rolling Restart방식도 알아보자. 먼저 순서의 경우 앞의 Full-cluster Restart와 동일하다. 다만 차이점은 Full-Cluster의 경우 전체 노드를 Shutdown하고 StartUp을 하지만 Rolling Restart의 경우 노드 한대씩 작업을 하는 것이다. 그리고 가급적이면 수행중인 인덱싱(색인) 작업은 중지 하고 작업하는게 안전하다. 1. 샤드 할당을 비활성화 한다.(Health = green) PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } } 2. 인덱싱을 중지하고 플러시를 수행합니다.(Health = g..

이번에 plugin반영 작업이 있어 운영 중인 ElasticSearch 재기동을 해야 하는 일이 생겼다. 때마침 정기점검이 있어 새벽에 작업이 있던 나와 부장님이 같이 작업을 하기로 하였다. 개발할때는 맘대로 재기동을 하였지만 이제는 운영이라 신중히 장애가 생기지 않도록 소스 반영 및 노드들을 재기동을 해야 했다. 먼저 공식 홈페이지에 나와 있는 방법으로는 아래 2가지가 있다. 1. Full-Cluster Restart 2. Rolling Restart 2가지의 차이 점은 서비스 중단이 되는냐 아니냐가 큰 차이점이라고 보면 될 것 같다. 1번 Full-Cluster Restart의 경우 전체 노드를 down시킨 뒤 작업할거를 하고 전체 노드를 다시 up시키는 형태라 중간에 Down Time이 발생한다. ..

전 시간에 Delete API를 이용하여 ElasticSearch의 Index의 Document를 삭제하는 방법을 알아보았다. 그럼 삭제를 하게 되면 Index의 데이터는 바로 사라질까? 답은 No이다 ElasticSearch에서 모든 문서는 삭제 여부를 표시하는 비트 배열이 내부적으로 존재한다. 삭제 요청이 들어오면 삭제 될 대상 데이터의 비트 배열을 찾아 삭제 여부(flag) 표시를 한다. 그럼 삭제를 하지 않으면 계속 데이터가 쌓이게 되고.....디스크가 Full이 날 수도 있겠는데? 라고 의문이 들수도 있겠지만 걱정하지 않아도 된다. 백그라운드에서 주기적으로 Merge작업이 일어나면서 쪼개진 세그먼트들을 합칠 때 삭제가 된다. 그렇기 때문에 삭제를 해도 Merge작업이 일어나기 전까지는 데이터는 ..

ElasticSearch Index에 Delete API를 날려 Document를 삭제를 해보자. 간단하게 Document를 등록한 뒤 삭제를 해보겠다. Index 생성 먼저 인덱스를 하나 생성한다. 위와 같이 키바나에서 작성한 뒤 실행을 하면 아래와 같이 정상적으로 인덱스가 생성이 된다. 로컬의 경우 싱글 노드로 띄웠기 때문에 PS는 1로 셋팅하고 RS는 0으로 셋팅한다. 그리고 mappings에 num이라는 필드 하나를 추가로 생성해 보자. Document 등록 이제 Document를 아래와 같이 3개 정도 등록해 보자 조회를 해보면 아래와 같이 등록한 Document 3개가 조회 된다. 자 그럼 이제 Document를 삭제 해보자 Document 삭제 Document를 삭제하려면 아래와 같이 작성하..

Health란? ElasticSearch의 Health라는 것은 현재 ElasticSearch 클러스터의 상태를 말한다. Health 상태 설명 Health Status에 대해 아래 3가지가 있으며 각각 상태에 대한 설명은 아래와 같다. Red 일부 혹은 모든 인덱스의 Primary와 Replica 샤드가 Unassigned 상태로 일부 혹은 모든 인덱스에 쓰기/읽기가 정상적으로 동작하지 않으며 데이터 유실이 발생할 수 있다. Yellow 일부 혹은 모든 인덱스의 Primary 샤드말고 Replica 샤드가 Unassigned 상태로 Primary 샤드는 정상적이므로 쓰기/읽기가 정상적으로 동작한다. Green 모든 샤드가 정상적으로 동작하고 있는 상태로 모든 인덱스에 쓰기/읽기가 정상적으로 동작 참고자..

로컬에서 테스트를 해보기 위해 ElasticSearch 1대를 띄워서 색인을 진행해 보았다. 그런데 다음과 같이 Index들의 Health 상태가 다 Yellow가 된 것이 아닌가? 이유는? 이유는 생각보다 간단하다. 바로 Primaries와 Replicas가 모두 1이여서 발생한 현상이다. 무슨 소리? ES의 경우 Primary Shard와 Replica Shard가 같은 노드에 존재를 할 수가 없다. 그로 인해 Replica를 할당하지 못해 Replica가 Unassigned 상태가 되어 Health 상태가 Yellow로 된 것이다. 왜 같은 노드에 존재 하면 안 될까? 그 이유는 바로 Replica Shard의 경우 해당 노드에 장애가 생겨 Primary Shard가 정상적으로 작동하지 못할 때 R..