[TIL] 2021.11.20 최종 프로젝트 진행중 - 멘토링 / 프로젝트 주제 변경 / response 형식 변경

오늘은 바울 멘토님께 멘토링을 받는 날이다(10:30 ~ 11:00)

 

이번주 회고 내용 - 백엔드

• CI/CD 방법 공부, 보류(.gitignore적용방법 어려워서)
  • Git Action에 환경변수를 주는 방법이 있다 찾아보시길

 

• https 사설 인증 적용(백엔드 배포 서버)
  • 클라우드 프론트를 적용한건지? 직접 적용한건지? -> Open SSL 적용했다
  • NGrinder → JMeter 로 변경
    • 부하테스트는 JMeter를 제일 많이 사용한다. 사용방법만 좀 익숙해진다면 잘 쓸 수 있을 거다

 

백엔드 질문

• 디비조회 할때 100만개 중 하나를 찾아야 하면, 이런 성능개선은 어떻게...?
  • index를 잘 걸어주세요
  • 이거 한번 읽어보세요 : https://yurimkoo.github.io/db/2020/03/14/db-index.html
  • DB는 신경쓸 수록 할게 너무 많다..
  • where절을 잘 쓰자! where절에 index가 걸려있으면 훨씬 빨라진다.
  • ex) 사용자 테이블(이름, 핸드폰번호, ...)이 있다고 치자. 이름에 인덱스가 걸려있다고 하면 인덱스가 안 걸려 있을 때보다 더 빠르게 검색할 수 있다.
  • 한 테이블에 그렇게 많은 인덱스는 필요하진 않는다. where절 많이 쓴다고 다 인덱스를 걸면 안된다. 적절하게 사용하면 된다.

 

• 어떤 흐름으로 부하테스트를 진행해야 하는지...?
  • 부하테스트는 왜 한다고 생각하나요?
    • 나: ...성능 개선을 위해서..!? 사용자들이 좀 더 빨리 사용할 수 있도록..!
  • 서버에 계속 부하를 주게 되면 서버가 일을 잘 하다가 가끔 안 시킨 일을 할 때도 있다. 얼마나 접속을 버틸 수 있는지, 얼마나 요청을 버틸 수 있는 지 판단하는 것이 부하테스트이다.
  • 여러분의 서비스를 고민해봤으면 좋겠다. 부하테스트가 진짜로 필요한 서비스인지, 동시 접속이 많은 서비스인지, 해당하는 API의 요청이 많아야하는 서비스인지, ..
  • 두꺼운 삼성 노트북은 개인 블로그 10만 뷰까지 버틸 수 있다. 듀얼코어..! window8 간신히 올라가는 친구가 서버로 쓰인다면 이정도 성능을 가지고 있다.
  • 우리 회사는 적을 때 한 주에 1TB의 요청이 온다. 이럴 경우 테스트해서 배포하면 좋을 것 같다.
  • 우리 서비스를 잘 생각해보고 부하테스트를 적용하면 좋을 것 같다.
  • 접근이 많을 페이지가 무엇일까요? 
    • 목록 조회하는 페이지..!
  • 사람들이 가장 많이 접할 API가 무엇일지 생각보고 그것 먼저 테스트해보면 될 것 같다.

 

•  복잡한 쿼리를 native로 짰는데, 다 QueryDsl로 적용해야 하는지?
  • 그렇죠. native도 좋기도 하고.. 네이티브는 어떻게 사용한건가요?
    • Repository에 @Query를 사용했습니다.
  • 방법의 차이라고 생각한다. QueryDSL과 native query의 각각의 장단점이 있는데 그것들을 비교해보고 적용해보는게 좋다. QueryDSL을 읽어보고 적용 가능하겠다 하면 적용해보기.
  • 지금 시점에서 QueryDSL을 적용하는데 프로젝트에서 오류가 생긴다면 그 오류를 잡는데 일정이 늦어지고 서비스의 영향을 준다면 안 하는게 좋다.
  • 적용할 수 있는 부분 조금씩 바꿔가면서 테스트도 같이 진행한다면 좋을 것 같다.

 

