[클러버] 운영을 위한 초기 인프라 구축 과정

실제 운영을 위해 인프라를 구성하였다. 프리티어 EC2 인스턴스 하나로 운영 예정인 작은 사이드 프로젝트이긴 하지만, 장애가 발생하였을 때 대처할 수 있는 시스템을 구축하는 것 자체가 의미있는 경험이라고 생각하고 있다. 

 

[로그, 모니터링 시스템] 

1. Promatil , Loki , Grafana 

기존에는 Spring Boot에서 발생한 로그를 도커 볼륨을 이용해서 EC2에 저장하고, 해당 파일들을 조회했다. 일일히 파일 열고, vi로 에러 로그를 검색하는 것 자체에 대한 불편함이 계속 있었던 거 같다. 이를 해결하기 위해 PLG 스택을 위한 로그 수집기 & 모니터링 시스템을 구축하였다.

 

vs ELK 

ELK 스택의 경우 질의가 훨씬 정교하지만, 현재 EC2의 리소스 상황으로는 운영되긴 힘든 무게였다. 앞에서 언급했듯이 한정된 리소스로 효율적으로 운영을 해보는 것이 목표였기 때문에, ELK보다는 상대적으로 경량으로 로그 수집 & 조회가 가능한 PLG 스택을 사용하였다. (메모리 총합이 전체 메모리의 10프로를 조금 넘는다!) 

 

구성

모니터링 서버를 운영 서버와 분리하여 구성하였다. 

 

작동 흐름

작동 흐름을 간단하게 정리한다면, 

1. Spring Boot 컨테이너 로그를 도커 볼륨으로 EC2 호스트 내부에 저장한다. 

2. 로그 수집기인 Promtail 컨테이너와 해당 로그 파일과 도커 볼륨을 사용하여 컨테이너 내부에 로그 파일을 위치시킨다. 

3. (운영 서버의) Promtail 컨테이너는 해당 로그 파일을 주기적으로 수집하여 (모니터링 서버의) Loki에 전송한다. 

4. Loki를 활용하여 해당 로그파일에 대한 질의를 수행한다. 

5. 이를 Grafana 컨테이너와 연동하면 시각화하여 로그 질의가 가능하다. 

파일 별로 로그를 조회할 수 있고, 텍스트 질의까지 가능하다.

 

2. 운영 환경별 Logback 설정 분리  

실제 운영을 하기 위해서는, 각 운영 환경 별 다른 로그 저장 정책이 필요했다. 이를 위해 Logback 설정을 구체화하여 구현하였다. 

 

[로컬] 

- ConsoleAppender 

- SQL & Hibernate 관련 Appender : Debug 로그 

- root level : INFO 

=> 로컬 환경에서는 ConsoleAppender만 실행되게 하여 로컬에서 로그 파일 저장을 하지 않게 하였다. 

 

[개발] 

- FileAppender

- SQL & Hibernate 관련 Appender: Debug 로그 

- root level : INFO 

=> 개발 로그에서는 로컬 환경과 동일하게, SQL & Hibernate 관련 Debug 로그를 발생시키고, 파일로 저장한다. 

 

[운영]

- FileAppender 

- root level : INFO

- Debug 제외 

=> 운영시에는 Debug 로그가 필요 없어 제외시켰다. 

=> ERROR 로그만 저장되게 설정하는 경우도 있다고 하는데, INFO 로그를 포함시킨 후, 추후에 상황에 맞게 변경하려 한다. 

 

[장애 시 알림 서비스] 

1. Grafana Alerts 

개발 하는 과정에서 해외에서 디도스 공격으로 인해 말도 없이 EC2가 다운된 적이 있다. 

https://velog.io/@sseongeun/ddos%EA%B3%B5%EA%B2%A9%EB%A7%89%EA%B8%B0

DDOS 공격 막기

팀원이 고생을 해주어서 요청을 막기는 했는데 언제 또 서버가 예상치 못한 문제로 서버가 다운될지 모른 상태이고, 별도의 알림이 없다면 대응이 힘들다고 생각했다. 이를 위해 Spring Boot Actuator에서의 헬스 체크 API의 응답값을 주기적으로 확인하는 작업을 Grafana Alerts에 Rule을 추가하여 문제 시 알림을 보내는 기능을 추가했다. 

 

 

 

2. 500 에러 발생 시 알림 

 클러버 팀은 소통을 위해 Slack을 사용하다가 Discord로 이전하였다. (무료 요금제로 Slack + Zoom 쓰다가 질려버렸다)

서버 내부 에러(HTTP Code 500)가 발생할 때, Spring Boot 공통 에러 핸들러에서 받고 알림을 전송해주고 있다. 개발 상의 문제일 경우이기 때문에, 알림을 받고 최대한 빠르게 장애 지점을 파악하여 수정하기 위해서다. 구현은 Discord Webhook과 Feign을 사용하였다. 

 

첫 문제 발생 

같은 카카오 code가 반복 요청(KOE320)되는 문제가 발생하였다. Front-End 로직 상 발생한 문제였는데 빠르게 발견하여 팀원이 빠르게 대처할 수 있었다. 하지만, 문제 원인 확인을 위한 로그 정보가 부족했다. 추후에 보다 더 구체적이고 가독성 있는 로그 포맷을 구성하는 것이 더 필요해보였다. 

 

외부 API상에서는 400에러이지만 에러 핸들러에서는 500 공통 에러로 판단하고 처리했다.

 

 

참고 

https://jojoldu.tistory.com/763

경쟁력 있는 신입 포트폴리오

 

https://sienna1022.tistory.com/entry/%ED%94%8C%EB%A1%9C%EB%8B%88-%EC%97%90%EB%9F%AC%EC%97%90-%EB%8C%80%EB%B9%84%ED%95%98%EB%8A%94-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%A7%8C%EB%93%A4%EA%B8%B0

[플로니] 에러에 대비하는 서비스 만들기

https://medium.com/@minina1868/%EB%A1%9C%EA%B7%B8-%EA%B0%9C%EC%84%A0-%EA%B3%BC%EC%A0%95-devops-observability-1-logs-3baaf2699546

불편했던 로그 시스템 전환기 with PLG

https://velog.io/@joonoo3/TrubleShooting-EC2-Docker-Compose%EC%8B%9C-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%B6%80%EC%A1%B1-%ED%95%B4%EA%B2%B0-feat.-ElasticSearch

[TrubleShooting] EC2 + Docker (Compose)시 메모리 부족 해결 (feat. ElasticSearch)