본문 바로가기
  • AI (Artificial Intelligence)
Industry 4.0/Edge computing

Azure에서 은행 시스템 클라우드 변환

by 로샤스 2020. 11. 23.

Ref. docs.microsoft.com/ko-kr/azure/architecture/example-scenario/banking/banking-system-cloud-transformation

이 문서에서는 Microsoft CSE (상업적 소프트웨어 엔지니어링) 팀이 은행 고객을 위한 솔루션을 구축 하는 데 사용 하는 프로세스 및 구성 요소를 요약 합니다. 익명의 편의를 위해이 문서는 고객을 Contoso Bank로 지칭 합니다. 이는 금융 트랜잭션 시스템 중 하나를 현대화 하는 데 필요한 주요 FSI.EXE (금융 서비스 업계) 조직입니다.

Contoso Bank는 시뮬레이션 된 응용 프로그램과 실제 응용 프로그램 및 기존 워크 로드를 사용 하 여 확장성 및 성능을 위한 솔루션 인프라의 반응을 모니터링 하려고 했습니다. 이 솔루션은 기존 지불 시스템의 요구 사항과 호환 되어야 합니다.

사용 사례

Contoso Bank에서 시뮬레이션 집합을 사용 하 여 다음을 수행 하려고 했습니다.

  • 인프라 확장성의 영향을 확인 합니다.

  • 특정 메인프레임 소프트웨어의 기존 아키텍처 디자인에서 발생 하는 오류에 대 한 대응을 결정 합니다.

제안 된 솔루션은 가상 응용 프로그램을 사용 하 여 함수형 시나리오를 시뮬레이트합니다. 이는 인프라의 성능 및 확장성을 모니터링 하기 위한 것입니다. 목표는이 시뮬레이션 집합을 통해 메인프레임 EFT (전자 자금 이체) 시스템 워크 로드에서 오류의 영향을 확인 하는 것입니다.

또한 온-프레미스에서 클라우드로의 원활한 DevOps 전환을 제안 하기 위한 요구 사항이 있었습니다. 전환에는 은행의 프로세스 및 방법론을 포함 해야 했으며 Contoso 은행의 기존 도구를 사용 해야 했습니다. 기존 기술을 사용 하면 개발자에 게 미치는 영향을 줄일 수 있습니다. 이 전환은 Contoso Bank에서 현재 및 미래의 디자인 결정을 검토 하는 데 도움이 됩니다. 또한이 전환은 Azure가 새로운 분산 시스템을 호스트 하는 데 충분 한 환경을 제공 한다는 확신을 제공 합니다.

Architecture

솔루션을 구성 하는 세 가지 주요 블록: 백 엔드 서비스, 부하 테스트, 모니터링 및 이벤트 Autoscaler.

실제 Contoso 마이크로 서비스 컨테이너는 Docker를 통해 Kubernetes 클러스터에 수동으로 푸시 되었습니다. 이 클러스터는 다음과 같습니다.

  • Kubernetes/OpenShift 가로 Pod Autoscaler (HPA)의 Azure Red Hat OpenShift (ARO):

    • 채널 소유자입니다.

    • 트랜잭션 시뮬레이션 결과물에 대 한 확장성 및 성능.

  • 채널 소유자의 노드 autoscaler에 대 한 AKS (Azure Kubernetes Services)

CSE 팀은 다른 마이크로 서비스를 스텁으로 만들어 솔루션이 AzureDevOps 파이프라인을 통해 푸시되는 다른 외부 메인프레임 서비스의 실제 Contoso 마이크로 서비스를 구체적으로 격리 합니다.

