다만 CSV데이터를 받아 차트를 그려서 보여주는 기능 페이지를 계획중입니다.
nuget : Blazor-ApexCharts](GitHub - apexcharts/Blazor-ApexCharts: A blazor wrapper for ApexCharts.js)
혼자 테스트가 불가능하고 경험도 없다보니 조언을 구합니다.
저는 그 서비스를 사용하지 않아서 감은 없지만, 대역폭 관련 경험을 공유하고자 합니다.
클라우드 서비스는 보통 하드웨어 티어 별 과금도 있지만, 대역폭 별 과금도 있습니다.
만약, ApexChart 에 WASM 이 들어가 있다면, 적지 않은 대역폭이 소진될 수 있습니다.
저는 cloudflare CDN에 테스트 앱(blazor wasm)을 운영 중이고, 이 앱은 4MB 수준입니다.
이 앱은 특정인한테만 공개해서 테스트 중인데, bot이나 crawler의 영향인지는 몰라도, 특정 월에 몇 백 GB 대역폭을 찍을 때도 있었습니다. 이 수치는 테스터의 접속만으로는 절대 나올 수 없습니다.
대역폭 과금이 없어 다행이었지, 대역폭 과금까지 있었으면…
참고로, 비용 측면에서는 1년에 한번 도메인 값 $11 내는 게 전부인데, 이는 제가 공개 도메인을 사용했기 때문에 발생한 것이고, dev.으로 시작하는 개발자 도메인을 사용한다면 내지 않아도 됩니다.
만약, Interactive WebAssembly 로 설정한 블레이저 앱을 클라우드 서버에 올렸다면, 식겁할 만 하죠.
간접적으로 나마 도움이 되었으면 합니다.
(정확한 상황은 컨설팅이 필요하겠으나 추정되는 내용만 가지고 의견을 먼저 드려봅니다.)
특정 데이터베이스에 대한 문제보다도, 아키텍처 관점으로는 캐싱 서버와 API 서버를 잘 활용해서 읽기가 빈번한 데이터는 캐시를 통해 제공될 수 있게 해주시고, 쓰기 작업의 경우만 그 빈도를 측정해서 얼마나 데이터베이스에 성능 상의 임팩트를 주겠는지를 체크해보시는 것이 중요하지 않을까 생각합니다.
거기다, 일단 NGINX를 프론트 웹 서버로 따로 두는 이유도 실제 애플리케이션을 담고 있는 ASP.NET 서버가 처리해야 할 요청이 아닌 기타 나머지 모든 요청 (파비콘 요청, 검색 엔진 크롤러 대응 등)은 특별한 연산이 필요하지 않은 NGINX 같은 평이한 웹 서버가 대행하도록 역할 분리를 하기 위함인 것도 있습니다.
그래서 실제 비즈니스 요구 사항이 어떤지에 따라 다른 상황이 펼쳐지겠지만 대부분의 경우 우려하시는 만큼의 성능 문제는 구현 관점에서의 문제가 아닌 경우 크게 문제가 될 가능성은 높지 않다고 생각합니다.
그리고 블레이저 타입의 애플리케이션 중에서, WASM 비중이 높은 경우에는 WASM 콘텐츠 자체를 CDN 등의 네트워크 가속 인프라를 사용해서 빠르게 딜리버리할 수 있도록 구성하는 것이 좋습니다. 이 부분은 서버의 부하도 있겠지만, 사용자가 "체감하는 성능"에 영향을 주는 부분이 큽니다.
안타깝게도 현재 블레이저 구현체는 닷넷 런타임의 상당 부분을 거의 그대로 패키징해서 웹 어셈블리로 만드는 방식을 취하다보니 초기 콜드 로딩에서 전달받아야 할 내용이 상당한 편입니다. 그나마 이 부분에 대한 경험을 완화시켜줄 수 있는 것은 CDN 같은 수단을 쓰는 것이 방편이 될 것 같습니다.
반면 WASM에 의존하는 비율을 줄이고 서버 렌더링 우선으로 간다면, 서버에 부하를 좀 더 얹어주고 콜드 로딩 경험은 개선할 수 있을 것 같습니다. 양쪽이 트레이드 오프가 어느 정도 있는 것이라고 할 수 있겠습니다.
(덧: 콜드 로딩이란 아무런 사전 준비없이 아주 맨 처음 사용자가 경험하게 되는 로딩 상황을 말합니다.)
제 질문에 설명이 부족했나봅니다.
WASM은 초기 다운로드 받아야 하는 런타임으로 인해 로딩 속도가 걸리는것을 알고있습니다.
그래서 서버 렌더링으로 웹페이지를 구성해보려 합니다.
실질적으로 이용자는 페이지를 오고 가며 내용을 보는 수준이 될것입니다.
질문을 요약하자면 서버 렌더링을 할 경우 서버에 부하가 얼마나 가게 될지 계산하는 방법이나 경험이 궁금합니다.
(단순 계산은 어렵겠지만 동시접속자 100명당 메모리 1기가로 잡고 계산한다 등등의 대략적인 사양견적 내는 방식이 궁금합니다.)
서버 렌더링을 사용할 경우, 기본적으로 서버형 가비지 컬렉터를 사용하게 되므로, 클라이언트 실행 때와는 달리 어그레시브하게 가비지 컬렉션을 시도하지는 않을 것입니다.
정확한 메모리 소비량 측정은 프로파일러를 통해서 재보는 것이 필요할 것입니다. 그러나 이런 특성에 비추어봤을 때, 사용하는 개체가 많다면 메모리 소비량이 일반적인 웹 요청에 비해서는 "많을 수 있음"을 가정하고 상대적으로 넉넉한 메모리 크기를 갖춘 서버를 구성하는 것이 유리할 것으로 예상됩니다.
그리고 객체의 라이프사이클을 안전하고 정확하게 관리하기 위해서는 ASP.NET의 Scoped DI를 적극 사용하는 것이 좋습니다. 이런 조건을 충족하도록 애플리케이션을 개발한 이후에 프로파일링을 해보면서 실제로 어떤 사양을 필요로 할 지 확인해보셔야 하지 않을까 싶습니다.
저도 궁금해서 검색을 해봤습니다.
보시는 분들 편의를 위해, 요약하자면, .net core 3.0 기준, 아래 정도에서는 성능 저하가 없다고 합니다.
Standard D1 V2 on Azure (1 vCPU, 3.5 GB memory) : 5000 users
Standard D3 V2 (4 vCPU, 14GB memory) : 20,000 users
8.0 기준으로는 더 좋아 졌을 거라는 예상을 해봅니다만,
다만, 코드 구조가 웹소켓 통신을 얼마나 자주 유발하도록 설계되었느냐에 따라 완전히 달라질 수 있을 것입니다.
예를 들어, 마우스 관련 이벤트를 빈번하게 처리하는 코드 구조라면, 웹소켓 통신은 매우 자주 일어나고, 그 만큼 동시 접속 사용자는 줄어 들 것입니다.
(이와 같이 interaction이 많다면 wasm 이 더 좋은 선택입니다)