런던의 아파트에서, Shay Banon은 일자리를 찾고 있었습니다. 그때 그의 아내는 요리 학교인 르 꼬르동 블루(Le Cordon Bleu)에 다니는 중이었습니다. Shay는 남는 시간을 이용해 점점 늘어가는 아내의 요리법 목록을 위한 검색 엔진을 만들기 시작했습니다.
최초의 버전은 컴파스(Compass)라고 불렀습니다. 두 번째 버전이 (아파치 루신(Apache Lucene)을 기반으로 한) Elasticsearch였습니다. 그는 Elasticsearch를 오픈 소스화했고, #elasticsearch IRC 채널을 만든 후, 사용자들이 나타나기를 기다렸습니다.
반응은 대단했습니다. 사용자들은 자연스럽고 쉽게 받아들였습니다. 사용자가 급증했고, 커뮤니티가 생겨나기 시작했으며, 사람들의, 좀더 정확히 말하자면 Steven Schuurman, Uri Boness, Simon Willnauer의 주목을 받게 되었습니다. 이들은 함께 검색 회사를 설립했습니다.
Elasticsearch Inc.가 설립되던 무렵, 다른 오프 소스 프로젝트가 두 개 더 시작되고 있었습니다.
Jordan Sissel은 Logstash를 작업 중이었는데, 사용자가 선택하는 보관함(stash)으로 로그를 보내는 오픈 소스 장착형 데이터 수집 도구였습니다. 그리고 그러한 보관함 중 하나가 Elasticsearch였습니다. 또한 조단은 그 외에도 로그 데이터를 시각화하기 위한 UI도 개발 중이었습니다. 하지만 잘봐준다고 해도 상당히 불안정했습니다.
다행히도, 다른 사람이 시각화 작업의 어려움을 해결하려 개입하게 되었습니다. Kibana라고 하는 오픈 소스 UI를 작업 중이던 Rashid Khan이 등장합니다.
Shay, Jordan, Rashid는 서로 알고 지냈고, 각자의 프로젝트에 대해서도 일정 기간 알고 있었으며, 함께 팀을 결성하기로 결정하고 ELK Stack — Elasticsearch, Logstash, Kibana Stack을 만들었습니다.
시간이 지나고, 우리는 두 개의 상용 플러그인을 출시했습니다. 모니터링을 위한 Marvel과 보안을 위한 Shield입니다.
초창기에는, Elastic에서 소프트웨어를 빌드하고 릴리스하는데 모든 엔지니어들이 저마다 스스로 알아서 작업하는 방식을 취했고, 원하는 버전을 원하는 시기에 출시하곤 했습니다. 멋진 결과만 나오면 되었죠. Kibana에는 베타가 있었고, Logstash에는 마일스톤이 있었고, Elasticsearch에는 숫자가 있었습니다. 모두가 하고 싶은 대로 플러그인이 결정되었습니다. 혼란스러웠지만, 작업은 진행되었습니다...하지만 더 이상 그렇게는 일할 수 없는 때가 왔죠.
사용자들이 제품으로 더 많은 것들을 하게 되면서, 우리는 사용자들에게 더 많은 일들을 해주는 제품을 빌드해야 할 필요가 생겼습니다. 우리는 기능을 추가했고, 풀 리퀘스트를 더 많이 제출했으며, 새 플러그인과 익스텐션을 만들었습니다. 더 멋진 제품이 되었고, 복잡하게 되기 시작했으며, 우리의 테크놀로지 스택에 비해 모든 것이 혼란스럽고 엉망이 되어 갔습니다.
예를 들어, Elasticsearch 1.7 버전과 일부 플러그인의 2.3 버전을 작동시키고 있다면, 서로 호환되고 있는지 아니면 플러그인이 아무런 신호도 없이 작동을 멈추고 있는지 여부를 자동으로 알 수 있는 방법이 없었습니다. 이것이 버그였습니다.
또한 우리는 “Shield를 사용하고 싶은데, 그럼 Elasticsearch 1.4.2가 필요해…Watcher를 사용하고 있지 않다면 말이야. Watcher를 사용하고 있다면, Elasticsearch 1.5.2가 필요하게 될 거야. Elasticsearch 1.5.2를 사용하고 있다면, Kibana 4.0.x, Logstash 1.4.x, Shield 1.2.x, Watcher 1.0.x하고만 호환이 돼.” 이런 식의 얘기를 듣게 되기 시작했습니다.
우리는 온갖 버전이 난무하는 상황에 봉착하게 되었습니다. 지원 매트릭스도 그다지 더 나아보이지 않았습니다. 변화가 필요한 때였습니다.
제품 팀이 버전 숫자들과 씨름을 하는 동안, 다른 제품 이야기가 펼쳐지고 있었습니다. 2015년에, 우리는 베를린을 기반으로 한 Packetbeat이라는 회사를 알게 되었습니다. 부부가 한 팀을 이뤄 네트워크 데이터를 Elasticsearch로, Elastic 패밀리로 보내는 경량의 전송 방법을 엔지니어링하고 있었죠.
이들 덕분에 우리는 이렇게 생각하게 되었습니다. 우리에게 에지 장비에서 Logstash와 Elasticsearch로 네트워크 데이터, 로그, 매트릭스, 성능진단 데이터 등을 보내는 단일 목적을 가진 경량 데이터 수집기 패밀리가 있다면? 이렇게 해서 Beats가 탄생했습니다.
2015년 10월은 제품 버전과 호환성의 복잡한 세계를 처리한 전환점으로 기억됩니다.
“대박 릴리스"라고도 하는데, 우리 전 제품 사상 최초였습니다. Elasticsearch 2.0, Logstash 2.0, Watcher 2.0, Shield 2.0, Kibana 4.2 — 이 모든 제품이 같은 날 함께 출시되었습니다. (Beats 1.0은 마무리 작업을 하는데 한 달이 더 걸렸습니다.)
이 노력을 조율하는 것은 쉽지 않았습니다. 엔지니어링 팀은 이 제품 모두가 함께 작동하는 방식으로 바꾸어서 제품을 빌드하고 테스트를 해야 했습니다. 그러나 그럴 만한 가치가 있었습니다. 이 변화는 사용자가 우리 제품을 좀더 쉽게 시작할 수 있게 해주었고, 우리 제품이 좀더 안정적으로 멋진 일들을 처리할 수 있게 해주었습니다.
좀더 성숙한 제품을 제공하기 위한 첫 단계는 Elasticsearch 2.0의 릴리스 리듬을 맞추는 것이었습니다. 두 번째 단계는 5.0의 출범이었습니다. 이로써, 그 어느 때보다도 훨씬 더 통합되고, 안정적인 테스트를 거친, 훨씬 더 쉽게 시작할 수 있는 제품이 소개되었습니다.
5.0 릴리스는 또한 우리의 모든 상용 플러그인(당시 Shield, Marvel, Watcher라고 부르던)이 번들로 포함된 X-Pack이라고 하는 단일 익스텐션으로 제공되었습니다. X-Pack은 우리의 핵심 제품을 위한 보안, 모니터링, 알림과 같은 기능들로 구성되었고, 런던 기반의 Prelert라고 하는 회사를 Elastic 패밀리로 영입하면서 더욱 성장하여 머신 러닝을 포함하게 되었습니다.
5.3 버전(2017년 3월 릴리스)에서는, Filebeat가 공식적으로 ‘모듈’ 개념, 다시 말해, Elastic Stack에서 공통된 로그 형식(Apache, Nginx, MySQL 등)을 수집/전송, 구문 분석, 저장, 분석 및 시각화하기 위한 한 세트의 안전한 구성을 도입했습니다. 모듈은 데이터세트에서 대시보드로의 이동을 훨씬 더 간소화해 주었습니다.
Metricbeat와 Packetbeat는 고유의 특색을 가진 모듈이었는데, 몇 달 후에 Logstash는 ArcSight와 NetFlow 데이터를 위한 자체적인 모듈을 도입하게 됩니다.
처음부터, 우리는 사용자들이 자신의 조직에서 Elastic을 배포하는 방법을 간소화하고자 하는 비전을 가지고 있었습니다. 우리는 자체적인 Elastic Cloud 서비스를 관리하기 위해 사용하는 기술을 활용해 Elastic Cloud Enterprise(ECE)를 릴리스하여, 크고 작은 사업체들이 우리가 호스팅하는 제품의 좋은 것들을 모두 다운로드하고 스스로 운영할 수 있도록 했습니다. ECE는 한 클러스터로 묶어 관리할 수 있도록, 또는 수천 개의 클러스터를 무결하게 관리할 수 있도록 하여, 어떤 환경에서든 Elastic 제품과 솔루션을 간소하게 관리하고 오케스트레이션할 수 있도록 했습니다.
모듈이 급속하게 늘기 시작하자, 로깅이나 메트릭 같은 특정 사용 사례를 처리하기 위해 Elastic Stack을 시작하는 것이 점점 더 쉬워졌습니다. 그리고 그 여세는 계속 이어져 우리는 코펜하겐을 기반으로 하는 애플리케이션 성능 모니터링(APM) 회사인 Opbeat와 손을 잡았고, 몇 달 후에는 샌프란시스코를 기반으로 하는 사이트 및 엔터프라이즈 검색 회사인 Swiftype과 함께 하게 되었습니다. 두 회사 모두 Elastic의 일부가 되었습니다.
이 무렵이 되자, 우리 회사는 성숙해져서, 공통적인 문제 해결을 위한 간소화된 방식을 제안할 수 있는 위치에 있게 되었고, 이에 따라 우리는 공식적으로 솔루션을 도입하기에 이르렀습니다. 우리의 솔루션은 DIY 경험에서부터 턴키 제품에 이르기까지 다양하며, 각각은 실제 제품을 갖추고 있어, 불과 몇 분 만에 배포할 수 있습니다.
오픈 소스에서 오픈 커뮤니케이션까지, 개방적이 되는 것이 우리가 하는 모든 것의 중심에 있습니다. 이것이 바로 우리가 상용 X-Pack 기능들까지 코드를 개방하기로 결정한 이유였습니다. 개발 시간을 촉진하고 커뮤니티 참여를 증가시키며 이로써 모두가 우리 코드에 기여하고 코멘트를 하고 검사할 수 있도록 말이죠.
결과적으로, Elastic Stack을 훨씬 더 쉽게 시작할 수 있게 되었고, X-Pack의 모든 기능은 이제 Elasticsearch, Kibana, Beats, Logstash의 기본 배포와 함께 출시됩니다. 이 변화는 Apache 2.0 코드를 하나도 없애지 않았습니다. 대신에, 더 열심히 개방적이 되려고 했죠.