애플리케이션 / 클라우드

IIS의 훌륭한 대체 웹 서버, 마이크로소프트 케스트렐

Simon Bisson | InfoWorld 2022.08.29
인터넷 정보 서비스(Internet Information Services, IIS)는 마이크로소프트가 만든 웹 서버 플랫폼 중 가장 오래된 기술이다. 1995년에 처음 출시된 이후 IIS는 윈도우 서버와 더불어 주기적으로 업데이트됐으나, 2018년 11월 마지막 릴리스인 IIS 10 버전 1809 이후에는 별다른 변화를 보이지 않았다. 윈도우 서버 2022는 QUIC 및 TLS 1.3 지원을 추가했지만, 코어 웹 서버 플랫폼은 그대로였다. 
 
ⓒ Getty Images Bank

그러는 동안 마이크로소프트는 최신 동적 웹 애플리케이션에 집중한 두 가지 대안 기술을 .NET의 일부 형태로 조용히 개발했다. 첫 번째인 Http.sys는 윈도우 전용 서버로, 윈도우에 호스팅 된 APS.NET 코어(Core) 애플리케이션을 규모 있는 환경에서 실행하기 좋은 기술이다. 두 번째인 케스트렐(Kestrel)은 ASP.NET 코어 웹 서버이며, 맥OS를 포함한 모든 .NET 코어 플랫폼상에서 실행된다. 케스트렐은 gRPC와 같은 최신 웹 기술을 지원하는 것은 물론 엔진엑스(Nginx)와 같은 로드 밸런서 뒤에서 작동하기 좋게 설계됐다.
 

케스트렐 기본 구조

.NET 웹 애플리케이션을 구축하는 개발자라면 케스트렐에 한번 주목해보자. 케스트렐은 IIS에 비해 비교적 가벼운 서버이고 크로스 플랫폼이기 때문에 호스팅 플랫폼 선택 방식을 단순화한다. 또한 개발 도구로 적당하며, 테스트와 실험용 데스크탑 하드웨어 환경에서도 잘 실행된다. HTTPS, HTTP/2, QUIC의 프리뷰 릴리스가 지원되므로 미래에도 사용 가능하고 안전하게 실행될 수 있다. 
 
서버는 ASP.NET 코어의 일부로 설치된다. IIS에 의해 명확히 호스팅 되지 않는 사이트라면 기본값으로 설정될 것이다. 익숙한 WebApplication.CreateBuilder 메소드를 사용하는 것 이외에, 케스트렐을 실행하기 위해서 어떤 코드도 작성할 필요가 없다. 그만큼 마이크로소프트는 케스트렐이 최소한의 구성으로 작동하도록 설계했다. 보통 닷넷을 새롭게 사용하여 앱 스캐폴딩을 설정할 때나 비주얼 스튜디오에서 새로운 앱을 만들 때 생긴 설정 파일을 사용해서 케스트렐을 실행한다. 
 

케스트렐 구성

웹애플리케이션(WebApplication) 및 웹애플리케이션빌더(WebApplicationBuilder) 안의 API를 사용하면 케스트렐을 구성할 수 있다. 가령 API로 포트를 추가할 수 있다. 케스트렐은 ASP.NET 코어 코드가 실행해야만 비로소 실행되므로 이 방식으로 비교적 손쉽게 서버 구성을 동적으로 만들 수 있다. 모든 변경 사항은 몇 줄의 코드만 필요하다. 이와 마찬가지로, 닷넷 실행 명령어를 활용하거나 앱의 appsettings.json 파일을 편집해, 새로운 엔드포인트 URL을 추가할 수 있다. 또는 ASP.NET 코어 환경 변수를 포트를 관리하는 방향으로 설정할 수 있다. 이런 유연성 덕분에 케스트렐은 놀라울 정도로 관리하기 간단하다. 해당 코드에 가장 적합한 메소드를 선택하기만 하면 된다.

