Aspire를 사용한 Runtime과 Observability

Aspire로 실행

AppHost는 솔루션의 로컬 실행을 한곳에 모읍니다. 서비스, web apps, PostgreSQL, Redis, RabbitMQ, workers 같은 의존성을 시작합니다.

dotnet run --project src/Aspire/AppHost/<ProjectName>.AppHost.csproj

dashboard를 사용해 logs, 변수, endpoints, 리소스 상태를 확인합니다. 서비스가 시작되지 않으면 AppHost와 AppHost가 주입하는 의존성부터 확인하십시오.

Aspire는 로컬 토폴로지를 보이게 합니다. APIs, web apps, 데이터베이스, cache, message broker, workers가 관련 리소스로 표시됩니다. 이 뷰는 잘못된 connection string, 누락된 파라미터, endpoint가 없는 서비스, 아직 시작되지 않은 의존성처럼 수동 실행에서는 숨겨질 수 있는 설정 오류를 찾는 데 도움이 됩니다.

• Logs: 초기화 오류, 인증 실패, migrations 문제, worker 메시지를 추적합니다.
• Endpoints: 포트, URLs, health checks, web apps 및 APIs 링크를 확인합니다.
• Parameters: 각 서비스로 전파되는 secrets와 변수를 검증합니다.
• Dependencies: 애플리케이션을 진단하기 전에 Redis, RabbitMQ, 데이터베이스가 provision 되었는지 확인합니다.

데이터베이스 리소스

Lino가 생성한 서비스는 일반적으로 자체 DbContexts, migrations, connection strings를 가집니다. 모듈형 시스템에서는 각 모듈이 예상한 데이터베이스/schema를 사용하는지, migrations가 올바른 위치에 적용되었는지 검증하십시오.

• 환경별 connection strings를 확인합니다.
• 새 schema에 의존하는 흐름을 테스트하기 전에 migrations를 실행합니다.
• 연결 실패와 query 시간을 모니터링합니다.
• 로컬 실행에서 운영 데이터베이스를 사용하지 마십시오.

단순한 서비스에서는 데이터베이스가 서비스를 따릅니다. 모듈형 서비스에서는 데이터베이스가 서비스에 속하지만, 각 모듈은 자체 schema, DbContext, migrations, scripts를 가질 수 있습니다. 이 분리는 운영에도 드러나야 합니다. migrations를 적용할 때는 실행 전에 서비스, 모듈, provider, 환경을 확인하십시오.

데이터베이스 장애는 보통 API 오류로 나타나지만, 원인은 AppHost, connection string, 보류 중인 migration, 존재하지 않는 schema 또는 로컬 자격 증명에 있을 수 있습니다. 따라서 진단은 전체 체인에서 시작해야 합니다. Aspire 파라미터, 활성 데이터베이스 리소스, 적용된 migration, 올바른 DbContext, 예상한 모듈을 호출하는 endpoint입니다.

Redis와 cache

Redis는 활성화된 templates에 따라 cache, 임시 상태, tokens, rate limiting 또는 기타 리소스에 사용할 수 있습니다. cache는 성능을 높이지만 invalidation과 eventual consistency를 도입합니다.

키, 만료 시간, 데이터 출처를 문서화하십시오. 암호화, 만료, 접근 방식을 이해하지 못한 상태에서 민감한 secrets를 cache에 저장하지 마십시오.

프로젝트가 분산 cache를 사용하면 여러 인스턴스가 값을 공유할 수 있어 수평 확장에 유용합니다. 로컬 인메모리 cache만 사용하는 경우 각 프로세스는 자체 복사본을 유지합니다. 이 차이는 운영 환경 동작, 부하 테스트, 데이터 invalidation에 영향을 줍니다.

RabbitMQ와 messaging

messaging은 integration events와 비동기 통신을 뒷받침합니다. Outbox를 사용하면 애플리케이션이 트랜잭션과 같은 순간에 메시지를 publish하는 것에 의존하지 않으며, worker가 다시 시도할 수 있습니다.

• 생성된 exchanges, queues, bindings를 확인합니다.
• 멈춘 메시지와 비활성 consumers를 모니터링합니다.
• idempotent한 handlers를 설계합니다.
• correlation logs를 사용해 메시지 경로를 따라갑니다.

integration events가 유용한 이유는 producer가 모든 consumers를 기다릴 필요가 없기 때문입니다. 하지만 이로 인해 복잡성의 일부가 운영으로 이동합니다. 메시지는 지연될 수 있고, consumers는 실패할 수 있으며, payloads는 변경될 수 있고, handlers는 두 번 이상 실행될 수 있습니다. 흐름 문서는 어떤 event가 publish되는지, 누가 consume하는지, 어떤 로컬 상태가 업데이트되는지 명확히 해야 합니다.

Shadow Entities는 이러한 observability에 의존합니다. tenant 또는 사용자 entity가 event로 다른 모듈에 복제되는 경우 consumer 실패로 로컬 복사본이 오래된 상태로 남을 수 있습니다. 시스템은 event, 메시지, handler, consumer 모듈 데이터베이스에서 수행된 업데이트를 진단할 수 있어야 합니다.

Hangfire Dashboard

background jobs가 활성화되어 있으면 Hangfire Dashboard는 반복 jobs, 실패, retries, Outbox 처리 실행을 검사하는 데 도움이 됩니다.

공유 환경에서는 dashboard를 보호하십시오. 관련 운영 정보를 노출하므로 인증과 권한 부여 없이 공개되어서는 안 됩니다.

dashboard를 진단 도구로 사용하되 logs와 metrics의 대체물로 사용하지 마십시오. queues, 시도 횟수, 실행 이력을 보여 주지만, job이 실패한 이유를 완전히 조사하려면 correlation id, 구조화된 logs, 비즈니스 컨텍스트가 여전히 필요합니다.

• Retries: 실패가 일시적인지, 또는 job이 계속 실패할 것인지 확인합니다.
• 반복 jobs: 간격, 배치, 평균 실행 시간을 확인합니다.
• Outbox: 멈춘 메시지, 재처리, 예외가 발생한 handlers를 관찰합니다.
• Security: payloads와 오류가 민감한 데이터를 드러낼 수 있으므로 접근을 제한합니다.

Workers와 백그라운드 처리

Workers는 HTTP 요청을 차단해서는 안 되는 작업을 실행합니다. 메시지 전송, Outbox 처리, 정리, 동기화, 외부 통합 등이 여기에 해당합니다.

• 볼륨에 맞는 배치를 사용합니다.
• retries와 실패 처리를 정의합니다.
• 재처리에 충분한 컨텍스트와 함께 오류를 기록합니다.
• 영구적인 실패를 일반적인 logs에 숨기지 마십시오.

worker를 추가할 때는 빈도, 배치 크기, 실패 시 동작, 도메인 영향도 함께 정의하십시오. 몇 초마다 100개 레코드를 읽는 worker는 일일 job과 다른 운영 특성을 가집니다. 둘 다 실제 볼륨에 따라 관찰하고 크기를 조정해야 합니다.

사용자에게 즉시 응답해야 하는 작업을 background에서 실행하지 마십시오. worker는 후속 작업, 통합, 알림, 재처리, 유지보수에 사용하십시오. 유스케이스가 트랜잭션 완료를 위해 결과에 의존한다면 동기 흐름으로 처리하거나 사용자에게 보이는 중간 상태를 모델링하십시오.