요약: 클라우드 네이티브 앱 설계
팁
이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 eBook 에서 발췌한 것으로, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.
요약하면, 이 가이드의 중요한 결론은 다음과 같습니다.
클라우드 네이티브는 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 최신 동적 환경에서 빠른 변화, 대규모 스케일링 및 복원력을 수용하는 최신 애플리케이션을 설계하는 것과 관련이 있습니다.
CNCF(Cloud Native Computing Foundation)는 300개가 넘는 주요 기업의 영향력 있는 오픈 소스 컨소시엄입니다. 기술 및 클라우드 스택에서 클라우드 네이티브 컴퓨팅의 채택을 유도하는 작업을 담당합니다.
CNCF 지침에 따르면 클라우드 네이티브 애플리케이션은 그림 11-1과 같이 6가지 중요한 핵심 요소를 수용하는 것이 좋습니다.
그림 11-1. 클라우드 네이티브 기본 핵심 요소
이 클라우드 네이티브 핵심 요소는 다음과 같습니다.
- 클라우드 및 해당 기본 서비스 모델
- 최신 디자인 원칙
- 마이크로 서비스
- 컨테이너화 및 컨테이너 오케스트레이션
- 데이터베이스 및 메시지 broker와 같은 클라우드 기반 지원 서비스
- IaC(Infrastructure as Code) 및 코드 배포를 포함한 자동화
Kubernetes는 대부분의 클라우드 네이티브 애플리케이션에서 선택하는 호스팅 환경입니다. 더 작고 간단한 서비스는 Azure Functions 같은 서버리스 플랫폼에서 호스트되는 경우도 있습니다. 많은 주요 자동화 기능 중에서 두 환경은 모두 변동하는 워크로드 볼륨을 처리하기 위한 자동 스케일링을 제공합니다.
서비스 통신은 클라우드 네이티브 애플리케이션을 생성할 때 중요한 디자인 결정이 됩니다. 애플리케이션은 일반적으로 프런트 엔드 클라이언트 통신을 관리하기 위해 API 게이트웨이를 노출합니다. 그런 다음, 백 엔드 마이크로 서비스는 가능한 경우 비동기 통신 패턴을 구현하여 서로 통신하려고 노력합니다.
gRPC는 오래된 RPC(원격 프로시저 호출) 프로토콜을 발전시키는 최신 고성능 프레임워크입니다. 클라우드 네이티브 애플리케이션은 종종 gRPC를 수용하여 백 엔드 서비스 간 메시징을 간소화합니다. gRPC는 전송 프로토콜에 HTTP/2를 사용합니다. 메시지 크기가 60~80% 더 작은 JSON serialization보다 최대 8배 더 빠를 수 있습니다. gRPC는 오픈 소스이며 CNCF(Cloud Native Computing Foundation)에서 관리합니다.
분산 데이터는 클라우드 네이티브 애플리케이션에서 구현하는 모델입니다. 애플리케이션은 비즈니스 기능을 작고 독립적인 마이크로 서비스로 구분합니다. 각 마이크로 서비스는 자체 종속성, 데이터 및 상태를 캡슐화합니다. 클래식 공유 데이터베이스 모델은 각각 마이크로 서비스에 맞춰 여러 개의 작은 데이터베이스 중 하나로 발전합니다. 연기가 사라지면
database-per-microservice모델을 노출하는 디자인으로 등장합니다.NoSQL 데이터베이스는 고성능 비관계형 데이터 저장소를 나타냅니다. 사용 편의성, 스케일링 기능, 복원력 및 가용성이 탁월합니다. 1초 미만의 응답 시간이 필요한 대용량 서비스는 NoSQL 데이터 저장소를 선호합니다. 분산 클라우드 네이티브 시스템에 대한 NoSQL 기술 확산은 상당할 수 있습니다.
NewSQL은 NoSQL의 분산 스케일링 가능성과 관계형 데이터베이스의 ACID 보장을 결합한 새로운 데이터베이스 기술입니다. NewSQL 데이터베이스는 완전한 트랜잭션/ACID 규정 준수를 통해 분산 환경에서 대량의 데이터를 처리해야 하는 비즈니스 시스템을 대상으로 합니다. CNCF(Cloud Native Computing Foundation)는 여러 NewSQL 데이터베이스 프로젝트를 제공합니다.
복원력은 시스템이 오류에 대응하고 계속 작동할 수 있게 하는 기능입니다. 클라우드 네이티브 시스템은 오류가 불가피한 분산 아키텍처를 수용합니다. 애플리케이션은 오류에 원활하게 대응하고 완전히 작동하는 상태로 빠르게 돌아가도록 구성되어야 합니다.
서비스 메시는 서비스 통신 및 기타 교차 편집 문제를 처리하는 기본 제공 기능을 갖춘 구성 가능한 인프라 계층입니다. 비즈니스 코드에서 교차 편집 책임을 분리합니다. 이 책임은 서비스 프록시로 이동합니다.
Sidecar pattern이라고도 하는 프록시는 비즈니스 코드에서 격리를 제공하기 위해 별도의 프로세스에 배포됩니다.가시성은 클라우드 네이티브 애플리케이션에 대한 주요 디자인 고려 사항입니다. 서비스가 노드 클러스터에 분산되면 중앙 집중식 로깅, 모니터링 및 경고는 필수가 됩니다. Azure Monitor는 시스템 상태에 대한 가시성을 제공하도록 디자인된 클라우드 기반 도구 컬렉션입니다.
IaC(Infrastructure as Code)는 플랫폼 프로비저닝을 자동화하는 널리 사용되는 사례입니다. 인프라 및 배포는 자동화되고, 일관되며, 반복 가능합니다. Azure Resource Manager, Terraform 및 Azure CLI와 같은 도구를 사용하면 필요한 클라우드 인프라를 선언적으로 스크립팅할 수 있습니다.
코드 자동화는 클라우드 네이티브 애플리케이션에 대한 요구 사항입니다. 최신 CI/CD 시스템은 이 원칙을 충족하는 데 도움이 될 수 있습니다. 일관되고 품질이 우수한 코드를 보장하는 데 도움이 되는 별도의 빌드 및 배포 단계를 제공합니다. 빌드 단계는 코드를 이진 아티팩트로 변환합니다. 릴리스 단계에서는 이진 아티팩트를 선택하고, 외부 환경 구성을 적용하고, 지정된 환경에 배포합니다. Azure DevOps 및 GitHub는 전체 기능을 갖춘 DevOps 환경입니다.
.NET