Today I Learned
날짜
2023년 12월 28일 목요일
내용
매 주, shop의 review에 관해 발생한 변화들을 담은 메일을 발송해야 한다. 어제 가진 의문들에 대해 집중적으로 고민한 덕에 많이 진행됐다.
현재 발송하는 shop의 이름
각 메일에는 수신하는 shop에 대한 정보가 담겨야 한다. 그렇다면 그 샵의 정보를 통해 조회하여 담아야 하는데 어떻게 알 수 있을까에 대해 고민됐다. 조금만 고민해보니 정말 쓸데 없는 생각이었다. 모든 shop에 보내야하니 그냥 각 shop에 대해 필요한 정보를 다 가져와야 했다.
Redis
이메일을 발송하는 로직은 Shop 서버에 구현되어 있고, 우리 서비스의 DB는 샵과 리뷰가 별개로 구성되어 있다. 그렇다면 메일에 담을 리뷰에 관한 데이터 요청을 리뷰 서버에 보내야 한다. 우리 서비스에 있는 두 개의 DB 간에 Redis로 연결되어 있다는 말을 들었을 떈 그냥 그런가보다 하고 넘겼는데, 이번 기회에 왜 그렇게 되있는지 많이 생각하게 되었다.
Redis에는 key와 value가 저장되어 있는데, key는 shop에 대한 간략한 정보들이 문자열로 저장되어있다. id나, Access Code, URL 등등을 이어서 만들었다. 매핑된 value는 shop에 대한 구체적인 정보가 담긴 json이다. 하지만 여기에는 review에 대한 정보는 따로 담겨있지 않았다.
그렇다면 지금 shop 서버에서 review에 대한 데이터가 필요한 나는 결국 review 서버에 데이터를 요청해야 한다. shop 서버에서 review 서버의 데이터베이스에 접근할 수 없는 건 당연한거니까. 그럼 redis에 굳이 shop에 관한 값들을 저장해두는 이유는 뭔지 궁금했는데, 반대의 경우에는 꽤 유용하지 않을까 싶다.
우리 서비스에서 가장 핵심적인 데이터 하나를 꼽으라면 난 아마 shop일 것 같다. 모든 주문, 상품, 리뷰, 고객이 결국 shop으로 연결된다. 따라서 가장 자주 조회되는 것도 이 shop일 테니 redis에 shop을 등록하는게 맞는 것같다. review 서버에서 필요로 하는 shop에 대한 정보를 redis를 통해 빠르고 편리하게 얻을 수 있도록. 샵에 비해 리뷰에 대한 레코드는 훨씬 더 많을 수 밖에 없는데, 이를 redis에 또 넣어놓으면 굳이 DB를 분리시켜 놓을 이유가 없다. DB가 분리된 상황에서, 가장 접근 빈도가 높은 shop에 대한 정보를 redis에 cache로 설정하여 접근성을 높인 거라고 판단했다. 내 Task는 shop에서 review 서버로 접근하다보니 이걸 체감하지 못했을 뿐인듯.
테스트
두 데이터베이스간의 관계를 이해한 덕에 그 이후는 조금 쉬워졌다. Shop 서버에서 요청을 보내면, Review 서버에서는 모든 shop에 대해 특정 조건에 알맞은 review들에 대한 정보를 반환하도록 해주었다. 위에서도 말했듯, 존재하는 shop은 redis를 통해 알 수 있었기 떄문에 shop 서버에서 review 서버로 요청을 보낼때 데이터를 담을 필요는 없었다.
2가지 난점에서 막혀있다.
-
어떻게 테스트할 것인가?
실서버에선 Amazon Simple Email Service로 설정하는데, 로컬에선 이메일이 잘 가는지 어떻게 테스트해야할지 모르겠다. 또, 데이터를 넣어 완성된 이메일 형식이 어떻게 생겨먹었는지도 볼 방법을 모르겠다.. 파일로 추출해봤자 값이 들어가지 않은 채 나오는데..
-
조건에 맞게 출력
메일에서 특정 문구는 조건에 따라 출력되지 않을 필요가 있었다. 어떤 정보 갯수가 0이라면, 굳이 메일에 이와 관련된 텍스트를 출력할 이유는 없으니까. 이 Task가 다 백엔드에서 이뤄지다보니 HTML 파일 내에서 해결해야 하나? 라는 생각이 든다. HTML 내에 JS를 설정해봐야겠다.
회고
내일이 올해 마지막 업무날인데, 내일까지 로컬에서 완성된 모습을 보고싶다. 노로 바이러스에게 질 수 없다.
