[ DevOps ] - AWS 기반 소규모 & 중규모 아키텍트 설계 - 로드밸런서 (L4, L7)의 동작원리와 AWS ELB

로드 밸런싱

만약 앱의 client가 늘어나게 되고, 서버가 하나라고 한다면, 서버는 이를 감당하지 못할 수도 있습니다. 이를 해결하기 위해서는 앞에서도 말했지만, 서버를 여러개로 늘릴 수 있습니다. 이러한 방식의 문제는 서버가 필요로 하는 용량이 너무 커졌을 떄, 이를 기술적으로 해결하기가 어렵다는 것입니다. 그리고 비용문제가 있을 수도 있습니다. traffic이 늘어나면 이에 대한 비용이 기하 급수적으로 늘어나기 때문에 비용 측면에서는 좋지 않습니다.

 

그래서 저희는 이러한 해결방안을 생각할 수 있습니다. 같은 성능의 서버를 여러개 만들고, 이에 대해 트래픽을 나누어 줄 수 잇는 어떠한 것을 활용하면 되겠다 라고요. 이를 위한 것이 AWS의 Elastic Load Balancer(ELB)입니다. 

 

이 LB에도 종류가 크기 2개가 있습니다. (L4, L7) L4는 CLB즉 Class Load Balancer라고 합니다. 

 

여기 OSI 7계층이 있습니다. L4는 이름에서 유추할 수 있겠지만 4계층인 전송계층에서 사용됩니다. 즉 이는 무슨말이냐면 어떠한 패킷의 데이터는 보지 않고 Ip와 Port만 보고 이를 적절히 가야할 곳을 지정해 준다는 것입니다.

 

이의 장점은 빠릅니다. 왜냐하면 데이터를 보지않고 트래픽이 어디서 왔는지 그 위치만을 보기 때문입니다. 그냥 리다이렉팅한다고 보면 됩니다. 그리고 단순합니다. 방향만 바꾸어 주는 것이기 때문이죠

 

하지만 이는 Microservice에 불리합니다. 만약 우리가 만든 order, boss, delivery앱이 3개가 있었잖아요. 이걸 Microservice로 구현했다고 하면, order따로, boss따로, delivery따로 구현한겁니다. 당연히 이에따른 서버도 따로 구축한 것이겠죠. 서버가 따로 있으니까. 만약 /order로 사용자가 가고 싶다 했는데, L4는 이걸 하지 못합니다. 왜냐면 이는 데이터 값을 보지 않기 때문이죠.

 

또한 L7 LB는 이름에서 유추할 수 있듯이. L7에서 돌아가는 것을 말한다. 만약에 /order를 요청하면 이는 이 안의 데이터를 확인하고 트레픽을 서버로 보낸다는 것입니다. 하지만 이렇게 데이터를 뜯어봐야 하므로 속도 이슈와 비용 이슈가 발생하게 됩니다. 즉 이는 MicroService에 유리합니다. 그리하여 실습에서는 L7로드벨런서를 사용하도록 하겠습니다.