기초부터 다지는 엘라스틱서치 운영 (3 ~ 4장) / 모니터링 및 기본개념

기초부터 다지는 엘라스틱서치 운영 (1 ~ 2장) / 훑어보기 및 기본동작

3장. ElasticSearch 모니터링 & 4장. ElasticSearch 기본 개념

3.1 Head를 이용해서 모니터링 하기

• Head는 클러스터의 상태를 한눈에 살펴볼 수 있는 유용한 모니터링 도구 중 하나이다.
• 샤드 배치 정보를 시각적으로 확인할 수 있다는 것이다.
• Head를 통해 클러스터의 노드에 접근하려면 클러스터에서도 접근 허용을 위한 설정 작업이 필요하다. elsticsearch.yaml 파일에 CORS 허용을 해주어야 한다.

http.cors.enabled: true
http.cors.allow-origin: "*"

• 화면 UI
  • [Overview] 메인에서는 클러스터를 구성하는 노드들의 이름과 인덱스 이름, 인덱스를 구성하는 샤드와 인덱스에 저장된 문서의 건수를 살펴 볼 수 있다.
  • 또한 노드와 인덱스에 [Info], [Action] 버튼을 두어 기본정보와 간단한 동작들을 수행할 수 있도록 했다.
    • [Info] → [Cluster Node Info]를 클릭하면 해당 노드의 호스트명과 아이피, 그리고 여러 가지 설정을 확인할 수 있다.
    • [Info] → [Node Stats]를 클릭하면 노드의 기본 정보와 클러스터에서 수행된 동작들의 통계 정보를 확인 할 수 있다.
      • 하지만 이 값은 stats API를 통해서 확인할 수 있는 값을 그냥 보여주고 있는 것이어서 클러스터가 어떤 상태인지, 어느 정도의 성능을 보여주고 있는지 확인하기 어렵다.
  • [Indicies] 탭은 클러스터 내에 생성한 인덱스의 이름과 크기, 문서의 개수를 요약하여 보여준다.
  • [Browser]탭은 생성한 인덱스와 타입, 문서의 필드에 해당하는 내용들을 확인할 수 있다.

3.2 프로메테우스를 활용한 클러스터 모니터링

• 프로메테우스는 데이터를 시간의 흐름대로 저장할 수 있는 시계열 데이터베이스의 일종이며, 수집된 데이터를 바탕으로 임계치를 설정하고 경고 메시지를 받을 수 있는 오픈소스 모니터링 시스템이다.
• 프로메테우스는 각종 메트릭을 저장하는 TSDB(Time Service Data Base)의 역할을 하는 Prometheus Server가 중앙에 있다.

결론

1. Head 모니터링은 클러스터의 전반적인 동작 상태를 확인하기에 용이하지만 성능 지표등의 자세한 정보는 확인하기 어렵다.
2. 프로메테우스 모니터링은 다양한 클러스터를 운영하고 있을 때 구축하기 수월하지만, 확인할 수 잇는 정보량이 X-Pack 모니터링에 비해 상대적으로 적다.
3. X-Pack 모니터링은 모니터링 시스템 중 가장 많은 정보를 확인할 수 있지만, 6.3 이전 버전의 경우 Basic 라이선스를 해마다 갱신해야 하며, 클러스터의 규모가 클수록 모니터링 데이터를 기록하기 위한 인덱스의 색인이 필요하기 때문에 색인 성능에 영향을 줄 수 있다.

 

---

클러스터와 노드의 개념

