확장성과 안정성 있는 서비스 시스템 설계 패턴

패스트 캠퍼스 (The Red: 4천만 MAU를 지탱하는 서비스 설계와 데이터 처리 기술 by 카카오페이지 기술전략이사 윤진석) 필기록입니다. 

---

 

 

초창기 웹 서비스 - 야후 (1994) 

 

http://yahoo.com <-> DNS lookup <-> Apache + Perl CGI <-> 메인 DB 

 

한 쪽에서 장애가 나면 모두 죽어버리는 문제 

 

1. 서비스 안정성이 떨어진다. 

- 서버 관점에서는 가용성이 떨어진다고 할 수도 있음

- 대부분 단일장애구간(SPoF : Single Point of Failure) 

 

데이터베이스의 중단 문제를 해결하기위한 Active-stanby 이중화 구성 

-> primary DB와 Secondary DB를 나눈다. 

 

 

2. 확장성이란? 

 

두 가지 의미로 분류해서 볼 수 있다. 

 

	서버 레벨의 확장성	코드 레벨의 확장성
정의	서버 측 요청 수가 증가에 따라 서버 확장이 용이한가?	새로운 요구 사항에 대해 코드 변경이 용이한가?
핵심 문제	1. 소프트웨어 스택 선정 2. 데이터베이스 설계 3. 시스템 아키텍처 4. 배포 관리	1. 언어 선정 2. 테이블 설계 3. 디자인 패턴 4. 버전 관리

 

active-standBy 구조에서는 서버 확장은 용이하지만 DB 확장은 어렵다. 

-> 네트워크로 연결된 공유 스토리지를 활용하기도 한다. (SAN stroage 등)

-> DB 인스턴스가 깨지더라도 멀티 DB 인스턴스들이 증설될 수 있다는 장점 

 

 

 

웹서버의 확장이 용이한 이유 

- 아무것도 공유하지 않는 구조 때문 

- 콜센터 트래픽을 예로 들면 -> 전화는 누가 받던 상관 없음, 부하에 따라 call을 다른 상담원에게 넘겨도 됨 

 

데이터베이스의 확장이 어려운 이유

- 데이터베이스는 공유자원이며, 데이터 관계의 복잡도 때문

- 출석부를 예로 들면

  -> 출석부가 여러 개 있다면, 나는 어디에 사인해야 할까? (데이터 update에 따른 동기화)

  -> 출석부는 생활기록부 등 다양한 데이터와 연관되어 관리되고 있음 ( 관계복잡도) 

 

 

최근에 각광받는 방식은 데이터를 partitioning 하는, 즉 샤딩함으로써 분산하는 문제 해결 방식 

 

 

 

요약 

 

초창기 야후의 사례부터 조금씩 진화하는 시스템 아키텍처를 알아보았다. 

 

요즘에는 상당수 클라우에 녹아들어가 있는 상태인데, 이렇게 진화 과정을 굳이 알 필요가 있을까? 

 

서비스 특성상 다른 형태의 아키텍처가 필요한 경우가 있고, 아마존 클라우드 서비스의 Elastic loadbalancing을 하는 종류 중에도 3가지 종류가 있듯이, 서비스 구현에 있어서 적합한 아키텍처를 설계하고 클라우드 서비스를 어떻게 활용할 것인지에 대한 설계 역량을 갖출 필요가 있다. 

 

 

 

문제의 정의와 이를 해결하는 알고리즘, 그리고 확장성 있는 소프트웨어 디자인과 구조를 통해 장애 성능 문제를 최소화할 수 있다.