[4차 스프린트 - 백엔드] 4차 스프린트 계획

[Minjoo522]

논의가 필요한 내용

• 기능 개발 외 해야 할 것
• 각 기능 별 담당자

결론

• 서브 모듈 - 리브
• 테스트 개선 - 아톰
• 프로덕션 서버, dev 서버 분리 - 브랜치 분리 - 리브
• DB 서버 분리 - 릴리
• 로그인 개선 - 로빈

논의는 같이 해야 함

• 로그 레벨, 뭐 찍을지

같이 해야 하는 업무

• 따닥
• 리팩토링
• 인프라 구조도 논의

프론트랑 논의해야 하는 내용

• 컨텐츠 제작
• 프론트 인프라???

신경써야 할 것

• 코드리뷰 제대로하기

[le2sky]

우선순위

1. 따닥
2. 테스트 개선
3. 서브 모듈
4. 인프라 변경(변경에 의한 환경설정 정리)
5. 브랜치
6. 버저닝
7. 개발 문서
8. 어드민
9. 로깅 (알림, 프롬테일 추가? 혹은 간소화)
10. 스키마 관리
11. 기술 선택 이유 정리(ci/cd, github action)
12. 백엔드 회식

[Minjoo522]

1. 프로덕션 서버, dev 서버 분리
2. 프로덕션 서버에 H2가 아니라 실 운영할 DB 연결하기
3. 엔진엑스 모니터링
4. 로깅/모니터링 - 모니터링 좀 덜어내고 어떤 걸 로깅할건지 로그 레벨 어떻게 할 건지 확실하게 정해야 함

기타!

• 코드리뷰 제대로 하기
• 1, 2번을 하기 전에 먼저 구조도를 같이 작성하고 인프라 담당자가 그 구조도에 맞게 구현했으면 좋겠음.

[alstn113]

• 해시태그
• 댓글
• 대시보드(진행중, 완료 솔루션)
• 프로덕션 서버
• DB 분리
• 미션 시작 제출 코드 리뷰 및 리팩토링

[lilychoibb]

1. 버그 수정 및 리팩터링
2. 에러 발생 시 즉각 알 수 있게 인프라 구성
3. 기능 개발
4. 퀄리티 있는 미션 만들기
5. 배너에 들어갈 컨텐츠 만들기
6. 프로덕션 서버
7. DB 구축

[robinjoon]

모니터링 걷어내기

모니터링 시스템에서 어떤 정보를 얻어내는 것은 상당히 많은 지식을 공부해야 됨. 프로메테우스, 로키 쿼리 언어나, 통계적인 지식 공부 같은 것들.

따라서, HTTP 요청 관련 정보들을 모두 로그에 남기고, 로그 파일을 분석하는 방식으로 이 정보들을 얻어내는게 합리적이라는 생각이 들었음.

또한, 프론트에서 어떤 요청을 보냈을 때, 이에 대응되는 로그가 백엔드에 쌓일텐데, 정확히 어떤 요청에서 발생한 로그인지 알기 어려웠음. 이를 구분할 수 있는 로깅 방식을 도입해야 됨.

개인적으로 로키를 쓰는 것 보단, 로그 파일을 EC2에 생성하고, 시간 지나면 S3에 저장하는 방법이 좋을 것 같음. 파일 분석은 리눅스 명령어로 충분히 가능하기 때문! 로키를 도입하는 것은 기술 부채임.

백엔드 문제 만들기

말 그대로 문제를 만들어야 함.