다음을 통해 공유

Azure Kubernetes Service의 마이크로 서비스 아키텍처

Microsoft Entra ID
Azure Container Registry
AKS(Azure Kubernetes Service)
Azure Load Balancer
Azure Pipelines
Azure Monitor

이 참조 아키텍처는 AKS(Azure Kubernetes Service)에 배포된 마이크로 서비스 애플리케이션을 보여 줍니다. 대부분의 배포의 시작점으로 사용할 수 있는 기본 AKS 구성에 대해 설명합니다. 이 문서에서는 Kubernetes에 대한 기본적인 이해가 있다고 가정합니다. 이 문서에서는 주로 AKS에서 마이크로 서비스를 관리하는 방법의 인프라 및 DevOps 측면을 강조 표시합니다. 마이크로 서비스를 디자인하는 방법에 대한 자세한 내용은 마이크로 서비스 아키텍처 디자인을 참조하세요.

GitHub 로고. 이 아키텍처의 참조 구현은 GitHub에서 사용할 수 있습니다.

아키텍처

AKS 참조 아키텍처의 마이크로 서비스를 보여 주는 다이어그램

Helm은 CNCF(Cloud Native Computing Foundation)의 상표입니다. 이 상표의 사용은 어떠한 보증도 의미하지 않습니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

AKS 기준 아키텍처를 기반으로 하는 고급 마이크로 서비스의 예를 보려면 고급 AKS 마이크로 서비스 아키텍처를 참조하세요.

워크플로

이 요청 흐름은 게시자-구독자, 경쟁 소비자 및 게이트웨이 라우팅 클라우드 디자인 패턴을 구현합니다.

다음 데이터 흐름은 이전 다이어그램에 해당합니다.

  1. 클라이언트 애플리케이션은 HTTPS를 통해 부하 분산 장치(관리되는 수신 컨트롤러)의 퍼블릭 정규화된 도메인 이름으로 JSON 페이로드를 전송하여 드론 픽업을 예약합니다.

    • 관리되는 수신 컨트롤러는 요청을 수집 마이크로 서비스로 라우팅합니다.

    • 수집 마이크로 서비스는 요청을 처리하고 Azure Service Bus 큐에서 배달 요청을 큐에 대기합니다.

  2. 워크플로 마이크로 서비스:

    • Service Bus 메시지 큐의 메시지 정보를 사용합니다.

    • Azure Cache for Redis의 외부 데이터 스토리지에 데이터를 전달하는 배달 마이크로 서비스에 HTTPS 요청을 보냅니다.

    • 드론 스케줄러 마이크로 서비스에 HTTPS 요청을 보냅니다.

    • MongoDB의 외부 데이터 스토리지에 데이터를 전달하는 패키지 마이크로 서비스에 HTTPS 요청을 보냅니다.

  3. HTTPS GET 요청은 배달 상태를 반환합니다. 이 요청은 관리되는 수신 컨트롤러를 통해 배달 마이크로 서비스로 전달됩니다. 그런 다음 배달 마이크로 서비스는 Azure Cache for Redis에서 데이터를 읽습니다.

샘플 마이크로 서비스 애플리케이션에 대한 자세한 내용은 마이크로 서비스 참조 구현 샘플을 참조하세요.

