Gateway Offloading pattern

- 출처: https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-offloading

Gateway Offloading pattern - Azure Architecture Center

 

- 개요

공유되거나 특화된 서비스 기능을 게이트웨이 프록시로 전가하라. 이 패턴은 SSL certificates 과 같이 공유된 서비스 기능을 게이트웨이로 옮김으로써 어플리케이션 개발을 손쉽게 해준다.

 

- 문제상황

특정 기능들은 여러 서비스들에서 공통적으로 사용되며 이런 기능들은 설정, 관리, 유지보수가 필요하다. 모든 어플리케이션 배포시 함께 배포되는 공유되거나 특화된 서비스는 관리 부담을 증가시키고 배포 오류의 가능성을 높인다. 공유된 기능에 대해 갱신이 발생할때마다 해당 기능을 공유하는 모든 서비스에 걸쳐 배포되야 한다.

 

보안 이슈를 다루거나 다른 복잡한 작업을 적절히 처리하려면 팀 구성원이 고도로 전문화된 기술을 갖추어야할 수 있다. 예를 들어 어플리케이션에서 요구되는 인증서는 반드시 모든 어플리케이션 인스턴스에 설정 및 배포되어야 한다. 새로운 배포마다 인증서는 만료되지 않도록 관리되어야 한다. 이렇게 만료가 있는 일반적인 인증서는 반드시 매 어플리케이션 배포마다 갱신, 확인, 검증이 필요하다.

 

인증, 인가, 로깅, 모니터링, 쓰로틀링과 같은 일반적인 다른 서비스들은 배포의 규모가 커지면 관리되거나 구현이 어려울 수 있다. 이런 유형의 기능을 통합하는것이 오버헤드와 오류 발생 가능성을 줄이는데 더 나을 수 있다.

 

- 해결책

인증서관리, 인증, 인가, SSL 종료, 모니터링, 프로토콜 변환, 쓰로틀링과 같은 관심사에 해당하는 기능들을 게이트웨이로 전가해야 한다. 아래 다이어그램은 인입 SSL 연결을 종료하는 게이트웨이를 보여준다. 이는 게이트웨이 업스트림에 있는 HTTP 서버로부터 원래 요청자를 대신하여 데이터를 요청한다.

 

이패턴을 사용하면 아래와 같은 이점이 있다.

• 예를 들어 웹서버 인증서, 설정, 보안과 같은 배포 및 유지보수의 필요성을 제거하여 서비스 개발을 간략화할 수 있다. 간단한 설정은 쉬운 관리 및 확장을 가능하게 하며, 서비스 업그레이트를 더 간단하게 한다.
• 특정 전담팀이 보안같은 전문성이 필요한 기능을 구현할 수 있다. 이렇게 되면 팀은 어플리케이션 기능 구현에만 집중할 수 있다.
• 요청 및 응답 로깅과 모니터링을 일관성을 있게 제공할 수 있다. 서비스가 올바르게 계측되지 않았더라도 게이트웨이를 구성하여 최소한의 모니터링과 로깅 수준을 보증해준다.

- 이슈 및 고려사항

• 게이트웨이의 고 가용성과 실패에 대한 복원력을 보증해줘야한다. 게이트웨이를 복수개 이상의 인스턴스로 구성하여 단일 장애점(SPOF)을 회피해야 한다.
• 게이트웨이가 어플리케이션과 앤드포인트의 용량 및 확장 요구사항에 맞게 설계되었는지 확인해야 한다. 게이트웨이가 어플리케이션의 병목지점이 되지 않도록 충분한 확장성을 지녀야 한다.
• 보안과 데이터 전송 같이 전체 어플리케이션에서 사용되는 기능들만 전가 해야 한다.
• 비즈니스 로직은 절대로 게이트웨이로 전가해선 안된다.
• 만약 트랜잭션을 추적해야 한다면 로깅 목적의 연관된 ID를 생성하는것을 고려해야 한다.