ELK 스택이란 무엇인가

#개발자의도구들 #ELK스택 #ElasticSearch #Logstash #Kibana

​

AI스쿨 msa기반 java 백엔드 코스 중에 공부한 내용을 작성하였습니다

\* 현재 Spring x 프로젝트를 진행하고 있습니다. 전체 목차를 보시려면 여기를 눌러주세요.

\* Devops stack: 여기

\* 리눅스 기본기: 여기

ELK Stack ?

ELK 스택은 Logstash, Elastic Search, Kibana로 구성됩니다. ELK 스택을 사용하면 서버내에서 발생한 로그들을 관리하며, 해당 로그들을 시각화하여 서비스의 유지, 보수, 운영에 도움을 줍니다.

전체 구조는 매우 단순합니다. 서버에서 생성된 로그는 Logstash로 Logstash로 전달된 로그는 Elastic Search로 전달됩니다. Elastic Search는 로그를 저장하는 DB로 보시면 됩니다.

​

Kibana는 로그를 시각화하기 위한 도구로, Elastic Search에 저장된 로그를 Kibana에서 시각화 하여 볼 수 있습니다.

​

위의 구조는 매우 심플한 구조이며, 실질적으로 더 복잡하게 구조를 만들 수 있습니다.

                                    ✍️ Tips
1. 반드시 Logstash를 거쳐서 Elastic Search에 로그를 저장할 필요는 없습니다.
2. 반드시 Kibana를 사용하여 Elastic Search를 시각화 할 필요는 없습니다.
3. Elastic Search는 로그를 관리하기 위한 전용 DB로 보시면 됩니다.

​

Deep Insight

🔍 ELK를 사용하는 근본적인 이유

​

ELK는 로그를 관리하기 위해 사용되는 스택입니다. 그럼 ELK 이전에 어떻게 Log를 관리하는지 알면 ELK가 가져다 주는 이점에 대해 파악할 수 있습니다.

​

기본적으로 서버가 있다고 해봅시다. 서버에는 어떤 오류든 발생합니다. 실제로 운영되는 서버라면 해당 오류의 원인을 수정하여 서버내에서 발생하지 않도록 만들어야합니다.

​

하지만, 보통 서버를 돌려놓기만 할 뿐, 해당 서버를 24시간 내내 쳐다보고 있지 않습니다. 보통 서버 로그는 프린팅 되어 cmd 화면에 출력됩니다. 이런 출력된 로그들은 서버가 중지되면 모두 사라집니다.

​

만약 서버가 잠시동안 꺼졌다가 다시 켜진다면, 개발자는 해당 오류를 인식조차 할 수 없습니다. 이런 상황에서 개발자가 할 수 있는 조치는 무엇일까요?

네 맞습니다. 정답은 매우 명확합니다. 저장하면 되는 것이죠. 그렇다면 이번에는 어떻게 저장해야 하는가에 대해 고민해봅시다.

​

저장의 가장 기본형태는 텍스트 파일로 로그 메세지를 있는 그대로 남겨두는 것입니다. 예를 들어 아래와 같이 Spring에 적힌 모든 로그를 있는 그대로 남겨둔다고 해봅시다.

                                    18:09:08,849 |-INFO in ch.qos.logback.core.model.processor.DefaultProcessor@59ebc205 - End of configuration.
18:09:08,850 |-INFO in org.springframework.boot.logging.logback.SpringBootJoranConfigurator@64bef789 - Registering current configuration as safe fallback point

매우 알아보기 불편하지만 괜찮습니다! 팀에서 이렇게 하기로 합의 되었으며 이미 팀원들은 해당 로그가 익숙하다고 가정해봅시다.

​

하지만, 어느날 서비스의 운영을 다른 팀과 협업 하기로 했다고 해봅시다. 새로운 팀은 로그를 보고 충격에 빠집니다. 해당 로그는 알아보기 너무 힘들기 때문입니다.

​

두 팀은 여러 논쟁 끝에 하나의 결론에 도달합니다. 바로 "데이터 형식을 통일하여 알아보기 쉽게 하자"는 것입니다. 어떤 데이터 형식이 좋을지 고민하다가, 일반적으로 웹 통신에 자주 사용되는 JSON으로 통합하기로 합의합니다.

                                    {
  "@timestamp": "2025-02-06T22:00:00.000Z",
  "@version": "1",
  "message": "User logged in",
  "logger_name": "com.example.MyController",
  "thread_name": "http-nio-8080-exec-1",
  "level": "INFO",
  "level_value": 20000,
  -- custom --
  "service_name": "my-application",
  "host": "my-host",
  "traceId": "abc123"
}

이렇게 포멧을 지정하고 보니, 언제 로그가 발생했으며, 어느 단계인지, 원인은 무엇인지 등 한눈에 알아볼 수 있습니다. 또한 두 팀은 JSON으로 로그를 관리하다보니, 검색에도 이점이 있다는 것을 깨닫게 됩니다.

​

🤔 이제 모든 문제가 해결 되었을 까요?

​

두 팀은 JSON 로그를 매우 만족스럽게 사용하던 도중 하나의 문제를 깨닫게 됩니다. 바로 서버가 다 다른 VM 내에 운영되고 있기 때문에, 특정 서버의 로그를 보려면 해당 서버에 있는 파일을 가져와야 한다는 사실입니다.

​

두 팀은 서로 다른 서버의 로그를 한 곳에 통합하여 관리하면 좋겠다는 생각을 하게 됩니다. 마치 DBMS 처럼 로그를 저장하는 데이터 베이스를 따로 만들기로 결정합니다.

자, 이제 Elastic Search라는 Database가 만들어졌습니다. 각 서버는 하나의 DB에 로그를 저장합니다. 각 팀은 이제 이 DB에서 모든 로그를 확인할 수 있습니다.

​

🤨 다 좋긴한데... 보는 것이 불편해요

​

이제 로그를 보기에도 편하고, 로그도 한곳에 모아서 검색하기도 쉬워졌습니다. 하지만, 한 팀에서 일하던 팀장이 해당 로그를 그래프나 도표 처럼 시각화 하여 보면 좋겠다는 생각을 하게 됩니다.

네, 그렇게 만들어진 것이 Kibana입니다. 이제 두 팀은 단순히 에러에 대한 로그 뿐 아니라, API 요청 수와 같은 실질적 가치가 잇는 로그들도 이 시각화 도구를 사용하여 손쉽게 파악할 수 있게 되었습니다.

​

​