서론
제가 처음 Elasticsearch( ES )를 공부할 때 어려웠던 것은 용어에 대한 낯섦, 방대한 API와 ES 아키텍쳐였습니다.
용어가 낯선 것이야 익숙해질텐데, 방대한 API 속에서 뭐부터 알아야 할지, 검색으로 아키텍쳐에 대한 설명은 찾을 수 있지만 튜닝을 어떻게 해야 할지 감이 안왔었죠.
그런데 사실 데이터베이스 CRUD를 처음 배울 때 Mysql 아키텍쳐가 어떻고, indexing, sharding, master-slave 등 이런 모든 것들을 이해할 필요가 없습니다. 나중에 알아두면 좋지만요.
처음엔 그저 SELECT, INSERT, UPDATE, DELETE 쿼리를 따라해서 익숙해지면 기본은 할 수 있습니다.
그러다가 join이나 subquery 등의 응용 개념들이 쌓이는거죠.
이런 관점에 맞춰 ES에서 데이터를 다루는 방법에 대해 알아보려고 합니다.
기본을 통해 용어들과 API 사용방법에 익숙해지면 그 후는 검색으로 레퍼런스를 찾아보면 되니까요.
예제들은 공식 문서를 참고했고, API를 다루기에 앞서 아래의 글들을 꼭 참고하시길 바랍니다.
용어와 기본 아키텍쳐를 모르면 이해가 어려울 수 있습니다.
1. ES API 호출 방법
ES는 Restful API로 호출을 한다는 것이 특징입니다.
그래서 API를 호출할 때 리눅스에서 curl 요청을 해도 되고, Postman 같은 툴로 HTTP 요청을 해도 ES API를 사용할 수 있습니다.
저는 앞으로 curl 요청을 통해 API를 조회할 것입니다.
현재 curl이 뭔지 몰라도 하다보면 자연스럽게 알게 되는데요, 그래도 궁금하시다면 여기를 참고하면 좋을 것 같네요.
2. Cluster health 체크 - 클러스터 정보
Cluster란 ES에서 가장 큰 시스템 단위를 말하며, node들의 집합입니다.
클러스터는 아키텍쳐를 구축하는게 중요한 부분이라 생각되어 클러스터 구성에 대한 그림을 그릴 수 있을 정도로 간단하게만 짚고 넘어가겠습니다.
ES를 설치하고 나면 Cluster와 node는 1개씩 존재하는데, 그 정보들은 아래의 명령어를 통해 확인할 수 있습니다.
# curl -XGET http://localhost:9200/_cluster/health?pretty=true
3. Cluster status
ES를 설치하고 클러스터 상태를 보니, yellow 상태입니다.
yellow 상태는 모든 데이터의 읽기/쓰기가 가능한 상태이지만 일부 replica shard가 아직 배정되지 않은 상태를 말합니다.
즉, 정상 작동중이지만 replica shard가 없기 때문에 검색 성능에 영향이 있을 수 있습니다.
status에 대한 자세한 설명은 여기를 참고하시면 좋을 것 같습니다.
현재 설치된 ES에서 클러스터의 상태가 yellow인 이유를 알아보도록 하겠습니다.
먼저 아래의 명령어로 index와 shard의 정보들을 조회합니다. ( cat API - indices / shards )
# curl -XGET localhost:9200/_cat/indices?v
# curl -XGET localhost:9200/_cat/shards?v
보시면 victolee index에 primary 당 replica가 1개 존재하는데, replica가 전부 unassigned입니다.
replica는 primary와 같은 노드상에 있을 수 없습니다.
즉, 현재는 하나의 노드가 실행 중이므로 replica를 배정할 수 없게 됩니다.
나중에 다른 노드가 클러스터에 포함되면 replica를 배정할 수 있고, 배정되면 green status로 바뀝니다.
지금은 replica를 갖지 않도록 클러스터 setting을 수정해서 green 상태로 바꿔보도록 하겠습니다.
# curl -XPUT 'localhost:9200/_settings?pretty' -d '{"index":{"number_of_replicas": 0}}' -H 'Content-Type: application/json'
그리고나서 다시 클러스터 상태를 확인해보면,
# curl -XGET http://localhost:9200/_cluster/health?pretty=true
다음과 같이 상태가 green으로 바뀌는 것을 확인할 수 있습니다.
그런데 항상 이렇게 처리하는 것은 좋지 않습니다.
지금 같은 경우는 노드가 master node 1개 밖에 없습니다.
하지만 data node가 추가 되어 클러스터를 구성해야 한다면, replica shard가 노드마다 할당되는 것이 고가용성에 있어서 좋습니다.
이런 상황에서 지금과 같이 replica를 0으로 셋팅한다면 안정성이 떨어지는 아키텍쳐가 되겠죠.
4. Cluster 구성 이해하기
고작 클러스터의 status만 바꾸는 작업이었는데, node와 shard의 개념들이 나오고 있습니다.
- 클러스터는 여러 노드의 집합으로 구성되며, 설치시 master node만 존재
- primary shard는 데이터를 저장할 때 나눠진 파티션을 말하며, 설치시 5개가 존재
- replica shard는 고가용성을 위해 존재하는 primary shard의 복제본을 말하며, 설치시 1개가 존재
- primary와 replica는 같은 노드에 존재할 수 없음
이를 바탕으로 아래의 아키텍쳐를 이해할 수 있습니다.
이상으로 클러스터에 대해 알아보았습니다.
실험적으로 여러 노드를 생성해서 클러스터를 구성하여 상태를 green으로 바꾸고 싶었지만, 아쉽게도 실패했습니다.
조사한 바로는 노드를 셋팅할 수 있는 elasticsearch.yml 파일은 서버당 하나씩 존재해야 한다는데, 한 서버에서 여러 노드를 구성하기 위한 여러 시도를 해봤는데 잘 안되더라구요.
다행히도 AWS를 이용해서 클러스터를 구성해보는 좋은 글이 있으니 클러스터를 구성해보고 싶다면 참고해주세요. ( 링크 )
다음 글에서는 index 관련 CRUD 작업을 해보도록 하겠습니다.