24년 1월 10일(수요일) - 68번째 TIL

 

오늘은 오전에 튜터님과 멘토링 시간이 잡혀서 미리 질문한 것들을 정리해서 갔었는데, 튜터님의 인터넷 상태가 고르지 못해,, 일단 적어둔 것을 글로 피드백 해주시고 저녁에 방문해서 질문을 받았다. 

 

정말.. 도움이 많이 되었다. 우선 우린 백엔드로 취업을 할 거여서, 쌩 EC2에다가 이것저것 구현하는 것보다 이미 잘 나와 있는 AWS의 서비스들을 잘 이용하고, 우리는 프로덕션 코드에 집중하는 것이 더 좋다고 하셨다. 

 

또 기획서는 꼭 버전 관리를 잘 해야 한다고 조언 받았다. 

 

아 그리고 나는 레디스를 담당하다 보니까 캐싱에 대해 궁금한 것들을 여러 개 질문했었는데, 그 중에 실제 상황에 가깝게 부하테스트를 해보고, 이를 토대로 어느 요소들을 캐싱해둘지, 또 캐싱 해둔다면 그 기준을 어떻게 잡아야 할지가 궁금했었다.

 

근데 우선, 실제 상황과 유사하게 테스트를 해볼 수 있지만, 부하테스트는 시스템의 견고성을 확인하는 거지 테스트 하는 것이 목적은 아니라고 하셨다. 

 

또한 캐싱은 스냅샷을 찍어서 저장할 수 있는 것과 상세 페이지의 정보들은 캐싱하는 것이 좋다고도 하셨고, 캐싱 하는 기준은 음 딱 정해진 것이 아닌 휴리스틱이라 개발자가 그때그때 판단을 한다고 했다. 

 

우선은 캐싱 없이 구현을 해보고, 첫 부하 테스트 이후 캐싱 했을 때의 개선율, 그리고 더 좋은 캐싱 전략이 있을지 고민을 해봐야 할 것 같다. 

 

백엔드 개발자로서 목표로 해야할 것은, 서버의 xx% 이상의 API가 0.x초 이하의 응답시간을 가지며, 높은 가용성을 가지도록 해야 하고, 그것을 이루기 위해 ~~한 기술을 썼다, 라고 말할 수 있어야 한다. 

 

또한 시계열 데이터인 시세 데이터가 있었는데, 이를 위해 시계열 데이터 특화 DB를 사용해볼까 했었는데 이것만을 위해 NoSQL을 도입하는 것은 너무 오버헤드가 크다고 했다. 실제로 유효하더라도 납득이 애매하다. 

 

라는 피드백을 받아서, 내일 아침에는 다시 기획부터 탄탄히 하고 또 AWS의 서비스를 적극적으로 활용하는 것을 고려해봐야 겠다.