우아한테크캠프 8주차 회고
8주차에는 TypeORM을 사용해서 백엔드 API 서버를 구축하는데 비중을 두었다.
그 중 내가 맡은 파트는 다음과 같았다.
JWT방식 로그인 시스템 구현
우리 서비스의 로그인은 JWT 방식을 활용했는데, 우선 다양한 로그인 방식과 그 차이점을 알아보자.
1. Session 인증방식
- 유저가 로그인 했을 때, 세션에 유저의 정보를 저장하고 해당 세션의 ID를 쿠키에 저장하는 방식.
- 이후 유저 정보가 필요한 요청을 하면(내가 쓴 리뷰, 구매목록 조회 등) 해당 세션에 담긴 유저의 정보를 갖고 해당 요청을 수행한다.
장점: HTTP 요청 중 쿠키가 탈취당해도, 세션 ID는 의미있는 값이 아니기 때문에 보안상 안전하다고 생각
단점: 세션 저장소를 사용하기 때문에 사용자가 늘어날 경우 서버에 부담이 된다.
2. JWT
- 유저가 로그인 했을 때, json 형식으로 된 유저의 정보를 토큰화 시켜 브라우저의 쿠키에 저장하는 방식.
- 이후 유저 정보가 필요한 요청을 하면 해당 토큰을 decode 후 요청을 수행한다.
장점: 서버에 별도의 인증 저장소가 필요없어서 서버의 부담을 덜어준다
단점:
3. OAuth
MiddleWare에서 매 요청마다 토큰을 분석해서 토큰이 담고있는 ID를 body에 담아 다음 각 컨트롤러로 넘겼다. 이 미들웨어에서 토큰만료시간이 종료되었을 때에는 Controller로 넘겨주지 않고 바로 Token Expired라는 메세지를 담아 응답을 주었다!
Elastic Search을 활용한 검색, 자동완성 구현
사실 이전에는 검색기능을 구현 할 때 보통 그냥 쿼리문에 LIKE %keyword%를 많이 사용했었는데 실제 현업에서는 검색할 대상이 많고 검색이 자주 일어날 때는 Elastic Search를 많이 사용한다고 한다.
그 이유는 다음과 같다.
1. 역색인 방식으로 인한 빠른 검색 속도
2. 형태소를 분리하는 등의 다양한 플러그인 (한글 검색에 유리)
- MySQL에서도 오라클 함수를 사용해서 구현은 가능
3. 데이터 로깅에 편리함
사실 우리 서비스에는 데이터가 그렇게 많지 않지만, 검색속도 향상을 체감 해보고싶기도 했고, 한번쯤은 배워보고 싶었던 부분이라 Elastic Search를 적용 해보기로 했다! 🙂 (시간관계상 LogStash와 Kibana까지는 연결하지 못했다...ㅠ) 정말 맛보기였지만 나름 의미있고 즐거운 경험이었다.
작동 방식을 간단하게 설명하자면 우선 백오피스에서 관리자가 새로운 상품을 추가하거나 삭제할 때, Elastic Search에 역색인 방식으로 데이터가 저장된다.
*역색인이란?
- 일반적으로 MySQL이나 다른 RDBMS에서는 데이터를 찾기 편하도록 index를 두고 거기에 대한 데이터를 저장하는 방식을 따르는데, Elastic Search에서는 데이터를 key값으로 하고 해당 id를 value로 갖는 역색인 방식을 사용한다.
예를 들어 연필이라는 단어를 포함하는 아이템들을 추가할 때 Elastic Search에서는 다음과 같이 저장된다.
'연필' ------- 32, 51, 129
이를 통해 우리는 '연필'이라는 단어를 검색 했을 때 어떤 제품들이 있는지 O(1)의 속도로 검색이 가능 한 것!!
여기서 상품의 제목만 key가 된다면 '연필'이라는 상품을 추가했을 때, 유저가 '연'이라는 단어만 검색한다면 '연필'이 검색이 되지 않는다.
때문에 원하는 조건에 맞는 검색결과를 출력하기 위해 검색 값을 정제하는 과정이 필요한데, 이를 도와주는 것이 분석기(Analyzer)다. 분석기는 해당 단어를 분해하고 (Tokenize), 분리된 단어들을 검색 가능 하도록 가공(Token Filt)하는 과정을 거친다.
그래서 원하는 Analyzer를 세팅하고 Index에 맵핑시키는 과정을 진행에서 깨나 애먹었는데, 우리팀은 jaso라는 Plugin을 설치해 형태소단위로 분리하는 Analyzer를 사용했다.
이제 '연필'이라는 상품을 추가한다면 'ㅇ', 'ㅕ', '여', 'ㄴ', '연','ㄴㅍ', 'ㅍ', '피', '필', 'ㅣㄹ', 'ㄹ' 등 수없이 쪼개진 형태소들이 key로 형성이 되어 저장이 된다.
위를 보면 알다시피 빠른 검색을 위해 데이터를 추가하는 과정은 많은 비용을 소모한다. 그래서 데이터가 자주 변경 될 수 있는 상품 특성상 상품의 이름와 아이디만 ElasticSearch data에 담고 검색 후 나머지 데이터들은 DB에서 JOIN해서 가져오도록 구성했다.
8주차에는 백엔드 위주로 진행하다 보니 시각적인 변화는 크지 않아 조금은 더딘 느낌이 들었지만, 다음주가 되면 좋은 성과가 있을거라 기대한다!