이 문서에서는 은행 고객을 위한 솔루션을 구축하는 데 사용된 Microsoft CSE(상업 소프트웨어 엔지니어링) 팀의 프로세스 및 구성 요소를 요약합니다. 익명성을 위해 이 문서에서는 고객을 Contoso Bank로 지칭합니다. 금융 트랜잭션 시스템 중 하나를 최신화하려는 주요 국가별 FSI(금융 서비스 산업) 조직입니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
솔루션은 백 엔드 서비스, 부하 테스트, 이벤트 자동 크기 조정기를 사용한 모니터링이라는 세 가지 주요 블록으로 구성되어 있습니다.
실제 Contoso 마이크로 서비스 컨테이너는 Docker를 통해 Kubernetes 클러스터로 수동으로 푸시되었습니다. 이 클러스터는 다음과 같습니다.
다음을 위한 Kubernetes/OpenShift HPA(Horizontal Pod Autoscaler)의 ARO(Azure Red Hat OpenShift):
채널 홀더.
트랜잭션 시뮬레이션 결과물을 위한 확장성 및 성능.
채널 홀더에 대한 노드 자동 크기 조정기용 AKS(Azure Kubernetes Service)입니다.
CSE 팀은 솔루션이 Azure Pipelines를 통해 푸시한 다른 외부 메인프레임 서비스에서 실제 Contoso 마이크로 서비스를 구체적으로 분리하기 위해 다른 마이크로 서비스를 스텁으로 만들었습니다.
워크플로
백 엔드 서비스는 EFT가 발생하는 데 필요한 논리를 핵심에서 제공합니다.
새로운 EFT는 채널 홀더 서비스에서 수신한 HTTP 요청으로 시작됩니다.
이 서비스는 Azure Cache for Redis를 통해 게시-구독 패턴을 사용하여 요청자에게 동기 응답을 제공하고 백 엔드 응답을 기다립니다.
솔루션은 EFT 파일럿 암호 서비스를 사용하여 이 초기 요청의 유효성을 검사합니다.
유효성 검사를 수행하는 것 외에도 서비스는 데이터를 풍부하게 합니다. 데이터 보강은 백 엔드가 솔루션이 EFT를 처리하기 위해 레거시 마이크로 서비스 시스템을 사용해야 하는지 아니면 새로운 시스템을 사용해야 하는지 결정을 내리는 데 도움이 됩니다.
그런 다음 채널 홀더 서비스는 비동기식 흐름을 시작합니다.
서비스는 트랜잭션 흐름을 조정하는 반응 오케스트레이터인 EFT 컨트롤러를 호출합니다. Azure Event Hubs/Kafka를 통해 다른 마이크로 서비스에서 명령을 생성하고 이벤트를 사용하여 수행합니다.
이러한 서비스 중 하나는 솔루션이 신용 및 차변 작업을 수행하는 실제 트랜잭션을 실행하는 EFT 프로세서입니다.
CSE 팀은 Kubernetes KEDA(이벤트 기반 자동 크기 조정)를 사용 했습니다. 솔루션이 처리한 메시지의 로드를 기반으로 애플리케이션을 자동으로 확장하는 프레임워크입니다. 솔루션에서는 솔루션이 새로운 EFT를 처리함에 따라 EFT 프로세서를 확장하는 데 사용되었습니다.
KEDA는 AKS 및 Azure Container Apps에서 지원됩니다.
다음은 부하 테스트입니다. Azure Load Testing은 대규모 부하를 생성할 수 있는 완전 관리형 부하 테스트 서비스입니다. 이 서비스는 추가 리소스를 배포할 필요 없이 애플리케이션에 대한 트래픽을 시뮬레이션합니다. Azure Load Testing에는 기존 Apache JMeter 스크립트를 사용하여 부하 테스트를 실행하는 기능도 함께 제공됩니다.
마지막으로 모니터링은 부하 테스트 결과, 인프라 및 애플리케이션 메트릭을 통합하는 역할을 담당했습니다.
팀은 부하 테스트 실행을 스토리지 및 컨테이너 오케스트레이션 계층에서 마이크로 서비스로 인한 부작용과 연관시켰습니다. 애플리케이션 튜닝을 위한 빠른 피드백 주기를 허용했습니다. Azure Monitor의 Prometheus, Grafana 및 Application Insights는 이러한 모니터링 및 가시성 기능을 허용하는 핵심 구성 요소였습니다. 이벤트 자동 크기 조정기는 수신된 메시지 로드를 기반으로 애플리케이션이 확장되는 시나리오의 유효성 검사를 지원했습니다. 이 동작을 구현하기 위해 CSE 팀은 Java 애플리케이션 크기 조정을 지원하도록 KEDA를 채택했습니다.
솔루션 기능
이 솔루션에는 세 가지 주요 기능이 포함됩니다.
채널 홀더용 수평형 Pod 자동 크기 조정기
채널 홀더를 위한 노드 자동 크기 조정
트랜잭션 시뮬레이션 결과물을 위한 확장성 및 성능
채널 홀더용 수평형 Pod 자동 크기 조정기
이 솔루션에서 팀은 Kubernetes/OpenShift HPA 메커니즘을 사용했습니다. HPA는 선택한 메트릭을 기반으로 Pod 수를 자동으로 조정합니다. 이렇게 하면 컨테이너에 대한 효율적인 스케일 인 및 스케일 아웃 메커니즘이 제공됩니다. 채널 홀더 REST API의 CPU에 바인딩된 특성을 감안할 때 팀은 새로운 EFT가 발생할 때 서비스 복제본이 커질 수 있도록 CPU와 함께 HPA를 사용하기로 결정했습니다.
이 구성 요소는 Azure Red Hat OpenShift에서 채널 홀더라는 서비스를 실행합니다. 이 서비스에 대해 Pod 자동 크기 조정 테스트를 수행합니다. 구성 요소는 다음 기능을 달성해야 했습니다.
채널 홀더 서비스를 위해 온-프레미스에서 Azure로 DevOps 파이프라인을 제공합니다.
Grafana 대시보드를 통해 OpenShift 클러스터 모니터링을 제공합니다.
Channel Holder 서비스에 대한 Horizontal Pod 자동 크기 조정 테스트를 실행합니다.
Prometheus 및 Grafana로 메트릭 캡처(예: 사용량)를 활성화하여 채널 보유자에 대한 가시성을 제공합니다.
실행된 테스트, 애플리케이션의 동작, Kafka 분할 전략(있는 경우)에 대한 자세한 보고서를 제공합니다.
채널 홀더를 위한 노드 자동 크기 조정
먼저 HPA는 클러스터 인프라를 포화시키는 지점까지 복제본을 확장합니다. 그런 다음 노드에 대한 축소 및 축소 메커니즘은 애플리케이션이 계속해서 새 요청을 수신하고 처리하도록 합니다. 이 메커니즘에 대해 팀은 Kubernetes 노드 자동 크기 조정을 사용했으며 그로 인해 모든 노드가 최대 용량에 근접한 경우에도 클러스터가 성장할 수 있었습니다.
이 구성 요소는 노드 자동 크기 조정 테스트를 허용하기 위해 AKS에서 채널 홀더 서비스를 실행하는 데 중점을 둡니다. 다음 기능을 달성해야 했습니다.
Grafana 대시보드를 통해 AKS 클러스터 모니터링을 제공합니다.
채널 홀더 서비스에 대한 노드 자동 크기 조정 테스트를 실행합니다.
Prometheus 및 Grafana로 메트릭 캡처를 활성화하여 채널 홀더에 대한 가시성을 제공합니다.
실행된 테스트, 애플리케이션의 동작, Kafka 분할 전략(있는 경우)에 대한 자세한 보고서를 제공합니다.
트랜잭션 시뮬레이션 결과물을 위한 확장성 및 성능
부하 테스트 프레임워크를 사용하여 CSE 팀은 HPA와 노드 자동 크기 조정 메커니즘을 모두 트리거하기에 충분한 부하를 생성했습니다. 솔루션이 구성 요소를 트리거할 때 팀이 채널 홀더 조정 응답 시간과 높은 부하에서 애플리케이션 동작을 유효성 검사할 수 있는 인프라 및 애플리케이션 메트릭을 생성했습니다.
이 구성 요소는 ARO 및 AKS에서 채널 홀더, EFT 컨트롤러 및 EFT 프로세서 서비스를 실행하는 데 중점을 둡니다. 또한 모든 서비스에 대해 Pod 및 노드 자동 크기 조정 및 성능 테스트를 수행합니다. 다음 기능을 달성해야 했습니다.
초당 2000 트랜잭션에 도달하거나 초과할 때까지 마이크로 서비스에 대해 성능 테스트를 실행합니다.
마이크로 서비스를 통해 수평적 Pod/노드 자동 크기 조정 테스트를 실행합니다.
Prometheus 및 Grafana로 메트릭 캡처를 활성화하여 채널 홀더에 대한 가시성을 제공합니다.
실행된 테스트, 애플리케이션의 동작 및 채택된 Kafka 분할 전략에 대한 자세한 보고서를 제공합니다.
구성 요소
아래 목록에는 CSE 팀이 이 솔루션을 만드는 데 사용한 기술이 요약되어 있습니다.
Azure
타사
Contoso Bank 백 엔드 서비스
오픈 소스
시나리오 정보
Contoso Bank는 금융 트랜잭션 시스템 중 하나를 최신화하려는 주요 국가별 FSI(금융 서비스 산업) 조직입니다.
Contoso Bank는 시뮬레이션 및 실제 애플리케이션과 기존 워크로드를 사용하여 확장성과 성능에 대한 솔루션 인프라의 반응을 모니터링하기를 원했습니다. 솔루션은 기존 결제 시스템의 요구 사항과 호환되어야 했습니다.
잠재적인 사용 사례
Contoso Bank는 다음을 위해 일련의 시뮬레이션을 사용하고자 했습니다.
인프라 확장성의 영향을 확인합니다.
특정 메인프레임 소프트웨어의 기존 아키텍처 설계에서 실패에 대한 반응을 결정합니다.
제안된 솔루션은 가상 애플리케이션을 사용하여 기능 시나리오를 시뮬레이션합니다. 그 목적은 인프라의 성능과 확장성을 모니터링하는 것입니다. 목표는 이 시뮬레이션 세트를 통해 메인프레임 EFT(전자 자금 이체) 시스템 워크로드의 실패 영향을 확인하는 것이었습니다.
온-프레미스에서 클라우드로의 원활한 DevOps 전환을 제안해야 한다는 요구 사항도 있었습니다. 전환에는 은행의 프로세스와 방법론이 포함되어야 했으며 Contoso Bank의 기존 도구를 사용해야 했습니다. 기존 기술을 사용하면 개발자가 기술 향상에 미치는 영향을 줄일 수 있습니다. 전환은 Contoso Bank가 현재 및 미래의 디자인 결정을 검토하는 데 도움이 됩니다. 전환은 또한 Azure가 새로운 분산 시스템을 호스팅할 수 있을 만큼 강력한 환경이라는 확신을 제공합니다.
고려 사항
성공 조건
Contoso 팀과 CSE 팀은 이 사용자 참여에 대해 다음과 같은 성공 기준을 정의했습니다.
일반 기준
Contoso Bank는 다음과 같은 일반적인 사항을 모든 구성 요소에 대한 성공적인 기준으로 간주했습니다.
Contoso 기술 팀에 디지털 변환 및 클라우드 채택을 적용할 수 있는 기능을 제공합니다. CSE 팀:
Azure에서 필요한 도구와 프로세스를 제공했습니다.
Contoso 기술 팀이 기존 도구를 계속 사용할 수 있는 방법을 보여 주었습니다.
각 구성 요소는 다음을 다루는 문서와 함께 제공됩니다.
확장성 및 성능 테스트 결과.
각 테스트에서 고려되는 매개 변수 및 메트릭.
각 테스트 중에 필요한 경우 코드 또는 인프라 변경.
성능 튜닝 및 각 테스트에 대해 고려되는 매개 변수에 대해 학습한 내용.
Kafka 분할 전략에 대한 학습 및 지침.
결과물에 대한 학습을 기반으로 하는 일반 아키텍처 권장 사항/지침.
결과물 기준
| 메트릭 | 값(범위) |
|---|---|
| 채널 홀더에서 Pod 자동 크기 조정 테스트를 실행하는 기능 | 대상: 시스템은 CPU 사용량이 50%에 도달한 후 새 채널 홀더 Pod 복제본을 자동으로 만듭니다. |
| 채널 홀더를 기반으로 노드 자동 크기 조정 실행 기능 | 대상: 시스템은 Pod의 리소스 제약 조건(예: CPU 사용량)으로 인해 새 Kubernetes 노드를 만듭니다. Kubernetes는 시스템이 만들 수 있는 노드 수를 제한합니다. 노드 제한은 3개입니다. |
| EFT 시뮬레이션에서 Pod/노드 자동 크기 조정 및 성능 테스트를 실행하는 기능 | 대상: 시스템은 모든 서비스에 대한 새 Pod 복제본을 자동으로 만듭니다. 복제는 CPU 사용량 50% 달성 및 CPU 리소스 제약 조건과 관련된 새 Kubernetes 노드 만들기 후 발생합니다. 솔루션은 초당 2000개의 트랜잭션을 지원해야 합니다. |
기술 솔루션
팀이 제공한 솔루션에는 대상 결과물을 달성하기 위한 복합적인 문제 및 특정 구현이 포함되었습니다. 또한 Contoso Bank의 정책을 기반으로 하는 몇 가지 디자인 제약 조건을 준수해야 했습니다.
Azure Red Hat OpenShift 3.11의 기능 제약 조건으로 인해 Contoso는 테스트 노드 자동 크기 조정 시나리오에 Azure Kubernetes Service 사용을 요청했습니다.
CSE 팀이 고려해야 하는 여러 설계 제약 조건이 있습니다.
내부 요구 사항으로 인해 Contoso Bank는 다음 기술의 사용을 요청했습니다.
컨테이너 오케스트레이션 플랫폼으로는 OpenShift 3.11.
마이크로 서비스 개발에는 Java 및 Spring Boot.
Confluent Schema Registry 기능이 있는 이벤트 스트리밍 플랫폼으로는 Kafka.
솔루션은 클라우드에 구애받지 않아야 했습니다.
DevOps 및 모니터링 도구는 Contoso가 이미 온-프레미스 개발 환경에서 사용한 것과 동일해야 했습니다.
솔루션은 Contoso가 온-프레미스 환경에서 호스팅하는 소스 코드를 외부 환경과 공유할 수 없습니다. Contoso 정책은 온-프레미스에서 Azure로의 컨테이너 이미지 이동만 허용합니다.
Contoso 정책은 온-프레미스 환경과 모든 클라우드 간에 작동하는 CI(상시 통합) 파이프라인의 기능을 제한합니다. Contoso는 온-프레미스 환경에서 호스팅되는 모든 소스 코드를 컨테이너 이미지로 Azure Container Registry에 수동으로 배포했습니다. 온-프레미스 쪽 배포는 Contoso의 책임이었습니다.
테스트를 위해 시뮬레이션된 시나리오는 흐름 참조로 메인프레임 EFT 워크로드의 하위 집합을 사용해야 했습니다.
Contoso Bank는 ARO에서 모든 HPA 및 성능 테스트를 수행해야 했습니다.
솔루션에 대한 복합적인 우려
메시지 스트리밍
CSE 팀은 Apache Kafka를 마이크로 서비스용 분산 메시지 스트리밍 플랫폼으로 사용하기로 결정했습니다. 더 나은 확장성을 위해 팀은 마이크로 서비스당 하나의 소비자 그룹을 사용하는 것을 고려했습니다. 해당 구성에서 각 마이크로 서비스 인스턴스는 이벤트 처리를 분할하고 병렬화하는 확장 단위입니다.
그들은 수식을 사용하여 예상 처리량을 지원하기 위해 항목당 예상되는 이상적인 파티션 수를 계산했습니다. 수식에 대한 자세한 내용은 Kafka 클러스터에서 항목 또는 파티션 수를 선택하는 방법을 참조하세요.
CI/CD 속도
DevOps의 경우 Contoso Bank는 이미 코드 리포지토리에 GitLab의 온-프레미스 인스턴스를 사용했습니다. 내부적으로 개발한 사용자 지정 Jenkins 기반 솔루션을 사용하여 개발 환경을 위한 CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 만들었습니다. 이는 최적의 DevOps 환경을 제공하지 못했습니다.
Contoso에 개선된 DevOps 환경을 제공하기 위해 CSE 팀은 Azure DevOps에서 Azure Pipelines를 사용하여 애플리케이션 수명 주기를 관리했습니다. CI 파이프라인은 모든 끌어오기 요청에서 실행되는 반면 CD 파이프라인은 기본 분기에 성공적으로 병합될 때마다 실행됩니다. 개발 팀의 각 멤버는 각 서비스에 대한 리포지토리와 파이프라인을 관리하는 일을 담당했습니다. 또한 코드 검토, 단위 테스트 및 린팅(정적 소스 코드 분석)을 적용해야 했습니다.
CSE 팀은 상호 의존성 없이 서비스를 동시에 배포했으며 Contoso Bank의 요청에 따라 Jenkins 에이전트를 사용했습니다.
그들은 서비스와 클러스터를 모니터링하기 위해 Prometheus를 솔루션의 일부로 통합했습니다. Contoso Bank는 솔루션에 대한 의미 있는 데이터를 생성하는 것 외에도 향후 Prometheus를 사용하여 일상적인 사용을 기반으로 제품을 개선할 수 있습니다. Grafana 대시보드는 이러한 메트릭을 표시합니다.
출시 전략
팀은 Azure Pipelines를 통해 개발 환경에 솔루션을 출시했습니다. 각 서비스에는 자체 빌드 및 배포 파이프라인이 있습니다. 수동으로 트리거할 수 있는 배포 파이프라인을 사용했습니다. 특정 분기 버전에서 환경 및 컨테이너의 전체 배포를 강제 실행해야 합니다.
CSE 팀은 배포를 위한 안정적인 버전을 만드는 릴리스 분기를 만들었습니다. 팀이 솔루션을 배포할 준비가 되었다고 확신하는 경우에만 분기를 기본 분기에 병합합니다. 이전의 안정적인 버전을 배포하는 것 이상의 롤백 전략은 이 사용자 참여의 범위를 벗어났습니다. 각 단계에 대한 승인 게이트가 있습니다. 각 게이트는 배포 승인을 요청합니다.
재해 복구
솔루션은 모든 서비스에 대해 Terraform 스크립트 및 Azure Pipelines를 사용합니다. 재해가 발생하면 Contoso Bank는 Terraform 스크립트를 사용하거나 릴리스 파이프라인을 다시 실행하여 전체 환경을 다시 만들 수 있습니다. Terraform은 환경이 변경되었음을 이해하고 다시 만듭니다. 솔루션은 필요에 따라 Azure에서 인프라를 동적으로 프로비저닝하고 파괴합니다. 스토리지 계정은 ZRS(영역 중복 스토리지)입니다. 백업 전략은 이 서비스의 범위를 벗어났습니다.
보안 및 개인 정보
프라이빗 레지스트리(Azure Container Registry)는 모든 컨테이너 이미지를 저장했습니다.
이 솔루션은 ARO 및 AKS 비밀을 사용하여 연결 문자열 및 키와 같은 중요한 데이터를 Pod에 주입합니다.
Kubernetes API 서버에 액세스하려면 ARO 및 AKS용 Microsoft Entra ID를 통한 인증이 필요합니다.
Jenkins에 액세스하려면 Microsoft Entra ID를 통한 인증이 필요합니다.
결론
프로젝트가 끝날 때 CSE 팀은 다음과 같은 인사이트를 공유했습니다.
솔루션 및 사용자 참여 결과
팀은 서비스 배포를 위해 AKS와 ARO 간의 높은 수준의 호환성을 관찰했습니다.
Application Insights Codeless를 사용하면 리프트 앤 시프트 마이그레이션에서 클라우드 채택과 협력하여 가시성을 쉽게 만들 수 있습니다.
부하 테스트는 대규모 의도된 솔루션의 중요한 부분이며 마이크로 서비스 특성을 고려하기 위한 사전 분석 및 계획이 필요합니다.
고객은 마이크로 서비스의 부작용을 찾을 수 있는 부하 테스트의 잠재력을 과소평가하는 경우가 많습니다.
테스트 환경을 만들려면 불필요한 인프라 비용을 피하기 위한 인프라 폐기 전략이 필요할 수 있습니다.
주요 학습 사항
ARO에서 AKS로의 애플리케이션 마이그레이션이 원활합니다.
노드 자동 크기 조정 기능은 사용자 참여 중에 사용된 버전인 Red Hat OpenShift 버전 3.11에서 사용할 수 없었습니다. 그에 따라 CSE 팀은 AKS를 통해 노드 오토스케일링 테스트 시나리오를 진행했습니다.
제품의 수명이 다하면 창의적인 사용자 지정이 필요할 수 있습니다. 준비 단계는 팀이 성공적인 솔루션을 제공할 때 중요한 역할을 합니다.
이 문서를 만들 때 CSE 팀은 Azure DevOps 파이프라인에서 Container Instances 및 JMeter를 통합하는 부하 테스트 솔루션을 만들었습니다. 이후 Azure Load Testing 은 추가 컴퓨팅 리소스를 배포할 필요 없이 완전 관리형 부하 테스트 서비스로 사용할 수 있게 되었습니다.
팀은 Kafka에 Azure 이벤트 허브를 사용하도록 권장했지만 Contoso Bank의 경우 스키마 레지스트리가 중요한 기능이었습니다. 요청한 시간 프레임에 Contoso Bank에 참석하기 위해 팀은 AKS의 다른 인스턴스에서 스키마 레지스트리 사용을 고려해야 했습니다.
스키마 레지스트리가 있는 Kafka 프로토콜은 KEDA의 Event Hubs Scaler에서 지원되지 않습니다.
다음 단계
Azure Event Hubs를 사용하여 KEDA로 Java 애플리케이션 자동 크기 조정: Java용 KEDA 샘플
패턴: Saga: Microservices.io의 Saga 패턴에 대한 정보
관련 참고 자료
이 솔루션을 만드는 데 사용된 프로세스 및 기술에 대한 자세한 내용은 다음 문서를 참조하세요.