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