구성 요소

  • AKS 는 Azure 클라우드에서 호스트되는 관리되는 Kubernetes 클러스터입니다. AKS는 대부분의 부담을 Azure에 오프로딩하여 Kubernetes를 관리하는 복잡성 및 운영 과부하를 감소시킵니다.

  • 수신 서버는 클러스터 내의 서비스에 HTTP(S) 경로를 노출합니다. 참조 구현은 애플리케이션 라우팅 추가 기능을 통해 관리되는 NGINX 기반 수신 컨트롤러 를 사용합니다. 수신 컨트롤러는 마이크로 서비스에 대한 API 게이트웨이 패턴을 구현합니다.

  • Azure SQL Database 또는 Azure Cosmos DB와 같은 외부 데이터 저장소는 상태 비저장 마이크로 서비스에서 해당 데이터 및 기타 상태 정보를 작성하는 데 사용됩니다. 참조 구현에서는 Azure Cosmos DB, Azure Cache for Redis, MongoDB용 Azure Cosmos DB 및 Service Bus 를 데이터 저장소 또는 상태를 저장할 위치로 사용합니다.

  • AKS 클러스터에는 Microsoft Entra ID가 필요합니다. Azure Container Registry에 액세스하고 부하 분산 장치 및 관리 디스크와 같은 Azure 리소스에 액세스하고 프로비전하는 데 사용되는 관리 ID 를 제공합니다. AKS 클러스터에 배포된 워크로드에는 각각 Microsoft Entra의 ID가 있어야 Azure Key Vault 및 Microsoft Graph와 같은 Microsoft Entra로 보호되는 리소스에 액세스할 수 있습니다. 이 참조 아키텍처에서 Microsoft Entra 워크로드 ID 는 Kubernetes와 통합되고 워크로드에 ID를 제공합니다. 각 워크로드에 대해 관리 ID 또는 애플리케이션 자격 증명을 사용할 수도 있습니다.

  • 컨테이너 레지스트리를 사용하여 클러스터에 배포되는 프라이빗 컨테이너 이미지를 저장할 수 있습니다. AKS는 Microsoft Entra ID를 사용하여 Container Registry로 인증할 수 있습니다. 참조 구현에서 마이크로 서비스 컨테이너 이미지는 빌드되고 Container Registry에 푸시됩니다.

  • Azure Pipelines 는 Azure DevOps 제품군의 일부이며 자동화된 빌드, 테스트 및 배포를 실행합니다. CI/CD(지속적인 통합 및 지속적인 배포) 접근 방식은 마이크로 서비스 환경에서 매우 권장됩니다. 다양한 팀은 Azure Pipelines를 사용하여 AKS에 마이크로 서비스를 독립적으로 빌드하고 배포할 수 있습니다.

  • Helm 은 Kubernetes 개체를 게시, 배포, 버전 관리 및 업데이트할 수 있는 단일 단위로 번들하고 표준화하는 메커니즘을 제공하는 Kubernetes의 패키지 관리자입니다.

  • Azure Monitor는 Azure 서비스에 대한 메트릭 및 로그, 애플리케이션 원격 분석 및 플랫폼 메트릭을 수집하고 저장합니다. Azure Monitor는 AKS와 통합되어 컨트롤러, 노드, 컨테이너의 메트릭을 수집합니다.

  • Application Insights는 마이크로 서비스 및 컨테이너를 모니터링합니다. 트래픽 흐름, 엔드 투 엔드 대기 시간 및 오류 비율을 포함하는 마이크로 서비스에 대한 관찰 가능성을 제공하는 데 사용할 수 있습니다. 마이크로 서비스의 상태와 마이크로 서비스 간의 관계는 단일 애플리케이션 맵에 표시될 수 있습니다.

대안

Azure Container Apps 는 관리형 서버리스 Kubernetes 환경을 제공합니다. Kubernetes 또는 해당 API에 직접 액세스할 필요가 없고 클러스터 인프라를 제어할 필요가 없는 경우 마이크로 서비스를 호스팅하기 위한 AKS의 간단한 대안으로 사용됩니다.

AKS에서 관리되는 수신 게이트웨이 대신 컨테이너용 Application Gateway, Istio 수신 게이트웨이 또는 비 Microsoft 솔루션과 같은 대안을 사용할 수 있습니다. 자세한 내용은 AKS의 수신을 참조하세요.

Docker Hub와 같은 비 Microsoft 컨테이너 레지스트리에 컨테이너 이미지를 저장할 수 있습니다.

상태 정보를 유지해야 하는 마이크로 서비스의 경우 Dapr 은 마이크로 서비스 상태를 관리하기 위한 추상화 계층을 제공합니다.

GitHub Actions를 사용하여 마이크로 서비스를 빌드 및 배포하거나 Jenkins와 같은 비 Microsoft CI/CD 솔루션을 선택할 수 있습니다.

Kiali와 같은 대체 도구를 사용하여 마이크로 서비스 관찰성을 달성할 수 있습니다.

시나리오 세부 정보

