현 시대에서 그 누구도 직간접적으로 네트워크를 사용하지 않은 사람은 없을 것이다.
따라서 사용자가 많아질수록 서버의 부담은 당연히 커졌고 선택할 수 밖에 없었다.
서버 자체의 스펙을 높이던가(Scale-Up), 서버의 갯수를 늘리던가(Scale-Out).
보통 컴퓨터의 장비가 최신에 가까울수록 업그레이드 비용이 수직 상승하기 때문에
대체로 비용적, 효율적 측면을 모두 비교해도 서버의 갯수를 늘리는것이 일반적이다.
그렇다면 무조건 서버의 갯수를 늘리는것이 능사는 아니다.
DB같은 경우 여러대의 서버를 동시에 돌리게 되면 write없이 read만 일어나는
사이트의 경우 문제가 없을 수 있지만 Table의 Data를 변경, 입력하게 되면
모든 DB서버가 동시에 같은 Data상태를 유지해야하기 때문에 이를 해결하는것이 굉장히 까다로워진다. 물론 구현이 불가능한것은 아니다!
그래서 DB는 Scale-Up이 간단하면서도 어느정도 규모에서는 맞는 선택지이기도 하다.
이외에도 DB측면에서는 위와같은 해결방법들이 많으니 나중에 자세히 더 봐야겠다.
서버의 갯수만 단순히 증가시키면, 서버마다 IP가 다르기 때문에 사용자가 직접 사용할 서버의 IP를 입력하고 들어와야한다. 이 말은 부하분산이 제대로 될지 보장도 안될 뿐더러 서버 증설을 한 이유가 사라진다.
서버의 트래픽을 확인해 적재적소에 요청을 넣게 해주게끔 하는것이 바로
Load balancer가 하는 일이다.
L2 - Data link 계층을 사용, Mac주소 기반 부하 분산
L3 - Network 계층을 사용, IP주소 기반 부하 분산
L4 - Transport 계층을 사용, Port 기반 부하 분산
L7 - Application 계층을 사용, 요청(URL) 기반 부하 분산
OSI7계층에따라서 계층마다 부하를 분산하는 방식이 다르고, 상위 계층일수록 섬세한 분산이 가능하다. 위의 계층에서 가장 많이 사용되는 계층이 L4, L7이다.
검색했을 때 가장 많이보이는 위의 표가 정리가 잘 되어 있어서 한 번 읽어보면 대략적인
차이점을 파악하는데는 문제가 없을것이다!
Network Address Translation(NAT)
사설 IP를 공인 IP로 변경
Tunneling
데이터를 캡슐화하여 연결되어진 노드만
그 데이터의 캡슐을 풀어서 볼수있게 해준다
Dynamic Source Routing protocol(DSR)
요청에 대한 응답을 할 때 로드밸런서가 아닌 클라이언트의 IP로 응답
Load balacer가 장애가 발생하면 당연히 서버에 연결되지 않는 사태가 발생한다.
그래서 Load balacer 역시 이중화를 해주는 것이 좋다.
이중화를 하게되면 두 개의 Load balancer가 서로 살아있는지 확인하는
Health Check를 진행한다.
Main으로 쓰던 Load balancer가 다운되면 살아있던 여분의 Load balancer가
일을 수행하게 되며 정상적인 운영이 가능하도록 해준다.
참고
https://medium.com/harrythegreat/aws-로드밸런싱-알아보기-9fd0955f859e
https://nesoy.github.io/articles/2018-06/Load-Balancer