Legacy 환경에서의 기본 L4구성 방식에 대해서 간단하게 포스팅하려고 한다. 최근 L4의 입지가 많이 줄고 있다고 포스팅을 했었지만 그래도 아직은 없어지기에 너무 이른 장비이니 애정을 갖고 포스팅을 하려고 한다.

흔히 네트워크 인프라를 구축한다고하면 다뤄지는 아키텍처가 있다. 유명하신 클라우드 사이트(AWS)나 호스팅 업체에 들어가보면 디테일하지는 않지만 나름 네트워크를 아는 사람이라면 아키텍처를 알 수 있을 정도의 구성을 보여주고 있다.

나는 오늘 여기서 그 아키텍처를 전부 설명하려는 것은 아니고..L4 장비의 배치에 대해서 얘기해보려고 한다.(필자는 LoadBalancer라는 말이 길기도하고 입에 잘 안붙기 때문에 앞으로 L4라고 쓰겠다.) L4는 보통 SLB로 사용되는데, 여기서 S는 서버(Server)를 뜻한다. 아무래도 트래픽의 종단은 Service가 올라가있는 서버이기 때문에 네트워크가 존재하는 이유는 서버로 패킷이 잘 갈 수 있게, 그리고 가용성 있게 갈 수 있게끔 해주는 것이다.

SLB를 위해 L4는 보통 L3장비 근처에 연결이 된다. 사실 이 부분을 이해하기 위해서는 L4의 구동원리에 대해서 알아야 하는데 그 부분을 먼저 포스팅 했어야 했는데, 체계적으로 운영되는 사이트가 아니다보니 생각을 못했다…;
빠른 시일내에 포스팅하도록 하겠다.

SLB구성 방식은 크게 2개로 나눠서 볼 수 있다. ‘In-Line 방식’과 ‘One-Arm 방식’이 있다. 구성을 어떻게 할지는 어떤 서비스가 올라오는지, 그리고 어떤 방식으로 구동이 되어야 하는지에 대한 Application의 이해가 충분히 된 후에 설계가 되어야한다.(사실은 그렇게 될 일이 별로 없는게 사실이지만..) 설명은 내가 열심히 PPT로 그려온 그림을 보면서 설명하도록 하겠다. 그 편이 이해하기 편하다.

In-Line Architecture-1

막 그려온 것 치고는 나름 예쁘다고 생각된다^^(그리고 이번 포스트 이후로는 저렇게 내가 그린거라고 이름도 써놓을 예정이다. 그림도 무료 라이센스인걸로 가져오는 것이니 걱정하지 마시길!) 위의 그림이 In-Line 방식이다. 말그대로 한줄로 쭉 내려오기 때문에 이름도 저렇게 붙은 것이다. ++추가적으로 얘기하자면 In-Line 방식은 Bridge 방식과 Two-Arm 방식으로 구분이 된다. 간단하게 설명하자면 L4를 기준으로 상하단의 네트워크 구분여부인데, 이 부분은 설명이 길어지기 때문에 추가 포스트로 설명을 하도록 하겠다.

In-Line Architecture-2

사실 In-Line 구성 방식은 위 그림과 같이도 설계가 가능하다. 왜냐하면 일반적으로 OSI Level이 높은 장비는 그 하위의 기능을 모두 할 수 있기 때문이다.(아닌 경우도 있으니 참고!) 보통의 L4장비는 라우팅도 가능하다. 적어도 내가 본 장비 중 라우팅 기능이 없던건 본 적이 없다.

In-Line 구성방식의 장단점에 대해 One-Arm방식과 비교하여 간단하게 설명하자면, (1) 구성이 간편해지고 (2) L3장비의 부하가 적어진다는 장점이 있다. 하지만 (1) 1라인으로 구성되어 있기 때문에 장비에 문제가 발생하였을 때 Service Impact를 고려안할 수가 없고 (2) L4가 처리하지 않아도 될 트래픽을 처리해야 하는 경우도 생기며 (3) 추가적인 기능 설정에 제약이 있다.(하지만 이런 제약들에 대해서는 요즘 장비들은 논리적으로 기능구현이 되어있어 해결이 가능하긴 하다)

그럼 One-Arm 구성에 대해서 간단하게 보도록 하자.

One-Arm Architecture

위 그림이 One-Arm 방식이다. 팔이 하나 생긴 형태라고 해서…음음. 그렇다. 이럴 경우에는 외부(인터넷)에서 서버로 트래픽이 들어온다고 했을 때, ‘인터넷 > L3 > L4 > L3 > L2 > Server’라는 경로로 통신이 되게 된다. 딱 봐도 L3가 좋아야 할 것 같은 느낌이 들지 않는가? 사실 어마무시한 트래픽만 아니면 괜찮다..;(그래도 In-Line보다는 2배니..)

이 방식의 장단점을 소개해보면, (1) 모든 트래픽이 L4를 통과하지 않을 거라는 설계하에 L4에 가중되는 부하가 줄어들 수 있고, (2) 확장이 용이하다. 하지만 (1) 모든 트래픽에 대한 제어가 힘들며, (2) 문제가 발생하였을 때 여러 기능들을 사용하고 있을 경우(ex: DSR(Direct Server Return)) 대응이 어렵다.

글은 길지만 사실 요약해보면 별 내용이 없긴하다..내가 얘기하고 싶은건 2문단 정도로 요약이 되어 있는 것 같은데, 차후 좀 더 상세하게 다뤄보도록 하겠다. L4장비를 다뤄본 사람의 입장에서의 생각은 L4장비는 L4에 맞게 사용하는게 맞다는 생각이다. 여러 기능들이 올라가 있어서 원가절감 차원에서 L4로 다양한 기능들을 수행한다. 하지만 그랬을 경우 발생하는 문제가 심각하기 때문에..부가 기능들을 사용할 땐, 영업이 아닌 엔지니어와 심도있는 대화를 나누고 Reference를 참고하여 도입할 수 있도록 하는게 좋겠다.