예제 마이크로 서비스 참조 구현은 이 문서에 설명된 아키텍처 구성 요소 및 사례를 구현합니다. 이 예제에서는 Fabrikam, Inc.라는 가상의 회사가 드론 항공기의 함대를 관리합니다. 기업은 서비스에 등록하고 사용자는 배달을 위해 드론이 상품을 픽업하도록 요청할 수 있습니다. 고객이 픽업을 예약할 때 백 엔드 시스템은 드론을 할당하고 예상 배달 시간을 사용자에게 알깁니다. 배달이 진행 중인 경우 고객은 지속적으로 업데이트된 예상 배달 시간으로 드론의 위치를 추적할 수 있습니다.

이 시나리오는 AKS의 마이크로 서비스 아키텍처 및 배포 모범 사례를 보여 주는 것을 목표로 합니다.

잠재적인 사용 사례

시나리오에서 다음 모범 사례를 채택하여 AKS에서 복잡한 마이크로 서비스 기반 애플리케이션을 설계합니다.

  • 복잡한 웹 애플리케이션
  • 마이크로 서비스 디자인 원칙을 사용하여 개발된 비즈니스 논리

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework참조하세요.

디자인

이 참조 아키텍처는 마이크로 서비스에 중점을 두지만 AKS에서 실행되는 다른 워크로드에는 많은 권장 사례가 적용됩니다.

마이크로 서비스

마이크로 서비스는 느슨하게 결합되며, 독립적으로 배포 가능한 코드 단위입니다. 마이크로 서비스는 일반적으로 잘 정의된 API를 통해 통신하며, 특정 형태의 서비스 검색을 통해 검색할 수 있습니다. Kubernetes 서비스 개체는 Kubernetes에서 마이크로 서비스를 모델링하는 일반적인 방법입니다.

데이터 스토리지

마이크로 서비스 아키텍처에서 서비스는 데이터 스토리지 솔루션을 공유해서는 안 됩니다. 각 서비스는 서비스 간의 숨겨진 종속성을 방지하기 위해 자체 데이터 세트를 관리해야 합니다. 데이터 분리는 서비스 간의 의도하지 않은 결합을 방지하는 데 도움이 됩니다. 이 프로세스는 서비스가 동일한 기본 데이터 스키마를 공유하는 경우에 발생할 수 있습니다. 서비스에서 자체 데이터 저장소를 관리하는 경우 특정 요구 사항에 대해 올바른 데이터 저장소를 사용할 수 있습니다. 자세한 내용은 마이크로 서비스에 대한 데이터 고려 사항을 참조하세요.

해당 메서드가 데이터를 노드에 바인딩하므로 로컬 클러스터 스토리지에 영구 데이터를 저장하지 않습니다. 대신 SQL Database 또는 Azure Cosmos DB와 같은 외부 서비스를 사용합니다. 또 다른 옵션은 Azure Disk Storage 또는 Azure Files를 사용하여 솔루션에 영구 데이터 볼륨을 탑재하는 것입니다. 자세한 내용은 AKS애플리케이션에 대한 Storage 옵션을 참조하세요.

API 게이트웨이

API 게이트웨이는 일반적인 마이크로 서비스 설계 패턴입니다. API 게이트웨이는 외부 클라이언트와 마이크로 서비스 사이에 있습니다. 게이트웨이는 역방향 프록시 역할을 하며 클라이언트에서 마이크로 서비스로 요청을 라우팅합니다. API 게이트웨이는 인증, SSL(Secure Sockets Layer) 종료 및 속도 제한과 같은 다양한 교차 절단 작업을 수행할 수도 있습니다. 자세한 내용은 다음 리소스를 참조하세요.

Kubernetes에서 수신 컨트롤러는 주로 API 게이트웨이의 기능을 처리합니다. 수신 및 수신 컨트롤러는 다음과 함께 작동합니다.

  • 클라이언트 요청을 올바른 백 엔드 마이크로 서비스로 라우팅합니다. 이 라우팅은 클라이언트에 대한 단일 엔드포인트를 제공하고 서비스에서 클라이언트를 분리하는 데 도움이 됩니다.

  • 클라이언트와 백 엔드 간의 수다를 줄이기 위해 여러 요청을 단일 요청으로 집계합니다.

  • SSL 종료, 인증, IP 주소 제한 또는 클라이언트 속도 제한( 제한이라고 함)과 같은 백 엔드 서비스에서 기능을 오프로드합니다.

