뭔가 개선할 점이나 문제점 생각좀 같이 해줘
4년차 허접인데 어쩌다 창업해서 서비스 운영하려다보니까 물어볼 사람이 없다
--------
목표
msa를 하는 이유는 트래픽처리나 단일 실패지점을 없애려는 목적보단 서비스별 배포를 가능하게 하기 위한 목적이 큼.
이번에 뽑는 직원들한테 덜 중요한 서비스 맡겨버리려고
여러가지 마케팅 시도를 해보는 단계라 최대한 기본 비용을 낮추기 위해 최대한 서비스를 웬만하면 서버리스로 올리려고 함
redis, db 말고는 다 서버리스가 가능하더라고? opensearch는 서울리전에서 서버리스를 지원하지 않아서 도쿄리전에서 가져다 씀
서비스
서비스는 스프링부트로 만들어져있고 aws-serverless-java-container라는 라이브러리를 써서 http 요청을 받을 수 있게 되어있음,
graalvm 지원이 돼서 콜드스타트 시간은 어느정도 해결이 됨.
각 서비스가 grapqhl api를 제공하면서 sub graph로 작동해
오케스트레이터
클라이언트는 각 서비스에 graphql 요청을 보내는 게 아니라 graphql federation 서비스가 오케스트레이터처럼 작동해서
각 서비스에서 쿼리를 해옴.
cud 작업이 필요한 경우는 여러 서비스중 한 서비스에서 요청을 처리하고 이벤트를 퍼블리시해서 다른 서비스에게 알려서 데이터 일관성을 맞추도록 함
sqs broker
이게 제일 고민인데 더 나은 방법이 떠오르질 않음..
sqs 메시지를 서버에서 바로 처리하려면 큐를 폴링해오거나, sqs가 람다를 직접 호출하는 식으로 해야히는데
폴링을 하면 비용이 쿠버네티스에 올리는 것보다 더 나올 거라 폴링 방식은 탈락이고,
sqs가 서비스를 직접 호출하려면 스프링부트 서비스 내에서 http 요청인지 sqs 요청인지를 분기처리해야해서 복잡해질 것 같았음..
그래서 sqs의 메시지를 http요청으로 바꿔서 서비스에게 보내주는 브로커를 두기로 함
db,데이터
db는 인스턴스 하나만 쓸거고, 논리적으로만 분리할 예정임.
각 서비스가 어느정도 중복 데이터를 가지고 있고, 이벤트를 수신 받아서 데이터 일관성을 맞출 생각임.
예를 들어 모든 서비스에는 유저테이블이 있지만, 유저가 좋아요한 사진 목록은 검색 서비스 db에만 있고, 유저 포인트는 결제 서비스 db에만 있는 식인데
만약 유저 서비스에서 유저 삭제가 일어나면 해당 이벤트를 다른 서비스가 수신 받아서 각 db에서도 삭제하는 방식으로..
잘 몰라서 그러는데 db가 하나면 이렇게 하는 의미가 있어? msa에서 중요한 부분이 여러개의 디비의 분산 트랜잭션과 일관성일텐데 너무 편의를 위해 구성한거 같아
논리적으로는 분리되어있어
db 어짜피 논리분리되어있어서 나중에 추가하는데 그렇게 힘드나??
근데 이왕 채팅이나 뷰모델은 nosql이 낫지않나?
db는 딱히 여러 물리 인스턴스가 필요할 거 같지 않아서 일단 하나로 뒀음. nosql이 낫다는 건 성능면에서 말하는건가?