소프트웨어 아키텍처 The Hard Parts 4주차 - 이동현 #613
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,28 @@ | ||||||
| # 8 ~ 9장 | ||||||
|
|
||||||
| ## 논의 | ||||||
|
|
||||||
| 최종 일관성 패턴 중 **백그라운드 동기화 패턴**은 매우 생소한 패턴인데, 사용해본 분이 계신지 궁금하네요. | ||||||
|
Contributor
There was a problem hiding this comment. 저도 백그라운드 동기화 패턴은 사용해보지 못 했고, 이번에 처음 알았습니다. |
||||||
| 어떤 상황이었고, 왜 이 패턴을 사용했는지.. | ||||||
|
Comment on lines
+3
to
+6
Collaborator
There was a problem hiding this comment. 단일 MS는 운영해보았지만, 여러 MS 를 관리하는 형태로 백그라운드 동기화 하는 것은 따로 경험해보진 못했습니다 왜 경험을 못해보았을까? 를 돌이켜 생각해보면, 가장 큰 이유는 책에도 나와있는 경계컨텍스트가 무너진다는 점 때문일 것 같습니다. 각 팀들은 경계컨텍스트가 무너지지 않은 상태에서 관리하길 원하고 그게 익숙하기 때문입니다 위 패턴을 적용하려면, 회사 MS 전체를 관장하는 팀이 존재하고, 그 팀에서 오너쉽을 가지고 해야할텐데, 위와 같이 조직구조를 만들지 않는 이상(콘웨이의 법칙)은 위와 같은 패턴을 쓸 가능성이 없는게 당연하지 않은가 생각됩니다 |
||||||
|
|
||||||
| ## 내용 | ||||||
|
|
||||||
| - 코드 재사용 패턴 | ||||||
| - 코드 복제: 서비스 진입점을 정의한 어노테이션과 같이 대부분의 서비스에서 필요한 극히 **정적인 일회성 코드**에는 유용 | ||||||
|
Contributor
There was a problem hiding this comment. 이 문구는 '정적인'과 '일회성'이라는 두 가지 특성을 동시에 강조하고 있는데, 의미 전달은 되지만 문장 구조가 다소 어색하게 느껴질 수 있습니다. 좀 더 자연스러운 표현으로 다듬는 것을 고려해볼 수 있습니다.
Suggested change
|
||||||
| - 공유 라이브러리: 버저닝이 필수 | ||||||
| - 공유 서비스: 이에 의존하는 서비스가 런타임에 잘못될 가능성이 있음 => 버저닝도 말처럼 쉽지 않음 | ||||||
|
Contributor
There was a problem hiding this comment. '말처럼 쉽지 않음'은 구어체 표현입니다. 기술 문서나 학습 노트에서는 좀 더 명확하고 공식적인 표현을 사용하는 것이 좋습니다.
Suggested change
|
||||||
| - 사이드카와 서비스 메시: 로깅, 보안, 모니터링과 같은 공통 인프라 로직 (구현 계층이 다른 AOP 느낌임) | ||||||
| - 공동 데이터 오너십(joint ownership) 해결 기법 | ||||||
| - 전술적인 보완책 3개 + 구조적인 해결책 1개(서비스 통합 기법) | ||||||
| - 테이블 분할 기법: 데이터를 물리적으로 나누어 관리 | ||||||
| - 데이터 도메인 기법: 도메인 관점에서 데이터를 그룹화 | ||||||
| - 대리자 기법: 특정 서비스가 데이터 접근을 대행 | ||||||
| - 서비스 통합 기법: 여러 테이블 오너 서비스를 하나의 서비스로 통합, 공동 오너십 => 단독 오너십 | ||||||
|
Contributor
There was a problem hiding this comment. 화살표(
Suggested change
|
||||||
| - 분산 트랜잭션 (Distributed Transaction, 이하 DT): not ACID, but BASE | ||||||
| - BA (Base Availability, 기본 가용성): DT의 모든 서비스/시스템이 DT에 참여할 수 있다 | ||||||
| - S (Soft state, 소프트 상태): DT가 진행 중이고 원자적 비즈니스 요청이 미완료(또는 완료 여부조차 알 수 없는) 상태 | ||||||
| - E (Eventual consistency, 최종적 일관성): 언젠가는 DT의 모든 부분이 무사히 완료되고 모든 데이터가 동기화 | ||||||
| - 최종 일관성 패턴 | ||||||
| - 백그라운드 동기화 패턴 | ||||||
| - 오케스트레이티드 요청 기반 패턴 | ||||||
| - 이벤트 기반 패턴 | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저도 경험이 없긴 한데 책을 읽다 보니 오케스트레이션 서비스를 만들기 귀찮아서 그냥 쓰기 작업만 하는 간단한 프로세스를 만든 느낌이 많이 들었습니다.
그러니까 급하니까 일단 이렇게 하자의 초기 단계가 백그라운드 동기화 패턴이지 않을까 싶네요.