코어에서 백 엔드 서비스는 EFT 발생 하는 데 필요한 논리를 제공 합니다.

  1. 새 EFT은 채널 소유자 서비스에서 받은 HTTP 요청으로 시작 합니다.

    이 서비스는 Azure Cache for Redis를 통해 게시-구독 패턴을 사용 하 여 요청자에 게 동기 응답을 제공 하 고 백 엔드 응답을 기다립니다.

  2. 솔루션은 EFT 파일럿 암호 서비스를 사용 하 여이 초기 요청의 유효성을 검사 합니다.

    유효성 검사를 수행 하는 것 외에도 서비스는 데이터를 강화 합니다. 데이터 보강를 사용 하면 솔루션에서 레거시 마이크로 서비스 시스템을 사용 해야 하는지 아니면 새 항목을 사용 해야 하는지 결정 하는 데 도움이 됩니다.

  3. 그러면 채널 소유자 서비스가 비동기 흐름을 시작 합니다.

    서비스는 트랜잭션 흐름을 조정 하는 대응식 orchestrator 인 EFT Controller를 호출 합니다. Azure Event Hubs/Kafka을 통해 다른 마이크로 서비스에서 명령을 생성 하 고 이벤트를 사용 하 여이를 수행 합니다.

  4. 이러한 서비스 중 하나는 솔루션이 실제 트랜잭션을 effectuates 하 여 크레딧 및 직불 작업을 수행 하는 EFT 프로세서입니다.

    CSE 팀에서 Keda를 사용 했습니다. 솔루션이 처리 하는 메시지의 부하에 따라 응용 프로그램을 자동으로 확장 하는 프레임 워크입니다. 솔루션에서 새 EFTs를 처리 하는 EFT 프로세서를 확장 하는 데 사용 되었습니다.

    KEDA는 AKS 에서만 지원 됩니다.

  5. 다음은 부하 테스트입니다. 여기에는 JMeter, Azure Container Instances (ACI) 및 Terraform을 기반으로 하는 사용자 지정 솔루션이 포함 됩니다.

    팀은 솔루션의 부하 테스트 블록을 사용 하 여 Azure Pipelines와의 필수 통합을 프로 비전 했습니다. 이 솔루션은 자동 크기 조정 메커니즘이 준비 되었는지 유효성을 검사 하기 위해 백 엔드 서비스에 충분 한 부하를 생성 하 여 초당 수천 개의 EFT 트랜잭션을 만듭니다.

  6. 마지막으로, 모니터링은 부하 테스트 결과, 인프라 및 응용 프로그램 메트릭을 통합 하는 일을 담당 합니다.

    팀은 저장소 및 컨테이너 오케스트레이션 계층에서 마이크로 서비스에 의해 발생 하는 부작용으로 부하 테스트 실행을 상호 관련 시켰습니다. 응용 프로그램 튜닝에 대 한 빠른 피드백 주기를 허용 했습니다. Azure Monitor의 프로메테우스, Grafana 및 Application Insights는이 모니터링 및 관찰성 기능을 허용 하는 핵심 구성 요소 였습니다. 이벤트 Autoscaler은 받은 메시지 로드에 따라 응용 프로그램이 확장 되는 시나리오의 유효성 검사를 지원 합니다. 이 동작을 구현 하기 위해 CSE 팀은 Java 응용 프로그램 크기 조정을 지원 하기 위해 KEDA를 채택 했습니다.

솔루션 기능

이 솔루션에는 세 가지 주요 기능이 포함 됩니다.

  • 채널 홀더의 수평 Pod Autoscaler

  • 채널 홀더의 노드 자동 크기 조정

  • 트랜잭션 시뮬레이션 결과물에 대 한 확장성 및 성능

채널 홀더의 수평 Pod Autoscaler

이 솔루션에서 팀은 Kubernetes/OpenShift HPA 메커니즘을 사용 했습니다. HPA 선택한 메트릭에 따라 pod 수를 자동으로 조정 합니다. 이렇게 하면 컨테이너에 대해 효율적인 확장 및 축소 메커니즘이 제공 됩니다. 채널 소유자 REST API의 CPU 바인딩된 특성에 따라 팀은 새로운 EFTs가 발생 하면 서비스 복제본이 증가할 수 있도록 CPU와 함께 HPA를 사용 하도록 옵트인 합니다.

이 구성 요소는 Azure Red Hat OpenShift에서 채널 소유자 라는 서비스를 실행 합니다. 이 서비스에서 pod 자동 크기 조정 테스트를 수행 합니다. 구성 요소에서 다음과 같은 기능을 구현 해야 합니다.

  • 채널 소유자 서비스를 위해 온-프레미스에서 Azure로 DevOps 파이프라인을 제공 합니다.

  • Grafana 대시보드를 통해 OpenShift 클러스터 모니터링을 제공 합니다.

  • 채널 소유자 서비스에 대해 수평 pod 자동 크기 조정 테스트를 실행 합니다.

  • 프로메테우스 및 Grafana를 사용 하 여 메트릭 캡처 (예: 사용량)를 활성화 하 여 채널 소유자에 관찰성을 제공 합니다.

  • 실행 한 테스트, 응용 프로그램의 동작 및 Kafka 분할 전략 (있는 경우)에 대 한 자세한 보고서를 제공 합니다.

