Day 69. 중간 발표로 쉼표를 찍어보자.

드디어 오늘 중간 발표가 있었다. 어떤 기술 면접 질문이 들어오게 될지 걱정반 기대반인 상태로 우리 리더가 발표를 해주었다. 발표 준비를 도와주면서 내가 발표를 하게 되면 어떻게 대답할 지 함께 고민할 수 있어서 나에게도 성장의 발판이 될 수 있었다. 

우리가 예상했던 건 우리 서비스의 아키텍쳐를 보고 "카산드라"를 왜 도입했는지 물어볼 것 같았다. 음.. 사실 이 이유는 아직 찾지 못했다. 단순히 db를 옮기자는 의도로 시작해서 일단 뭐라도 해보자는 심정이 컸기 때문에 어떻게 찾아보다가 다른 팀원이 제시한 의견이었다. 해결책은 아니었으나 일단 db를 옮겨놓은 상태였기 때문에 설정을 바꾸기엔 턱없이 짧은 시간이어서 그대로 두었다. 그래서 이 질문이 들어오면 어쩌지 하는 마음이 많았는데 다행히 이 질문은 들어오지 않았다. 중간 발표를 하고 추가적으로 받은 피드백을 정리해보려한다. 

 

- 테스트 코드에 대하여

  : 지금 우리의 테스트 코드는 메서드 위주로 작성했는데 메서드 뿐만 아니라 모든 예외를 catch 할 수 있어야한다. 예를 들면 중간에 exception을 억지로 던져보는 테스트코드도 필요하다. 또한 DB를 읽어오면서 처리하는 내용을 반환해주는데 만약 우리가 예상한 데이터가 없을 때에는 어떻게 처리가되고 있는지도 파악해야한다. 조건이 맞지 않거나 DB에 예상과 달리 데이터가 없거나 엉뚱한 데이터가 담겨있는 일이 많으니 그런 것까지 테스트할 수 있어야한다.

 

- util 클래스

  : util성 클래스는 활용도가 높다. 아무곳에서나 필요하면 불러서 사용하기 때문에 무조건 null 값이 체크되어 있다고 볼 수 없다. 그렇기 때문에 util 클래스에는 그 메서드 안에서 null 체크를 해야만 null-safe한 코드를 구현할 수 있다. 지금 우리 메서드 중 TimeUtil에는 따로 null 체크가 되어있지 않으니 조금 더 높은 완성도를 위해서라면 그 안에서 추가해주는 것이 좋다.

 

- config properties

  : url이나 api 호출 주소 등 설정에 맞는 String 들을 properties 파일로 사용하는 것을 추천한다. ( 이것이 현업의 방식) + 비밀번호, api 키 값, 헤더 등을 보관해놓아야한다. 이런 것들은 보통 암호화하여 사용하고 AWS 에 키를 저장하는 서비스를 제공하고 있으니 그걸 사용해보는 것도 좋다.

 

++  (아마도 이 기능인 것 같음)

AWS Secrets Manager 

AWS Secrets Manager란 무엇인가요? - AWS Secrets Manager

 

- error log에 대하여

  : Info 레벨의 에러로그는 어떤 request가 들어오는지 user Id를 찍어보는 경우가 대부분이다. 또한 복잡한 로직에서 중간중간 찍어야할 필요가 있을 때 사용한다. Debug 레벨의 에러로그는 로직 중에 debug를 사용해 (코드의 흐름을?) 한 번에 파악하기 위해 찍어본다. 또한 null 값을 체크하기 위해 사용한다. 다음 Error 레벨의 에러로그는 catch 안에 로그를 한 번 찍고 던지는 경우가 일반적인 케이스이다. log관리도 중요하기 때문에 용도에 맞게 사용해보는 것을 추천한다.

 

---

이제 기술 면접 질문

 

1. 지금 서비스에 Redis를 사용했는데 mysql 과 다른 점은 무엇인지? ( in-memory DB와의 차이점이 무엇인가? )

: in-memory DB는 메모리에 데이터를 저장한다. 외부 저장 장치에 데이터를 저장하지 않기 때문에 메모리<->디스크 간 병목이 없다. 그래서 disk-based DB보다 속도가 훨씬 빠르다. 그리고 영속성을 보장하지 않기 때문에 서버가 다운되거나 갑자기 프로세스가 종료되면 데이터 유실 가능성이 크다. 또한 메모리에 데이터를 저장하기 때문에 저장 공간이 한정되어서 영속성을 보장 받을 필요가 없고 저장 공간이 많이 필요하지 않은 데이터를 적재하여 사용해야한다.  

(이러한 내용의 답변을 했는데 멘토님의 마음에는 썩 와닿지 않으셨던 것 같아 아쉬웠다...)

 

https://2kindsofcs.tistory.com/40

in-memory DB는 왜 더 빠를까

 

 

 

2. 현 서비스에서 트래픽에 대한 대비는 어떻게 하고 있나? 아직 대비가 되어있지 않다면 어떻게 할 것인지?

 -> 이 질문은 정말 예상하지 못하고 있었다. 대용량 트래픽 처리.. 말로만 들었지 진짜 고민해본적이 없었기 때문에 조금은 당황스러웠던 질문이었다. 한 두명이 테스트하기 위해 서버에 접근하는데도 pending 현상을 막지 못했던 우리였기 때문에.. 대용량 트래픽 처리? 전혀 생각도 못하고 있었다.

대용량 트래픽 처리를 위한 방법이 어떤게 있는지 앞으로 차차 고려해보려고 한다.

https://leonkim.dev/systems/scaling-100k/

10만명의 유저가 될때까지 백엔드 인프라 확장하기

 

---

 

진짜 3주동안 모든 팀원이 모든 것을 쏟아부으려고 한게 느껴져서 일단 오늘 내일은 주말을 좀 즐기고 오자고 했다. ㅎㅎ 많은 것을 보고 느끼고 또 해본 시간이었다. 그럼 즐거운 주말!!!!! 즐토 즐일 ❤️