소프트웨어 아키텍처 The Hard Parts 3주차 - 김영명#600
소프트웨어 아키텍처 The Hard Parts 3주차 - 김영명#600
Conversation
ymkim97
added
2026
Software Architecture: The Hard Parts
ymkim97
requested review from
TaeHyoungKwon,
aquamagic9,
dhlee3994,
fkdl0048,
hemil0102,
jintaeyeong,
jongfeel,
tttghost and
wooyaggo86
|
우측에 있는 |
Summary of ChangesHello @ymkim97, 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장(서비스 세분도)에 대한 학습 내용을 정리하고 개인적인 논의 의견을 추가합니다. 데이터베이스 분해의 복잡성, 폴리글랏 데이터베이스의 활용, 그리고 서비스의 적절한 크기를 결정하는 기준과 고려사항들을 다루며, 특히 분산 환경에서의 트랜잭션 관리 문제를 중요한 주제로 강조합니다. 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
| --- | ||
| ## 논의 내용 | ||
| * 서비스를 분리하면서 고려해야 하는 것 중 각자 생각하는 가장 큰 걸림돌이 무엇인지 의견이 궁금합니다. | ||
| > 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요한다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다. |
There was a problem hiding this comment.
중요한다는 중요하다의 오타로 보입니다. 수정하면 문장이 더 자연스러워집니다.
| > 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요한다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다. | |
| > 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요하다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다. |
| 분해의 반대로 데이터 통합인은 데이터 관계, 데이터베이스 트랜잭션을 생각할 수 있다. | ||
|
|
||
| 데이터를 분해하면서 생기는 가장 큰 골칫거리는 트랜잭션이라고 생각하며, 대다수의 엔지니어들이 동의하지 않을까 예상한다. | ||
| 모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능 하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다. |
There was a problem hiding this comment.
불가능 하기 때문에는 불가능하기 때문에로 붙여 쓰는 것이 올바른 띄어쓰기입니다. 가독성을 위해 수정하는 것이 좋습니다.
| 모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능 하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다. | |
| 모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다. |
|
|
||
| ## Chapter 7- 서비스 세분도 | ||
| 각 서비스의 크기를 정하는 것에 대한 내용이 주인 챕터다. | ||
| 서비스를 나누면 크기가 너무 작거나, 커질 수 도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다. |
There was a problem hiding this comment.
커질 수 도는 커질 수도로 붙여 쓰는 것이 올바른 띄어쓰기입니다.
| 서비스를 나누면 크기가 너무 작거나, 커질 수 도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다. | |
| 서비스를 나누면 크기가 너무 작거나, 커질 수도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다. |
| * 신장성 | ||
|
|
||
| 같은 예시 (책에서 나오는 알림 - sms, 이메일, 우편 - 서비스)에서도 각 분해인에 따라 적합 여부가 달라진다. | ||
| 서비스의 범위와 기능으로 볼때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼때 구분이 되면 적절한 후보가 된다. |
There was a problem hiding this comment.
볼때는과 볼때는 각각 볼 때는과 볼 때로 띄어 쓰는 것이 올바른 표현입니다. 가독성을 위해 수정하는 것이 좋습니다.
| 서비스의 범위와 기능으로 볼때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼때 구분이 되면 적절한 후보가 된다. | |
| 서비스의 범위와 기능으로 볼 때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼 때 구분이 되면 적절한 후보가 된다. |
| * 공유 코드 | ||
| * 데이터 관계 | ||
|
|
||
| 운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는 요인이라고 생각한다. |
There was a problem hiding this comment.
문장 중간에 불필요한 공백이 두 칸 있습니다. 가독성을 위해 수정하는 것이 좋습니다.
| 운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는 요인이라고 생각한다. | |
| 운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는 요인이라고 생각한다. |
|
|
||
| 서비스를 분해한다 해도 의존성이라는 것이 없어지는 것은 아니다. | ||
| 따라서 서비스를 잘게 나누다 보면 언젠가는 서비스 간 통신이 점점 늘어나 부정적인 영향을 끼치기 시작하는 지점에 이르게 된다. | ||
| 예를 들어 과도하게 디펜던시가 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다. |
There was a problem hiding this comment.
문서 내에서 의존성이라는 용어를 사용하고 있으므로, 일관성을 위해 디펜던시 대신 의존성으로 통일하는 것이 좋겠습니다.
| 예를 들어 과도하게 디펜던시가 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다. | |
| 예를 들어 과도하게 의존성이 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다. |
ymkim97
requested review from
GeunJuLEE,
benscookie and
chichoon
and removed request for
fkdl0048 and
hemil0102
| * 서비스를 분리하면서 고려해야 하는 것 중 각자 생각하는 가장 큰 걸림돌이 무엇인지 의견이 궁금합니다. | ||
| > 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요한다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다. |
There was a problem hiding this comment.
저는 장애 영향을 가장 크게 봅니다 어떤 크리티컬한 도메인이 있을 때, 해당 도메인이 다른 덜 중요한 도메인의 기능으로 인해서, 정상동작을 못할 때, 서비스 분해인으로 보고 있습니다
There was a problem hiding this comment.
저 같은 경우에는 트랜잭션 관리라고 생각합니다.
저도 이부분에 대해서 이론적으로는 공감하지만, 현실세계의 MSA 환경에서는 제약이 존재하는 것 같습니다
그 이유는 대개의 회사를 보면, 콘웨이 법칙으로 인해서, MSA를 하고 있다면, MS 기준으로 팀의 경계를 나누게 되는데, 팀의 경계가 MS의 경계이면서, 업무의 경계가 되다보니, 팀 간에는 애초에 분산 트랜잭션을 관리하는 상황이 될 수밖에 없는거 같습니다
이런 경우에, 반드시 물리적 트랜잭션으로 처리하기 위한 통합 작업이 필요하다면, 역콘웨이 법칙에 인해서, 그 팀이 합쳐지는 경우가 있긴한데, 아주 크리티컬하지 않다면, 보상 트랜잭션을 통해서, 분산트랜잭션을 구현한다던지, 사후처리 로직을 통해서 보정 작업을 별도로 한다던지 하는 선택을 많이 하는 것 같습니다
2 participants
Close #598