|
| 1 | +## Chapter 06: 운영 데이터 분리 |
| 2 | + |
| 3 | +### 개요 |
| 4 | + |
| 5 | +- 애플리케이션보다 훨씬 분해가 어려운 것이 데이터베이스 |
| 6 | +- 데이터베이스를 분해해야 경계 구분이 명확해진다 |
| 7 | + |
| 8 | +### 데이터 분해인 |
| 9 | + |
| 10 | +- 데이터 분해 이유 (언제 분해해야할까?) |
| 11 | +- 변경 관리 |
| 12 | + - 테이블을 수정할 때 얼마나 많은 서비스에 영향을 끼치는지 |
| 13 | + - 영향 받은 서비스를 명확히 알 수 있으면 괜찮은데, 그걸 모른 채로 배포했더니 프로덕션이 오동작하는 일도 있음 |
| 14 | + - 데이터베이스를 적절히 분리하여 변경 관리에 이점을 얻을 수 있다 |
| 15 | + - 자신을 소유한 서비스에만 영향을 미치게끔 독립적으로 운용 |
| 16 | +- 커넥션 관리 |
| 17 | + - 여러 서비스가 동일한 데이터베이스를 공유할 경우, 서비스와 연결된 커넥션 풀이 많아지면서 데이터베이스에 부하를 일으킨다 |
| 18 | + - 커넥션이 너무 많으면 커넥션 대기가 걸림 |
| 19 | + - 추후 서비스를 확장하게 될 경우, 커넥션이 더 늘어남을 고려해야 함 |
| 20 | + - 데이터베이스를 분리함으로써 동시에 사용할 수 있는 커넥션 수를 늘릴 수 있다 |
| 21 | +- 확장성 |
| 22 | + - 서비스 응답 시간을 일정하게 유지하고, 요청량에 따라 서비스 규모를 늘리는 능력 |
| 23 | + - 하나의 데이터베이스를 여러 서비스가 바라볼 경우, 커넥션 뿐만 아니라 처리량 부하도 심각해진다 |
| 24 | + - 따라서 서비스 확장을 위해서는 데이터베이스 확장을 통해 처리량을 분산시키는것이 좋음 |
| 25 | +- 내고장성 |
| 26 | +- 여러 서비스가 하나의 데이터베이스를 공유할 경우, 해당 데이터베이스에 장애가 발생하면 이를 공유하는 모든 서비스가 영향을 받게 됨 |
| 27 | + - 내고장성: 하나의 서비스나 데이터베이스가 고장나도, 다른 부분은 중단없이 가동시킬 수 있는 능력 |
| 28 | + - 데이터베이스를 여러 개 두어 하나의 데이터베이스가 망가져도 다른 서비스가 문제없이 동작할수 있도록 하는게 좋다 |
| 29 | +- 아키텍처 퀀텀 |
| 30 | + - 어떤 경우에 데이터베이스를 분해하는 게 좋을지 알려주는 길잡이 |
| 31 | + - 퀀텀 단위로 데이터베이스를 쪼개면 독립적인 서비스로 분리가 가능 |
| 32 | +- 데이터베이스 타입 최적화 |
| 33 | + - 데이터 처리 방식에 따른 분리 |
| 34 | + |
| 35 | +``` |
| 36 | +논의점: 데이터 분해인에 정말 많은 요인들이 있는데, 이것들을 고려하기 수월하게 해 주는 피트니스 함수나 유틸리티는 어떤 것이 있을까? |
| 37 | +``` |
| 38 | + |
| 39 | +### 데이터 통합인 |
| 40 | + |
| 41 | +- 데이터 통합 이유 (언제 합쳐야할까?) |
| 42 | +- 데이터 관계 |
| 43 | + - 데이터베이스 테이블간에도 커플링이 발생할 수 있음 |
| 44 | + - 외래 키를 통한 연결, 저장 프로시저 등 |
| 45 | + - 데이터베이스 분해를 통해 내고장성을 높일지, 통합을 통해 테이블 간 관계를 유지하는게 나을지 고민해야 함 |
| 46 | +- 데이터베이스 트랜잭션 |
| 47 | + - 서로 다른 테이블에서 발생한 에러는 같은 트랜잭션으로 묶을 수 없기 때문에 데이터의 일관성과 무결성을 보장할 수 없음 |
| 48 | + |
| 49 | +### 모놀리식 데이터 분해 |
| 50 | + |
| 51 | +- 마이그레이션 점진적 진행 과정 |
| 52 | +- 데이터베이스 분석, 데이터 도메인 생성 |
| 53 | + - 내부의 도메인 그룹 식별 |
| 54 | +- 데이터 도메인에 테이블 할당 |
| 55 | + - 테이블들을 특정 컨텍스트로 묶은 뒤, 각 데이터 도메인에 속하는 테이블들을 스키마에 할당 |
| 56 | + - 서로 다른 도메인에 속한 테이블들 간 밀접한 커플링이 존재한다면, 이를 묶어야 함 |
| 57 | + - synonym (일종의 심볼릭 링크와 같은 별칭) 을 이용하여 코드 분석을 용이하게 만드는 것도 좋은 방법 |
| 58 | +- 데이터 도메인에 접속하는 데이터베이스 커넥션의 분리 |
| 59 | + - 모든 데이터 접근이 서비스 - 스키마를 통해서만 이루어지도록 구성을 리팩토링 |
| 60 | + - 교차 스키마 접근을 서비스 단위로 제거해야 함 |
| 61 | + - 이 과정을 완료하여 서비스마다 데이터를 각각 소유하는 아키텍처로 전환됨 |
| 62 | +- 개별 데이터베이스 서버로 스키마 이전 |
| 63 | + - 위 단계에서 독립적인 접근으로 분리한 데이터 (스키마) 들을 물리적인 단일 데이터베이스 각각으로 옮김 |
| 64 | + - 스키마를 옮길 땐 백업 후 복원하거나, 아예 스키마를 복제해서 새 데이터베이스로 커넥션 전환하는 방법이 있음 |
| 65 | +- 독립적 데이터베이스 서버로 전환 |
| 66 | + - 위에서 각 스키마를 이전하면, 서비스 커넥션도 전환할 수 있음 |
| 67 | + - 하나의 서비스 덩어리를 독립적인 배포 단위로 작동시키는 것 |
| 68 | + - 기존 큰 데이터베이스에 묶인 스키마와 커넥션을 전부 삭제하면, 이제 각 서비스는 자신의 데이터베이스를 가진 독립적인 도메인이 된다 |
| 69 | + |
| 70 | +### 데이터베이스 타입 선택 |
| 71 | + |
| 72 | +- 학습 용이성 |
| 73 | + - 데이터베이스를 배우기 쉬운지 |
| 74 | +- 모델링 용이성 |
| 75 | + - 데이터 모델러가 얼마나 쉽게 도메인을 표현할 수 있는지 |
| 76 | +- 확장성 및 처리량 |
| 77 | + - 증가된 처리량을 데이터베이스가 얼마나 쉽게 확장 및 감당 가능한지 |
| 78 | +- 가용성, 내분할성 |
| 79 | + - 고가용성 구성을 지원하는지 |
| 80 | +- 일관성 |
| 81 | + - 항상 일관된 패러다임 지원 여부 |
| 82 | +- 프로그래밍 언어 지원 |
| 83 | + - 다양한 프로그래밍 언어 지원 여부 |
| 84 | + |
| 85 | +#### 데이터베이스 종류별 특징 |
| 86 | + |
| 87 | +- 관계형 디비 |
| 88 | + - 가용성보다 일관성 중시 |
| 89 | + - 업계 표준이라 공부할 자료가 많고 모델링도 비교적 쉽다 |
| 90 | +- 키-값 데이터베이스 |
| 91 | + - 관계형 디비보다 배우는 것은 까다로우나, 확장성과 내분할성 면에서 이점을 갖는다 |
| 92 | + - 테이블 조인 등의 과정이 필요없기 때문 |
| 93 | +- 문서형 데이터베이스 |
| 94 | + - 사람이 값을 읽기 쉬워 배우기 쉽고 FE 등에게도 익숙한 형식 |
| 95 | +- 컬럼형 데이터베이스 |
| 96 | + - 확장성과 내분할성은 최고이지만 이해하기가 어려움 |
| 97 | +- 그래프 데이터베이스 |
| 98 | + - 어렵고, 정보가 비교적 많지 않음 |
| 99 | + - 데이터 흐름 방향성에 따라 복잡해지기 쉽다 |
| 100 | +- NewSQL |
| 101 | + - 관계형 데이터베이스와 유사하여 학습이 어렵지 않음 |
| 102 | + - SQL을 지원하고, NoSQL의 확장성과 관계형 데이터베이스의 장점을 섞은 느낌 |
| 103 | +- 클라우드 네이티브 데이터베이스 |
| 104 | + - 관계형 데이터베이스와 비슷하고, 클라우드에 바로 올릴 수 있다 |
| 105 | +- 시계열 데이터베이스 |
| 106 | + - 시계열 분석에 특화 |
0 commit comments