AMAZON ES 사용하기

foremessage 개발이 진행되는 과정에서 클라이언트에서 통신이 실패한다든지, 응답코드가 500 error가 내려오는 경우에 대해서 로그를 확인해야 되는데, 이를 실시간으로 확인을 할 수 있는 곳이 없다.

직접 서버에 ssh로 접근을 해서 로그를 확인할 수는 있으나, VPC구축을 하고 외부 접근을 막아 놓다보니 외부에서 확인이 쉽지가 않았다. 이를 쉽게 볼 수 있도록 하기 위해서 elasticsearch를 사용할려고 한다.

회사에서도 application log에 대해서는 es를 통해 kibana로 보고 있다. 해당 시스템을 foremessage에도 적용을 해볼려고 한다. 다만 회사에서는 ES를 managed service를 이용하고 있지 않지만, 우리는 amazon es인 managed service를 이용할려고 한다. 이유는 다음과 같다.

1. 비용이 추가가 된다.

일반 instance로 띄울 경우, instance 비용이 추가로 들어간다. 돈이 없는 대학생 개발자여서 비용이 추가로 들어가는 부분에 대해서는 거부감이 있었다. Amazon es는 가입 후 1년 동안 t2.micro 레벨로 프리티어로 제공을 해준다.

1. 관리가 어렵다.

   따로 띄우고 있는 서비스에서 ES를 다른 instance를 이용해서 띄워보았으나 JVM에서 서서히 메모리를 점점 먹기 시작하더니 결국 서버 메모리자원이 넘어서면서 서버가 죽는 현상이 반복되었다. JVM의 heap 메모리 사이즈 최대값과 최소값을 설정을 하였으나, 잘 적용이 되지 않는 모습이였다.

Amazon es를 이용하면 위의 2가지 문제를 해결할 수 있기 때문에 amazon es를 이용하도록 하였다.

기본 구성

Amazon es를 이용해 elasticsearch를 구성하고, api서버에 떨어지는 application log를 logstash를 이용해서 amzon es로 전송하도록 한다. t2.micro의 경우, 1G의 메모리로 구성 되는데, passenger와 ngnix까지 운영이 되고 있어서 logstash보다는 경량화되어 있는 filebeat를 이용할려고 하였으나, filebeat에서 amazon es로 전송을 할 수가 없어서 logstash를 이용할려고 한다.

AMAZON ES 구성

아쉬운 점

logstash가 떠 있다보니, 메모리 자원이 항상 70 ~ 80%를 사용하게 된다. logstash의 jvm option으로 heap size를 256M으로 구성을 하여도 항상 top를 이용해 리소스 자원을 확인하면 항상 500M정도 사용하는 것 같다. 이 부분은 좀 더 확인 후 수정할 수 있도록 해야겠다.

메모리 자원이 80%가 되다보니, 배포를 하게 될 경우, bundle install하면서 메모리 자원을 좀 더 먹으면서 서버가 죽는 현상이 발견되었다. 배포 스크립트에서 배포 시작전 해당 logstash를 중단시키고 배포가 끝나면 다시 logstash를 띄울 수 있도록 하였으나 좋은 방법은 아닌것 같아서 logstash 메모리자원을 수정하던지 아니면, filebeat로 변경을 할 수 있던지 해야겠다.