Load Balancer
Load Balancer의 목적은 여러 서버로 부하를 나누어 특정 서버에 부하가 집중되는 것을 막고 여러 서버의 주소를 직접 노출하지 않아 보안상의 기능도 한다.
Load Balancer는 여러 Quality Attributes를 향상시켜줄 수 있다.
-
Scalabitlity
Traffic의 양에 따라 처리하는 서버의 수를 조정할 수 있다. 이때 Traffic을 단위시간당 요청의 수, 네트워크 대역폭 등을 기준으로 측정한다. -
HA(High Availability)
Load Balancer가 주기적으로 각 서버의 health check를 수행하여 비정상적인 동작이 감지되면 해당 서버로는 요청을 보내지 않을 수 있다. -
Performance(Throughput)
많은 수의 서버를 사용할 수 있게 해주므로 성능향상에 도움을 준다. -
Maintainability
두 개 이상의 서버를 사용할때 하나의 서버를 유지보수하기 위해 중단하여도 나머지 하나의 서버가 남아있기 때문에 유지보수에 수월하다.Load balancer에는 다양한 종류가 있다. DNS load balancing, Hardware load balancing, Software load balancing, GSLB(Global Server load balancing).
DNS는 URL을 IP로 변환해주는 시스템으로 네트워크 라우터를 활용해 주소를 찾아준다. DNS서버로 요청을 보내면 IP주소를 반환해주는데 Round Robin 방식을 사용해 요청할때마다 IP 주소목록 순서를 다르게 반환해 준다. 이 방식은 domain name만 구매하면 되므로 간단하고 싸다. 하지만 DNS 서버는 우리 서버의 health check를 하지않아 서버에 문제가 생겼을때 요청시간이 길어지는 문제가 발생할 수 있다. 또한 단순히 round-robin 방식을 사용하기때문에 부하 분산을 최적으로 하지 못한다. client는 모든 서버의 IP 주소 목록을 받기때문에 보안상의 문제가 발생할 수 있다. 시스템의 내부 구현에 대한 정보를 일부 노출할 수도 있고 하나의 IP 주소로의 악의적인 요청을 막을 방법이 없다.
DNS load balancing의 단점을 보안한 방법이 Software/Hardware load balancing이다. load balancing만을 목적으로한 Software/Hardware를 개발한 것을 말한다. 이 방식은 IP 주소의 목록을 반환하는 것이 아니라 하나의 IP만 반환해 시스템이 몇 개의 서버로 구성되어 있는 정보를 숨기고 Monitoring system의 기능도 할 수 있어 각 서버가 정상적으로 동작하는지 확인할 수 있다. 또한 부하 분산을 단순히 round-robin 방식이 아닌 각 서버의 성능, 실행중인 부하의 양, Open Connection의 갯수를 고려하여 수행한다. 그리고 서버를 기능단위로 나눠 개발하는 경우 각 기능별 독립적인 수행을 도와준다. 하지만 DNS resolution problem을 직접 해결할 수 없어 URL을 IP 주소로 변환해주는 DNS의 기능은 여전히 필요하다.
GSLB는 위의 두 방식의 하이브리드 버전이다. GSLB는 DNS처럼 URL을 IP로 변환해주며 더 나아가 지능적인 routing decision을 수행한다. client의 주소로 위치를 파악해 client와 위치적으로 가까운 서버의 주소를 알려주는 방식으로 말이다. 또한 모니터링 기능도 제공한다. 대규모 시스템의 경우 다양한 위치에 서버 군집고 위치에 따라 LB를 가지며 가용성을 고려해 두 개 이상의 LB를 가지기도 한다. 그런 점에서 GSLB는 서버의 주소를 알려주기보단 LB의 주소를 알려주는 경우가 많다. GSLB는 위치적인 것만 고려하는 것이 아니라 traffic, 각 data center의 CPU 부하, response time, badwidth도 고려해 최적의 결정을 내린다.
Message broker
두 애플리케이션은 직접 통신하거나 Load balancer를 통해 통신을 한다. 이 것은 두 애플리케이션이 정상적으로 동작을 한다는 전제가 포함되어 있다. Sender는 receiver가 정삭적으로 처리했다는 응답을 받을때까지 기다린다. 이러한 방식을 Synchronous라고 한다.
Synchronous방식은 몇가지 단점이 존재한다. 첫째는 위에서 언급했듯이 두 서버가 정상적으로 동작해야한다는 것이다. 이는 두 서버가 작은 양의 데이터를 주고 받는 상황이라면 괜찮은데 큰 규모의 데이터를 다뤄 긴 지연시간이 발생하면 복잡해진다. 두번째는 traffic이 갑자기 급증하는 상황에 문제가 될 수 있다.
이러한 문제상황은 Asnychronous방식으로 해결할 수 있다. Message broker는 asynchronous 방식에 자주 사용되는 빌딩 블록으로 sender와 receiver 사이에서 데이터를 queue 형태로 저장하는 빌딩 블록이다. Message broker는 일시적으로 데이터 저장, 메시지 라우팅, 유효성 체크, load balancing의 역할을 할 수 있다. 메시지 브로커는 traffic spike가 발생하였을때 방파제 역할을 할 수 있다. 또한 Pub/Sub 패턴을 제공해 sender 와 receiver의 coupling을 약화시킬수 있다.
Quality Attributes 관점에서 Message broker는 Fault Tolerance을 제공해준다. 메시지 브로커를 사용하게 되면 receiver가 일시적으로 문제가 생겨도 메시지를 잃지 않아 시스템이 멈추지 않고 동작하게 해준다. Fault Tolerance로인해 자연스럽게 HA를 제공한다. 또한 traffic spike가 일어나더라도 message broker가 이를 잘 저장하고 있기때문에 scalability를 제공한다고 할수도 있다. 하지만 두 서비스를 간접적으로 연결하기 때문에 성능이 떨어질 수 있다. 많은 경우에는 성능하락이 크지도 않고 이보다 얻는 이점이 많다.
API gateway
하나의 API로 서비스를 개발하려고 하다보면 code base가 너무 복잡해지는 경우가 많다. 그래서 서비스를 여러 목적으로 나눠 각 목적에 맞게 여러 API로 구성하는 것은 좋은 방법이 될 수 있다. 하지만 여러 API로 구성하게 되면 Authentication/Authorization으로 인해 성능하락, 중복이 발생할 수 있다. 이러한 것은 API Gateway로 추상화 할 수 있다. API Gateway는 API composition이라는 software architecture pattern을 따른다. 서비스를 구성하는 모든 API를 하나의 API로 구성하여 client는 단순히 하나의 service를 호출해도 된다.
API Gateway는 여러 장점을 가진다.
1. 시스템을 추상화하여 내부구현을 투명화한다.
2. security, authorization, authentication을 한번에 처리한다.
3. permssion에 따라 다른 기능을 제공한다.
4. rate-limiting을 구현하여 Denial of Service(DoS) attacks를 막을 수 있다.
5. 다양한 서비스를 한번에 요청할 수 있다.
6. caching, static content는 바로 응답할 수 있다.
7. 모니터링 기능을 제공할 수 있다.
8. Protocol transformation을 제공해 다양한 외부 서비스와 통합할 수 있다.
API Gateway를 사용할때 주의사항
1. API Gateway에 business logic을 넣어선 안된다.
API Gateway의 목적은 business logic을 더욱 수월하게 구현하기위해 API 구성을 단순화하여 잘 활용할 수 있게 하는 것이였다.
2. Single Point of Failure
모든 요청은 API Gateway를 거치기 때문에 Single Point of Failure의 위험이 있다. 따라서 human error의 가능성을 제거하고 새로운 release는 주의깊게 배포해야한다.
3. 외부 서비스가 API Gateway를 거치지 않게해선 안된다.
외부 서비스가 API Gateway를 거치지 않고 직접적으로 연결되면 coupling이 강화된다.
CDN(Content Deliver/Distributed Network)
CDN은 end-user에게 Content를 빠르게 제공하기 위해 곳곳에 분산되어 있는 Server이다. CDN은 website content를 edge server에 caching하여 end-user에게 더 빠른 접근성을 제공한다. CDN을 사용하면 main server 입장에서는 모든 요청에대해 응답해야한다는 부담이 줄어들어 전체 시스템 입장에서는 더 높은 traffic을 처리할 수 있게해준다. 사용자 입장에서는 위치적인 영향으로 더 빠른 응답을 받을 수 있다. CDN은 보통 cache 데이터를 저장하기 위해 더 빠르고 최적화된 하드드라이버를 사용하며 content를 압축하여 대역폭을 낮출 수 있다.
CDN에는 Push, Pull Publishing 전략이 존재한다. Pull Strategy는 end-user가 최초로 content를 요청하면 CDN은 Server에 content를 요청한다. 한번 caching 된 content는 설정값인 TTL(Time To Live)동안 유효하며 TTL안에 다시 그 content에 대한 요청이 오면 Server에 접근하지 않고 바로 반환한다. 하지만 expire 되면 Server에게 다시 요청하여 변화된 점이 있다면 새로운 content를 caching하고 아니면 기존의 content의 TTL을 재설정한다. Push Strategy는 CDN에 content를 publish할 책임이 server에 있다. Server가 content의 변경을 감지하면 CDN에 republish한다. Push Strategy를 위해 CDN provider는 이 모델을 직접 구현하거나 TTL을 큰 값으로 설정하여 cache가 절대 만료되지 않게 한다.
Pull model의 장점은 모든 작업을 CDN 제공자가 책임져 낮은 유지비용이 든다는 점이다. 단점으로는 최초 사용자의 경우 server까지 요청이 닿기때문에 지연시간이 길고 모든 content에 TTL을 같게 설정하면 traffic spike가 발생할 가능성이 높다는 것이다.
Push model의 장점은 content가 자주 push 되지 않는 상황에선 system의 Traffic을 낮출 수 있다. 또한 main server가 다운되더라도 CDN에 caching 된 content가 존재하기 때문에 HA를 더욱 수월하게 달성할 수 있다. 단점은 content가 자주 변경되 push가 자주되는 상황에선 CDN에 최신의 데이터를 유지하기위해 더 자주 push해야해서 부담이 될 수 있다.
