Skip to content

소프트웨어 아키텍처 the hard parts sprint 3 - 이근주 #603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
GeunJuLEE merged 1 commit into from
Feb 7, 2026
+38 −0
Merged

소프트웨어 아키텍처 the hard parts sprint 3 - 이근주 #603

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions .../Fundamentals_of_Software_Architecture_2nd_Edition/geunju-lee/Chapter_6_to_7.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# 트레이드오프 위에서의 아키텍처 선택

## 6 ~7장
---

## chapter 6 - 운영 데이터 분리
이 작업은 꽤나 어렵다. 이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던거처럼 특정 테이블을 특정 서비스만 보게하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것이다.
그 후에 api로 만들어 따로 떼어내거나 하는 방법이다.
DB 분리에서 가장 큰 적은 transaction이다. 이 방법 때문에 SAGA 패턴도 쓰고, 여러 방식을 고민 했는데, 역시나 정답은 없다.
그나마 제일 베스트가 SAGA 패턴을 활용하고, 카프카와 api call을 하고, 그 상태를 DB에 저장한 후, 배치까지 돌려 완벽한 보상을 하려고 노력하는 것이다.
Comment on lines +7 to +10
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

문장의 가독성을 높이기 위해 몇 가지 표현을 다듬는 것을 제안합니다.

  • 나왔던거처럼 -> 나왔던 것처럼 (띄어쓰기)
  • transaction -> 트랜잭션(transaction) (용어 통일 및 명확화)
  • 고민 했는데 -> 고민했는데 (띄어쓰기)
  • 제일 베스트가 -> 가장 좋은 방법은 (중복 표현 수정)

또한, 문서의 전체적인 통일성을 위해 문체를 ~다 에서 ~입니다 로 변경하는 것을 고려해볼 수 있습니다.

Suggested change
이 작업은 꽤나 어렵다. 이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던거처럼 특정 테이블을 특정 서비스만 보게하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것이다.
그 후에 api로 만들어 따로 떼어내거나 하는 방법이다.
DB 분리에서 가장 큰 적은 transaction이다. 이 방법 때문에 SAGA 패턴도 쓰고, 여러 방식을 고민 했는데, 역시나 정답은 없다.
그나마 제일 베스트가 SAGA 패턴을 활용하고, 카프카와 api call을 하고, 그 상태를 DB에 저장한 후, 배치까지 돌려 완벽한 보상을 하려고 노력하는 것이다.
이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던 것처럼 특정 테이블을 특정 서비스만 보도록 제한하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것입니다.
그 후에 API로 만들어 따로 떼어내는 방법도 있습니다.
DB 분리에서 가장 큰 장애물은 트랜잭션(transaction)입니다. 이 문제를 해결하기 위해 SAGA 패턴을 비롯한 여러 방식을 고민했지만, 역시나 정답은 없었습니다.
가장 좋은 방법은 SAGA 패턴을 활용하고, Kafka와 API 호출을 사용하며, 그 상태를 DB에 저장한 후 배치 작업까지 실행하여 완벽한 보상을 하도록 노력하는 것입니다.


그다음 모든 DB의 데이터를 하나의 장소로 모아 대사를 할 수 있는 시스템을 만들어서 후처리를 완벽히 하는 것이 중요하다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'대사'라는 단어의 의미가 모호합니다. 데이터 정합성을 맞추는 '비교' 또는 '검증'의 의미로 사용하셨다면, 더 명확한 단어로 변경하는 것이 좋겠습니다.

Suggested change
그다음 모든 DB의 데이터를 하나의 장소로 모아 대사를 할 수 있는 시스템을 만들어서 후처리를 완벽히 하는 것이 중요하다.
그다음 모든 DB의 데이터를 하나의 장소로 모아 비교/검증할 수 있는 시스템을 만들어 후처리를 완벽히 하는 것이 중요합니다.


그리고 여러 DB에 대해 이야기가 나오는데, 각 특성별로 쓰면 되지만 결국 중요도가 있다면 아직까지는 RDB를 사용하는거 같고,
로그나 엄청나게 중요하지 않지만 속도는 중요한 것에 대해서 key-value DB를 사용한다.

## chapter 7 - 서비스 세분도
역시나 정답이 없는 것에 대한 이야기다. 언제나 옳은 것은 없다. transaction을 어떻게 가져잘 것인가, 쪼갠다면 어디까지 쪼갤 것인가 등등 많은 고민이 든다.
적정한 점을 찾는 것이 좋다. 그럼에도 불구하고 나는 가능한 transaction을 쪼개는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각한다.
Comment on lines +18 to +19
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

문장에 오타가 있고, 표현을 조금 더 명확하게 다듬으면 가독성이 향상될 것 같습니다.

  • 가져잘 -> 가져갈 (오타 수정)
  • transaction -> 트랜잭션 (용어 통일)
Suggested change
역시나 정답이 없는 것에 대한 이야기다. 언제나 옳은 것은 없다. transaction을 어떻게 가져잘 것인가, 쪼갠다면 어디까지 쪼갤 것인가 등등 많은 고민이 든다.
적정한 점을 찾는 것이 좋다. 그럼에도 불구하고 나는 가능한 transaction을 쪼개는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각한다.
역시나 정답이 없는 이야기입니다. 언제나 옳은 것은 없습니다. 트랜잭션을 어떻게 가져갈 것인가, 나눈다면 어디까지 나눌 것인가 등 많은 고민이 듭니다.
적정한 지점을 찾는 것이 좋습니다. 그럼에도 불구하고 저는 가능한 트랜잭션을 나누는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각합니다.


