백엔드 기술 부채 리스트업(2024.09.09)

[le2sky]

논의가 필요한 내용

2024.09.09 기준으로 백엔드팀의 기술 부채를 메모합니다.

리스트업

인증

• 이메일 인증 부재 (github 사용자 이메일이 비어있는 경우를 처리)
  • 인증 확장성 고려 (카카오 로그인.. etc)
• 리프레시 토큰 + 슬라이딩 세션

데이터베이스

• 개발 데이터베이스 스키마 관리(flway를 쓸지말지)
• 데이터베이스 인덱스
• 데이터베이스 RAID
• 데이터베이스 복구 전략

인프라

• 무중단 배포
• 로드 밸런싱
• 그라파나 앱 + 알림?

로그

• MDC 적용 여부
• 로그 저장 공간
• 로그 레벨 재정비

추가 기능

• 알림 개발
• 페이지네이션 -> @BatchSize -> hashTag n + 1
  • solution -> mission -> missionHashTag -> hashTag 에서 n + 1 문제 해결
  • offset vs cursor
• 좋아요, 스크랩
• PR 실제로 열렸는지 확인하기 -> github api
• 채점

기타

• 개발용 웹 페이지 보안
• 개발용 swagger 보안(#351)
• API 버저닝
• 어드민 + 어드민 보안
• data.sql이 아닌 코드로 작성
• MissionHashTag unique id

[robinjoon]

로그

로그를 어디에 저장할지, 얼마동안 저장할지는 논의의 우선 순위가 높지 않다고 생각합니다. 아직 로그가 쌓이지 않기 때문입니다. 급한건 어떤 요청을 누가 보내서 어떤 과정을 통해 응답이 생성되었는지 아는 것 입니다.

로그를 남기는 가장 큰 이유는 문제가 발생했을 때, 문제가 발생한 대상이 무엇이고, 누구에게 영향을 주었는지 확인하는 것입니다. 따라서, 지금 우리의 문제는 다음 두가지 입니다.

1. 유용한 로그를 남기지 않는 것
2. 하나의 요청에서 발생한 연속적인 로그를 식별할 수 없다는 것입니다.

따라서, 어떤 방식으로든 요청을 식별할 수 있어야 합니다. MDC를 통해 그런 기능을 제공할 수 있으니 도입해야 한다고 생각합니다. 나아가, 우리는 Nginx를 사용하므로 그 로그 역시 연속적으로 확인할 수 있어야 합니다. Nginx 에서도 로그를 남길 때 요청의 식별자를 포함시킬 수 있고, 이를 WAS로 넘길 수 있는 것으로 보입니다.

무중단 배포

운영 서버에서 무중단 배포를 할 수 있도록 준비해야 한다고 생각합니다. 다만, 그것이 EC2 레벨의 이중화를 통한 것은 과하다고 생각합니다. Nginx와 리버스 프록시를 이용해 Blue - Green 배포를 도입해야 한다고 생각합니다.

단, 이는 다가올 약한 런칭 기간에는 우선 적용하지 않고, 우테코 프리코스 특수를 노린 홍보 시점에 준비되어있으면 될 것이라 생각합니다.

데이터베이스

데이터베이스 스키마 관리는 해야 한다고 생각합니다. 잘못 했다가 배포 후에 큰 문제가 생길 수 있기 때문입니다. 데이터베이스 스키마를 관리하는 기술인 flway를 도입하는 것이 좋다고 생각합니다. 잠깐 찾아봤는데 관련 예시도 많아서 실험 및 적용하기 쉬울 것이라 판단합니다.

인덱스는 약한 런칭 전에 실제 실행되는 sql 기준으로 실행계획 확인 한 뒤 적절하게 걸면 될 것 이라 생각합니다. 당장은 데이터 양이 그리 많지 않아서 조금 잘못 걸려도 큰 문제는 없을것이라 생각됩니다.

데이터베이스 RAID는 결국 데이터베이스가 동작하는 디스크의 RAID를 의미하는 건데, RAID는 기본적으로 디스크의 용량과 데이터의 안정성, 그리고 IO 속도를 저울질하는 기술입니다. 데이터의 안정성을 높이기 위한 용도라면 다른 가용 영역에 DB용 EC2를 만들어 이중화 하는 것이 근본적인 해결 방식입니다.

추가 기능

PR이 실제로 열려있는지 확인하는 것은 별도의 API 연동 없이도 단순히 실제 그 주소(https://github.com/develup-mission/java-smoking/pull/1) 로 HTTP 요청 보낸 뒤 응답이 200인지만 확인하면 될 것 같아서 빠르게 할 수 있을 것이라 생각합니다.

알림 기능은 시간 남는 분이 있으면 개발과 도입을 해도 될거라 생각해요. 프론트쪽 UI 작업이 어느정도 되어있는 것으로 알아서... 알림 수단은 합의가 있어야 하겠지만, 지금 드는 생각은 카카오톡은 제외해야 할 것 같아요. 카카오톡으로 알림을 보낸다는 것은 스마트폰으로 알림을 확인하라는 것인데, 우리 서비스는 모바일 대응이 되어있지 않고, 앞으로도 계획이 없기 때문입니다.

페이지네이션은 약한 런칭 이후 데이터 추이를 보고 많은 영역부터 하면 좋을 것 같습니다.

나머지 기능들은 우테코 레벨 4 기간 내에 할 수 있을지 의문입니다.

개발용 웹페이지 보안

정말 단순히 생각한다면 HTTP basic auth 도입해서 보안 처리를 할 수 있을 것이라 생각합니다. Nginx 레벨에서 적용할 수 있어서 Swagger 보안은 확실히 할 수 있습니다.

개발 서버 보안은 지금 생각해보면 우리가 사업을 하는 것도 아니기 때문에 유출되지 말아야할 신규 기능을 생각할 수 없어요. 따라서, 실제 데이터가 연결되어있지 않기 때문에 접근 제한을 할 필요는 없을 것 같습니다.

[lilychoibb]

기술 부채 추가할 것

아래 쿼리 시 에러 해결 -> @Transactional 로 임시 조치, 원인 파악하기

private void createDiscussion(Mission mission, HashTag hashTag) {
        Member member = memberRepository.save(MemberTestData.defaultMember().build());

        Discussion discussion = DiscussionTestData.defaultDiscussion()
                .withMission(mission)
                .withMember(member)
                .withHashTags(List.of(hashTag))
                .build();

        discussionRepository.save(discussion);
    }

[robinjoon]

필수 요구사항이 변경되서 위에 적은 것도 다시 생각해야겠네요

[le2sky]

논의가 필요한 내용

2024.09.10 기준으로 백엔드팀의 기술 부채를 메모합니다.

리스트업

인증

• 이메일 인증 부재 (github 사용자 이메일이 비어있는 경우를 처리)
  • 인증 확장성 고려 (카카오 로그인.. etc)
• 리프레시 토큰 + 슬라이딩 세션

데이터베이스

• 개발 데이터베이스 스키마 관리(flway를 쓸지말지)
• 데이터베이스 인덱스
• 데이터베이스 복구 전략

인프라

• 무중단 배포
• 그라파나 앱 + 알림?

로그

• MDC 적용 여부
• 로그 저장 공간
• 로그 레벨 재정비

추가 기능

• 알림 개발
• 페이지네이션 -> @BatchSize -> hashTag n + 1
  • solution -> mission -> missionHashTag -> hashTag 에서 n + 1 문제 해결
  • offset vs cursor
• 좋아요, 스크랩
• PR 실제로 열렸는지 확인하기 -> github api
• 채점

기타

• 개발용 웹 페이지 보안
• 개발용 swagger 보안(#351)
• API 버저닝
• 어드민 + 어드민 보안
• data.sql이 아닌 코드로 작성
• MissionHashTag unique id

[le2sky]

++ 솔루션 조회 시 이메일 응답