소프트웨어 아키텍처 The Hard Parts 3주차 - 최지윤 #604
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,106 @@ | ||||||
| ## Chapter 06: 운영 데이터 분리 | ||||||
|
|
||||||
| ### 개요 | ||||||
|
|
||||||
| - 애플리케이션보다 훨씬 분해가 어려운 것이 데이터베이스 | ||||||
| - 데이터베이스를 분해해야 경계 구분이 명확해진다 | ||||||
|
|
||||||
| ### 데이터 분해인 | ||||||
|
|
||||||
| - 데이터 분해 이유 (언제 분해해야할까?) | ||||||
| - 변경 관리 | ||||||
| - 테이블을 수정할 때 얼마나 많은 서비스에 영향을 끼치는지 | ||||||
| - 영향 받은 서비스를 명확히 알 수 있으면 괜찮은데, 그걸 모른 채로 배포했더니 프로덕션이 오동작하는 일도 있음 | ||||||
| - 데이터베이스를 적절히 분리하여 변경 관리에 이점을 얻을 수 있다 | ||||||
| - 자신을 소유한 서비스에만 영향을 미치게끔 독립적으로 운용 | ||||||
| - 커넥션 관리 | ||||||
| - 여러 서비스가 동일한 데이터베이스를 공유할 경우, 서비스와 연결된 커넥션 풀이 많아지면서 데이터베이스에 부하를 일으킨다 | ||||||
| - 커넥션이 너무 많으면 커넥션 대기가 걸림 | ||||||
| - 추후 서비스를 확장하게 될 경우, 커넥션이 더 늘어남을 고려해야 함 | ||||||
| - 데이터베이스를 분리함으로써 동시에 사용할 수 있는 커넥션 수를 늘릴 수 있다 | ||||||
| - 확장성 | ||||||
| - 서비스 응답 시간을 일정하게 유지하고, 요청량에 따라 서비스 규모를 늘리는 능력 | ||||||
| - 하나의 데이터베이스를 여러 서비스가 바라볼 경우, 커넥션 뿐만 아니라 처리량 부하도 심각해진다 | ||||||
| - 따라서 서비스 확장을 위해서는 데이터베이스 확장을 통해 처리량을 분산시키는것이 좋음 | ||||||
| - 내고장성 | ||||||
| - 여러 서비스가 하나의 데이터베이스를 공유할 경우, 해당 데이터베이스에 장애가 발생하면 이를 공유하는 모든 서비스가 영향을 받게 됨 | ||||||
| - 내고장성: 하나의 서비스나 데이터베이스가 고장나도, 다른 부분은 중단없이 가동시킬 수 있는 능력 | ||||||
| - 데이터베이스를 여러 개 두어 하나의 데이터베이스가 망가져도 다른 서비스가 문제없이 동작할수 있도록 하는게 좋다 | ||||||
| - 아키텍처 퀀텀 | ||||||
| - 어떤 경우에 데이터베이스를 분해하는 게 좋을지 알려주는 길잡이 | ||||||
| - 퀀텀 단위로 데이터베이스를 쪼개면 독립적인 서비스로 분리가 가능 | ||||||
| - 데이터베이스 타입 최적화 | ||||||
| - 데이터 처리 방식에 따른 분리 | ||||||
|
|
||||||
| ``` | ||||||
| 논의점: 데이터 분해인에 정말 많은 요인들이 있는데, 이것들을 고려하기 수월하게 해 주는 피트니스 함수나 유틸리티는 어떤 것이 있을까? | ||||||
| ``` | ||||||
|
Comment on lines
+35
to
+37
Collaborator
There was a problem hiding this comment. 관련된 피트니스 함수가 있는지 잘모르겠네요 상황에 맞게 사람이 판단해야하는 부분 같습니다 |
||||||
|
|
||||||
| ### 데이터 통합인 | ||||||
|
|
||||||
| - 데이터 통합 이유 (언제 합쳐야할까?) | ||||||
| - 데이터 관계 | ||||||
| - 데이터베이스 테이블간에도 커플링이 발생할 수 있음 | ||||||
| - 외래 키를 통한 연결, 저장 프로시저 등 | ||||||
| - 데이터베이스 분해를 통해 내고장성을 높일지, 통합을 통해 테이블 간 관계를 유지하는게 나을지 고민해야 함 | ||||||
| - 데이터베이스 트랜잭션 | ||||||
| - 서로 다른 테이블에서 발생한 에러는 같은 트랜잭션으로 묶을 수 없기 때문에 데이터의 일관성과 무결성을 보장할 수 없음 | ||||||
|
Contributor
There was a problem hiding this comment. 데이터베이스 트랜잭션에 대한 설명이 약간 모호합니다. '서로 다른 테이블'이라고만 하면 같은 데이터베이스 내의 다른 테이블로 오해할 수 있습니다. 데이터베이스가 분리되었을 때의 트랜잭션 문제를 지적하는 것이므로, '서로 다른 데이터베이스'에 있는 테이블이라는 점을 명확히 하는 것이 좋겠습니다.
Suggested change
|
||||||
|
|
||||||
| ### 모놀리식 데이터 분해 | ||||||
|
|
||||||
| - 마이그레이션 점진적 진행 과정 | ||||||
| - 데이터베이스 분석, 데이터 도메인 생성 | ||||||
| - 내부의 도메인 그룹 식별 | ||||||
| - 데이터 도메인에 테이블 할당 | ||||||
| - 테이블들을 특정 컨텍스트로 묶은 뒤, 각 데이터 도메인에 속하는 테이블들을 스키마에 할당 | ||||||
| - 서로 다른 도메인에 속한 테이블들 간 밀접한 커플링이 존재한다면, 이를 묶어야 함 | ||||||
| - synonym (일종의 심볼릭 링크와 같은 별칭) 을 이용하여 코드 분석을 용이하게 만드는 것도 좋은 방법 | ||||||
| - 데이터 도메인에 접속하는 데이터베이스 커넥션의 분리 | ||||||
| - 모든 데이터 접근이 서비스 - 스키마를 통해서만 이루어지도록 구성을 리팩토링 | ||||||
| - 교차 스키마 접근을 서비스 단위로 제거해야 함 | ||||||
| - 이 과정을 완료하여 서비스마다 데이터를 각각 소유하는 아키텍처로 전환됨 | ||||||
| - 개별 데이터베이스 서버로 스키마 이전 | ||||||
| - 위 단계에서 독립적인 접근으로 분리한 데이터 (스키마) 들을 물리적인 단일 데이터베이스 각각으로 옮김 | ||||||
| - 스키마를 옮길 땐 백업 후 복원하거나, 아예 스키마를 복제해서 새 데이터베이스로 커넥션 전환하는 방법이 있음 | ||||||
| - 독립적 데이터베이스 서버로 전환 | ||||||
| - 위에서 각 스키마를 이전하면, 서비스 커넥션도 전환할 수 있음 | ||||||
| - 하나의 서비스 덩어리를 독립적인 배포 단위로 작동시키는 것 | ||||||
| - 기존 큰 데이터베이스에 묶인 스키마와 커넥션을 전부 삭제하면, 이제 각 서비스는 자신의 데이터베이스를 가진 독립적인 도메인이 된다 | ||||||
|
|
||||||
| ### 데이터베이스 타입 선택 | ||||||
|
|
||||||
| - 학습 용이성 | ||||||
| - 데이터베이스를 배우기 쉬운지 | ||||||
| - 모델링 용이성 | ||||||
| - 데이터 모델러가 얼마나 쉽게 도메인을 표현할 수 있는지 | ||||||
| - 확장성 및 처리량 | ||||||
| - 증가된 처리량을 데이터베이스가 얼마나 쉽게 확장 및 감당 가능한지 | ||||||
| - 가용성, 내분할성 | ||||||
| - 고가용성 구성을 지원하는지 | ||||||
| - 일관성 | ||||||
| - 항상 일관된 패러다임 지원 여부 | ||||||
| - 프로그래밍 언어 지원 | ||||||
| - 다양한 프로그래밍 언어 지원 여부 | ||||||
|
|
||||||
| #### 데이터베이스 종류별 특징 | ||||||
|
|
||||||
| - 관계형 디비 | ||||||
|
Contributor
There was a problem hiding this comment. 문서의 다른 부분에서는 '데이터베이스'라는 용어를 사용하고 있는데, 여기서는 '디비'라는 구어체 표현이 사용되었습니다. 용어의 일관성을 위해 '데이터베이스'로 수정하는 것을 제안합니다.
Suggested change
|
||||||
| - 가용성보다 일관성 중시 | ||||||
| - 업계 표준이라 공부할 자료가 많고 모델링도 비교적 쉽다 | ||||||
| - 키-값 데이터베이스 | ||||||
| - 관계형 디비보다 배우는 것은 까다로우나, 확장성과 내분할성 면에서 이점을 갖는다 | ||||||
|
Contributor
There was a problem hiding this comment. 여기서도 '디비'라는 구어체 표현이 사용되었습니다. 문서 전체의 일관성을 위해 '데이터베이스'로 통일하는 것이 좋겠습니다.
Suggested change
|
||||||
| - 테이블 조인 등의 과정이 필요없기 때문 | ||||||
| - 문서형 데이터베이스 | ||||||
| - 사람이 값을 읽기 쉬워 배우기 쉽고 FE 등에게도 익숙한 형식 | ||||||
| - 컬럼형 데이터베이스 | ||||||
| - 확장성과 내분할성은 최고이지만 이해하기가 어려움 | ||||||
| - 그래프 데이터베이스 | ||||||
| - 어렵고, 정보가 비교적 많지 않음 | ||||||
| - 데이터 흐름 방향성에 따라 복잡해지기 쉽다 | ||||||
| - NewSQL | ||||||
| - 관계형 데이터베이스와 유사하여 학습이 어렵지 않음 | ||||||
| - SQL을 지원하고, NoSQL의 확장성과 관계형 데이터베이스의 장점을 섞은 느낌 | ||||||
|
Contributor
There was a problem hiding this comment. '섞은 느낌'이라는 표현은 다소 구어적이어서, 정리 문서의 톤과 맞지 않을 수 있습니다. 조금 더 공식적인 표현으로 수정하면 좋겠습니다.
Suggested change
|
||||||
| - 클라우드 네이티브 데이터베이스 | ||||||
| - 관계형 데이터베이스와 비슷하고, 클라우드에 바로 올릴 수 있다 | ||||||
| - 시계열 데이터베이스 | ||||||
| - 시계열 분석에 특화 | ||||||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,45 @@ | ||
| ## Chapter 07: 서비스 세분도 | ||
|
|
||
| ### 개요 | ||
|
|
||
| - 세분도: 작게 나눈 서비스들의 사이즈 정도 | ||
|
|
||
| ### 세분도 분해인 | ||
|
|
||
| - 서비스를 작게 나눠야 하는 이유 | ||
| - 서비스의 범위와 기능 | ||
| - 서비스가 하는 일의 크기와, 컴포넌트의 사이즈 | ||
| - 서비스로 나눠지는 기준이 사람마다 다르고, 개발자는 서비스를 최대한 작게 나누려는 성향이 있기 때문에 서비스의 범위를 꼭 고려해야 한다 | ||
| - 코드 변동성 | ||
| - 소스 코드를 변경하는 빈도 | ||
| - 자주 변경되는 기능을 영향력이 적은 단일 서비스로 묶으면 타 기능에 끼치는 영향이 작아지기 때문에 테스트에 용이 | ||
| - 확장성 + 처리량 | ||
| - 처리량을 달성하기 위해 서비스를 확장할 필요가 있음 | ||
| - 서비스를 적절히 쪼개 다양한 처리량 목표를 달성하게 할 수 있다 | ||
| - 내고장성 | ||
| - 데이터베이스와 마찬가지로 하나의 도메인에 장애가 발생해도 다른 곳에 영향을 끼치지 않게끔 하는 것이 중요하다 | ||
| - 보안 | ||
| - 민감한 데이터를 다른 서비스가 접근하지 못하게 보호 | ||
| - 데이터 저장 뿐만 아니라 데이터 접근도 보안에 큰 영향을 끼친다 | ||
| - 신장성 | ||
| - 현재 기능에서 새로운 기능이 추가될 경우 리스크를 작게 만들어야 함 | ||
|
|
||
| ### 세분도 통합인 | ||
|
|
||
| - 서비스를 합쳐서 크게 만들어야 하는 이유 | ||
| - 데이터베이스 트랜잭션 | ||
| - 데이터베이스와 비슷하게, 서로 다른 서비스끼리 데이터 공유가 잦은데 도메인이 분리되어 있을 경우 트랜잭션 적용이 어렵다 | ||
| - 이런 경우 통합하는 것이 좋다 | ||
| - 워크플로우와 코레오그래피 | ||
| - 기능간 결합도를 확인하고, 단단히 결합되어 있을 경우 전체 내고장성 보장을 위해 굳이 분리하지 않는 것도 방법 | ||
| - 데이터 일관성과 무결성을 중시한다면 서비스 통합도 대안이 된다 | ||
| - 공유 코드 | ||
| - 서비스들 간 코드를 공유해야 하는지 여부 | ||
| - 서비스가 분리되어 있을 경우 라이브러리나 코드 변경시 이를 사용하는 모든 서비스를 찾아서 같이 수정해야 함 | ||
| - 이 경우 서비스를 통합하는 게 방법일 수 있다 | ||
| - 데이터 관계 | ||
| - 서비스 간 데이터는 공유되지 않고 엄격한 콘텍스트로 나눠져 있으므로 서비스간 통신이 잦을 경우 이 서비스를 합치는 게 나을 수도 있다 | ||
|
|
||
| ### 적정 균형점 찾기 | ||
|
|
||
| - 분해인과 통합인을 고려하여 트레이드오프를 결정해야 함 |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
책에서 직접적인 설명은 안해줬지만 커넥션 풀의 유휴 갯수를 체크하는 피트니스 함수가 있었기 때문에 서비스별 커넥션 사용 갯수를 뽑을 수 있지 않았을까 싶습니다.
분해인에 대해서 뭔지는 설명해 줬으니 방법은 직접 구현해서 뽑아보면 좋을 것 같습니다.