ASP.NET을 웹 서버 없이 프레임워크 기능만 사용하는분 계실까요?

안녕하세요, ASP.NET을 사용하는 미천한 개발자입니다.

다름이 아니라 현재 회사에서 L7 레이어에서 독자적으로 개발한 네트워킹 프로토콜 인프라와 해당 네트워킹 프로토콜을 지원하는 서비스를 개발하기 위한 프레임워크(C++ 베이스)가 있는데 이제 모던 언어로 넘어가야 하는 포인트에 마주치게 되었습니다.

L4 (TCP 기반)를 이용한 L7 레이어를 독자 개발하여 (HTTP 스펙과 유사한) 자체 라우팅 시스템 인프라를 갖추고 서비스가 돌아가고 있는데요.

이러한 네트워크 인프라 시스템에서 동작하는 서비스 어플리케이션을 C++로 개발 및 유지보수를 하는것에 한계에 부딪히게 되어 이참에 모던 언어로 새로운 프레임워크를 개발하려 합니다. (기존 인프라에 호환되는)

이에 따라 ASP.NET의 웹 서버를 제외한 프레임워크 기능을 사용하며 서버는 자체 라우팅 시스템에 호환되는 서버를 내장하여 ASP.NET의 풍부한 기능들을 모두 활용하면서 손 쉽게 비즈니스 서비스 어플리케이션을 개발하기 위함이 목적입니다.

진행 방향은 ASP.NET의 기초 뼈대인 ApplicationBuilder를 이용하여 ASP.NET Http 미들웨어 파이프라인을 직접 생성하여 회사의 자체 L7 프로토콜과 호환되는 서버가 I/O를 담당하고 요청된 메시지에 대해HttpContext를 직접 생성하여 파이프라인을 통과 하게끔 설계하였습니다.

(물론 Http 기반으로 모두 바꾸는것이 제일 베스트이지만 이러한 부분은 쉽지가 않습니다…)

현재 프로토타이핑으로 성공적으로 기능이 잘 작동하며, 이제 ASP.NET의 MVC 기능과 같은 풍부한 기능들을 활용 할 수 있게 되었습니다. (커스텀 프로토콜 ↔ Http의 변환 레이어가 있지만 이는 코스트가 크지가 않습니다.)

다만, 걱정되는 부분은 이렇게 사용하는 케이스가 있는지? 그리고 이러한 형상으로 유지보수를 하고 있는 분들이 계실지 궁금합니다.
마이크로소프트에서도 ApplicationBuilder 자체를 public으로 노출 시켰다는 것은 이렇게 직접 사용해도 된다는 의미로 받아들였습니다.

초기에 이러한 아이디어로 리서칭을 했을때 이러한 Needs가 있는 여러 스택오버플로우 글들을 보았는데요.

이러한 방향성이 괜찮을지 닷넷데브의 수많은 경험을 가지신 개발자분들의 의견을 여쭙고 싶습니다.

PS. 참고한 스택오버플로우 링크: Programmatically invoking the ASP.NET Core request pipeline

4개의 좋아요

ApplicationBuilder 기능 자체는 ASP.NET에서만 쓰는 기능은 아니고, 두루 쓰이는 개발 패턴이라 딱히 다른 환경에서 사용을 못할 이유는 없을 것 같습니다. 구현하신 방식은 지극히 일반적이고 잘 쓰이는 방법론으로 보입니다. 다만 애플리케이션 패키지 사이즈가 너무 커지고 뚱뚱해지는 것이 혹시 아쉬우시다면, 추상화된 빌더 패키지를 조금 찾아서 튜닝을 시도해보셔도 좋지 않을까 생각합니다.

그리고 L7을 언급해주셨는데, Microsoft에서도 Yarp (Yet Another Reverse Proxy)라는 오픈 소스 프로젝트를 통해 닷넷 기반의 리버스 프록시 프레임워크를 ASP.NET Core와 연계하도록 디자인해서 출시했습니다. 아마 생각하시는 시나리오에 참고할만하거나 직접 가져다 쓸 만한 프레임워크일 것 같아 살짝 언급해봅니다.

이외에도, .NET 8 기반으로 구현을 하고 계시다면 NativeAOT 도입도 검토해보시면 좋을 것 같습니다. :+1:

6개의 좋아요

답변 감사합니다!
참고용으로 추천해주신 Yarp를 보니 제가 의문을 품었던 부분에 대해 유사하게 구현을 했네요! 덕분에 현재 진행하고 있는 방향이 ASP.NET Core에서도 지향하는 방향이라는것에 자신감이 생겼습니다. 감사합니다!

4개의 좋아요

CyGames의 오픈소스 자회사 CySharp에서 ASP.NET에 기반해서 자체 프레임워크나 서버를 적극적으로 구현하고 공개하는데요, 이쪽 리포들 둘러보시면 원하시는 사례가 있을 것 같아 공유해봅니다.

4개의 좋아요