저자: Liu Weiguang, Alibaba Cloud Intelligent New Finance & Internet Industry 회장, China Finance Forty Forum 전무 이사, Tsinghua University 전자 공학과 졸업
01 서문
2015년 클라우드 네이티브 개념이 제시되었을 때 당시 100년에 걸친 글로벌 금융의 발전으로 형성된 정보화와 디지털화의 이면에는 금융 수준의 기술 서비스 수준이 오랜 시간의 연마 끝에 산업 합의 표준을 형성했습니다. . 8년 전 클라우드 네이티브의 고전적인 개념은 컨테이너화, DevOps, 지속적인 개발 및 지속적인 통합, 마이크로서비스 아키텍처에 초점을 맞춘 소프트웨어 개발의 새로운 패러다임입니다. 고가용성, 고성능, 비즈니스 연속성, 시스템 보안 및 안정성 등과 같은 재정적 수준의 요구 사항은 클라우드 네이티브 아키텍처의 개념과는 다른 두 범주에 속하는 것 같습니다. 기술 수준의 지속적인 발전과 함께 새로운 애플리케이션 시스템 개발에서 금융 기관은 컨테이너화와 같은 클라우드 네이티브 배포 아키텍처를 점진적으로 도입하기 시작했지만 항상 개발 상태에 초점을 맞춘 클라우드 네이티브 기능은 건드릴 수 없다는 것을 발견했습니다. 모든 수준의 금융 시스템 구축. 클라우드 컴퓨팅 기술의 급속한 변화는 좁은 의미에서 넓은 의미로 클라우드 네이티브의 발전을 촉진했으며 오늘날의 클라우드는 보다 보편적인 표준 인프라이자 새로운 기술과 새로운 비즈니스 혁신을 위한 플랫폼이 되었습니다. 빅 데이터, 클라우드 네이티브 스토리지 및 클라우드 네이티브 네트워크 기술과 같은 네이티브 기술을 통해 클라우드의 네이티브 기능을 소프트웨어 개발에서 데이터 플랫폼으로 확장한 다음 기본 물리적 배포 아키텍처로 확장할 수 있습니다. 퍼블릭 클라우드이건 프라이빗 클라우드이건 오늘날의 클라우드 컴퓨팅은 기술 시스템의 발전과 오픈 소스의 수용 및 지원으로 인해 실제로 업계의 미래 지향적인 계획을 변화시키고 있습니다.
오랜 탐구와 연습 끝에 우리는 금융 등급의 클라우드 네이티브라는 새로운 개념을 제안합니다.핵심 아이디어는 클라우드 네이티브를 좁은 의미에서 넓은 의미로 변경하고 클라우드의 선진적 사고를 확장하는 것입니다. -애플리케이션 개발만 다루는 것에서 시스템 물리적 배포 아키텍처에 이르기까지 기본.단순 개발 상태에서 설계 상태+연구 개발 상태+운영 상태+운영 및 유지 관리 상태+재해 복구 상태로의 완전한 기술 링크, 재무 수준 결합 각 범주의 고가용성, 고성능, 비즈니스 연속성 등 금융 수준의 풀스택 클라우드 네이티브 아키텍처 패러다임으로 요약 및 정의된 기능입니다. 이러한 아키텍처 패러다임은 가장 진보된 기술 아키텍처 개념과 가장 엄격한 재무 수준의 SLA를 고도로 결합하여 전체 스택 클라우드 네이티브 기능을 업그레이드하고 기존 아키텍처를 완전히 대체하고 디지털의 급속한 발전을 위한 기술 시스템을 설명하는 것을 목표로 합니다. 오늘날 인공 지능의 클라우드 시대에 가장 강력한 지원을 제공할 수 있습니다.
02 금융 IT 아키텍처 개발
은행이 Iron Man이라면 IT 시스템은 그의 옷입니다.
지난 40년 동안 은행으로 대표되는 금융업의 사업 발전과 변혁으로 IT 시스템의 전체 구조도 여러 차례의 반복적 진화를 거쳤습니다.은행의 정보 개발 프로세스는 크게 네 단계로 요약할 수 있습니다. - 혼자만의 시대, 네트워킹과 온라인의 시대, 데이터 집중의 시대, 분산형 클라우드 네이티브의 시대.
1) 독립형 시대 : 컴퓨터가 수작업을 대체하는데 사용되나 정보의 상호접속이 없고 각 지점이 별도의 "전자장부"가 되어 정보의 섬이 됨.
2) 네트워킹 시대 : 은행은 완전한 네트워크 인프라에 의존하여 지방 및 지자체 호스트를 중심으로 지역 중소 도시에 의존하고 다양한 매장의 비즈니스를 연결하여 지방 및 지자체 상호 연결을 실현합니다.
3) 데이터 중앙 집중화 시대 : 은행은 자체 개발에 따라 데이터와 비즈니스를 다양한 수준으로 중앙 집중화하고 시스템 인프라, 물리적 서버, 데이터 및 응용 프로그램의 중앙 집중화를 실현합니다.
대용량 데이터 집중 시대에 은행의 IT 정보화가 가장 빠르게 발전하고 사업이 가장 활발하게 추진되는 시기이기도 하며, 전체 IT 시스템 구축에 있어 가장 중요한 것은 '코어 시스템'이다. 코어 시스템: 코어 뱅킹 시스템, 여기서 CORE는 Centralized Online Real-time Exchange를 의미하며 "centralized online real-time transaction"의 약자이기도 합니다. 이체 결제를 예로 들면 원래 반달에서 반달로 단축되었습니다. "실시간 재도착".중국 금융 서비스가 서비스 능력과 거래 효율성을 크게 향상시킨 것은 대규모 데이터 집중과 핵심 시스템의 실시간 온라인 거래 기능 구축을 통해 이루어졌습니다. 은행의 비즈니스 풍부함, 비즈니스 트랜잭션 볼륨 및 데이터 볼륨은 지속적으로 최고치를 기록하고 있으며 동시에 은행의 초석 역할을 하는 핵심 시스템은 처리 성능, 안정성, 및 IT 시스템의 보안이 필요합니다. 당시 국내 IT 기업들은 여전히 이렇게 극도로 높은 요구 사항을 감당할 수 없었고 은행의 IT 아키텍처에 대한 유일한 선택은 중앙 집중식 아키텍처였습니다.
4) 분산형 클라우드 네이티브 시대 : 금융업 형태의 지속적인 확장으로 인해 중앙집중식 구조의 확장성 부족, 인터넷식 고동시 대응 능력 부족, 고비용, 독자적 연구개발 요구 등의 결함이 지속적으로 나타나고 있다. 동시에 분산형 클라우드 네이티브 기술도 은행의 인터넷 서비스 플랫폼에서 핵심 시스템의 기술 아키텍처로 점차 이동하고 있으며 점차 은행의 차세대 은행 전체 주류 기술 아키텍처가 되고 있습니다.
중앙 집중식 아키텍처의 특징: 중앙 집중식 아키텍처는 IBM, Oracle 및 EMC가 지배하는 시스템 아키텍처 패러다임을 의미하기도 합니다. 핵심 아키텍처 시스템. 중앙 집중식 아키텍처의 가장 큰 특징은 배포 구조가 단순하다는 점이며 기본 하드웨어는 일반적으로 IBM, HP, Oracle 및 기타 제조업체에서 구입한 고가의 메인프레임, 미니 컴퓨터 및 올인원 컴퓨터를 사용하므로 고려할 필요가 없습니다. 여러 노드에 서비스를 배포하는 방법 및 노드 간의 "분산 협업 문제"를 고려할 필요가 없습니다. 일반적으로 단일 머신의 리소스 구성을 늘려 시스템의 처리 능력을 향상시키고 하드웨어 장치 및 기본 소프트웨어의 클러스터 메커니즘을 늘려 시스템의 가용성을 향상시키기 위해 "수직 및 수직 확장" 방식을 채택합니다.
분산 아키텍처의 특징: 시스템은 서로 다른 네트워크 컴퓨터에 배치된 여러 모듈로 구성되며 시스템은 네트워크를 통과하는 메시지를 통해 서로 통신하고 조정합니다. 분산형 시스템은 서버 수를 늘려 시스템의 운영 능력을 향상시키기 위해 "수평 수평 확장" 방식을 채택하고 있으며 이론적으로 운영 능력은 무한히 확장될 수 있다. 분산 시스템은 클러스터 배치를 채택하고 클러스터의 각 노드는 독립적인 운영 단위이며 작업 크기에 따라 언제든지 노드 수를 늘리거나 줄일 수 있습니다. 단일 노드의 장애는 전체 가용성에 영향을 미치지 않습니다.
03 클라우드 네이티브의 문제점과 갈등을 포용하는 금융 기업
"디자인은 물건을 예쁘게 만드는 것이 아니라 더 잘 작동하게 만드는 것입니다." 마찬가지로 클라우드 네이티브는 유행을 위한 것이 아니라 문제를 해결하기 위한 것입니다.
알리바바는 2009년 탈중앙화 아키텍처를 제안했고, 2013년 탈중앙화 아키텍처를 기본적으로 완성했다.
하드웨어 측면에서 표준화된 X86 서버를 사용하여 IBM 미니 컴퓨터와 EMC 스토리지 장치를 대체하여 성능 확장의 압박을 해결합니다.
소프트웨어 측면에서 Oracle 데이터베이스 대신 오픈 소스 OceanBase 및 MySQL을 사용하십시오.
시스템 측면에서는 분산 클라우드 네이티브 아키텍처라는 아이디어를 사용하여 새로운 시스템을 구축했습니다.
아키텍처를 분산화하는 과정에서 Ali는 저렴하고 상대적으로 제어 가능한 PC 서버로 대규모 컴퓨팅 문제를 해결할 뿐만 아니라 클라우드 네이티브 기술의 성숙도와 광범위한 적용을 촉진합니다. 금융 산업에서 비즈니스 및 기술의 지속적인 반복 및 개발로 분산형 클라우드 네이티브 기술은 고성능, 높은 안정성, 높은 유연성 및 높은 표준 요구 사항을 충족해야 할 뿐만 아니라 보안, 위험에 중점을 두어야 합니다. , 성능 및 용량 비용 전사적 아키텍처 설계 고려 사항 측면에서 다음과 같은 8가지 주요 문제에 직면해야 합니다.
질문 1: 클라우드 네이티브란 무엇입니까? 금융 등급 클라우드 네이티브란 무엇입니까?
CNCF의 클라우드 네이티브에 대한 초기 정의는 소프트웨어 개발 수준에서 새로운 패러다임에 더 초점을 맞춘 협소한 개념입니다.컨테이너화된 배포 + 마이크로서비스 아키텍처 + 지속적인 개발 및 지속적인 통합 + DevOps의 네 가지 특성을 가진 "좁은 클라우드 네이티브"로 정의됩니다. ", 핵심은 애플리케이션 개발자를 위한 것입니다. 그러나 클라우드 컴퓨팅의 지속적인 진화로 클라우드 네이티브 스토리지, 클라우드 네이티브 네트워크, 클라우드 네이티브 데이터베이스, 클라우드 네이티브 빅 데이터, 클라우드 네이티브 AI, 클라우드 네이티브 비즈니스 중간 플랫폼 등이 모두 클라우드 네이티브의 통합 범주이므로 개념이 점차 확장되고 있습니다. 이는 "협의의 클라우드 네이티브"가 여전히 개발 수준에 중점을 두고 여전히 고객의 전반적인 아키텍처 업그레이드 문제를 완전히 해결할 수 없으므로 "광의의 클라우드 네이티브"를 나타냅니다. 센스'가 생겼다.
금융 산업의 보다 엄격한 요구 사항에 직면하여 민첩한 개발 문제뿐만 아니라 아키텍처의 고급 특성을 해결하고 금융을 보안 준수, 강력한 트랜잭션 일관성, 단위 확장, 재해와 통합해야 합니다. 복구 및 다중 활성 및 전체 체인 클라우드 네이티브 기술과 심층 통합하여 기존 중앙 집중식 아키텍처의 전체 아키텍처 업그레이드를 실현하고 금융 산업의 표준 및 요구 사항을 충족할 뿐만 아니라 기본 기술 아키텍처의 장점이 있습니다. , "재무 수준의 클라우드 기본 아키텍처"를 형성합니다.
질문 2: 클라우드 네이티브는 IT 운영 및 유지 관리를 어디에서 변경합니까?
"같은 트랙 위의 자동차, 같은 텍스트의 책, 같은 길을 걷는다"
IT 아키텍처 진화의 관점에서 볼 때 전통적인 중앙 집중식 아키텍처는 배포하기 쉽지만 수직 굴뚝 분할과 수평 관리 분산이 있으며 각 계층과 각 기술 제품은 독립적으로 관리 및 유지됩니다. 가상화 기술이 성숙되면 기본 서버, 스토리지, 네트워크, 가상 시스템 및 기타 수준에서 중앙 집중식 통합 관리가 실현되어 운영 및 유지 관리 인력의 관리 반경이 크게 향상됩니다. 클라우드 네이티브의 핵심 개념은 더 이상 전통적인 굴뚝식 자원 공급 관계가 아닌 풀링과 서비스의 형태로 모든 자원 기술이 제공된다는 것입니다. 클라우드 네이티브 아키텍처는 IaaS 리소스, PaaS 리소스, 분산 데이터베이스, 분산 미들웨어, 컨테이너 및 R&D 프로세스와 같은 다양한 기술 서비스의 표준화 및 통합 관리를 더욱 실현하고 "같은 트랙의 차량, 책 같은 텍스트"를 진정으로 실현합니다. "는 운영 및 유지 관리의 복잡성을 크게 줄이고 1인당 관리 개체의 규모를 향상시킵니다.
질문 3: 클라우드 네이티브 시스템은 오픈 소스 거버넌스를 어떻게 구현합니까?
과거 금융기업이 클라우드 네이티브 기술이나 상품을 사용하려면 일부 오픈소스 프로젝트를 연구하고 O&M 및 관리를 직접 수행하는 데 많은 에너지를 소비해야 했으며 통합 및 안정성 보장과 같은 문제도 고려해야 했습니다. 클라우드 네이티브 플랫폼을 구축하기 위해. 금융 기관은 오픈 소스 소프트웨어가 표면 위의 명시적이고 기능적인 요구 사항과 표면 아래에 있는 많은 수의 암시적이고 비기능적인 요구 사항만 해결할 수 있다는 사실을 깨닫기 시작했습니다. 클라우드 네이티브 애플리케이션을 구축할 때 정말 고려해야 합니다.
개발자와 운영 및 유지 보수 담당자가 클라우드 네이티브 기술 제품을 보다 쉽게 사용할 수 있도록 하기 위해 점점 더 많은 금융 기관이 제품 통합, 운영, 모니터링에 이르기까지 엔터프라이즈급 클라우드 네이티브 기술 플랫폼 및 기술 표준 세트를 구축했습니다. , 운영 및 유지 관리 다차원 제품 및 아키텍처 거버넌스, SLA 보장, 성숙한 사례, 기술 사양 및 그레이 스케일을 통해 클라우드 네이티브 기술의 적응 및 구현을 실현합니다.
질문 4: 클라우드 네이티브와 정보 기술 애플리케이션 혁신을 어떻게 결합하여 1+1>2를 달성할 수 있습니까?
완전한 하향식 클라우드 네이티브 기술 스택은 오늘날 가장 진보된 기술 시스템을 대표하므로 "정보 기술 애플리케이션 혁신"을 위한 기술 솔루션을 선택하는 데 있어서 순수한 하드웨어 아이디어나 단순한 점대점 방식이 아닙니다. 대체 아이디어, 그러나 더 많이 사용되어야 함 가장 진보된 클라우드 네이티브 기술 아키텍처는 포괄적인 기능 업그레이드를 달성하기 위해 "정보 기술 애플리케이션 혁신" 변환의 기회를 활용합니다.
"정보기술 응용 혁신"은 금융기관의 IT 시스템 구축에 있어 무시할 수 없는 중요한 요소가 되었습니다. 하드웨어 및 소프트웨어 공급망의 안정성과 국산 칩의 신뢰성.
"정보 기술 응용의 혁신"은 필연적으로 금융 기관이 서로 다른 칩 서버의 "단편화 문제"에 직면하게 할 것입니다 (관리 복잡성 증가 및 비용 증가). 클라우드 관리를 위해 각 유형의 칩 클러스터를 별도로 구축하면 이 멀티 클라우드 리소스 풀의 단편화 및 차별화로 인해 클라우드 네이티브 애플리케이션이 리소스를 일정하게 예약하고 사용하는 것이 어렵고 탄력성을 위해 서로 다른 비즈니스의 최고점과 최저점을 완전히 활용할 수 없습니다. 또한 다중 클라우드는 배포, 업그레이드, 용량 확장 등 운영 및 유지 관리가 복잡해 별도로 관리해야 하므로 운영 및 유지 관리 비용이 많이 들고 운영 경험이 좋지 않습니다.
따라서 "다중 코어를 가진 하나의 클라우드 + 클라우드 네이티브"는 단편화 문제에 대한 최적의 솔루션이 되었고 "하나의 다중 코어를 가진 클라우드"는 서로 다른 유형의 칩이 공존하여 발생하는 멀티 클라우드 관리 문제를 근본적으로 해결합니다. 단편화의 통합 관리, ""의 통합 "멀티 코어"의 차이는 "하나의 클라우드"의 표준화된 서비스로 전환되었으며 클라우드 네이티브는 리소스 통합(소규모 및 대규모 단편화된 리소스의 조합) 문제를 해결합니다. 클라우드에서 리소스 풀의 강력한 컴퓨팅 성능을 최대한 활용하고 다중 칩 클러스터 기능의 컴퓨팅 성능 리소스 통합을 실현하여 진정으로 1+1>2 클라우드를 형성합니다.
질문 5: 클라우드 네이티브 아키텍처는 비즈니스 보안 프로덕션에 어떻게 대응합니까?
"머피의 법칙"에 따르면 - "모든 것을 의심하라, 모든 노드 오류가 발생할 것이다!" ("잘못될 수 있는 모든 것은 잘못될 것이다"). 클라우드 네이티브 애플리케이션 아키텍처의 설계 원칙은 안전한 생산에 영향을 미치는 잠재적인 "블랙 스완" 위험을 "정상"으로 간주하는 것입니다.
클라우드 네이티브 아키텍처의 제안은 장애 발생을 허용하고 각 서버와 각 구성 요소가 시스템에 영향을 미치지 않고 장애가 발생할 수 있으며 자가 치유 및 교체 가능한 기능을 갖도록 하는 것입니다. 즉각적인 장애(Fail fast 및 Fail small)는 클라우드 네이티브 시스템의 중요한 설계 원칙입니다. 생산 환경에 들어가는 문제. Fail small의 본질은 실패의 범위, 즉 폭발 반경을 제어하는 것입니다 시스템의 문제를 소진하는 방법에서 실패를 신속하게 발견하고 적절하게 처리하는 방법으로 초점이 전환됩니다.
기술적 위험은 금융 등급 클라우드 네이티브 아키텍처의 최우선 순위이기도 합니다. 거래 처리 오류는 예측할 수 없는 재정적 손실로 이어질 수 있습니다. 아키텍처 설계, 제품 개발, 온라인 변경, 안정성 평가, 결함 측면에서 시스템 아키텍처 플랫폼에서 위험 문화 메커니즘에 이르기까지 전문 기술 위험 시스템(SRE, Site Risk Engineering)을 구축해야 합니다. 위치 및 복구 등 수명주기 전반에 걸쳐 위험 품질 관리를 보장하고 모든 시스템 변경에 대해 포괄적인 보증을 제공합니다.
질문 6: 클라우드 네이티브 아키텍처는 비즈니스 연속성을 어떻게 보장합니까?
금융 기관의 경우 비즈니스가 온라인 상태가 되면 가장 용납할 수 없는 것은 비즈니스를 사용할 수 없다는 것입니다.
클라우드 네이티브 복원력은 시스템이 의존하는 소프트웨어 및 하드웨어 구성 요소에서 다양한 이상이 발생할 때 전체 시스템의 복원력을 나타냅니다. 이러한 이상에는 일반적으로 하드웨어 장애, 하드웨어 리소스 병목 현상(예: CPU/네트워크 카드 대역폭 고갈), 비즈니스 요인이 포함됩니다. 소프트웨어 설계 능력을 초과하는 트래픽, 전산실 작업에 영향을 미치는 장애 및 재해, 소프트웨어 버그 및 해커 공격 등 비즈니스 비가용성에 치명적인 영향을 미칩니다. 복원력은 시스템이 다차원에서 비즈니스 서비스를 지속적으로 제공할 수 있는 능력으로 해석되며, 핵심은 시스템 전체의 비즈니스 연속성을 개선하고 클라우드 네이티브 아키텍처 설계에서 시스템 복원력을 향상시키는 것입니다. 재무 수준의 클라우드 네이티브 복원 기능에는 다음이 포함됩니다. 서비스 비동기 기능, 재시도/전류 제한/저하/퓨징/배압, 마스터-슬레이브 모드, 클러스터 모드, AZ 내 고가용성, 단위화, 교차 지역 재해 복구, 원격 다중 라이브 재해 복구 등
질문 7: 클라우드 네이티브 아키텍처는 트랜잭션 일관성을 어떻게 처리합니까?
사람들은 독립형 시스템과 같은 분산 시스템을 사용하기를 원하므로 "분산 일관성" 문제에 직면하는 것은 불가피합니다.
클라우드 네이티브 마이크로 서비스의 "마이크로"는 서비스 세분화가 작아지고 금융 거래의 복잡성이 상대적으로 커짐을 의미합니다. 따라서 클라우드 네이티브 시스템의 데이터 일관성은 상대적으로 복잡한 문제이며, 서로 다른 마이크로 서비스의 독립적인 데이터 스토리지는 데이터 일관성을 유지하기 어렵습니다. 분산형 마이크로서비스 시스템에서 네트워크 오류는 불가피하기 때문에 CAP 이론에 따라 네트워크 파티션이 발생할 때 일관성과 가용성의 균형을 유지하기 위한 클라우드 네이티브 아키텍처가 필요합니다.
따라서 재무 수준의 클라우드 네이티브 아키텍처를 계획할 때 금융 서비스에서 일관성에 대한 문제도 직면하게 됩니다. 이러한 일관성은 비즈니스 로직(TCC, SAGA, XA 트랜잭션, 메시지 대기열 등)에 반영될 뿐만 아니라 데이터 수준에서 더 많은 일관성 보장이 필요합니다(다중 노드 일관성, 다중 센터 일관성).
질문 8: 클라우드 네이티브 아키텍처와 애플리케이션 설계 및 개발의 과제는 무엇입니까?
사람을 힘들게 하는 것은 먼 산이 아니라 신발 속에 있는 한 알의 모래입니다.
클라우드 네이티브 기술은 많은 이점이 있지만 금융 기관은 기존 시스템이 많은 경우가 많습니다.이러한 기존 시스템의 기술 시스템은 클라우드 네이티브 기술과 다른 경우가 많습니다.기존 시스템과 새로운 클라우드 네이티브 응용 프로그램을 통합하고 관리하는 방법은 무엇입니까? 마이크로 서비스의 분할 전략을 공식화하는 방법, 분할 차원, 분할 표준 및 분할 세분성을 측정하는 방법은 무엇입니까? 클라우드 네이티브 관찰 가능 시스템을 구축하고, 효과적인 모니터링, 로그 관리 및 경보를 구현하고, 애플리케이션 성능 및 리소스 사용량을 실시간으로 모니터링하고, 문제가 발생할 때 신속하게 찾아 해결하는 방법은 무엇입니까?
이러한 문제는 심층 솔루션에 도전합니다.많은 금융 기관은 클라우드 네이티브 기술이 설계, 연구 및 개발, 운영, 운영 및 유지 관리, 재해 복구의 5가지 상태에서 통합된 기술 사양을 구현해야 한다는 것을 인식하고 있습니다.백엔드 기능 및 요구 사항 운영 및 유지 보수, 재해 복구 및 보안과 같은 설계 및 개발 단계에서 고려, 설계 및 프런트 엔드하고 클라우드 네이티브 기술을 사용하여 백엔드 인적 작업 및 관리 복잡성을 해결합니다.
04 재무적 차원의 클라우드 네이티브를 위한 "새로운 표준, 새로운 청사진"
금융 등급 클라우드 네이티브의 개발 프로세스
"Out of Control: The Ultimate Fate and Ending of All Mankind"에서 현대 기술에 대한 케빈 켈리의 예측의 정확성은 저자를 많은 기술 실무자들의 마음 속에 예언자 왕으로 만들었고, 이 책은 또한 성스러운 책이 되었습니다. 책 설명에 두 가지 핵심 사항이 강조 표시됩니다.
1. 복잡한 시스템은 다수의 독립적이고 자율적인 단순 시스템으로 구성됩니다.
2. 복잡한 무브먼트는 단순한 무브먼트가 합쳐진 것이지 수정된 것이 아닙니다.
전체 시스템은 서로 다른 수준(마이크로 서비스)에서 단일 책임을 가진 여러 "마이크로 시스템"으로 구성되며 시스템 자체에는 내결함성과 반복 자유가 있어 전체적으로 동적 내결함성을 달성할 수 있습니다. 가장 중요한 것은 시스템에 "중앙화된 신의 손"이 없다는 것입니다. 이는 클라우드 네이티브가 주창하는 시스템 아키텍처 설계와 일치하며, 클라우드 네이티브의 탄생도 여기에 영감을 받았다.
"한 마리의 고래가 쓰러지면 모든 것이 성장한다."는 말처럼 전통적인 중앙 집중식 아키텍처의 쇠퇴와 쇠퇴와 함께 클라우드 네이티브 기술이 전면적으로 성장하고 부상하고 있습니다.
클라우드 네이티브는 기본적으로 클라우드에서 태어난 소프트웨어, 하드웨어 및 아키텍처입니다. 클라우드 네이티브도 지속적인 개발과 진화의 과정입니다.클라우드 네이티브(클라우드 네이티브)의 개념은 2015년에 제안된 후 CNCF가 추가로 개발하고 정제하여 컨테이너, 지속적인 제공, 지속적인 통합, 서비스 그리드, 마이크로 서비스, 불변의 토대 "좁은 클라우드 네이티브" 기능 및 선언적 API의 개념.
오늘날 "디지털화"에 대해 논의할 때 실제로 두 가지 개념이 있습니다. 하나는 원본이고 다른 하나는 변형입니다. 좁은 의미의 클라우드 네이티브 기술은 주로 인터넷 기반 "디지털 네이티브" 기업의 새로운 민첩한 혁신 요구 사항(주로 상태 비저장 인터넷 기반 애플리케이션)을 충족하며 데이터 일관성을 위한 최종 일관성이 필요합니다. 그러나 전통적인 금융 "디지털 변환" 기업의 기존 기술 표준 및 기술 자산(부담)에 더 큰 장애물이 있는 경우가 많습니다.
클라우드 컴퓨팅 기술이 지속적으로 심화되고 대중화됨에 따라 점점 더 많은 새로운 기술이 "클라우드에서 탄생"했습니다. "클라우드에서 태어나고 클라우드보다 더 긴 " 이러한 제품, 기술, 소프트웨어, 하드웨어 및 아키텍처는 점차 성숙되고 구성됨 "일반화된 클라우드 기원"의 개념이 탄생했습니다. 미래에는 "클라우드에서 태어나고 성장하는" "클라우드 네이티브" 제품이 계속 등장할 것입니다: 차세대 데이터베이스, 인공 지능, 스토리지, 칩, 네트워크 및 건강 코드. 클라우드 네이티브의 뛰어난 탄력성, 서비스 자율성 및 대규모 복제 가능성을 통해 이기종 리소스를 더 쉽게 표준화하고, 디지털 생산성 릴리스를 가속화하고, 비즈니스 애플리케이션의 반복 속도를 가속화하고, 비즈니스 혁신을 촉진할 수 있습니다. 이는 디지털 시대의 많은 불확실성 중 '가장 확실성'이며, 강력한 포용성은 미래 디지털 기업의 전반적인 기술 아키텍처 방향을 나타냅니다. "디지털 네이티브 기업"의 기술 아키텍처에 대한 기민한 혁신 요구 사항 외에도 일반화된 클라우드 네이티브 기술은 전통적인 "디지털 변환 기업"의 기술 표준 및 아키텍처 호환성 요구 사항을 고려하므로 기술 범위가 더 넓습니다. 아키텍처 적용 가능성 및 더 나은 엔터프라이즈급 서비스 기능.
오늘날 클라우드 네이티브가 점차 커뮤니티에서 금융 기관으로 이동하고 사람들 사이에서 점점 더 대중화됨에 따라 금융 기관은 재무 시나리오의 요구 사항을 클라우드 네이티브 구현과 결합하는 방법(금융 보안 규정 준수, 강력한 트랜잭션 일관성, 장치 확장, 재해 복구 및 다중 활성, 전체 링크 비즈니스 위험 관리, 운영 및 유지 관리 및 기타 산업 요구 사항은 클라우드 네이티브 기술과 깊이 통합되어 일련의 "금융 등급 클라우드 네이티브 아키텍처"를 개발합니다. 금융 수준 IT 환경의 엄격한 과제와 요구 사항을 더 잘 충족하고 금융 기관의 기존 "안정적인 애플리케이션"(디지털 변환) 및 "민감한 애플리케이션"(디지털 네이티브) 애플리케이션에 대한 통합 기술 아키텍처 지원을 제공할 수 있습니다.
과거 중앙 집중식 금융 아키텍처(중앙 브레인)의 통합 제어를 "왼쪽"으로, 완전히 오픈 소스 분산형 클라우드 네이티브를 "오른쪽"으로 가져간다면. 금융 클라우드 네이티브 아키텍처에서 금융 기관이 필요로 하는 기술 아키텍처는 재무 수준의 보안, 강력한 일관성 및 안정성뿐만 아니라 내결함성, 확장성, 그리고 빠른 대응 능력. 애플리케이션 복잡성을 보호하기 위해 "강한 로컬 자율성, 약한 중앙 제어" 아키텍처를 제안하고(예: GRC 아키텍처, G-Global 글로벌 시스템, R-Region 지역 시스템, C-City 로컬 시스템) 판단이 필요한 항목만 종합적인 요인에 의해 복잡한 로직을 글로벌 시스템(중앙 브레인)에서 완성하여 중앙 시스템의 부담을 줄이는 한편, 일상의 단순 판단과 실행 행위를 다수의 로컬 시스템에서 폐회로로 완성하여 내결함성을 높인다. 전체 시스템의 견고성.
금융 클라우드 네이티브를 정의하는 10가지 새로운 요소
클라우드 네이티브 아키텍처는 클라우드 네이티브 기술을 기반으로 한 일련의 아키텍처 원칙 및 디자인 패턴으로, 클라우드 애플리케이션에서 비업무용 코드 부분의 분리를 극대화하여 클라우드 시설이 많은 수의 원래 비기능적 코드를 인계할 수 있도록 하는 것을 목표로 합니다. 탄력성, 강인성, 보안성, 관찰성, 그레이스케일 등과 같은 애플리케이션의 기능을 비기능적 비즈니스 중단 문제 없이 비즈니스를 가볍고 민첩하며 고도로 자동화합니다. 기존 아키텍처에서는 애플리케이션 계층에 비즈니스 외 코드가 더 많았지만, 클라우드 네이티브 아키텍처에서는 비기능 코드가 애플리케이션 코드 논리에 반영되지 않고 인프라에 스며들게 하는 것이 이상적인 상황입니다. 유지보수 담당자도 비즈니스 코드와 관련된 부분에만 집중하면 됩니다. 재무 수준 클라우드 네이티브의 핵심을 다음 10가지 주요 아키텍처 요소로 요약합니다.
요소 1: 플랫폼 엔지니어링 및 불변 인프라
클라우드 네이티브 기술의 대규모 사용에 직면하여 금융 기관의 연구 개발과 운영 및 유지 관리의 복잡성을 줄이는 것은 클라우드 네이티브 기술 구현을 제한하는 큰 장애물입니다. 현재 R&D 관리와 운영 및 유지 관리의 관점에서 볼 때 "플랫폼 엔지니어링"과 "불변 인프라"는 복잡성을 크게 줄일 수 있는 두 가지 핵심 클라우드 네이티브 기능입니다.
DevOps 철학은 "누가 빌드하고 실행하는가"이며, 개발자는 애플리케이션을 엔드 투 엔드로 개발, 배포 및 실행할 수 있어야 합니다. 그러나 대부분의 금융 기관에서 이것은 실제로 달성하기 쉽지 않습니다. 검증된 효과적인 노동 분업(Ops 및 Dev)은 인재에 대한 요구 사항이 상대적으로 낮지만 DevOps 패러다임의 촉진으로 R&D 직원은 모든 것을 잘 알고 있어야 하므로 "인지 부담"이 크게 증가합니다. 이것은 금융 기관의 R&D 팀에 대한 높은 요구 사항을 부과하며, 이는 보편적인 인재의 구축에 도움이 되지 않으며 금융 기관의 클라우드 네이티브 애플리케이션의 포괄적인 도입을 크게 방해할 것입니다. 개선을 위한 가장 가능성 있는 방향 중 하나가 플랫폼 엔지니어링이라면 플랫폼 엔지니어링은 DevOps와 비즈니스 프로그래머 사이의 다리입니다. 개발자가 비즈니스 소프트웨어를 더 빠르고 효과적으로 제공할 수 있는 셀프 서비스 플랫폼입니다. 간단한 페이지 기반 작업을 통해 이 링크의 시리즈 구성을 완료할 수 있으므로 R&D는 많은 운영 및 유지 관리 도구의 세부 사항에 주의를 기울일 필요가 없으며 응용 프로그램 기능 개발에 집중할 수 있습니다. 플랫폼 엔지니어링에 대한 Gartner의 설명은 "플랫폼에서 제공하는 도구, 기능 및 프로세스는 도메인 전문가가 신중하게 선택하고 최종 사용자 편의를 위해 패키지화합니다. 궁극적인 목표는 사용자에게 올바른 최소한의 비용으로 중요한 작업을 수행하여 최종 사용자 생산성을 높이고 인지 부하를 줄이는 데 도움이 되는 기능입니다."
전통적인 가변 인프라는 물리적 머신 또는 가상 서버를 기반으로 응용 서비스를 배포하는 것을 말하며, 운영 환경의 구성은 일부 서버의 구성, 기본 소프트웨어 등과 같이 동적으로 구성되거나 분산될 수 있는 많은 변수에 따라 달라집니다. 실시간으로 외부 서비스에 접속하여 애플리케이션 상태 업데이트 전체 애플리케이션 서비스가 의존하는 인프라는 끊임없이 변화 긴급 롤백이 필요한 시나리오 발생 시 운영 및 유지보수 담당자의 처리 프로세스가 종종 복잡하고 오류가 발생하기 쉽습니다.
클라우드 네이티브 불변 인프라란 클라우드 네이티브 미러링 솔루션을 기반으로 애플리케이션이 의존하는 인프라(운영 체제, 보안 스크립트, 운영 및 유지 관리 에이전트, 개발 프레임워크, 운영 환경 등)가 불변 이미지로 패키징되는 것을 의미합니다. 이미지에 의존하여 컨테이너를 가져오면 애플리케이션의 배포 및 운영 및 유지 관리 비용이 크게 절감되고 애플리케이션 배포 및 운영 및 유지 관리가 더 쉽고 예측 가능해지며 동시에 애플리케이션 운영 환경은 또한 더 높은 일관성과 안정성을 달성합니다. 또한 이미지를 기반으로 자동 회전 교체, 자동 롤백과 같은 O&M 기능을 구현할 수 있어 애플리케이션 O&M의 자동화 수준을 크게 향상시킵니다. 한편으로는 이미지 계층화를 통해 이미지 관리 수준을 향상시킬 수 있고, 다른 한편으로는 이미지 계층화는 컨테이너 로딩 이미지의 원리에 따라 이미지 로딩 효율성을 어느 정도 향상시켜 애플리케이션 시작 속도를 높일 수 있습니다.
요소 2: 탄력적 하이브리드 클라우드
클라우드 아키텍처가 금융기관의 주류 플랫폼 및 인프라가 되면서 사업단위에 따라 탄력적으로 온디맨드 확장이 가능하고, 트래픽 피크 시 리소스 및 애플리케이션 처리 능력을 향상시키기 위해 빠르고 탄력적으로 확장할 수 있으며, 출시가 가능하다. 최대 애플리케이션 트래픽 후 신속하게 자원을 최대한 활용하기 위해 유연하고 저렴한 비용으로 복제할 수 있는 탄력적인 아키텍처를 구축해야 합니다. 탄력적 아키텍처의 본질은 단위화된 아키텍처의 확장으로, 주로 팝업 및 바운스백을 포함하여 단위화된 아키텍처에서 사업 단위의 가장 작은 세분화로 탄력적인 확장을 수행할 수 있는 기능을 제공합니다. 팝업은 비즈니스 단위를 기반으로 컴퓨팅 리소스, 네트워크, 응용 프로그램, 데이터 수준의 포괄적인 팝업으로 하위 수준 리소스에서 상위 계층 트래픽까지의 전반적인 탄력적 수단입니다.팝업 단위를 탄력적 비즈니스라고 합니다. 단위. 일반 사업부와 달리 유연한 사업부는 다음과 같은 특징이 있습니다.
지역성: 일반 모드에서 확장된 각 비즈니스 단위는 모든 애플리케이션과 모든 데이터를 포함해야 하는 반면 탄력적 아키텍처 아래 팝업되는 탄력적 비즈니스 단위는 애플리케이션의 일부와 단위의 데이터 일부만 포함하면 됩니다. 트래픽이 많은 링크 관련 응용 프로그램이 포함됩니다.
일시적: 일반 사업부의 긴 수명 주기와 달리 유연한 사업부의 수명 주기는 상대적으로 짧습니다.'더블 일레븐' 및 기타 대규모 판촉 지불 피크를 지원한 후 유연한 사업부의 비즈니스 요청이 정규로 되돌아갑니다. 탄력적인 사업부를 해제하여 비용을 절감합니다.
크로스 클라우드: 탄력적 사업부는 일반적으로 하나 또는 여러 개의 다른 클라우드에 위치하며 탄력적 아키텍처를 사용하는 시나리오에서 직면하는 트래픽 피크는 일일 트래픽보다 몇 배 더 높으며 일일 클라우드 컴퓨팅 기반이 충분한 리소스를 제공하기 어렵습니다. 시간이 지남에 따라 많은 양의 리소스 지원을 제공하기 위해 다른 클라우드 컴퓨팅 기반이 필요합니다.
탄력적인 아키텍처는 하이브리드 클라우드의 장점을 최대한 발휘합니다.대규모 클라우드 리소스를 통해 응용 프로그램이 무한히 확장되어 극도로 높은 트래픽 피크에 대처할 수 있습니다.트래픽 피크에 도달한 후 리소스를 신속하게 해제하고 리소스를 탄력적으로 확장할 수 있습니다. 수요.
요소 3: 리소스의 혼합 배포
일일 생산에서 고품질 서비스를 보장하기 위해 온라인 서비스 응용 프로그램은 종종 장시간 실행되고 CPU 리소스를 독점하지만 CPU 사용률은 매우 낮습니다. 수명주기 및 리소스 서비스 품질에 미치는 영향 요구 사항은 높지 않지만 런타임 동안 CPU 사용률이 높습니다. 비즈니스 규모가 확장됨에 따라 온라인 비즈니스 클러스터와 오프라인 클러스터의 리소스 풀이 점차 커집니다.비즈니스의 낮은 피크 기간으로 인해 리소스 활용에 문제가 발생할 것입니다.클러스터의 리소스 할당 비율이 높지만 실제 이용률은 낮습니다.
금융 기관은 클라우드 네이티브 아키텍처 구축 과정에서 온라인 및 오프라인 클러스터를 구축합니다. 온라인 및 동적 조정, 다양한 속성 유형의 온라인 서비스 및 오프라인 컴퓨팅 서비스가 정확하게 결합되어 효율적인 자원 활용 문제를 해결합니다. 재무 수준의 복잡성에 따라 다음과 같은 혼합 부서 기능 표준을 설정해야 합니다.
대규모 다중 시나리오 혼합 부서, 혼합 부서 기술을 비즈니스 운영을 위한 인프라 및 환경에 구축하고 혼합 부서 기술 능력의 출력을 향상하며 다른 자원 환경으로의 촉진을 촉진합니다.
혼합 부서 관리 및 제어, 운영 및 유지 보수 시스템의 일관성을 유지하십시오. 리소스 액세스 프로세스를 통합하여 기본 소프트웨어 및 구성의 글로벌 일관성 유지 및 관리를 보장합니다.
리소스 예약, 온라인-오프라인 서비스를 위한 빠른 리소스 전환, 통합 리소스 예약을 위한 유연하고 효율적이며 세분화된 프로세스
혼합 부품의 안정성은 비혼합 부품과 동일한 수준의 안정성 지수에 도달합니다. 세분화된 서비스 측정 공식화, 리소스 격리 및 비즈니스 운영 적응성 향상에 의존합니다.
런타임 모니터링, 이상 발견 및 진단 기능을 개선하기 위한 혼합 모니터링 시스템
혼합부서의 비정상 비상대응 메커니즘은 안정성 리스크에 대한 시나리오를 사전에 파악하고 프로세스 기반의 비상대응 메커니즘을 공식화하여 비정상적이고 신속한 복구 능력을 창출합니다.
요소 4: 여러 기술 스택의 이기종 통합
서비스 메시는 서비스 간의 통신을 처리하는 인프라 계층으로 생각할 수 있습니다. 최신 클라우드 네이티브 애플리케이션에는 복잡한 서비스 토폴로지가 있으며 서비스 메시는 이러한 토폴로지에서 안정적인 요청 전달을 담당합니다. 실제로 서비스 그리드는 일반적으로 애플리케이션과 함께 배포되는 일련의 경량 네트워크 에이전트로, 서비스 간 네트워크 호출, 전류 제한, 퓨즈 및 모니터링을 담당하는 애플리케이션 또는 마이크로 서비스 간의 TCP/IP와 비교할 수 있습니다.
서비스 그리드 기술을 적용하기 전에 마이크로 서비스 시스템의 구현은 비즈니스 애플리케이션을 위한 미들웨어 팀에서 제공하는 경우가 많습니다.SDK는 서비스 검색, 로드 밸런싱, 회로 차단 및 SDK와 같은 다양한 서비스 관리 기능을 SDK에 통합합니다. 전류 제한 및 서비스 라우팅 대기. 런타임 시 SDK와 비즈니스 애플리케이션 코드가 혼합되어 하나의 프로세스에서 실행되며 결합도가 매우 높아 일련의 문제가 발생합니다.
하나의 업그레이드 비용이 높습니다. SDK가 업그레이드될 때마다 비즈니스 애플리케이션은 SDK 버전 번호를 수정한 다음 애플리케이션을 다시 게시해야 합니다. 비즈니스가 빠르게 발전할 때 이러한 업그레이드는 연구 개발의 효율성에 영향을 미칩니다.
둘째, 버전 단편화가 심각하다. 높은 SDK 업그레이드 비용과 미들웨어의 지속적인 개발로 인해 시간이 지남에 따라 일관성 없는 SDK 버전 및 고르지 않은 기능과 같은 문제가 발생하여 통합 관리에 막대한 작업 부하가 발생합니다.
셋째, 미들웨어의 진화가 어렵다. SDK 버전의 심각한 단편화로 인해 미들웨어가 앞으로 진화할 때 코드의 다양한 구 버전 논리와 호환되어야 하며 족쇄를 들고 앞으로 나아가는 것과 같으며 빠른 반복을 달성할 수 없습니다.
금융 기관의 서비스 그리드는 기본 RPC, 메시지 및 DB 액세스 기능은 물론 서비스 검색, 융합, 전류 제한, 트래픽 제어, 하위 데이터베이스 기능을 포함하여 SDK를 통해 원래 통합된 일부 네트워크 통신 기능을 Sidecar에 싱크합니다. 데이터베이스의 하위 테이블은 비즈니스 시스템에 보다 투명한 통신 인프라를 제공하고, 비즈니스 시스템에서 인프라의 반복적인 진화를 분리하고, 비즈니스 연구 및 개발이 비즈니스 논리에 집중할 수 있도록 하고, 비즈니스 시스템에 대한 부담을 줄입니다. 시스템 및 인프라의 비즈니스 반복 효율성 향상.
요소 5: 인프라의 연속성(공공 및 민간 통합)
점점 더 많은 핵심 시스템이 완전한 클라우드 네이티브화로 이동함에 따라 대규모 리소스의 스케줄링 및 오케스트레이션은 금융 인프라의 연속성을 위해 없어서는 안 될 기능이 되었습니다. 금융 기관의 다양한 비즈니스 부서에서 수천 개의 애플리케이션에 서비스를 제공하는 방법, 다양한 애플리케이션이 클라우드를 잘 사용하도록 하는 방법, 다양한 애플리케이션의 리소스 요구 차이를 충족하고 클라우드 기능을 최대한 활용하여 비즈니스 성장을 지원하는 방법, 인프라 연속성은 퍼블릭 클라우드와 같은 통합 리소스 관리 기능이어야 하며, 여기에는 기존의 범거래 및 데이터 시나리오뿐만 아니라 대규모 컴퓨팅에서 GPU로 대표되는 새로운 이기종 컴퓨팅 하드웨어의 채택 증가도 포함됩니다. 학습 교육 작업, 온라인 추론 작업, 스트리밍 미디어 인코딩 및 디코딩 작업 등에는 더 풍부한 리소스 컴퓨팅 시나리오가 필요합니다.
기본 리소스의 통합 운영 및 관리를 위한 통합 인프라 연속성은 공급망, 용량 예측, 용량 계획 및 리소스 풀 탄력성과 같은 여러 차원에서 풍부한 클라우드 네이티브 기술 수단을 통해 비용을 최적화하고 효율성을 향상시킬 수 있습니다. 제어, 기본 리소스의 누수 제로, 평평하고 관리하기 쉽고 유연하고 구성 가능하며 유연한 방식으로 모든 시나리오를 지원합니다.
요소 6: 전체 링크 기술 위험 방지 및 제어
금융 업무 시스템의 많은 생산 실패는 변경으로 인해 발생하며 변경 제어는 기술적 위험을 예방하고 통제하는 데 중요합니다. 특히 마이크로서비스 분산구조 하에서는 서비스 규모가 방대하고 변화의 원천이 광범위하여 변화가 강력한 통제력과 추적능력을 갖추지 못한 경우 온라인상에서 한번 문제가 발생하면 최초에 해당 변화를 빠르게 발견하기 어렵다. 또한 변경 자체의 품질을 효과적으로 제어하기 어려우므로 전체 링크에 걸쳐 위험과 변경을 관리하고 제어할 수 있는 클라우드 네이티브 아키텍처 기반의 "기술적 위험 예방 및 제어 시스템 .
기술 위험 예방 및 제어의 핵심 지침 원칙은 관찰 가능, 그레이스케일 및 비상이라는 "3가지 변경 트릭"입니다. 모든 변화는 예상되는 효과를 평가하고, 예상치 못한 문제를 식별하고, 비상 대응 조치에 대한 변경 범위 및 의사 결정의 추가 확장을 안내하기 위해 구현 전에 관찰 가능한 기능을 배치해야 합니다. "그레이스케일"은 변화가 점진적으로 범위를 확장하고 지역, 데이터 센터, 환경, 서버, 사용자 및 시간과 같은 여러 차원에서 그레이스케일 프로세스를 설계해야 함을 강조합니다. "긴급"은 변경 계획이 롤백 기능을 보장하는 데 우선 순위를 두어야 함을 강조합니다. 특수한 상황으로 인해 일부 변경에는 롤백 기능이 없거나 롤백 비용이 허용되지 않을 수 있습니다. 이는 데이터와 같은 다른 변경 사항을 추가하여 처리해야 합니다. 수정. , 새 버전 온라인 등 "변화의 3축"은 금융 클라우드 네이티브 아키텍처에서 변경 위험 제어의 핵심 기능이기도 합니다. 기능 통합, 일부 퓨즈 구축 및 변경 프로세스 동안 자가 치유 기능.
"전체 링크 위험 방지 및 제어 시스템"의 핵심 책임은 모든 변경 정보를 통합하여 변경 사항을 가시화하고 보다 추적 가능하게 만드는 것입니다. 동시에 변경 배치, 변경 그레이 스케일 검사, 변경 사전 확인, 변경 결과 모니터링 및 조기 경고와 같은 기능을 제공하며, 문제 발생 시 변경 연관을 제공하여 온라인 문제 처리 속도를 높입니다.
또한 전체 링크 위험 예방 및 제어 시스템은 자본 손실 위험 포인트 분석을 생성하고 예방 및 제어 조치를 공식화하며 계획의 세부 사항을 명확히 할 수 있어야 합니다. 품질 테스트 및 분석 단계에서 테스트 및 자본 검증 분석을 수행해야 합니다. 공개 전 실시간 검증, T+M 분 단위 검증, T+H 시간 단위 검증, T+ 등 자본 손실 방지 및 통제 조치 이행 여부를 확인하기 위해 리스크를 다시 평가할 필요가 있다. 1 익일검증 등 "조기경보를 확인하기 위해 가입함과 동시에 사업측은 자금흐름을 완전히 수용해야 한다. 자금 흐름 작업은 인증서, 인증서, 계정 및 계정과 같은 확인 모드를 통해 수행됩니다.
요소 7: 클라우드 네이티브 보안 및 신뢰성
현재 인터넷 환경의 외부 위협은 다양하고 새로운 경향을 보이고 있으며, 기존의 방어 방식은 알려진 취약점 익스플로잇과 위협 공격 방식에 대해서는 잘 대응하지만 APT 공격, 0Day 취약점 공격 등에 대해서는 잘 대처하지 못하고 있습니다. . 그러나 이러한 알려진 위협과 새로운 위협은 공통적인 특징을 공유합니다. 즉, 모두 비즈니스에서 예상하지 않는 동작입니다. 이 기능을 기반으로 클라우드 네이티브 기술은 모든 서비스 요청 및 리소스 로드 동작에 대한 신뢰할 수 있는 측정을 수행하고 신뢰할 수 있는 동작을 기반으로 하는 심층 보안 방어 시스템을 구축하여 예상된 동작만 액세스하고 성공적으로 실행할 수 있도록 해야 합니다. 알려지거나 알려지지 않은 위협에 저항하는 효과를 달성하기 위해 차단하고 차단합니다.
동시에 금융 산업에서 비즈니스 엔터티 간의 보안 격리를 보장하기 위해 인프라와 같은 기술 서비스도 독립적인 격리된 네트워크 환경과 더 높은 수준의 보안으로 비즈니스 엔터티와 격리된 환경을 구축해야 합니다. 클라우드 네이티브 플랫폼 기술 서비스는 신뢰할 수 있는 네이티브 서비스 표준에 따라 다중 테넌트 격리, 통합 관리 및 제어, 신뢰할 수 있는 채널 융합과 같은 관련 변환을 통해 신뢰할 수 있는 네이티브 서비스로 업그레이드됩니다. 응용 프로그램이 실행되는 환경의 경우 클라우드 네이티브 안전하고 신뢰할 수 있는 아키텍처는 인프라에 ID, 인증, 권한 부여, 전체 링크 액세스 제어 및 전체 링크 암호화와 같은 보안 및 신뢰할 수 있는 기능을 내장하고 실현합니다. 애플리케이션의 분리는 신뢰할 수 있는 기본 방식으로 서비스 중단을 줄이고 신뢰할 수 있는 애플리케이션 운영 환경을 제공합니다.
요소 8: 재정 수준의 일관성
클라우드 네이티브 응용 프로그램은 주로 분산 시스템이며 응용 프로그램은 여러 분산 마이크로 서비스 시스템으로 나뉩니다.분할은 일반적으로 수평 분할과 수직 분할로 나뉩니다.이것은 데이터베이스 또는 캐시를 의미할 뿐만 아니라 분할은 주로 분할을 표현하고 아이디어와 논리를 정복하십시오.
분산 시스템의 최하위 계층은 "CAP의 불가능한 삼각형" (C: 일관성, 일관성, A: 가용성, 가용성, P: 파티션 허용 오차, 파티션 허용 오차)을 벗어날 수 없습니다. CAP 원칙은 모든 분산 시스템이 위의 두 가지 사항만 동시에 충족할 수 있으며 세 가지를 모두 처리할 수 없음을 증명합니다. 그러나 분산 서비스 시스템은 파티션 허용 오차를 충족해야 하므로 일관성과 가용성 사이에서 균형을 이루어야 합니다. 네트워크에서 비정상적인 상황이 발생하면 분산 시스템의 일부 노드 간 네트워크 지연이 계속 증가하여 분산 시스템에서 네트워크 분할이 발생할 수 있습니다. 복사 작업이 지연될 수 있습니다. 사용자가 복사가 완료될 때까지 기다렸다가 반환하면 제한된 시간 내에 반환할 수 없어 가용성을 잃을 수 있습니다. 사용자가 복사가 완료될 때까지 기다리지 않고 기본 샤드 작성 후 바로 반환하면 사용성은 있지만 일관성이 떨어집니다.
금융 기관의 경우 아키텍처 수준의 고가용성과 비즈니스 수준의 강력한 일관성이 거의 똑같이 중요합니다. 이를 위해서는 재무적 수준의 클라우드 네이티브가 "CAP의 불가능한 삼각형"의 균형을 잘 맞출 수 있어야 하며, 강력한 비즈니스 일관성과 높은 시스템 가용성을 최대한 고려할 필요가 있습니다.
그러나 "일관성 문제"는 분산 시스템의 데이터베이스 문제뿐만 아니라 트랜잭션 일관성, 노드 일관성, 시스템 간 비즈니스 일관성, 메시지 성능 등 분산 시스템의 모든 수준을 다루는 큰 주제입니다. IDC 일관성 등 따라서 클라우드 네이티브 아키텍처에는 재무 수준의 일관성이라는 엄격한 과제에 대처할 수 있는 일련의 기술이 필요합니다.
거래 수준: 서로 다른 재무 시나리오에 따라 적절한 분산 거래 모델을 선택해야 합니다.비용과 성능의 균형을 맞춘 후 SAGA와 TCC는 금융 기관에서 일반적으로 사용하는 두 가지 분산 거래 모델입니다. SAGA 모드는 응용 프로그램 구현에 덜 방해가 되지만 설계의 일관성을 보장하기 위해 보상 트랜잭션을 기반으로 하며 이전 및 후속 단계를 실행하는 동안 트랜잭션 격리가 보장되지 않습니다. 더 나은 트랜잭션 격리가 필요하지만 더 복잡한 애플리케이션 계층 인식이 필요합니다. 결과를 동기적으로 반환할 필요가 없는 트랜잭션 프로세스의 일부 노드에 대해 비동기 메시지 큐를 사용하여 실행 효율성을 높일 수 있습니다.긴 트랜잭션 프로세스가 있는 일부 시나리오에서 트랜잭션 구현의 복잡성을 크게 줄이고 피크 및 채우기를 줄일 수 있습니다. 계곡. 고객이 자산 관리를 구매하는 것과 같은 일반적인 시나리오는 예금 계좌 공제와 자산 관리 계좌 신용의 두 단계로 단순화됩니다."to"의 비정상적인 상태에서 시스템은 거래 일관성을 보장하기 위해 예금 계좌 공제를 취소해야 합니다. TCC 모드를 선택하면 예금계좌 차감과 자산관리계좌 입력 로직 처리가 순차적으로 완료되며, 예금시스템과 자산관리시스템은 각각 로직 처리 상태를 기록해야 한다. 시작됩니다.
데이터베이스 수준: 금융 시나리오에서 데이터가 손실되지 않도록 하는 극단적인 요구 사항이 있습니다.한편으로는 같은 도시 또는 다른 장소에 있는 여러 컴퓨터실에 여러 복사본을 저장해야 합니다.Off-site RPO는 가깝습니다. 0으로. Paxos 알고리즘은 메시지 전달을 기반으로 분산 시스템에서 데이터 일관성을 달성하기 위한 알고리즘 중앙 데이터 일관성 보장.
전산실 수준: 전산실 간 라우팅 기능 및 비정상 트랜잭션에 대한 전산실 간 복구 기능. 전산실에서 장애가 발생하면 데이터베이스는 동일한 시외 사본으로 전환할 수 있어야 하며 RPO가 0인지 확인하고 애플리케이션 계층에서 트랜잭션 라우팅 전환과 협력하여 전산을 완료해야 합니다. 룸 레벨 재해 복구 스위치 및 비즈니스 복원. 전산실 장애로 인해 거래 프로세스의 일부가 중단되는 동안 분산 트랜잭션 구성 요소는 자동으로 복구하고 중단된 트랜잭션 프로세스를 다시 시작하여 사전 설정된 비즈니스 규칙에 따라 정방향 또는 역방향으로 완료할 수 있어야 합니다. .
요소 9: 단위화, 여러 위치 및 여러 활동
디지털 금융 서비스의 급속한 발전으로 인해 전통적인 중앙 집중식 생산 환경은 수요를 충족시키기 어려웠습니다. 현재 진화 방향은 높은 적시성 및 재정적 수준의 보안 요구 사항을 충족하기 위해 통합 전산실(이하 LDC)을 기반으로 "다른 장소에서 멀티 액티브"의 통합 구조입니다.
금융 기관에서 일반적으로 채택하는 "두 장소에 세 개의 센터" 아키텍처에는 몇 가지 일반적인 결함이 있습니다. 첫째, 이 아키텍처는 완전한 전환을 충족하기 위해 유사한 컴퓨터실 용량을 갖기 위해 동일한 도시에 있는 두 개의 센터가 필요합니다. 둘째, 이 아키텍처 모델에서 원격 재해는 복구 시스템은 일반적으로 "콜드" 시스템으로 실제로 비즈니스 트래픽을 전달하지 않으며 재해 발생 시 전체 비즈니스를 인계받기 어렵습니다. 새로운 데이터 센터는 일반적으로 내몽고, 구이저우와 같은 전통적인 데이터 센터에서 멀리 떨어진 지역에 집중되어 있고 신규 데이터 센터와 기존 데이터 센터의 용량 비율이 매우 불균형하기 때문에 금융 기관은 "2개의 3개 센터"를 돌파해야 합니다. 기존 모델은 N+1 "멀티액티브" 재해 복구 솔루션으로 발전하여 장애 복구의 시스템적 기능을 더욱 향상시킵니다.
"원격 다중 활성 아키텍처"는 LDC 장치 아키텍처를 기반으로 한 확장 기능을 의미합니다. LDC 장치는 다른 지역의 IDC에 배치되며 각 LDC 장치는 "라이브"이므로 실제 비즈니스 트래픽을 라인에서 수행합니다. 장애 발생 시 LDC 장치 간 빠른 전환이 가능합니다. 원격 다중 활성 장치 아키텍처는 다음 네 가지 주요 문제를 해결합니다.
장치 간 상호 작용 최소화 및 비동기 사용으로 인해 오프 사이트 배포가 가능합니다. 전체 시스템의 수평적 확장성이 크게 향상되어 더 이상 동일한 도시 IDC에 의존하지 않습니다.
N+1 원격 재해 복구 전략을 실현하여 재해 복구 비용을 크게 절감하는 동시에 재해 복구 시설의 진정한 가용성을 보장할 수 있습니다.
전체 시스템에 단일 지점이 없어 전체 고가용성이 크게 향상되며, 동일한 도시와 다른 장소에 배치된 여러 대의 장치를 상호 백업을 위한 재해 복구 시설로 사용할 수 있으며 운영 및 유지 보수를 통해 신속하게 전환할 수 있습니다. 100% 지속적인 가용성을 달성할 기회가 있는 관리 및 제어 플랫폼
이 아키텍처에서 서비스 수준의 트래픽 진입과 퇴장은 통합 제어 및 라우팅 제어 지점을 형성하며 전체 시스템의 제어 가능성이 크게 향상됩니다. 이 아키텍처를 기반으로 온라인 압력 측정, 트래픽 제어 및 그레이 스케일 릴리스와 같이 이전에 구현하기 어려웠던 운영 및 유지 보수 관리 및 제어 모드를 이제 매우 쉽게 구현할 수 있습니다.
요소 10: 비즈니스 연속성 및 디지털 인텔리전스 운영 및 유지 관리
클라우드 네이티브 환경에서는 서비스가 다운된 이유와 정의된 SLO가 구현되지 않은 이유에 대한 답을 얻기 위해 여러 컨테이너, 여러 가상 머신, 여러 호스트, 여러 가용 영역, 심지어 여러 지역에 대한 정보를 연관시켜야 합니다. 장애 등의 영향을 받는 사용자와 기업은 운영 및 유지 관리 데이터와 AI 인텔리전스를 기반으로 효율적인 디지털 지능형 운영 및 유지 관리를 실현할 수 있습니다.
클라우드 네이티브 디지털 지능형 운영 및 유지 관리에는 주로 기능의 7가지 측면이 포함됩니다.
모니터링 및 검색 기능: 지표, 로그 및 링크의 전방향 관찰 가능성, 서비스, 미들웨어 및 인프라의 포괄적인 범위, 드릴다운 기능.
오류 비상 대응 기능: 비정상적인 포괄적인 검색, 신속한 위치 파악 및 복구 기능을 통해 비즈니스 SLA를 보장합니다.
변경 위험 방지 및 제어 기능: 전면적인 비즈니스 변경 관리 및 제어, "그레이 스케일 가능, 관찰 가능 및 롤백 가능"의 세 가지 축을 엄격히 준수합니다.
용량 관리 기능: 비즈니스에서 인프라에 이르기까지 전체 링크 용량에 대한 정확한 평가와 위험의 조기 식별을 제공하여 안정성과 비용 간의 균형을 달성합니다.
재해 복구 관리 기능: 플랫폼 기반 재해 복구를 배치할 수 있으며 전산실 재해 복구, 통합 재해 복구 및 기타 시나리오, 적용 훈련, 전환 및 대형 화면 기능을 지원합니다.
드릴 및 평가 기능: 카오스 엔지니어링, 적색 및 청색 공격 및 방어 등을 통해 비즈니스 위험 보증 기능을 감지하고 테스트합니다.
자본 보안 보증 기능: 자본 보안 점검 규칙을 기반으로 비즈니스 시스템의 자본 흐름을 오프라인, 실시간, 파일 및 기타 방법을 통해 모니터링합니다.
클라우드 네이티브 디지털 지능형 운영 및 유지 관리에는 주로 세 가지 특성이 있습니다.
효율성: 운영 및 유지 관리 작업의 플랫폼화를 통해 운영 및 유지 관리 효율성을 향상시킵니다. 시스템 모니터링 플랫폼, 변경 관리 및 제어 플랫폼, 동적 자원 관리 및 제어 플랫폼, 스케줄링 센터, 등록 센터 등
보안: 자동 비즈니스 검증 플랫폼 및 빅데이터 운영 규칙을 기반으로 시스템 운영의 안정성과 정확성을 보장합니다. 데이터 검증 센터, 종속성 관리 및 제어 플랫폼, 용량 감지 관리 및 제어 플랫폼 등
인텔리전스: 빅데이터 분석 및 규칙 계산을 기반으로 지능적인 운영 및 유지 관리 및 제어. 자동 고장 분석 및 처리 시스템, 자동 용량 감지 및 확장 시스템 등
금융 클라우드 네이티브를 위한 새로운 청사진 구축
금융 등급 클라우드 네이티브 애플리케이션 아키텍처
"Architecture is the Future"라는 책은 가장 중요한 클라우드 네이티브 애플리케이션 아키텍처의 핵심 요소인 분산 애플리케이션 설계의 14가지 기본 원칙을 제시합니다.
N+1 설계 : 개발하는 모든 시스템에 장애 발생 시 최소한 하나의 중복 인스턴스가 있는지 확인하십시오. 롤백 설계 : 시스템을 이전에 릴리스된 버전으로 롤백할 수 있는지 확인합니다.
Switch Disable Design : 게시된 기능을 끄는 기능. 모니터링 설계 : 모니터링은 구현이 완료된 후에 추가되는 것이 아니라 설계 단계에서 고려되어야 합니다.
다중 활성 데이터 센터 설계 : 설계 시 다중 활성 배치를 고려하고 데이터 센터 솔루션에 제한을 두지 마십시오.
비동기 설계 : 비동기는 동시성에 적합하며 절대적으로 필요한 경우에만 동기 호출을 수행합니다.
상태 비저장 시스템 : 상태 비저장 시스템은 확장 및 로드 밸런싱에 더 도움이 됩니다. 비즈니스에서 실제로 필요할 때만 상태를 사용하십시오.
수직적 업그레이드가 아닌 수평적 확장 : 더 크고 빠른 시스템에 의존하지 마십시오. 마이크로서비스의 핵심 아이디어는 모든 기능을 하나의 시스템에 집중시키는 것이 아니라 수평적으로 확장하는 것입니다. 필요한 경우 기존 시스템을 업그레이드하는 대신 요구 사항을 여러 시스템으로 분할합니다.
미래지향적 설계 : 다음 단계의 시스템 확장성 문제에 영향을 미치는 솔루션을 미리 고려하고 공용 공유 서비스를 지속적으로 개선하여 리팩토링 횟수를 줄입니다.
핵심이 아닌 경우 구매 : 자신이 가장 잘하는 것이 아니고 차별화된 경쟁 우위를 제공하지 않는 경우 직접 구매하십시오. 데이터베이스, 클라우드 서비스 등을 구매할 수 있습니다.
작은 빌드, 작은 릴리스, 빠른 시행착오 : 모든 R&D에는 시스템이 지속적으로 성장할 수 있도록 작은 빌드와 지속적인 반복이 필요합니다. 소규모 릴리스는 실패율이 솔루션의 변경 횟수와 직접적인 관련이 있기 때문에 실패율이 낮습니다.
결함 분리 : 분리된 결함의 설계를 실현하고 개방 회로 보호를 통해 결함 전파 및 교차 효과를 방지합니다. 여러 시스템 간의 상호 영향을 피하는 것이 매우 중요합니다.
자동화 : "자동화는 지혜의 원천" 클라우드 네이티브 아키텍처에서는 신속한 배포와 자동화된 관리가 핵심입니다. 디자인은 아키텍처와 디자인을 통해 최대한 자동화하는 과정에서 시작됩니다. 기계가 할 수 있다면 인간에게 의존하지 마십시오.
검증된 기술 사용 : 실패율이 높은 기술은 절대 사용해서는 안됩니다.
금융 등급 클라우드 네이티브 플랫폼 아키텍처
전체 금융 클라우드 네이티브 플랫폼 아키텍처는 설계 영역, 연구 개발 영역, 운영 영역, 운영 및 유지 관리 영역, 재해 복구 영역의 5가지 주요 영역으로 나눌 수 있습니다.
디자인 모드: 마이크로 서비스 아키텍처 시스템과 자연스럽게 호환되는 도메인 중심 디자인 및 기타 디자인 방법을 채택하고 디자인 프로세스 중에 데이터 일관성 및 서비스 세분화와 같은 문제에 주의를 기울이고 분산 아키텍처 디자인의 디자인 원칙 및 사양을 구현합니다. .
R&D 상태: R&D 인력을 위해 원스톱 R&D 생산성 도구를 제공하고 분산 기술의 복잡성을 보호하며 R&D 인력의 경험과 생산성을 향상시킵니다. 조직의 인지 비용을 줄이기 위해 광범위한 합의 엔지니어링 템플릿에 도달합니다.
실행 상태: 생성, 배포, 모니터링 및 구성 변경을 포함하여 애플리케이션의 전체 수명 주기를 포괄하고 다양한 형태의 애플리케이션 상호 작용 및 데이터 저장을 지원하는 분산 애플리케이션 운영을 위한 애플리케이션 지향 인프라입니다. 최하위 계층은 다양한 형태의 컴퓨팅 방법과 그에 대한 스케줄링 방법을 지원합니다.
운영 및 유지 보수 상태: 운영 및 유지 보수 인력을 위해 분산 아키텍처의 고유한 복잡성을 해결하고 엔지니어링 방법을 광범위하게 사용하여 시스템의 전반적인 가용성을 보장합니다.
재해 복구 상태: 재해를 지향하며 노드 수준, 전산실 수준, 도시 수준에서 재해를 견딜 수 있는 기능을 제공합니다.
재무급 클라우드 네이티브 데이터 아키텍처
클라우드 네이티브 프레임워크는 빠른 전달, 탄력적 확장, 표준화, 자동화 및 격리와 같은 고유한 장점을 가지고 있으며, 차세대 데이터 기술과 지속적으로 통합되어 다음과 같은 특징을 가진 클라우드 네이티브 데이터 아키텍처 시스템을 형성합니다.
1. 여러 컴퓨팅 모드의 확장 가능한 융합
클라우드 네이티브 데이터 아키텍처는 배치, 스트림, 대화식, 다중 모드 및 그래프와 같은 다양한 컴퓨팅 모드의 통합을 균일하게 지원할 수 있습니다. 예: 호수 및 창고 통합, 스트림 및 배치 통합, 스트림 기계 학습 다양한 컴퓨팅 시스템의 긴밀한 통합을 가능하게 합니다.보완적인 기능과 생태계를 통해 사용자는 하나의 시스템에서 더 많은 유형의 계산을 완료하고 플랫폼 운영 효율성을 향상시키며 사용 비용을 절감할 수 있습니다.
2. 다중 계층 지능형 분산 스토리지 계층
스토리지와 컴퓨팅의 분리는 2~3년 내에 표준이 될 것이며 데이터 플랫폼은 호스팅 및 클라우드 네이티브 방향으로 발전할 것입니다. 스토리지 내 세분화된 계층화는 성능과 비용의 균형을 맞추는 핵심 수단이 되었습니다. 줄인. AI는 계층화된 알고리즘에서 더 큰 역할을 할 것이며 범용 프로세서에서 인코딩 및 압축을 위한 제한된 최적화 공간의 경우 향후 혁신 및 기술 업그레이드는 소프트웨어 및 하드웨어 통합의 기술 개발 및 적용에 달려 있습니다.
3. 통합 스케줄링 및 탄력적 확장 리소스 풀 관리
데이터 레이크 스토리지와 컴퓨팅의 분리가 심화됨에 따라 클라우드 네이티브 아키텍처를 기반으로 하는 통합 컨테이너형 리소스 스케줄링 시스템의 구축은 데이터 레이크 스토리지 및 컴퓨팅 분리 개발에 필요한 구성 요소가 되어 통합 리소스 풀링과 오프라인을 제공합니다. 빅 데이터와 AI의 통합 아키텍처를 위한 스토리지.혼합 부서의 기본 지원, 통합 컴퓨팅 파워 자원 풀을 통해 자원의 전반적인 계획 및 스케줄링을 실현하고 세분화된 자원의 관리 및 스케줄링을 최적화하며 오프라인에서 결합할 수 있습니다. 컴퓨팅 및 기타 온라인 컴퓨팅 작업을 통해 최고점과 최저점의 상보성 효과를 달성하여 서버 리소스 활용도를 높이는 동시에 컴퓨팅 작업 리소스를 비즈니스 우선 순위에 따라 할당하여 리소스 예약 중에 경합이 없도록 할 수 있습니다. 피크 비즈니스 기간 동안 컴퓨팅 파워 리소스를 탄력적 확장 및 수축 모드로 호출하여 리소스 컴퓨팅 파워를 최대한 발휘할 수 있도록 응답 효율성을 향상시킵니다.
4. 빅데이터 SRE 지능형 운영 및 유지보수 역량
빅데이터 기술의 다양성과 데이터 플랫폼 아키텍처의 복잡성으로 인해 빅데이터 플랫폼의 운영 및 유지 관리에 어려움이 있습니다. 차세대 빅 데이터 플랫폼은 온라인 롤링 업그레이드를 지원하여 업그레이드 시간을 단축하고 다양한 이기종 워크로드 프로세스의 통합 운영, 작업 수명 주기의 통합 관리, 태스크 워크플로우의 통합 스케줄링을 제공하고 태스크의 규모와 성능을 보장할 수 있습니다. 작업 로그, 성능 지표, 리소스 사용률 및 기타 데이터는 과거 기록 및 실시간 부하 조건과 결합하여 기계 학습 방법을 사용하여 쿼리 계획, 데이터 모델, 리소스 관리 자체 적응 및 시스템 이상을 분석, 감지 및 최적화합니다. 탐지 및 자가 치유 등 지속적인 최적화 측면에서 대규모 데이터 플랫폼의 지능형 운영 및 유지 관리 기능을 형성합니다.
금융 등급 클라우드 네이티브 인프라
금융 등급 클라우드 네이티브 인프라는 5가지 일반 요구 사항과 13가지 관리 요구 사항을 충족해야 합니다.
(1) 다섯 가지 일반 요구 사항은 다음과 같습니다.
하나는 성숙한 클라우드 플랫폼 제품을 채택하여 IaaS와 PaaS의 통합 클라우드 컴퓨팅 플랫폼을 만들고 테넌트 측과 운영 및 유지 보수 측에서 완전한 서비스 카탈로그를 실현하고 소프트웨어 개발 시스템과 생산 운영 및 유지 보수와 원활하게 연결하는 것입니다. 체계;
두 번째는 전사적 기본 자원의 유연한 공급을 실현하고 안전한 생산 요구 사항을 충족하기 위해 분산 기술 프레임워크에 따라 고가용성 재해 복구 아키텍처를 실현하기 위해 전사적 비즈니스 시스템을 지원하는 것입니다.
세 번째는 정보 기술 응용 프로그램의 혁신 요구 사항을 완전히 충족하는 것입니다.클라우드 플랫폼 기반에서 소프트웨어 서비스에 이르기까지 전체 링크 정보 기술 응용 프로그램을 혁신하고 실행하는 동시에 분산 응용 프로그램의 고성능 및 안정적인 작동을 보장합니다. ;
넷째, 클라우드에 대규모 애플리케이션을 제공할 수 있는 기반을 갖추고 있으며, 완전한 애플리케이션 프레임워크를 제공하고 애플리케이션 시스템에 대해 안정적이고 지속적이며 고성능 지원을 제공합니다.
다섯째, 클라우드 플랫폼 제품에는 성숙한 생태계가 있어 기본적으로 업계의 퍼블릭 클라우드 기술 발전과 보조를 맞추고 최신 오픈 소스 기술의 진화에 적응합니다.
(2) 13가지 관리 능력 요건은 다음과 같습니다.
통합 리소스 관리: 통합된 물리적 리소스 유형 및 아키텍처를 사용하여 서버, 스위치, 운영 체제 등과 같은 기본 하드웨어 리소스의 통합 관리를 실현합니다. 클라우드 관리 플랫폼은 통합 관리 방법(콘솔, API 등), 스토리지, 네트워크 및 기타 클라우드 리소스를 관리하여 개발 및 운영 및 유지 보수의 복잡성을 줄입니다.
통합 데이터 관리 : 도시 내 활성-활성 및 원격 다중 활성 구조에 대해 데이터 저장, 마이그레이션, 동기화 등을 통해 분산 클라우드 노드의 데이터 일관성을 보장하고 통합 재해 복구 및 연계 전환 기능을 제공하여 비즈니스를 충족시킵니다. 최대 범위의 연속성 요구 사항. 예를 들어 통합 미러링 솔루션, 오브젝트 스토리지 재해 복구, 데이터베이스 교차 지역 백업 및 동기화 등을 제공합니다.
통합 서비스 관리: 서비스 배포 및 업데이트를 위한 통합 컨트롤 플레인과 같은 통합 API, SDK, 콘솔 등을 통해 클라우드 서비스를 관리하기 위해 두 곳에서 세 개의 중앙 노드를 지원하여 클라우드 서비스 관리의 복잡성을 크게 줄이고 효율성을 향상시킵니다. 클라우드 사용의.
통합 운영 및 유지 관리: 클라우드 관리를 통해 동일한 운영 및 유지 관리 시스템을 사용하여 두 곳에서 세 개의 센터에 있는 서로 다른 노드를 관리할 수 있으므로 일관된 운영, 모니터링, 안정성 SLA 및 기타 서비스를 제공하여 운영 및 유지 관리 관리자의 작업 부하를 줄입니다. 운영 및 유지 보수 효율성을 향상시켜 시스템 오류를 크게 줄이고 가동 중지 시간을 단축합니다.
통합 보안 관리: 한편으로는 물리적 인프라, 네트워크 보안, 데이터 플레인/컨트롤 플레인 격리 등을 통해 플랫폼 측 보안을 구현하고, 다른 한편으로는 호스트 보안, 액세스 제어, 방화벽, 통합보안 확보를 위한 상황인식 등
Unified Resource Scheduling: 클라우드 관리를 통해 3개 센터의 컴퓨팅 파워 리소스를 두 곳에서 통합 스케줄링하고 다양한 스케줄링 전략을 지원합니다. 위치 기반 스케줄링은 지연 및 대역폭에 민감한 서비스(예: 모바일 뱅킹 오디오 및 비디오 애플리케이션)를 충족하고 컴퓨팅 기반 스케줄링은 AI, 빅 데이터 및 기타 대규모 컴퓨팅 서비스(예: 조수 스케줄링, 혼합 부서 및 기타 시나리오)를 충족합니다. ; 기반 워크로드 스케줄링은 다차원 및 이기종 시나리오(예: 금융 공황 구매, 포인트 교환, Double 11 및 기타 애플리케이션 시나리오)를 충족합니다.
통합 모니터링 관리: 클라우드 및 클라우드 외부의 다양한 모니터링 지표에 대한 액세스 및 통합 표시를 완료하고 클라우드 및 클라우드 외부의 분산 링크 추적 기능을 완료하고 비즈니스 모니터링에서 계층별 모니터링을 실현합니다. 애플리케이션 서비스 모니터링 및 리소스 모니터링 드릴다운 및 다차원 분석을 통해 결함 위치 및 분석 기능을 개선하고 통합 알람 센터의 도킹 및 최적화를 통해 동적 임계값을 완료하고 전반적인 비즈니스 이벤트 인식 기능, 신속한 위치 지정 기능 및 지능형 분석 및 의사 결정 기능.
다중 컴퓨팅 성능 지원: 클라우드 리소스 풀은 CPU 및 GPU와 같은 다중 컴퓨팅 성능과 호환되며 인공 지능, 딥 러닝 및 과학 컴퓨팅과 같은 다중 필드 시나리오에서 새로운 금융 기술 응용 제품에 효율적인 클라우드 컴퓨팅 성능 서비스를 제공합니다. .
전체 스택 정보 기술 응용 프로그램 혁신 지원: 다중 제품 서비스 기능과 호환되는 시스템을 통해 하나의 클라우드 다중 코어, 전체 스택 XC 클라우드 플랫폼 서비스 기능을 지원하고 정보 기술 응용 프로그램 혁신 전략의 구현을 촉진합니다.
정교한 관리 지원: 플랫폼의 계량 및 청구 기능과 업계의 다양한 시스템과의 연결을 통해 컴퓨팅, 스토리지, 네트워크, 보안 및 기타 리소스의 계량 및 청구 기능이 실현됩니다. IT 비용의 세련된 관리를 점진적으로 실현하고 비즈니스 IT 투자 및 비즈니스 성과의 측정 및 평가를 실현하며 비용과 효율성 간의 균형을 실현하고 IT 리소스의 효율적인 사용을 실현합니다.
베어 메탈 관리 지원: 서버 랙킹, 자동 설치, 시스템 설정 및 소프트웨어 오케스트레이션에서 베어 메탈 전달 프로세스 자동화 및 일괄 처리를 충족하고 전달 효율성을 개선하고 수동 워크로드를 줄이며 베어 메탈 통합 관리 요구 사항을 충족하고 베어 메탈의 통합 모니터링 및 관리를 실현합니다. 금속 경보.
서비스 품질 지원 : 셀프 서비스 기능 향상을 통해 인프라 관리 플랫폼의 구축은 효율적이고 안정적인 운영과 더 나은 서비스를 제공하기 위한 세련된 관리를 제공할 수 있으며, 플랫폼의 데이터 수집 및 분석에 따라 효과적으로 개선될 것입니다. 관리 방향과 내용을 파악하고 서비스 품질을 효과적으로 향상시킬 수 있습니다.
지원 아키텍처 개발: 업계 최고의 독점 클라우드 아키텍처를 채택하고, 퍼블릭 클라우드와 동일한 소스로 클라우드 플랫폼을 구축하고, 금융 산업의 재해 복구 요구 사항을 충족하고, 일련의 시스템을 통해 모든 제품을 지원하고, 미래 풀스택 클라우드 플랫폼의 역량강화에 부합하는 유기적이고 통일된 아키텍처 설계를 통해 은행 전체의 온오프라인 통합 운영 및 유지관리 시스템을 구축합니다.
05 재무 수준의 클라우드 네이티브 구현 경로
재무 수준의 클라우드 네이티브 기능 평가
"미래에 투자하는 가장 좋은 방법은 현재를 개선하는 것입니다."
금융 수준의 클라우드 네이티브는 디지털 시대의 배당금을 크게 방출했습니다. 클라우드 네이티브는 클라우드의 설계 아이디어를 완전히 상속합니다. 앞으로 더 많은 애플리케이션이 클라우드를 기반으로 개발될 것입니다. 즉, 클라우드 네이티브 애플리케이션은 클라우드 아키텍처에 더 적합하고 클라우드 컴퓨팅은 또한 리소스 격리 메커니즘, 분산 배포 및 고가용성 아키텍처와 같은 더 나은 기본 지원을 제공하는 클라우드 네이티브 애플리케이션에 적합합니다.새로운 아키텍처 및 기술을 통해 애플리케이션 시스템은 더욱 견고해집니다. 클라우드 네이티브 애플리케이션은 클라우드의 장점을 극대화한다고 할 수 있습니다. .
IaaS/PaaS 통합 클라우드 플랫폼을 기반으로 은행은 분산된 마이크로 서비스 프레임워크, 클라우드 미들웨어, 컨테이너, DevOps 및 기타 클라우드 네이티브 기술을 사용하여 수평적 확장, 2단계 확장, 지능형 운영 및 신속한 개발 및 지속적인 제공에 적응하고 유지 관리 PaaS 수준의 클라우드 플랫폼은 기존 아키텍처에서 인터넷 아키텍처로 은행의 진화를 촉진합니다. 플랫폼은 컨테이너를 기반으로 리소스를 배포, 실행 및 예약하고 컨테이너의 경량화 기능을 활용하여 서비스 수가 급증할 때 더 많은 애플리케이션 배포 및 운영 리소스를 절약하고 변동하는 비즈니스 트래픽에 쉽게 대처할 수 있습니다. 동시에 애플리케이션의 이미지 제공 형식은 "하나의 빌드, 다중 배포"를 실현하여 기존 배포 프로세스에서 발생하는 운영 복잡성과 운영 위험을 피합니다. 이 플랫폼을 통해 애플리케이션 딜리버리 주기가 80% 단축되었고 비즈니스 요구에 대한 응답 속도가 50% 증가했습니다.
하지만 금융기관이 클라우드 네이티브 기술을 대량으로 구매·도입하기 시작하면서 클라우드 네이티브 기술 제품 시스템이 너무 복잡하고 오픈소스 생태계에 거버넌스가 부족하고 제품 간 호환성과 적응성이 떨어진다는 등의 문제가 많았다. 어려운. 부분적인 기술적 특성은 종종 금융 기관 선택에 큰 간섭을 일으키고 높은 시행 착오 비용을 발생시킵니다.
"전체를 버리고 지역의 세부 사항을 보는 것은 훌리건입니다."
플랫폼 기반 기술일수록 전체적인 관점에서 고려할 필요가 있다. 따라서 금융 기관이 클라우드 네이티브 기술 변환의 개발 단계에 위치하여 단점을 비교 및 분석할 수 있도록 금융 기관에 기능 참조 모델을 제공하기 위해 산업 특성을 결합한 일련의 통일된 표준이 시급합니다. 클라우드 네이티브 역량 강화 및 미래 기술과 역량 구축 방향을 제시합니다. 일부 금융 산업 관행을 결합하여 금융 기관에 완전한 기술 역량 프레임워크와 클라우드 네이티브 기술 채택을 위한 9차원 성숙도 평가 모델을 제공합니다. 이는 다음 지표를 참조하여 개발할 수 있습니다.
마이크로서비스 아키텍처 수준, 애플리케이션 클라우드화 수준, 관찰 가능성, 고가용성 관리, 구성 자동화, DevOps, 클라우드 플랫폼 기능, 클라우드 네이티브 보안, 컨테이너 및 K8s 기능.
재무 수준의 클라우드 네이티브 진화 경로
좋은 아키텍처는 진화에서 나온다 무결성 및 구축 사양을 보장하기 위한 완전한 아키텍처 계획 세트가 필요하지만 전반적인 안정성과 제어 가능성을 보장하기 위해 지속적으로 진화하는 아키텍처도 필요하므로 두 가지 클라우드 네이티브 아키텍처를 요약했습니다. 진화 경로는 참조로 사용됩니다.
참조 경로 1: 글로벌 거시 규모(위에서 아래로)를 살펴보고 클라우드 네이티브 기능 평가를 기반으로 기술적 단점과 진화 경로를 찾습니다. 다음 예는 클라우드 네이티브 아키텍처의 3단계 진화 경로로, 금융 기관이 애플리케이션 아키텍처를 단일 마이크로서비스에서 단위화로 점진적으로 전환하고 동일한 도시의 이중 활성에서 다중 활성으로의 전환을 실현하도록 지원합니다. 다른 장소들. 비즈니스 개발 및 가혹한 시나리오 테스트를 충족하기 위해 가장 균형 잡힌 아키텍처 개발 경로를 찾습니다.
참조 경로 2: 문제에서 시작하여(아래에서 위로) 아키텍처 진화의 목적은 특정 유형의 문제를 해결하는 것이어야 합니다. 전체 클라우드 네이티브 아키텍처의 진화를 설계하기 위해 "문제"의 관점에서 시작하고자 할 수 있습니다. 다음은 기술적인 문제를 해결하여 클라우드 네이티브 아키텍처를 지속적으로 발전시키는 사례입니다.
1단계: 전체 애플리케이션 아키텍처가 "더 나은 기본 지원"을 갖도록 하려면 클라우드 플랫폼에서 애플리케이션 아키텍처를 실행합니다.
2단계: 모놀리식 아키텍처의 "복잡성 문제"를 해결하기 위해 마이크로서비스 아키텍처 사용
3단계: 마이크로서비스 간의 "통신 예외 문제"를 해결하기 위해 거버넌스 프레임워크 + 모니터링 사용
4단계: 마이크로 서비스 아키텍처에서 많은 애플리케이션의 "배포 문제"를 해결하려면 컨테이너를 사용합니다.
5단계: 컨테이너의 "오케스트레이션 및 스케줄링 문제"를 해결하려면 Kubernetes를 사용하십시오.
6단계: 마이크로서비스 프레임워크의 "침입 문제"를 해결하기 위해 Service Mesh 사용
06 에필로그
이 기사는 일반화된 클라우드 네이티브 기술 개념과 재무 수준 기술 표준을 매핑 및 결합하고 재무 수준 클라우드 네이티브 기술의 청사진 및 10가지 요소를 정의하여 고급 클라우드 네이티브 기술 개념을 만능 기술로 확장하는 것을 목표로 합니다. 기업 조직의 스택은 정보 기술 응용 혁신을 위한 금융 산업의 아키텍처 계획을 위한 새로운 참조 아키텍처를 제안합니다.금융 수준 아키텍처 혁신을 가속화하기 위해 함께 탐구하고 실천합시다.
저자 소개:
Liu Weiguang, Alibaba Cloud Intelligent New Finance & Internet Industry 회장, China Finance 40 Forum 전무이사, Tsinghua University 전자공학과 졸업. Alibaba Cloud에 합류하기 전에는 Ant Financial에서 비즈니스 홍보 및 금융 기술의 생태계 구축과 Ant Blockchain의 비즈니스 개발을 담당했습니다. 중국 지사, 엔터프라이즈급 구축 빅데이터 및 엔터프라이즈급 클라우드 컴퓨팅 시장 최초의 PaaS 플랫폼입니다. Pivotal China Software Company를 설립하기 전에 Liu Weiguang은 EMC Greater China의 데이터 컴퓨팅 사업부 총책임자를 역임했으며 수년간 Oracle China에서 근무했습니다. 한때 Exadata Greater China의 제품 사업부를 만들고 분할.