NGINX, HAProxy, Traefik 및 Azure Application Gateway를 포함하는 역방향 프록시에 대한 수신 컨트롤러가 있습니다. AKS는 여러 관리되는 수신 옵션을 제공합니다. 애플리케이션 라우팅 추가 기능인 Application Gateway for Containers를 통해 관리되는 NGINX 기반 수신 컨트롤러 중에서 선택할 수 있습니다. 또는 Istio 수신 게이트웨이를 수신 컨트롤러로 선택할 수 있습니다. 자세한 내용은 AKS의 수신을 참조하세요.

수신 리소스 Kubernetes 개체는 보다 고급적이고 다양한 Kubernetes Gateway API로 대체되었습니다. 수신 컨트롤러 및 게이트웨이 API는 모두 트래픽 관리 라우팅 및 부하 분산에 사용되는 Kubernetes 개체입니다. 일반적이고 표현적이며 확장 가능하며 역할 지향적으로 설계된 게이트웨이 API는 Kubernetes에서 L4 및 L7 라우팅 규칙을 정의하기 위한 최신 API 집합입니다.

수신 컨트롤러는 에지 라우터 또는 역방향 프록시로 작동합니다. 역방향 프록시 서버는 잠재적인 병목 상태 또는 단일 실패 지점이므로 고가용성을 보장하기 위해 두 개 이상의 복제본을 배포하는 것이 좋습니다.

수신 컨트롤러 또는 게이트웨이 API를 선택하는 경우

수신 리소스는 다음 사용 사례에 적합합니다.

  • 수신 컨트롤러는 쉽게 설정할 수 있으며 간편한 구성의 우선 순위를 지정하는 더 작고 덜 복잡한 Kubernetes 배포에 적합합니다.

  • 현재 Kubernetes 클러스터에 수신 컨트롤러가 구성되어 있고 요구 사항을 효과적으로 충족하는 경우 Kubernetes Gateway API로 즉시 전환할 필요가 없을 수 있습니다.

게이트웨이 API를 사용해야 합니다.

  • 복잡한 라우팅 구성, 트래픽 분할 및 고급 트래픽 관리 전략을 처리하는 경우 Kubernetes Gateway API의 경로 리소스에서 제공하는 유연성은 필수적입니다.

  • 네트워킹 요구 사항에 사용자 지정 솔루션 또는 비 Microsoft 플러그 인의 통합이 필요한 경우 사용자 지정 리소스 정의를 기반으로 하는 Kubernetes Gateway API의 접근 방식은 향상된 확장성을 제공할 수 있습니다.

신뢰도

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.

마이크로 서비스 분할

네임스페이스를 사용하여 클러스터 내에서 서비스 구성합니다. Kubernetes 클러스터의 모든 개체는 네임스페이스에 속합니다. 네임스페이스를 사용하여 클러스터에서 리소스를 구성하는 것이 좋습니다.

네임스페이스는 이름 충돌을 방지하는 데 도움이 됩니다. 여러 팀이 동일한 클러스터에 수백 개의 마이크로 서비스를 배포하고 모든 마이크로 서비스가 동일한 네임스페이스로 이동하면 관리가 어렵습니다. 네임스페이스를 사용하면 다음을 수행할 수도 있습니다.

  • 네임스페이스에 할당된 총 Pod 집합이 네임스페이스의 리소스 할당량을 초과할 수 없도록 네임스페이스에 리소스 제약 조건을 적용합니다.

  • RBAC(역할 기반 액세스 제어) 및 보안 정책을 포함하는 네임스페이스 수준에서 정책을 적용합니다.

여러 팀이 마이크로 서비스를 개발하고 배포하는 경우 네임스페이스를 편리한 메커니즘으로 사용하여 각 팀이 배포할 수 있는 영역을 제어할 수 있습니다. 예를 들어 개발 팀 A는 네임스페이스 A에만 액세스 권한을 부여할 수 있으며, 개발 팀 B는 Kubernetes RBAC 정책을 통해 네임스페이스 B에 대한 액세스 권한만 부여할 수 있습니다.

마이크로 서비스 아키텍처의 경우 마이크로 서비스를 제한된 컨텍스트로 구성하고 각 바인딩된 컨텍스트에 대한 네임스페이스를 만드는 것이 좋습니다. 예를 들어 "주문 처리" 바인딩된 컨텍스트와 관련된 모든 마이크로 서비스는 동일한 네임스페이스로 전환될 수 있습니다. 또는 개발 팀마다 네임스페이스를 만듭니다.

