그 동안의 근황

우선 2022년 크리스마스 시즌… 우리집의 실질적 지주 춘식이 굿즈가 6개 정도 늘었습니다.

더 많은 춘식이를 영접하러 판교에 있는 카카오 아지트 프렌즈샾에도 다녀왔고요.

2월 초에는 부여, 공주로 가족 여행을 다녀왔습니다.

그리고 미루고 있던 숙제인 작년 유럽 : 프랑스 - 네덜란드 여행 이야기도 유튜브에 전부 편집해서 올렸습니다. 하루에 한편씩 총 13편 입니다.

래밀리TV : 래밀리 가족 유럽 여행기 전체 재생목록 보기

그리고 개인적으로 가장 많은 시간을 들인… 작업실 리모델링을 했습니다. 약간(?)의 탕진잼을 하면서 이런 저런 공구들을 구입해서 벽에 전시도 해 보고, 오드로이드 클러스터도 구축 해 보려고 이런 저런 잡스러운 짓들을 해 봤습니다. 딱히 뭘 해보겠다 하는 목적은 없고요, 그냥 평소에 지르고 싶었던 소소한 것들, 어릴때 한번쯤 꿈꿨던 나만의 본부? 느낌으로 꾸며보고 싶었습니다.

그리고 하는 김에 이런 저런 소소한 작업들 기록 해 보려고 유튜브 채널도 하나 새로 파 봤습니다.

래밀대디TV 유튜브 채널

그리고 어쩌다 보니 저희 본가 가족들과 약 2년에 한번 꼴로 갔었던 알펜시아에 아이들 개학 전 마지막으로 다녀왔고요.

새로운 시작

커피챗 하면서 만난 분들 과의 감사한 시간 이후에도 몇몇 분들과의 순수한 고기 모임과, 개발자 분들의 소중한 네트워크 자리에도 초청 받아 감사하게도 좋은 시간을 보내기도 했습니다.
개인적으로 연락 주셔서 Elastic 관련해서 약간의 도움을 드리고자 만나 뵌 분들도 계셨고, 저명한 교수님께서 초청 해 주셔서 해외 있는 학생 분들께 온라인으로 강연을 할 기회도 있었습니다.

제가 쉬는 동안 기회를 주시고자 적지 않은 분들께서 연락을 주시고 만남을 가졌습니다.

• 약 절반 정도의 분들은 제가 가진 Elastic 기술, 지식 경험을 높이 평가하시고 그와 관련된 기회를 제안 해 주셨고
• 약 30% 정도의 분들은 Developer Advocate 경험을 값지게 생각 하시고 제안을 주셨습니다.
• 나머지 분들은 새로운 경험에 대한 제안 해 주셨고요.

매력적이지 않은 곳이 없었고, 전부 함께 하고 싶은 곳 뿐이었습니다. 한분 한분께 고개 숙여 다시 한번 깊이 감사드립니다.
합류 제안에 긍정적인 답변을 드리지 못한 분들께는 감사와 죄송한 마음에 다시 한번 고개 숙이며, 더 좋은 분들과 함께 계속 번창하시기를 진심으로 기원합니다.

3월 6일 부터 래블업(https://www.lablup.com) 에서 Developer Advocate / Developer Experience Engineer (DEX) 로 새로운 출발을 하게 되었습니다.

AI 분야는 저도 아직 생소하고 무지한 분야라 지금은 기대 보다는 걱정이 앞서는 것이 사실입니다. 제 인생의 큰 마일스톤이었던 Elastic 을 비우고 새로운 채움을 해 나가야 하는 것이 가장 큰 과제일 것 같습니다.
그럼에도 불구하고 AI 라는 거대한 흐름에 말석에라도 매달려 볼 수 있는 기회를 갖게 된 것도 참 감사한 일이라는 생각이 듭니다. 새로운 곳에서도 제 가치를 다시 증명 해 나갈 수 있는 시간이 될 수 있도록 새로 마음을 다잡고 열심히 해야겠습니다. :)

종민과의 커피챗 - Coffee Chat with Jongmin 포스트를 쓰고 SNS 에 공유한 뒤 많은 분들이 메일, 페이스북, 링크드인, 신청 폼 으로 커피챗 신청을 해 주셨습니다. 약 2주 동안 거의 매일 약속이 2~3 개씩 있어서 열심히 돌아다녔네요. 그 동안 집에서 재택 근무를 많이 하다가 오히려 이번 기회에 바깥에 많이 돌아다니니 체력적으로 많이 지치던게 느껴졌습니다. ㅎㅎ

구글이 알고리즘이 제 블로그랑 SNS를 반영한건지, 유튜브에 실제로 최근 실리콘 밸리의 Layoff 와 관련된 영상도 요즘 부쩍 눈에 띄더라고요.
당일 통보, 당일 해고. 그날의 이야기
구독도 안 한 처음 보는 분의 채널이었는데도 우연히 구글 알고리즘이 보여준 저 영상을 보고도 동병상련을 느끼기도 했습니다.

좋은 기회를 제안 해 주신 분들, 그냥 안부를 묻고 싶어서 만나뵌 분들, 아무런 교류가 없었는데 호기심에 신청 해 주셨던 처음 뵙는 분들, 정말 다양한 분들이 계셨습니다. 예술, 인공지능, 클라우드, 건축, 오픈소스, HR, 경영 등 다양한 분야에 계신 분들과 흥미로운 주제로 많은 이야기들을 나누었고, 시야와 생각이 좀 더 넓어지고 자유로워 지는 느낌을 많이 받았습니다. layoff 이후 우울해 질 수 있었던 시기에 시간 내어 주시고 자존감을 많이 높여주신 분들께 다시 한번 감사의 말씀을 드립니다.

이전 포스트에 올려두었던 소개자료(이력서) 를 보시고 다양한 제안을 해 주셨는데, 역시나 Tech Evangelist 포지션에 대한 제안이 제일 많았습니다. 어느 정도 팀과 제품이 완성이 되었는데 고객들의 눈높이에 맞춰 "우리 제품 정말 좋은데 이걸 말로 설명할 방법이 없네" 의 해결을 필요로 하신 분들이 계셨습니다. 그 밖에도 Elastic 기술과 데이터 분석 을 함께 해 보고자 하시는 분들도 계셨고요. 사실 예전부터 팀 관리나 작은 조직의 CTO 일도 해 보고 싶다는 생각도 있었는데 그와 관련한 이야기와 경험담도 나눠 주신 분들도 계셨습니다. 하나의 만남도 허투로 할 것이 없는 모두 소중한 시간들이었습니다.

다들 바쁘고 경제적으로도 많이 어려운 시기에 이런 배부른 이야기 하긴 죄송스럽지만 우선 지금은 잠시 쉬면서 스스로 정비를 하고 오랬동안 손 놓았던 코딩 공부도 좀 다시 해 볼 예정입니다. 여유가 되면 개인적으로 프로젝트도 한번 해 보고요.
아이들 겨울 방학 동안은 가족과 함께 보내고 2023년 2월 중순에서 말 정도 즈음에 일 시작하면 좋겠다 생각 하는 중입니다. 그 중에도 제안 주셨던 분들께는 다시 또 찾아뵙고 인사 드리고 하겠습니다.

날씨도 경제도 많이 얼어붙어서 몸도 마음도 추운 시기입니다. 모두들 힘들지만 기운내시고 행복한 연말, 힘찬 새해 맞으시길 바랍니다. 🥰

연말 동안 느긋하게 시간을 갖고 새로운 곳에 가 보고 사람들을 만나며 그동안 우물 안에 갇혀 있던 생각들을 넓혀보려고 합니다.
During the end of the year days, I am going to spend some time to relax, visit new places, meet people, and wide up my thoughts and minds that have been stuck in the well.

저에 대한 소개 자료입니다. 표준 이력서 형식이 아니라 생각의 흐름대로 정리 해 보았습니다. 표준 형식의 이력서는 커피챗 이후 마음이 결정되면 필요한 내용으로 작성 해 드리겠습니다.
This is an introduction about me. Rather than a standard resume format, I wrote it according to the flow of thought. If resume in standard format needed, I will write with necessary content after the coffee chat.

• 김종민 소개자료 - 한국어
• Resume in English - Google translated from Korean and didn’t inspected yet. Some sentences may not clear.

제 커피챗 일정은 잡히는 대로 아래 캘린더에 업데이트 해 놓겠습니다. 필요하시면 참고하세요.
I will update my schedule at calendar below once planned. Please refer if necessary

신청은 편하신 채널로 주시거나
You can make contact through convenient channel for you.

• Facebook : https://www.facebook.com/kimjmin81
• Linkedin : https://www.linkedin.com/in/kimjmin
• Twitter : https://twitter.com/kimjmin
• Email : kimjmin@gmail.com

아래 폼을 입력 해 주시면 제가 연락 드리겠습니다.
Or you may submit form below. I will make contact to you.

갑작스럽게 Elastic 을 떠나게 되었습니다.

실리콘밸리의 추운 감원 바람이 Elastic 에도 불어오게 되면서 12월 1일 13% 의 인력을 감축하게 된다는 CEO 의 발표가 있었습니다.
https://www.elastic.co/blog/ceo-ash-kulkarni-email-to-elastic-employees

저희 Community 팀 대다수 인원들 또한 대상이 되어 저 역시 Elastic 을 갑작스레 떠나게 되었습니다.

Elastic 이라는 회사가 제게 어떤 의미였는지 개인적으로 저를 아시는 분들은 아마도 다 알고 계실거라 생각됩니다. 2015년 6월 저의 생일날 합류하게 되어 (Elastic 입사 이야기) 7년 6개월간 몸담으며 제 인생에 있어서 황금기라고 말할 수 있는 시기를 보내게 해 준 회사였고, 저에게 한없이 부푼 꿈과 행복을 안겨준 회사였습니다.

처음 통보를 받았을 때는 잠깐 정신이 멍했습니다. 우선 사설 채널로 한국 팀 동료분들께 상황을 설명드리고 일단 무엇부터 해야 하나 차분히 생각하기 시작했습니다.

그 와중에도 제일 먼저 생각난 것은 당장 다음주 부터 참석하기로 했던 행사들은 어쩌지 하는 생각이 먼저 들면서 (저도 어쩔 수 없는 대한민국 직장인인가봅니다) 행사 담당자분들께 참여가 불가능하게 되어 죄송하다는 메일과 단톡 메세지들을 먼저 전달했습니다. 그리고 나서 업무적으로 관계가 있던 생각나는 가까운 몇몇 분들께도 연락을 드렸습니다.

그런 후에야 앞으로 어떻게 될 지를 설명하는 HR 팀 메일을 차근 차근 읽어보기 시작했습니다. 회사 내부 정보에 접속할 수 있는 대부분 채널들은 이미 종료 된 상태이고, 이메일과 캘린더는 24시간 동안은 유지될 예정이니 처리 못한 expense 등을 처리하라는 내용 등이 있었습니다. 짧게 진행된 (새로 예정되었을) 매니저와의 콜에서도 회사 상황이 이렇게 되었다 라는 이야기만 들으며 상황만 전달 받고 콜을 마쳤습니다.

보도가 나간 사이 페이스북과 링크드인 그리고 개인 메일로 현/전 직장 동료들로부터 수많은 격려와 안부의 메시지를 받았습니다. 위로의 말도 있었고 축하의 말도 있었습니다. 한국 동료분들은 전화 주셔서 아직 기회는 있을테니 힘내라는 격려를 해 주셨고, 하루 짧은 시간 동안 당황 -> (아주 짧은)걱정 -> (매우 긴)감사 의 시간을 보냈습니다.

