# README
프로젝트 개요
다양한 툴을 사용하는 것을 목표로 작성이 되었다.
이떄까지는 하나의 툴을 사용을 하여, 해당 툴을 적용한 API서버가 목표였다면
이번에는 이떄까지 사용했던 툴을 모두 사용을 하는 API서버를 만들어 보고 싶었다.
기본적으로 사용한 툴은 다음과 같다.
-
Kafka
-
ElasticSearch
-
gRPC
-
Docker
-
Mongo
해당 툴에 대해서는 아래에서 따로 다루어 볼 예정이다.
프로젝트 구조 및 시작법
나는 모든 툴에 대해서 Docker를 사용하여, 툴을 활용을 하였다.
ElasticSearch
모두 똑같이 Docker를 통해서 관리를 하고 싶었지만, Docker로 이미지를 띄우고 바로 연결을 시도하면, Node를 찾을 수 없는 이슈가 있었기 떄문에
해당 툴은 따로 Docker를 관리하는 명령어를 통해서 시작을 하게 되었다.
명령어는 다음과 같다.
# 1. 기존 컨테이너 제거
docker rm -f elasticsearch-docker
# 2. 새로운 컨테이너 실행
docker run -d -p 9200:9200 -p 9300:9300 \
-e "discovery.type=single-node" \
-e "ELASTIC_USERNAME="akaps"" \
-e "ELASTIC_PASSWORD="004"" \
--name elasticsearch-docker \
docker.elastic.co/elasticsearch/elasticsearch:7.14.0
Kafka
개인적으로 Pub/Sub방식은 굉장히 병렬적으로 처리가 가능한 구조라고 생각을 한다.
그리고 다양한 Pub/Sub툴 중에서 가장 유명한 Kafka를 도입을 해서 한번 활용을 해보았다.
Kafka같은 경우에는 Docker를 통해서 구동이 가능하기 떄문에, 자세한 부분은
docker라는 폴더를 확인하면 된다.만약 Kafka에 대한 메시지들을 모두 초기화 하고, 재시작을 하고 싶다면,
Golang을 통해서 초기화하는 로직을 구현을 해두었으니단순히
go run . -init=true로 프로젝트르르 실행하면, Flag가 인식을 하여,Kafka에 대한 이미지를 초기화 하고, 재 구동시킨다.
Mongo
실무에서 주로 사용을 하는 DB이기 떄문에, 사용을 하였다.
딱히 큰 이유는 없고.. 클러스터 만들기도 쉽고, ElasticSearch에 관심이 갔던 이유가, Mongo의
AtlasSearch를 실무에 적용을 하면서검색 엔진에 흥미가 갔기 떄문에, 그냥 자연스럽게 사용을 하였다.
gRPC
서버간 통신에 대해서 일반적인
http통신을 구현을 하고 싶지 않았다.그래서 최대한 리소스를 덜 먹을 수 있는
RPC통신을 사용하는것이 좋다고 생각을 하였고,적용을 하였다.
해당
gRPC프로토콜은 유저의 인증에 사용을 하고 있다.해당 유저의 데이터에 대해서도, DB를 통해서 관리가 되어야 하지만, 나는 사이드 프로젝트로 혼자서 해보는것이기 떄문에,
딱히 해당 부분은 고려하지 않았다.
프로젝트 구조
간단하게 draw.io 를 통해서 그림으로만 다루어 보겠다.
일반 검색 쿼리를 요청을 하는 경우에는 유저에 대한 Verify가 필요가 없다.
하지만 이외의 요청에 대해서는 사실 유저 Verify가 필요가 없기 떄문에, 따로 검증을 진행을 하지 않고, ElasticSearch에 바로 요청을 하게 된다.
하지만 DB를 업데이트 하는 경우에는 Verify를 먼저 진행을 하게 되고, 이 후, Kafka에 해당 이력을 전송을 한다.
이후, Kafka측에서 ElasticSearch에 channel을 통해서 메시지를 전송을 하고,
ElasticSearch는 해당 정보를 노드에 저장을 하게 된다.