0. Table Of Contents
1. 설계에 반영되어야 하는 내용
- 하나의 솔루션 데이터 뿐만 아니라 여러가지 솔루션의 데이터를 핸들링 할 수 있어야 한다.
- 불필요한 색인을 줄여 자원 사용량을 줄일 수 있어야 한다.
- 형태소 분석을 어떻게 할 것인지에 대한 전략을 작성할 수 있어야 한다.
2. Shard 및 Index 설계
설계시 생각해야 할 조건을 나열하면 아래와 같다.\
- 이종간의 솔루션의 로그에 대해서 분석을 할 수 있어야 한다.
- ElasticSearch에서 권장하는 수준의 Shard 크기를 유지할 수 있어야 한다.
첫 번째 조건인 수집된 데이터에 대해 통계 및 분석을 할 수 있어야 한다에 대해 고민을 먼저해보자. elasticsearch에는 인덱스에 대해 검색시, wildcard(*)를 이용하여 복수개의 인덱스에 대해서도 색인 및 검색이 가능하다. 따라서 이를 사용하기 위해 인덱스 패턴도 계층이 적용되어야 한다는 것을 알게 되었다. 따라서 설계된 elasticsearch index pattern은 아래와 같다.
{{로그 성격 ex.logs, metrics, }}-{{솔루션 이름}}-{{현장}}-{{YYYYMMDDHH}}
위 패턴의 인덱스를 활용하면 여러 계층 및 시간대별로 인덱스가 분리되면서 검색 및 색인을 더 빠르게 할 수 있으며 ElasticSearch에서 권장하는 수준의 shard 크기까지 맞출 수 있을 것으로 보인다. 샤드 용량 계산식은 아래와 같다.
140 byte(1개의 json object 평균 크기) * 60(sec) * 60(min) * 24(hour) * 50(device) * 50(data) = 30.24 GB
3. Indice (ElasticSearch Data Modeling)
indice 설정을 어떻게 하냐에 따라 데이터 분석에 대한 내용이 달라지기 때문에 이 부분에 대해 조심해야한다. 해당 내용에 대해서는 아래 문서를 참조한다.
4. 데이터 시각화
처음에 Kibana Dashboard 원형 자체를 가져오려고 하였으나, 그렇게 되면 아래와 같은 단점이 존재하였다.
- 리버스 프록시를 이용하여 kibana 대시보드를 그대로 가지고오기
- 리버스 프록시 내부에 kibana 계정 정보가 있기 때문에 authentication 파편화 예상
- 가지고 오더라도 대시보드 컴포넌트를 선택적으로 들고올 수 없다.
- 대시보드를 커스텀 할 수 없다.
이러한 이유로 elasticsearch dsl query를 이용하여 직접 대시보드에 필요한 데이터를 전송 하는 것으로 전략을 대체하였다.