우선 24시간 내에 정리해야 할 것들이 있어 첫날은 정신 없이 정리 할 것들을 정리했습니다. 둘째날인 금요일에 링크드인에 상황을 남겼고 여기에도 많은 전 동료들이 위로의 반응을 남겨주어 큰 위로를 받았습니다.

저녁에 참석하기로 했던 데브릴 나이트도 상황이 이렇게 됬는데 가야 하나? 잠깐 고민했지만, 오랬만에 반가운 분들의 얼굴을 보고 싶어 마음먹고 참석했습니다. 아쉽게도 가져가려던 스티커와 스웨그는 못 가져가게 되었지만 참석해서 만난 분들께는 상황을 설명을 드렸고 마찬가지로 큰 위로의 시간을 얻고 왔습니다.

이제 다음 행보를 준비해야 하는데 레쥬메 정리는 시간이 걸릴것 같아 우선 다른 분들께도 이제 상황을 알려드려야 할 것 같아서 블로그를 먼저 쓰게 되었습니다.

서두에 말씀드렸지만 Elastic 이라는 조직, 제품, 사람들은 제 인생에 있어 정말 큰 선물과도 같았습니다. 국제적으로 어려운 경제 상황 때문에 어쩔 수 없는 작별을 하게 되었지만 평생 제 인생에 큰 행복의 기억으로 남아있을 것입니다. 조직을 떠나게 되어도 커뮤니티와의 인연은 가능한 한 계속 유지 할 생각입니다.

그 동안 제 실력보다는 Elastic 이라는 브랜드를 등에 업고 활동 한 것이 많았고, 반대로 Elastic 역시 제가 했던 활동들을 기반으로 김종민 이라는 브랜드를 이용해서 한국에서의 입지를 넓혀갔던지라, 저와 Elastic 은 뗄레야 떼기 힘든 관계였습니다. 아마 이런 상황이 아니었다면 제 스스로 Elastic 의 문을 열고 새로운 곳으로 나가기는 힘들었겠지요. 이 뜻밖의 상황이 오랬만에 눈을 돌려 바깥 세상도 다시 한번 돌아보고, Elastic 이라는 브랜드를 떼어낸 김종민 이라는 개인이 얼마나 평가받을 수 있는 사람인지도 시험 해 볼 수 있는 기회가 됬다고 생각하니 오히려 홀가분해지고 살짝 기운도 납니다.

그 동안 Elastic 을 통해 했던 유니크한 경험들

• 커뮤니티 활동 경력을 기반으로 리모트 입사
• 국내 커뮤니티 회원 0 -> 8k / 국내 직원 0 -> 00 / 국내 고객 0 -> 000
• 수백명이 모인 컨퍼런스에서의 발표. 제 사회 초년때의 버킷리스트 중 하나가 100명 앞에서 발표하기였습니다.
• 제 영상과 블로그를 보고 공부해서 취업에 성공했다는 주니어 엔지니어분의 감사 메일
• 커뮤니티에서 발굴해서 Elastic 에 입사해 제 덕분에 Elastic 에서 자신이 꿈꾸던 삶을 시작할 수 있게 되었다고 말씀 해 주신 직원분
• Elastic 입사 당시 국내에는 손에 꼽을 정도로 적었던 DevRel 직군이 이제는 수십명이 모여 밋업을 할 정도로 성장한 대한민국의 DevRel 문화
• 멘토링을 통해 Elastic 글로벌 컨퍼런스에서 온라인 발표 경험을 제공 해 드린 대학생 분들
• 마지막으로 실리콘밸리의 감원 칼바람(?) 을 맞아본 경험 (역시 매우 소중하게 생각합니다)

들은 어디를 가던 간에 평생 잊지 못할 제 믿거름이 될거라 믿습니다.

지금 또 드는 생각이, 그 동안 감사하게 꾸준히 참여 해 왔던 커뮤니티 컨퍼런스

• 파이콘 (2016~)
• 데이터야놀자 (2018~)
• 한국 커뮤니티 데이 (2016~)
• 올해 처음 참석한 우부콘

리더 분들께는 앞으로 Elastic 의 참여는 어렵게 되서 죄송한 마음이 드네요. 아마 아시아 커뮤니티 팀 전체가 정리가 되어서 당분간은 저 대신 지원 할 사람도 없는 상황일겁니다.

당분간은 쉬면서 생각도 정리하면서 여유를 갖고 시간을 좀 보내려고 합니다. 오히려 그동안 코로나도 있고 해서 재택하느라 집에만 있었는데, 일부러 밖에도 자주 나가서 기운을 차려야 할 것 같습니다. 커피챗 해 주실 분들 편하게 연락주세요. 😁

I left Elastic abruptly

As Silicon Valley’s cold winds of layoff also blew to Elastic, the CEO announced on December 1st that Elastic is reducing 13% of workforce.
https://www.elastic.co/blog/ceo-ash-kulkarni-email-to-elastic-employees

My community team has also been targeted and I recently had to leave Elastic.

Those of you who know me personally probably know what the company Elastic meant to me. I joined on my birthday in June 2015 (History of Joining Elastic), and it was a company that allowed me to spend a period that can be called a golden age in my life for 7 years and 6 months. Elastic gave me unlimited dreams and happiness.

When I notified, I was momentarily stunned. First, I explained the situation to my Korean teammates through a private channel, and I started thinking about what need to be done first.

In the meantime, the first thing that came to my mind was the events I was supposed to attend from next week (I guess I’m a Korean worker who can’t help it), so I sent emails and chat messages to organizers of the events to apologize for not being able to participate. Then, I text to a few people close to me who I had a business relationship with.

After that, I started reading through the email from HR team explaining what going to be happened next. Most of working channels and accesses of the company’s internal information have already been terminated. Only email calendar system will be maintained for 24 hours, so there was a message to process expenses that could not be processed and handle other things need to be done. Short zoom call with new team leader (Team was recently re-orgaznied) was scheduled. At the call, I just was told of company situation and general informations and ended up shortly.

After the public announcement, I received numerous messages of encouragement and regards from current and former colleagues through Facebook, LinkedIn, and personal mail. There were words of encorage and words of congratulations. My Korean colleagues called me, encouraged me to cheered me up with words of hope. My day passed with moments of embarrassment -> (short) worrying -> (long) gratitude.

First of all, there are things that need to be handled out within 24 hours, so the first day was hectic. On Friday (the second day), I left my situation on LinkedIn also many former colleagues left consoling responses, giving great comfort.

I bit hasitated with DevRel Night event, which was supposed to attend that evening. I am in situation like this, should I go? I thought about it for a bit, and I decided to attend because wanted to see people’s in face who hadn’t seen for a long time. Unfortunately, I couldn’t bring the stickers and swag that I wanted to share. I explained the situation to the people I met there and I got a great time of comfort as well.

Now I need to prepare for my next move, but resume update will take some time. First of all, I decided to let others know about my current situation, so I am writing this blog first.

As I said for the first, the organization, product, and people of Elastic have been a great gift for my life. I had to say goodbye because of world wide economical situation, but it will remain as a memory of great happiness for the rest of my life. Even if I leave the organization, I plan to keep my relationship with the community as long as possible.

In the meantime, many my activities been done with the brand Elastic I am sitting on the shoulder rather than my own capabilities. And also Elastic was using the name of Kim Jongmin’s (which is me) value to expand its presence in Korea. It meant me and Elastic were inseparable. If it weren’t like this, it will never happened for me to open out the door of Elastic on my own and walk away. I am thinking in good way that this unexpected situation was an opportunity to look around the outside world once again after a long time, and to test how much individual Kim Jongmin, who step down from shoulder of Elastic, can be evaluated by himself.

Unique experiences I had with Elastic so far

• Get hired as remote employment with background of community activity experience
• Raised local community members 0 -> 8k / employees 0 -> 00 / customers 0 -> 000
• Spoke at conference sessions with hundreds of people. One of my bucket lists in my early years was speaking in front of 100 people.
• Got thank you email from a junior engineer who informed that he made getting a job after watching my videos and blogs and studied with it.
• Local employees who discovered from the community and joined Elastic and thanked to me, he was able to start a new life in Elasitc which he was looking for.
• Korea’s DevRel culture has grown to such an extent that dozens of DevRel positions, which were very few and hard to find in Korea at the time of joining Elastic, are now gathering and holding meetups.
• College students who provided online presentation experience at the Elastic Global Conference through my mentoring.
• Finally, the experience of being layed off in Silicon Valley way. (I truly think it is very precious experience)

I believe that wherever I go, these will be a valuable source of nutrient for me.

And one thing is hitting my brain, about the community conferences that I have been gratefully participating in.

• PyCon (2016~)
• Datayanolja (Play Data) (2018~)
• Korea Community Day (2016~)
• Ubucon (attended for the first time this year)

To organizers, I feel sorry that it will be difficult for Elastic to be sponsor in the future. Most asian community folks has left, so there will be no one to support for sponsoring in the future.

For the time being, I’m going to take a break, organize my thoughts, and will spend some time. Rather, I’ve been staying at home most time (becuase of COVID), now I need to go outside to see people and refresh and wide up my mind. If you would like to have a coffee chat with me, please feel free to contact. 😁

서울시 지하철 승하차인원 대시보드 v3 - 1. 데이터 색인
서울시 지하철 승하차인원 대시보드 v3 - 2. 대시보드 생성

지난 시간에 저장한 데이터를 가지고 이번에는 Kibana 대시보드를 만들었습니다. 이 포스트에서 Kibana 대시보드 만드는 방법을 하나 하나 설명하지는 않습니다. 자세한 내용은 위 영상에 설명되어 있으니, 영상을 보시면서 차근 차근 따라 해 보시기 바랍니다.

완성된 대시보드는 아래 링크로 가면 직접 실행 해 보실 수 있습니다.

• 서울시 지하철 승하차인원 대시보드

이 외에도 앞으로 다양한 데모들을 로그인 없이 공개적으로 볼 수 있게 계속 만들어 나갈 계획입니다.

• Elastic 한국 커뮤니티용 Kibana 데모 모음 : https://ela.st/demo-kr

만약에 공유하실 수 있는 좋은 데모가 있으신 분들은 위에 kibana 데모 모음 화면의 계정 신청 링크에서 신청하시고 함게 만들어 주시면 감사드리겠습니다.

서울시 지하철 승하차인원 대시보드 v3 - 1. 데이터 색인
서울시 지하철 승하차인원 대시보드 v3 - 2. 대시보드 생성

제가 Elastic Stack 을 처음 시작할 때 부터 사골처럼 우려먹고 있는 예제가 있습니다. 그런데 아직도 이것보다 좋은 예제 데이터셋을 찾지를 못했네요.

바로 서울시 지하철 승하차인원 대시보드입니다.

2015년 EMOCON 에서 처음 발표한 버전 (Elasticsearch 2.x, Kibana 4.x)

• ELK 스택을 사용한 서울시 지하철 대시보드 만들기

2019 년에 3편으로 나누어 다시 녹화한 시리즈 버전 (Elastic Stack 7.x)

• Elastic Stack을 이용한 서울시 지하철 대시보드 다시 만들기 #1
• Elastic Stack을 이용한 서울시 지하철 대시보드 다시 만들기 #2
• Elastic Stack을 이용한 서울시 지하철 대시보드 다시 만들기 #3

