요약
Google Cloud 장애로 HSBC, 레볼루트, 로이즈 등 유럽 은행과 물류 서비스가 멈췄습니다.
IT 뉴스 사이트 니오윈의 보도입니다. 유럽에서 은행 업무가 막힌 이용자가 많은데, 그 원인이 Google Cloud 장애로 보인다고 전했습니다.
왜 중요한가
- 클라우드 한 곳의 장애가 여러 은행의 결제와 송금을 한꺼번에 멈출 수 있음을 보여 줍니다.
- 구글은 고객이 직접 작업을 옮기라고 권고했습니다. 장애 대비가 결국 이용 기업의 몫이라는 점이 드러났습니다.
핵심 내용
- HSBC, 레볼루트, 뱅크오브스코틀랜드, 로이즈, 로열메일, 지오포스트의 DPD 등이 영향을 받았습니다.
- 레볼루트는 가입, 로그인, 결제, 송금, 충전, ATM 출금, 주식·암호화폐 거래가 모두 멈췄다고 밝혔습니다.
- 구글은 Google Compute Engine, Google Cloud Storage, Google BigQuery 등 30개가 넘는 서비스의 장애를 확인했습니다.
- 구글은 가능하면 영향받은 작업을 다른 존(데이터센터 묶음)이나 리전(존 여러 개를 묶은 지역 단위)으로 옮기라고 권고했습니다.
HN 반응
- 구글 상태 페이지에 원인이 한 존의 전력 사고로 나오자, 대기업이 왜 여러 존을 쓰지 않았느냐는 지적과 남은 존에 요청이 몰린 구글 쪽 문제라는 반론이 맞섰습니다.
- 여러 존에 나눠 두어도 존 하나가 멈추는 상황을 실제로 시험해 보는 회사는 드물다는 경험담이 여럿 나왔습니다.
구글 상태 페이지에서 가져왔습니다. https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj
그러니까 어떤 전원 장애가 터져서 존 하나가 내려간 모양입니다. 안타깝지만 이런 일은 일어나기 마련입니다. 그래서 클라우드 업체들이 전부 여러 존을 두는 것이고요. 다운됐다고 보도된 대기업들이 멀티 존을 쓰고 있지 않았다니 놀랍습니다.
(참고로 시간을 PDT로 적어 둔 것도 별로 도움이 안 됩니다. 이 존을 쓰는 사용자는 아마 대부분 영국이나 EU에 있을 텐데요.)
여기가 그렇다는 얘기는 아니지만, 클라우드 업체 자체에 존 간 의존성, 심지어 리전 간 의존성이 있어서 다른 존이나 리전의 장애로 번지는 경우도 가끔 있습니다.
예를 들어 AWS us-east-1 장애가 여러 번 전 세계 장애로 이어졌습니다. 이 기사가 그런 사례입니다. https://www.networkworld.com/article/4168878/aws-hit-by-us-east-1-outage-after-data-center-thermal-event.html
Google Cloud에서는 그게 절대 해서는 안 되는 일이고, 사후 검토 때 문제 인물 명단에 올라 호된 추궁을 받게 될 겁니다.
공지: 저는 Google Cloud에서 일합니다.
혹시 누가 그냥 5테라바이트를 서빙하려고 했던 건 아닐까요?
아니요. 그건 절대 불가능해요. 5테라바이트를 서빙할 수 있는 사람은 아무도 없다고요.
알겠습니다만, 그러면 존 단위도 아닌 상위 수준 서비스들은 왜 전부 문제를 겪은 겁니까?
네, TK랑 직접 얼굴 볼 기회를 얻고 싶은 사람한테는 아주 좋은 전략이죠.
클라우드 서비스 일을 하지 않는 사람들은 보통 용어를 아주 두루뭉술하게 쓰는데, 그래서 여기서 말이 엇갈리는 것 같습니다. 하이퍼스케일러에서 사람들이 '클라우드'로 여기는 대부분의 것에게 '존'은 사실 가용성의 단위가 아닙니다. 존은 데이터센터 1~3개 정도이고, 국지적인 전원 사고 같은 일에 매우 취약합니다. 그래서 대부분의 서비스는 존 단위로 제공되지 않고, 존 단위로 제공되는 경우에는 그렇다는 큼직한 고지문이 붙고 SLA의 9도 더 적게 보장됩니다.
대부분은 여러 존으로 이뤄진 리전 단위입니다. AWS us-east-1이 그런 리전 중 하나입니다. 리전 전체가 장애를 일으키기 시작하려면 꽤 넓은 지역에 흩어진 수많은 데이터센터에 문제가 생겨야 합니다.
GCP의 경우에는 데이터센터 한 곳의 전원 사고가 리전 나머지에 쇄도 현상(thundering herd)을 일으킨 것이 실제 문제였던 것 같습니다. (상당히 심각한 문제이고, 일어나서는 안 되는 일입니다)
대체로 맞는 말씀이지만, AWS 대형 장애의 역사는 모르시는 것 같습니다. 최초의 AWS 클라우드 리전인 us-east-1의 장애는 AWS 전체로 번지는 전 세계적 연쇄 장애를 자주 일으킵니다. 제 기억으로는 특히 DNS와 DynamoDB 관련 장애가 그랬습니다. 즉 eu-west-1 같은 곳(사실은 AWS 어디든)에서 돌아가는 AWS 워크로드가 핵심 리전의 AWS 인프라 장애 때문에 실패하기 시작하거나, 최소한 성능과 가용성이 크게 떨어지는 일이 흔합니다.
AWS 자신도 리전 간 격리와 가용성을 제대로 다루지 못한다면, AWS 위에서 서비스를 돌리는 대부분의 기업에 대한 제 기대치는 아주 낮을 수밖에 없습니다.
AWS가 컨트롤 플레인, 특히 lambda를 us-east-1에서 운영하기 때문입니다. us-east-1에서만 돌릴 수 있는 아주 인기 있는 서비스도 몇 개 있고요. 기술적 제약이라기보다는 설계상의 결정입니다.
잠깐, 그러면 us-east-1이 내려가면 큰 손해를 볼 게 뻔한 대형 고객들과는 어떻게 아직도 계약을 하는 건가요?
(그런 고객이라면 us-east-1에만 제한된 게 있는지 확인할 동기가 충분할 텐데요)
2023년에 europe-west9에서도 비슷한 문제가 있었습니다. 물리적 사고로 존 하나를 통째로 잃으면 실제로 곤란해지는 모양입니다. 쇄도 현상(thundering herd) 때문이거나, 나머지 두 존의 용량이 세 번째 존의 부하를 전부 넘겨받기에는 단순히 부족하기 때문이겠죠.
그래서 마이크로소프트는 이걸 가용성 영역(Availability Zone)이라고 부릅니다. 각 영역은 전원, 냉각, 네트워크 인프라가 완전히 독립된 데이터센터 하나 이상으로 구성됩니다. 한 영역이 다른 영역을 무너뜨려서는 안 됩니다. 영역들은 대개 서로를 잇는 광케이블이 아주 효율적일 만큼만 가깝게 떨어져 있기도 합니다.
다만 이건 마이크로소프트가 하는 방식이고, GCP는 어떤지 모르겠습니다.
그래도 흥미로운 난제이긴 합니다. 가까이 있는 가용성 영역이 전부 정전으로 한꺼번에 내려가면 어떻게 될까요? 이런 상황에 가장 잘 대비한 주요 클라우드 업체는 어디일지 궁금합니다.
저는 마이크로소프트 쪽만 아는데요, '지역-영역 중복 스토리지(geo-zone-redundant storage)'라는 게 있어서 기본 리전의 가용성 영역 3곳 이상에 데이터를 복사하고, 보조 지리 리전에도 복사해요(제 기억엔 최소 100마일 이상 떨어져 있는데, 더 멀 수도 있어요). 여러 지역-영역에 영향을 주려면 사고가 엄청난 규모여야 할 거예요.
90년대에 중요 인프라 고객이 많던 대형 ISP에서 일했습니다. 진정한 이중화(diversity)는 많은 사람이 생각하는 것보다 훨씬 어렵습니다.
백업과 마찬가지입니다. 테스트하지 않으면 없는 것이나 마찬가지입니다.
제가 일했던 곳은 어디나 멀티 AZ 인프라를 갖추고 있었습니다. 하지만 AZ 장애를 정기적으로 시뮬레이션하고 2차 영향까지 파악해 둔 곳은 한 번도 본 적이 없습니다.
저희는 애플리케이션과 서비스를 기본적으로 멀티 AZ로 구성합니다. AWS 서비스 상당수가 리전 단위이거나 글로벌이라서 그렇게 어렵지도 않습니다(다만 DNS 장애가 나면 그때는 문제가 생길 거라고 봅니다). 하지만 저희는 워크플로의 일부일 뿐이고, 멀티 AZ가 아닌 다른 애플리케이션과 연동되어 있어서 영향을 받게 됩니다. 그건 저희 손을 벗어난 일입니다.
온프렘 시스템도 마찬가지입니다. 데이터센터 하나가 오프라인이 되는 상황을 가정해 DR 계획을 세우고 훈련하라는 지시를 받았지만, 계획의 일부가 '같은 데이터센터에 호스팅된 애플리케이션 X가 선택한 장애 조치 방식에 맞춰 적응한다'라면 DR 계획을 온전히 훈련할 수 없습니다. 저희는 애플리케이션 X의 소유자가 아닙니다. 회사 전체가 동시에 DR 훈련을 조율하겠다는 의지는 사업 쪽 어디에도 없습니다.
하위 환경에서 전부 해 보는 것조차 불가능합니다. 환경 간에 공유되는 시스템에 대한 의존성이 있기 때문입니다. 저희 데이터센터들 사이에 동기화되는 거대한 이중화 파일시스템이 있는데, 동기화가 사실상 불리언 값 하나입니다. 한 데이터센터의 인스턴스가 프라이머리이고 나머지는 승격되기 전까지 읽기 전용입니다. 이런 게 하나 있고, 하위 환경은 그 시스템에서 접근 패턴만 다른 별도의 루트 폴더일 뿐이라서, 운영에서는 데이터센터 A를 프라이머리로, UAT에서는 데이터센터 B를 프라이머리로 둘 수가 없습니다.
이걸 한 번도 안 써 본 사람의 질문인데요, 멀티 AZ 구성이 AZ 하나가 떨어져 나가는 상황을 견딜 수 있는지 어떻게 테스트하나요? 서드파티 앱 때문에 테스트가 어차피 별 의미 없을 것 같긴 한데, 궁금해서요!
Ops 쪽 사람입니다. 보통은 AZ를 직접 장애 상태로 만들어 보고 어떻게 되는지 봐야 합니다. 운영과 똑같이 만든 Dev/Staging 환경에 테스트도 충분히 갖춰 놨다면 거기서 하면 되고요. 그런 환경은 딱 하나 봤습니다.
대부분의 회사는 운영 환경에서 해야 하는데, 고객에게 영향을 주는 장애는 원치 않으니까 실제 장애가 났을 때 하는 경향이 있습니다.
고맙습니다! 그러면 모든 것에 스테이징 환경을 두고, 네트워크를 끊거나 인스턴스, Aurora DB 등을 죽인 다음, 그동안 부하를 흉내 내고 데이터 손실이 있는지 확인하는 건가요? 그게 통하면 운영에서도 해 보고요?
엄청난 작업량 같고, 아키텍처가 바뀌어 갈수록 멀티 AZ 장애 조치가 제대로 동작하도록 유지하기도 어려울 것 같아요.
네, 그건 비싸다는 뜻이고, 그래서 기업들이 보통 돈을 쓰지 않는다는 뜻입니다. 그러니 영업이익을 챙기겠다고 그 비용을 쓰지 않는 기업들은 이름을 공개하고 망신을 줘야 합니다.
문제의 기사가 그런 목록을 일부 제공하는 것으로 알고 있습니다.
대부분의 회사가 멀티 존 사용을 고민하고, DR도 정기적으로 테스트하고, 그것도 성공적으로 한다고 생각해요(제가 낙관적인 걸 수도 있지만요). 문제는 그게 전부 화창한 월요일 아침에나 아무 탈 없이 돌아간다는 거예요. 그러다 일이 터지면 갑자기 모두가 동시에 그걸 해야 하잖아요. 완전히 다른 얘기가 되죠.
GCP는 좀 특이한데, 어떤 하드웨어는 특정 존에서만 쓸 수 있고, 어떤 하드웨어는 기술적으로는 여러 존에서 쓸 수 있지만 용량이 고르게 분포되어 있지 않습니다. 저는 GCP용 인프라 코드를 구현하면서 리전과 존별 하드웨어 가용성을 조회해 VM을 배치하도록 했고, 멀티 AZ 가용성은 의미가 있는 곳에서만 절충했습니다.
다른 클라우드도 비슷하게 이상해요(더 심한 곳도 있고요). Azure에서 겪었는데, 어떤 서비스의 기본 SKU로 리소스 그룹을 프로비저닝하면 나중에 최신 최상위 SKU로 올릴 방법이 리소스 그룹 전체를 허물고 처음부터 다시 만드는 것뿐이에요. 제자리 스케일 업은 전부 알 수 없는 오류로 실패하고요. 데이터센터의 오래된 구석에 배정되면 거기서 못 빠져나오는 느낌이에요.
key vault까지 끼어 있으면 더 신나는데요, 그 안의 키를 전부 수동으로 지워야 해요. 안 그러면 새 vault에 같은 이름으로 키를 못 만들거든요.
저는 지금 Azure EUS2에서 관리형 redis 인스턴스조차 못 받고 있어요...
맞습니다. 서비스, 하드웨어, 규제 준수가 겹치는 벤 다이어그램 영역은 놀랄 만큼 작습니다.
제 고객 중에 아주 큰 은행과 계약한 곳이 있었는데, 전 세계에서 배포할 수 있는 존이 네 개쯤밖에 없었습니다.
구글은 AWS와 달리 존 추상화가 매우 가상적이어서, 두 존이 같은 물리적 건물에 있을 수도 있습니다. 배포 존이 최소한 일정 거리 이상 물리적으로 떨어져 있어야 한다는 요건이 있으면 꽤 곤란해질 수 있습니다.
그리고 제가 아는 한, 실제로 쓰고 있는 하드웨어의 정확한 물리적 위치(데이터센터, 홀, 랙)를 알아낼 방법이 없습니다. 있다면 최소한 숨은 의존성이 없는지 확인할 수 있을 텐데요.
그건 어떻게 하는 건가요?
각 존에서 제공한다고 공시된 하드웨어를 나열해 주는 GCP API가 있어서, 그걸 출발점으로 삼습니다. 그다음 각 존에서 실제로 하드웨어를 프로비저닝해 보면서 거기에 어느 정도 용량이 있는지 감을 잡아야 합니다. 둘을 합치면 대략적인 토폴로지를 그려 볼 수 있습니다.