각 개발 팀의 자체 별도 네임스페이스에 유틸리티 서비스를 배치합니다. 예를 들어 Elasticsearch 및 Prometheus와 같은 클러스터 모니터링 도구를 모니터링 네임스페이스에 배포할 수 있습니다.

상태 프로브

Kubernetes는 Pod가 노출할 수 있는 세 가지 유형의 상태 프로브를 정의합니다.

  • 준비 상태 프로브: Pod가 요청을 수락할 준비가 되었는지 여부를 Kubernetes에 알릴 수 있습니다.

  • 활동성 프로브: Pod를 제거하고 새 인스턴스를 시작해야 하는지 여부를 Kubernetes에 알릴 수 있습니다.

  • 시작 프로브: Pod가 시작되었는지 여부를 Kubernetes에 알릴 수 있습니다.

프로브에 대해 생각할 때 Kubernetes에서 서비스가 작동하는 방식을 기억하는 것이 중요합니다. 서비스에는 0개 이상의 Pod 집합과 일치하는 레이블 선택기가 있습니다. Kubernetes는 선택기와 일치하는 Pod에 트래픽을 부하 분산합니다. 성공적으로 시작되고 정상 상태인 Pod만 트래픽을 수신합니다. 컨테이너가 충돌하는 경우 Kubernetes는 Pod를 종료하고 교체를 예약합니다.

Pod가 성공적으로 시작되었음에도 불구하고 트래픽을 수신할 준비가 되지 않은 경우가 있습니다. 예를 들어 컨테이너에서 실행 중인 애플리케이션이 메모리에 데이터를 로드하거나 구성 파일을 읽는 경우와 같은 초기화 작업이 진행 중일 수 있습니다. 이러한 느린 시작 컨테이너에 대해 시작 프로브를 사용할 수 있습니다. 이 방법을 사용하면 Kubernetes가 완전히 초기화되기 전에 종료되지 않도록 방지할 수 있습니다.

활동성 프로브는 Pod가 실행 중이지만 제대로 작동하지 않고 다시 시작해야 하는지 확인하는 데 사용됩니다. 예를 들어 컨테이너가 HTTP 요청을 처리하지만 충돌하지 않고 갑자기 응답을 중지하는 경우 활동성 프로브는 이 이벤트를 감지하고 Pod의 다시 시작을 트리거합니다. 활동성 프로브를 설정하는 경우 컨테이너가 응답하지 않을 때를 확인하고 컨테이너가 프로브에 반복적으로 실패하는 경우 Kubernetes에 Pod를 다시 시작하라는 메시지를 표시합니다.

마이크로 서비스에 대한 프로브를 디자인할 때 다음 사항을 고려합니다.

  • 코드에 시작 시간이 긴 경우 시작이 완료되기 전에 활동성 프로브가 실패를 보고할 위험이 있습니다. 활동성 프로브의 시작을 지연하려면 시작 프로브를 사용하거나 활동성 프로브와 함께 설정을 사용합니다 initialDelaySeconds .

  • 활동성 프로브는 Pod를 다시 시작하면 정상 상태로 복원할 수 있는 경우에만 도움이 됩니다. 활동성 프로브를 사용하여 메모리 누수 또는 예기치 않은 교착 상태를 완화할 수 있지만 즉시 다시 실패할 Pod를 다시 시작할 이유가 없습니다.

  • 때때로 준비 상태 프로브는 종속 서비스를 확인하는 데 사용됩니다. 예를 들어 Pod가 데이터베이스에 종속된 경우 프로브가 데이터베이스 연결을 확인할 수 있습니다. 그러나 이 방법은 예기치 않은 문제를 일으킬 수 있습니다. 외부 서비스를 일시적으로 사용할 수 없을 수 있습니다. 이 사용 불가로 인해 서비스의 모든 Pod에 대해 준비 상태 프로브가 실패하여 부하 분산에서 제거됩니다. 이 제거는 업스트림에서 연속 실패를 만듭니다.

    더 나은 방법은 서비스가 일시적인 오류로부터 올바르게 복구할 수 있도록 서비스 내에서 재시도 처리를 구현하는 것입니다. 또는 Istio 서비스 메시 에서 재시도 처리, 오류 허용 오차 및 회로 차단기를 구현하여 마이크로 서비스 오류를 처리할 수 있는 복원력 있는 아키텍처를 만들 수 있습니다.