이 대시보드를 Elastic Stack 새 버전으로 다시 만들어보려고 합니다. 내용이 길어질 것 같아 이 포스트에서는 데이터 색인 부분만 다루도록 하겠습니다.

데이터 소스 파일

그 동안 소스 데이터는 서울시 공공데이터 포털에서 제공하는

• 서울시 역코드로 지하철역 위치 조회
• 서울교통공사 지하철 역명 다국어 표기 정보
• 서울교통공사 연도별 일별 시간대별 역별 승하차 인원

등의 json, csv 데이터를 받아 여기에서 Elasticsearch 에 색인하기 적합한 모양으로 변환하는 프로그램 을 만들어 사용하고 있었습니다.
그런데 언제부터인가 서울시 공공데이터 포털에서 위 데이터들이 사라져서 찾을수가 없습니다. 또 서울교통공사 홈페이지에서 제공하는 데이터도 어떤 년도는 xlsx 어떤 년도는 csv 처럼 파일 형식이 통일되어 있지도 않고, 컬럼도 어떤년도는 날짜가 A열에 있고 어떤 년도는 A열에 역 코드가 있는 등 데이터 좀 뒤죽박죽 아쉽게 되어 있었습니다.

그래서 제가 이전에 만들었던 데이터들을 기반으로 하여 좀 더 다양한 데이터들을 찾아서 추가하고, 형식을 통일한 뒤 배포하기 쉬운 형태로 제작해서 직접 배포하기로 결정했습니다.

소스 파일은 아래의 캐글(Kaggle) 페이지에 있습니다. 내려받으려면 캐글 계정이 필요합니다.
https://www.kaggle.com/datasets/kimjmin/seoul-metro-usage

서울 지하철 승하차인원 대시보드는 그냥 보여주는 용도가 아니라, 항상 Elastic 을 처음 시작하시는 분들이 처음부터 쉽게 따라서 만들어 볼 수 있는 튜토리얼을 제공하는 것이 목적이기 때문에 소스 파일에 다 넣어놓지 않고 색인 때 다양한 과정을 통해 데이터를 제대로 만들어 가도록 했습니다. (캐글에서 제공하는 용량이 한정적이기도 했고요)

제공하는 파일들은 다음과 같습니다.

seoul-metro-station-info.csv

서울 지하철 역별 메타정보 파일입니다. 사이즈는 약 85KB 이고 1~8호선 총 286 개의 역 정보가 저장되어 있습니다.
각 행의 정보는 다음과 같습니다.

• station.code : 역 내부 코드 - 각 로그 파일의 station_code 와 연결되는 키값 (238)
• station.fr_code : 역 공개 코드 (211-2)
• line.num : 호선 number (2)
• line.name : 호선 text (2호선)
• line.name_sub : 세부 호선 text (을지로순환선) - 2호선 처럼 한 호선이 을지로순환선, 성수지선 처럼 또 나눠진 것을 구분하기 위한 정보입니다.
• line.station_seq : 호선별 역 순번 (23) - 나중에 지도에 각 호선을 연결하여 그릴 때 사용하기 위한 호선별 순번입니다. station.code 는 역이 생긴 순서대로 매겨지기 때문에 예를 들어 두 역 사이에 나중에 역이 추가된다면 순번이 24 - 29 - 25 처럼 되어 버려서 지도에 그릴때 직선이 뒤죽박죽이 되어 버립니다.
• station.name_full : 역명 전체 (서울대입구(관악구청))
• station.name : 역명 “|” 로 구분 (서울대입구|관악구청) - 나중에 이 역을 [“서울대입구”, “관악구청”] 같이 배열로 저장하기 위해 구분 한 것입니다.
• station.name_chc : 역명 한자 (서울大入口(冠岳區廳))
• station.name_chn : 역명 중국어 (首尔大学(冠岳区厅))
• station.name_en : 역명 영어 (Seoul Nat‘l Univ. (Gwanak-gu Office))
• station.name_jp : 역명 일본어 (ソウルデイック)
• geo.latitude : 좌표계 위도 (37.481247)
• geo.longitude : 좌표계 경도 (126.952739)
• geo.sigungu_code : 시군구코드 (11210) - Elastic Map Service 를 이용해서 표현하기 위한 값입니다.
• geo.sigungu_name : 시군구명 (관악구)
• geo.addres_road : 역 도로명 주소 (서울특별시 관악구 남부순환로 지하1822(봉천동))
• geo.address_land : 역 지번 주소 (서울특별시 관악구 봉천동 979-2 서울대입구역(2호선))
• geo.phone : 역 대표 전화번호 (02-6110-2281)

seoul-metro-2015.logs.csv ~ seoul-metro-2021.logs.csv

년도별 지하철 승하차 인원 집계 파일입니다. 각 파일의 사이즈는 100MB 를 넘지 않도록 했습니다. 이렇게 하면 Filebeats 나 Logstash, Elastic Agent 를 사용하지 않고 Kibana 에서 직접 파일 업로드 기능을 이용해서 색인 할 수 있습니다. (제한 100MB)
각 행의 정보는 다음과 같습니다.

• timestamp : 타임스탬프, 매 시작 정각값이며 ISO8601 형식으로 되어 있습니다 (2015-01-02T00:00:00.000+09:00)
• station_code : 역 내부 코드 - seoul-metro-station-info.csv 의 station.code 에 대입합니다. (151)
• people_in : 승차인원 (281)
• people_out : 하차인원 (311)

이제 캐글 페이지 에서 Download 버튼을 눌러 소스들을 다운로드 합니다.

seoul-metro-station-info.csv 색인

이제 먼저 seoul-metro-station-info.csv 파일을 색인하겠습니다. 먼저 사용할 Elasticsearch 와 Kibana 를 준비합니다. Elastic Cloud 를 사용하여도 되고 직접 설치한 클러스터가 있으면 그것을 사용해도 됩니다.
간편하게 Kibana 의 Data Visualizer 의 파일 업로드 기능을 이용해서 색인 하겠습니다. Machine Learning 메뉴에서 File 을 선택하면 됩니다. 참고로 머신러닝 기능이지만 Basic 무료 라이센스에서 사용 가능합니다.

이제 seoul-metro-station-info.csv 파일을 드래그 & 드롭 하거나 파일찾기를 이용해서 업로드를 하면 Data Visualizer 가 파일을 읽어들여 필드명과 매핑을 적절하게 설정 해 줍니다. 업로드를 한 다음에 import 버튼을 클릭합니다.

우선은 기본 설정으로 색인을 한 뒤 필요한 부분은 _reindex API 를 이용해서 다시 하도록 하겠습니다. Data View 는 생성하지 않도록 create data view 는 체크를 해제 하고 색인할 인덱스 이름은 seoul-metro-station-info-temp 로 하겠습니다.
이제 import 버튼을 눌러 업로드 한 파일의 색인을 시작합니다.

285 개의 서울시 역 정보 도큐먼트 색인이 모두 끝났습니다.

Dev Tools 에서 데이터가 제대로 들어갔는지 확인 해 보겠습니다.

seoul-metro-station-info 매핑 설정

데이터는 잘 들어갔지만 매핑을 손보아야 합니다. seoul-metro-station-info 인덱스를 만들면서 매핑을 아래와 같이 추가합니다.

PUT seoul-metro-station-info
{
  "mappings": {
    "properties": {
      "geo": {
        "properties": {
          "addres_road": { "type": "text" },
          "address_land": { "type": "text" },
          "latitude": { "type": "float" },
          "longitude": { "type": "float" },
          "phone": { "type": "text" },
          "sigungu_code": { "type": "keyword" },
          "sigungu_name": { "type": "keyword" },
          "location": { "type": "geo_point" }
        }
      },
      "line": {
        "properties": {
          "name": { "type": "keyword" },
          "name_sub": { "type": "keyword" },
          "num": { "type": "byte" },
          "station_seq": { "type": "byte" }
        }
      },
      "station": {
        "properties": {
          "code": { "type": "short" },
          "fr_code": { "type": "keyword" },
          "name": { "type": "keyword" },
          "name_chc": { "type": "keyword" },
          "name_chn": { "type": "keyword" },
          "name_en": { "type": "text" },
          "name_full": { "type": "keyword" },
          "name_jp": { "type": "keyword" }
        }
      }
    }
  }
}

필드 구조 정리를 위한 ingest pipeline

루트에 있는 필드들을 geo, line, station 필드의 하위 필드로 적절하게 나누어 저장을 할 것입니다. seoul-metro-station-info-temp 인덱스의 도큐먼트들을 seoul-metro-station-info 로 재색인 할 때 사용할 ingest pipeline 을 다음과 같이 입력합니다.

PUT _ingest/pipeline/seoul-metro-station-pipe
{
  "processors": [
    { "set": { "field": "_id", "value": "{{station_code}}" } },
    { "set": { "field": "geo.location.lon", "value": "{{geo_longitude}}" } },
    { "set": { "field": "geo.location.lat", "value": "{{geo_latitude}}" } },
    { "convert": { "field": "geo.location.lon", "type": "float" } },
    { "convert": { "field": "geo.location.lat", "type": "float" } },
    { "split": { "field": "station_name", "separator": "\\|" } },
    { "split": { "field": "line_name_sub", "separator": "\\|" } },
    {"rename": { "field": "geo_addres_road", "target_field": "geo.addres_road" } },
    {"rename": { "field": "geo_address_land", "target_field": "geo.address_land" } },
    {"rename": { "field": "geo_latitude", "target_field": "geo.latitude" } },
    {"rename": { "field": "geo_longitude", "target_field": "geo.longitude" } },
    {"rename": { "field": "geo_phone", "target_field": "geo.phone" } },
    {"rename": { "field": "geo_sigungu_code", "target_field": "geo.sigungu_code" } },
    {"rename": { "field": "geo_sigungu_name", "target_field": "geo.sigungu_name" } },
    {"rename": { "field": "line_name", "target_field": "line.name" } },
    {"rename": { "field": "line_name_sub", "target_field": "line.name_sub" } },
    {"rename": { "field": "line_num", "target_field": "line.num" } },
    {"rename": { "field": "line_station_seq", "target_field": "line.station_seq" } },
    {"rename": { "field": "station_code", "target_field": "station.code" } },
    {"rename": { "field": "station_fr_code", "target_field": "station.fr_code" } },
    {"rename": { "field": "station_name", "target_field": "station.name" } },
    {"rename": { "field": "station_name_chc", "target_field": "station.name_chc" } },
    {"rename": { "field": "station_name_chn", "target_field": "station.name_chn" } },
    {"rename": { "field": "station_name_en", "target_field": "station.name_en" } },
    {"rename": { "field": "station_name_jp", "target_field": "station.name_jp" } },
    {"rename": { "field": "station_name_full", "target_field": "station.name_full" } }
  ]
}

이제 seoul-metro-station-info-temp 인덱스의 도큐먼트들을 seoul-metro-station-info 로 재색인 합니다.

POST _reindex
{
  "source": {
    "index": "seoul-metro-station-info-temp"
  },
  "dest": {
    "index": "seoul-metro-station-info",
    "pipeline": "seoul-metro-station-pipe"
  }
}

아래와 같이 285 개의 도큐먼트가 created 되었다는 메시지가 나오면 성공입니다.

재색인 작업이 끝났으면 seoul-metro-station-info-temp 인덱스와 seoul-metro-station-pipe 인제스트 파이프라인은 삭제하셔도 됩니다.

