Beats를 통해 eBay에서 매일 로그의 페타바이트 모니터링하기

eBay는 매일 1.2페타바이트의 로그와 초당 메트릭 데이터 요소 5백만 개가 있어 추적할 데이터가 넘쳐납니다. 전자 상거래 회사의 로깅 및 모니터링 팀은 모든 로그와 메트릭을 수집하고 시각화하는 엄청난 업무에 매일 마주합니다. 또한 대부분의 회사와 마찬가지로, 다양한 애플리케이션(Hadoop 및 MySQL 등)을 사용하여 여러 팀에 다양한 사용 사례를 제공합니다.

컨테이너가 새로운 애플리케이션 배포 방법을 보여주는 화면에 나타났을 때 팀은 라이프사이클 관리에 Kubernetes를 사용하여 Docker를 컨테이너 방식으로 담고 Kubernetes를 통해 배포합니다. 하지만 여러 팀이 겪는 가장 큰 어려움 중 하나는 앱과 환경이 항상 변하며 계속 파악하기가 어렵다는 점입니다. Beats의 도입으로 새로운 국면을 맞이하게 되었습니다. Filebeat 및 Metricbeat는 Docker 및 Kubernetes의 로그와 메트릭을 수집하고 배포하는 두 가지 확실한 선택이었습니다.

또한 작업이 생성될 때 그 규모를 파악할 수 있기를 원했습니다. 자동 검색 기능이 Beats에 등장하기 전에(6.2의 신규 기능) 자체적으로 Collectbeat를 만들었습니다. 해당 Beat는 libbeat를 기반으로 구축되어, Kubernetes 클러스터에서 새로운 pod를 발견했습니다. Collectbeat는 Kubernetes API를 사용하여 작업 부하를 검색하고, 데이터를 수집 및 강화한 다음 내부 모니터링 시스템으로 보냈습니다. Sherlock.io라고 하는 이 시스템은 유연하고 신기술 채택에 적응할 수 있도록 구축되었습니다.

수집에 관련된 측면이 이제 해결되었지만 분석 및 시각화 부분은 여전히 집중적으로 다뤄야 할 문제입니다. 모든 데이터를 수집하여도 eBay 사용자가 친숙한 라벨을 사용하여 이 데이터들을 분석할 수 있어야만 유용합니다. 다음 논리적 단계는 전송하기 전에 메타데이터로 데이터에 태그를 지정하는 방법을 확인하는 것이었습니다. 그래서 eBay의 Vijay Samuel과 그의 팀은 로그 메시지와 메트릭 페이로드를 취하고 이름과 pod 스페이스와 같은 메타데이터를 추가하는 ‘add_kubernetes_metadata’라는 명칭의 프로세서를 구축했습니다. 이제 이 프로세서는 GitHub에서 사용할 수 있으며 커뮤니티 중심의 오픈 소스 프로젝트가 강력한 이유를 보여주는 좋은 예입니다.

물론, eBay도 여전히 변화하고 있습니다. 새로운 기술의 채택으로 더 많은 애플리케이션, 로그, 메트릭이 제공됩니다. 사실, 유기적 로깅 성장은 전년대비 50%입니다. 그렇다면, 리소스가 유한할 때 증가하는 데이터를 처리하는 방법은 무엇입니까? 한 가지 방법은 티어 기반 할당량과 보유 제한을 생성하여 호스트/풀 수준에서 애플리케이션을 측정하는 것입니다. 다른 방법은 특정한 데이터 유형에 우선순위를 부여하는 것입니다. 이벤트가 최우선이며, 운영 가시성을 나타내는 메트릭이 두 번째, 로그가 그 다음입니다. 그렇게 하면 올바른 우선순위를 유지하도록 이벤트 스케줄러를 추가하고 자동 검색이 구성에 가중치를 추가할 수 있습니다.

팀의 도구와 전략에 대해 더 알 준비가 되었습니까? Elastic{ON} 2018에서 Vijay가 한 프레젠테이션을 통해 Sherlock.io와 Beats를 활용하여 Kubernetes 클러스터 내의 모든 데이터를 모니터링하는 방법을 알아보세요. Elastic Stack을 통해 Kubernetes 및 Docker를 모니터링하는 방법에 대해 자세히 알아보려면 당사의 Elastic Stack: Beats를 통해 Kubernetes 애플리케이션 모니터링하기 웨비나를 참조하세요.