계속 늘어나는 대규모 시스템을 어떻게 구축해 나아가야할까

- 이 책은 가상면접사례로 배우는 대규모 시스템 설계 기초에 있는 내용을 기반으로 작성하였습니다

 

프로젝트를 만들었다고 가정해보자 (아래 예제는 제가 실제로 구축한건 아님니다..)

 

1. 처음에 내가 작은 소소한 프로젝트로 A프로젝트라는 것을 만들어서 서버를 띄우고, dns 설정도 해주고 줄기차게 프로젝트를 오픈했다.

 

- 웹브라우저로 그 페이지를 사람들이 접속한다면,

- DNS를 통해서 IP를 받아오고, 그 IP주소로 HTTP 요청이 들어간다, 그 요청을 웹서버가 응답으로(페이지로) 반환한다.

 

2. 엥 ! 근데 사람들이 조금씩 더 들어오고, 그 사람들의 정보를 저장해야 할 일이 생겼다. 데이터베이스가 필요해졌다.

 

- 무슨 데이터베이스를 쓸 지 정해야한다. 관계형 데이터베이스? 비관계형 데이터베이스?

- 수직적 규모 확장을 할지, 수평적 규모 확장을 할지 정해야한다.

- 근데 나는 돈이 없다. 수직적 규모확장은 계속된 비용증가를 야기할 수 있다.

- 그래서 보통 대규모 어플리케이션을 지원하는데에는 수평적 규모 확장법을 사용한다.

- 근데,, 내 서버는 웹서버가 한대다 보니까 만약 사람들이 더 늘어나면 웹서버가 터지면 그대로 못쓰는 상황이 된다.

- 웹서버를 더 추가해서 쓰고 싶다, 로드 밸런서를 도입해야겠다.

3. 로드밸런서를 추가해서 많이 들어오는 사람들을 분산해서 웹서버가 받아들일 수 있도록 설정해놨다.

이제 서버1이 터진다면 로드밸런서가 서버2로 가서 부하를 나누도록 동작하게 해준다.

이제 웹계층은 안정화했는데,, 데이터베이스는 어쩌지?

 

- 데이터 베이스 다중화를 해야겠따.

- 보통은 주 데이터베이스와 부 데이터베이스 관계를 설정해서 데이터 원본은 주서버에, 사본은 부서버에 저장한다.

- 쓰기 연산은 주데이터베이스에서, 읽기 연산은 부데이터베이스에서 이뤄진다

- 만약 주서버가 죽는다면 부서버 여러대 중 한대가 주서버가 된다. 

- 이 과정에서 주서버로 대체된 부서버가 최신 상태가 아닐 수 있으므로 복구스크립트를 돌려서 추가 하도록하자.

 

4. 근데 모든 데이터를 데이터베이스에서 가져오게 하니까 너무 느리다.. 빠르게 하는 방법이 없을까..

캐시를 도입해볼까? 이미지도 너무 느리게 뜨는 것 같은데,, CDN을 추가해볼까?

 

- 캐시계층을 추가하자! 자주 참조되는 데이터를 메모리안에 두고, 뒤이은 요청이 빨리 처리할 수 있도록 해보자

- 캐시를 추가해서 데이터베이스의 부하를 줄이도록 하자

- 하지만 캐시를 쓸때는 유의할 점이 있다. https://phpdeveloper.tistory.com/59 를 참조해보자 ^^ ㅎㅎ

- 정적 콘텐츠를 전송할때 쓰는 지리적으로 분산된 서버의 네트워크인 CDN을 추가하자. 

5. 와 이렇게 만들었더니 내 페이지가 진짜 완전 세계적으로 유명한 사이트가 되었다..

이제 지금 쓰고 있는 데이터베이스로는 감당이 안된다.. 데이터센터를 알아보자 

 

- 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정해주도록 하는 DNS서비스를 제공받아보자.

- 다른 데이터센터의 데이터가 문제가 생기면, 모든 트래픽은 장애가 없는 데이터센터에 보내준다.

 

6. 시스템을 더 큰 규모로 확장하고 싶은데.. 시스템의 컴포넌트를 분리해서 각자 독립적으로 확장될 수 있도록 하고싶다.

이럴땐 메시지 큐는 많은 실제 분산 시스템이 이 문제를 풀기 위해 채용하고 있는 핵심적 전략 가운데 하나다

메시지 큐를 써볼까?

 

- 메시지 큐는 메시지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트이다.

- 메시지의 버퍼 역할을 하며, 비동기적으로 전송한다.

- 메시지 큐 동작방식은 프로듀서(producer)라는 입력서비스가 메시지를 만들어서 메시지큐에 발행한다. 컨슈머(consumer)가 받아서 메시지를 처리한다. 끝!

- 메시지 큐를 사용하게 되면, 서버간의 결합이 느슨해져서 규모 확장성을 보장되어야하는 안정적 어플리케이션을 구성하기 좋다. ex) 이미지 블러처리 시스템에서 , 비동기적으로 이미지 블러처리를 해야하는 이미지를 프로듀서가 메시지큐에 보내면, 비동기적으로 메시지큐에서 컨슈머가 받아서 처리한다. => 이러면 생산자와 소비자가 독립적으로 확장될 수 있다.

 

7. 사이트가 너무 커진다.. 로그,메트릭 그리고 자동화가 절실해진다

 

- 로그 : 에러로그를 모니터링할 수 있게 하는게 필요하다. 로그를 모아주는 모니터링 서비스를 이용하면 더 편하다

- 메트릭 : 사업 현황에 관한 유용한 정보를 얻을 수 있게 하자

- 자동화 : 시스템이 점점 커지면 사람이 감당하기 어려워지므로 일부 동작이 한정된 일들을 모아서 자동화 처리하면 생산성을 높일 수 있다.

 

8. 데이터베이스도 너무 커져서 다 갖다 붙여도 이제 더이상 감당이 불가능해. 샤딩을 하자!

 

- 수직적 확장을 하면 , 비용이 너무 많이 든다.

- 데이터베이스의 수평적 확장을 통해(샤딩) 더 많은 서버를 추가함으로서 성능을 향상 시키도록 한다

- 샤딩 전략을 통해 대규모 데이터베이스를 샤드로 나누고 저장한다 (각각의 다른 데이터베이스에 저장한다)

 

그럼 아래 그림 처럼 된다 짜잔~