DELETE seoul-metro-station-info-temp
DELETE _ingest/pipeline/seoul-metro-station-pipe

데이터 확장을 위한 스크립트 작업

승하차인원 집계 로그 데이터를 색인하면서 다양한 변환 작업을 해 줄 것이기 때문에 이를 위한 준비를 먼저 해보도록 하겠습니다.

hour_and_week 스크립트

나중에 만들 대시보드에 아래와 같이 요일별, 시간대별 값을 보는 차트를 만들 것입니다.

그러기 위해서는 쿼리 시점에서 timestamp 필드값에서 요일과 시각 정보를 만드는 것 보다 미리 별도의 시각값과 요일값 필드를 만들어 각 도큐먼트에 넣어 두는 것이 성능이나 자원 활용 면에서 여러가지로 유용합니다. timestamp 필드로부터 요일과 시각 정보를 추출해서 저장하는 스크립트를 만들고 _scripts 에 hour_and_week 라는 이름으로 미리 저장을 하겠습니다.

PUT _scripts/hour_and_week
{
  "script": {
    "lang": "painless",
    "source": """def ts=ctx[params['dateTimeField']];
def sdf=new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS");
def date=sdf.parse(ts);
def cal=Calendar.getInstance();
cal.setTime(date);

ctx[params['hourOfDayField']]=cal.get(Calendar.HOUR_OF_DAY);

def dowNum=cal.get(Calendar.DAY_OF_WEEK)-1;
def dowEn=["Sun","Mon","Tue","Wed","Thu","Fri","Sat"][dowNum];
def dowKr=["일","월","화","수","목","금","토"][dowNum];

ctx[params['dayOfWeekField']]=["num":dowNum, "en":dowEn, "kr":dowKr];"""
  }
}

이 스크립트에 사용되는 파라메터 3가지는 다음과 같습니다.

• dateTimeField : 시각과 요일 정보를 추출할 date 타입의 필드명
• hourOfDayField : 시각 값을 저장할 필드명
• dayOfWeekField : 날짜 값을 저장할 필드명

이 스크립트를 테스트 하기 위해서 임시로 ingest pipeline 을 만들어봅니다. 이름은 temp_hourAndWeek 으로 했습니다.

PUT _ingest/pipeline/temp_hourAndWeek
{
  "processors": [
    {
      "script": {
        "id": "hour_and_week",
        "params": {
          "dateTimeField": "timestamp",
          "hourOfDayField": "hour_of_day",
          "dayOfWeekField": "day_of_week"
        }
      }
    }
  ]
}

POST _ingest/pipeline/temp_hourAndWeek/_simulate
{
  "docs": [
    {
      "_source": {
        "timestamp": "2022-07-01T12:00:00.000+0900"
      }
    }
  ]
}

{
  "docs" : [
    {
      "doc" : {
        "_index" : "_index",
        "_id" : "_id",
        "_source" : {
          "hour_of_day" : 12,
          "timestamp" : "2022-07-01T12:00:00.000+0900",
          "day_of_week" : {
            "en" : "Fri",
            "num" : 5,
            "kr" : "금"
          }
        },
        "_ingest" : {
          "timestamp" : "2022-07-02T05:25:30.495605395Z"
        }
      }
    }
  ]
}

enrich pipeline process

승하차인원 집계 로그 파일이 색인될 때 앞서 만든 seoul-metro-station-info 인덱스의 정보를 가져와 조인 할 수 있도록 enrich 프로세서를 포함하는 인제스트 파이프라인을 만들겠습니다. 자세한 사용 방법에 대한 설명은 공식 도큐먼트의 Enrich your data 페이지를 참고하시기 바랍니다.

먼저 enrich policy 를 만들어야 합니다. seoul-metro-station-info 인덱스에서 station.code 필드와 일치하는 도큐먼트를 가져와 병합하는 seoul-metro-info_policy 를 만들고 활성(_execute) 해 줍니다.

PUT /_enrich/policy/seoul-metro-info_policy
{
  "match": {
    "indices": "seoul-metro-station-info",
    "match_field": "station.code",
    "enrich_fields": [ "line", "station", "geo" ]
  }
}

POST /_enrich/policy/seoul-metro-info_policy/_execute

방금 만든 seoul-metro-info_policy 의 enrich 프로세서를 포함하는 인제스트 파이프라인을 만들고 문서를 테스트 해 봅니다.

PUT _ingest/pipeline/seoul-metro-logs-pipe
{
  "processors": [
    {
      "enrich": {
        "policy_name": "seoul-metro-info_policy",
        "field": "station_code",
        "target_field": "info"
      }
    }
  ]
}

POST _ingest/pipeline/seoul-metro-logs-pipe/_simulate
{
  "docs": [
    {
      "_source": {
        "@timestamp": "2015-01-01T05:00:00.000+09:00",
        "station_code": 150,
        "people_in": 441,
        "people_out": 392
      }
    }
  ]
}

아래와 같이 데이터가 확장 되었으면 성공입니다.

enrich, hour_and_week, date 파이프라인

이제 앞에서 만든 enrich 프로세서와 hour_and_week 스크립트, 그리고 그 외 필요한 프로세서들을 포함하는 seoul-metro-logs-pipe 파이프라인을 만듭니다. 앞에 만든 파이프라인과 이름이 중복되어도 덧씌워지기 때문에 상관 없습니다.

PUT _ingest/pipeline/seoul-metro-logs-pipe
{
  "description": "Ingest pipeline for seoul-metro-logs-%{+YYYY} index",
  "processors": [
    {
      "enrich": {
        "policy_name": "seoul-metro-info_policy",
        "field": "station_code",
        "target_field": "info"
      }
    },
    {
      "script": {
        "id": "hour_and_week",
        "params": {
          "dateTimeField": "timestamp",
          "hourOfDayField": "hour_of_day",
          "dayOfWeekField": "day_of_week"
        }
      }
    },
    { "rename": { "field": "info.geo.sigungu_name", "target_field": "geo.sigungu_name" } },
    { "rename": { "field": "info.geo.sigungu_code", "target_field": "geo.sigungu_code" } },
    { "rename": { "field": "info.geo.location", "target_field": "geo.location" } },
    { "rename": { "field": "info.station", "target_field": "station" } },
    { "rename": { "field": "info.line", "target_field": "line" } },
    { "date": { "field": "timestamp", "formats": [ "ISO8601" ], "timezone" : "Asia/Seoul" } },
    { "remove": { "field": [ "info", "station_code", "timestamp" ] } }
  ]
}

seoul-metro-logs-pipe 파이프라인은 다음과 같은 작업들을 합니다.

• enrich : seoul-metro-info_policy 인덱스에서 가져온 정보들을 info 필드의 하위에 넣습니다.
• script : @timestamp 필드로부터 hour_of_day, day_of_week 정보를 추출해서 입력합니다.
• rename : enrich 에서 가져온 info.geo, info.line, info.station 필드들을 바깥으로 옮깁니다.
• remove : 필요 없어진 info 필드와 중복 값을 가진 station_code 를 삭제합니다.

이제 다시 도큐먼트를 넣고 테스트를 해 봅니다.

seoul-metro-%{+YYYY}.logs.csv 색인

seoul-metro-station-info 매핑 설정

이제 seoul-metro-logs* 형식을 가진 인덱스가 색인될 때 자동으로 매핑을 적용할 인덱스 템플릿을 만들겠습니다.

PUT _index_template/seoul-metro-logs_template
{
  "index_patterns": [ "seoul-metro-logs*" ],
  "template": {
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "year": { "type": "integer" },
        "people_in": { "type": "integer" },
        "people_out": { "type": "integer" },
        "hour_of_day": { "type": "byte" },
        "day_of_week": {
          "properties": {
            "en": { "type": "keyword" },
            "kr": { "type": "keyword" },
            "num": { "type": "byte" }
          }
        },
        "geo": {
          "properties": {
            "sigungu_code": { "type": "keyword" },
            "sigungu_name": { "type": "keyword" },
            "location": { "type": "geo_point" }
          }
        },
        "line": {
          "properties": {
            "name": { "type": "keyword" },
            "name_sub": { "type": "keyword" },
            "num": { "type": "byte" },
            "station_seq": { "type": "byte" }
          }
        },
        "station": {
          "properties": {
            "code": { "type": "short" },
            "fr_code": { "type": "keyword" },
            "name": { "type": "keyword" },
            "name_chc": { "type": "keyword" },
            "name_chn": { "type": "keyword" },
            "name_en": { "type": "keyword" },
            "name_full": {
              "type": "keyword",
              "fields": {
                "nori": { "type": "text", "analyzer": "nori" }
              }
            },
            "name_jp": { "type": "keyword" }
          }
        }
      }
    }
  }
}

logstash 필터 설정

실시간 로그 수집은 Filebeats 또는 Elatic Agent 등이 잘 되어 있지만 간단한 커스텀 데이터를 색인하는 데에는 Logstash 가 아직까지는 수월합니다. Logstash 로 파일에서 데이터를 수집해서 csv 형식을 파싱하고 elasticsearch 로 내보내도록 다음과 같이 config 설정 파일을 만들어주도록 하겠습니다.

처음에는 output 을 stdout { } 으로 테스트 하면서 데이터가 제대로 확장되었는지 확인하고 나중에 elasticsearch { } 로 변경하는 것이 좋습니다.

input {
  file {
    path => "/Users/kimjmin/elastic/source/seoul-metro/seoul-metro-*.logs.csv"
    start_position => "beginning"
    sincedb_path => "/dev/null"
  }
}

filter {
  # csv 파싱
  csv {
    source => "message"
    skip_header => true
    columns => [ "timestamp", "station_code", "people_in", "people_out" ]
  }
  # timestamp 필드로부터 year 값 추출.
  mutate {
    copy => { "timestamp" => "year" }
  }
  mutate {
    split => { "year" => "-" }
  }
  mutate {
    replace => { "year" => "%{[year][0]}" }
  }
  # 숫자 필드 타입 변경
  mutate {
    convert => {
      "station_code" => "integer"
      "people_in" => "integer"
      "people_out" => "integer"
      "year" => "integer"
    }
  }
  # 사용하지 않는 필드 삭제
  mutate {
    remove_field => ["@version", "event", "log", "host", "message"]
  }
}

output {
  # stdout { }
  elasticsearch {
    cloud_id => "seoul-metro-test:YXNpYS1ub3J0aGVhc3QzLmdj..."
    cloud_auth => "ingest:password"
    index => "seoul-metro-logs-%{[year]}"
    pipeline => "seoul-metro-logs-pipe"
  }
}

전체 파이프라인을 거치면서 데이터는 다음과 같이 변경됩니다.

이제 Logstash 를 실행하고 데이터가 정상적으로 색인되었는지 확인합니다.

서비스에서 여러개의 서로 다른 클러스터를 동시에 운영하고 있거나, DR(Disaster Recovery) 구성, 멀티 리전 운영 등을 위해 한 클러스터에서 다른 클러스터의 데이터를 접속해야 하는 경우가 종종 있는데 Elastic 에서는 여러 클러스터의 데이터를 동시에 검색할 수 있는 Cross Cluster Search 과 서로 다른 클러스터의 데이터를 동기화 시키는 Cross Cluster Replication 기능들을 지원하고 있습니다.

