사용목적
서비스회사 금융권모두 Logging 하는 이유는
서비스 애플리케이션에 동작하는 기능들이 정상인지 장애가 발생했을 때 ELK스택으로 제공되는 다양한 GUI를 이용해서 프로파일링 하기 위한 목적으로 사용된다
ELK스택 사용방법
일단 검색엔진 목적이 아닌 이상 대부분이 ELK스택 설정은 클러스터 구성하고 기본적인 설정 이상은 사용하지 않는다
물론 ELK스택을 잘 알고 사용하거나 관심이 있다면 최적화하겠지만 실제 금융권 설치된 서버들 구성을 보면..
기본 설치 하고 관리가 잘되지 않는 것이 현실이다
운영 노하우
생각보다 리소스를 많이 사용하는 ELK스택은 관리를 해줘야 한다
하지만 개발을 입찰 올리고 정해진 업체를 선정해서 일정만 맞춰서 개발된 퀄리티에 서비스는 사실 … 답이 없다
관리가 잘되지 않아 방치되거나
막상 장애발생하여 원인파악을 위해서 Dashboard를 보면 내가 원하는 정보를 찾기 어렵거나 분석이 쉽지 않은 상태로 데이터들이 저장되어 있는 안타까운 상황을 볼 수 있다
어떻게 처리해야 잘할 수 있을까?
- 로깅 데이터를 이해할 수 있게 표준화할 수 있는 템플릿을 고민해야 한다
- Elasticsearch Document에 조회가능하게 Key:Value형태로 등록하여 원하는 조회가 될 수 있도록 Json형식을 권고하며 해당 부분이 적용하기 어렵다면 Logstash에서 구분할 수 있는 방법으로 로그를 구성해야 한다
- 비즈니스 로직에 영향이 가지 않도록 코드와 로그를 명확히 분리해야 한다
MDC를 권고하며 필요하다면 AOP를 사용하지만 되도록 가장 단순하게 할 수 있는 방법을 고려해야 한다
코드 분리를 위한 AOP도 중요하지만 단순화가 더 중요하다
인프런 김영한 님의 Spring고급에서도 나오는 프록시부터 Aop까지 나오는데 상황에 맞게 써야 한다 정답은 없고 베스트 프렉티스를 찾아야 한다
- 로그는 초당 처리되는 데이터를 마구잡이로 넣으려고 하지 말아야 한다 필요하다고 생각되는 정보는 커스텀하게 구성해서 Info 레벨로 만들고 error 역시 프로파일링 할 때 빠짐없이 로깅될 수 있도록 해야 한다
- Elasticsearch Datanode에 저장할 때 꼭 구성된 노드를 기반으로 인덱스에 주샤드 복제샤드를 검색 운영이 용이하도록 설정해야 하며 정책을 넣어서 특정기간이 되면 삭제 또는 백업이 될 수 있도록 해야 한다
- data node에 구성된 주샤드, 복제샤드 구성과 생성된 샤딩이 클러스링 된 ELK스택에 정상으로 구성되었는지 모니터링해야 한다
Document
관계형 데이터가 아닌 Nosql은 정규화 Join 등으로 구성한 데이터를 하나의 문서에 만들고 Elasticsearch의 역색인이라는 조회 최적화로 사용되는 문서이기에 CQRS패턴으로 쓰기에 적합하고 애플리케이션에서 TPS에서 쏟아져 나오는 데이터를 누적시키고 오류 프로파일링에 적합하다
다만 로그데이터를 모든 서비스 통합용도로 사용한다면 데이터를 정책 적용하고 주기적으로 고가용성에 문제가 없는지 관리해야 한다
우선 로그 통합으로 사용된다면 서버 구성 및 CPU, Memory, Disk 리소스를 검토하고
Master Node, Data Node 및 Hot, Warm, Cold 아키텍처 구성 정책적용을 우선 고민해야 한다
ELK스택 Document 템플릿 구성
Document는 저장되는 byte이기에 절대적인 양이 포함되어 디스크 용량 그리고 datanode를 고려해야 한다
사람이 주기적으로 관리하는 것도 방법이지만
Elasticsearch에서 사용할 수 있는 방법들을 언듭해보겠다
Hot Warm Cold 아키텍처
예를 들어 Logging 되는 데이터중 준실시간성이나 1-3일 정도는 다양한 이유로 빈도 높게 조회될 수 있고 로그데이터의 특성상 별이슈가 없다면 조회되지 않고 자주 사용되지 않은 채 큰 이슈나 추가적인 요인이 없다면 자주 조회되지 않는 데이터로 처리된다
이럴 때 특정 주기를 기반으로
Hotnode : 1-3 day
Warmnode : 3-6 day
Coldnode : 7-9 day
필요하다면 10 day이상 데이터는 별도 Nas 데이터 압축 후 특정 주기로 삭제
해당내용은 데이터를 처리하는 아키텍처로 다양한 Nosql형태의 라이브러리에서 사용이 가능하다
설정이나 재시작이 발생할 수 있지만 관리와 리소스사용을 위해서 필수 적인 요소 중 하나이다
Datanode 및 Index
Datanode의 INDEX는 어느 정도의 용량에서 검색 최적화가 유지될까?
권고하는 공식문서내용은 20-50GB 정도를 사용량으로 볼 수 있고
검색이 최적회 되는 용량은 20GB를 유지해야 한다!!
주샤드, 복제샤드
Datanode는 주샤드, 복제샤드로 데이터가 유실되거나 서버 중지 재시작 장애 등으로 같은 데이터를 Document 생성 시 설정할 수 있다
Datanode의 구성에 따라 주샤드 복제샤드 구성에 최적화 방안이 필요하다
ELK스택으로 로그를 전송하는 여러 방법
방안 1
Filebeat -> Logstash -> Elasticsearch
공식문서에서 권장되는 기본적인 구성
ELK스택 버전에 맞춰서 beats Agent 다운로드 이후
Windows, Mac, Linux 등 개발환경에 맞게 설정정보를 변경하고 정상적으로 Kibana 모니터링이 되는지 검증
방안 2
Logback-spring.xml
Logstash Tcp protocol append 방식으로 Logstash 파이프라인 연결 Elasticsearch 전송방식
방안 3
Elasticsearch HighLevelClient 이용한 전송방식
방안 1, 방안 2로 진행하는 것이 별도에 코드레벨 개발을 퇴소화 라며 전송하는 방식 방안 3 가능하지만 코드개발이 필요함
Kibaba 모니터링 최소한 기능 사용하기
Kibana는 지속적인 업데이트로 다양한 플러그인형태로 시각화할 수 있는 dashboard를 제공한다
너무 다양하다 보니 kibana를 처음 접하고 매뉴얼을 안 보면 뭘 써야 되는지 알 수 없지만
오늘은 간단하게 필요하다고 느껴지는 기능만 살펴보려고 한다
이 부분은 다음 시간에…
