요구사항
FE 리액트와 BE 스프링부트로 이루어진 A앱이 있고, A앱이 올라간 운영 서버에서는 웹 서버로 IIS를 쓰고 있다.
모바일/태블릿에서 이용하는 B앱에서 특정 아이콘 클릭시 A앱이 실행되어야 하는데 이 때 외부 프록시 서버(IIS)를 거쳐서 통신을 할 수 있어야 했다.
그 이유는 모바일/태블릿에서는 공중망을 이용해서 A앱으로 접근 시도를 할 수 있는데, 보안상 이를 방지하고자 특정 네트워크에 위치한 프록시 서버를 거쳐야만 유효한 요청이라고 여기고 모바일/태블릿에 응답을 주기로 했다.
각 서버의 url은 다음과 같다고 가정한다.
- 프록시 서버 : https://proxy.com
- A앱의 FE URL : https://aaa.co.kr
B앱에서 아이콘 클릭시 A앱과 통신 과정
아이콘을 클릭시 프록시 서버가 A앱으로 라우팅 하라는 정보는 프록시 서버에게 컨텍스트 패스를 /A_PROD로 설정해서 알려주었다.
클릭시 다음과 같이 요청된다.
https://proxy.com/A_PROD/login프록시 서버 설정에는 applicationHost.config 파일에 룰과 webFarm 설정을 추가했다.
<rule name="WMO_A_REWRITE" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="A_PROD*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="on" />
<add input="{PATH_INFO}" pattern="/A_PROD*" />
</conditions>
<action type="Rewrite" url="http://WMO_A_PROD/{R:1}" />
</rule>
...
<webFarm name="WMO_A_PROD" enabled="true">
<server address="aaa.co.kr" enabled="true" />
</webFarm>url rewrite 설정
WMO_A_REWRITE 라는 이름의 URL 리라이트 규칙을 정의합니다.patternSyntax 속성은 와일드카드를 사용하여 URL 패턴을 매칭하도록 설정합니다.stopProcessing 속성은 이 규칙이 매칭되면 다른 규칙들을 더 이상 처리하지 않도록 설정합니다.match 요소의 url 속성은 매칭할 URL 패턴을 지정합니다. 여기서는 "A_PROD*"와 일치하는 URL을 매칭합니다.conditions 요소는 매칭 조건들을 정의합니다. logicalGrouping 속성은 조건들을 모두 만족해야 한다는 의미이고,trackAllCaptures 속성은 캡처된 값들을 추적하지 않도록 설정합니다.add 요소들은 각각 {HTTPS}와 {PATH_INFO} 변수의 값을 검사하는 조건들을 정의합니다.action 요소의 type 속성은 리라이트 작업의 유형을 지정합니다. 여기서는 리라이트된 URL로 이동하도록 설정하고,{R:1}은 첫 번째 캡처된 그룹의 값을 리라이트된 URL에 추가합니다.
웹 팜 설정
WMO_A_PROD라는 이름의 웹팜을 정의합니다.name 속성은 웹팜의 이름을 지정합니다.enabled 속성은 웹팜을 활성화하도록 설정합니다.server 요소의 address 속성은 웹팜에 속하는 서버의 주소를 지정합니다. 여기서는 "aaa.co.kr" 주소를 가진 서버를 웹팜에 추가합니다.
IIS는 "A_PROD*"와 일치하는 URL을 match url="A_PROD*" 설정에 맞게"http://WMO_A_PROD/{R:1}"로 리라이트하고, "WMO_A_PROD"라는 이름의 웹팜에 속한 서버로 요청을 전달한다.
최종적으로 http://aaa.co.kr/ 로 라우팅 된다.
여기서 들었던 의문점
URL 리라이트 규칙에서 action type의 url이 "http://WMO_A_PROD/{R:1}"로 설정되어 있음에도 불구하고, 실제로는 HTTPS로 라우팅되는 이유가 궁금했다.
그 이유는 아마도 IIS의 다른 설정 또는 HTTPS 리다이렉션 설정 때문일 수 있다.
원인1) HTTPS 리다이렉션 설정
IIS에서 HTTPS 리다이렉션을 설정한 경우, HTTP로 들어오는 요청이 자동으로 HTTPS로 리다이렉션될 수 있다.
이 설정은 IIS의 사이트 또는 애플리케이션의 SSL 설정에서 구성할 수 있다.
원인2) 다른 IIS 설정
다른 IIS 설정이 HTTP 요청을 HTTPS로 리다이렉션하도록 구성되어 있을 수 있다.
예를 들어, IIS의 바인딩 설정에서 HTTPS를 기본 프로토콜로 설정한 경우, HTTP 요청이 자동으로 HTTPS로 리다이렉션 될 수 있다.
실제로 HTTPS로 라우팅되는지 확인하려면 IIS의 SSL 설정, 바인딩 설정, HTTPS 리다이렉션 설정 등을 확인해야 한다.
운영 서버 IIS까지 요청이 들어온 후
A앱이 사이트로 등록된 운영 서버의 IIS에서는 https://aaa.co.kr로 요청이 들어올 경우 사이트 바인딩에 다음과 같이 등록되어있다.
운영 서버에 FE는 80포트로 떠 있고 https 프로토콜 aaa.co.kr 도메인에 기본포트인 443으로 바인딩 되어있다.
즉, https://aaa.co.kr로 IIS에 들어온 요청은 운영 서버 로컬에 떠 있는 80서버로 떠 있는 FE로 요청된다.
FE까지 요청이 들어온 후
FE에서는 width를 보고 모바일/태블릿인지를 판단한다. 특정 width 이내라면 백엔드 요청을 같은 서버에 떠 있는 스프링부트 앱이 아닌 일단 프록시 서버로 보낸다.
https://proxy.com/A_API_PROD/login-api
위와 같이 요청하면 프록시에서는 A_API_PROD 패스를 보고 A앱의 백엔드로 요청을 라우팅한다.
다음은 프록시 서버의 설정이다.
<rule name="WMO_A_SERVER_REWRITE" patternSyntax="Wildcard" stopProcessing="true">
<match url="A_API_PROD/*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="on" />
<add input="{PATH_INFO}" pattern="/A_API_PROD*" />
<add input="{HTTP_HOST}" pattern="proxy.com" />
</conditions>
<action type="Rewrite" url="https://WMO_A_SERVER_PROD/{R:1}" />
</rule>
...
<webFarm name="WMO_A_SERVER_PROD" enabled="true">
<server address="a-api.co.kr" enabled="true">
<applicationRequestRouting httpsPort="8080" />
</server>
</webFarm>rule 부분에 conditions에 add 된 조건들은 HTTPS 프로토콜을 사용하고, 경로가 "/A_API_PROD"로 시작하며, 요청 헤더의 호스트가 "proxy.com"인 경우에만 적용된다.
이를 통해 요청이 다른 서버로 리라이트 되고, HTTPS 프로토콜을 사용하도록 전환될 수 있다.
백엔드 도메인이 a-api.co.kr로 등록된 운영 서버로 들어오게 된다. 포트를 8080으로 명시하였으므로 백엔드가 8080으로 기동되어있을 때 이 요청을 받을 수가 있다.
FE에서 외부 솔루션을 다이렉트로 호출하고 있던 이슈
위와 같이 설정해서 A앱과 프록시 사이의 연동은 잘 되었는데,
FE에서 문서뷰어를 보여주는 외부 솔루션을 다이렉트로 호출하고 있었다. 이 부분이 LTE환경에서 요청시에는 프록시 서버를 거치지 않아서 에러가 나고 있었다.
외부 문서 뷰어 솔루션 요청도 프록시 서버를 거치도록 바꿔야 했다.
외부 솔루션도 위에서 설정했던 프록시 설정들을 동일하게 셋팅했다.
<rule name="WMO_SOLUTION_REWRITE" patternSyntax="Wildcard" stopProcessing="true">
<match url="SOLUTION_PROD*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{PATH_INFO}" pattern="/SOLUTION_PROD*" />
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Rewrite" url="https://WMO_SOLUTION_PROD/{R:1}" />
</rule>
...
<webFarm name="WMO_SOLUTION_PROD" enabled="true">
<server address="solution.co.kr" enabled="true">
<applicationRequestRouting httpsPort="8443" />
</server>
</webFarm>
하지만 통신이 되지 않았다..
다른 선배분께 도움을 구했다.
<serverVariables>
<set name="HTTP_HOST" value="solution.co.kr" />
</serverVariables>이렇게 추가 해보라고 알려주셨다. 원리는 알려주시지 않았는데..
찾아보니 IIS에서 내부적으로 쓰고 있는 서버 변수인 HTTP_HOST에 value를 셋팅하는 설정이였다.
HTTP_HOST는 요청 헤더의 host필드라고 한다. 즉 solution.co.kr로 요청을 보내게 되는 설정이다.
HTTP_HOST변수를 설정할 때는 다음과 같은 상황이 있다고 한다.
1)가상 호스트 설정
IIS에서는 하나의 서버에 여러 개의 웹 사이트를 호스팅할 수 있는데 이 때 각 웹 사이트는 고유한 도메인 또는 호스트 이름을 가질 수 있다.
HTTP_HOST 변수를 설정하여 요청된 도메인 또는 호스트 이름에 따라 서로 다른 웹 사이트로 라우팅할 수 있다.
2)개발 또는 테스트 환경 설정
개발 또는 테스트 환경에서는 실제 도메인이 아닌 가상 도메인 또는 로컬 호스트 이름을 사용할 수 있는데, HTTP_HOST 변수를 설정하여 개발 또는 테스트 서버에서 해당 도메인 또는 호스트 이름으로 요청이 되도록 사용한다.
<configuration>
<system.webServer>
<!-- 기존의 다른 설정들 -->
<serverVariables>
<set name="HTTP_HOST" value="dev-tmspre.lg.co.kr" />
</serverVariables>
</system.webServer>
</configuration>프록시 서버 담당자에게 위와 같이 추가하면 된다고 가이드했는데 조금 더 찾아보니 아마 아래와 같이 추가했을 것으로 예상된다.
<rule name="WMO_SOLUTION_REWRITE" patternSyntax="Wildcard" stopProcessing="true">
<match url="SOLUTION_PROD*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{PATH_INFO}" pattern="/SOLUTION_PROD*" />
<add input="{HTTPS}" pattern="on" />
</conditions>
<serverVariables>
<set name="HTTP_HOST" value="solution.co.kr" />
</serverVariables>
<action type="Rewrite" url="https://WMO_SOLUTION_PROD/{R:1}" />
</rule>이런식으로 추가해서 해당 조건들이 맞을 때 서버 변수를 솔루션 도메인으로 설정했을 것 같다.
'Architecture' 카테고리의 다른 글
| MSA 대두 배경은? (0) | 2020.11.13 |
|---|