이 포스트에서는 Elastic Cloud 서비스 (https://cloud.elastic.co) 에서 Cross Cluster 기능들을 사용하는 방법에 대해 설명 드리려고 합니다.

같은 Elastic Cloud 계정

Elastic Cloud 서비스에는 Cross Cluster 기능을 사용하기 위해 Trust 라는 것을 설정해야 합니다. Elastic Cloud 관리 화면의 아무 클러스터 메뉴에 가서 Features 아래에 Trust 메뉴로 가면 Trust all my deployments 체크가 있습니다. 여기에 체크가 되어 있으면 같은 Elastic Cloud 계정 (Organization) 끼리는 기본적으로 Cross Cluster 기능을 허용하게 됩니다.

서로 다른 Elastic Cloud 계정

서로 다른 Elastic Cloud 계정 간의 클러스터들 끼리 Cross Cluster 기능을 활성화 하기 위해서는 각 클러스터에 대해 Trust 정보를 추가해야 합니다. 이 작업은 2개 클러스터 모두 진행해야 합니다.

먼저 Elastic Cloud 관리 페이지에서 Cross Cluster 를 사용할 클러스터의 설정 화면 중 Security 메뉴로 이동합니다. 화면의 Trusted deployments 섹션에 있는 Create trus 버튼 클릭합니다.

이제 Trust 를 추가 할 Elastic Cloud Orgazniation(계정) 의 ID와 연결 해 줄 클러스터(Deployment) ID 를 입력해야 합니다. 이 정보들은 연결 할 클러스터 관리 화면에서 확인할 수 있습니다.

연결할 클러스터의 우측 상단 아이콘의 드롭다운 메뉴에서 Organization 화면으로 이동하면 Organization ID 를 확인할 수 있습니다. 이 ID 를 복사해서 이전 클러스터 관리 화면의 Add organization ID 란에 넣어줍니다.

All deployments 를 체크하면 연결한 organization 의 모든 Cluster 와 Cross Cluster 설정이 가능합니다. 특정 Cluster 만 허용하고 싶으면 Specific deployments 를 선택하고 Deployment ID 를 넣어줍니다. Deployment ID 는 연결할 클러스터 관리 화면으로 들어간 뒤 URL 에 나타나는 32자의 문자열 입니다. 이 문자열을 복사해서 붙여넣어줍니다.

이 과정을 서로에 대해 각각 연결할 클러스터 모두 진행 해 줍니다

Remote Cluster 설정

이제 Organization 간의 Trust 작업을 마쳤으면 Elasticsearch 클러스터애 Remote Cluster 정보를 등록해야 합니다. Kibana 의 Stack Management 메뉴의 Remote Cluster 메뉴로 이동한 뒤 Add a remote cluster 버튼을 클릯합니다.

Name 은 원격 클러스터의 닉네임으로 사용할 이름을 적어줍니다.
그리고 Manually enter proxy… 를 체크하여 Proxy address 와 Server Name 을 입력해야 합니다.

이 정보들은 연결할 Elastic Cloud 의 관리 화면 중 앞에서 보았던 Security 메뉴의 맨 아래 Remote cluster parameters 섹션에 있습니다. 값이 화면에 표시되지는 않으며 Prox address 와 Server name 링크를 클릭하면 각각 값들이 클립보드로 복사되어 위 Kibana 의 Add Remote Cluster 화면에 붙여넣기 하면 됩니다.

이제 원격 클러스터에 접속할 준비는 다 끝났습니다. 앞에서 만든 원격 클러스터 이름 뒤에 콜론 : 을 붙이고 인덱스를 넣어 원격 클러스터에 있는 데이터를 사용할 수 있습니다. 다음은 mycrawl 이라고 명명한 원격 클러스터의 googleplayreview 인덱스를 검색한 결과입니다.

GET mycrawl:googleplayreview/_search

다음과 같이 멀티테넌시로 원격 클러스터와 로컬 클러스터의 인덱스들을 한꺼번에 검색하는것도 가능합니다.

GET remote:my-index,my-index/_search

기본적으로는 같은 메이저 버전의 클러스터들 끼리 원격 클러스터로 설정이 가능하며, 이전 버전의 경우 가장 마지막 마이너 버전의 클러스터와의 연결이 지원됩니다.

따라서 예를 들어 현재 8.2 버전 클러스터에서 7.11 버전 클러스터를 연결하고 싶으면 먼저 7.11 버전을 7.x 의 마지막 마이너 버전인 7.17 로 업데그레이드를 해야 합니다.

맺음말

Cross Cluster 기능은 하나의 서비스에서 여러 클러스터를 운영하는데 같이 검색이나 분석을 하거나 DR 구성등을 하는데 유용하게 쓸 수 있습니다. 그리고 지금 또 한가지 유용한 팁은, 현재 운영중인 클러스터를 업그레이드를 해야 할 때 운영중 업그레이드가 부담스럽다면 기존 서비스는 그대로 두고 최신 클러스터를 새로 만들어서 새로운 데이터는 새 클러스터로 색인하고 기존 데이터도 새 클러스터에서 예전 클러스터 데이터를 같이 조회하도록 하면 좀 더 안전하고 쉽게 최신 버전을 사용할 수 있습니다.

메이저 버전이 다르다면 이전 클러스터는 메이저의 마지막 버전으로는 업그레이드 해야 합니다. Elastic Cloud 에서는 원클릭으로 바로 가능합니다.

사실 7.0 에서 7.17 버전으로 오기 까지 마이너 업데이트를 하면서 변경된 기능들이 정말 많았습니다. 7.0 버전 출시 때 작성했던 포스트에서도 이야기했지만, 보통 Elastic 의 기능 추가는 마이너 릴리스에서 기능들이 추가 되고 메이져 릴리스는 데이터 저장방식 등의 구조 변경에 초점을 맞추기 때문에 오히려 기능들이 Deprecated 되거나 Expire 되는 경우가 많습니다.

이번 8.0 릴리스의 가장 큰 테마는 NLP (자연어 처리) 와 Vector Search 입니다. 저도 이 분야에는 알못이라서 차근 차근 공부 해 가면서 계속 공유 해 보도록 하겠습니다. 자세한 내용은 Elastic 8.0 출시 블로그를 참고하세요. 아직은 영문 버전만 올라와 있는데 곧 한국어로 번역되어 올라올 예정입니다.

Elastic 처음 설치 과정에도 몇가지 변경된 내용이 있습니다. 오늘 포스트에서는 Elasticsearch 와 Kibana 의 처음 설치 과정이 어떻게 변경되었는지에 대해 간단하게 한번 살펴보겠습니다.

현재는 (그리고 아마 앞으로도 계속) Elastic에서 하는 거의 모든 홍보, 영업이 대부분 Elastic Cloud 를 중심으로 이루어지고 있습니다. Elastic 공식 홈페이지(https://www.elastic.co) 에서도 대부분의 링크들이 클라우드 서비스 페이지(https://cloud.elastic.co) 로 연결되도록 유도하고 있고, 가입된 Elastic Cloud 계정을 로그인 정보로 이용해서 공식 교육 페이지라던가 내부 행사 등에 사용합니다.

하지만 여전히 온프렘으로 설치, 사용하시는 분들이 많이 계신걸로 알고, 오늘은 간단히 로컬에서 설치하는 방법 까지만 살펴보고, 클러스터 구성이나 추가적인 설정들은 이후 다른 포스트에서 계속 다루도록 하겠습니다. 설치 파일 다운로드를 위해서는 Elastic 공식 홈페이지(https://www.elastic.co) 에서 상단에 product 메뉴로 이동해서 Elasticsearch + Kibana 부분을 클릭합니다.

그리고 그 아래 Or Download … 링크를 클릭합니다.

그러면 시작 튜토리얼 페이지 (https://www.elastic.co/start) 로 이동하게 됩니다. 이제 여기서 안내하는대로 쭉 따라서 하시면 되는데, 먼저 elasticsearch 를 설치할 OS의 버전을 선택하고 아래 버튼을 눌러 elasticsearch 설치 파일을 다운로드 합니다.

그 다음은 tar 또는 zip 명령을 이용해서 압축을 풀고 시작 튜토리얼 페이지에 나온 대로 명령들을 실행하시면서 설치하면 됩니다. 각 명령 옆에 있는 스니펫 카피 버튼을 누르면 클립보드에 명령이 복사되어 바로 붙여넣기를 하실 수 있습니다.

bin/elasticsearch 명령어로 실행을 하고 난 뒤, 터미널을 잘 보고 계시면 이전 버전까지는 보이지 않았던 다음과 같은 메시지가 하나 나타탑니다.

OSS 버전(7.11 부터 OSS 는 제공하지 않고 현재 최소 기능 버전은 Basic 입니다) 에서는 제공하지 않았고 Basic 에서도 선택적으로 활성화 가능했던 Security 기능이 이제 필수로 활성화가 됩니다. 슈퍼 관리자(superuser) 계정인 elastic 의 패스워드가 자동으로 생성 되고 그 외에 다른 노드, 클라이언트 및 에이젼트 연동에 필요한 암호화 키 정보들이 표시가 됩니다.

이제 Kibana를 실행시켜 봅니다. Kibana도 처음 실행하면 보안 설정을 마저 마무리 하라는 메시지가 터미널에 나타납니다.

웹브라우저를 열고 kibana 화면에 들어가면 (디폴트 포트 :5601) enrollment token 을 입력하라는 화면이 보입니다.

여기 아까 elasticsearch 실행 터미널에 있던 enrollment 토큰을 복사해서

Kibana 화면의 enrollment 입력란에 붙여넣기 해 줍니다. 그리고 Configure Elastic 버튼을 클릭합니다.

그럼 또다시 Kibana verification code 를 입력하라는 화면이 나옵니다. 요즘은 6자리 숫자 인증이 공통 갬성인것 같습니다.

이 숫자는 kibana 실행 터미널에서 볼 수 있습니다.

터미널에서 확인된 숫자를 kibana 화면에 입력 해 줍니다.

그럼 이제 kibana 가 나머지 설정들을 진행합니다.

Kibana 홈 디렉토리 아래애 config/kibana.yml 파일을 살펴보면 elasticsearch 와 연동에 필요한 암화 정보 들이 자동으로 추가되어 있는 것도 확인할 수 있습니다.

잠시 기다리면 이제 kibana 화면에 로그인 화면이 나타납니다. elasticsearch 터미널에 표시되었던 슈퍼 관리자 elastic 의 패스워드를 복사해서

사용자 elastic, 패스워드는 붙여넣고 로그인 합니다.

이제 예전처럼 elasticsearch 와 kibana 를 사용할 수 있습니다. 화면 디자인은 7.17 버전에서 크게 변한 것은 없습니다.

메이져 릴리즈가 나왔는데 이전 버전과 화면이 동일한 것은 살짝 아쉽기는 합니다. 새 버전 느낌이 나도록 배경 색상 정도라도 바꿔주면 좋지 않았을까 하는 생각이 있지만, 7.x 에서도 마이너 버전이 업데이트 될 때 마다 바뀐게 많았기 때문에 8.x 도 앞으로 계속 마이너 릴리스가 나올 때마다 발전될것이라 기대 해 봅니다.

오늘 포스팅은 이것으로 마치고 다음에는 또 다른 8.x 내용에 대해 다루어 보도록 하겠습니다. 🤓

먼저 이 글은 제 개인의 생각일 뿐 제가 속한 조직이나 제가 관리자로 있는 커뮤니티의 입장을 대변하진 않습니다. 이 내용들이 어떤 논쟁의 근거로 쓰이는 일은 없기를 바랍니다.

어제 페이스북에 친구 공개로 끄적여 본 내용입니다.

기왕 이야기 꺼낸거 생각을 한번 정리 하고자 오랬만에 블로그에 글을 씁니다.

작년에 한번 Elastic 라이센스, 그리고 오픈 소스 에반젤리스트의 딜레마 라는 제목으로 비슷한 주제의 글을 쓴 적이 있었습니다. 그 때도 Elastic의 가장 큰 경쟁 제품은 A사도, S사도, D사도 아닌 Elastic 오픈 소스 입니다. 라는 이야기를 했었는데, 이제 Elastic 제품들의 라이센스가 Apache 에서 SSPL 로 변경이 되어 더 이상 오픈소스 라고 부르면 안되긴 하지만 다른 오픈소스 기업들이 다 같이 겪고 있는 고민이라고 생각 되어서 글 제목에는 오픈소스라는 단어를 달았습니다.

한동안 커뮤니티에서 여러번 설명을 드렸지만, Elasticsearch 와 Kibana 를 더 이상 오픈소스 라고 부르지 못하는 이유는 Open Sorce 라는 단어에 대한 사용권(?)은 Open Source Initiative 에서 승인한 라이센스들 에서만 가능하기 때문입니다. Elastic 이 이번에 변경한 SSPL 역시 다른 오픈소스들과 마찬가지로

• 무료로 사용이 가능하고
• 소스 코드가 공개되어 있고
• 사용자는 제품에 코드 기여가 가능

하지만, OSI 에서 승인하고 있는 종류의 라이센스가 아니라서 오픈소스라고 부르면 안됩니다. 기존 오픈소스와 뚜렷하게 다른 점은

• 13항 - 클라우드에서 제품 서비스로 제공하는 경우 기능에 대한 소스를 공개해야 한다

는 점 입니다. SSPL 은 MongoDB 에서 처음 발표 한 라이센스 인데, 과거 오픈소스 라이센스들이 제정 되던 시기에는 소프트웨어는 다운로드 받아 설치하는 것 이었지만, 지금은 소프트웨어를 클라우드에서 구매해서 사용하는 것으로 환경이 바뀌었기 때문에 과거에 제정된 라이센스에는 맞지 않는 조항들을 개선한 것이라고 볼 수 있습니다. AGPL 과 SSPL 비교

서론이 길었네요. 이제 Elastic이 한국에서 했던 비즈니스 활동에 대해서 이야기를 좀 해 보겠습니다. 제가 속한 Elastic 의 이야기지만 많은 오픈소스 회사들도 비슷하리라 생각합니다.

Elastic 의 비즈니스 패턴

지금까지 국내에서 제가 보아 온 Elstic 의 비즈니스 활동은 몇가지 패턴이 있었습니다.

• SI 신규 프로젝트
• 시스템 고도화
• 무료(오픈) 기능을 사용하다가 유료로 전환

SI 신규 프로젝트

우리 나라는 아직도 SI(Service Integration) 라고 하는 프로젝트 발주 형식의 비즈니스가 많습니다. 그리고 이 SI 라고 하는 큰 과정 안에서 개발자 인건비, 장비 구매비, SW 구매비 등과 같은 비용들이 산정이 됩니다.

Elastic 의 주 비즈니스는 년간 구독 방식의 기술지원 서비스 입니다. 당연히 일반적으로 SI 에서 이런 비용을 산정하는 경우는 잘 없습니다. 있다고 해도 보통 1~2주의 컨설팅이나 교육 구매 정도입니다. 따라서 Elastic은 SI 프로젝트에 참여가 가능한 파트너사에게 상용 기능과 기술지원 서비스를 제공하는 방식으로 비즈니스를 모색합니다. Elastic 유료 라이센스와 기술지원 비용이 결코 저렴하지 않기 때문에 가격 면에서 경쟁 하기가 사실 쉽지는 않습니다.

이 때 Elastic과의 협업 없이 오픈된 무료 기능만 가지고 기능을 개발 해 주겠다는 경쟁자가 나타납니다. 당연히 가격은 공식 파트너사의 제품 보다 훨씬 저렴하겠고요.

Elastic 은 (제 생각에)다른 오픈소스 DB 보다는 비교적 쉬운 편이지만, 그래도 잘 설치하고 제대로 활용하기 위해서는 만만치 않은 기술과 노하우가 필요합니다. 프로젝트 진행 과정에서 Elastic 의 공식 파트너라면 이런 문제들이 나타날 때 마다 Elastic 기술지원 서비스를 받을 수 있지만, 나중에 나타난 경쟁업체에는 Elastic을 아무리 잘 하는 엔지니어가 있어도 모든 문제에 대처가 어려울 수 있습니다. 설치 중 오류 문제, 성능 문제 등등 프로젝트에 난항을 겪다 보면 결국에는 고객의 입에서

• 오픈소스는 너무 어려워. 이래서 쓰면 안돼.

라는 말이 나와 버리게 됩니다. 😩

시스템 고도화

Oracle 같은 RDB 나 Hadoop 같은 시스템을 유지하다가 새로운 기능의 요구조건을 충족시키기 위한 솔루션으로 Elastic 을 선택해서 진행하는 경우입니다. 위의 SI 신규 프로젝트와 마찬가지로 파트너와 진행하는 경우도 많고, 똑같은 문제도 종종 발생하지만, 이 경우에는 희망을 주는 경우가 있습니다.

Elastic 을 경험했고 좋아하는 엔지니어(보통 이런 분들을 챔피언 이라고 합니다)가 있는 경우입니다.

이 경우 보통 초반 미팅은 Elastic 에서 어렵게 설명하지 않아도 고객사의 챔피언이 직접 경험한 Elastic 의 장점을 이야기하고 설득 해 주는 경우도 많습니다. 이렇게 처음 이야기는 매끄럽게 잘 진행됩니다.

이렇게 프로젝트 수주 - 진행 - 납품까지 잘 이어지는 아름다운 그림이 나오면 좋겠는데 다음과 같은 경우가 생깁니다.

1. 고객사에서 비용적인 이슈가 발생해서 프로젝트 비용을 줄여야 하는 경우가 생깁니다. 유료 솔루션이나 장비의 구매 가격을 갑자기 내리는 것은 불가능합니다. 이 때 만만하게 비용을 줄일 수 있는 것이 없을까 하다가 눈이 가는 것이 Elastic 의 무료(오픈소스) 버전입니다.
   “죄송하지만 저희 기술지원 안 받고 무료 버전 가지고 저희가 한번 해 보겠습니다”
   라는 답변이 저희에게 돌아옵니다.

2. 구매 결정권자 또는 상부 라인에서 갑자기 챔피언을 호출합니다.
   “이거 오픈소스라던데 왜 돈주고 사는거에요? 이러다 비용 감사 들어오면 뭐라고 할거에요? 블라 블라…”
   그리고 자기 혼났다고 챔피언에게서 연락이 옵니다. 🥺

역시 Elastic 의 비즈니스 경쟁 상대는 Elastic 무료버전 입니다.

무료(오픈) 기능을 사용하다가 유료로 전환

가장 아름답고 이상적인 그림의 비즈니스입니다. Elastic 을 오랬동안 잘 써 왔고, 커뮤니티에도 열심히 참여하였으며, Elastic 의 다양한 기능과 철학들을 잘 이해하고 있는 고객이 새로운 시스템 또는 서비스로 도약하기 위해 연락을 하는 경우입니다.

“처음에는 검색 때문에, 로깅 때문에 Elastic을 쓰기 시작했는데 사용하다 보니 이런 저런 유용한 기능들이 많았어요. 그 동안에는 필요해서 서로 다른 솔루션들을 쓰고 있었는데 Elastic 으로 기능들을 통합하면 앞으로 좀 더 다양한 분석도 가능해지고, 새로운 비즈니스 전략도 발굴할 수 있을것 같아요. 이 과정에서 Elastic 의 도움을 받고 싶습니다.”

정말 감동적입니다.

사실 Elastic 을 처음 써 보는 고객의 경우에는 기초적인 질문 부터 시작해서, Elastic 에서 다 알아서 해줬으면 하는 생각으로 접근하는 경우가 많아 컨설팅이나 기술지원 팀에서도 응대 하는 것이 쉽지 않는 경우가 많습니다. 하지만 이렇게 이미 경험이 있는 고객의 경우에는 기술지원팀 에게 질문을 할 때도 어떤 부분이 문제인지를 대부분 잘 알고 질문을 하기 때문에 기술지원팀 입장에서도 협업하기가 매우 수월합니다.

Elastic 의 비즈니스 철학

지금은 수많은 오픈소스 제품들이 있지만 오픈소스로 비즈니스를 잘 성공시킨 기업은 많지 않습니다. 얼핏 제 머릿속에도 RedHat과 Elastic 정도 밖에 떠오르지가 않네요. Elastic 은 코드가 오픈된 제품이고 무료 기능과 유료 상용 기능이 있지만, Elastic 비즈니스의 핵심은 기술지원입니다. 그리고 제가 자주 하는 이야기이지만, Elastic의 기술지원의 철학은 단순히 고객의 질문에 답변만 하는 것이 아니라, 고객과 함께 문제 해결의 과정을 동행하는 것에 있습니다.

Elastic 이 오픈소스 비즈니스로 성장하는 여정에서 언급을 하지 않을 수 없는 고객이 골드만삭스 입니다. 공식 릴리즈도 아닌 초기 0.9x 버전, 유료 기능은 전혀 없던 시절 부터 회사의 모든 시스템을 Elastic 으로 통합하고 Elastic 과 기술 지원 협약을 맺었습니다. 현재 골드만삭스의 증권 거래, 분석 시스템은 물론 채용시스템의 이력서 검색 기능이라던가 내부 회계 결재 같이 모든 기능 구석구석에서 Elastic 이 쓰이고 있습니다. 골드만 삭스에는 현재도 수백명의 Elastic 전문 엔지니어들이 수천개의 노드의 클러스터를 운영하고 있습니다.

골드만 삭스 엔지니어의 운영 노하우는 다시 Elastic 엔지니어링 팀에게 피드백 되어 Elastic 의 공식 기능으로 개발 된 경우도 많이 있습니다. 대표적으로 현재 대용량 클러스터에서 자주 사용되는 Hot-Warm-Cold 아키텍쳐 입니다. 수천개의 노드를 운영하던 골드만 삭스 엔지니어가 제안하여 Elastic 엔지니어들이 이런 구조의 클러스터 아키텍트를 구성할 수 있는 config 옵션을 추가하고, 릴리즈 하여 Elastic의 모든 사용자들이 사용할 수 있게 되었습니다.

이처럼 골드만 삭스 라는 좋은 선례를 경험했기 때문에 Elastic 창시자들은 Elastic 이 모든 고객들과 골드만 삭스 같은 관계가 되기를 희망합니다.

기술지원 엔지니어를 모십니다

Elastic 에는 현재 대한민국에 5분 - 해외에 계신 한국어가 가능하신 분 까지 합하면 7분의 기술지원 엔지니어가 있습니다. 한국의 비즈니스 규모를 생각하면 굉장히 많은데, 한국 고객만 다루지 않고 해외 고객들의 문의도 두루두루 담당하고 계시기 때문에 그렇습니다. Elastic 기술지원 엔지니어는 국가가 아니라 리전(아시아) 단위로 채용하는데 한국 엔지니어분들이 뛰어나신 분들이 많아 많이 계신거라고 봅니다.

그리고 한국에서 기술지원 엔지니어는 계속 채용중입니다. 한국의 기술지원 엔지니어인 조인석님 께서 쓰신 글로벌 오픈소스 기술 지원 여정에 동참하시겠습니까?도 한번 읽어보세요.

Elastic 과 함께 해 주셔서 늘 감사드립니다. 앞으로도 계속 잘 부탁드립니다. 😘

Elastic은 버전업이 될 때 마다 나오는 새로운 기능들이 많습니다. 워낙 기본 기능도 다양하기 때문에 기본 기능 활용의 학습에만도 많은 시간을 들이게 되는데, 이번 포스트에서는 비교적 최근에 출시된 새로운 필드들에 대해 한번 살펴보고 활용 방법을 알아보도록 하겠습니다. 다음은 이 포스트에서 살펴볼 필드들입니다.

• unsigned_long
• version
• flattened
• aggregate_metric_double
• dense_vector

unsigned_long

이름 그대로 양/음 부호를 없앤 long 정수 타입입니다. Java의 long 타입인 64비트로 표현 가능한 최대 정수값인 0 ~ 18446744073709551615 까지 숫자의 저장이 가능합니다. 1천8백경이 넘네요. 입력은 아래처럼 심플합니다.

PUT my_index
{
  "mappings": {
    "properties": {
      "my_counter": {
        "type": "unsigned_long"
      }
    }
  }
}

version

elasticsearch 에 시스템 메트릭 같은 정보들을 저장하게 되면 버전 정보값을 저장해야 할 일이 있습니다. 보통 버전 정보는 7.12.2 처럼 3군데 이상으로 구분되어있는 경우가 많아 소수점이 있는 숫자로 저장하기 힘들고 보통은 문자열로 저장을 많이 합니다. 그러다 보니 버전 간의 대/소를 비교하거나 정렬하는 것이 쉽지가 않았습니다. version 타입을 사용하면 이런 버전 형식의 값의 비교 또는 정렬이 가능합니다.
다음과 같이 version 타입의 필드인 my_version을 갖는 version-test 인덱스를 선언하고 값들을 넣습니다.

PUT version-test
{
  "mappings": {
    "properties": {
      "my_version": {
        "type": "version"
      }
    }
  }
}

POST version-test/_bulk
{ "index" : {}}
{"my_version": "1.5.0"}
{ "index" : {}}
{"my_version": "1.2.5"}
{ "index" : {}}
{"my_version": "2.1.7"}
{ "index" : {}}
{"my_version": "1.5.3-beta"}
{ "index" : {}}
{"my_version": "1.5.3-alpha2"}

GET version-test/_search
{
  "query": {
    "range": {
      "my_version": {
        "gt": "1.3.9",
        "lt": "1.5.3-beta"
      }
    }
  }
}

...
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "version-test",
        "_type" : "_doc",
        "_id" : "wlujzngBoohoz6ycrpvX",
        "_score" : 1.0,
        "_source" : {
          "my_version" : "1.5.0"
        }
      },
      {
        "_index" : "version-test",
        "_type" : "_doc",
        "_id" : "xlujzngBoohoz6ycrpvX",
        "_score" : 1.0,
        "_source" : {
          "my_version" : "1.5.3-alpha2"
        }
      }
    ]
  }
...

GET version-test/_search
{
  "sort": [
    {
      "my_version": {
        "order": "desc"
      }
    }
  ]
}

...
{ "my_version" : "1.2.5" }
...
{ "my_version" : "1.5.0" }
...
{ "my_version" : "1.5.3-alpha2" }
...
{ "my_version" : "1.5.3-beta" }
...
{ "my_version" : "2.1.7" }
...

flattened

매핑에 하위 필드를 가지는 필드를 설계할 때는 보통 ojbect 또는 경우에 따라 nested 타입으로 설계를 합니다. 하지만 하위 필드로 어떤 타입의 필드가 오게 될지를 모르고, 데이터를 생성하는 개발자들이 자유롭게 형식을 만들 수 있도록 하고 싶은 경우 flattened 타입으로 선언이 가능합니다.

PUT flatten-label
{
  "mappings": {
    "properties": {
      "labels": {
        "type": "flattened"
      }
    }
  }
}

PUT flatten-label/_doc/1
{
  "labels": {
    "size": "XL",
    "color": "red",
    "price": 9000,
    "manufactured_date": "2020-10-21"
  }
}

### 요청 ###
GET flatten-label/_mapping

### 결과 ###
{
  "flatten-label" : {
    "mappings" : {
      "properties" : {
        "labels" : {
          "type" : "flattened"
        }
      }
    }
  }
}

PUT flatten-label/_doc/2
{
  "labels": {
    "color": "green",
    "price": 11000
  }
}
PUT flatten-label/_doc/3
{
  "labels": {
    "color": "blue",
    "price": 13000
  }
}

### 쿼리 ###
GET flatten-label/_search
{
  "query": {
    "match": {
      "labels.color": "red"
    }
  }
}

### 결과 ###
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    },
    "max_score" : 0.9530773,
    "hits" : [
      {
        "_index" : "flatten-label",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 0.9530773,
        "_source" : {
          "labels" : {
            "size" : "XL",
            "color" : "red",
            "price" : 9000,
            "manufactured_date" : "2020-10-21"
          }
        }
      }
    ]
  }