• 서버 죽을 경우를 대비해야 하는가?
  • 네. 백엔드가 코딩이 빨리 끝나는 이유가 다른 것들 할 게 많기 때문이다.
  • 대비해야 할 경우가 많다. 서버 죽을 경우에는 어떻게 다시 살릴지, 우리가 수동으로 살릴지, 자동으로 살릴지 고민해야 하고, 서버 하나가 죽어도 다른 친구들이 알아서 밸런싱 될 수 있게 작업을 해야하는 지에 대한 고민도 필요하다.
  • 그럼 어떻게...해야할까요..?
    • AWS의 Cloud Watch(구름시계라고 부름..)라는 게 있다. 서버 지표를 계속 확인해주는 친구다. 알람 설정을 하면 서버가 죽었는지 얘기를 해준다. 그럴 때 들어가서 수동으로 처리하던가, 아니면 nginx의 로드밸런싱을 가지고서 서버 여러 대를 두고 한 대가 죽어도 나머지를 가지고 활용할 수 있도록 하는 방법이 있다. 왜 쓰는지, 어떻게 쓰는 지 읽어보면 화가 나기 시작한다..!! 잘 찾아보세요

 

• 로깅 남겨야 하는지? 하는 방법?(SLF4J?)
  • 로깅 중요합니다. 남겨야하는 로그 중 하나가 에러 로그이다. 리눅스는 잘 되는건 뭐라 안 하고 안 되는건 엄청 뭐라 한다. 안 되는 요소들을 파악하는 것이 중요하다.
  • Sentry라는 친구가 있다. 서버에 에러를 남기지 않더라도 자동적으로 에러를 캐치해서 리스트화해주는, 인풋 아웃풋을 남겨주는 친구이다. 사용해보면 에러 로그 추적하는 데 엄청 좋다는걸 알 수 있을 것이다.
  • 그게 아니면 log4j나 slf4j 같은 라이브러리로 로그 파일을 남기고(날짜별/시간별 등..) 직접 들어가서 확인해줘야 한다.

 

• 인프라를 신경 써야 되는지?
  • 백엔드의 대부분의 서비스는 작성되었나요?
    • 하긴 했는데, 예상치 못한 오류들이 생겨서 고치고 있습니다
  • 우선적으로 다 되었다고 생각할게요. 기본적인 서비스들을 뒷받침할 것들을 이제 생각하면 좋을 것 같다. 2주정도 남았으니 지금 당장 해볼 수 있는 것은 CI/CD와 서버 죽을 경우 대비해야되는 방법.
  • 개인적인 생각으로는 굳이 안 해도 된다. 해도 CI/CD 정도?
  • 필요를 느끼신다면 도와드릴 수 있다. 여쭤보실 때 답변해드릴 수 있다.
  • CI/CD는 중간발표쯤 신경써야 하는 것들인 것 같다.

 

 

---

후...프로젝트 주제가 또 바뀌었다

우리 프로젝트는 카페 음료의 커스텀 레시피를 공유하는 사이트였다.

하지만 카페 공유 사이트로 바꾸는 것이 어떤지? 라는 의견이 나왔다.

이유는..뭐였지..?

레시피 공유 보다 카페 공유가 사람들이 좀 더 많이 쓸 것 같다는 이유였던거 같다

사실 마음 한 켠에 걱정이 있었다

레시피 공유 사이트지만, 결국 나중엔 글이 잘 안 올라올 것 같았다.

사람들이 매일매일 커스텀 레시피를 먹지 않을 테고, 매일매일 생각해내는 것도 사실상 힘들다.

초반엔 글이 많이 올라올지라도, 몇 주 지나면 글이 잘 안 올라오고, 올라와봤자 게시판 쪽 글만 올라올 것 같다.

결국 카페 공유로 바뀌었다.