케스트렐을 구성하는 또 다른 방법은 서버 연결과 관련된 IP 주소를 관리하는 것이다. 이때 이용 가능한 모든 인터페이스를 살펴볼 수 있다. HTTPS 작업을 하면서 프로덕션 단계 전에 애플리케이션을 테스트해야 할 경우, 케스트렐은 그 작업을 시작하는 자체 테스트 인증서를 활용한다. 이는 ASP.NET 코어 SDK의 일부로 설치되며 닷넷 명령줄 도구에서 관리할 수 있다. 일단 프로덕션 단계에 진입하면 다양한 구성 도구를 활용해 적절한 인증서를 선택할 수 있다.
 
유닉스(Unix) 소켓이 지원되는 케스트렐은 엔진엑스를 포함한 로드 밸런서 대부분과 호환된다. 따라서 리눅스나 윈도우 컨테이너에서 등 컨테이너에서 사용하기에 이상적이다. 여기서 유닉스 소켓 지원 덕분에 네트워킹 및 보안 기능을 서비스 메시를 통해 코드에 추가할 수 있다.
 

서버 사용자화

웹 서버 구성을 프로그래밍 방식으로 조절하는 구조는 언제나 여러 이점을 준다. 대표적으로 필요에 따라 기능을 추가할 수 있다. 예를 들면, 생산 서버는 최소한의 로깅으로 실행될 수 있다. 문제가 발생하면 작동 관련 상세 내용을 확보하기 위해 대체 로깅 제공자를 추가하도록 빠르게 케스트렐을 구성할 수 있다. 혹은 대체 서비스에 대한 지원을 추가해볼 수 있다. 예를 들면 파일 시스템에서 정지 컨텐츠를 제공하는 식이다.
 
ASP.NET 코어에는 지원 서비스에 대한 선택지가 많다. 따라서, 최소한의 기본 API 구성을 넘어 확장을 할 수 있다. 예를 들면 세션 관리 도구나 반응 캐싱을 추가할 수 있다. 명심할 점은 새로운 서비스를 추가하면 할수록, 더 많은 API가 서버에 추가되므로 공격 표면이 확장된다는 점이다. 따라서 사용할 것이 확실하면서도 보안 플랫폼으로 보호될 것이 확실한 기능만 추가해야 한다.
 
케스트렐은 맞춤화하기 좋은 기술이다. 브라우저에서 오는 요청을 지원하는 HTTP 메소드의 관리는 물론 서버가 특정 URI 구조에 반응하는 방식의 관리도 가능하다. 여기서는 람다와 같은 .NET의 기본 요소를 활용해 데이터를 분석한 후 해당 애플리케이션에서 적용해볼 수 있다. 이런 경우 기능은 서버로 넘어가 코드의 복잡성이 줄어들며, URI 인코딩을 사용해 애플리케이션에 대한 상태를 다루기가 수월 해진다. 이런 경우 URI에서 매개변수를 캡처할 때는 라우터를 사용한다. 케스트렐과 ASP.NET은 단일 페이지 웹 애플리케이션을 구축하고 실행할 수 있으며, URI 구조를 사용하여 사용자에게 제공되는 컨텐츠를 결정한다.
 
마이크로소프트는 ASP.NET 애플리케이션에 사용되던 IIS를 대체할만한 유연하고 강력한 웹 서버케스트렐을 만들어냈다. 케스트렐은 웹 서버 구축에 필요한 코드가 거의 없으면서도, 최소한의 API 방식을 활용해 ASP.NET 코어 기능과 함께 정적 컨텐츠를 제공하기 위한 경로와 매개변수를 사용한다. 그리고 ASP.NET 기능 이야말로 클라우드 네이티브 컨테이너에서 확장할 수 있는 최신 애플리케이션을 구축하는 데 꼭 필요한 기술이다.
 

마이크로소프트에서도 활용하는 케스트렐

마이크로소프트가 자체 개발한 도구를 실제 서비스에 어떻게 활용하고 있는지 지켜보는 일은 흥미롭다. 케스트렐은 오픈소스 .NET 리버스 프록시인 YARP와 함께 애저 앱 서비스(Azure App Services)에서 핵심 웹 플랫폼으로 도입됐다. 애저 팀은 블로그에서 그 과정을 상세히 소개하기도 했다. 
 
