. : 다수의 한문자
? : 0개 이상의 한문자
* : 0개 이상의 문자 또는 문자열
+ : 1개 이상의 문자 또는 문자열
^ : 문자열의 첫문(열)을 지정합니다.
$ : 문자열의 끝 문자(열)을 지정합니다.
(역슬래쉬) : 정규표현식에서 특별한 의미로 사용되는 문자의 특수기능을 제거합니다.(예:(, ), [, ] . 등)
{n} : 정확히 n번 반복
{n,} : n번 이상 반복
{n,m} : n 이상 m 이하 반복
[chars] : 문자들의 범위 또는 표현할 수 있는 문자들을 설정합니다.
예) [a-z] : a 부터 z 까지의 소문자, [tT] : 소문자 t 또는 대문자 T
정규표현식 단축표현들
[:alpha:] : 알파벳. [a-zA-Z] 와 같은 표현
[:alnum:] : 알파벳과 숫자. [a-zA-Z0-9] 와 같은 표현
[:digit:] : 숫자 [0-9] 와 같은 표현
[:upper:] : 대문자. [A-Z] 와 같은 표현
이용방식이 stateful인지의 여부에 따라 매우 다른 형태가 이루어지는데 stateful인 경우 상태를 서버간에
동기화시키기위한 도전이 필요하고 performance가 떨어질 위험이 있으므로 될 수 있으면 stateless하게 이용할 수
있도록 노력하고 있다.
가용성(availability),
확장성(scalability)
일반적인 load balancing으로 서버군에 대한 접근은 load balancer를 통해서만 수행되며 load
balancer가 실제 request를 담당할 서버들을 주어진 알고리즘을 통해 선택하는 방식
통
상은 load balancing에 대한 architecture를 이야기 할때 가용성(availability),
확장성(scalability)을 살펴보게 되는데 위와 같은 구조는 load balancer가 병목이 생기지 않는다면 확장성은
매우 좋은 구조다. 다만, load balancer 자체에 대한 가용성 문제 때문에 가용성 부분은 쉽게 단정하기 힘들다.
따라서 load balancer를 다중화 할 수 있다면 가용성이 증대되는 효과가 크고 또한
load balancer의 병목위험을 없애 확장성도 크게 높일 수 있게 된다.
Server load balancing techniques
다음의 2가지로 구분될 수 있다.
Transport-level
Application-level
또
한 hardware인지 software인지를 이용해 구분할 수도 있는데 transport-level의 경우는 대부분
hardware타입이 많다(hardware타입은 속도가 빠르다.). 다만, hardware의 경우는 비용이 많이 소요되는 단점이
있다.
DNS-based load balancing
DNS
설정을 이용해 요청 host 명에 다수의 ip를 배정하여 round robin방식으로 balancing하게 되는데
구축이 매우쉽다.
따로 load
balancer가 필요없다.
위와 같은 장점이 있는 반면 다음과 같은 치명적 단점을 가지고 있다.
stateful 지원이 안된다.
클라
이언트에 cache를 가지고 있기 때문에 가용성에 문제가 발생한다.(예를 들면 특정 서버가 고장이 났어서 클라이언트 cache에
해당 서버 주소가 있다면 접근을 시도할 것이므로)
TCP/IP Server load
balancing
Virtual IP를 이용한 스위칭을 통해 수행되며 LVS(Linux Virtual Server)로
구성된다. 아래 그림과 같이 load balancer 자체의 가용성을 높이기 위해 backup load
balancer 채용이 가능하다.
단, 이들 TCP/IP level의 load balancer는 session처리나 caching처리를
application에서 따로 담당해야 하는 단점이 있다.
Caching
어
플리케이션 수준에서 caching이나 session처리를 위한 서버들 사이의 공용 메모리 영역을 설정할 수 있는 솔루션이
필요하다.
cache에
대해서는 위 그림과 같이 구성할 수 있다. 위 그림에서 Server1, Server n은 모두 동일한
Cache Server를 이용할 수 있도록 구성되어 있다.
위와 같은 구조는
spymemcached와 같은 memcached 라이브러리를 이용하여 구성한다. 즉,
request에 대해 response와 짝을 이뤄 cache에 저장을 하고 request가 올때마가 cache에서 먼저 검사를
해서 있으면 바로 해당 response를 return하고 그렇지 않은 경우에만 business layer를 구동하는 형태임.
Application session data support
caching
과 session자료는 다른 성격을 갖는다. 즉,
cache는 있다면 좋지만 없어도 새로 생성해서 사용할 수 있는 특징이 있지만 session은 반드시 하나씩 있어야 하고
없어져서는 안되는 자료이다. 따라서 cache관련 구조로는 한계가 있고 cookie를 이용하는 방안도 보안 위험성이 높다.
따라서 이런 종류의 경우에 대해서는 application(server software)에서
감당이 되어야 한다.
Client affinity
memcached
구조나 session server 구조를 이용하는 경우 양이 많아지면 network traffic이 필요이상으로 많아 지는
문제가 발생한다. 이를 해결하기 위해서는 한번 접속한 client에 대해서 접속했던 load balancer 하위의 실질서버에
그 이후 요청을 지속으로 보내서 불필요한 network traffic을 막을 수 있다. LVS에서는
client affinity를 설정에 의해 지정할 수 있다. dial-up 연결에 대해서는 하지만 항상 새로운 연결이라고 여기기
때문에 affinity가 작동하지 않는다는 점을 주의하자.
part 1에서 언급한 TCP/IP level의 load balancing으로 static web service는 충분한 기능을
수행하지만 dynamic web service에 대해서는 cache의 문제나 session의 문제 등을 원활히 처리하기 위해서는
memcached 구조나 session server 구조 등 부가적인 구조가 필요해 진다.
따라서 이들 dynamic web service에 대해서는 application-level의 load
balancing이 필요해진다.
위 그림은 transport level과 app level의 load balancer를 포함하는 구성이다.
위 그림과 같은 tomcat서버의 예는 다음과 같다.
물리적으로 transport-level load balancer와 Apache는 같은 서버가 될 수 있다.
여
기서 application-level load balancer는 요청 HttpRequest로부터 사용자ID나
sessionID등을 이용해 뒷 단의 서버를 선택하는 방식을 이용한다면 cache나 session에 대한 처리 문제를 해결할 수
있으며 cookie값을 이용하는 방법도 이를 해결할 수 있는 solution이다.(물론 사용자가 cookie사용을 제한하는
경우는 사용할 수 없게 되겠지만)
HTTP redirect-based server
load balancer
위의 구조와는 달리 redirect 방법을 이용해서 load balancer가 접속해야 하는
서버를 분리 지정해주는 방식이 있을 수 있다. 이는 처음 접속시에만 실질서버를 알지 못하고 이미 접속해서
사용하기 시작하면 실질적인 서버를 알고 그곳에 접속해 서비스를 이용하는 형태가 된다.
이 구조는 2가지 단점을 갖는다.
외부 인터넷에 서버 구조를 투명하게 공개함으로써 공격 받을 수 있는 영역이 넓다.
고 가용성에 문제가 있는데 이미 서버를 배정받아 서비스 중인 상황에서 해당 서버가 말썽을 부리면 그곳에서
서비스를 받던 클라이언트는 고스란히 말썽을 감내해야 한다.
Server-side server load balancer interceptor
interceptor 방식으로 구성을 하게 되면 아래 그림과 같은 구조를 가질 수 있다.
위 구성을 사용하게 되면 불필요한 network 이동을 줄일 수 있다는 단점이 있다.(로컬 접속의 경우에 대해서만) 하지만
서버의 scalability를 훼손할 수 있다. 즉, 많은 양의 서버를 증설하는 경우 문제가 발생할 수 있다.
Client-side server load balancer interceptor
아래 그림과 같이 사용하는 경우 가용성이나 확장성을 높일 수 있으나 정상적인 웹서비스를 위해서 cross-domain 문제등을
해결해야 하는데 이런 부분은 매우 program지향적인 작업이 된다.
Application session data support
cache나 session자료에 대한 공유의 문제에 있어 cache는 affinity를 이용해서 자체 해결하도록 할 수 있으며
다만 session자료에 대한 공유가 필요해 진다. 이는 서버들간에 session자료를 공유하는 구조를 갖고 클라이언트에서는
jsessionid를 cookie에 담아 서버에 요청할 때 부가하는 방법을 이용하면 서버가 문제가 생겨 다른 서버로 이동할때에도
문제가 없게 된다. 다만, 서버가 많아 서로간의 session자료 공유가 메모리상 문제가 발생된다면 서버들을 특정 수만큼씩의
그룹으로 나눠 그 그룹내에서만 session자료를 공유하는 방향으로 해결할 수도 있다.
또한 session backup 구조를 이용한다면 서버들 끼리 세션자료를 공유할 필요조차 없어지며 자신이 보유한
sessionid 이외의 요청이 들어오면 backup server에 요청하여 세션자료를 가져와 이용하면 되는 구조이다.
Apache Tomcat load balancing architectures
앞의 내용에서 Apache Tomcat구조의 load balancing 예제를 간단히 살펴보긴 했는데 아래 그림과 같은 구조가
적합할 것이다.
그림에서와 같이 http 서버 전에 tcp/ip level의 load balancer를 LVS를 이용해 구성하고(backup까지
포함해서) Apache 서버에서는 application-level load balancing을 mod_proxy,
mod_proxy_balancer를 통해 수행하여 ajp를 통해 뒷단의 tomcat에 전달할 수 있게 된다. 다만,
tomcat도 session자료 등 공유해야할 자료가 있는 만큼 session server를 따로 두지 않고 tomcat의
clustering 구조를 이용하여 해결할 수 있다.
In conclusion
client-side load balancing은 쉽고 강력한 방법이긴 하지만 cross domain 문제와 같은 해결에 많은
자원이 소모되는 상황이 발생할 수 있다.
순수한 transport level load balancing은 쉽고, 유연하며 효율적이긴 하지만 cache의 문제와
session자료 문제를 해결하기 위한 공용장소의 필요가 생기게 되며 많은 수의 network traffic이 발생할 가능성이
높아진다.
이런 경우 client affinity를 구현하면 cache와 session에 대한 문제를 상당부분 해소할 수 있게 된다.