주제가 바뀜으로 인해, 사용자들이 좀 더 많을 것이라는 생각에 좀 좋았지만, 

주제에 맞춰 디자인 등 바뀌어야할 것들이 많다.

디자인은 사실 프론트에 영향이 있어, 백엔드는 걱정할 부분은 아니긴 하다..

모르겠다.. 좋은것 같기도 하면서 안 좋은 것 같기도 하고..

타격이 꽤 있다..

디자이너분들의 의견에 우리 개발자들이 너무 휘둘리는 것 같기도 하다..

복잡미묘하다..ㅎ

주제를 또또 바꾸는게 과연 잘 한 것일까...?

우리 조만 너무 자주 바뀌는 것 같다

 

 

프로젝트 이름도 바꿨다

끼니즈(운동 관리 사이트) -> 내시피(카페 음료 커스텀 레시피 공유 사이트) -> 이카페어디야(카페 공유 사이트)

 

ㅎㅎ...

악ㄱ모르겠다진짜

좋기도 하고 안 좋기도 한 이 기분....몰라...

 

 

---

프론트에서 지속적인 얘기가 나왔다

백엔드에서 API의 response 형식이 이랬다

@AllArgsConstructor
@NoArgsConstructor
@Getter
public class CustomResponseDto<T> {
    private int code;
    private String message;
    private T data;
}

API의 로직을 정상적으로 실행했고 정상적인 결과가 나온다면 code: 1, 로직에서 문제가 생겨 exception이 나타나 비정상적인 결과가 나온다면 code: -1로 response 하고 있었다

하지만 code가 -1이라도 상태코드가 200으로 response하는 경우가 있다

이럴 경우 프론트에서 에러를 잡는 것이 어려워진다고 한다

200이 아닌 경우 try-catch에서 catch문으로 빠지게 된다는데 200인 경우 catch문으로 빠질 수 없어 try에도, catch문에도 각각 예외처리를 해야한다고 한다

나도 지금까지 마음에 걸렸었다(?)

토큰이 사라져서 만료되었다는 내용이나, 아이디/비밀번호를 잘못 입력했다던가 등 이런 내용은 따로 다른 코드로 넘겨줘야 프론트에서 '이런 코드일 때 이런 처리를 한다'라고 할 수 있을것 같았기 때문이다

하지만 다른 백엔드 분들은 코드가 -1로 respone하더라고 message에 정확한 에러 내용을 담아서 알려주기 때문에 message를 보면 되지 않냐 라고 하셨다

그리고 response를 200, 400, 500 등으로 하거나 1, -1로 하는 등 코드를 어떤 식으로 response를 할 지는 회사 by 회사라고 한다. 멘토님도 실제로 그렇게 말씀하시긴 했다

프론트분들이 처음부터 response 형식을 프론트에서 필요한대로 정했어야 했다고 말하셨다

프로젝트를 시작할 때 이렇게 될 줄은 전혀 몰랐다고 하신다

우리도 마찬가지다. 이렇게 될 줄은 초반엔 몰랐다.

프론트분들도 죄송하다고 하시면서 response형식을 바꿔달라고 하셨다.

그래서 바꾸는 작업을 했다

//게시물 등록
    @PostMapping("/boards")
    public ResponseEntity<?> createBoard(PostBoardRequestDto requestDto,
                                            @AuthenticationPrincipal UserDetailsImpl userDetails) 
                                            throws IOException {

        Long boardId = boardService.createBoard(requestDto, userDetails);

        if(boardId > 0) {
            return new ResponseEntity<>(
                new CustomResponseDto<>(1, "게시물 등록 성공", ""), HttpStatus.OK
            );
        } else {
            return new ResponseEntity<>(
                new CustomResponseDto<>(-1, "게시물 등록 실패", ""), HttpStatus.BAD_REQUEST
            );
        }
    }

ResponseEntity에 CustomResponseDto를 담아, 정상적인 response는 200, 비정상적인 respone는 400으로 response하도록 했다.