로그 보기 너무 힘들어요 (?_⊙)?
배포한 서비스의 에러로그를 보기 위해선 E2C 우분투 서버에 들어가 직접 명령어로 로그를 확인해야했고 다음과 같은 문제가 발생했다.
따라서 서버에 접속하지 않고도 로그를 확인할 수 있는 방법을 도입하기로 했다.
이런 기능을 도입한다면, 추가적으로 사용자 행동 분석, 보안 모니터링등의 이점을 얻을 수도 있다고 한다!
먼저 어떤 기술 스택을 사용할지 고민했다.
여러가지 기술이 있었지만 나는 다음의 세가지 조건을 고려했다.
1. 무료일 것
2. 프로젝트 규모에 적합할 것
3. 취업에 의미 있는 기술일 것
지금 배포 준비 중인 서비스는 수익이 나는 구조가 아니고, 이후 수익구조로 바꾸더라도 필요이상의 성능으로 인한 지출은 의미없다고 생각했다.
따라서 2번과 3번의 기준에서 많이 생각해봤고 다음의 두 가지를 고민하게되었다.
EFK Stack는 Elasticsearch, Fluentd, Kibana의 약자이다.
EFK Stack는 세가지의 기술로 구성되어있다.
Elasticsearch는 대규모 데이터 저장/검색에 특화된 검색 엔진이다. 대규모의 로그를 저장해야할 때 유용하다.
Fluentd는 데이터 수집 파이프라인을 구축하는 도구로 다양한 데이터의 수집,전송을 지원한다. 또한 고마운 오픈 소스 플랫폼이다.
Kibana는 Elasticsearch의 데이터를 시각화하는 도구로, 그래프, 차트, 로그 분석 등의 기능을 지원한다.
이런 EFK Stack는 대규모 로그 수집이 필요한 상황에서도 유용하다.
또한 여러개의 서버가 돌아가는 분산환경에도 적합하다. 각 서버에 설치된Fluentd
가 중앙서버로 로그를 전송해주기 때문이다.
먼저 현재 프로젝트 실행 환경에 대해서 설명하자면,AWS EC2에서 배포되고 있으며, 애플리케이션의 로그는 우분투 서버의 지정된 파일에 저장되고 있다.
로그를 확인할 수 있는 페이지를 보기 위해서 백엔드 서버는 백엔드 서버는 Java의 File API를 사용하여 해당 파일들에 직접 접근하고 내용을 읽어오고 출력할 수 있다.
이런 구조는 외부 api를 사용하지 않고 간단하게 구현할 수 있다는 장점이 있다.
그러나 여러대의 서버가 돌아가는 환경이라면 로그 수집에서 복잡성이 올라갈 수 있고, 실시간성을 보장할 수 없다는 단점도 있다.
또한 만약 그래프나, 여러 분석 UI를 원한다면 구현의 어려움이 생길 수 있다.
과연 나의 선택은?
사실 3번의 기준에서 EFK가 조금 더 끌리지만? 가장 중요한건 프로젝트의 규모라고 생각한다. 어려운 일은 어렵게 쉬운 일은 쉽게!
현재 프로젝트는 분산 환경도 아닐 뿐더러 엘라스틱이 필요한만큼 대규모 로그가 발생하는 환경도 아니다.
또한 Elasticsearch가 많은 메모리르 사용하게 되어 서버 부하가 발생할 수도 있다.따라서 파일 기반의 로깅 + 관리자 페이지를 구현하기로 결정! (대신 이후 여유가 생기면 꼭 2탄으로 EFK 도입도 다루고 싶다!! )
안 할 수가 없잖아용~
되는지만 먼저 테스트 해보려고 한다.
로그분석에 활용할 수 있는 EFK 스택 간단하게 정리해보기-매직
좋은 글 감사합니다 ... 🙇♀️🙇♀️