https://github.com/PacktPublishing/Java-Concurrency-and-Parallelism.git
{
"용어": {
"트레이드오프":"상충관계,득과실,장단점"
}
}• 관찰 시각observation time: 데이터 프로덕트가 이벤트 또는 상태를 인식하는 시점
• 처리 시각processing time: 데이터 프로덕트가 관찰한 데이터를 처리하고 변환하는 시점
• 기록 시각record time: 데이터 프로덕트가 처리한 데이터를 저장하는 시점
• 퍼블리싱 시각publish time: 데이터 사용자가 데이터에 액세스할 수 있게 되는 시점
- 순차적 처리 상태 유지
- 원본 장부 문제 시
- 일단위 갱신 영업 종료후 재고 파악
- 최종 일관성 트랜잭션 계획
- 일관성 문제 발견 처리 -> 읽기 복구
- 불일치 발견의 경우에만 전체 상태 파악후 수정 -> 큰 비용소요
- 상태 점검을 여러번 수행해 일관성 유지
- 2가지 관리 방식
- [1] 클라이언트 <-> 서버 스타일 설계 강한일관성
- [2] 대용량 트랜잭션 후 불일치 발견시 해결
Note
소프트웨어 추상화 목적 복잡성 숨김 세부 구현을 모르고 개발 가능하도록 달성 목표에 집중
- 데이터 웨어하우스 -> 데이터를 통합하는 중앙 저장소
- 직접적이과 격리된 영향 측정 -> 메트릭
- 데이터 제공 개별 요소연결 접착제
- 느슨한 구성요소를 같은 방향이로 오케스트레이션
-웹콘솔을 버려라 -모듈을 생성해 코드에 재사용 하도록 -버전관리 시스템 사용 코드 관리 풀리퀘스트 활성화 메인 브랜치 푸시 전 코드 검사
- 변경 푸시전 테스트 ->테라폼 적용전 인프라 변경사항 알려줌
- CICD 파이프라인 자동화 작업 수월
- 인프라를 코드로 작성해 재사용 하도록
- 데이터 처리 지연
- 일반전략 늦게 수집된 데이터 를 저장 로직에 따라 다름
- 간단한 전략 늦게 수집한 데이터 업데이트 타임스탬프에 따라 저장
- 바이템포럴 모델리 반복 -> 도착시간을 추가 생성 시간을 필터링해 로직생성 (시점에 따라 처리)
- 최신 데이터 무신 고정 간격 설정 마감 시간을 적용해 처리
분산 시스템으로의 변화 - 마이크로 서비스 이전 설계 방식 - 이유: - 예전 설계구조의 제약조건 - 기업 합병 과정에서 통합 필요 - 오픈소스의 배제(주된 원인: 정치적이유) - 공유리스소 or 중앙집중식 오케스트레이션 선택 - 시간과 환경 변화에 따라 예상치 못한 진화 -요약: - 설계 의사 결정 , 상황에 따른 트레이드 오프 평가 할것
아키텍쳐
- 데이터가 전부
- 시스템 이나 설계보단 오래 지속되는 가치
- 기업의 가장 중요한 가치
- 의사 결정에 활용
- 고객 확보,유지,개선 판매...
- 데이터 중심으로 돌아간다
- 데이터를 서비스하기 위해 아키텍처가 있다
데이터의 분류
-
운영 데이터 OLTP(OnLine Transactional Processing)
Write,Update,Delete- 판매
- 거래
- 재고
- 비지니스 활동에 사용
-
분석데이터
- Analytical , prediction , BI(Business Intelligence)
- 비지니스 분석 데이터
- 의사결정에 사용
- No 트랜잭션, 관계형
- 그래프 OR 스냅샷
-
문서화 ADR
- 컨텍스트
- 간략한 문제 정의 해결 대안 나열
- 결정
- 결정과 이유 기술
- 결과
- 발생 결과 와 트레이드 오프 고려 설명
- 컨텍스트
-
프로세스
- 아키텍쳐와 개발프로세스는 직교적 공리(독립적이다)
- 아키텍쳐는 반복적 이다
-
- 아키텍쳐의 모든것은 트레이드 오프이다
- 깔끔하게 맞아 떨어지는 것은 하나도 없다
-
- 어떻게 보다 왜 가 중요하다 Why?
- 의사결정 과정에 대한 설명을 할수 있어야 한다
- 설계의 이유 , 구조의 이해 , 기능의 이해
- 무엇을 하고 있는지 본질에 대한 깊이
-
- 클래스, 컴포넌트의 순환 참조는 의존성으로 진흙탕에 빠진다
- 관심사를 분리하자
-
아키텍쳐와 설계의 구분
- 아키텍트의 기본원칙
- 효과적인 결정 왜 하는지 이유에 맞는 결정
- 개념에 집중하기 상세구현 방법은 넘어가고 선택에 이유를 명시
- 원칙에 근거하여 추상화
- 아키텍트의 기본원칙
-
설계 용어의 개념
-
서비스
- 독립적 실행 파일 형태
- 기능이 응집된 집합체
-
커플링
- 코드 변경시 함께 변경 해야 되는 경우
- 결합된 코드
-
동기식
- 호출후 다음 진행전 응답을 받아야 진행
-
비동기식
- 응답과 무관하게 다음 단계 진행
- 선택적 응답 수신 가능
-
블로킹
- 호출후 수신자에게 제어권 위임
-
논블로킹
- 제어권을 유지한다
-
오케스트레이션
- 워크플로 코디네이션 서비스
- 조정,중개
-
원자성 (Atomicity)
- 일관된 작동
-
계약 / 컨트랙트(contract)
- A 와 B 의 호출, 관계 , 종속성 등
- 둘 이상의 관계를 통해 이루어 지는 경우
-
-
데이터
- 코드와 데이터는 공생관계
-
분산의 어려움
- 단일 데이터베이스의경우 테이블 쿼리 문제 거의 없다
- 분산 시 조회 수집 어려움
-
서비스 경계 컨택스트 외부의 데이터 엑새스 패턴
- 소유 데이터베이스, 비소유 데이터베이스
-
서비스 와 서비스 통신 ? REST
- 일반적인 접근 방법
- 서비스에 데이터 요청
- 간단함 , 데이터 보관 용량 문제 없음
- 단점 :
- 지속적 호출 필요
- 여러번 호출과정에서 레이턴시 발생
- 레이턴시로 인해 응답 성능 저하
- 서비스 커플링 의존성 발생
- 확장등의 변경시 모두 수정해야함
-
컬럼 스키마 레플리케이션
-
컬럼을 여러 테이블에 복제해 컨텍스트에서 사용할수 있도록함
-
데이터 엑세스 원활
-
확장과 처리량 문제 없음
-
내고장성 문제 없음
-
서비스 의존성 없음
-
단점 :
- 일관성과 동기화
- 변경 발생시 복제 테이블에 변경 적용해야함
- 책임이 불분명해 일관성의 문제
- 데이터 업데이트 적용 안될수도
- 원본 데이터와 불일치
- 실시간 동기화가 필요없을 경우 적합
- 일단 해당 패턴 사용은 보류하는게 좋다
- 서비스에서는 사용하지 말자
- 데이터 분석 집계 등의 비지니스와 직접적이지 않은 부분에서 사용하자
-
트랙잭션
- 메세지 큐 또는 이벤트 스트리밍으로 비동기 처리
-
-
캐싱 레플리케이션
- 분산데이터 접근과 공유
- 메모리 캐시에 데이터 복제
- 지속 적인 동기화
- 개별 서비스의 응답성이 좋다
- 정적인 데이터에 사용한다
- 단점 :
- 서비스와 서비스간 데이터 공유 안함
- 서비스간 통신에 발생하는 내고장성 문제
- 서비스와 서비스 통신 패턴에서 의존성만 캐시서버로 이동한차이
- 중앙 캐시 서버 사용시 원격호출로 레이턴시 증가 응답성 저하
- 분산 캐싱
- 외부 캐시서버에 데이터 보관 -복제 캐싱
- 캐시를 복제
- 지원 제품 {HAZELCAST}
-
데이터 도메인 패턴
- 여러서비스에 걸쳐 동일한 테이블에 데이터 쓰기
- 공동 소유
- 공유 테이블에 스키마로 관리
- 서비스별 테이블 조인 하여 쿼리한다
- 디커플링 서비스의 독립성 보장
- 응답성
-
- 소유 데이터베이스, 비소유 데이터베이스
-
패턴의 트레이드 오프
- 예시 :
- 장바구니에 상품 추가
- 카탈로그 상품 목록 관리
- 고객이 장바구니 조회
- 문제 :
- 장바구니서비스 데이터베이스에는 상품정보가 없다
- 외부에서 정보를 가져와야 한다
- 해결 방법
-
복제 캐싱 사용
-
장바구니 서비스에서 캐시를 소유한다
-
서비스 호출없이 데이터 변경시 캐시를 동기화하여 일관성 유지
-
장바구니 서비스에도 캐시 데이터를 보관하도록한다
-
트레이드오프:
- 장바구니서비스 자체 캐시가 없는경우
- 캐시를 채우지 못해 데이터가 없는 상태가 되어 의존성 카탈로그 서비스장애시 장바구니도 같이 대기상태
- 데이터 용량 증가는 메모리 사용량의 증가
- 데이터 캐시 용량이 500MB 일 때 메모리는 2.5GB 사용
- 변경 빈도와 업데이트 속도가 빠른경우 완전 동기화 어려움
- 재고와 같은 실시간 변경에 부적합
-
- 예시 :
설계 하기
1. 콘텍스트
- 계약 관계 파악
- 문제 정의
- 해결 방법 나열
2. 결정
- 계약 관계 정의
- 결과에 대한 근거
3. 결과
- 제약 조건
- 추가 발생 문제