Conversation
|
우측에 있는 |
Summary of ChangesHello @GeunJuLEE, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 "소프트웨어 아키텍처 the hard parts" 책의 6장("운영 데이터 분리")과 7장("서비스 세분도")에 대한 학습 노트를 추가합니다. 데이터베이스 분리 전략, 분산 트랜잭션 관리의 복잡성, 그리고 SAGA 패턴을 통한 보상 처리의 중요성에 대한 심층적인 내용을 다루며, 실제 경험 사례를 통해 아키텍처 결정 시 고려해야 할 실용적인 관점을 제시합니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
GeunJuLEE
added
2026
Software Architecture: The Hard Parts
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
이 Pull Request는 '소프트웨어 아키텍처 the hard parts' 책의 6장과 7장에 대한 요약 및 생각을 정리한 마크다운 파일을 추가합니다. 전반적으로 분산 시스템에서의 데이터 관리와 서비스 분할에 대한 깊은 고민이 담겨 있습니다. 다만, 내용의 명확성과 가독성을 높이기 위해 몇 가지 오타 수정, 용어 통일, 문장 구조 개선을 제안합니다. 특히 'transaction'과 같은 기술 용어의 표기를 일관되게 하고, 일부 모호한 표현을 더 구체적으로 다듬으면 좋겠습니다.
| 이 작업은 꽤나 어렵다. 이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던거처럼 특정 테이블을 특정 서비스만 보게하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것이다. | ||
| 그 후에 api로 만들어 따로 떼어내거나 하는 방법이다. | ||
| DB 분리에서 가장 큰 적은 transaction이다. 이 방법 때문에 SAGA 패턴도 쓰고, 여러 방식을 고민 했는데, 역시나 정답은 없다. | ||
| 그나마 제일 베스트가 SAGA 패턴을 활용하고, 카프카와 api call을 하고, 그 상태를 DB에 저장한 후, 배치까지 돌려 완벽한 보상을 하려고 노력하는 것이다. |
There was a problem hiding this comment.
문장의 가독성을 높이기 위해 몇 가지 표현을 다듬는 것을 제안합니다.
나왔던거처럼->나왔던 것처럼(띄어쓰기)transaction->트랜잭션(transaction)(용어 통일 및 명확화)고민 했는데->고민했는데(띄어쓰기)제일 베스트가->가장 좋은 방법은(중복 표현 수정)
또한, 문서의 전체적인 통일성을 위해 문체를 ~다 에서 ~입니다 로 변경하는 것을 고려해볼 수 있습니다.
| 이 작업은 꽤나 어렵다. 이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던거처럼 특정 테이블을 특정 서비스만 보게하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것이다. | |
| 그 후에 api로 만들어 따로 떼어내거나 하는 방법이다. | |
| DB 분리에서 가장 큰 적은 transaction이다. 이 방법 때문에 SAGA 패턴도 쓰고, 여러 방식을 고민 했는데, 역시나 정답은 없다. | |
| 그나마 제일 베스트가 SAGA 패턴을 활용하고, 카프카와 api call을 하고, 그 상태를 DB에 저장한 후, 배치까지 돌려 완벽한 보상을 하려고 노력하는 것이다. | |
| 이 작업을 그나마 쉽게 하는 방법은 이 책에서 나왔던 것처럼 특정 테이블을 특정 서비스만 보도록 제한하고, 해당 테이블과 관련된 모든 Join 쿼리를 없애는 것입니다. | |
| 그 후에 API로 만들어 따로 떼어내는 방법도 있습니다. | |
| DB 분리에서 가장 큰 장애물은 트랜잭션(transaction)입니다. 이 문제를 해결하기 위해 SAGA 패턴을 비롯한 여러 방식을 고민했지만, 역시나 정답은 없었습니다. | |
| 가장 좋은 방법은 SAGA 패턴을 활용하고, Kafka와 API 호출을 사용하며, 그 상태를 DB에 저장한 후 배치 작업까지 실행하여 완벽한 보상을 하도록 노력하는 것입니다. |
| DB 분리에서 가장 큰 적은 transaction이다. 이 방법 때문에 SAGA 패턴도 쓰고, 여러 방식을 고민 했는데, 역시나 정답은 없다. | ||
| 그나마 제일 베스트가 SAGA 패턴을 활용하고, 카프카와 api call을 하고, 그 상태를 DB에 저장한 후, 배치까지 돌려 완벽한 보상을 하려고 노력하는 것이다. | ||
|
|
||
| 그다음 모든 DB의 데이터를 하나의 장소로 모아 대사를 할 수 있는 시스템을 만들어서 후처리를 완벽히 하는 것이 중요하다. |
There was a problem hiding this comment.
'대사'라는 단어의 의미가 모호합니다. 데이터 정합성을 맞추는 '비교' 또는 '검증'의 의미로 사용하셨다면, 더 명확한 단어로 변경하는 것이 좋겠습니다.
| 그다음 모든 DB의 데이터를 하나의 장소로 모아 대사를 할 수 있는 시스템을 만들어서 후처리를 완벽히 하는 것이 중요하다. | |
| 그다음 모든 DB의 데이터를 하나의 장소로 모아 비교/검증할 수 있는 시스템을 만들어 후처리를 완벽히 하는 것이 중요합니다. |
| 역시나 정답이 없는 것에 대한 이야기다. 언제나 옳은 것은 없다. transaction을 어떻게 가져잘 것인가, 쪼갠다면 어디까지 쪼갤 것인가 등등 많은 고민이 든다. | ||
| 적정한 점을 찾는 것이 좋다. 그럼에도 불구하고 나는 가능한 transaction을 쪼개는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각한다. |
There was a problem hiding this comment.
문장에 오타가 있고, 표현을 조금 더 명확하게 다듬으면 가독성이 향상될 것 같습니다.
가져잘->가져갈(오타 수정)transaction->트랜잭션(용어 통일)
| 역시나 정답이 없는 것에 대한 이야기다. 언제나 옳은 것은 없다. transaction을 어떻게 가져잘 것인가, 쪼갠다면 어디까지 쪼갤 것인가 등등 많은 고민이 든다. | |
| 적정한 점을 찾는 것이 좋다. 그럼에도 불구하고 나는 가능한 transaction을 쪼개는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각한다. | |
| 역시나 정답이 없는 이야기입니다. 언제나 옳은 것은 없습니다. 트랜잭션을 어떻게 가져갈 것인가, 나눈다면 어디까지 나눌 것인가 등 많은 고민이 듭니다. | |
| 적정한 지점을 찾는 것이 좋습니다. 그럼에도 불구하고 저는 가능한 트랜잭션을 나누는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각합니다. |
| 적정한 점을 찾는 것이 좋다. 그럼에도 불구하고 나는 가능한 transaction을 쪼개는 대신 SAGA 패턴을 사용하여 얼마나 잘 보상하는가가 중요하다고 생각한다. | ||
|
|
||
| 예를 들면 billing 팀에서 쿠폰과 카드를 동시에 사용하는 결제 건이 들어와서 카드간편결제와 쿠폰팀에 api를 호출한 상황에서 쿠폰은 정상 소진되고, 카드간편결제 팀에서는 카드 한도로 인해 막힌 상황이 있다고 가정하자. | ||
| 이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 transaction이 깨지기 때문에 그냥 롤백되기 때문에 문제가 쉽게 해결된다. |
There was a problem hiding this comment.
~때문에가 반복되어 문장이 어색하게 느껴집니다. 문장 구조를 변경하여 가독성을 높이는 것을 제안합니다.
| 이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 transaction이 깨지기 때문에 그냥 롤백되기 때문에 문제가 쉽게 해결된다. | |
| 이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 단일 트랜잭션으로 처리되어 실패 시 롤백되므로 문제가 쉽게 해결됩니다. |
| 예를 들면 billing 팀에서 쿠폰과 카드를 동시에 사용하는 결제 건이 들어와서 카드간편결제와 쿠폰팀에 api를 호출한 상황에서 쿠폰은 정상 소진되고, 카드간편결제 팀에서는 카드 한도로 인해 막힌 상황이 있다고 가정하자. | ||
| 이 때, 만약 쿠폰 팀과 카드간편결제 팀이 없고, billing팀에서 모든걸 한다면 이것은 transaction이 깨지기 때문에 그냥 롤백되기 때문에 문제가 쉽게 해결된다. | ||
|
|
||
| 그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰에 대한 망취소를 날려줘야한다. |
There was a problem hiding this comment.
'망취소'는 내부 용어일 수 있어 의미가 명확하게 전달되지 않을 수 있습니다. '보상 트랜잭션 요청' 또는 '쿠폰 사용 취소 요청'과 같이 보다 보편적인 용어로 풀어쓰는 것이 좋겠습니다. 또한 '날려줘야한다'는 구어체 표현이므로 '요청해야 합니다'와 같이 문어체로 수정하는 것을 제안합니다.
| 그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰에 대한 망취소를 날려줘야한다. | |
| 그렇지만 예시처럼 billing 팀, 쿠폰 팀, 카드간편결제 팀이 있다면 billing 팀은 위 상황에서 쿠폰 팀에 해당 쿠폰 사용을 취소하는 보상 트랜잭션을 요청해야 합니다. |
|
|
||
| 이렇게 보면 transaction이 참 좋아보인다. 그렇지만 이 회사가 점점 커져서 계좌간편, 포인트, 머니, 휴대폰, 티머니, 상품권 등등 여러 결제 수단이 생기고 그에 따른 팀이 생긴다면 그래도 이렇게 해야할까? | ||
|
|
||
| 결론적으로 transation을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 일이다. |
There was a problem hiding this comment.
transaction에 오타가 있습니다. transation을 transaction으로 수정하고, 문체를 통일하는 것을 제안합니다.
| 결론적으로 transation을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 일이다. | |
| 결론적으로 transaction을 쪼개서 SAGA 패턴을 사용하는 것은 귀찮고, 힘들고, 불편하고, 생각할 게 많아지지만, 기업이 커지고 서비스가 많아지고 사람이 많아지고 팀이 많아지면 당연한 수순입니다. |
|
|
||
| 피할 수 있으면 피해도 좋다. 피할 수 있다면. | ||
|
|
||
| 그리고 이러한 상황 때문에 자꾸 reserve에 대한 뭔가가 나오는거 같다. reserve해서 돈이나 좌석이나 무엇인가를 lock 잡아놓고, 그거에 대한 seq를 부여한 다음 그 seq로 confirm api를 호출하면 lock 잡혔던게 처리되는 그런 시스템. |
There was a problem hiding this comment.
'뭔가가 나오는거 같다'는 표현이 모호하고, 문장이 불완전하게 끝나 내용을 이해하기 어렵습니다. 'reserve & confirm 패턴'과 같은 구체적인 용어를 사용하고 문장을 완성하면 전달력이 높아질 것 같습니다.
| 그리고 이러한 상황 때문에 자꾸 reserve에 대한 뭔가가 나오는거 같다. reserve해서 돈이나 좌석이나 무엇인가를 lock 잡아놓고, 그거에 대한 seq를 부여한 다음 그 seq로 confirm api를 호출하면 lock 잡혔던게 처리되는 그런 시스템. | |
| 그리고 이러한 상황 때문에 'Reserve and Confirm' 패턴과 같은 개념이 등장하는 것 같습니다. 먼저 리소스(돈, 좌석 등)를 예약(reserve)하여 선점(lock)하고 고유 식별자(seq)를 발급합니다. 이후 해당 식별자를 사용해 확정(confirm) API를 호출하면 예약된 리소스가 최종 처리되는 방식의 시스템을 의미합니다. |
| RDB를 써야하는데, DB 장애로 인한 서비스 장애를 줄이고 싶다면 multi shard DB인 vitess나 nbase-t도 나쁘지 않은거 같다. | ||
| cKey를 통해 어떤 shard로 들어갈 지 결정되고, 이것은 shard 개수만큼 DB 장애에 대한 서비스 장애 확률이 낮아진다. |
There was a problem hiding this comment.
문장의 가독성과 명확성을 높이기 위해 몇 가지 수정을 제안합니다.
vitess,nbase-t와 같은 고유명사는 대문자로 시작하는 것이 일반적입니다 (Vitess,Nbase-T).cKey가 'sharding key'를 의미하는 것이라면, 더 명확한 용어를 사용하는 것이 좋습니다.- 마지막 문장은 의미를 더 명확하게 전달하도록 구조를 변경할 수 있습니다.
| RDB를 써야하는데, DB 장애로 인한 서비스 장애를 줄이고 싶다면 multi shard DB인 vitess나 nbase-t도 나쁘지 않은거 같다. | |
| cKey를 통해 어떤 shard로 들어갈 지 결정되고, 이것은 shard 개수만큼 DB 장애에 대한 서비스 장애 확률이 낮아진다. | |
| RDB를 사용하면서 DB 장애로 인한 서비스 장애를 줄이고 싶다면, Vitess나 Nbase-T와 같은 멀티 샤드(multi-shard) DB를 고려하는 것도 좋은 대안이 될 수 있습니다. | |
| 샤딩 키(sharding key)를 통해 데이터가 분산될 샤드가 결정되므로, 특정 샤드에 장애가 발생하더라도 다른 샤드는 영향을 받지 않아 전체 서비스 장애로 이어질 확률이 낮아집니다. |
2 participants
No description provided.