원본 글: Introducing .NET Aspire: Simplifying Cloud-Native Development with .NET 8 - .NET Blog
.NET 8에 추가된 백엔드 스택으로 .NET Aspire 특집 아티클이 있어 읽는 분들의 편의를 위해 영한 기계 번역본 콘텐츠를 공유합니다.
Aspire는 예전에 나왔던 Project Tye (실험용 오픈 소스 프로젝트)에서 부족했던 점을 대폭 보완한 것으로 보입니다.
지금까지 여러 릴리스에서 Microsoft는 지속적으로 열망하는 목표 중 하나에 진전을 이루었습니다. .NET을 클라우드 네이티브 애플리케이션을 빌드하는 데 가장 생산적인 플랫폼 중 하나로 만드는 것입니다.
Microsoft에서 가장 까다로운 서비스 중 일부와 함께 일하면서 대부분의 앱에서 전례가 없는 확장 요구 사항, 즉 수억 명의 월간 활성 사용자를 지원하는 서비스와 함께 작업했습니다. 이러한 서비스와 협력하여 요구 사항을 충족시킴으로써 대규모 클라우드 서비스의 요구 사항을 충족할 수 있는 기본 기능을 확보할 수 있었습니다.
상태 확인, YARP, HTTP 클라이언트 팩토리, gRPC와 같은 중요한 기술 및 라이브러리에 투자했습니다. Native AOT를 통해 성능과 크기의 최적점을 향해 노력하고 있으며, SDK 컨테이너 빌드를 사용하면 개발자의 생각이나 작업 없이도 모든 .NET 앱을 컨테이너로 가져와 최신 클라우드에 사용할 수 있도록 간단하게 준비할 수 있습니다.
하지만 개발자들의 의견을 들어보니 더 많은 작업이 필요하다는 의견이 있었습니다. 클라우드용 앱을 빌드하는 것은 여전히 너무 어려웠습니다. 개발자는 점점 더 비즈니스 로직과 클라우드의 복잡성을 처리하는 데 가장 중요한 것에서 멀어지고 있습니다.
클라우드 앱의 복잡성을 간소화할 수 있도록 다음과 같은 기능을 소개합니다.
.NET Aspire는 .NET을 사용하여 복원력 있고, 관찰 가능하며, 구성 가능한 클라우드 네이티브 애플리케이션을 빌드하기 위한 의견 스택입니다. 여기에는 서비스 검색, 원격 분석, 복원력 및 상태 확인을 포함하여 클라우드 네이티브에 맞게 향상된 엄선된 구성 요소 집합이 기본적으로 포함되어 있습니다. 정교하지만 간단한 로컬 개발자 환경과 결합된 .NET Aspire를 사용하면 첫날은 물론 100일째에도 .NET 8+를 사용하는 신규 및 기존 .NET 앱에서 클라우드 네이티브 앱에 필요한 필수 종속성을 쉽게 검색, 획득 및 구성할 수 있습니다.
.NET 8과 함께 .NET Aspire의 첫 번째 프리뷰를 출시하며, 내년 봄에 .NET 8의 일부로 정식 출시할 예정입니다. .NET 8의 일부이며 향후 .NET과 함께 버전이 출시될 예정입니다. (문서, GitHub)
.NET Aspire 둘러보기
우선, 이 글의 뒷부분에서 더 자세히 살펴보기 전에 새로운 .NET Aspire 스타터 템플릿을 둘러보고 모든 기능을 살펴보겠습니다. 이 섹션은 함께 따라할 수 있는 대화형 개요로 설계되었습니다. 최신 .NET 8 및 Visual Studio 2022 프리뷰(17.9 프리뷰 1)가 필요합니다. Linux 또는 Mac을 사용하는 경우에도 모든 내용을 따라할 수 있지만 일부 툴링 예제는 아직 제공되지 않습니다.
Visual Studio 솔루션 둘러보기
스타터 앱은 실제 작동하는 .NET Aspire 솔루션을 사용해 볼 수 있도록 설계되었습니다. 이 앱은 두 개의 프로젝트와 Redis 캐시로 구성됩니다. 프론트엔드 프로젝트는 날씨 정보를 위해 백엔드 API를 호출하는 Blazor 웹 애플리케이션입니다.
이전에는 볼 수 없었던 두 개의 새로운 프로젝트인 .AppHost와 .ServiceDefaults를 확인할 수 있습니다.
AppHost 프로젝트는 배포된 애플리케이션을 가져오는 데 필요한 모든 .NET 프로젝트, 컨테이너 또는 실행 파일을 실행합니다. Visual Studio에서는 실행 중인 모든 프로젝트에 디버깅이 첨부되어 애플리케이션의 각 서비스를 단계별로 살펴볼 수 있습니다. 이 글의 뒷부분에서 이 프로젝트와 그 안의 코드에 대해 자세히 살펴보겠습니다.
ServiceDefaults 프로젝트에는 앱의 각 프로젝트에 적용되는 공통 서비스 중심 로직이 포함되어 있습니다. 여기에서 서비스 검색, 원격 분석, 상태 확인 엔드포인트와 같은 교차적인 문제가 구성됩니다. 모든 프로젝트에서 일관성이 유지되기를 원했지만 팀과 조직에서 일부 설정을 조정하고 싶을 수 있다는 점도 이해했습니다. 프로젝트의 공유 코드는 이러한 목표를 달성하기 위해 찾을 수 있는 가장 검색하기 쉽고 개발자 친화적인 메커니즘이었습니다.
대시보드 - 앱 모니터링 및 검사를 위한 중앙 허브
Visual Studio 또는 명령줄을 통해 실행되는 닷넷에서 F5를 사용하여 .NET Aspire 스타터 애플리케이션을 실행하면 개발자 대시보드로 이동합니다. 이 대시보드는 분산 애플리케이션을 디버깅하는 데 필수적인 도구로서 로그, 메트릭 및 추적과 함께 서비스에 대한 통합 보기를 제공합니다.
이 대시보드는 단순히 클라우드 네이티브 애플리케이션을 보여주는 창이 아니라 프로젝트에 대한 귀중한 인사이트를 제공하고 오류를 강조 표시하여 더 깊이 조사할 수 있는 대화형 플랫폼입니다. 아래는 빨간색 점으로 표시된 오류가 확인된 프로젝트를 보여주는 이미지입니다:
또한 모든 프로젝트의 로그와 날씨 페이지에 대한 요청을 보여주는 분산 추적도 볼 수 있습니다. 추적은 분산 시스템의 문제를 진단하는 데 없어서는 안 될 도구입니다.
개발자 대시보드는 모든 개발 시간 진단 데이터를 한데 모아 개발 머신의 속도 저하 및 버그 문제를 해결할 수 있는 홈입니다. 이 대시보드는 Grafana+Prometheus, Application Insights 등과 같은 프로덕션 텔레메트리 시스템을 구성할 때 프로덕션에서 사용하는 것과 동일한 개방형 표준을 모두 사용합니다. 이 포스팅의 뒷부분에서 대시보드에 대해 자세히 살펴보겠습니다.
몇 년 전에 Project Tye라는 실험을 진행했는데, 이 실험에서 처음 시도했던 이 대시보드를 포함하여 이 실험에서 얻은 많은 교훈을 이제 .NET Aspire에서 사용할 수 있습니다. 프로젝트 타이가 재미있었고 계속 이어지기를 원했다면 .NET Aspire도 마음에 드실 것입니다.
구성 요소
이제 프로젝트의 어떤 점이 다른지 살펴보겠습니다. 먼저, 웹 프로젝트에는 Aspire.StackExchange.Redis.OutputCaching이라는 이름으로 Aspire가 포함된 NuGet 패키지가 있습니다.
이 과정을 따라가는데 이 패키지가 보이지 않는다면 프로젝트를 생성할 때 “Redis 캐싱 사용” 확인란을 선택하지 않았을 가능성이 높습니다.
이 NuGet 패키지를 우리는 .NET Aspire 컴포넌트라고 부릅니다. 컴포넌트는 클라우드 환경에서 작동하도록 SDK를 구성하는 글루 라이브러리입니다. 각 컴포넌트는 다음을 수행해야 합니다:
앱설정.json에서 문 완성을 제공하도록 구성할 JSON 스키마를 제공해야 합니다.
재시도, 시간 초과, 회로 차단기 등 구성 가능한 복원력 패턴을 활용하여 가용성을 극대화합니다.
애플리케이션이 원격 서비스의 상태를 추적하고 이에 대응할 수 있도록 상태 확인을 노출합니다.
최신 .NET 추상화(ILogger, Meter, Activity)를 사용하여 통합 로깅, 메트릭, 추적을 제공하세요.
등록되는 유형에 적합한 수명으로 SDK에서 DI 컨테이너로 서비스를 '글루’하는 확장 메서드를 제공합니다.
이 글의 뒷부분에서 컴포넌트에 대해 더 자세히 살펴보겠습니다. 핵심은 .NET Aspire 구성 요소는 클라우드에서 성공하기 위해 소비자를 설정하는 일련의 요구 사항을 준수하도록 종속성을 구성한다는 것입니다. 실제 SDK/라이브러리를 감싸거나 숨기는 것이 아니라 라이브러리가 적절한 기본값으로 구성되고 DI에 올바르게 등록되도록 하는 접착제 역할을 합니다. 오늘날에는 일반적으로 개발자에게 맡겨진 작업입니다.
코드
이제 날씨 API를 호출하는 Blazor 앱의 코드와 앞서 설명한 AppHost의 일부 코드를 살펴보겠습니다. 먼저 웹 프로젝트의 Program.cs에서 다음과 같은 코드를 볼 수 있습니다:
builder.Services.AddHttpClient<WeatherApiClient>(
client => client.BaseAddress = new("http://apiservice"));
이것은 날씨 API를 호출할 수 있도록 웹 프런트엔드를 구성하는 것입니다. 하지만 여기에는 몇 가지 특이한 점이 있는데, 바로 이 apiservice 이름이 어디에서 유래한 것일까요? 이에 대한 답을 찾기 위해 AppHost 프로젝트를 처음으로 살펴볼 것이며, 여기 해당 프로젝트의 Program.cs 파일이 있습니다.
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedisContainer("cache");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
.WithReference(cache)
.WithReference(apiservice);
builder.Build().Run();
이 코드는 앱호스트가 시작 프로젝트이기 때문에 실행됩니다. 이 코드는 프로젝트와 프로젝트의 종속성을 실행하고 프로젝트가 통신할 수 있도록 적절하게 구성합니다. 저희의 목표 중 하나는 개발자 흐름에서 포트와 연결 문자열을 최대한 제거하는 것입니다. 이를 위해 개발자가 HTTP 호출을 할 때 IP 주소와 포트 대신 논리적 이름을 사용할 수 있는 서비스 검색 메커니즘을 사용합니다. 여기에서 API의 이름을 apiservice로 지정한 다음 이를 프런트엔드에 참조로 전달한 다음 IHttpClientFactory를 통해 HTTP 호출을 할 때 apiservice를 이름으로 사용할 수 있음을 확인할 수 있습니다. 이 방법을 사용한 호출은 Polly 프로젝트와의 통합 덕분에 일시적인 실패도 자동으로 재시도하고 처리합니다.
앱 호스트가 앱 종속성 및 요구 사항을 설정하면 .NET Aspire 툴링이 개발 루프에서 이를 충족합니다.
더 깊은 다이빙
컴포넌트
이제 컴포넌트에 대해 자세히 살펴보겠습니다. .NET Aspire 구성 요소는 클라우드 네이티브 개발을 시작하려는 고객으로부터 제대로 익혀야 할 기술/구성이 많고 어떤 경로로 시작해야 할지 명확하지 않다는 어려움을 해결하기 위해 고안되었습니다. 저희는 모든 구성 요소가 최소한 복원력 기본값, 상태 확인, 원격 분석 설정, DI와의 통합을 제공하도록 의무화하여 구성 요소가 제공해야 하는 사항에 대한 의견을 제시함으로써 이러한 문제를 해결하도록 돕습니다. 이를 강조하기 위해 프로덕션 준비가 완료된 앱이 앱에서 Redis를 구성하는 방법을 살펴봅시다:
- Redis 클라이언트 라이브러리와 함께 Redis 패키지를 추가합니다.
- 앱이 Redis를 사용할 수 없을 때 응답할 수 있도록 상태 검사 라이브러리를 찾아서 추가합니다. 이는 자주 놓치는 부분이지만 실제로는 유용합니다.
- DI에 Redis를 추가하고 연결 문자열을 구성합니다. 이 작업은 Redis 클라이언트 라이브러리 유형의 수명을 알아야 하므로 까다롭습니다. 따라서 조사가 필요합니다.
- 로그 출력을 원격 분석 시스템으로 전송하도록 Redis 클라이언트 라이브러리를 구성합니다.
- 로그와 메트릭은 서로 다르며 다른 배관이 필요합니다.
- 어떤 복원력 정책과 로직이 필요한지 결정하고, 복원력 정책을 구현할 수 있는 Poly와 같은 라이브러리로 Redis를 구성하거나 호출을 래핑하세요. 이 역시 Redis의 기능에 대한 조사와 어떤 복원력 정책이 필요한지에 대한 지식이 필요한데, 처음부터 이를 알지 못하는 경우가 많기 때문에 기하급수적인 백오프를 사용하는 재시도 정책으로 피할 수 있는 프로덕션에서 문제가 발생할 때까지 복원력 정책 없이 배포하게 되는 경우가 많습니다.
이를 .NET Aspire 사용과 대조해 보면 다음과 같습니다:
- .NET Aspire Redis 패키지를 추가합니다.
- 빌더에서 AddRedis를 호출합니다.
- 선택적으로 appSettings.json에서 기본 구성을 재정의합니다(이제 도식화되어 있으므로 설정할 수 있는 항목을 찾을 수 있습니다).
.NET Aspire 구성 요소는 기본 SDK를 숨기지 않고 프로덕션에 바로 사용할 수 있는 최적의 구성을 제공하도록 제작되었습니다. 앞서 언급한 두 예제에서 Redis를 활용하기 위한 코드는 일관되게 동일한 Redis 클라이언트 라이브러리 및 유형을 사용합니다.
컴포넌트는 다음을 수행해야 사용할 준비가 된 것으로 간주됩니다:
- 상세하고 도식화된 구성을 제공합니다.
- 원격 서비스 상태를 추적하고 응답할 수 있도록 상태 확인을 설정합니다.
- 가용성을 극대화하기 위해 구성 가능한 기본 복원력 패턴(재시도, 시간 초과 등)을 제공하세요.
- 구성 요소를 관찰할 수 있도록 통합 로깅, 메트릭, 추적을 제공합니다.
초기 구성 요소 집합은 아래에 나열되어 있으며, 자세한 설명서는 .NET Aspire 구성 요소 개요 | Microsoft Learn에서 확인할 수 있습니다.
클라우드 벤더 중립적인 컴포넌트
| 이름 | 설명 |
|---|---|
| PostgreSQL Entity Framework Core | 엔티티 프레임워크 코어를 사용하여 PostgreSQL 데이터베이스에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| PostgreSQL | PostgreSQL 데이터베이스에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| RabbitMQ | RabbitMQ에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Redis Distributed Caching | 분산 캐싱을 위해 Redis 캐시에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Redis Output Caching | 출력 캐싱을 위해 Redis 캐시에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Redis | Redis 캐시에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| SQL Server Entity Framework Core | 엔티티 프레임워크 코어를 사용하여 SQL Server 데이터베이스에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| SQL Server | SQL Server 데이터베이스에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
Azure에 특화된 컴포넌트
| 이름 | 설명 |
|---|---|
| Azure Blob Storage | Azure Blob Storage에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Azure Cosmos DB Entity Framework Core | 엔티티 프레임워크 코어를 사용하여 Azure Cosmos DB 데이터베이스에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Azure Cosmos DB | Azure Cosmos DB 데이터베이스에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Azure Key Vault | Azure Key Vault에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Azure Service Bus | Azure Service Bus에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
| Azure Storage Queues | Azure 스토리지 큐에 액세스하기 위한 클라이언트 라이브러리를 제공합니다. |
현재 이 구성 요소 집합은 Microsoft에서 사용할 수 있으며 제공됩니다. 우리의 목표는 클라우드가 변화하고 더 많은 라이브러리가 구성 요소를 보유하기를 원함에 따라 Aspire 구성 요소가 되기 위한 프로세스와 이에 대한 요구 사항/베스트 프랙티스가 커뮤니티 주도로 만들어지는 것입니다.
애플리케이션 모델
.NET Aspire 앱의 AppHost 프로젝트를 사용하면 애플리케이션의 요구 사항을 선호하는 .NET 언어로 표현할 수 있습니다(초기에는 C# 지원). 이 프로젝트는 개발 컴퓨터에서 앱의 실행을 오케스트레이션하는 역할을 합니다.
오케스트레이션은 클라우드 네이티브 앱의 여러 부분 간의 연결 및 구성을 간소화하도록 설계된 .NET Aspire의 핵심 기능입니다. .NET Aspire는 서비스 검색, 환경 변수, 컨테이너 구성과 같은 문제를 낮은 수준의 구현 세부 정보를 관리할 필요 없이 오케스트레이션할 수 있는 유용한 추상화를 제공합니다. 또한 이러한 추상화는 많은 구성 요소와 서비스가 포함된 애플리케이션 전반에서 일관된 설정 패턴을 제공합니다.
.NET Aspire 오케스트레이션은 다음과 같은 문제를 지원합니다:
- 앱 구성 : .NET 프로젝트, 컨테이너, 실행 파일 또는 클라우드 리소스 등 애플리케이션을 구성하는 리소스를 정의합니다.
- 서비스 검색: 서로 다른 리소스가 서로 통신하는 방법을 결정합니다.
예를 들어, 다음 코드는 .NET Aspire를 사용하여 로컬 Redis 컨테이너 리소스, API용 프로젝트 리소스를 만들고 “웹프론트엔드” 프로젝트에서 적절한 연결 문자열 및 URL을 구성합니다.
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedisContainer("cache");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
.WithReference(cache)
.WithReference(apiservice);
builder.Build().Run();
이제 “웹프론트엔드” 프로젝트는 포트 매핑에 대해 걱정할 필요 없이 http://apiservice 로 HTTP 요청을 할 수 있습니다. .NET Aspire 구성 요소가 자동으로 제공된 연결 문자열을 사용하도록 Redis 클라이언트를 구성하므로 Redis 연결 문자열이 훨씬 더 투명해집니다. 따라서 개발 흐름에서 오류가 발생하기 쉬운 설정의 큰 원인을 제거하고 시작과 온보딩을 모두 간소화할 수 있습니다. 프로덕션 환경에서 서비스 검색을 사용하는 경우, 기본 Kubernetes 기능만 사용하더라도 수동 구성보다 프로덕션을 더 가깝게 미러링할 수 있습니다.
초기 리소스 세트는 다음과 같습니다:
기본 제공 리소스
- 프로젝트: .NET 프로젝트(예: ASP.NET Core 웹 앱).
- 컨테이너: 컨테이너 이미지(예: Docker 이미지).
- 실행 파일: 실행 파일.
클라우드에 구애받지 않는 확장 프로그램
각 확장 기능은 해당 리소스에 대한 NuGet 패키지(구성 요소)를 추가하면 사용할 수 있습니다. 이들 각각에 대해 개발 중에 .NET Aspire가 컨테이너를 시작하거나 연결 문자열을 통해 기존/외부 리소스에 연결할 수 있습니다.
- 포스트그레스
- RabbitMQ
- Redis
- SQL Server
Azure 특정 확장
이러한 각 메서드는 해당 리소스에 대한 NuGet 패키지(구성 요소)를 추가하면 사용할 수 있습니다. 현재 이러한 리소스 중 로컬 컨테이너 실행을 지원하는 리소스는 Azure Storage가 유일하며, 나머지는 실제 Azure 리소스에 대한 연결 정보가 필요합니다.
- Azure 저장소(블롭, 테이블, 대기열)
- Azure Cosmos DB
- Azure KeyVault
- Azure Redis 캐시
- Azure 서비스 버스
오케스트레이션 작동 방식에 대한 자세한 내용은 .NET Aspire 설명서에서 확인할 수 있습니다: .NET Aspire 오케스트레이션 개요 | Microsoft Learn
개발자 대시보드
.NET Aspire 대시보드는 AppHost가 실행되는 동안에만 표시되며 프로젝트를 시작할 때 자동으로 실행됩니다. 왼쪽 탐색은 여기에서 설명할 대시보드의 여러 부분에 대한 링크를 제공합니다. 또한 대시보드 오른쪽 상단의 톱니바퀴 아이콘은 대시보드 환경을 구성할 수 있는 설정 페이지에 대한 액세스를 제공합니다.
- 프로젝트: 프로젝트 페이지는 대시보드의 홈 페이지로, 애플리케이션의 모든 프로젝트 리소스를 나열합니다. 주요 기능은 각 프로젝트의 상태를 표시하고 앱의 일부에 대한 URL을 제공하는 것입니다. 또한 프로젝트에 오류가 기록되면 배지가 표시되어 문제를 쉽게 파악할 수 있습니다.
- 컨테이너: 이 페이지는 프로젝트 페이지와 동일하지만 애플리케이션의 컨테이너 리소스에 대한 페이지입니다. 위의 둘러보기에서는 Redis 캐시 컨테이너가 여기에 표시됩니다.
실행 파일: 이 페이지는 프로젝트 페이지와 동일하지만 애플리케이션의 실행 리소스에 대한 페이지입니다. - 로그: 대시보드의 로그 섹션에서는 애플리케이션의 모든 부분에 대한 로그를 중앙 위치에서 액세스할 수 있습니다.
- 프로젝트 로그: .NET 프로젝트의 로깅 공급자의 출력을 여기에서 볼 수 있으며, 각 프로젝트 간에 전환할 수 있고 각 로그 심각도는 다른 색상으로 표시됩니다.
- 컨테이너 로그: 이 페이지는 프로젝트 로그와 동일하지만 컨테이너에 대한 것입니다.
실행 로그: 이 페이지는 프로젝트 로그와 동일하지만 실행 파일에 대한 페이지입니다. - 구조화된 로그: 구조화된 로그 페이지에서는 모든 로그를 필터링할 수 있는 보기를 제공합니다. 구조화된 로그는 로그 메시지의 속성을 유지하므로 개별적으로 필터링/검색할 수 있는 반면, 다른 로그 페이지에는 모든 속성이 단일 문자열 로그 메시지로 병합되어 있습니다.
- 추적: 추적 페이지에는 애플리케이션의 모든 부분에 걸친 단일 동작의 경로, 즉 분산 추적이 표시됩니다. 이 보기는 병목 현상, 속도 저하 등을 찾아내고, 전체 시스템이 사용 중일 때만 나타나는 기타 동작을 진단하는 데 매우 유용할 수 있습니다. 위의 둘러보기 섹션에서 추적 보기의 스크린샷을 보여드렸는데, Redis 캐시, API, 프론트엔드를 사용하는 단일 작업을 하나의 보기에서 모두 볼 수 있는 방법을 강조했습니다.
- 메트릭: 메트릭 페이지에는 애플리케이션에 대한 모든 메트릭이 표시됩니다.
대시보드에 대한 자세한 내용은 .NET Aspire 대시보드 | Microsoft Learn에서 확인할 수 있습니다.
관찰 가능성
.NET Aspire 애플리케이션은 기본적으로 통합 가시성을 제공합니다. 통합 가시성이 뛰어나다는 것은 실행 중인 앱에서 수집되는 모든 데이터를 통해 특히 중단 중에 솔루션에서 무슨 일이 일어나고 있는지 확인할 수 있다는 의미입니다. 특히 로그, 메트릭, 추적을 통해 확인할 수 있습니다. 로그와 메트릭이 있어도 무슨 일이 일어나고 있는지 파악할 수 없다면 전체 시스템을 관찰할 수 없으며, 적시에 적절한 보기에서 올바른 데이터가 필요합니다.
즉, 앱을 관찰할 수 있어야 합니다:
- .NET 자체, 사용하는 라이브러리, 자체 애플리케이션 코드를 포함하여 분산 애플리케이션의 모든 부분이 사용자가 사용할 수 있는 방식으로 데이터를 제공해야 합니다.
- 이러한 데이터는 사용자가 액세스할 수 있는 어딘가로 전송되어야 합니다.
- 데이터를 보고/쿼리하고/이해할 수 있는 도구가 존재해야 합니다.
.NET에서는 데이터의 형식으로서 오픈 원격 분석에 점점 더 많은 투자를 하고 있으며, 데이터에 대한 오픈 원격 분석 이름 지정 및 구조를 채택하고, 데이터를 애플리케이션에서 도구 에코시스템으로 가져오기 위한 오픈 원격 분석 프로토콜(OLTP)을 채택하고 있습니다.
.NET Aspire에서는 기본적으로 ServiceDefaults 프로젝트에서 Open Telemetry를 연결하기 위한 코드를 제공합니다. 공유 코드를 사용한 이유는 상태 엔드포인트의 이름과 같이 일부 사람들이 프로젝트나 회사에 맞게 사용자 지정하고 싶을 것으로 예상되는 규칙이 있기 때문입니다. 실험 결과, 공유 코드는 구성 설정이 있는 라이브러리에 넣는 것보다 사람들이 조정할 수 있는 이러한 유형의 기본값을 정의하는 데 더 나은 환경을 제공한다는 것을 알게 되었습니다.
또한 위에서 언급한 개발자 대시보드를 제공하여 앱의 모든 로그, 메트릭 및 추적을 제공합니다. 대시보드의 주요 기능 중 하나는 앱을 통과한 요청의 분산 추적을 제공하는 추적 보기입니다. 아래 예제에서는 Aspire 스타터 앱 템플릿의 날씨 페이지에 대한 요청을 수행했습니다. 요청이 프론트엔드에서 Redis 캐시로 이동하여 데이터가 캐시되는지 확인한 다음(DATA redis GET 라인), 캐시에 데이터가 없기 때문에 백엔드 API를 호출하고 마지막으로 해당 데이터를 캐시하는 과정을 확인할 수 있습니다.
이러한 유형의 보기를 사용하면 시스템에서 비효율적인 경로를 유발하는 사용자 작업과 같은 것을 찾을 수 있습니다. 여러 데이터베이스 호출이 이루어지거나 시스템의 다른 부분의 속도를 저하시키는 개별 서비스 등을 즉시 확인할 수 있습니다. 이러한 유형의 문제는 이러한 유형의 데이터와 데이터 보기가 없으면 발견하기 어려울 수 있습니다.
서비스 발견
분산 애플리케이션 구축의 핵심 요소 중 하나는 원격 서비스를 호출할 수 있는 기능입니다. .NET Aspire의 일부로 새로운 서비스 검색 라이브러리인 Microsoft.Extensions.ServiceDiscovery를 빌드했습니다. 이 라이브러리는 클라이언트 측 서비스 검색 및 부하 분산에 대한 핵심 추상화 및 다양한 구현을 제공하여 HttpClientFactory 및 YARP와 원활하게 통합할 수 있으며, 배포된 환경에서도 Kuberentes 및 Azure 컨테이너 앱과 통합할 수 있습니다.
여기에서 서비스 검색에 대해 자세히 알아보세요: .NET Aspire의 서비스 검색
.NET Aspire 애플리케이션 배포
.NET Aspire 애플리케이션의 최종 아티팩트는 클라우드 환경에 배포할 수 있는 .NET 앱 및 구성입니다. 강력한 컨테이너 우선 사고방식을 가진 .NET Aspire의 .NET SDK 네이티브 컨테이너 빌드는 이러한 앱을 컨테이너에 쉽게 게시할 수 있는 유용한 도구 역할을 합니다.
.NET Aspire 자체는 기본적으로 애플리케이션을 최종 대상에 배포하는 직접적인 메커니즘을 제공하지 않지만, 위에서 설명한 애플리케이션 모델은 애플리케이션의 종속성, 구성 및 각 서비스에 대한 연결을 모두 알고 있습니다. 애플리케이션 모델은 도구가 배포를 위해 소비, 보강 및 구축할 수 있는 이러한 모든 관계와 종속성을 설명하는 매니페스트 정의를 생성할 수 있습니다.
이 매니페스트를 통해 Azure 컨테이너 앱을 사용하여 가능한 가장 간단하고 빠른 방법으로 .NET Aspire 애플리케이션을 Azure로 가져올 수 있게 되었습니다. Azure 개발자 CLI 및 .NET Aspire의 새로운 기능을 사용하여 이러한 결합된 환경을 사용하면 .NET Aspire 환경을 빠르게 감지하고, 애플리케이션을 이해하고, 한 단계로 Azure 리소스를 즉시 프로비저닝 및 배포할 수 있습니다.
(참고: 이 비디오의 일부는 속도가 빨라졌습니다. Aspire 스타터 앱은 일반적으로 프로비저닝 및 배포하는 데 약 5분이 걸립니다.)
위 동영상에서 볼 수 있듯이, .NET Aspire를 사용하여 코드에서 클라우드로 전환하는 가장 빠른 방법 중 하나입니다. Microsoft는 Visual Studio의 게시 메커니즘과 같은 도구에서 배포의 용이성을 확장하고, 동일한 기본 매니페스트를 활용하고, 즐겨 사용하는 IDE에서 바로 Azure 개발자 CLI와 통합하여 .NET Aspire 앱을 배포하는 이 기능을 계속 발전시킬 것입니다!
Azure 개발자 CLI는 또한 개발자와 플랫폼 엔지니어가 배포 프로세스를 감사하거나 보강할 수 있도록 매니페스트에서 바이셉을 만들 수 있습니다.
이 기능은 많은 IaC 시스템과 통합되는 핵심 구성 요소가 될 것으로 예상합니다. 매니페스트 및 .NET Aspire 앱의 배포에 대한 자세한 내용은 다음을 참조하세요: .NET Aspire 매니페스트 형식 - .NET | Microsoft Learn을 참조하세요.
기존 앱
지금까지 이 블로그 게시물에서 많은 새로운 애플리케이션을 소개했지만, 스택의 다양한 부분을 점진적으로 채택할 수 있으므로 기존 애플리케이션과 함께 .NET Aspire를 사용할 수도 있습니다.
첫째, .NET Aspire는 .NET 8의 일부입니다. 따라서 스택의 일부를 사용하려면 먼저 업그레이드해야 합니다. 여기에 도움이 되는 도구와 지침이 있습니다: 업그레이드 도우미 | .NET(microsoft.com). 또한 Visual Studio 도구를 사용하려면 이 글을 작성할 당시 17.9 버전인 최신 Visual Studio 프리뷰 버전이 필요합니다.
이 버전이 있으면 Visual Studio에서 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 추가 → Aspire Orchestrator 지원을 선택하면 됩니다.
그러면 프로젝트와 작업을 확인하기 위해 다음과 같은 메시지가 표시됩니다.
이렇게 하면 AppHost 및 ServiceDefaults 프로젝트가 생성되며 선택한 프로젝트는 이미 AppHost에 추가됩니다. 이제 AppHost 프로젝트를 실행하면 개발자 대시보드가 표시됩니다. 여기에서 ServiceDefaults 프로젝트에 대한 참조를 추가하고 애플리케이션 빌더에서 AddServiceDefaults() 메서드를 호출할 수 있습니다. 이렇게 하면 이 프로젝트에 대한 Open Telemetry, 상태 확인 엔드포인트, 서비스 검색 및 기본 복원력 패턴이 설정됩니다.
Visual Studio를 사용하지 않는 경우에도 닷넷 새로 만들기를 사용하여 기존 솔루션에 AppHost 및 ServiceDefaults 프로젝트를 추가할 수 있지만 위의 예제처럼 기존 프로젝트를 이미 참조하지는 않습니다.
이제 컴포넌트가 있는 서비스를 사용 중인 경우 .NET Aspire 컴포넌트로 전환할 수 있습니다. 즉, 이미 컴포넌트가 수행하는 작업을 직접 설정한 경우 일부 명시적 구성을 제거할 수 있습니다. 또한 오케스트레이션 없이 모든 .NET 8 앱에서 컴포넌트를 자유롭게 사용할 수 있습니다. 이렇게 하면 복원력 및 기타 구성이 구성 요소에 적용되지만 대시보드, 서비스 검색, 자동 포트, URL 또는 연결 문자열과 같은 나머지 .NET Aspire는 사용할 수 없습니다.
결론
오늘 .NET Aspire의 첫 번째 미리 보기를 제공하게 되어 정말 기쁩니다. 탄탄한 기본 기반과 믿을 수 없을 정도로 생산적인 .NET 8의 API 표면을 기반으로 구축되었으므로 .NET Aspire를 사용하여 클라우드 네이티브 앱을 빌드할 때 생산성을 크게 향상시킬 수 있을 것이라고 확신합니다.
지금 바로 다음 리소스를 사용하여 시작하세요:
가장 중요한 것은 여러분의 의견을 듣고 개선할 수 있는 부분이 무엇인지 파악하는 것입니다. .NET Aspire는 .NET 플랫폼 및 파운데이션의 일부이며 플랫폼과 함께 오픈 소스 프로젝트입니다. GitHub - dotnet/aspire: An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET 에서 참여하세요.
이 글은 www.DeepL.com/Translator로 기계 번역한 콘텐츠입니다.