IT's 잡탕찌개 블로그

이번 포스팅에서는 Elasticsearch에 대해서 알아보자.

Elasticsearch란?
Elasticsearch는 Lucene을 기반으로 개발된 검색엔진으로 다양한 방식의 검색을 할 수 있다.
또한 cluster를 구성할 수 있으며, cluster는 여러개의 node로 구성된다.

elasticsearch에서 중요한 개념은 아래와 같다.
. 색인(index)과 역색인(reverse index)
. data의 집계
.cluster
대충 요약하자면 cluster 환경에서 색인과 역색인을 통해 빠른 검색이 가능하며 data에 대해서 집계정보 까지 활용이 가능하다는 것이라고 이해하면 될 것 같다.

Elastic에서는 각 data를 json 형태로 저장한다.
해당 data들은 Index라는 개념으로 구분되어 저장되는데 여기서 Index는 색인의 개념이라기보다는 RDB의 Table과 유사한 개념이라고 생각하면 된다.
해당 Index들은 저장되는 data에 대한 항목별로 각 type 정보들을 정의할 수 있다.
ELK stack에서 data를 import 할 때 자동으로 설정해서 Index가 생성되긴하지만 해당 type에 대해서는 확인을 하는 것이 좋다.
이유로는 특정 항목의 값이 원래는 실수 범위이지만 import 하는 data가 모두 정수값인 경우 index가 type을 정수로 지정하는 경우가 생길 수 있기 때문이다.
cluster의 경우 elastic이 기본적으로 방대한 양의 data를 저장하고 이를 검색에 활용하기 때문에
가령 하드웨어의 용량을 초과하거나 혹은 너무 많은 용량을 지녀 검색이 느려지는 등의 문제가 발생할 수 있다.
이를 방지하기 위해서는 cluster 환경을 구축하는 것이 좋은데 cluster에서 sharding 과 replica를 구현할 수 있기 때문이다.
shard는 Index를 일종의 조각으로 분해하는 것이다.
Index 생성 시 원하는 갯수로 shard 를 지정할 수 있고 이 shard 자체 역시 온전한 Index의 역할을 한다.
해당 shard들은 data volume을 수평분할 및 확장이 가능해지게 하며 여러 shard에 분산된 만큼 검색 성능을 더 끌어 올릴 수 있다.
이 때 오류가 일어나 해당 shard에 대해서 접근을 못하거나 사라지게 되는 경우를 대비하여 replica shard라는 것 역시 존재한다(이하 replica).
replica를 만들면 원본 shard 혹은 해당 shard를 지닌 node에 문제가 발생하더라도 검색기능에는 문제가 생기지 않는다.
물론 해당 replica는 원본 shard와 다른 node에 존재한다.

실제로 elasticsearch 의 설치에 대해서는 다음 포스트에서 알아보자.

참고 - https://nanbuja.com/entry/Elasticsearch%EB%9E%80-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%A2%85%EB%A5%98-RDBMS%EC%99%80-%EC%B0%A8%EC%9D%B4

ELK stack이란?
ELK stack이란 말은 서버 개발자라면 한번 들어봤을 것이다.
ELK stack이란 Elasticsearch Logstash Kibana를 구축하여 활용하는 환경을 의미한다고 보면 된다.
ELK를 구성하는 것들 (위의 3가지)는 각자 맡은 역할이 다르고 장단점도 존재하지만 이 포스팅에서는 크게 다루지는 않고 간단하게 역할만 짚고 넘어간다.

Elasticsearch
elasticsearch는 검색엔진이다.
JAVA 언어 기반으로 구현되었으며 data의 검색 및 집계에 사용된다.

Logstash
다양한 data source로부터 data를 수집 및 집계, 가공할 수 있다.
ELK stack에서의 역할은 수집 및 가공된 data들을 Elastic에 전달하는 역할을 맡는다.

Kibana
kibana는 ELK stack에서 모니터링 및 시각화를 담당한다.

ELK stack의 구성형태 및 처리 순서
. Data processing ( Logstash )
-> log, 혹은 DB등에서 data 수집 ( input )
-> data 변환 ( filter )
-> data 전달 ( output )
. Storage ( Elasticsearch )
-> data의 저장
-> data의 분석
-> data의 관리
. Visualize ( Kibana )
-> dashboard등 다양한 시각화 자료 확인 가능
-> elastic 환경에 대한 접근 제어

ELK의 장점
ELK 의 경우 전반적인 장점으로는 빠른 검색과 특정 data들에 대한 분석, 시각화를 손꼽는다.
더불어 개발자가 아니더라도 ata에 대한 집계 및 검색을 하기 쉽다는것도 장점이다.
그 외의 다양한 모듈등이 존재하며 유연하게 data를 분석,가공 할 수 있는 생태계라는것 역시 장점이다.
실제 작성자가 참여한 프로젝트에서도 ELK를 활용했었는데 서버LOG를 빠른속도로 보기 쉽도록 가공된 상태로 조회한다는게 좋았던 기억이 있다.

ELK의 단점
E, L, K의 각각의 단점이 아닌 ELK stack 자체의 단점으로는 아무래도 리소스를 많이 사용한다는 점과 용량 역시 많이 차지한다는 점이 있다.
또한 ELK stack 환경을 구축하는 것이 해당 정보분석에 다소 과하진 않은가 에 대해서도 충분히 고려해야 한다.

DB 혹은 server를 개발하다보면 UUID란 말을 한번쯤은 들어봤을 것이다.
이번 포스팅에서는 UUID란 무엇이고 그 외 추가적인 내용을 알아보자.

UUID란?
UUID란 범용 고유 식별자(Universally Unique Identifier)의 약자이다.
간단하게는 다른 리소스중에서 해당 리소스를 고유하게 식별해주는 값 이라고 생각하면 된다.

이렇게만 보면 기본적으로 ID를 auto increment해주는 것과 차이가 없다고 생각할 수도 있다.
일반적인 ID와는 어떠한 점에서 차이가 있을까?

우선 UUID는 주로 분산 컴퓨팅 환경에서 사용되는 식별자로, 중앙 관리 시스템에서 순차적으로 일련번호를 부여하는 것이 아니더라도 고유한 값을 보장할 수 있어야 하기때문에 탄생하게 되었다.
- 물론 UUID 역시 완벽하게 고유성을 보장하지는 못한다.

UUID의 구조
UUID는 128 bit(16byte)로 구성된다.
UUID는 32자리의 16진수로 표시되는데 여기서 각 8-4-4-4-12 자리마다 의미하는 내용이 다르다.

UUID의 종류
UUID는 버전이 여러개 존재하는데( 1 ~ 5 ) 대표적으로 1, 4 버전이 많이 사용된다.
1 버전의 경우 UUID 생성을 timestamp를 기준으로 생성하며,
4 버전의 경우 무작위 랜덤 생성을 통해 UUID를 발급한다.


UUID의 하이픈(-)을 제거해도 괜찮은가?
UUID를 발급 받으면 해당 문자열에는 하이픈이 포함되어 있다. 굳이 문자열 길이를 더 늘린상태로 활용해야할 필요가 있을까? 우선 UUID에 하이픈이 포함되는 것이 국제 표준이며 유일성을 보장받을 수 있다.
다만 하이픈을 없앤다고 해도 유일성이 깨지는 확률이 상당히 낮다