채널 홀더의 노드 자동 크기 조정

첫 번째 HPA는 클러스터 인프라를 saturates 하는 지점까지 복제본의 크기를 조정 합니다. 그러면 노드에 대 한 확장/축소 메커니즘이 새 요청을 수신 하 고 처리 하는 응용 프로그램을 유지 합니다. 이 메커니즘의 경우 팀은 모든 노드가 전체 용량에 근접 한 경우에도 클러스터를 늘릴 수 있도록 하는 Kubernetes 노드 자동 크기 조정을 사용 했습니다.

이 구성 요소는 노드 자동 크기 조정 테스트를 허용 하도록 AKS에서 채널 소유자 서비스를 실행 하는 데 집중 합니다. 다음 기능을 구현 해야 했습니다.

  • Grafana 대시보드를 통해 AKS 클러스터 모니터링을 제공 합니다.

  • 채널 소유자 서비스에 대 한 노드 자동 크기 조정 테스트를 실행 합니다.

  • 프로메테우스 및 Grafana를 사용 하 여 메트릭 캡처를 활성화 하 여 채널 소유자에 관찰성을 제공 합니다.

  • 실행 한 테스트, 응용 프로그램의 동작 및 Kafka 분할 전략 (있는 경우)에 대 한 자세한 보고서를 제공 합니다.

트랜잭션 시뮬레이션 결과물에 대 한 확장성 및 성능

부하 테스트 프레임 워크를 사용 하 여 CSE 팀은 HPA 및 노드 자동 크기 조정 메커니즘을 모두 트리거하기 위한 충분 한 부하를 생성 했습니다. 솔루션이 구성 요소를 트리거한 경우 팀에서 채널 소유자 크기 조정 응답 시간 및 응용 프로그램 동작의 유효성을 검사 하는 데 필요한 인프라 및 응용 프로그램 메트릭을 생성 합니다.

이 구성 요소는 ARO 및 AKS에서 채널 소유자, EFT 컨트롤러 및 EFT 프로세서 서비스를 실행 하는 데 집중 합니다. 또한 모든 서비스에서 pod 및 노드 자동 크기 조정 및 성능 테스트를 수행 합니다. 다음 기능을 구현 해야 했습니다.

  • 초당 2000 개 트랜잭션에 도달 하거나 초과 때까지 마이크로 서비스에 대 한 성능 테스트를 실행 합니다.

  • 마이크로 서비스에 대 한 수평 pod/노드 자동 크기 조정 테스트를 실행 합니다.

  • 프로메테우스 및 Grafana를 사용 하 여 메트릭 캡처를 활성화 하 여 채널 소유자에 관찰성을 제공 합니다.

  • 실행 된 테스트, 응용 프로그램의 동작 및 Kafka 분할 전략에 대 한 자세한 보고서를 제공 합니다.

구성 요소

아래 목록에는 CSE 팀에서이 솔루션을 만드는 데 사용한 기술이 요약 되어 있습니다.

고려 사항

성공 조건

Contoso 팀 및 CSE 팀은이 engagement에 대해 다음과 같은 성공 조건을 정의 했습니다.

일반 조건

Contoso Bank는 모든 구성 요소에 대해 다음과 같은 일반 사항을 성공적인 조건으로 간주 합니다.

  • Contoso 기술 팀에 디지털 변환 및 클라우드 도입을 적용할 수 있는 기능을 제공 합니다. CSE 팀:

    • Azure에서 필요한 도구와 프로세스를 제공 했습니다.

    • Contoso 기술 팀이 기존 도구를 계속 사용 하는 방법을 보여 주었습니다.

  • 각 구성 요소는 다음을 다루는 문서와 함께 제공 됩니다.

    • 확장성 및 성능 테스트 결과.

    • 각 테스트에 고려 되는 매개 변수 및 메트릭입니다.

    • 각 테스트 중에 필요한 경우 모든 코드 또는 인프라를 변경 합니다.

    • 각 테스트에 대해 고려 되는 성능 조정, 성능 조정 및 매개 변수에 대해 학습 했습니다.

    • 교훈 및 Kafka 분할 전략에 대 한 지침을 제공 합니다.

    • 결과물에 대 한 학습을 기반으로 하는 일반 아키텍처 권장 사항/지침

결과물 기준

결과물 기준메트릭값 (범위)