애저 앱 서비스는 엄청나게 확장 가능한 멀티테넌트 플랫폼이 되어야 한다는 요구가 있지만, 마이크로소프트가 진행한 마이그레이션 과정을 보면, 케스트렐은 어떤 기술에서든 활용할 수 있다는 점을 확인할 수 있다. 빙, 애저 액티브 디렉토리(Azure Active Directory), 다이나믹스(Dynamics) 365 등이 이미 케스트렐을 사용 중이다. 
 
애저 앱 서비스의 규모는 하이퍼스케일 서비스 치고도 방대하다. 현재 하루에 1,600억 건이 넘는 HTTP 요청을 지원하며 1,400만 개가 넘는 도메인 이름을 호스팅한다. 아키텍처의 기반은 전형적인 클라우드 서비스의 모습을 갖추었다. 로드 밸런서 뒤에 플랫폼이 있고 앱 서비스 코드가 작업자 상에서 실행되며 웹 서버를 통해 제공된다. 전세계적으로 이는 20만 개 이상의 코어가 웹 서버를 실행한다는 의미다.
 
업데이트 전에 애저 앱 서비스는 IIS와 HTTP.sys 상에서 실행되고 있었다. 케스트렐과 YARP을 도입하면서, 마이크로소프트는 사용자들에게 보다 광범위하게 HTTP 프로토콜을 제공하고, 보안 연결 옵션을 강화하며, 동시에 개발자들이 스스로 선택한 앱 플랫폼을 사용하게끔 도와주고 있다. 
 
물론 REST 및 gPRC API 클라이언트와 연결된 전통적인 브라우저와 프론트엔드 서비스를 마이그레이션하는 과정에서 케스트렐은 몇몇 문제를 보였다. 하지만 해당 문제는 수정되어 케스트렐은 사용자와 화면과 밀접히 연결된 애플리케이션용으로 더욱 적합해졌다. 가장 흥미로운 변화는 케스트렐의 동작이 덜 엄격한 방식으로 가고 있다는 사실이다. 처음에 케스트렐은 HTTP 사양에 맞게 작성돼 주요 개행 문자가 포함된 요청을 거부했다. 하지만 케스트렐 팀은 규정준수 요건을 완화했고, 최신 릴리스는 해당 종류의 요청을 받아들이고 있다. 
 
애저에서 케스트렐을 비롯한 새로운 플랫폼이 도입되면서 흥미로운 벤치마크가 나오기도 했다. 일반적인 HTTP 요청에 대해 처리량이 80% 가까이 늘어났는데, 그 결과 프론트엔드 서비스 호스트 전체에 걸쳐 CPU 사용이 크게 줄어들었다. 애저 팀은 결국 사용하는 코어 수를 줄여 비용과 데이터 센터 자원을 모두 줄이기를 기대하며 성능을 계속 모니터링하고 있다.
 
케스트렐은 크로스 플랫폼이므로 똑같은 코드를 이용해 리눅스 워크로드까지 지원할 수 있다. 따라서 애저에서 엔진엑스 서버를 제거할 수도 있다. 리눅스와 윈도우용으로 똑같은 인프라가 있으면 관리 비용이 줄어든다. 서비스에 대한 공통의 코드베이스와 공통의 기능이 있기 때문이다. 케스트렐과 YARP가 업데이트되면서 앞으로 특정 OS 환경이 아닌 앞으로 모든 애저 앱 서비스 사용자들이 새로운 기능을 이용할 수 있다.
 
케스트렐과 YARP가 애저 앱 서비스에 제공되면서, 그 혜택은 케스트렐을 사용하는 모든 사람에게 돌아갈 것이다. 가장 많은 사용자를 보유한 애저 플랫폼 핵심이 변화하면서 과거 디버깅하지 않으면 ASP.NET 코어에서 보이지 않았던 엣지 사례를 빠르게 확인할 수 있을 것으로 보인다.

다시 말해 케스트렐과 ASP.NET 코어 모두에게 도움이 되는 전략이다. 따라서 오래된 IIS를 사용하는 대신 케스트렐을 한번 고려해보자. 케스트렐은 구성과 관리가 더욱 쉬운 웹 서버이면서 인기 서버 플랫폼이나 컨테이너에서 잘 실행되는 기술이다. 규모 있는 환경에서도 보안과 단순함 두 가지를 모두 안겨줄 것이다.  
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.