먼저 간단하게 이 패턴을 설명하자면, 시스템 모던화와 같은 서비스 차질이 발생할 수 있는 작업 진행시, 서비스 앞에 파사드 레이어와 같은 특정 레이어를 생성하여 서비스를 차질없이 제공 해주는 패턴이라고 짧게 설명 할 수 있다.
위의 예제인 시스템 모던화인 경우에는 아래와 같은 고려사항들이 나올 수 있다.
위의 고려사항 보다 더 많은 포인트들이 있겠지만, 이러한 고려사항들을 만족 시키기 위해 사용하는 패턴이 Anti-corruption Layer pattern이다.
그렇다면 어떻게 이 특정 레이어가 위와 같은 고려사항들을 만족시킬 수 있을까?
아래와 같은 기존 시스템이 있다고 가정해보자.
뭐 internal only 일수도 있고 external로 서비스 하는 것일 수도 있다. vm들 또한 n-tier도 될 수 있다. 중요한 것은 그냥 일반적인 vm기반으로 설계 되고 개발된 시스템 이라는 부분이다.
전통적인 vm 기반으로 여러가지 서비스들이 vm위에 떠있고 해당 vm을 scale out하는 구조로 보면된다.
위와 같은 아키텍처를 microservices로 모던화 한다고 할 때, 아래와 같이 kubernetes를 이용하며 여러 db를 사용하고 bigdata를 위한 databricks를 활용하는 to-be 아키텍처는 아래와 같다고 가정해보자.
모든 테스트를 완벽하게 하고 기존 서비스에서 신규 kubernetes 기반 서비스로, 어느 시점을 기준으로 dns를 바꾸면 되겠지만, 완벽한 테스트는 없다. 문제는 항상 발생한다. 그리고 완벽한 마이그레이션 또한 없다. 이전 db를 조회해야 할 일도 많이 생기고 복잡성이 너무 높아 마이그레이션에 너무 오랜 시간이 걸려 오픈시간에 맞추지 못하는 서비스 또한 있을 것이다.
위와 같은 상황에서 Azure의 어떤 서비스를 사용하여, Anti-corruption Layer를 적용할 수 있을까?
쉽고 편하게 적용하는 것을 찾는다면 나는 크게 3가지 서비스를 추천하고 싶다.
3 가지 서비스 모두 internal external 모두에 적용할 수 있으며, 받은 트래픽을 뒤쪽으로 라우팅 시킬 수 있는 역할을 할 수 있다. 즉, 위의 구성도와 같이 wonchul123.com/image는 기존 legacy로 보내고 나머지 wonchul123.com 과 wonchul123.com/login은 to-be로 보내는 것 또한 가능하다.
kubernetes와 legacy에 있는 postgresql 또한 servie endpoint 또는 private endpoint를 사용하여 얼마든지 접근이 가능하다.
Anti-corruption layer에서 1차적으로 한번 path에 따른 라우팅을 할 수 있기에 위와 같이 사용가능하다.
물론 internal traffic이라면 비용이 조금 많이 나온다. vnet integration 비용이 너무하다구요!!
그럼 vnet integration 비용이 너무 부담된다면 어떤 선택지가 있을까?
위와 같이 첫번재 트래픽을 바로 kubernetes가 받는 것이다. 예를 들면 istio 같은 흔히들 사용하는 툴들을 쓴다면 canary 기능 까지 사용할 수 있는 장점이 있다.
aks는 istio를 무려 built in으로 제공한다. (작성일 기준 preview!!)
ms docs!!
위와 같이 kubernetes의 istio 또는 nginx ingress 같은 아이들이 바로 받는다면 비용적으로 부담을 훨씬 덜 수도 있다.
서비스 모던화, 마이그레이션 등과 같은 작업을 할 때는 꼭 Anti-corruption Layer pattern 고려하자!!
aks는 istio를 무려 built in으로 제공하는게 너무 부럽습니다.