소프트웨어 아키텍처 The Hard Parts 3주차 - 이동현 #608
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,73 @@ | ||||||
| # 6 ~ 7장 | ||||||
|
|
||||||
| ## 논의 | ||||||
|
|
||||||
| 성능 향상을 위해 서비스를 분해했는데, 네트워크 오버헤드 등의 이유로 전체 응답성이 떨어져 다시 합쳤던 경험이 있다면 공유해보면 좋을 것 같습니다. | ||||||
|
|
||||||
| ## 내용 | ||||||
|
|
||||||
| - 데이터 분해(요)인 | ||||||
| - 변경 영향 범위: 테이블 변경 시 얼마나 많은 서비스가 영향을 받는가 | ||||||
| - 커넥션 관리: 데이터베이스가 여러 분산 서비스와 커넥션을 맺을 수 있는가 | ||||||
| - 확장성: 액세스하는 서비스 수요에 맞게 데이터베이스를 확장할 수 있는가 | ||||||
| - 내고장성: 장애 및 수리 등의 사유로 가동 중단될 때 얼마나 많은 서비가 영향을 받는가 | ||||||
|
Contributor
There was a problem hiding this comment. 내고장성 설명 부분에 '서비가'라는 오타가 있습니다. '서비스가'로 수정하면 더 자연스러운 문장이 될 것 같습니다.
Suggested change
|
||||||
| - 아키텍처 퀀텀: 단일 공통 데이터베이스가 바람직하지 않은 단일 아키텍처 퀀텀을 유발하는가 | ||||||
| - 데이터베이스 유형 최적화: 여러 종류의 데이터베이스를 사용해 데이터를 최적화할 여지가 있는가 | ||||||
| - 데이터 통합(요)인 | ||||||
| - 데이터 관계 | ||||||
| - 데이터베이스 트랜잭션 | ||||||
| - 데이터 분해 과정 | ||||||
| 1. 데이터베이스 분석과 데이터 도메인 생성 | ||||||
| 2. 데이터 도메인에 테이블 할당 | ||||||
| 3. 데이터 도메인에 접속하는 데이터베이스 커넥션 분리 | ||||||
| 4. 개별 데이터베이스 서버로 스키마 이전: "백업 및 복원" or "복제" | ||||||
| 5. 독립적 데이터베이스 서버로 전환 | ||||||
| - 데이터베이스 타입 | ||||||
| | 항목 | 관계형 | 키-값 | 문서형 | 컬럼형 | 그래프 | NewSQL | 클라우드 네이티브 | 시계열 | | ||||||
| |------------------------------|:-----:|:----:|:-----:|:-----:|:----:|:-----:|:---------------:|:-----:| | ||||||
| | 학습 용이성 | 4 | 3 | 3 | 2 | 1 | 3 | 2 | 1 | | ||||||
| | 데이터 모델링 용이성 | 3 | 1 | 3 | 1 | 2 | 3 | 2 | 2 | | ||||||
| | 확장성 / 처리량 | 2 | 4 | 2 | 4 | 3 | 3 | 4 | 4 | | ||||||
| | 가용성 / 내분할성 | 1 | 4 | 3 | 4 | 3 | 3 | 3 | 2 | | ||||||
| | 일관성 | 5 | 2 | 2 | 1 | 3 | 2 | 3 | 3 | | ||||||
| | 언어 지원 / 성숙도 / 커뮤니티 | 4 | 3 | 3 | 2 | 2 | 2 | 2 | 2 | | ||||||
| | 읽기/쓰기 우선순위 | 중간 | 읽기 | 읽기 | 쓰기 | 읽기 | 중간 | 읽기 | 읽기 | | ||||||
| - 관계형: Oracle, MySQL, PostgreSQL | ||||||
| - 키-값: Redis, Amazon Dynamo DB | ||||||
| - 문서형: MongoDB, Couchbase | ||||||
| - 컬럼형: Cassandra, Amazon SimpleDB | ||||||
| - 그래프: Neo4j, Infinite Graph, Tiger Graph | ||||||
| - NewSQL: VoltDB, ClustrixDB, SimpleStore | ||||||
| - 클라우드 네이티브: Snowflake, Datomic, Redshift | ||||||
| - 시계열: InfluxDB, Amazon Timestream | ||||||
| - 서비스 세분도 분해(요)인 | ||||||
| - 서비스의 범위와 기능: 기능의 응집도와 컴포넌트 전체 사이즈를 고려 | ||||||
| - 코드 변동성 | ||||||
| - 확장성/처리량 | ||||||
| - 내고장성 | ||||||
| - 보안: 요구되는 보안 수준 | ||||||
| - 신장성(=확장성, Extensibility): 새로운 기능을 추가하는 능력 | ||||||
| - Scalability(부하에 대응하는 능력)와 같은 **확장성**이라 명확성을 위해 신장성 사용한 듯 | ||||||
| - 서비스 세분도 통합(요)인 | ||||||
| - 데이터베이스 트랜잭션 | ||||||
| - 워크플로와 코레오그래피: 기능들이 단단히 결합된 서비스들간에서 발생 | ||||||
|
Contributor
There was a problem hiding this comment. '서비스들간에서'는 '서비스들 간에서'로 띄어쓰기를 하는 것이 한국어 맞춤법에 맞습니다.
Suggested change
|
||||||
| - 과도한 IPC -> 내고장성, 성능 이슈 | ||||||
| - 요청의 70%는 자체 처리가 가능하다면 서비스를 분리한 상태로 두는게 합리적 | ||||||
| - 나머지 30%가 매우 빠른 응답을 요한다면 서비스를 합치는 것이 타당할 수도 | ||||||
| - 즉 요청 처리 성능, 응답성과 함께 요청의 중요도 역시 통합인 중 하나 | ||||||
|
Contributor
There was a problem hiding this comment. 문맥상 '통합인'은 '통합 요인'을 의미하는 것으로 보입니다. '통합 요인'으로 수정하여 의미를 명확하게 하는 것이 좋겠습니다.
Suggested change
|
||||||
| - 운영 측면에서 데이터 일관성과 무결성이 그 무엇보다 중요한 경우 통합 고려 | ||||||
| - 공유 코드 | ||||||
| - 데이터 관계 | ||||||
| - 서비스 세분도 정리 | ||||||
| |종류|요인|적용해야 하는 이유| | ||||||
| |--|--|--| | ||||||
| |분해인|서비스 범위| 응집도가 강한 단일 목적의 서비스| | ||||||
| ||코드 변동성|민첩성(테스트 범위와 배포 리스크가 줄어든다)| | ||||||
| ||확장성|비용절감, 빠른 응답성| | ||||||
| ||내고장성|전체 가동 시간 개선| | ||||||
| ||보안 액세스|어떤 기능의 보안 액세스 강화| | ||||||
| ||신장성|민첩성(새로운 기능을 추가하기 쉽다)| | ||||||
| |통합인|데이터베이스 트랜잭션|데이터 무결성 및 일관성| | ||||||
| ||워크플로|내고장성, 성능, 신뢰성| | ||||||
| ||공유 코드|유지 보수성| | ||||||
| ||데이터 관계|데이터 무결성 및 정확성| | ||||||
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.
책 내용대로라면 서비스 분해가 성능 향상의 방법이진 않은데...
어쨌든 제 경험은 아니고 미리 만들어져 있던 서비스를 분석하면서 알게 된 내용으로 얘기해 보면
응답성이 떨어져서 서비스를 합치지는 않았습니다.
대신 SQS라고 비동기 메시지 큐에 담아서 처리하게 했는데 당시에는 그렇구나 하고 넘어갔었다가
나중에 아키텍처 관련 책을 하나씩 읽으면서 서비스간 응답성에 대해 보장해주는 장치로 알게 되었습니다.
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.
성능 향상이라기 보다는 팀이 분리되면서, 서비스도 같이 분해된적이 있었는데, 나누고 나서 보니, 굳이 나눌 필요가 없다고 판단되서(성능적이거나, 운영적 측면에서)다시 합친적은 있었습니다
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.
앗.. 머릿속으로 성능성능 하다가 실수했네요..
사용자 요청에 대한 지연을 줄이는 것을 생각했었습니다.