AWS 기반 결제 인프라 설계 — 국내 리전 제약 안에서 가용성·재해복구 확보하기
클라우드 이용 절차 글에서 다룬 것처럼, 개인의 신용정보를 다루는 서비스는 국내(서울)에 있는 서버 밖으로 데이터를 옮길 수 없다. 그런데 클라우드에서 흔히 쓰는 "장애에 대비하는 방법"은 대부분 "다른 나라의 서버로 데이터를 복제해두는 것"을 전제로 한다. 이 글은 그 전제가 통하지 않는 결제 서비스에서, AWS(아마존의 클라우드 서비스)가 제공하는 장애 대비 기능들을 어떻게 조합해야 하는지를 다룬다.
규제가 요구하는 최소 기준
전자금융감독규정(금융회사의 보안·운영을 관리하는 규정)은 주요 서버 장비를 예비로 하나 더 준비해두도록 요구하고, 재해에 대비하는 별도 시설(재해복구센터)을 원래 서버가 있는 곳과 어느 정도 떨어진 안전한 곳에 만들어두도록 하며, 장애가 났을 때 복구까지 걸려도 되는 최대 시간(복구목표시간, RTO)을 3시간 이내(일부 금융회사는 24시간)로 정해두고 있다. 서버실을 새로 만들거나 옮기거나 재해복구센터를 지을 때는 금융감독원의 보안 심사도 받아야 한다. 이 기준을 놓고 AWS가 제공하는 기능들을 비교해보면, 사실 기술적으로는 이미 이 기준을 훨씬 넉넉하게 만족시킬 수 있다는 게 드러난다 — 진짜 병목은 대개 기술이 아니라 회사 안의 절차다.
무엇을 선택할지, 무엇을 포기할지
1. 같은 지역 안에서 서버를 이중화하는 두 가지 방식 서울 안에는 물리적으로 떨어진 4개의 데이터센터 구역(AZ)이 있다. 같은 서울 안에서만 서버를 이중화해도 방식에 따라 차이가 크다.
| 배포 방식 | 장애 복구(failover) 시간 | 특징 |
|---|---|---|
| Multi-AZ 인스턴스 배포(전통 방식) | 보통 60~120초 | 대부분의 데이터베이스 종류·버전 지원 |
| Multi-AZ DB 클러스터 배포(최신 방식) | 35초 미만 | 평소 조회 속도도 향상, 단 지원 종류·버전 제약 |
후자는 지원하는 데이터베이스 종류와 버전에 제약이 있어서 기존에 쓰던 서비스를 그대로 옮기지 못할 수도 있다 — 새로 만드는 서비스라면 처음부터 이 방식으로 시작하는 걸 검토할 만하다.
2. 해외로 복제하는 기능은 매력적이지만 절반만 쓸 수 있다 Aurora Global Database(AWS의 데이터베이스가 여러 나라에 자동으로 복제되게 해주는 기능)는 데이터가 거의 실시간(약 1초 차이)으로 복제되고, 장애가 나도 1분 안팎으로 다른 나라 서버가 대신 일을 이어받을 수 있는 강력한 기능이다. 문제는 이 기능이 전제하는 "다른 나라 서버로 복제하기"가, 개인 신용정보가 포함된 데이터에는 처음부터 허용되지 않는다는 점이다. 그러니 이 기능은 결제·정산·장부처럼 개인정보가 섞인 데이터에는 못 쓰고, 개인을 특정할 수 없게 처리된 로그 모음이나 통계용 데이터처럼 개인정보가 없는 데이터에만 제한적으로 쓸 수 있다. 처음부터 "이 데이터는 해외로 복제해도 되는지, 안 되는지"를 정리해서 표시해두지 않으면, 나중에 이 기능을 쓰려다가 개인정보가 섞여 있어서 통째로 못 쓰는 상황을 만난다.
3. 서울 지역 전체가 문제 생기는 상황까지 대비했는가 규정이 요구하는 재해복구센터는 "원래 서버가 있는 곳과 어느 정도 떨어진 안전한 곳"이다. 같은 서울 리전 안의 4개 데이터센터 구역들은 물리적으로 떨어져 있긴 하지만, 이게 규정이 말하는 "재해복구센터"로 인정받을 만큼 충분히 떨어져 있는 건지는 보안 심사 전에 법무·보안 담당자와 따로 확인해야 한다. 서울 지역 전체가 문제가 생기는 극단적인 상황까지 대비하려면, 국내의 다른 회사가 운영하는 데이터센터에 백업 저장소를 따로 마련하는 방법도 검토 대상이 되는데, 이 경우 관리해야 할 게 훨씬 많아진다. 실무적으로는 "서울 리전 안에서 데이터센터 구역을 나눠 이중화 + 다른 물리적 장소에 백업 저장소 하나 더" 정도로 절충하는 경우가 많다.
4. 기술이 빠른 것과 실제로 빠른 것은 다르다 어떤 방식을 쓰든, AWS가 자동으로 처리해주는 장애 대응은 몇 초에서 몇 분 안에 끝난다. 규정이 요구하는 3시간(또는 24시간)에 비하면 기술적으로는 여유가 많다. 그런데 실제 장애 상황에서는 "장애를 알아차리고 → 원인을 파악하고 → 다른 서버로 넘길지 사람이 결정하고 → 실행하는" 과정이 전체 복구 시간의 대부분을 차지한다. 자동으로 넘어가도 안전한 상황은 미리 자동화해두고, 사람이 판단해야 하는 상황은 정기적으로 실제 훈련을 해봐서 얼마나 걸리는지 직접 재봐야 한다 — 측정도 안 해보고 "기술적으로는 금방 될 것"이라고만 말하는 건 감사받을 때 통하지 않는다.
체크리스트
- 개인 신용정보가 포함된 데이터가 Aurora Global Database 같은 해외 복제 대상에 실수로 섞여 있지 않은지, 어떤 데이터를 해외로 복제해도 되는지 미리 정리해뒀는지
- 서버 이중화 방식(인스턴스형 vs 클러스터형)에 따른 복구 시간 차이를 알고, 서비스 목표 시간에 반영했는지
- 재해복구센터가 규정이 요구하는 물리적 거리 기준을 충족하는지 보안 심사 전에 법무·보안 담당자와 확인했는지
- 3시간(또는 24시간)이라는 목표 시간 대비, 실제 훈련에서 재본 복구 시간이 있는지, 훈련을 얼마나 자주 하는지 정해뒀는지
- 장애를 알아차린 뒤 사람이 판단해야 하는 구간을 자동화할 수 있는지, 그대로 둔다면 그 이유를 문서로 남겨뒀는지
참고자료
- Failing over a Multi-AZ DB instance for Amazon RDS – AWS 공식 문서
- Using switchover or failover in Amazon Aurora Global Database – AWS 공식 문서
- REL10-BP01 Deploy the workload to multiple locations – AWS Well-Architected Reliability Pillar
- AWS Regions and Availability Zones – AWS 공식 문서
- 전자금융감독규정 – 국가법령정보센터
관련 글
- 전자금융감독규정상 클라우드 이용 절차, PG·선불사가 AWS 쓸 때 놓치는 것들 — 이 글에서 다룬 국내 리전 제약, 이중화 요건의 근거 규정
- PG/선불 사업에 필요한 최소 시스템 구성 — 원장·정산·리스크·감사로그 — 여기서 다룬 원장·정산 시스템이 이 글이 설계하는 인프라 위에서 돌아간다