Elastic{ON} 서울 투어 2/22

Elasticon{ON} 서울투어(2/22) 행사에 참여했다.

참여하게 된 계기는 회사 상사의 지목(?)이었고, 연구원 2명이서 그렇게 첫 IT컨퍼런스에 참석하게 되었다.

나는 이런 컨퍼런스 성격의 행사나 기술 세미나에 참가하는 것을 매 순간 학수고대 해왔을지도 모른다.

이제 4년차 웹개발자로 어느정도 내가 가진 기술에 대한 자부심도 가진듯..는 아직 멀었지.

저러한 신기술 관련 발표회나 다른 동료들이 공유하는 대세의 기술들은 접할 때 마다 부족함을 느낀다. 

그러기에 다른 사람들이 경험해보고 실무에 적용해보는 것들은 수박 겉핡기식이라 할지라도 배우거나 학습하고 넘어가고 싶었다. 그리고 우연히 Elastic{ON} 행사를 참가 하게 되었다.

Elastic{ON} 서울투어는 작년에도 진행 되었었으며, 무료로 참석할 수 있었다. 하지만 올해는 행사장 입장에 제한이 있었고, 약 6만원 정도를 써서 사전 예약을 했어야만 했다.(회사에서 지원해줬다)

요즈음 어디서나 쓸만한 Elasticsearch. 그 유명세 만큼이나 참석자도 많았던 것 같다.(처음 가보는 컨퍼런스라 그렇게 느꼈던 걸 수도 있겠지) 첨엔 어색어색 긴장긴장 쭈뼛쭈뼛 했지만 이도 시간이 지나니 차차 무뎌져 갔다.

행사장이 지하였는데 내려가자마자 빵을 먹고, 09:30분 부터 행사가 본격적으로 시작되었다.

여기서부터는

솔직히 내용들을 100% 이해하지 못했다. 아니 50%는 했으려나 ㅜㅜ

사실 나는 Elasticsearch에 대해서 실무나 프로젝트에서 사용해보기는 커녕 공부를 해보지도 않았다. 어제 급하게 인터넷으로 이것저것 찾아보고 Elasticsearch, logstash, firebeats, kibana 등을 알게 되고, 각 도구들이 어디에 쓰이는지와 index, type, mapping 등 Elasticsearch에 쓰이는 개념들을 학습했었다. 하지만 이런 초급지식으로 발표자들이 전하고자하는 것들을 캐치하기는 역부족이었던 것 같다. 

주로 오전에는 Elastic 현지 개발자들이 새로운 기능에 대한 소개를 강연하였다. APM, X-PACK, Hot-warm 아키텍쳐... 생소하디 생소하다. Elastic이라는 도구를 써보지 않았기에 감히 말하긴 그렇지만, 모든 기능들은 결국 Data분석이라는 것에 수렴하고 있는듯 했다. Data는 사람과 같이 태어나고 나이먹고, 폐기된다. 너무 기억에 남는 말이었다. 내가 조금 더 Elastic 도구들에 대한 경험이 있었고, 영어를 잘 들었더라면(?) 조금더 유익한 시간이 되지 않았을까 싶다.

호텔식 도시락을 먹고

오후 세션이 시작되었다. 오후에는 오전과 다르게 Elasticsearch를 사용해서 실제 기업들이 사용한 사례들에 대한 발표가 진행되었다. 

여전히 100% 이해하지는 못하였지만, 마이크로서비스 아키텍처를 사용한 프로젝트를 경험해봄으로써 오전보다는 더 유익한 시간이 되었던 것같다.

나는 groupA에 세션들을 들었으며 요약하자면

11번가

 BTOC 서비스 기업으로 트래픽 up은 곧 매출증가로 이어질 수 있다. 특히 11월 11일에는 서버를 증설해서 서비스 함으로써 평소보다 몇배의 매출을 올릴 수 있었다고 한다. 하지만 매년 증가하는 트래픽에 대응하는 과정에서 Oracle에 부하가 걸리기 시작했다. 당시 11번가는 우리나라기준에서 가장 거대한 오라클 DB를 사용하고 있었지만, RDB 클러스터링을 통한 이득은 그 임계치가 명확하여 Request/Response Driven Model의 아키텍처에서 Event Driven Model 아키텍처로 변경하게 되었고, 이 과정에서 처리시간, 유실등에 대한 모니터링이 필요하여 Elasticsearch를 도입하여 장애 탐지를 해낼수 있었다고 한다. 하지만 ELK를 경험하면서 얻은 것은 이러한 모니터링을 통한 장애 탐지 뿐만 아니었다. 수많은 수치화된 데이터와 시각화 자료를 이용해서 고객에 대한 needs에 직결되는 insight를 얻기도 하였다.

데브시스터즈

게임회사로서 서버의 로그 뿐만 아니라 클라이언트, web의 로그 데이터들도 수집하여 이슈탐지에 대응하였다. 

Beats lightweight data shippers. Logstash보다는 기능이 한정적이지만, 속도는 빨라서 그만큼 장점이 있었다.

Elasticsearh의 장점을 많이 느꼈따. 모든 로그들을 모아서 확인가능하며, 각각의 서버에 접속하지 않더라도 이슈를 탐지 해낼수 있었다. 또한 서버접근에 제한된 개발 엔지니어들도 Kibana를 통해서 열람이 가능하다는 점.

그리고 이러한 Elasticstack 인프라와 Logging 플랫폼을 코드로서 관리(Infrastructure as a Code)하기위해 Terraform을 도입하였고 Vault를 이용하여 패스워드 관리까지 하였다. 

ELK는 매우 쉽게 (준)고가용성 플랫폼을 구축할 수 있어서 추천한다.

등등 다른 회사들의 유익해보이는 Elasticsearch 사용사례들이 있었지만 넘어가도록하고...

사실 이 모든걸 들으면서 드는 생각은 아직 나는 내공이 부족하다는 것이다. 

그들의 사례을 들으며서 우리 회사, 팀의 프로젝트에서 적용할 만한 아키텍처가 있는지

Elasticsearch를 어떻게 지금 보다 더 잘 활용하여 무에서 유를 창조해낼수 있는지

잘 와닿지 않았다.

그래도 나름 좋은 경험이었고, Elasticsearch의 도구에 대한 궁금증과 데이터 분석에 대한 관심을 가지게 되었다.