이전 전 / 중 / 후의 네트워크 설계 #
이전 전의 네트워크 구성 #
위 그림은 이전 전 즉, 도커 스웜 위주의 네트워크 구성도다.
트래픽을 최상위의 로드밸런서에서 받은 뒤 아파치(혹은 엔진엑스, OpenResty 등)와 같은 L7 로드밸런서에 전달한 후 도커 스웜의 클러스터에 도달한다. 이어서 컨테이너 네트워크에 접속 되고 최종적으로 웹 애플리케이션이 응답을 반환하게 된다.
이전 중의 네트워크 구성 #
위 그림은 도커 스웜에서 쿠버네티스로 이전하는 과정 중 활용한 네트워크 구성이다.
기본적인 이전 방법으로 클러스터 외의 로드밸런스로 부터 신/구버전 환경을 PATH로 지정하고 나누어 단계적 이전을 수행한다.
여기에서 아파치를 해당 핸들러 역할로 선택한 이유는 후술 한다.
이전 후의 네트워크 구성 #
쿠버네티스 위주의 네트워크 구성은 위 그림과 같다. 아파치에 의한 로드밸런스는 이전 전 즉, 도커 스웜과 같지만 모든 애플리케이션은 한번은 이스티오(istio)의 인그레스 게이트웨이를 경유한다.
또, Rate Limit 등 엔진엑스로 수행하던 시스템의 방위 처리는 쿠버네티스 클러스터 전체에 대한 Global Rate Limit과 Pod 단위의 Local Rate Limit으로 기능을 분할했다. 이와 관련한 자세한 내용은 별도 장에서 소개하니 참고한다.
아파치를 이전 시의 로드밸런서로 선택한 이유 #
- 아파치라는 L7 로드밸런서는 요청과 응답에 관련된 복잡한 헤더 처리 등을 이미 갖고 있어 단기간에 다른 시스템으로 이전하는 것은 어려울 것으로 예상했다.
- 아파치 외의 Down Stream 쪽에 있는 로드밸런서는 팀 권한으로 조작할 수 없기 때문에 어떠한 설정 변경에 시간이 오래 소요 될 것으로 예상했다.
- 아파치 외의 다른 수단(엔진엑스, HAProxy 등)을 고려하기 이전에 직접 쿠버네티스 클러스터로 트래픽을 받았을 경우에 쿠버네티스 자체나 이스티오 인그레스 게이트웨이가 트래픽의 부하에 견딜 수 있을지 신뢰할 수 있는 부하 시험의 결과가 존재하지 않았기 때문에 구환경으로 되돌려야 할 가능성이 높다고 판단했다.
즉, 운용 실적과 오퍼레이션의 용이성을 미루어 볼 때 아파치로 이전하는 것이 이전 간 취할 수 있는 선택 사항으로 부터 자유롭다고 판단했다.
※ 결과는 말 할 것도 없이 작성한 대로 예상한 일정대로 이전을 완료하고 있다.