twitch-clone

• Wiki
• 서버 실행 시 주의사항
• APM 실행
• Problem Solving
  • 분산 트랜잭션 설계하기 (초급)

Wiki

• Ground Rule
  • Git 전략, Commit Convention, PR review
• [회원] 전체 흐름

서버 실행 시 주의사항

default

• 환경 변수로 비밀번호 입력이 필요합니다.
  • --spring.datasource.password={password}

local

• local DB 정보 입력이 필요합니다.
  • DATASOURCE_URL
  • DATASOURCE_USERNAME
  • DATASOURCE_PASSWORD

APM 실행

• Elastic APM

  URL : http://49.50.162.164:5601/app/apm/services/apm-1/overview?comparisonEnabled=true&environment=ENVIRONMENT_ALL&kuery=&latencyAggregationType=avg&offset=1d&rangeFrom=now-15m&rangeTo=now&serviceGroup=&transactionType=request
  • ID : elastic
  • P.W :
• module-api bootJar 실행 후 apm.sh 파일 .jar 뒤에 --spring.datasource.password={password} 옵션 붙여서 sh 실행 시키면 client 실행 됩니다.

Problem Solving

트랜잭션 설계

• 이 모델은 Choreographed SAGA 패턴과 유사합니다.
  • 메시지 브로커 활용 대신 트랜잭션을 잡고 있는 점이 달라 장애 처리는 비교적 용이하지만, 복수 개의 서비스에 연쇄적인 트랜잭션이 생기고 있어 관리와 추적이 힘들다는 단점이 같습니다.
  • 반면 2PC 패턴은 트랜잭션의 관리 주체가 한 곳으로 집중되어 트랜잭션 관리가 용이합니다.
• 반면 2PC 패턴은 트랜잭션의 관리 주체가 한 곳으로 집중되어 트랜잭션 관리가 용이합니다.
• api-module만이 Spring 의존도를 가지며 그 외 module은 도메인 로직을 가지도록 설계했습니다.
  따라서 usecase에 따라 각 module에서 생성된 결과를 api-module에서 영속시킵니다.
• 사이드 프로젝트이기에 복잡도가 높지 않기에 로직의 추가가 api-module에 영향을 주어도 괜찮다고 생각했습니다.

아마 실무였다면 트랜잭션 타임을 줄이기 위해 MQ를 도입하고 Orchestration Saga 패턴을 고려했을 것 같습니다.
하지만 사이드 프로젝트에 MQ까지 고려하는 것은 힘들었고, 도메인 분리와 모듈 프로그래밍에 집중하기 위해 2PC 패턴의 구성을 선택했습니다.

좀 더 많은 예시와 생각은 블로그를 참고 부탁드립니다. 분산 트랜잭션 설계하기 (초급)