기존에는 EFK스택을 사용하여 시스템을 구성하였으며 구축된 시스템을 이용하여 사업 및 운영팀에서 게임 로그데이터를 조회하였습니다.
ElasticSearch는 막강한 indexing 기능으로 대용량의 데이터 속에서도 원하는 데이터를 빠르게 조회할수 있는 장점이 있었습니다. 하지만 빠른 속도를 위해 indexing을 하다보니 데이터 저장소를 과도하게 사용하는 측면이 있었습니다. 대략 로그 데이터 용량의 2~3배 정도되는 용량을 index를 위해 사용되었습니다.
이때문에 순전히 디스크 용량을 위해 호스트머신을 전부 할당을 받아 구축하게 되어 CPU나 메모리가 남는 현상이 발생하는등 비효율적인 측면이 생겼습니다. 결국 저장소 비용을 아끼기 위해 리플리카수를 조정하기에 이르렀고 이는 시스템 성능 및 안정성에 문제를 일으켰습니다.
이러다 보니 나중에는 저장소, 시스템 속도, 안정성 및 인력 리소스까지 영향을 미쳤습니다. 이를 해결하기위해 저장소 비용이 저렴하면서도 기존 만큼 속도가 보장되고 안정적이면서 확장성있는 시스템 구축이 필요하게 되었고 Hadoop Ecosystem를 기반으로 한 빅데이터 플랫폼 구축을 검토하게 되었습니다.
전사에서 같이 쓸 빅데이터 플랫폼을 구축하는 것을 목적으로 하였으므로 누구라도 원하면 바로 데이터를 가져갈수 있는 서버가 필요했습니다. 이를 위해 kafka를 도입했습니다.
kafka는 발행/구독 형식의 분산형 메세징 시스템 입니다. 물론 각 서버에서 저장소로 데이터를 바로 보낼수도 있지만 저장소 서버가 만에하나 떨어진다면 데이터를 보내는 쪽에서도 계속 실패가 날것이고 데이터 유실이 일어날 확률이 높습니다. 따라서 중간에 믿을 수 있고 안정적인 버퍼 서버가 필요하였고 이 역할을 수행할 수 있는 시스템이 kafka입니다.
kafka서버 구축을 완료한 이후 이제 kafka로 로그 데이터를 보내는 작업을 진행하였습니다. 로그데이터를 다른 서버로 전송하는 방법은 많이 있지만 저희는 filebeat를 사용하였습니다. filebeat를 선택한 이유는 서비스 자체가 매우 가벼워서 게임서버에 부담이 없고 윈도우, 리눅스서버 상관없이 쓸수 있는 점이 좋았습니다. 또한 다양한 플러그인을 지원하여 추후 다른 형식의 데이터를 보낸다고 해도 대부분의 케이스를 커버가능할 것이라고 보았습니다.