본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 부터는 프로젝트 3번이 아니라 5번 프로젝트로 순서를 변경하여 대규모 트래픽 상황에서 필요한 이벤트 기반 아키텍처와 분산 처리 강의를 시작했다. 강의에서 언급한 트래픽 급증 시 시스템 확장 방법과 데이터 분산 전략의 기본 개념을 확인했으며, 스케일 업과 스케일 아웃의 차이점, 스케일 아웃 방식 중 복제와 샤딩 방식의 차이를 정리해보았다.
스케일 업 (수직 확장)
단일 서버에 CPU, 메모리, 디스크를 추가하는 방식이다. 구현이 단순하고 기존 애플리케이션에서 아키텍처 변경 없이 적용할 수 있다. 최신 서버의 고성능 하드웨어를 활용할 수 있지만, 하드웨어 사양은 결국 물리적 한계에 도달한다. 리소스 간 병목 현상이 발생할 수 있고, 고성능 서버는 비용이 높다.
스케일 아웃 (수평 확장)
동일 역할의 서버를 여러 대 추가하여 부하를 분산하는 방식이다. Kubernetes에서는 Pod 복제본 수를 늘려서 확장한다. 필요에 따라 노드를 계속 추가할 수 있어 장기적인 확장성을 제공하며, 부하 감소 시 노드를 제거하여 리소스를 절약할 수 있다. 범용 서버를 사용할 수 있지만, 애플리케이션 재설계가 필요할 수 있고 네트워크 복잡도와 데이터 일관성 문제가 증가한다.
복제 (Replication)
데이터베이스 전체를 여러 서버에 복사하는 방식이다. 장애 내성과 가용성을 개선하지만, 모든 복제본의 일관성 유지를 위한 조정이 필요하다.
Primary-Secondary 복제
- 하나의 Primary 서버가 쓰기를 처리하고, 여러 Secondary 서버가 읽기를 처리한다.
- Primary에서 발생한 쓰기는 Secondary로 전파된다.
- Secondary 장애는 가용성에 큰 영향이 없지만, Primary 장애는 Failover 과정이 필요하며 데이터 손실 가능성이 있다.
Primary-Primary 복제
- 모든 서버가 쓰기를 받을 수 있다. 서버들은 업데이트를 올바른 순서로 적용하기 위해 조정하며, Primary-Secondary보다 복잡하다.
분산 (Distribution)
- 데이터를 노드나 샤드로 나누고 각 서버가 다른 샤드를 저장한다.
- 사용자 ID 범위나 날짜별로 샤드를 나눌 수 있다.
- 하나의 샤드만 접근하는 쿼리는 성능이 향상되지만, 여러 샤드에 걸친 쿼리는 지연시간과 복잡도가 증가한다.
- 샤드 서버가 실패하면 해당 샤드는 복구될 때까지 사용할 수 없다.
- 각 샤드를 여러 서버에 복제하여 완화할 수 있다.
- 일부 샤드가 불균형적으로 많은 워크로드를 받는 핫스팟 문제가 있으며, Consistent Hashing이 데이터를 고르게 분산하는 데 도움이 된다.
조합 사용
- 대규모 시스템은 데이터를 샤드로 나눈 후 각 샤드를 여러 서버에 복제한다.
- 중복 저장으로 장애 내성과 가용성이 향상되지만, 일관성과 유지보수 복잡도가 증가한다.
- Google의 AlloyDB와 Cloud Spanner가 두 방식을 모두 사용한다.
CAP와 PACELC 정리
네트워크 파티션이 발생할 수 있는 분산 시스템에서는 가용성과 일관성 사이의 트레이드오프가 필요하다.
CAP 정리에 따르면 완전 분산 시스템은 Consistency(일관성), Availability(가용성), Partition Tolerance(파티션 내성) 중 최대 두 가지만 제공할 수 있다.
네트워크 파티션은 불가피하므로, 파티션 발생 시 가용성과 일관성 중 선택해야 한다.
PACELC 정리는 파티션이 발생하면 가용성과 일관성 중 선택하고, 파티션이 없으면 지연시간과 일관성 중 선택해야 한다고 말한다. 파티션이 없을 때도 지연시간과 강한 일관성 사이의 트레이드오프가 존재함을 강조한다.
참고 출처
- https://portworx.com/blog/scale-up-vs-scale-out/
- https://fitech101.aalto.fi/fi/courses/designing-and-building-scalable-web-applications/part-2/3-data-distribution-sharding-partitioning-and-cap-and-pacelc-theorems