### 쿼리 ###
GET flatten-label/_search
{
  "sort": [
    {
      "labels.price": {
        "order": "desc"
      }
    }
  ]
}

### 결과 ###
    "hits" : [
      {
        "_index" : "flatten-label",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : null,
        "_source" : {
          "labels" : {
            "size" : "XL",
            "color" : "red",
            "price" : 9000,
            "manufactured_date" : "2020-10-21"
          }
        },
        "sort" : [
          "9000"
        ]
      },
      {
        "_index" : "flatten-label",
        "_type" : "_doc",
        "_id" : "3",
        "_score" : null,
        "_source" : {
          "labels" : {
            "color" : "blue",
            "price" : 13000
          }
        },
        "sort" : [
          "13000"
        ]
      },
      {
        "_index" : "flatten-label",
        "_type" : "_doc",
        "_id" : "2",
        "_score" : null,
        "_source" : {
          "labels" : {
            "color" : "green",
            "price" : 11000
          }
        },
        "sort" : [
          "11000"
        ]
      }
    ]

aggregate_metric_double

도큐먼트의 숫자 타입의 필드들은 aggregation을 통해 min, max, sum, avg 등의 값을 계산할 수 있습니다. 이 계산은 raw 도큐먼트들의 필드를 쿼리 때 마다 계산할 수도 있지만, aggs 를 위한 통계성 데이터만 저장 해 놓을 때에 매우 유용하게 사용될 수 있습니다. 이 때 사용하는 필드 타입이 aggregate_metric_double 입니다. aggregate_metric_double 에는 다음의 두 설정 값이 있습니다.

