처음엔 크고 멋진 회사였지만 이젠 작고 볼품 없어 보인다. 많이 알수록 힘은 있지만 어깨는 무겁다. 명확하게 깨달은 것은 내가 본 세상이 아주 많이 작았다는 것이다. 애써 포장하기보다 있는 그대로 밝히는 것이 더 현명한 방법임을 믿는다. 그저 올해가 되어 퀀텀리프의 도화선을 발견한 것이다. 지난 시간을 후회하는 약한 마음도 들지만 그땐 그것이 최선이었음을 안다.
분석가를 떠나 엔지니어로 생활 시작한게 작년 2월부터니 딱 1년이 되었다. 본격적으로 전념한 것은 6개월정도. 사실 개발 관련 포스트를 자주 올리고 싶었다. 그렇지 못한 이유는 나 스스로 확신이 없어 더 공부하기 벅차고 또한 공개된 문서의 내용을 그대로 전할 수 밖에 없어서다. 앞으로 가능하다면 양질의 해외 문서 및 강의를 편집해 공유하고 싶다. 양질의 한국어 자료는 찾기 어려워서다. 나처럼 스스로 길을 찾는 junior가 의지할 수 있는 그런 문서.
2020년에 kubernetes용 elasticsearch가 정식 출시됐다. eks에서 사용하기 때문에 어떤 ec2 instance가 적합한지를 조사했는데 암만 찾아도 좋은 가이드는 없다. 찾다못해 직접 판단 기준을 세워보았고 그 과정과 결과를 공유하려한다. (찾아서 안 나오는 걸 내가 글로 쓰는게 의미가 있지😎) 물론 나는 초보자이기 떄문에 이보다 좋은 접근법이 무조건 있을 것이다.
master, data, coordinating의 특징을 정리하며 인스턴스 후보를 골랐다.
후보는
위에 조합을 대상으로 esrally를 돌려 나온 결과값을 비교한다. 다만 cluster 너무 크면 크게 부하를 줘야하니 작은 cluster로 실험한다.
성능도 괜찮고 가격이 싼 조합을 최종 초이스한다. (안정성은 실험이 어려워 배제)
esrally 성능지표중 term=phrase>aggregation>index 차례로 우선순위를 두고 가격 대비 성능을 판단했다 (스토리지 타입은 eks console에서 선택이 불가하므로 pass했다.) 이유는 es 용도가 logging이 아닌 search며 주요 task로는 match가 가장 크고 heavy aggregation도 상당수 있기 때문이다.
종합하면 가성비를 위해선 master: t3 or m5, data: m5, coordinating: c5로 구성하는 것이 좋을 것이다.
덧붙여 ebs 대신 ssd 사용을 고려했지만 포럼을 보고 접었다.
“jekyll algolia 사용법”을 검색해보면 minima theme에 _config.yaml을 수정하는 방법만 나와서
내부적으로 어떻게 돌아가는지 찾아본 결과를 공유한다.
(드디어 묵은 숙제를 건드렸다😎)
algolia 검색 API는 data indexing, API call 두 가지로 파악할 수 있다. 사실 이거와 저거만 보면 충분하다.
bundle exec jekyll algolia를 실행하면 _post의 data가 _config.yaml에 세팅된 algolia endpoint로 전송된다.
github blog 사용자는 이 커맨드를 ci 과정에서 (travis CI) 실행한다.
여기 설명이 있는데 쉽게 말하면 _includes/algolia.html 파일에 호출 코드를 심어 놓고 검색이 들어갈 div 태그의 id 값으로 호출 코드를 불러온다. <div id="search-searchbar"></div>와 <div id="search-hits">가 그 값이다. 여기서도 _config.yaml를 통해 algolia endpoint를 찾는다.