데브허브 | DEVHUB | System Design Was HARD - Until You Knew the Trade-Offs, Part 2System Design Was HARD - Until You Knew the Trade-Offs, Part 2
- 수직 확장(Vertical Scaling)은 기존 서버에 자원을 추가하여 관리가 쉽지만 물리적 한계에 부딪히고 비용이 많이 듭니다. 📈
- 수평 확장(Horizontal Scaling)은 서버를 추가하여 무한한 확장성과 내결함성을 제공하지만 로드 밸런싱 및 데이터 일관성 문제로 복잡성이 증가합니다. 🌐
- 핵심 트레이드오프는 단순성과 확장성 사이의 균형입니다. ⚖️
- REST API는 성숙하고 널리 이해되며 간단한 CRUD 작업에 적합하지만, 복잡한 UI에서는 여러 번의 왕복 통신과 과도한 데이터 전송 문제가 발생할 수 있습니다. 🔄
- GraphQL은 클라이언트가 필요한 데이터를 정확히 한 번의 쿼리로 요청할 수 있게 하여 유연성을 높이지만, 서버 구현 복잡성, 성능 문제, 보안 위험을 수반합니다. 🚀
- 애플리케이션의 요구사항과 성숙도에 따라 REST와 GraphQL 중 적절한 것을 선택하는 것이 중요합니다. 🎯
- 대부분의 웹 서비스는 확장성을 위해 무상태(Stateless) 설계를 선호하지만, 게임 서버나 웹소켓 서버처럼 특정 애플리케이션은 핵심 기능을 위해 서버 측 상태(Stateful)를 반드시 필요로 합니다. 🎮
- 현대 아키텍처는 일반적인 작업에는 무상태 서비스를, 실시간 기능에는 특화된 상태 유지 구성 요소를 결합하는 하이브리드 접근 방식을 사용하기도 합니다. 🧩
- 읽기 스루 캐싱(Read-through Caching)은 구현이 간단하지만, 데이터가 캐시에 오래 남아있어 최신성이 중요한 경우 문제가 될 수 있습니다. 📚
- 쓰기 스루 캐싱(Write-through Caching)은 캐시와 데이터베이스를 동시에 업데이트하여 데이터 최신성을 보장하지만, 쓰기 작업의 복잡성을 증가시킵니다. 💾
- 성능과 데이터 최신성 사이의 트레이드오프를 이해하는 것이 중요합니다. ⏳
- 동기식 처리(Synchronous Processing)는 간단하고 예측 가능하며 즉각적인 피드백을 제공하지만, 시간이 오래 걸리는 작업은 사용자 경험을 저하시킬 수 있습니다. ⏱️
- 비동기식 처리(Asynchronous Processing)는 요청을 즉시 승인하고 백그라운드에서 처리하여 사용자 경험을 향상시키지만, 메시지 큐, 상태 추적 등 구현 복잡성이 추가됩니다. 📩
- 사용자 경험과 구현 복잡성 사이의 균형을 맞추기 위해 빠른 작업은 동기식으로, 리소스 집약적인 작업은 비동기식으로 처리하는 하이브리드 접근 방식이 일반적입니다. 💡