6,7 장 정리 (#603)

Author: GeunJuLEE

2026/Fundamentals_of_Software_Architecture_2nd_Edition/geunju-lee/Chapter_6_to_7.md

@@ -0,0 +1,38 @@
+# 트레이드오프 위에서의 아키텍처 선택
+
+## 6 ~7장
+---
+
+## chapter 6 - 운영 데이터 분리
+이 작업은 꽤나 어렵다. 이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던거처럼 특정 테이블을 특정 서비스만 보게하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것이다.
+그 후에 api로 만들어 따로 떼어내거나 하는 방법이다.
+DB 분리에서 가장 큰 적은 transaction이다. 이 방법 때문에 SAGA 패턴도 쓰고, 여러 방식을 고민 했는데, 역시나 정답은 없다.
+그나마 제일 베스트가 SAGA 패턴을 활용하고, 카프카와 api call을 하고, 그 상태를 DB에 저장한 후, 배치까지 돌려 완벽한 보상을 하려고 노력하는 것이다.
+
+그다음 모든 DB의 데이터를 하나의 장소로 모아 대사를 할 수 있는 시스템을 만들어서 후처리를 완벽히 하는 것이 중요하다.
+
+그리고 여러 DB에 대해 이야기가 나오는데, 각 특성별로 쓰면 되지만 결국 중요도가 있다면 아직까지는 RDB를 사용하는거 같고, 
+로그나 엄청나게 중요하지 않지만 속도는 중요한 것에 대해서 key-value DB를 사용한다.
+
+## chapter 7 - 서비스 세분도
+역시나 정답이 없는 것에 대한 이야기다. 언제나 옳은 것은 없다. transaction을 어떻게 가져잘 것인가, 쪼갠다면 어디까지 쪼갤 것인가 등등 많은 고민이 든다.
+적정한 점을 찾는 것이 좋다. 그럼에도 불구하고 나는 가능한 transaction을 쪼개는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각한다. 
+
+예를 들면 billing 팀에서 쿠폰과 카드를 동시에 사용하는 결제 건이 들어와서 카드간편결제와 쿠폰팀에 api를 호출한 상황에서 쿠폰은 정상 소진되고, 카드간편결제 팀에서는 카드 한도로 인해 막힌 상황이 있다고 가정하자.
+이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 transaction이 깨지기 때문에 그냥 롤백되기 때문에 문제가 쉽게 해결된다.
+
+그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰에 대한 망취소를 날려줘야한다. 
+
+이렇게 보면 transaction이 참 좋아보인다. 그렇지만 이 회사가 점점 커져서 계좌간편, 포인트, 머니, 휴대폰, 티머니, 상품권 등등 여러 결제 수단이 생기고 그에 따른 팀이 생긴다면 그래도 이렇게 해야할까?
+
+결론적으로 transation을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 일이다.
+
+피할 수 있으면 피해도 좋다. 피할 수 있다면.
+
+그리고 이러한 상황 때문에 자꾸 reserve에 대한 뭔가가 나오는거 같다. reserve해서 돈이나 좌석이나 무엇인가를 lock 잡아놓고, 그거에 대한 seq를 부여한 다음 그 seq로 confirm api를 호출하면 lock 잡혔던게 처리되는 그런 시스템.
+
+### 논의사항
+ 
+### 경험 사례
+RDB를 써야하는데, DB 장애로 인한 서비스 장애를 줄이고 싶다면 multi shard DB인 vitess나 nbase-t도 나쁘지 않은거 같다.
+cKey를 통해 어떤 shard로 들어갈 지 결정되고, 이것은 shard 개수만큼 DB 장애에 대한 서비스 장애 확률이 낮아진다.