마이크로소프트 익스체인지 서버(Microsoft Exchange Server) 기반의 이메일 및 그룹웨어를 사용하는 기업이 많습니다. 클라우드가 아무리 대세라 하지만 보안 이유로 온프레미스 환경에서 이메일 서비스를 제공하는 기업이 여전히 많습니다.
관련해 이번 포스팅에서는 익스체인지 서버 2016 환경을 대상으로 한 로드밸런싱에 대해 간단히 살펴 보겠습니다. 참고로 익스체인지 서버 2016을 기준으로 살펴보겠습니다.
익스체인지 서버의 경우 2013 버전이 나왔을 때 시스템 측면의 고가용성과 네트워크 측면의 복원력을 보장하는 기능이 강화되었습니다. 여기에 하드웨어 기반 로드밸런서를 쓰면 막강한 아키텍처가 완성됩니다.
익스체인지 서버 2016과 2019의 경우 메일 박스 서버와 클라이언트 서버 롤(role)을 구분해 고가용성과 성능을 보장하기 위한 구성을 더 유연하게 할 수 있습니다. 이 방식의 배포는 2013버전부터 지원되었는데요, 버전이 올라갈수록 더욱 정교해지고 있습니다.
서버와 클라이언트의 연결 역시 2013 버전부터 HTTP가 공식적으로 지원되면서 한결 간소화되었습니다. 2007, 2010만 해도 RPC over HTTP, MAPI over HTTP 등을 써서 아웃룩과 서버가 연결되었습니다.
익스체인지 서버 2016과 2019에서는 서버 롤을 맡는 시스템 수를 줄여 하드웨어 요구 사항과 인프라 구성의 복잡성을 낮출 수 있습니다. 이게 가능한 것은 메일 박스 서버와 엣지 트랜스포트로 서버 롤을 세분화할 수 있기 때문입니다. 이렇게 구성할 때 펌킨네트웍스 AEN 시리즈 같은 하드웨어 로드밸런서를 다음과 같이 엣지 트랜스포트 서버와 클라이언트 사이에 위치할 수 있습니다.
조직이 큰 경우 메일 박스 서버 대수가 많습니다. 이런 경우 DAG(Database Availability Group)을 구성하는데요, 이렇게 하는 이유는 더 작은 서버 대수로 고가용성을 보장하기 위함입니다.
여기서 한 가지 눈에 띄는 부분이 있죠. 네, 클라이언트가 메일 박스 서버가 아니라 로드밸런서로 연결되는 것입니다.
하드웨어 기반 로드밸런서를 쓰는 이유는 DAG 구성이 마이크로소프트 클러스터 서비스를 사용하기 때문입니다. 윈도우 NLB(Network Load Balancing) 기능은 DGA 환경에서 선택 가능한 옵션이 아닙니다.
참고로 익스체인지 서버 환경에서 로드밸런싱은 DNS 라운드로빈 방식을 통해 메시지 트래픽이 처리되는 간단한 방식이 선호됩니다. L4가 아니라 L7 기반 로드밸런싱이 쓰이기도 하는데요, 환경과 조건에 따라 각각의 장단점이 있으므로 신중하게 선택해야 합니다.