리소스 제약 조건

리소스 경합은 서비스의 가용성에 영향을 줄 수 있습니다. 단일 컨테이너가 메모리 및 CPU와 같은 클러스터 리소스를 압도할 수 없도록 컨테이너에 대한 리소스 제약 조건을 정의합니다. 스레드 또는 네트워크 연결과 같은 비 컨테이너 리소스의 경우 Bulkhead 패턴을 사용하여 리소스를 격리하는 것이 좋습니다.

리소스 할당량을 사용하여 네임스페이스에 허용되는 총 리소스를 제한합니다. 이 제한은 프런트 엔드가 리소스에 대한 백 엔드 서비스를 굶어 버릴 수 없도록 하거나 그 반대의 경우도 마찬가지입니다. 리소스 할당량은 동일한 클러스터 내의 리소스를 여러 마이크로 서비스 개발 팀에 할당하는 데 도움이 될 수 있습니다.

보안

보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안대한 디자인 검토 검사 목록을 참조하세요.

TLS 및 SSL 암호화

많은 구현에서 수신 컨트롤러는 SSL 종료에 사용됩니다. 수신 컨트롤러 배포의 일부로 TLS(전송 계층 보안) 인증서를 만들거나 가져와야 합니다. 개발 및 테스트 목적으로 자체 서명된 인증서만 사용합니다. 자세한 내용은 애플리케이션 라우팅 추가 기능을 사용하여 사용자 지정 도메인 이름 및 SSL 인증서 설정을 참조하세요.

프로덕션 워크로드의 경우 신뢰할 수 있는 인증 기관에서 서명된 인증서를 가져옵니다.

조직의 정책에 따라 인증서를 회전해야 할 수도 있습니다. Key Vault를 사용하여 마이크로 서비스에서 사용하는 인증서를 회전할 수 있습니다. 자세한 내용은 Key Vault에서 인증서 자동 회전 구성을 참조하세요.

RBAC

여러 팀이 동시에 마이크로 서비스를 개발하고 배포하는 경우 AKS RBAC 메커니즘은 사용자 작업의 세부적인 제어 및 필터링을 제공할 수 있습니다. Microsoft Entra ID와 함께 Kubernetes RBAC 또는 Azure RBAC를 사용하여 클러스터 리소스에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 AKS에 대한 액세스 및 ID 옵션을 참조하세요.

인증 및 권한 부여

마이크로 서비스는 사용하는 서비스 또는 사용자가 인증서, 자격 증명 및 RBAC 메커니즘을 사용하여 마이크로 서비스에 대한 액세스를 인증하고 권한을 부여하도록 요구할 수 있습니다. Microsoft Entra ID를 사용하여 권한 부여를 위한 OAuth 2.0 토큰을 구현할 수 있습니다. 또한 Istio와 같은 서비스 메시는 OAuth 토큰 유효성 검사 및 토큰 기반 라우팅을 포함하는 마이크로 서비스에 대한 권한 부여 및 인증 메커니즘을 제공합니다. 참조 구현은 마이크로 서비스 인증 및 권한 부여 시나리오를 다루지 않습니다.

비밀 관리 및 애플리케이션 자격 증명

애플리케이션 및 서비스가 Azure Storage 또는 SQL Database 같은 외부 서비스에 연결할 수 있는 자격 증명이 필요한 경우가 종종 있습니다. 문제는 이러한 자격 증명이 유출되지 않도록 안전하게 보호하는 것입니다.

Azure 리소스의 경우 가능하면 관리 ID를 사용합니다. 관리 ID는 Microsoft Entra ID에 저장된 애플리케이션 또는 서비스의 고유 ID와 같습니다. 이 ID를 사용하여 Azure 서비스를 인증합니다. 애플리케이션 또는 서비스에는 Microsoft Entra ID로 만든 서비스 주체가 있으며 OAuth 2.0 토큰을 사용하여 인증합니다. 프로세스 내에서 실행되는 코드는 토큰을 투명하게 가져올 수 있습니다. 이 방법은 암호 또는 연결 문자열을 저장할 필요가 없도록 하는 데 도움이 됩니다. 관리 ID를 사용하려면 Microsoft Entra 워크로드 ID를 사용하여 AKS의 개별 Pod에 Microsoft Entra ID를 할당할 수 있습니다.

