-
Notifications
You must be signed in to change notification settings - Fork 1
Logs
서버 모니터링은 안정적인 서비스 운영이라는 목적이 있다. 서버 장애가 발생하고 해결되기까지 오랜 시간이 걸린다면 고객들은 서비스에 대한 신뢰를 잃고 떠날테고 장애 시간동안 서비스가 동작하지 않는 것만으로도 금전적인 피해를 볼 수 있다.
따라서 큰 장애가 발생하기 이전에 미리 징후를 찾아내서 최대한 예방해야하고 장애가 발생하더라도 바로 원인을 파악하고 고쳐야한다.
감으로 문제점을 추측하는 것이 아닌 정확한 원인을 바로 찾기 위해서는 제대로된 모니터링 시스템이 갖춰져 있어야한다.
서버 모니터링 영역은 다음과 같이 구분된다.
- 인프라에 대한 모니터링: 애플리케이션이 실행되고 있는 인프라에 장애가 발생하거나 징후가 있지는 않은지 파악한다.
- 클라이언트의 요청에 대한 모니터링: 클라이언트에서 우리가 의도한 대로 올바른 요청을 보내고 있는지, 공격 시도가 들어오지는 않는지, 얼마만큼의 요청량을 보내고 있는지 파악한다.
로그는 그 당시 어떤 일이 일어났는지 확인할 수 있게 해주는 중요한 단서로서 문제 해결을 할 수 있는 유일한 단서가 되는 경우가 많다.
그렇기 때문에 이런 로그들은 반드시 기록하고 있어야하며 일정시간동안 유실되지 않도록 잘 관리해야한다.
서비스가 커질수록 로그의 양은 기하급수적으로 늘어나기 때문에 필요한 정보만 기록해야한다.
이렇게 많은 로그에서 손쉽게 필요한 정보를 찾을 수 있도록 관리할 방법이 필요하다.
로그의 양이 많아져서 생기는 문제뿐만 아니라 유시르이 문제도 있다. Auto Scaling을 이용하면 인스턴스가 하루에도 수없이 많이 실행되고 종료된다.
인스턴스가 종료되면 내부에 있는 데이터는 모두 유실되기 때문에 인스턴스가 종료되기 이전에 내부에 있는 중요한 정보들은 따로 관리해야한다.
다중 서버 환경에서 EC2 인스턴스는 연산만 처리하는 컴퓨팅 유닛
으로 생각해야하므로 보존해야 하는 파일과 같은 데이터는 EC2 외부에 저장해야한다.
AWS에서는 로그를 CloudWatch Logs
와 Elastic Stack
으로 로그를 관리하고 분석할 수 있다.
로그는 영구적으로 보존할 수도 있으며 만료 시간을 지정해서 자동으로 삭제되게 처리할 수 있다. 용량 단위로 요금이 책정되기 때문에 적당한 만료시간을 두는 것이 좋다.
CloudWatch Logs는 크게 세가지 항목으로 이루어져 있다.
- 로그 이벤트: 로그를 기록하는 애플리케이션이나 자원에서 로그를 기록한 줄의 모음. 독립적인 이벤트로 볼 수 있는 로그 줄의 묶음이기 때문에 로그 파일에서 한줄이 될 수도 있고 여러줄이 될 수도 있다. 예를들어, 애플리케이션 서버 로그에서 클라이언트 요청의 시작부터 응답을 줄 때까지 쌓인 여러줄의 로그를 하나의 이벤트로 볼 수도 있다.
- 로그 스트림: 동일한 소스에서 기록된 로그 이벤트들을 시간순으로 모아둔 스트림, 예를 들어 특정 인스턴스에서 발생한 서버 호출 로그들이 하나의 스트림이 된다.
- 로그 그룹: 여러 로그 스트림을 하나로 모아둔 곳. 예를 들어 여러 인스턴스에서 발생한 서버 호출 로그들을 모아둔 그룹이 존재하게 된다.
CloudWatch 에이전트 설정 파일을 이용해 인스턴스 내 어떤 파일을 가져올지 지정할 수 있다.