채널 보유자에서 pod 자동 크기 조정 테스트를 실행 하는 기능 대상: 50%의 CPU 사용량을 달성 한 후 시스템에서 자동으로 새 채널 소유자 pod 복제본을 만듭니다.
채널 소유자에 따라 노드 자동 크기 조정을 실행 하는 기능 대상: pod에 대 한 리소스 제약 조건 (예: CPU 사용량)으로 인해 시스템에서 새 Kubernetes 노드를 만듭니다. Kubernetes는 시스템에서 만들 수 있는 노드 수를 제한 합니다. 노드 제한은 3 개 노드입니다.
EFT 시뮬레이션에서 pod/node 자동 크기 조정 및 성능 테스트를 실행 하는 기능 대상: 시스템에서 모든 서비스에 대 한 새 pod 복제본을 자동으로 만듭니다. 50%의 CPU 사용량을 달성 하 고 CPU 리소스 제약 조건과 관련 된 새 Kubernetes 노드를 만든 후 복제가 발생 합니다. 솔루션은 초당 2000 트랜잭션을 지원 해야 합니다.

기술 솔루션

팀에서 제공 하는 솔루션은 대상 결과물을 얻기 위한 교차 잘라내기 문제 및 특정 구현을 포함 합니다. 또한 Contoso Bank 정책을 기반으로 하는 일부 디자인 제약 조건을 준수 해야 했습니다.

Azure Red Hat OpenShift 3.11에 대 한 기능 제약 조건 때문에 Contoso는 노드 자동 크기 조정 시나리오를 테스트 하기 위해 Azure Kubernetes 서비스를 사용 하도록 요청 했습니다.

CSE 팀에서 고려해 야 하는 몇 가지 디자인 제약 조건이 있습니다.

  • 내부 요구 사항으로 인해 Contoso Bank는 다음 기술의 사용을 요청 했습니다.

    • OpenShift 3.11는 컨테이너 오케스트레이션 플랫폼입니다.

    • 마이크로 서비스 개발용 Java 및 스프링 부팅

    • 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 (지속적인 통합/continuos 배달) 파이프라인을 만들었습니다. 최적의 DevOps 환경을 제공 하지 않았습니다.

Contoso에 대 한 향상 된 DevOps 환경을 제공 하기 위해 CSE 팀은 Azure DevOps 에서 Azure Pipelines 사용 하 여 응용 프로그램 수명 주기를 관리 합니다. CI 파이프라인은 모든 끌어오기 요청에서 실행 되는 반면 CD 파이프라인은 마스터 분기에 성공적으로 병합 될 때마다 실행 됩니다. 개발 팀의 각 구성원은 각 서비스에 대 한 리포지토리 및 파이프라인을 관리 해야 했습니다. 또한 코드 검토, 단위 테스트 및 lint (정적 소스 코드 분석)를 적용 해야 했습니다.

CSE 팀은 상호 종속성 없이 서비스를 동시에 배포 하 고 Contoso Bank에서 요청 하는 Jenkins 에이전트를 사용 했습니다.

서비스 및 클러스터를 모니터링 하기 위한 솔루션의 일부로 프로메테우스를 통합 합니다. Contoso Bank는 솔루션에 대 한 의미 있는 데이터를 생성 하는 것 외에도 나중에 프로메테우스를 사용 하 여 일일 사용량을 기준으로 제품을 개선할 수 있습니다. Grafana 대시보드에는 이러한 메트릭이 표시 됩니다.

출시 전략

팀은 Azure Pipelines를 통해 개발 환경에 솔루션을 출시 했습니다. 각 서비스에는 고유한 빌드 및 배포 파이프라인이 있습니다. 수동으로 트리거할 수 있는 배포 파이프라인을 사용 했습니다. 환경 및 특정 분기 버전의 컨테이너에 대 한 전체 배포를 적용 해야 합니다.

CSE 팀은 배포를 위해 안정적인 버전을 생성 한 릴리스 분기를 만들었습니다. 마스터 분기로 분기를 병합 하는 것은 팀에서 솔루션을 배포할 준비가 되어 있는 경우에만 발생 합니다. 이전 안정적인 버전을 배포 하는 것 외의 롤백 전략은이 engagement의 범위를 벗어났습니다. 각 단계에 대 한 승인 게이트가 있습니다. 각 게이트가 배포 승인을 요청 합니다.

재해 복구

