Spring log를 AWS CloudWatch에 연동하는 방법

pood 3.0 업데이트를 위해 서비스에 대한 개발이 마무리가 되어 가기 때문에
회사 인프라 환경 개선 작업을 시작하기로 하였습니다.

첫째로 현재 우리 회사의 CD를 Jenkins 활용하여 사용하고 있지만 Jenkins의 빌드에 대한 범위가 was의 실행 단계까지를 범위로 잡고 있기 때문에 was가 실행 되는 동안에는 빌드중인 상태로 유지하고 있습니다.

4일째 빌드중인 Jenkins.......

해당 방식의 장점으로는
1. was가 비정상적으로 죽었을 경우 빌드 실패로 간주하여 slack으로 연동되어 바로 메시지를 준다는 것입니다.
2. was 로그를 Jenkins의 빌드 로그로 바로 확인할수 있다는 장점이 있습니다.
보통 해당 서버를 터미널로 접속하여 로그파일을 tail로 확인하는 경우와는 달리 편하게 느껴지는게 사실이니까요

단점으로는 빌드의 영역에 맞지 않는 작업을 하고 있기에 많은 로그가 쌓일경우 서버가 강제적으로 죽어버리는 현상이 일어나 주기적으로 was를 재시작 해야 한다는 점입니다.

그래서 우리는 Jenkins의 책임을 빌드의 책임만을 주고 해당 방식의 장점을 다른 방법으로 취할려고 인프라 개선을 하고 있습니다.

Jenkins는 빌드의 책임만을 하도록 변경하고 로그는 CloudWatch를 활용하여 바로 확인가능하도록 변경하고 was서버가 죽으면 AWS에서 SNS(Simple Notification Service)을 사용하여 Slack으로 연동한다면 장점 1, 2를 모두 취하도록 개선작업을 시작하였습니다.

즉 2의 로그 확인은 CloudWatch에게 책임을 주고 1의 slack연동은 SNS에게 책임을 줘 Jenkins를 Jenkins의 답게 사용하려고 합니다.

먼저 CloudWatch 에서 was log를 저장할 로그 그룹을 생성해 줍니다.

Spring에서는 was 로그를 CloudWatch와 연동을 위해서는 logBack에 설정을 해주어야 합니다.
logback-awslogs-appender 라이브러리를 dependency 하고 spring_logback.xml 파일에 설정을 해주면 됩니다.

• logGroupName: CloudWatch log Group Name 을 적어 줍니다.
• logStreamUuidPrefix: 로그파일이 생성할때 무작위 uuid를 생성하는데 해당 설정을을 적어주면 적어준 text뒤에 uuid가 붙는 형식으로 로그파일을 생성됩니다.
• logRegion: CloudWatch AWS Region에 맞춰 적어주며 됩니다.
• maxBatchLogEvents: 최대 이벤트 갯수를 설정하는 것이며 1 ~ 10000사이 값만 설정이 가능합니다. 이벤트 대기열에 갯수가 50개가 되면 AWS Cloud Watch로 로그가 전송됩니다.
• maxFlushTimeMillis: 마지막 플러시가 발생된 이후 지정된 시간이 지나면 AWS Cloud Watch로 로그가 전송됩니다. 0일 경우 로그를 동기로 전송하고 0보다 큰값일 경우 비동기로 로그가 전송됩니다.
• maxBlockTimeMillis: 로그가 전송되는 동안 코드가 계속 실행되는 것을 차단하고 값을 0으로 세팅하면 전송중에 발생되는 모든 로그를 버립니다.
• retentionTimeDays: 로그그룹의 보존기간을 설정해주면 된다. 0으로 세팅하면 보존기간은 무기한 설정이 됩니다.
• accessKeyId: AWS IAM Access Key를 적어주면 됩니다.
• secretAccessKey: AWS IAM Secret Key를 적어주면 됩니다.

그 후 was서버를 실행해 주면 Creating AWSLogs Client라는 로그가 떳다면 정상적으로 설정이 된것을 알수 있습니다.

CloudWatch에서 확인하면 로그가 정상적으로 연동이 된걸 확인할수 있습니다.

다음에는 CloudWatch에서 SNS을 통행 was에 대한 이벤트를 Slack으로 연동하는 방법을 포스팅 하겠습니다.

감사합니다.