Well-Architected 프레임워크: 금융 서비스 (FS) 관점의 이 문서에서는 금융 서비스 워크로드의 성능을 최적화하기 위한 원칙과 권장사항을 간략히 설명합니다.Google Cloud Google Cloud이 문서의 권장사항은 Well-Architected 프레임워크의 성능 최적화 부문과 일치합니다.
성능 최적화는 금융 서비스에서 오랜 역사를 가지고 있습니다. 성능 최적화는 FS 조직이 기술적 과제를 극복하는 데 도움이 되었으며, 거의 항상 새로운 비즈니스 모델을 만드는 데 도움이 되거나 가속화했습니다. 예를 들어, ATM은 (1967년에 도입) 현금 지급 프로세스를 자동화하고 은행이 핵심 비즈니스 비용을 절감하는 데 도움이 되었습니다. OS 커널을 우회하고 애플리케이션 스레드를 컴퓨팅 코어에 고정하는 등의 기술은 거래 애플리케이션의 결정론적이고 짧은 지연 시간을 달성하는 데 도움이 되었습니다. 지연 시간 감소는 금융 시장에서 스프레드가 더 좁아지고 유동성이 더 높고 견고해지는 데 도움이 되었습니다.
클라우드는 성능 최적화를 위한 새로운 기회를 창출합니다. 또한 역사적으로 허용된 최적화 패턴 중 일부에 도전합니다. 특히 클라우드에서는 다음과 같은 절충안이 더 투명하고 제어 가능합니다.
- TTM(time to market)과 비용
- 시스템 수준의 엔드 투 엔드 성능과 노드 수준의 성능
- 기술 관련 의사 결정의 민첩성과 인재 가용성
예를 들어 특정 기술 요구사항에 맞게 하드웨어 및 IT 리소스를 조정하는 것은 클라우드에서 간단한 작업입니다. GPU 프로그래밍을 지원하기 위해 GPU 기반 VM을 만들 수 있습니다. 클라우드에서 용량을 확장하여 리소스를 과도하게 프로비저닝하지 않고도 수요 급증을 수용할 수 있습니다. 이 기능을 사용하면 비농업 부문 고용 지표 발표일과 같이 거래량이 과거 수준보다 훨씬 높은 경우 워크로드가 최대 부하를 처리할 수 있습니다. 개별 서버 수준에서 고도로 최적화된 코드 (예: C 언어의 고도로 미세 조정된 코드)를 작성하거나 기존 고성능 컴퓨팅 (HPC) 환경을 위한 코드를 작성하는 대신, 잘 설계된 Kubernetes 기반 분산 시스템을 사용하여 최적으로 수평 확장할 수 있습니다.
이 문서의 성능 최적화 권장사항은 다음과 같은 핵심 원칙에 매핑됩니다.
- 기술 실적 측정항목을 주요 비즈니스 지표에 맞춥니다.
- 입증되지 않은 위험에 대한 성능을 희생하지 않고 보안을 우선시합니다.
- 새로운 기회와 요구사항에 맞게 아키텍처를 재고합니다.
- 현재 및 미래의 비즈니스 요구사항을 충족하도록 기술을 미래에 대비합니다.
기술 성능 측정항목을 주요 비즈니스 지표에 맞춥니다.
성능 최적화를 여러 가지 방법으로 비즈니스 가치 결과에 매핑할 수 있습니다. 예를 들어 매수 측 조사 데스크에서 비즈니스 목표는 조사 시간당 출력을 최적화하거나 Sharpe 비율이 높은 것과 같이 실적이 입증된 팀의 실험에 우선순위를 두는 것일 수 있습니다. 매도 측에서는 분석을 사용하여 클라이언트의 관심을 추적하고 가장 흥미로운 연구를 지원하는 AI 모델의 처리량을 우선시할 수 있습니다.
성능 목표를 비즈니스 핵심성과지표 (KPI)에 연결하는 것도 성능 개선을 위한 자금 조달에 중요합니다. 비즈니스 혁신 및 혁신 이니셔티브 (change-the-bank 노력이라고도 함)는 예산이 다르며, 일상적인 비즈니스 (BAU) 또는 run-the-bank 운영과 비교할 때 리소스에 대한 액세스 수준이 다를 수 있습니다. 예를 들어 Google Cloud G-SIFI의 위험 관리 및 기술팀이 프런트 오피스 정량 분석가와 협력하여 위험 분석 계산 (예: XVA)을 몇 시간 또는 며칠이 아닌 몇 분 안에 수행할 수 있도록 지원했습니다. 이 솔루션을 통해 조직은 관련 규정 준수 요구사항을 충족할 수 있었습니다. 또한 거래자가 고객과 더 높은 품질의 대화를 나눌 수 있도록 지원하여 스프레드를 더 좁히고 유동성을 더 높이며 비용 효율적인 헤징을 제공할 수 있었습니다.
성능 측정항목을 비즈니스 지표에 맞출 때는 다음 권장사항을 고려하세요.
- 각 기술 이니셔티브를 관련 비즈니스 목표 및 핵심 결과지표 (OKR), 수익 또는 이익 증대, 비용 절감, 위험을 더 효율적 또는 전체적으로 완화하는 것과 같은 것에 연결합니다.
- 시스템 수준에서 성능 최적화에 집중합니다. 기존의 change-the-bank와 run-the-bank 분리 및 프런트 오피스와 백 오피스 사일로를 넘어 살펴보세요.
입증되지 않은 위험에 대한 성능을 희생하지 않고 보안을 우선시합니다.
FS 조직의 보안 및 규정 준수는 명확하게 높은 수준이어야 합니다. 높은 수준을 유지하는 것은 고객을 잃지 않고 조직의 브랜드에 돌이킬 수 없는 손상을 방지하는 데 필수적입니다. 가장 높은 가치는 생성형 AI와 같은 기술 혁신과 Spanner와 같은 고유한 관리형 서비스를 통해 얻을 수 있는 경우가 많습니다. 과도한 운영 위험 또는 부적절한 규정 준수 상태에 대한 전반적인 오해로 인해 이러한 기술 옵션을 자동으로 폐기하지 마세요.
Google Cloud 는 자금 세탁 방지 (AML)를 위한 AI 기반 접근 방식을 기관이 고객에게 서비스를 제공하는 관할권에서 사용할 수 있도록 G-SIFI와 긴밀히 협력해 왔습니다. 예를 들어, HSBC 다음과 같은 결과를 통해 금융 범죄 (Fincrime) 부서의 실적을 크게 개선했습니다.
- 확인된 의심스러운 활동이 거의 2~4배 증가했습니다.
- 거짓양성을 60% 이상 없애고 위험도가 높고 실행 가능한 알림에만 조사 시간을 집중하여 운영 비용을 절감했습니다.
- 규정 준수를 지원하는 감사 가능하고 설명 가능한 출력을 제공합니다.
다음 권장사항을 고려하세요.
- 사용하려는 제품이 운영하는 관할권의 보안, 복원력, 규정 준수 요구사항을 충족하는 데 도움이 되는지 확인합니다. 이 목표를 달성하려면 Google Cloud 계정팀, 위험팀, 제품팀과 협력하세요.
- AI 설명 가능성 (예: Shapley 값 기여도)을 활용하여 더 강력한 모델을 만들고 고객에게 투명성을 제공합니다. Shapley 값 기여도와 같은 기술은 모델 결정을 입력 수준의 특정 특성에 기여할 수 있습니다.
소스 인용, 그라운딩, RAG와 같은 기술 을 사용하여 생성형 AI 워크로드의 투명성을 달성합니다.
설명 가능성이 충분하지 않은 경우 가치 스트림에서 의사 결정 단계를 분리하고 AI를 사용하여 의사 결정이 아닌 단계만 자동화합니다. 경우에 따라 설명 가능한 AI가 충분하지 않거나 프로세스 에 규제 문제 (예: GDPR, 22조)로 인해 사람의 개입이 필요할 수 있습니다. 이러한 경우 인간 에이전트가 의사 결정을 위해 필요한 모든 정보를 단일 제어 창에 표시하되 데이터 수집, 수집, 조작, 요약 작업을 자동화합니다.
새로운 기회와 요구사항에 맞게 아키텍처를 재고합니다.
클라우드 기반 기능으로 현재 아키텍처를 보강하면 상당한 가치를 제공할 수 있습니다. 더 혁신적인 결과를 얻으려면 클라우드 중심 접근 방식을 사용하여 아키텍처를 주기적으로 재고해야 합니다.
성능을 더욱 최적화하기 위해 워크로드의 아키텍처를 주기적으로 재고하려면 다음 권장사항을 고려하세요.
온프레미스 HPC 시스템 및 스케줄러 대신 클라우드 기반 대안 사용
더 높은 탄력성, 향상된 보안 태세, 그리고 광범위한 모니터링 및 거버넌스 기능을 활용하려면 클라우드에서 HPC 워크로드를 실행하거나 온프레미스 워크로드를 클라우드로 버스팅할 수 있습니다. 그러나 투자 전략 시뮬레이션 또는 XVA 모델링과 같은 특정 수치 모델링 사용 사례의 경우 Kubernetes와 Kueue를 결합하면 더 강력한 솔루션을 제공할 수 있습니다.
시뮬레이션을 위해 그래프 기반 프로그래밍으로 전환
Monte Carlo 시뮬레이션 은 Dataflow와 같은 그래프 기반 실행 시스템에서 훨씬 더 성능이 좋을 수 있습니다. 예를 들어, HSBC 는 Dataflow를 사용하여 이전 접근 방식에 비해 16배 더 빠르게 위험 계산을 실행합니다.
클라우드 기반 거래소 및 거래 플랫폼 실행
고객과의 대화를 통해 80/20 파레토 법칙 이 시장 및 거래 애플리케이션의 성능 요구사항에 적용된다는 것을 알 수 있습니다. Google Cloud
- 거래 애플리케이션의 80% 이상은 지연 시간이 매우 짧을 필요가 없습니다. 그러나 클라우드의 복원력, 보안, 탄력성 기능에서 상당한 이점을 얻습니다. 예를 들어, BidFX 외환 멀티 딜러 플랫폼은 클라우드를 사용하여 새 제품을 빠르게 출시하고 리소스를 늘리지 않고도 가용성과 점유율을 크게 높입니다.
- 나머지 애플리케이션 (20% 미만)은 지연 시간 (1밀리초 미만), 결정론, 메시지 전달의 공정성이 필요합니다. 일반적으로 이러한 시스템은 엄격하고 비용이 많이 드는 코로케이션 시설에서 실행됩니다. 점점 더 많은 애플리케이션이 에지 또는 클라우드 중심 애플리케이션으로 클라우드에서 리플랫폼되고 있습니다 .
현재 및 미래의 비즈니스 요구사항을 충족하도록 기술을 미래에 대비합니다.
역사적으로 많은 FS 조직이 경쟁 우위를 확보하기 위해 독점 기술을 구축했습니다. 예를 들어 2000년대 초반에는 성공적인 투자 은행과 거래 회사가 펍/서브 시스템 및 메시지 브로커와 같은 기본 기술을 자체적으로 구현했습니다. 오픈소스 기술과 클라우드의 발전으로 이러한 기술은 상품화되어 추가적인 비즈니스 가치를 제공하지 않습니다.
기술을 미래에 대비하려면 다음 권장사항을 고려하세요.
TTM(time to market) 단축 및 비용 투명성을 위해 DaaS(data-as-a-service) 접근 방식 채택
FS 조직은 종종 유기적 성장과 인수합병 (M&A)의 조합을 통해 발전합니다. 따라서 조직은 이질적인 기술을 통합해야 합니다. 또한 데이터 공급업체, 데이터 라이선스, 통합 지점과 같은 중복 리소스를 관리해야 합니다. Google Cloud 는 인수 후 통합에서 차별화된 가치를 창출할 수 있는 기회를 제공합니다.
예를 들어 BigQuery 공유 와 같은 서비스를 사용하여 분석 준비가 완료된 DaaS (data-as-a-service) 플랫폼을 빌드할 수 있습니다. 이 플랫폼은 시장 데이터와 대체 소스의 입력을 모두 제공할 수 있습니다. 이 접근 방식을 사용하면 중복 데이터 파이프라인을 빌드할 필요가 없으며 더 가치 있는 이니셔티브에 집중할 수 있습니다. 또한 합병 또는 인수된 회사는 인수 후 데이터 라이선스 및 인프라 요구사항을 빠르고 효율적으로 합리화할 수 있습니다. 결합된 비즈니스는 기존 데이터 자산 및 운영을 조정하고 병합하는 데 노력을 기울이는 대신 새로운 비즈니스 기회에 집중할 수 있습니다.
기존 시스템을 격리하고 새로운 비즈니스 모델을 해결하기 위한 추상화 레이어 빌드
점점 더 많은 은행의 경쟁 우위는 핵심 뱅킹 시스템이 아니라 고객 경험 레이어입니다. 그러나 기존 뱅킹 시스템은 종종 Cobol과 같은 언어로 개발되고 전체 뱅킹 가치 사슬에 통합된 모놀리식 애플리케이션을 사용합니다. 이 통합으로 인해 가치 사슬의 레이어를 분리하기 어려웠으므로 이러한 시스템을 업그레이드하고 현대화하는 것은 거의 불가능했습니다.
이 문제를 해결하는 한 가지 방법은 기록부를 복제하고 고급 분석 및 AI를 사용하여 서비스 현대화를 지원하는 API 관리 시스템 또는 Spanner와 같은 스테이징 레이어와 같은 격리 레이어를 사용하는 것입니다. 예를 들어 Deutsche Bank 는 Spanner를 사용하여 기존 핵심 뱅킹 자산을 격리하고 혁신 여정을 시작했습니다.