솔루션은 모든 서비스에 대해 Terraform 스크립트와 Azure Pipelines 를 사용 합니다. 재해가 발생 하는 경우 Contoso Bank는 Terraform 스크립트를 사용 하거나 릴리스 파이프라인을 다시 실행 하 여 전체 환경을 다시 만들 수 있습니다. Terraform은 환경이 변경 된 것을 인식 하 고 다시 만듭니다. 솔루션은 필요에 따라 Azure에서 인프라를 동적으로 프로 비전 하 고 제거 합니다. 저장소 계정은 ZRS (영역 중복 저장소)입니다. 이 engagement의 백업 전략이 범위를 벗어났습니다.

보안 및 개인 정보

  • 개인 레지스트리 (Azure Container Registry)는 모든 컨테이너 이미지를 저장 합니다.

  • 이 솔루션은 ARO 및 AKS 암호를 사용 하 여 연결 문자열 및 키와 같은 중요 한 데이터를 pod에 삽입 합니다.

  • Kubernetes API 서버에 대 한 액세스에는 ARO 및 AKS에 대 한 Azure Active Directory 를 통한 인증이 필요 합니다.

  • Jenkins에 액세스 하려면 Azure Active Directory를 통한 인증이 필요 합니다.

결론

프로젝트의 끝에서 CSE 팀은 다음 정보를 공유 했습니다.

  • 솔루션 및 참여 결과

    • 팀은 서비스 배포에 대 한 AKS와 ARO 간의 높은 수준의 호환성을 관찰 했습니다.

    • Application Insights 코드 없는 를 사용 하면 관찰성를 보다 쉽게 만들 수 있으며, 리프트 앤 시프트 마이그레이션에 대 한 클라우드 채택을 공동으로 작업할 수 있습니다.

    • 부하 테스트는 대규모 솔루션의 중요 한 부분으로, 이전 분석과 마이크로 서비스 specificities을 고려해 야 하는 계획이 필요 합니다.

    • 마이크로 서비스 측 효과를 찾을 수 있는 부하 테스트는 고객이 자주 과소 예측 합니다.

    • 테스트 환경을 만들려면 불필요 한 인프라 비용을 방지 하기 위해 인프라 폐기 전략이 필요할 수 있습니다.

  • 주요 학습

    • ARO에서 AKS로의 원활한 응용 프로그램 마이그레이션이 있습니다.

    • 노드 자동 크기 조정 기능은 engagement 중에 사용 되는 버전인 Red Hat OpenShift 버전 3.11에서 사용할 수 없습니다. 따라서 CSE 팀은 AKS를 통해 테스트 시나리오를 자동으로 조정 합니다.

    • 제품의 수명 끝에는 creative 사용자 지정이 필요할 수 있습니다. 준비 단계는 팀에서 성공적인 솔루션을 배달할 때 중요 한 역할을 합니다.

    • CSE 팀은 Apache JMeter 테스트와 Azure Test Plans 에서 CLT (클라우드 부하 테스트) 기능을 사용 하는 것을 권장 했습니다. 그러나 조사 단계에서 팀은 Azure Test Plans 팀이이 기능을 사용 하지 않도록 확인 했습니다. 팀은 ACI와 JMeter를 통합 하는 새 솔루션을 파이프라인에 만들어야 했습니다.

    • 팀은 Kafka에 대해 Azure Event Hubs를 사용 하는 것을 권장 하지만 Contoso Bank의 경우 스키마 레지스트리는 중요 한 기능입니다. 요청 된 시간 프레임의 Contoso Bank에 참석 하려면 팀은 AKS의 다른 인스턴스에서 스키마 레지스트리를 사용 하는 것을 고려해 야 했습니다.

    • 스키마 레지스트리가 있는 Kafka 프로토콜은 KEDA의 Event Hub Scaler에서 지원 되지 않습니다.

다음 단계

이 솔루션을 만드는 데 사용 되는 프로세스 및 기술에 대 한 자세한 내용은 다음 문서를 참조 하세요.

저작자표시

'Industry 4.0 > Edge computing' 카테고리의 다른 글

APACHE IGNITE VS REDIS  (0) 2020.12.22
Optimize Delivery of Trending, Personalized News Using Amazon Kinesis and Related Services  (0) 2020.11.23
Level Up Your Games with Amazon Aurora  (0) 2020.11.23
Webhooks - Facebook  (0) 2020.10.19
JHipster란?  (0) 2020.10.19

관련글

댓글

티스토리툴바