예를 들면 billing 팀에서 쿠폰과 카드를 동시에 사용하는 결제 건이 들어와서 카드간편결제와 쿠폰팀에 api를 호출한 상황에서 쿠폰은 정상 소진되고, 카드간편결제 팀에서는 카드 한도로 인해 막힌 상황이 있다고 가정하자.
이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 transaction이 깨지기 때문에 그냥 롤백되기 때문에 문제가 쉽게 해결된다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

~때문에가 반복되어 문장이 어색하게 느껴집니다. 문장 구조를 변경하여 가독성을 높이는 것을 제안합니다.

Suggested change
이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 transaction이 깨지기 때문에 그냥 롤백되기 때문에 문제가 쉽게 해결된다.
이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 단일 트랜잭션으로 처리되어 실패 시 롤백되므로 문제가 쉽게 해결됩니다.


그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰에 대한 망취소를 날려줘야한다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'망취소'는 내부 용어일 수 있어 의미가 명확하게 전달되지 않을 수 있습니다. '보상 트랜잭션 요청' 또는 '쿠폰 사용 취소 요청'과 같이 보다 보편적인 용어로 풀어쓰는 것이 좋겠습니다. 또한 '날려줘야한다'는 구어체 표현이므로 '요청해야 합니다'와 같이 문어체로 수정하는 것을 제안합니다.

Suggested change
그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰에 대한 망취소를 날려줘야한다.
그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰 사용을 취소하는 보상 트랜잭션을 요청해야 합니다.


이렇게 보면 transaction이 참 좋아보인다. 그렇지만 이 회사가 점점 커져서 계좌간편, 포인트, 머니, 휴대폰, 티머니, 상품권 등등 여러 결제 수단이 생기고 그에 따른 팀이 생긴다면 그래도 이렇게 해야할까?

결론적으로 transation을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 일이다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

transaction에 오타가 있습니다. transation을 transaction으로 수정하고, 문체를 통일하는 것을 제안합니다.

Suggested change
결론적으로 transation을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 일이다.
결론적으로 transaction을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할 게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 수순입니다.


피할 수 있으면 피해도 좋다. 피할 수 있다면.

그리고 이러한 상황 때문에 자꾸 reserve에 대한 뭔가가 나오는거 같다. reserve해서 돈이나 좌석이나 무엇인가를 lock 잡아놓고, 그거에 대한 seq를 부여한 다음 그 seq로 confirm api를 호출하면 lock 잡혔던게 처리되는 그런 시스템.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

'뭔가가 나오는거 같다'는 표현이 모호하고, 문장이 불완전하게 끝나 내용을 이해하기 어렵습니다. 'reserve & confirm 패턴'과 같은 구체적인 용어를 사용하고 문장을 완성하면 전달력이 높아질 것 같습니다.

Suggested change
그리고 이러한 상황 때문에 자꾸 reserve에 대한 뭔가가 나오는거 같다. reserve해서 돈이나 좌석이나 무엇인가를 lock 잡아놓고, 그거에 대한 seq를 부여한 다음 그 seq로 confirm api를 호출하면 lock 잡혔던게 처리되는 그런 시스템.
그리고 이러한 상황 때문에 'Reserve and Confirm' 패턴과 같은 개념이 등장하는 것 같습니다. 먼저 리소스(돈, 좌석 등)를 예약(reserve)하여 선점(lock)하고 고유 식별자(seq)를 발급합니다. 이후 해당 식별자를 사용해 확정(confirm) API를 호출하면 예약된 리소스가 최종 처리되는 방식의 시스템을 의미합니다.


### 논의사항

### 경험 사례
RDB를 써야하는데, DB 장애로 인한 서비스 장애를 줄이고 싶다면 multi shard DB인 vitess나 nbase-t도 나쁘지 않은거 같다.
Copy link
Member

@jongfeel jongfeel Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

모임 때 vitess와 nbase-t 에 대해 자세한 설명을 해주시면 좋을 것 같습니다.

cKey를 통해 어떤 shard로 들어갈 지 결정되고, 이것은 shard 개수만큼 DB 장애에 대한 서비스 장애 확률이 낮아진다.
Comment on lines +37 to +38
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

문장의 가독성과 명확성을 높이기 위해 몇 가지 수정을 제안합니다.

  • vitess, nbase-t와 같은 고유명사는 대문자로 시작하는 것이 일반적입니다 (Vitess, Nbase-T).
  • cKey가 'sharding key'를 의미하는 것이라면, 더 명확한 용어를 사용하는 것이 좋습니다.
  • 마지막 문장은 의미를 더 명확하게 전달하도록 구조를 변경할 수 있습니다.
Suggested change
RDB를 써야하는데, DB 장애로 인한 서비스 장애를 줄이고 싶다면 multi shard DB인 vitess나 nbase-t도 나쁘지 않은거 같다.
cKey를 통해 어떤 shard로 들어갈 지 결정되고, 이것은 shard 개수만큼 DB 장애에 대한 서비스 장애 확률이 낮아진다.
RDB를 사용하면서 DB 장애로 인한 서비스 장애를 줄이고 싶다면, Vitess나 Nbase-T와 같은 멀티 샤드(multi-shard) DB를 고려하는 것도 좋은 대안이 될 수 있습니다.
샤딩 키(sharding key)를 통해 데이터가 분산될 샤드가 결정되므로, 특정 샤드에 장애가 발생하더라도 다른 샤드는 영향을 받지 않아 전체 서비스 장애로 이어질 확률이 낮아집니다.