관리 ID를 사용하는 경우에도 일부 자격 증명 또는 다른 애플리케이션 비밀을 저장해야 할 수 있습니다. 이 스토리지는 관리 ID, 타사 서비스 또는 API 키를 지원하지 않는 Azure 서비스에 필요합니다. 다음 옵션을 사용하여 비밀을 보다 안전하게 저장할 수 있습니다.

Key Vault와 같은 솔루션을 사용하면 다음을 비롯한 몇 가지 이점이 있습니다.

  • 비밀을 중앙에서 제어할 수 있습니다.
  • 모든 비밀이 미사용 시 암호화되도록 지원합니다.
  • 키를 중앙에서 관리합니다.
  • 비밀 액세스를 제어할 수 있습니다.
  • 키 수명 주기 관리.
  • 감사.

참조 구현은 Key Vault에 Azure Cosmos DB 연결 문자열 및 기타 비밀을 저장합니다. 참조 구현은 마이크로 서비스에 대한 관리 ID를 사용하여 Key Vault에 인증하고 비밀에 액세스합니다.

컨테이너 및 오케스트레이터 보안

다음 권장 사례는 Pod 및 컨테이너를 보호하는 데 도움이 될 수 있습니다.

  • 위협을 모니터링합니다. 컨테이너용 Microsoft Defender 또는 비 Microsoft 기능을 사용하여 위협을 모니터링합니다. VM(가상 머신)에서 컨테이너를 호스트하는 경우 서버용 Microsoft Defender 또는 Microsoft 이외의 기능을 사용합니다. 또한 Azure Monitor의 컨테이너 모니터링 솔루션 에서 Microsoft Sentinel 또는 기존 SIEM(보안 정보 및 이벤트 관리) 솔루션에 로그를 통합할 수 있습니다.

  • 취약성을 모니터링합니다. 클라우드용 Microsoft Defender 또는 비 Microsoft 솔루션을 사용하여 이미지 및 실행 중인 컨테이너에서 알려진 취약성을 지속적으로 모니터링합니다.

  • 이미지 패치를 자동화합니다. Container Registry의 기능인 Azure Container Registry 작업을 사용하여 이미지 패치를 자동화합니다. 컨테이너 이미지는 레이어에서 빌드됩니다. 기본 레이어에는 ASP.NET Core 또는 Node.js 같은 OS 이미지 및 애플리케이션 프레임워크 이미지가 포함됩니다. 기본 이미지는 일반적으로 애플리케이션 개발자로부터 업스트림으로 만들어지고 다른 프로젝트 유지 관리자는 이를 유지 관리합니다. 이러한 이미지가 업스트림에 패치된 경우 알려진 보안 취약성을 남기지 않도록 고유한 이미지를 업데이트, 테스트 및 다시 배포하는 것이 중요합니다. Azure Container Registry 작업은 이 프로세스를 자동화하는 데 도움이 될 수 있습니다.

  • 신뢰할 수 있는 프라이빗 레지스트리에 이미지를 저장합니다. Container Registry 또는 Docker Trusted Registry와 같은 신뢰할 수 있는 프라이빗 레지스트리를 사용하여 이미지를 저장합니다. Kubernetes에서 허용 웹후크의 유효성을 검사하여 Pod가 신뢰할 수 있는 레지스트리에서만 이미지를 검색할 수 있도록 합니다.

  • 최소 권한 원칙을 적용합니다. 컨테이너를 권한 있는 모드로 실행하지 마세요. 권한 있는 모드는 호스트의 모든 디바이스에 컨테이너 액세스를 제공합니다. 되도록이면 프로세스를 컨테이너 내부에서 루트로 실행하지 마세요. 컨테이너는 보안 관점에서 완전히 격리되지 않으므로 권한 없는 사용자로 컨테이너 프로세스를 실행하는 것이 좋습니다.

배포 CI/CD 고려 사항

