6주 동안 실전 프로젝트를 진행하면서 학습한 내용을 기록하고, 팀의 리더로서 프로젝트 매니징 경험을 기록하는 시리즈입니다.
나혼자 일주일 돌아보기
Keep
- 책 읽기
Problem
- 체력이 국력이다..... 겁나 거창한데 뭔 소린지 알 거 같아요.... 텐션이 떨어지는 건 체력이 떨어지기 때문일거야😭
- 원래 이번주부터 코테 준비 스터디 하기로 했는데, 우리 팀 일정 관리 미숙으로 중간 발표 전까지 못하겠다고 양해를 구했다.. 프로젝트도 프로젝트지만 코테 준비도 해야지욧
Try
- 코테 스터디 열심히 참여하기
2차 기술 멘토링
Q & A
Q1. 데이터 파이프라인 구축에 관한 질문
ES에 데이터 밀어 넣는 여러 방식이 있는데, 대용량 데이터를 빠르게 넣기 위해 가장 효율적인 방법은 무엇이라고 생각하시나요?
방법 1) Spring Batch + bulk API
방법 2) 로그스태시
방법 3) 비츠 + 인제스트 노드A1. 개발자에게 편한 방식대로 개발하면 된다고 생각합니다.
방법 1) 스프링부트, 스프링배치에서 API를 호출해서 데이터를 땡겨오고, 이걸 bulk API로 ES에 넣는 방식
- 스케줄러 등록해서 사용해도 된다.
1) @Scheduled 이용한 Batch 작업 (https://copycoding.tistory.com/305)
→ 다만, 쓰레드를 많이 잡아 먹는 단점이 있다.
2) 스케줄러 Quartz 사용 (https://pooney.tistory.com/99)
- Spring Batch 이해하고 사용하기
Spring Batch란? 이해하고 사용하기(예제소스 포함)
- 스프링 배치로 수집기를 만들 때는 서비스 개발 프로젝트와 분리해야 합니다.
방법 2) 자바에서 Excel 편집하는 POI 써서 .csv 파일로 변환하고, 그렇게 쭉 쌓아둔 파일을 로그스태시로 한번에 ES에 넣는 방식 → 현재 우리가 사용하려고 하는 방식!
💡시간이 넉넉하게 있다면 1번 방식으로 직접 수집기를 개발하는 것도 좋은 경험이 될 것이다!
Q2. 데이터 수집에 관한 질문
저희 팀의 최종 목표 데이터는 7500만 건이고, 현재 레퍼런스 사이트(키프리스)에 xml 파일 다운로드를 요청하는 url로 request를 보내면서 회 당 5000 건의 데이터를 수집할 수 있게 되었습니다. 현재는 파일로 최대 5000건의 데이터를 받을 수 있어 이 방식이 가장 효율적이라고 판단했는데, 이 방식보다도 더 효율적으로, 더 많은 양의 데이터를 받아올 수 있는 방법이 있을까요?
A2. 없습니다. 이 방식이 최선입니다.
Q3. 데이터 업데이트에 관한 질문
특허 상태를 계속 업데이트를 하기 위해서는 OPEN API를 사용 헤야 하는데, 저희의 예산으로는 서비스 이용수수료를 감당할 수 없습니다. 하지만 등록 정보였다가 공개로 바뀐 특허권을 서비스에 반영하지 못하면(업데이트X) 이는 온전히 서비스 책임인데 이 문제를 어떻게 해결해야 할까요?
A3. 명확한 정보가 아닌 점을 주의사항으로 명시하면 됩니다.
투자 서비스에서도 투자에 대한 정보를 제공할 때 이렇게 주의사항을 명시합니다.
“투자결정에 대한 책임은 전적으로 본인에게 있습니다.”
⇒ 찾아보니 키프리스에도 데이터 제공에 대한 안내사항이 있다. 
이런 형식으로 “키프리스에서 제공하는 데이터를 제공하지만, 그 데이터가 변경됐을지도 모르니 다시 한 번 확인하세요.”라고 주의사항을 명시하고, 키프리스로 리다이렉트 시켜서 사용자가 정보를 한번 더 확인하게 하면 될 듯!
Q4. UI 설계에 관한 질문
현재는 ‘제외 검색 하기’ 체크 박스를 통해 제외 검색을 할 수 있게 UI를 설계했는데, 생각해보니 만든 사람은 알지만 사용자는 이 기능을 어떻게 사용해야 하는지 모를 수도 있을 것 같습니다. UI적으로 어떻게 개선할 수 있을까요?
A4. 도움말이나 가이드처럼 설명을 만들어 두는 것도 나쁘지 않을 것 같습니다.
⇒ ❔버튼 hover 하면 어떤 기능인지 설명이 나오게 하는 방법도 좋을 것 같음!
Q5. 서버 운영에 관한 질문
서버는 DB의 고가용성을 위해 최소 3대를 써서 node를 나누는 것이 좋은 것으로 알고 있는데 구글링을 하여 다른 프로젝트들을 참고 해보니 data node의 경우 램 메모리 16~32 GB를 추천하는 것 같습니다. 그런데 저희의 서버 예산이 한정적인 상황에, 데이터 7500만 개라고 가정하면 서버를 몇 대 쓰는 게 적절한가요?
A5. [client -> ec2 -> nginx -> ES#1~3] 의 흐름으로 가면 됩니다.
- EC2 하나에 우분투 세 개(도커 세 개 각각에 엘라스틱 띄우기), 그리고 그 앞 단에 nginx 붙이면 된다.
- nginx가 프록시 서버 역할을 해줄 것이다. 바깥에서 요청이 들어오면 이 nginx가 로드밸런싱으로 vip(virtual ip)에 던져줄 것이다.
- ES 하나에 vip 하나, vip는 config에서 정할 수 있다. 지금 엘라스틱 세 개 띄워져 있으니, nginx가 vip에 던져준 요청을 vip 세 대 중 하나가 처리할 것임.
피드백
- 검색 서비스 개발팀과 데이터 팀을 나눠 분업을 명확히 하자.
- 검색 서비스 개발팀: 서비스를 개발하고, 데이터를 서빙한다.
- 데이터 엔지니어링 팀: 데이터를 수집, 가공하고 ES에 밀어 넣는다.
- 작업 순서:
1) 검색 서비스 개발 팀은 mock data를 만들어서 서비스 쭉 만든다.
→ mock data 만들어주는 라이브러리 많고 다양하다. 그걸 쓰면 된다!
→ 데이터를 화면에 어떻게 뿌려줄 지 논의하고, api 호출을 받으면 데이터를 어떻게 서빙할 지 고려해서 서비스를 개발한다.
2) 정형화된 mock data(예를 들어, json 형태)를 데이터 팀에게 전달한다.
3) 데이터 엔지니어링 팀은 전달 받은 mock data를 보면서 어떤 분석기를 쓰고, 어떻게 가공할 지 결정할 수 있다.
- DB Schema를 촘촘하게 설계하자.
- 키프리스 업그레이드 버전으로 잘 만들어 보면 좋을 것 같다!
느낀 점
와악!!!!!! 우리 팀 방향 설정은 맞게 했구나!!!! 우리 잘 하고 있구나!!!!!3일 동안 기획 변경 회의하고, 또 남은 3일 동안 기능 개발한다고 잠도 못 자고 노트북 끼고 살았는데..😭 그래서 컨디션 난조에 힘들어하는 팀원들도 있어서 맘이 너무 안 좋았는데..!!!! 그래도 다 같이 으쌰으쌰해서 달려온 보람이 있다!!!!!😄👍- MVP 발표까지 데이터 파이프라인을 구축하기에는 시간이 너무 촉박해서 현재 임시로 키바나 파일 업로드를 통해 ES에 데이터를 넣어뒀다. 그걸 가지고 검색 기능을 개발하면서 '아 데이터 파이프라인 구축되면 서비스 로직을 다 변경해야 할 수도 있겠네' 이런 생각이 들었다. 그런데 멘토링을 통해 Mock Data로 검증하면서 검색 기능을 개발하면 데이터 파이프라인 구축까지 기다리지 않아도 된다는 것을 알았다.
이 과정에서 DB Schema 설계도 촘촘히 이뤄질 것 같다.
