[대규모 시스템 설계] 1-1. 아키텍처 설계

지금까지 여러 프로젝트를 진행해왔지만 서비스를 더 키우거나 많은 사용자들의 유입이 들어왔던 경험은 없었다. 사실, 실무에서의 개발 경험이 없었기 때문에 위의 사례는 극히 드물다고 생각한다. 특히, "서비스를 런칭해야지!" 라는 거대한 포부를 가지고 개인, 팀 프로젝트를 진행을 해본 분들이 계시다면 팀 동료를 제외한 실사용자 100명을 채우는 것은 상당히 힘든일이라는 것을 공감할 것이다. 즉, 트래픽을 처리하기 위한 대규모 시스템 설계는 실무 경험이 없는 신입 개발자들이 경험하기는 힘들다는 것이다. 그러면 어떻게 해야하는가? 개인적으로 학습이 필요하고 그 학습을 토대로 아키텍처를 구상해야한다고 생각한다. 최근 1년간 싸피 교육으로 개인 공부를 소홀히 하였기에 다시 포스팅을 꾸준히 시작해보려고 한다.

 

이번 주제는 여러 고민 끝에 [대규모 시스템 설계] 에 대한 글을 기록하려고 한다. 최대한 쉽게 풀어서 작성할테니 흐름 정도를 이해하면서 간단하게라도 훑어보자!

 

단일 서버

요즘에는 MSA라는 아키텍처로 많이 설계를 한다. 하지만, 복잡한 아키텍처를 다루기 이전에 한 대의 서버에서부터 어떻게 늘려나가는지 간단한 시스템부터 설계하는 능력부터 키워야한다고 생각한다. 

 

 

 

 

1. 개발자 배씨(사용자)가 도메인 이름 (baebalja.com) 을 이용하여 웹 사이트에 접속한다. 이 접속을 위해서는 도메인 이름을 도메인 이름 서비스 (DNS)에 질의하여 IP 주소로 변환하는 과정이 필요하다.

2. DNS 조회 결과로 공인 IP 주소가 반환되는데, 위의 IP 주소는 실제 주소가 아닌 필자가 임의로 정한 주소니 검색해보진 마라!

3. 해당 IP 주소로 HTTP 요청이 전달되고, 전달 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답을 반환하게 된다.

 

데이터베이스

사용자가 늘면 서버 하나로는 충분하지 않을거다. 즉, 데이터 베이스 서버용도 하나를 두어야한다. 데이터베이스는 기본적으로 다들 알겠지만, 말 그대로 데이터들을 보관하는 서버이다. 이렇게 웹/모바일 트래픽 처리 서버 (웹 계층)와 데이터베이스 서버 (데이터 계층)을 분리하게 되면 독립적으로 확장해 나갈 수 있다. 

 

 

 

Q. 어떤 데이터베이스 사용할것인가? 

 

관계형 데이터베이스와 비-관계형 데이터베이스 사이에서 고를 수 있을거다. 

 

1. RDB (관계형 데이터베이스) - MySQL, 오라클 DB, PostgreSQL

자료를 테이블과 열, 칼럼으로 표현하고 SQL을 사용하면 여러 테이블에 있는 데이터를 그 관계에 따라 조인하여 합칠 수 있다. 

 

2. NoSQL (비관계형 데이터 베이스) - NoSQL, CouchDB 

비관계형 데이터베이스는 다시 네 부류로 나눌 수 있는데, 키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소가 있다. 이러한 비-관계형 데이터베이스는 일반적으로 조인 연산을 제공하지 않는다. 

 

필자도 경험을 해보았지만, 프로젝트를 처음 입문하게 됐을 때 관계형 데이터베이스를 기본적으로 많이 사용하게 된다. 하지만, 여러 서비스를 구축하다보면 관계형 데이터베이스가 적합하지 않는 상황이 올 때가 있다. 예를 들면, 아주 낮은 응답 지연시간이 요구되거나 다루는 데이터가 관계형 데이터가 아닐 때, 아주 많은 양의 데이터를 저장할 필요가 있을 때, 데이터를 직렬화하거나 역직렬화 할 수 있기만 할 때 등 비-관계형 데이터베이스를 고려해봐도 좋을 것이다. 

 

 

수직적 규모 확장 VS 수평적 규모 확장 

수직적 규모 확장은 트래픽의 양이 적을 때 좋은 선택이며, 가장 큰 장점은 단순함이다. 이 방식은 더 좋은 CPU, 더 많은 RAM 등을 추가하여 고사양 자원을 늘리며 스케일 업이라고 불린다. 

 

하지만 심각한 단점이 있는데, 한 대의 서버에 CPU나 메모리를 무한대로 증설할 순 없다는 것이다. 또한, 장애에 대한 자동 복구 방안이나 다중화 방안을 제시하지 않는다. 즉, 서버에 장애가 발생하게 되면 서비스를 이용할 수 없다는 것이다. 

 

그래서 대규모 애플리케이션을 지원하는 데는 보통 수평적 규모 확장법이 적절하다. 수평적 규모 확장은 더 많은 서버를 추가하여 성능 개선하는 행위를 말하며, 스케일 아웃이라고 말을 한다. 

 

서버를 여러대로 증설하긴 했지만, 만약 너무 많은 사용자가 하나의 서버에만 접속하여 서버가 한계 상황에 도달하게 된다면 어떻게 해야할까? 자원에 대한 한계는 존재하기 때문에 응답 속도가 느려지거나 접속이 불가할 수 있을 것이다. 그렇다면 사용자의 요청을 분산시키는 놈이 필요하게된다.

 

 

로드밸런서

로드밸런서는 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다. 

 

 

 

 

먼저 사용자는 로드밸런서의 공개 IP 주소를 DNS를 통해 얻어오고 로드밸러서의 공개 IP 주소로 접속하게 된다. 따라서 웹 서버는 클라이언트의 접속을 직접 처리하지 않는다. 즉, 로드밸런서라는 새로운 놈이 중간에 개입하게 되면서 "넌 절로 가, 넌 일로 가" 알려주는 역할을 한다는 것이다. 

 

서버 간 통신에는 사설 IP 주소가 이용된다. 이전에 필자가 포스팅 한 것이 있기 때문에, 한 번 읽고 오는 것도 도움이 될것이다. 

 

[네트워크 2편] IP 주소 체계

 

간단히 말하면, 사설 IP 주소는 같은 네트워크에 속한 서버 사이의 통신에만 쓰일 수 있는 IP 주소로, 인터넷을 통해서는 접속할 수 없다. 여러분이 네이버에 IP 주소를 치게되면, 공유기의 공인 IP 주소가 나오지만 해당 공유기로 인터넷이 연결된 각각의 단말기(노트북, 탭, 휴대폰)의 사설 IP 주소는 모른다는 것이다. 즉, 로드 밸런서는 웹 서버와 통신하기 위해 바로 이 사설 주소를 이용한다는 것. 

 

이제 로드밸런서를 뒀으니, 다음과 같은 상황에서 해결할 수 있게된다. 

 

1. 서버 1이 다운되면 모든 트래픽이 서버 2로 전송된다. (웹 서비스 다운 방지) 

2. 두 대의 서버로 트래픽이 감당이 안된다면, 더 많은 서버 추가하여 로드밸런서가 자동으로 트래픽 분산한다. 

 

지금까지 어느정도 흐름은 이해가 갈것이다. 하지만 여기서 문제가 있다. 데이터 계층 (데이터베이스)에서 만약 문제가 발생한다면? 사용자의 모든 데이터가 사라질 것이다. 

 

다음 장에서는 데이터베이스의 다중화에 대해서 알아볼것이다.