• metrics : 하위 필드로 저장할 메트릭을 지정합니다. [min, max, sum, value_count] 가 올 수 있습니다. avg는 별도로 저장하지 않는데, sum 과 value_count 를 이용해서 계산하게 됩니다.
• default_metric : 쿼리 시 사용할 디폴트 하위 필드를 지정합니다. 이 필드의 값을 exist, range, term, terms 쿼리로 검색할 수 있습니다.

다음과 같이 revenue-stats 인덱스에 revenue 필드를 aggregate_metric_double 타입으로 선언합니다.

PUT revenue-stats
{
  "mappings": {
    "properties": {
      "revenue": {
        "type": "aggregate_metric_double",
        "metrics": [ "min", "max", "sum", "value_count" ],
        "default_metric": "max"
      }
    }
  }
}

PUT revenue-stats/_doc/2020-01
{
  "revenue": {
    "min": 25,
    "max": 470,
    "sum": 124400,
    "value_count": 374
  }
}
PUT revenue-stats/_doc/2020-02
{
  "revenue": {
    "min": 35,
    "max": 600,
    "sum": 187465,
    "value_count": 491
  }
}
PUT revenue-stats/_doc/2020-03
{
  "revenue": {
    "min": 20,
    "max": 580,
    "sum": 159650,
    "value_count": 420
  }
}

### 쿼리 ###
GET revenue-stats/_search
{
  "aggs": {
    "min-revenue": { "min": { "field": "revenue" } },
    "max-revenue": { "max": { "field": "revenue" } },
    "sum-revenue": { "sum": { "field": "revenue" } },
    "avg-revenue": { "avg": { "field": "revenue" } },
    "total-count": { "value_count": { "field": "revenue" } }
  }, 
  "size": 0
}

### 결과 ###
  "aggregations" : {
    "max-revenue" : {
      "value" : 600.0
    },
    "total-count" : {
      "value" : 1285
    },
    "sum-revenue" : {
      "value" : 471515.0
    },
    "min-revenue" : {
      "value" : 20.0
    },
    "avg-revenue" : {
      "value" : 366.9377431906615
    }
  }

### 쿼리 ###
GET revenue-stats/_search
{
  "query": {
    "range": {
      "revenue": {
        "gte": 500,
        "lt": 600
      }
    }
  }
}

### 결과 ###
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "revenue-stats",
        "_type" : "_doc",
        "_id" : "2020-03",
        "_score" : 1.0,
        "_source" : {
          "revenue" : {
            "min" : 20,
            "max" : 580,
            "sum" : 159650,
            "value_count" : 420
          }
        }
      }
    ]
  }

dense_vector

dense_vector 를 이용하면 필드에 다차원의 벡터 값들을 입력해서 검색을 할 수 있습니다. dims 속성을 이용해서 차원 수를 입력합니다. 다음은 books 인덱스에 문자열 title 필드와 3차원의 벡터를 갖는 vector_recommend 필드에 값을 입력하는 예제입니다.

PUT books
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text"
      },
      "vector_recommend": {
        "type": "dense_vector",
        "dims": 3
      }
    }
  }
}

# 1차원: 페이지 수/100
# 2차원: 사용자 평점 (최대 10.0)
# 3차원: 책 가격 / 5000

POST books/_bulk
{"index": {"_id": 1}}
{ "title": "혼자 공부하는 머신러닝+딥러닝", "vector_recommend": [5.8, 10.0, 5.2] }
{"index": {"_id": 2}}
{ "title": "핸즈온 머신러닝", "vector_recommend": [9.52, 9.1, 9.8] }
{"index": {"_id": 3}}
{ "title": "파이썬 머신러닝 완벽가이드", "vector_recommend": [6.48, 9.6, 7.6] }
{"index": {"_id": 4}}
{ "title": "밑바닥부터 시작하는 딥러닝", "vector_recommend": [3.12, 9.5, 4.8] }
{"index": {"_id": 5}}
{ "title": "빅데이터분석기사 필기", "vector_recommend": [3.68, 9.6, 5.0] }
{"index": {"_id": 6}}
{ "title": "선형대수와 통계학으로 배우는 머신러닝 with 파이썬", "vector_recommend": [6.24, 9.8, 7.5] }
{"index": {"_id": 7}}
{ "title": "파이썬 라이브러리를 활용한 머신러닝", "vector_recommend": [4.8, 9.2, 6.4] }
{"index": {"_id": 8}}
{ "title": "파이썬 머신러닝 판다스 데이터 분석", "vector_recommend": [3.92, 9.2, 5.0] }
{"index": {"_id": 9}}
{ "title": "텐서플로 2와 머신러닝으로 시작하는 자연어 처리", "vector_recommend": [5.6, 8.0, 7.0] }
{"index": {"_id": 10}}
{ "title": "R 데이터 분석 머신러닝", "vector_recommend": [3.08, 8.6, 4.0] }

