1주차 멘토링 일지

✔️ 멘토링 아젠다

진행상황 및 참고 자료

멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.

• 깃헙 레포지토리
• WatchDucks 노션
• 1주차 프로젝트 기획 현황 (발표 자료)

논의 사항 및 질문

• 저희 주제 괜찮을까요..?
  • 실현 가능성(규모, 비용)
  • 해당 서비스의 필요성(굳이 이걸 만들어야하나?)
  • 보안이나 성능적으로 생각 못한 문제가 있을지
• 아웃 바운드 트래픽이 2번 발생합니다. (클라이언트 → 프록시, 프록시 → 유저)
  • 추가적인 네트워크 비용이 발생하게 되며 여러 클라이언트가 서비스를 이용할 경우 부담이 클 것
• WatchDucks의 NameServer(1,2차)를 사용하지 않을 수도 있습니다.
  • 사용자가 WatchDucks가 아닌 다른 네임 서버를 3,4차로 등록한다면
  • 이런 경우 트래픽 측정불가가 예상됨
  • Client가 WatchDucks만을 사용할 수 있게 무중단 배포로 해결?
• 저희 계획 괜찮을까요..?

✔️ 멘토링 내용

멘토링을 진행하며 나눈 이야기가 휘발되지 않게 기록해보세요.

멘토님이 도움을 줄 수 있는 내용

성호님께는 죄송하지만.. 프론트엔드 지식은 부족

다양한 클라우드를 다룹니다. 제품을 클라우드에서 사용할 수 있게 하는 역할을 맡고 있습니다.

성수 튜링의 사과 장소 어떨지~

멘토님 질문 리스트

1. 어떤 데이터를 수집하고 싶은 건가요?
   • 저희는 트래픽 위주로 수집할 예정인데, 네임 서버만을 사용하면 캐싱되어 트래픽이 쌓이지 않는 것을 확인했습니다!
   • 따라서 프록시 서버를 두기로 결정하였습니다.
2. 기존의 shlink 애플리케이션과 어떤점이 다르나요?
   • 보여지는 데이터가 조금 다릅니다. 저희는 트래픽, 요청의 성공률들을 수집하고이를 보여주려고 합니다.
   • 또한, 부스트캠프 프로젝트들의 데이터를 비교하여 보여주는것에 목적이 있습니다.
3. 캐싱을 사용하지 않으면 다른 서비스의 트래픽을 모두 감당하게 될텐데 그 부분 해결책이 있는지
4. 브랜치 룰을 보았는데, 서비스 특성상 빠르게 배포가 되어야 할 것 같습니다. 메인 전 테스트를 위한 릴리즈 브랜치에 대해 생각해보신 바가 있나요?

무중단 배포의 필요성

• 고민하신 게 좋습니다! 서비스 특성도 예측이 어려우니 더더욱 필요할 것 같습니다.

스케일링

• 나름의 규칙 세워서 시도해보기
• 스케일링 많이 고려하면 좋을 듯 → 서버가 쉽게 죽을 수 있음.
• 트래픽이 일정하지 않게 많이 몰릴 때가 있는 데, 모든 트래픽을 받기 때문에, 모든 상황 고려 필요
• 오토 스케일링까지 고려해야할까요?
  • 적어도 어떻게 하면 서버가 스케일링 가능하게 만들지 고려해보세요.

보안관련

• 보안관련해서 신경을 썼으면 좋겠다.
• 외부망? 내부망? (잘 이해 못했어요..)
  • Sentry와 Datadog 등
  • 외부망을 사용하는 서비스도 있으니 그렇게 걱정할 필요 X
• 로그인 없어도.. 괜찮지 않을까~ 통계만 보여주니~

아키텍처

• 프록시 서버나 네임 서버는 프레임워크 없이 간단하게 구현하려 합니다. ⇒ 굿
• 데이터베이스는?

  • 특히 로그는 어디에 저장해야할까요? 컬럼기반DB vs 엘라스틱서치

  • 엘라스틱 서치는 영구적으로 저장하는 것으로 보기는 어렵습니다. 전부 메모리에 올렸다 내리는 비용 고려해야 합니다.

  • 멘토님: 어느 정도까지의 정확성을 고려하려 하나요? 트래픽이 몰렸을 때.

  • 로그 데이터는 삭제될 일도 없으니 정확성/실시간성을 너무 엄격하게 고려하진 않으려 합니다.

    ⇒ 굿. 읽기/쓰기 비율 등 잘 고려해보세요.

서버 스펙

• 현재 4코어 8GB인데, 2코어 4GB * 2가 나을까요?

  ⇒ 멘토님 생각에는 하드웨어 문제는 잘 없을 것. 인스턴스 한 대만 죽는 경우는 흔치 않습니다. 차라리 인스턴스 한 대에서 서버 여러개 띄우는 게 낫지 않을까 싶네요.

• 로그 수집 데이터베이스

  ⇒ 여러분이 만든 것보다 인스턴스에 올라간 DB서버는 강력합니다. 여러분 서비스가 먼저 죽어요!

실현 가능성, 완성도

최소한의 기능이라도 최대한 빠르게 찍어내서 다른 캠퍼들이 바로 사용할 수 있게 만들어내고, 맞춰가며 성능 높여가는 게 이상적인 사이클 같습니다.

완성할 수 있지 않을까요? 재밌을 것 같아요~

로그 수집/시각화 서버

수집은 각각의 에이전트 붙이고, 시각화는 별도의 서버에서 해도 괜찮을 것 같습니다.

로그뱃과의 차이점

설치 없이 사용한다는 점 큰 이점이지 않을까.

보통 클라이언트마다 별도의 에이전트가 있는 이유는 상황을 한정하기 위함. + 실행 상의 로그 & 라이선스 문제

↔ 프록시 서버는 중앙 집중된 형태.

추가 기능) 트래픽을 바탕으로 클라우드 비용 예상

가능할까요?

⇒ AWS와 달리 NCP는 없는 기능이니 만들면 좋을 것 같습니다.

트래픽, 용량, 과금체계 여러가지 조합해서 만들면 좋을 것 같아요. 기능 사이즈가 큽니다. 후순위!

멘토님 추천 자료

• https://wslog.dev/naver-camp-project4

• 구현에 대해 아키텍처 참고

  https://github.com/shlinkio/shlink

• 로그 수집 도구들

  https://vector.dev/https://github.com/elastic/logstash

  https://github.com/fluent/fluentd

• 모놀리틱에서 무중단 배포 https://wslog.dev/naver-camp-project4

✔️ 결론 및 To Do

멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.

✔️ 체크리스트

1주차 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 팀원 및 멘토와 함께 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.

• 프로젝트 기획과 설계의 뼈대가 나왔다.
• 프로덕트 backlog가 제작되었다.
• 서비스 핵심 기능에 대한 완성도의 기준 또는 기술적 목표가 수립되었다.
• 현실성 있는 계획이 수립되었다.