• ElasticSearch 클러스터 역시 여러 개의 ElasticSearch 프로세스들을 논리적으로 결합하여 하나의 ElasticSearch 프로세스 처럼 사용할 수 있게 해준다. 그리고 이때 클러스터를 구성하는 하나하나의 ElasticSearch 프로세스를 노드라고 부른다.
• 클러스터 내에서 메타데이터를 관리하는 마스터 노드는 한 대라는 것이다. 이 부분이 헷갈릴 수 잇는데 마스터 노드는 마스터 역할이 가능한 노드와 실제 마스터 역할을 하는 노드 이렇게 두 가지로 구분된다고 이해하면 된다. 만약 클러스터를 구축할 때 3대의 마스터 역할 노드를 구성한다면 그중 한 대만 실제 메타데이터를 관리하는 역할을 수행하고, 나머지 두 대는 현재 동작하고 있는 마스터 노드에 장애가 발생했을 때 새로운 마스터가 될 수 있는 마스터 후보 노드가 된다. 마스터 후보 노드들은 마스터 노드들로부터 지속적으로 클러스터 운영에 필요한 데이터를 전달받기 때문에 항상 같은 메타 데이터를 유지하고 있다. 그래서 마스터 노드에 장애 발생해서 새로운 마스터 노드가 선출되어도 중단 없이 서비스를 이어갈 수 있다.

인덱스와 타입

• 인덱스는 사용자의 데이터가 저장되는 논리적인 공간을 의미하며 타입은 인덱스 안의 데이터를 유형별로 논리적으로 나눠 놓은 공간을 의미한다.
• 인덱스는 RDBMS에서 ‘데이터베이스’를 의미하며, 타입은 ‘테이블’을 의미한다.
• RDBMS에서는 데이터베이스안에 여러 개의 테이블을 가질 수 있는 것과 달리 ElasticSearch는 6.x버전 이후로는 하나의 인덱스에 하나의 타입만 가질 수 있다.
• ElasticSearch 6.x 이후로는 단일 타입만을 허용하기 때문에 큰 이슈가 없다면 _doc을 타입명으로 사용하게 된다. 따라서 nginx 웹 서버에서 발생하는 접속 로그는 nginx-access-log-YYYY.MM.DD 형태의 인덱스 _doc 타입명으로 저장된다.
  • 멀티 타입을 허용하지 않게 된 이유 중 하나는 인덱스에 존재하는 서로 다른 타입에서 동한 이름의 JSON 문서 필드를 만들 수 있어서 의도치 않은 검색 결과가 나타나는 문제가 발생했기 때문이다.

샤드와 세그먼트

• 샤드는 인덱스에 색인되는 문서들이 저장되는 논리적인 공간을 의미하며, 세그먼트는 샤드의 데이터들을 가지고 있는 물리적인 파일을 의미한다.
• 하나의 인덱스는 다수의 샤드로 구성되고 하나의 샤드는 다수의 세그먼트로 구성된다.
• 프라이머리 샤드는 최초 인덱스를 생성할 때 개수를 결정하는데, 이떄 결정한 프라이머 샤드의 개수는 이후에 변경할 수 없다. 따라서 인덱스를 생성할 때 몇 개의 프라이머리 샤드를 만들 것인지 신중하게 결정해야 한다.
• 세그먼트는 불변의 특성을 갖는다. 즉, 기존에 기록한 데이터를 업데이트하지 않는다는 뜻이다. 기존 데이터를 업데이트하거나 삭제하는 과정에서 기존 데이터는 불용처리만 하고 새롭게 쓴다. 이 특성으로 데이터의 일관성을 유지할 수 있지만, 불변의 특성을 유지하기 위해 여러 개의 세그먼트로 사용자의 문서를 색인하므로 시간이 지나면 작은 크기의 세그먼트가 점점 늘어나고, 사용자가 문서를 검색할 때마다 많은 수의 세그먼트들이 응답해야 한다는 단점이 생긴다.

프라이머리 샤드와 레플리카 샤드

• 프라이머리 샤드는 처음에 인덱스를 생성할 떄 설정하면 변경할 수 없지만, 복제본인 레플리카 샤드는 운영 중에도 샤드 개수를 변경할 수 있다.
• 레플리카 샤드가 추가되면 검색 성능도 확장 됨.

매핑

매핑은 RDBMS와 비교하자면 스키마와 유사하다. ElasticSearch에 저장될 JSON 문서들이 어떤 키와 어떤 형태의 값을 가지고 있는지 정의한 것이다.

마치며

• 샤드는 하나 이상의 세그먼트들로 구성된다. 백그라운드에서 세그먼트의 병합 작업이 진행되며 이를 통해 작은 크기의 세그먼트들이 큰 크기의 세그먼트로 합쳐진다.