From e7f58b27bf6885d9144e0ceefb29d4ea74fc5259 Mon Sep 17 00:00:00 2001 From: k-dgier Date: Sun, 19 Jan 2025 21:17:59 +0900 Subject: [PATCH] systemdesign01 --- _posts/2025-01-19-systemdesign01.md | 43 +++++++++++++++++++++-------- 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/_posts/2025-01-19-systemdesign01.md b/_posts/2025-01-19-systemdesign01.md index 5e4599a..4224f3d 100644 --- a/_posts/2025-01-19-systemdesign01.md +++ b/_posts/2025-01-19-systemdesign01.md @@ -11,7 +11,7 @@ mermaid: true --- -## 1. 단일 서버 +# 단일 서버 가장 단순하게 사용자의 요청을 처리할 수 있는 구조이다. @@ -26,7 +26,7 @@ mermaid: true --- -## 2. 단일 서버 + DB 서버 +# 단일 서버 + DB 서버 - 사용자: 웹 브라우저, 모바앨 앱 - 서버: 웹 서버, DB @@ -85,7 +85,7 @@ https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases 위 링크는 RDB에서 벗어나야할 상황과 NoSQL의 어떤 종류가 있는지 기술되어있다. -### 관계형 데이터베이스의 한계 징후 +## 관계형 데이터베이스의 한계 징후 **구조적 문제** @@ -101,7 +101,7 @@ https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases - 데이터셋의 크기가 단일 서버의 저장 용량을 초과한다 - 배치 처리나 분석 쿼리로 인해 트랜잭션 성능이 저하된다 -### 비관계형 데이터베이스의 유형 +## 비관계형 데이터베이스의 유형 **키-값 저장소** @@ -121,7 +121,7 @@ https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases - 적합한 용도: 소셜 네트워크, 추천 시스템, 부정 거래 탐지 - 특징: 복잡한 관계 데이터의 효율적인 쿼리 처리 -### 데이터베이스 선택 시 고려사항 +## 데이터베이스 선택 시 고려사항 **데이터 구조 측면** @@ -146,9 +146,9 @@ https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases --- -## Scale-Up vs Scale-Out +# Scale-Up vs Scale-Out -### 애플리케이션 서버의 관점 +## 애플리케이션 서버의 관점 Scale-Up은 서버에 더 좋은 하드웨어 장비를 추가하는 것을 말한다. 단순하게 처리량을 늘릴 수 있는 방법이다. @@ -160,7 +160,7 @@ Scale-Up의 단점으로 인해 애플리케이션 서버에서는 주로 Scale- LB가 각 서버의 앞단에서 트래픽을 받아주고 사설 네트워크 망에 있는 애플리케이션 서버에 트래픽을 전달한다. -### 데이터베이스 서버의 관점 +## 데이터베이스 서버의 관점 데이터베이스 또한 Scale-Out 혹은 다중화를 위한 기술에 친화적이다. @@ -178,9 +178,9 @@ LB가 각 서버의 앞단에서 트래픽을 받아주고 사설 네트워크 --- -## 캐시 +# 캐시 -### 캐시 사용 시 유의할 점 +## 캐시 사용 시 유의할 점 - 쓰기작업은 자주 일어나지 않지만 읽기 작업이 빈번하게 일어나는 경우에 적합하다. - 영속성이 보장되지 않아도 되는 데이터를 보관해야한다. @@ -789,9 +789,9 @@ public class CacheMonitoringAspect { ``` -## 결론 +### 결론 -각 캐싱 패턴은 고유한 장단점을 가지고 있으며, 시스템의 요구사항과 특성에 맞는 패턴을 선택하는 것이 중요하다. 특히 다음 사항들을 고려해야 한다. +각 캐싱 패턴은 시스템의 요구사항과 특성에 맞는 패턴을 선택하는 것이 중요하다. 특히 다음 사항들을 고려해야 한다. - 데이터 일관성 vs 성능 - 시스템 복잡도 @@ -800,3 +800,22 @@ public class CacheMonitoringAspect { - 모니터링 및 운영 전략 실제 구현 시에는 하나의 패턴만을 사용하기보다는 여러 패턴을 조합하여 사용하는 것이 일반적이며, 시스템의 요구사항 변화에 따라 유연하게 패턴을 조정할 수 있어야 한다. + +--- + +## CDN + +정적 컨텐츠를 지리적으로 분산된 서버에 캐시할 수 있는 시스템이다. + +동적 컨텐츠는 요청 경로, 쿼리 스트링, 쿠키, 요청 헤더 등에 기반하여 HTML 페이징을 캐싱하는 방법이지만 CDN은 일관된 정적 컨텐츠를 다룬다. + +사용자가 웹 사이트를 방문하면 해당 사용자에 가장 가까운 리전에 있는 서버에서 정적 파일을 제공한다. + +CDN역시 캐시의 일종으로 볼 수 있어 적절한 만료시간과 CDN 장애에 대한 대처방안이 중요하다. + +적절한 만료시간을 지정해서 컨텐츠의 신선도를 관리하고, CDN 불용상태 시 직접 서버로부터 컨텐츠를 가져갈 수 있는 조치가 필요하다. + +--- + +## Stateless 웹 계층 +