Well-Architected 프레임워크: 금융 서비스 (FS) 관점의 이 문서에서는 안정적인 FS 워크로드를 설계, 배포, 운영하기 위한 원칙과 권장사항을 개략적으로 설명합니다.Google Cloud Google Cloud이 문서에서는 고급 안정성 관행과 관측 가능성을 아키텍처 청사진에 통합하는 방법을 살펴봅니다. 이 문서의 권장사항은 안정성 분야 Well-Architected 프레임워크와 일치합니다.
금융 기관의 경우 안정적이고 복원력이 우수한 인프라는 비즈니스 요구사항이자 규제상의 필수사항입니다. 에서 FS 워크로드가 안정적인지 확인하려면 잠재적인 장애 지점을 파악하고 완화하며, 리소스를 중복으로 배포하고, 복구를 계획해야 합니다.Google Cloud 운영 복원력은 안정성의 결과입니다. 운영 복원력은 중단을 흡수하고, 중단에 적응하고, 중단으로부터 복구하는 능력입니다. 운영 복원력을 통해 FS 조직은 엄격한 규제 요구사항을 충족할 수 있습니다. 또한 고객에게 용납할 수 없는 피해 를 방지하는 데도 도움이 됩니다.
의 안정성을 위한 주요 구성요소 는 Google Cloud 리전, 영역, 클라우드 리소스의 다양한 위치 범위(영역별, 리전별, 멀티 리전별, 전역)입니다. 관리형 서비스를 사용하고, 리소스를 분산하고, 고가용성 패턴을 구현하고, 프로세스를 자동화하여 가용성을 개선할 수 있습니다.
규제 기관 요건
FS 조직은 미국의 연방준비제도, EU의 유럽 은행 감독청, 영국의 건전성 규제청과 같은 규제 기관의 엄격한 안정성 의무를 준수하며 운영됩니다. 전 세계적으로 규제 기관은 금융 안정성과 소비자 보호에 중요한 운영 복원력을 강조합니다. 운영 복원력은 중단을 견디고, 효과적으로 복구하고, 중요한 서비스를 유지하는 능력입니다. 이를 위해서는 기술적 위험과 서드 파티에 대한 종속 항목을 관리하기 위한 조화로운 접근 방식이 필요합니다.
대부분의 관할권에 걸쳐 규제 요구사항에는 다음과 같은 공통 주제가 있습니다.
- 사이버 보안 및 기술적 복원력: 사이버 위협에 대한 방어를 강화하고 IT 시스템의 복원력을 보장합니다.
- 서드 파티 위험 관리: 정보통신기술 (ICT) 제공업체에 서비스를 아웃소싱하는 것과 관련된 위험을 관리합니다.
- 비즈니스 연속성 및 침해 사고 대응: 중단 중에 중요한 운영을 유지하고 효과적으로 복구하기 위한 강력한 계획입니다.
- 금융 안정성 보호: 광범위한 금융 시스템의 건전성과 안정성을 보장합니다.
이 문서의 안정성 권장사항은 다음과 같은 핵심 원칙에 매핑됩니다.
- 멀티 영역 및 멀티 리전 배포 우선순위 지정
- 단일 장애점 (SPOF) 제거
- 집계 가용성 이해 및 관리
- 강력한 DR 전략 구현
- 관리형 서비스 활용
- 인프라 프로비저닝 및 복구 프로세스 자동화
멀티 영역 및 멀티 리전 배포 우선순위 지정
중요한 금융 서비스 애플리케이션의 경우 리전 2개 이상과 각 리전 내의 영역 3개에 분산된 멀티 리전 토폴로지를 사용하는 것이 좋습니다. 이 접근 방식은 영역 및 리전 서비스 중단에 대한 복원력에 중요합니다. 규정에서는 이 접근 방식을 규정하는 경우가 많습니다. 한 영역 또는 리전에서 장애가 발생하면 대부분의 관할권에서 두 번째 영역에 심각한 중단이 발생할 수 있는 결과로 간주하기 때문입니다. 한 위치에서 장애가 발생하면 다른 위치에서 예외적으로 많은 추가 트래픽을 수신할 수 있다는 것이 그 이유입니다.
영역 및 리전 서비스 중단에 대한 복원력을 구축하려면 다음 권장사항을 고려하세요.
- 위치 범위가 더 넓은 리소스를 선호합니다. 가능한 경우 영역별 리소스 대신 리전별 리소스를 사용하고 리전별 리소스 대신 멀티 리전별 또는 전역 리소스를 사용합니다. 이 접근 방식을 사용하면 백업을 사용하여 운영을 복원할 필요가 없습니다.
- 각 리전에서 2개의 영역 대신 3개의 영역을 활용합니다. 장애 조치를 처리하려면 예상보다 1/3 더 많은 용량을 오버프로비저닝합니다.
- 다음 예와 같이 활성-활성 배포를 구현하여 수동 복구 단계를 최소화합니다.
- Spanner와 같은 분산 데이터베이스는 리전 간에 기본 제공 중복성 및 동기화를 제공합니다.
- Cloud SQL의 HA 기능 은 영역 간에 읽기 전용 복제본이 있는 활성-활성 토폴로지에 가까운 토폴로지를 제공합니다. 리전 간에 0에 가까운 복구 지점 목표 (RPO)를 제공합니다.
- Cloud DNS를 사용하여 리전 간에 사용자 트래픽을 분산하고 각 리전에 리전 부하 분산기를 배포합니다. 전역 부하 분산기는 요구사항 및 중요도에 따라 고려할 수 있는 또 다른 옵션입니다. 자세한 내용은 멀티 리전 배포를 위한 전역 부하 분산의 이점과 위험을 참조하세요.
- 데이터를 저장하려면 Spanner 및 Cloud Storage와 같은 멀티 리전 서비스를 사용합니다.
단일 장애점 제거
단일 장애점 (SPOF)이 전체 애플리케이션 스택에 영향을 미치지 않도록 여러 위치에 리소스를 분산하고 중복 리소스를 사용합니다.
SPOF를 방지하려면 다음 권장사항을 고려하세요.
- 단일 애플리케이션 서버 또는 데이터베이스만 배포하지 마세요.
- 관리형 인스턴스 그룹 (MIG)을 사용하여 장애가 발생한 VM을 자동으로 다시 만듭니다.
- 부하 분산을 구현하여 사용 가능한 리소스 간에 트래픽을 균등하게 분산합니다.
- Cloud SQL과 같은 데이터베이스에 HA 구성을 사용합니다. Cloud SQL.
- 동기식 복제를 사용하는 리전 영구 디스크 를 사용하여 데이터 가용성을 개선합니다.
자세한 내용은 에서 워크로드를 위한 안정적인 인프라 설계를 참조하세요. Google Cloud
집계 가용성 이해 및 관리
시스템의 전체 또는 집계 가용성은 시스템의 각 등급 또는 구성요소의 가용성에 영향을 받습니다. 애플리케이션 스택의 등급 수는 스택의 집계 가용성과 반비례합니다. 집계 가용성을 관리하기 위한 다음 권장사항을 고려하세요.
등급1_가용성 × 등급2_가용성 × 등급N_가용성 수식을 사용하여 다중 등급 스택의 집계 가용성을 계산합니다.
다음 다이어그램은 4개의 서비스로 구성된 다중 등급 시스템의 집계 가용성 계산을 보여줍니다.
위 다이어그램에서 각 등급의 서비스는 99.9% 가용성을 제공하지만 시스템의 집계 가용성은 99.6% (0.999 × 0.999 × 0.999 × 0.999)로 더 낮습니다. 일반적으로 다중 등급 스택의 집계 가용성은 최소 가용성을 제공하는 등급의 가용성보다 낮습니다.
가능한 경우 연결 보다 병렬화 를 선택합니다. 병렬화된 서비스를 사용하면 엔드 투 엔드 가용성이 각 개별 서비스의 가용성보다 높습니다.
다음 다이어그램은 연결 및 병렬화 접근 방식을 사용하여 배포된 두 서비스 A와 B를 보여줍니다.
위의 예에서 두 서비스 모두 SLA가 99%이므로 구현 접근 방식에 따라 다음과 같은 집계 가용성이 발생합니다.
- 연결된 서비스 는 집계 가용성이 98% (.99 × .99)에 불과합니다.
- 병렬화된 서비스 는 각 서비스가 독립적으로 실행되고 개별 서비스가 다른 서비스의 가용성에 영향을 받지 않으므로 집계 가용성이 99.99% 로 더 높습니다. 집계된 병렬화된 서비스의 공식은 1 − (1 − A) × (1 − B) 입니다.
애플리케이션 스택의 전반적인 가동시간 요구사항을 충족하는 데 도움이 되는 가동시간 SLA가 있는 Google Cloud 서비스를 선택합니다.
아키텍처를 설계할 때는 가용성, 운영 복잡성, 지연 시간, 비용 간의 장단점을 고려하세요. 가용성의 9의 개수를 늘리면 일반적으로 비용이 더 많이 들지만 규제 요구사항을 충족하는 데 도움이 됩니다.
예를 들어 가용성 99.9%(3개의 9)는 24시간 동안 86초의 잠재적 다운타임을 의미합니다. 반대로 99% (2개의 9)는 동일한 기간 동안 864초의 다운타임을 의미하며, 이는 가용성 3개의 9보다 10배 더 많은 다운타임입니다.
중요한 금융 서비스의 경우 아키텍처 옵션이 제한될 수 있습니다. 하지만 가용성 요구사항을 파악하고 가용성을 정확하게 계산하는 것이 중요합니다. 이러한 평가를 수행하면 설계 결정이 아키텍처와 예산에 미치는 영향을 평가하는 데 도움이 됩니다.
강력한 DR 전략 구현
영역 및 리전 서비스 중단을 비롯한 다양한 재해 시나리오에 대한 잘 정의된 계획을 만듭니다. 잘 정의된 재해 복구 (DR) 전략을 사용하면 중단으로부터 복구하고 영향을 최소화하면서 정상적인 운영을 재개할 수 있습니다.
DR과 고가용성 (HA)은 서로 다른 개념입니다. 클라우드 배포의 경우 일반적으로 DR은 멀티 리전 배포에 적용되고 HA는 리전 배포에 적용됩니다. 이러한 배포 원형은 다양한 복제 메커니즘을 지원합니다.
- HA: 많은 관리형 서비스는 기본적으로 단일 리전 내의 영역 간에 동기식 복제를 제공합니다. 이러한 서비스는 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)가 0 또는 0에 가까운 값을 지원합니다. 이 지원을 통해 SPOF가 없는 활성-활성 배포 토폴로지를 만들 수 있습니다.
- DR: 리전 2개 이상에 배포된 워크로드의 경우 멀티 리전 또는 전역 서비스를 사용하지 않으면 복제 전략을 정의해야 합니다. 복제 전략은 일반적으로 비동기식입니다. 이러한 복제가 중요한 애플리케이션의 RTO 및 RPO에 미치는 영향을 신중하게 평가합니다. 장애 조치에 필요한 수동 또는 반자동 작업을 식별합니다.
금융 기관의 경우 장애 조치 리전 선택은 데이터 주권 및 데이터 저장 위치에 관한 규정으로 제한될 수 있습니다. 두 리전에 걸쳐 활성-활성 토폴로지가 필요한 경우 특히 데이터 복제가 중요한 경우 Spanner 및 Cloud Storage와 같은 관리형 멀티 리전 서비스를 선택하는 것이 좋습니다.
다음 권장사항을 고려하세요.
- 데이터에 관리형 멀티 리전 스토리지 서비스를 사용합니다.
- 영구 디스크의 데이터 스냅샷을 만들고 멀티 리전 위치에 스냅샷을 저장합니다.
- 리전별 또는 영역별 리소스를 사용하는 경우 다른 리전에 데이터 복제를 설정합니다.
- 계획을 정기적으로 테스트하여 DR 계획이 효과적인지 확인합니다.
- RTO 및 RPO와 관할권의 금융 규정에 명시된 영향 허용 범위와의 상관관계를 파악합니다.
자세한 내용은 클라우드 인프라 중단을 위한 재해 복구 설계를 참조하세요.
관리형 서비스 활용
가능한 경우 관리형 서비스를 사용하여 백업, HA, 확장성을 위한 기본 제공 기능을 활용합니다. 관리형 서비스 사용에 대한 다음 권장사항을 고려하세요.
- 에서 관리형 서비스를 사용합니다. Google CloudSLA로 지원되는 HA를 제공합니다. 또한 기본 제공 백업 메커니즘과 복원력 기능도 제공합니다.
- 데이터 관리의 경우 Cloud SQL, Cloud Storage, 및 Spanner와 같은 서비스를 고려하세요.
- 컴퓨팅 및 애플리케이션 호스팅의 경우 Compute Engine 관리형 인스턴스 그룹 (MIG) 및 Google Kubernetes Engine (GKE) 클러스터를 고려하세요. 리전 MIG 및 GKE 리전 클러스터는 영역 서비스 중단에 대한 복원력이 우수합니다.
- 리전 서비스 중단에 대한 복원력을 개선하려면 관리형 멀티 리전 서비스를 사용하세요.
- 고유한 특성이 있는 서비스의 종료 계획 의 필요성을 파악하고 필요한 계획을 정의합니다. FCA, PRA, EBA와 같은 금융 규제 기관은 클라우드 제공업체와의 관계가 종료되는 경우 데이터 검색 및 운영 연속성을 위한 전략과 비상 계획을 기업에 요구합니다. 기업은 클라우드 계약을 체결하기 전에 종료 가능성을 평가해야 하며 운영 중단 없이 제공업체를 변경할 수 있는 기능을 유지해야 합니다.
- 선택한 서비스가 CSV, Parquet, Avro와 같은 개방형 형식으로 데이터 내보내기를 지원하는지 확인합니다. 서비스가 Open Container Initiative (OCI) 형식에 대한 GKE 지원 또는 Apache Airflow를 기반으로 구축된 Managed Service for Apache Airflow와 같은 개방형 기술을 기반으로 하는지 확인합니다.
인프라 프로비저닝 및 복구 프로세스 자동화
자동화는 인적 오류를 최소화하고 침해 사고에 대응하는 데 필요한 시간과 리소스를 줄이는 데 도움이 됩니다. 자동화를 사용하면 장애로부터 더 빠르게 복구하고 더 일관된 결과를 얻을 수 있습니다. 리소스를 프로비저닝하고 복구하는 방법을 자동화하려면 다음 권장사항을 고려하세요.
- Terraform과 같은 코드형 인프라 (IaC) 도구를 사용하여 인적 오류를 최소화합니다.
- 장애 조치 프로세스를 자동화하여 수동 개입을 줄입니다. 자동화된 응답은 장애의 영향을 줄이는 데도 도움이 됩니다. 예를 들어 Eventarc 또는 워크플로를 사용하여 감사 로그를 통해 관찰된 문제에 대응하여 수정 조치를 자동으로 트리거할 수 있습니다.
- 자동 확장을 사용하여 장애 조치 중에 클라우드 리소스의 용량을 늘립니다.
- 플랫폼 엔지니어링을 채택하여 서비스 배포 중에 클라우드 토폴로지 전반에 규제 요구사항에 대한 정책 및 가드레일을 자동으로 적용합니다.