왜 필요한가?
scale up???
흔히, scale out이라는 편리한 방법 때문에 대부분의 구성도에서는 고려를 할 필요가 없지만, 특정 소프트웨어에서는 고려가 되어야 할 필요가 있다. tibco 같이 cpu에 라이선스가 걸려 있거나 라이선스 특성상 scale up만 되는... 아 미치겠다...
모든 cloud 플랫폼에서 어렵나?
aws에서는 위 구성이 어렵지 않다.
같은 서버에 여러 포트로 부하분산 하는것은, 아래와 같이 그냥 nlb에서 설정해주면 된다.
그럼 Azure에서는?
Azure에서는 문제다.
아래와 같이 rule을 생성할 때, 이미 backend pool은 따로 만들어져있고, backend port를 backend pool 집합 전체에 적용해 버린다.
대환장 파티
어떻게 해결할까?
NVA를 쓰는 방향과 안쓰는 방향으로 볼 수 있을것 같다.
NVA를 쓰는 방향
여기서 예제로 들고온 NVA는 Palo Alto 차사대 방화벽이다.
Palo Alto 에서는 뒤쪽으로 Ip 기반 부하분산을 지원해준다.
아래의 스크린샷과 같이, Translated Address 에 원하는 IP 그룹을 넣어줄 수 있다.
그리고 아래와 같이, 부하분산 method를 선택하여 분산 시킬 수 있다. port를 분산 못시키는게 아쉽다.
NVA를 쓰지 않는 방향
위의 그림에서 조금 더 자세하게 표현하자면 아래와 같은 아키텍처를 가져갈 수 있다.
위와 같이 머신이 scale up 또는 out을 할 때, 필요한 작업이 있다.
Scale up
- LB에 frontend ip 새로 추가하기
- 새로운 frontend ip를 이용하여 AGW가 보내주는 port to 새롭게 사용할 포트를 룰로 설정하기
- AGW에서 새로운 frontend ip를 backend pool에 추가하기
Scale out
- LB의 backend pool에 새로운 VM 추가하기
위의 AGW와 LB의 맛보기 설정은 아래와 같다.
AGW의 path based 로 각각 1001, 1002, 1003 등으로 보내주기 위해 각각의 backend pool을 구성하였다.
같은 LB 리소스로 가지만, frontend ip와 포트의 조합이 다르게 넘어간다.
LB의 설정은 frontend ip를 추가하는 부분과 LB rule에서 각각 같은 backend pool로 보내지만 다른 port로 보내는 부분이 중요하다.
위와 같이 진행하면, aws에서 손쉽게 같은 VM 대상으로 다른 port를 이용한 backend pool 구성을 할 수 있다. 첨부터 그냥 지원이 되면 좋지만 이 글을 작성하는 날 기준으로는 지원되지 않는다. 그리고 지금 이 부분을 써야해서 기록해둔다.
마치며
Scale out이 대세라서 이런 scale up을 통한 여러 포트를 사용하는 방법은 크게 고려될 필요는 없다.
하지만 운이 없게 회사에서 특정한 소프트웨어를 쓰며 해당 라이선스 또는 개발자가 위와 같이 머신에 JVM만 추가해서 사용하는 방법을 사용하길 원한다면 한번쯤은 고려해볼만한 방법이다.
특히 Kubernetes가 나오고, 위와 같은 부분들을 service가 알아서 다 묶어주기도 하며 hpa 자체가 너무 쉽고 편하기에... 위의 방법을 다시 쓸지는 모르겠다.