마이크로 서비스 아키텍처에 대한 강력한 CI/CD 프로세스의 다음 목표를 고려합니다.

  • 각 팀은 다른 팀에 영향을 주거나 방해하지 않고 독립적으로 소유한 서비스를 빌드하여 배포할 수 있습니다.

  • 새 버전의 서비스를 프로덕션에 배포하기 전에 유효성 검사를 위해 개발, 테스트 및 Q&A 환경에 배포됩니다. 각 단계에서 품질 게이트를 적용합니다.

  • 새 버전의 서비스를 이전 버전과 함께 배포할 수 있습니다.

  • 충분한 액세스 제어 정책을 적용합니다.

  • 컨테이너화된 워크로드의 경우 프로덕션 환경에 배포된 컨테이너 이미지를 신뢰할 수 있습니다.

문제에 대해 자세히 알아보려면 마이크로 서비스 아키텍처에 대한 CI/CD를 참조하세요.

Istio와 같은 서비스 메시를 사용하면 카나리아 배포, 마이크로 서비스의 A/B 테스트 및 백분율 기반 트래픽 분할이 있는 단계적 롤아웃과 같은 CI/CD 프로세스에 도움이 될 수 있습니다.

특정 권장 사항 및 모범 사례에 대한 자세한 내용은 Azure DevOps 및 Helm을 사용하여 Kubernetes에서 마이크로 서비스에 대한 CI/CD 파이프라인 빌드를 참조하세요.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화대한 디자인 검토 검사 목록을 참조하세요.

Azure 가격 계산기를 사용하여 비용을 예측합니다. 다른 고려 사항은 Microsoft Azure Well-Architected Framework의 비용 섹션에 설명되어 있습니다.

이 아키텍처에 사용되는 일부 서비스에 대해 다음 사항을 고려합니다.

AKS

Azure 부하 분산기

구성된 부하 분산 및 아웃바운드 규칙 수에 대해서만 요금이 청구됩니다. 인바운드 네트워크 주소 변환 규칙은 무료입니다. 규칙을 구성하지 않으면 표준 Load Balancer에 대한 시간당 요금이 청구되지 않습니다. 자세한 내용은 Azure Load Balancer 가격 책정을 참조하세요.

Azure Pipelines (애저 파이프라인스)

이 참조 아키텍처는 Azure Pipelines만 사용합니다. Azure는 파이프라인을 개별 서비스로 제공합니다. CI/CD의 경우 매월 1,800분, 매월 무제한으로 자체 호스팅 작업 1개를 사용하는 무료 Microsoft 호스팅 작업이 허용됩니다. 추가 작업에는 더 많은 비용이 발생합니다. 자세한 내용은 Azure DevOps 서비스 가격 책정을 참조하세요.

Azure Monitor (Azure 모니터)

Azure Monitor Log Analytics의 경우 데이터 수집과 보존에 대한 요금이 청구됩니다. 자세한 내용은 Azure Monitor 가격을 참조하세요.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성대한 디자인 검토 검사 목록을 참조하세요.

이 참조 아키텍처에는 클라우드 리소스 및 해당 종속성을 프로비전하기 위한 Bicep 파일이 포함됩니다. Azure Pipelines를 사용하여 이러한 Bicep 파일을 배포하고 프로덕션 시나리오 복제와 같은 다양한 환경을 신속하게 설정할 수 있습니다. 이 방법을 사용하면 필요한 경우에만 부하 테스트 환경을 프로비전하여 비용을 절감할 수 있습니다.

워크로드 격리 기준을 따라 Bicep 파일을 구성하는 것이 좋습니다. 워크로드는 일반적으로 임의의 기능 단위로 정의됩니다. 예를 들어 클러스터에 대한 별도의 Bicep 파일과 종속 서비스에 대한 다른 파일을 가질 수 있습니다. 각 워크로드가 자체 팀에 의해 연결되고 관리되기 때문에 Azure DevOps를 사용하여 워크로드 격리를 통해 CI/CD를 수행할 수 있습니다.

시나리오 배포

이 아키텍처에 대한 참조 구현을 배포하려면 GitHub 리포지토리에 설명된 단계를 따르세요. 자세한 내용은 AKS 마이크로 서비스 참조 구현을 참조하세요.

기여자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

대표 저자:

기타 기여자:

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계