• 페이지 수가 적고 : 1
• 평점은 높고 : 10
• 가격은 저렴한 : 1
  추천 결과값을 가져오는 쿼리를 cosineSimilarity 를 이용해서 실행 해 보겠습니다.

  GET books/_search { "query": { "script_score": { "query":{ "match_all": {} }, "script": { "source": "cosineSimilarity(params.query_vector, 'vector_recommend') + 1.0", "params": { "query_vector": [1, 10, 1] } } } } } ### 결과 ### "hits" : [ ... "_source" : { "title" : "R 데이터 분석 머신러닝", "vector_recommend" : [3.08, 8.6, 4.0] ... "_source" : { "title" : "밑바닥부터 시작하는 딥러닝", "vector_recommend" : [3.12, 9.5, 4.8] ... "_source" : { "title" : "빅데이터분석기사 필기", "vector_recommend" : [3.68, 9.6, 5.0] ...

  가장 저렴하고 페이지수가 적은 책 부터 나타납니다. 이번에는 페이지수는 중간 5, 가격은 중간에서 약간 위 6 을 기준으로 놓고 그 조건에 맞는 책을 추천받는 쿼리를 실행 해 보겠습니다.

  GET books/_search { "query": { "script_score": { "query":{ "match_all": {} }, "script": { "source": "cosineSimilarity(params.query_vector, 'vector_recommend') + 1.0", "params": { "query_vector": [5, 10, 6] } } } } } ### 결과 ### ... "_source" : { "title" : "파이썬 머신러닝 판다스 데이터 분석", "vector_recommend" : [3.92, 9.2, 5.0] ... "_source" : { "title" : "파이썬 라이브러리를 활용한 머신러닝", "vector_recommend" : [4.8, 9.2, 6.4] ... "_source" : { "title" : "혼자 공부하는 머신러닝+딥러닝", "vector_recommend" : [5.8, 10.0, 5.2] ...

elastcsearch 에는 이밖에도 다양한 고급 속성, 기능 들이 많이 있습니다. 잘 찾아보고 나에게 도움이 되는 기능들을 잘 활용 해 보시기 바랍니다.

1 - Amazon S3 에서 Elastic Cloud 로 데이터 수집하기
2 - Elastic Cloud 마이그레이션

Elastic 클러스터 마이그레이션

시스템을 운영하다 보면 버전이나 장비 업그레이드, 클라우드 서비스 사업자 교체 등의 이유로 데이터를 통째로 옮겨야 하는 경우가 종종 발생합니다. Elasticsearch 에는 데이터 마이그레이션을 할 수 있는 다양한 방법들이 있는데 잘 알려진 방법으로는

• 소스 데이터를 다시 색인
• data 디렉토리를 통째로 복사
• Logstash 또는 _reindex API 를 이용해서 다른 클러스터로 복사
• Cross Cluster Search 를 이용해서 다수의 클러스터 운용
• _snapshot, _restore API를 이용한 복원

등이 있습니다.

소스 데이터를 다시 색인

저는 개인적으로 소스 데이터를 다시 색인 하는 것을 선호하는 편입니다. 시간이 가장 오래 걸리긴 하지만 Elasticsearch 새로운 장비나 버전에 대한 호환성 등에 신경 쓸 필요가 없고 마이그레이션 중 발생할 수 있는 문제를 체크 해 가며 가장 안전하게 할 수 있는 방법이기 때문입니다.

data 디렉토리를 통째로 복사

data 디렉토리를 통째로 복사 하는 방법은 보통 데이터 마이그레이션 보다는 플러그인 패치나 업그레이드를 할 때 주로 사용하는 방법입니다. path.data (디폴트는 홈 디렉토리의 \data) 내의 파일들은 그대로 두고 Elasticsearch 홈 디렉토리의 \bin, \lib, \plugins 등만 새 버전으로 덮어 씌운 뒤 노드를 다시 시작하면 데이터를 새로 색인 할 필요가 없이 바로 새 버전의 Elasticsearch 가 실행이 됩니다.

5.x 이상 부터는 메이저 버전으로의 롤링 업그레이드도 지원하기 때문에 클러스터 다운 없이 무중단으로 업그레이드도 가능합니다. 롤링 업그레이드 할 때는
샤드 리로케이션을 중단 -> 노드 재시작 -> 샤드 리로케이션 활성 -> 클러스터 상태 Green 으로 변경 확인 -> 다시 처음부터
를 반복해야 하기 때문에 중간에 순서가 꼬이지 않도록 조심해야 합니다. 자세한 순서와 명령들은 공식 도큐먼트에 잘 나와 있습니다.
https://www.elastic.co/guide/en/elasticsearch/reference/7.8/setup-upgrade.html

다만 이 때도 플러그인이라던가 depricated 된 API 등을 체크하지 않으면 샤드들이 살아나지 않을 수도 있습니다. 이것은 과거 6.4 버전때 제가 한번 실패했고

다시 했던 경험이 있는데

위의 두 영상들을 보면서 확인하실 수 있습니다.

Logstash 또는 _reindex API 를 이용해서 다른 클러스터로 복사

Logstash 또는 _reindex API 를 이용해서 다른 클러스터로 복사 하는 것도 시간은 걸리지만 비교적 안전하게 데이터를 옮길 수 있는 방법입니다. 기존 클러스터의 _source 데이터를 이용해서 다른 클러스터로 다시 색인을 하는 것이기 때문에 기능적으로는 소스 데이터를 다시 색인 하는 것과 차이가 없습니다. 이 방법을 사용하기 위해서는 기존 클러스터의 인덱스들은 모두 _source 를 저장하고 있어야 합니다. (인덱스 mapping 에서 _source 를 저장하지 않도록 하는 설정도 있습니다.) 참고로 _reindex 로 재색인을 하는 경우 도큐먼트id 까지 동일하게 복사를 하며 Logstash 로 하는 경우 docinfo 라는 설정값으로 지정을 할 수 있습니다.

사용 방법은 Logstash 도큐먼트 페이지
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-elasticsearch.html
에서 확인하실 수 있습니다.

Cross Cluster Search 를 이용해서 다수의 클러스터 운용

Elastic 클러스터 운영 경험과 노하우가 많이 쌓인 분들은 Cross Cluster Search 를 이용해서 여러 클러스터를 운영 해 가며 마이그레이션 하는 방법도 있습니다. 새로운 데이터는 새 버전으로만 색인을 하고 과거 클러스터와 새 클러스터를 한 클라이언트(Kibana) 에서 같이 검색하면서 사용하다가 과거 클러스터의 데이터들의 보관 주기가 끝나면 이제 새 클러스터로만 운영하는 방식입니다. 장기간의 계획으로 운영 되어야 하겠지만 잘만 활용 되면 매우 유용하게 사용할 수 있는 방법입니다.

Elasticsearch 는 5.3, Kibana 는 5.7 버전 부터 Cross Cluster Search 기능을 지원합니다. 아래는 제가 오래 전에 Cross Cluster Search 관련해서 발표했던 장표를 캡쳐 한 것입니다.

_snapshot, _restore API를 이용한 복원

Elasticsearch 에는 스냅샷을 찍어 인덱스를 저장하는 기능이 있습니다. 이 스냅샷을 다른 클러스터에서 복원(restore) 시키는 것으로 클러스터의 데이터를 옮길 수 있습니다. Snapshot, Restore 방법은 아래 도큐먼트에 있습니다.
https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html

스냅샷은 로컬 디스크나 공유 디스크, HDFS, Amazon S3, Azure, Google Cloud Storage 등에도 저장이 가능합니다.
https://www.elastic.co/guide/en/elasticsearch/plugins/5.5/repository.html

Elastic Cloud 에서 클러스터를 생성 할 때는 GCP, Azure, AWS 중에 선택이 가능합니다.

Elastic Cloud 에서는 자동적으로 매 30분 마다 클러스터의 스냅샷을 해당 서비스 사업자의 스토리지(AWS의 경우 S3)에 자동으로 저장하고 있습니다. 클러스터에 문제가 생기면 인덱스를 삭제하고 과거 스냅샷의 복원이 가능합니다.

또한 Elastic Cloud 에서 새 클러스터를 생성할 때 다른 클러스터가 저장 해 놓은 스냅샷으로부터 클러스터를 생성하거나 가져와서 복원 하는 것이. 이는 운영 서비스 데이터를 복사해서 개발 클러스터를 만들거나 할 때 매우 유용합니다. 다만 같은 서비스 사업자와 같은 리전에 있는 클러스터의 스냅샷만 사용 가능한 제약이 있습니다.

아마도 이번에 Elastic Cloud 의 서울 리전 발표로 Elastic Cloud 를 사용하시는 분들이 서울 리전으로의 데이터 마이그레이션을 계획하고 계신 분들이 많으실겁니다. Elastic Cloud 관리 화면과 Kibana 에서 스냅샷 환경을 직접 설정하면 스냅샷을 다른 리전에서도 복원이 가능합니다.

s3.client 설정

Amazon S3 를 스냅샷 리파지토리로 사용하기 위해서는 S3 클라이언트 정보를 설정해야 합니다. 기본적인 설정법은 아래 도큐먼트 페이지에 있습니다.
https://www.elastic.co/guide/en/elasticsearch/plugins/7.8/repository-s3-client.html

먼저 AWS IAM 에서 AmazonS3FullAccess 권한을 가진 사용자의 Access Key 와 Secret Key 가 필요합니다. 위의 도큐먼트에서는 이 값들을 elasticsearch-keystore 에서 설정하도록 안내를 하고 있습니다.

keystore 는 터미널에서 하는 작업이기 때문에 위와 같은 명령은 온프렘 환경에서만 가능합니다. 다행이 Elastic Cloud 에서는 Security 메뉴에서 keystore 값을 설정할 수 있도록 기능을 제공하고 있습니다. Security 화면의 Elasticsearch Keystore 섹션의 Add settings 버튼을 클릭하면

오른쪽에서 아래와 같은 화면이 팝업되어 설정을 추가할 수 있습니다.

클라이언트 정보는 s3.client.CLIENT_NAME.SETTING_NAME 같은 형태로 설정합니다. 위 스크린샷에서 설정한 클라이언트의 이름은 default 이고 access_key 값을 지정 한 것입니다. 같은 방법으로 s3.client.default.secret_key도 저장을 합니다.

이제 Kibana 의 Stack Management 메뉴에 있는 Snapshot and Restore 메뉴에서 새로운 S3 리파지토리를 등록할 수 있습니다.

또는 Dev Tools 에서 _snapshot API 를 이용해서 바로 등록하는 것도 가능합니다.

PUT _snapshot/s3-repository
{
  "type": "s3",
  "settings": {
    "bucket": "my_bucket",
    "client": "default"
  }
}

이제 스냅샷을 실행하면 앞서 지정한 S3 버킷에 저장이 됩니다. 다른 클러스터에도 같은 S3 리파지토리를 등록하고 S3 버킷에 저장된 스냅샷을 복원할 수 있습니다.

더 자세한 사용법은 아래 영상을 참고하시기 바라며 안전하게 마이그레이션 성공하시길 바랍니다. 🤓