3.1 기본적인 구성
서버의 구성에는 흔히 3가지의 패턴이 있고, 이를 이론상으로 1 tier부터 2,3 tier 구조라고 부른다. 1-tier의 경우 하나의 물리적 서버 안에 웹서비스를 모두 구현하는 것이며 2,3 tier는 이를 WEB, DB, File 형태로 각각을 서버로 분리하여 구현한 것을 말한다. 각 형태의 전형적인 구분 방법은 아래와 같다. 이렇게 역할을 명확히 구분하게 되면, 해당 역할을 하는 솔루션의 버전을 변경하거나 다른 솔루션으로의 전환, 교환이 쉬워진다. 수직적인 스택에 비해 결합도가 강해 역할을 독립적으로 운용하기에는 어렵지만, 이렇게 세분화하여 분리함으로써 성능과 다중성 및 가용성 등의 대책을 조금 더 용이하게 세울 수 있게 된다.
구분 | 내용 | 역할 및 대표 제품 |
WEB | 클라이언트의 접속 데이터 전송 정적 데이터 전달 동적 데이터 중계 동적 데이터 생성 애플리케이션 로직 |
WEB 서버나 애플리케이션 서버(WAS) NginX, Apache(cgi/mod_php/mod_perl), php-fpm, plack, Unicorn, gunicorn, Tomcat, Classfish, WebLogic, JBoss(WildFly) 등 |
DB | 데이터베이스의 가동 및 데이터베이스의 데이터 보관 | RDBMS나 NoSQLDB PostgreSQL, MySQL, Oracle, DB2, memcached, Redis, MongoDB 등 |
File | 파일 형식의 데이터 보관 화상 및 프로그램 파일 등을 보관 |
디스크 스토리지, 오브젝트 스토리지 하드디스크, Amazon EBS, Amazon S3 등 |
시스템의 구성을 변경하는 경우, 구성 변경에는 전형적인 패턴이 몇 가지 존재하며 대부분의 시스템이 해당 패턴을 기준으로 시스템을 확장하거나 축소하게 된다. 이 4가지 방법에서 스케일 아웃은 서버를 추가로 준비하는 등 특정 조건에서는 다중화를 겸할 수 있지만, 근본적으로는 다른 개념이므로 혼동하지 않도록 주의하여야 한다.
방법 | 목적 | 내용 |
다중화 | 다중성 향상, 가용성 향상 | 같은 기능과 역할의 기기를 여러 대 준비하여 단일 기기의 고장에 따른 영향이 시스템 전체에 미치지 않도록 함으로써 시스템 전체의 가용성을 높인다. |
기능분할 | 처리 능력 향상 | 1대로 여러 기능을 제공하고 있는 경우, 서버를 기능별로 준비하여 1대당 처리 부하를 감소시켜 시스템 전체의 성능을 향상시킨다. |
스케일 업 | 처리 능력 향상 | 구성은 변경하지 않고 서버 자체의 성능을 향상시킴으로써 시스템 전체의 성능을 향상시킨다. |
스케일 아웃 | 처리 능력 향상 | 같은 기능과 역할의 기기를 여러 대 준비하여 처리를 분담시킴으로써 시스템 전체의 성능을 향상시킨다. |
기능 분할의 경우 서버 1대로는 서비스를 견디는데 스펙이 부족할 때, 이를 해결하기 위해 WEB과 DB의 기능을 분할하게 되는 경우가 많다. 이 때는 DB만 분할하는 경우와 DB, File을 함께 분할하는 두 가지 방법이 있다. 다중화의 경우 대기용(StandBy) 서버를 운용 서버와 동일한 스펙으로 구축을 해 두고 DB, File을 동기화시켜 가용성을 향상 시키고자 하게 된다. 이때, DB와 File의 데이터 동기화는 DBMS의 기능을 사용하기도 하고 공유 스토리지(하드웨어 및 소프트웨어)를 이용하기도 한다. 또한 동기 방식으로 완전 동기, 비동기 방식 등이 있기 때문에 설계할 때 주의하여야 한다(해당 내용은 8장에서 소개된다).
WEB과 DB/File을 서로 분리하여도 성능이 나아지지 않는다면 WEB을 추가로 증설하여 연결하는 스케일 아웃 방법을 사용한다. WEB의 경우 사용자 수에 따라 처리량이 증가되기 쉽기 때문에 WEB을 병렬로 증설하여 액세스를 분산시키게 되면 시스템 전체의 성능을 향상시키는데 도움이 된다.
3.2 부하 분산(로드밸런싱)의 기초 지식
로드밸런싱의 목적은 부하의 분산이지만, 다중화의 역할을 하기도 한다. 사용자가 웹 서버에 액세스 하는 지점을 로드밸런싱하는 경우가 가장 흔하지만, 웹 서버에서 애플리케이션 서버 또는 AP 서버에서 DB 서버로의 액세스에서도 로드밸런싱이 가능하다. 로드밸런싱은 로드밸런서를 사용하거나 DNS 라운드 로빈을 사용하여 구현할 수 있다. 로드밸런서는 서버 측(수신 측)에 부하를 분산할 수 있는 구조를 제공하며, 하드웨어와 소프트웨어 모두 구현 가능하다. 로드밸런서는 클라이언트가 서버 측으로 액세스 할 때마다 연결할 서버를 변경함으로써 대량 액세스에 대한 분산이 가능하다.
DNS 라운드 로빈은 클라이언트 측의 동자에 의존적인 방법으로, DNS 내부에 하나의 레코드에 대한 복수의 IP주소를 등록하여 순서를 불규칙하게 응답, 결과적으로 부하가 분산되는 것을 기대하는 방법이다. 이는 클라이언트가 충분히 많고 다양하다는 것을 전제로 하여, 한 명으로부터의 대량 액세스는 분산할 수 없게 된다. DNS 라운드 로빈의 경우에는 클라이언트 또는 OS, 브라우저에 의존적인 방법이기 때문에 시스템을 이용하는 사용자의 OS, 브라우저 버전에 따라 기대했던 효과나 가용성의 향상 효과를 얻지 못할 경우도 발생한다.
로드밸런서의 이점은 의도한 대로 확실하게 서비스를 분산할 수 있다는 점이며, 로드밸런서와 웹 서버를 활용하면 서비스를 중지하지 않고도 업데이트 등을 할 수 있게 된다. 다만, 로드밸런서가 단일 장애 포인트가 되지 않게 하기 위해서는 밸런서 자체를 다중화하는 것도 고려를 해야만 한다. DNS 라운드 로빈의 경우에는 추가 설비가 필요 없다는 이점이 있지만 문제 발생 시 DNS의 TTL을 따르지 않는 장비들의 영향을 받아 신속한 전환을 기대하기가 어렵다는 단점이 있다.
로드밸런서는 L4-NAT, L4-DSR, L7 크게 3개의 종류로 나뉜다. L4 로드밸런서의 경우 OSI 참조모델의 제4 계층(TCP, UDP)까지를 처리하며 L7 로드밸런서는 제7 계층(HTTP, SMTP 등)까지를 모두 처리하게 된다. 이 두 가지를 비교하자면 L4가 처리하는 계층이 더 좁기 때문에 처리량이 줄어 해당 장비가 보틀넥이 되기 어렵고, L7의 경우에는 고기능성 장비인만큼 L4와 비교하자면 보틀넥이 되기 쉽다는 차이가 있다.
L4-NAT(Proxy Mode)는 IP주소를 변환하는 NAT 방법과 IP와 통신포트까지 변환하는 NAPT 방법을 모두 이용이 가능하며, NAPT방법을 사용하는 것이 매우 일반적이다. L4-NAT와 L7은 같은 구조로 응답을 주고받지만, L7의 경우에는 응답을 캐시 하거나 SSL의 종단이 되거나 응답이 500(Internal Server Error)인 경우 서버 대신 에러 화면을 띄우는 기능도 제공한다.
L4-DSR(Direct Server Return)은 수 Gbps가 넘는 대량 트래픽이 발생하는 시스템에서 사용하며, 네트워크적으로 조금 더 까다로운 구현을 통해 응답 패킷이 로드밸런서를 직접 통하지 않게 하여 로드밸런서가 보틀넥이 되지 않도록 한다.
로드밸런서의 액세스 분산 방식은 대표적으로 아래와 같이 4가지로 분류된다. 또한 로드밸런서는 헬스체크 기능을 사용할 수 있는데, 분산 목적지의 서버가 응답하지 않는 상황에서 해당 서버를 분산 대상에서 제외하는 기능이다. 로드밸런서 중에는 분산 목적지에 접속하지 못하였을 경우 목적지 리스트의 다음 목적지로 다시 접속하도록 하는 기능을 가진 제품도 있다.
방법 | 내용 |
라운드로빈 (Round Robin) |
분산 목적지 목록에 있는 순서대로 액세스를 분산한다. 간단하여 알기 쉽지만, 분산 목적지 서버의 상태를 고려하지 않기 대문에 어더한 이유인지와 상관없이 일시적으로 부하가 높아진 서버로도 액세스가 분산 된다. |
가중 라운드로빈 (Weighted Round Robin) |
기본적으로 라운드로빈과 동일하지만, 지정한 가중치에 따라 특정 분산 목적지에 많거나 적은 액세스를 분산한다. 가중치의 기준은 서버의 스펙이 동일하지 않은 경우 서버의 스펙에 따라 적절한 양의 처리를 부담시키기 위해 이용한다. |
최소 커넥션 (Least Connection) |
접속 수가 적은 서버에 액세스를 분산한다. 대부분의 웹 사이트 접속은 짧은 시간 내에 종료되고 접속이 끊어지기 때문에 접속 수의 변동이 심해 밸런스가 흔들리기도 한다. |
가중 최소 커넥션 (Weighted Least Connection) |
최소 커넥션과 동일하지만 가중치를 조절하여 서버별 액세스 양을 변동 시킬 수 있다. |
'Book Study > 웹 엔지니어가 알아야 할 인프라의 기본' 카테고리의 다른 글
Chapter 5. 웹 서비스 운용 1 : 시스템 감시의 기본 (0) | 2021.04.04 |
---|---|
Chapter 4. 인프라 준비의 기초 지식 (0) | 2021.03.30 |
Chapter 2. 인프라 기술의 기초 지식 -2 (0) | 2021.03.11 |
Chapter 2. 인프라 기술의 기초 지식 -1 (0) | 2021.03.07 |
Chapter 1. 웹서비스에서 인프라의 역할 (0) | 2021.03.03 |