내부자 입장이라 임시 계정 사용 중임, 이번 사고의 근본 원인은 리더십이 속도를 내기 위해 원칙을 무시한 것임, 이런 관행이 수년 동안 지속되어 결국 한계에 도달하게 됨, 이번에 일어난 ‘query of death’는 서버가 특정 쿼리로 인해 크래시 나는 오래된 C++ 서버에서 불가피하게 발생하는 전형적인 실패 유형임, Service Control은 C++로 작성되었고 다양한 엔지니어링 가이드라인을 활용해 이런 실패를 최소화하려고 노력했음, 10년 동안 큰 사고 없이 운영되었으나 최근 리더십 압박 아래 빨리 만든 글로벌 쿼터 정책이 문제였음, 이런 신규 기능은 별도 서비스로 개발하거나 최소한 기존 가이드라인을 준수했어야 함, 공식 보고서에 언급된 대책보다 팀이 원래 지켜온 표준이 훨씬 높음, 팀은 할 수 있는 한 기존 기준을 유지하려고 노력하고 있음
모든 책임을 리더십에만 돌릴 수 없음, 글로벌 전체 반경으로 배포를 극도로 신중히 검토하지 않은 것은 엔지니어링 문화의 실패임, 최소한 글로벌 정책은 지역별 서비스 컨트롤 배포보다 먼저 진행했어야 함
사고 보고서가 흥미롭다는 생각임, SRE 팀이 2분 만에 빠르게 대응하고, ‘red button’ 롤아웃이 시작됐음, 문제는 us-central-1처럼 대규모 리전에서 Service Control 태스크가 재시작될 때 인프라(Spanner 테이블)에 과부하가 걸리는 ‘herd effect’가 나타났다는 점임, Service Control에 무작위 지수 백오프가 구현되어 있지 않아 2시간 40분까지 완전한 복구가 지연됨, 이런 상황에서는 정상적인 쿼터가 빨리 초과되며 새로운 장애로 이어짐, 이런 경우 인프라가 견딜 수 있다면 쿼터를 임시로 중단하거나 복구 작업을 느리게 제한하는 것도 좋다고 생각함
이 상황에서는 지수 백오프가 적합한 대책이 아니었음, 서버 시작 시 중요한 데이터를 읽을 때 의도적으로 재시도 없이 처리되므로 백오프 적용이 안 됨, 더 좋은 방법은 기존에 존재하는 백업 데이터베이스로 부하를 빠르게 분산하는 것임, 다른 방법도 있음
내 생각에는 인간이든 자동화든 방어책에 완벽함이란 없으며, 결국 트레이드오프의 연속임, 아무리 많은 유닛 테스트와 통합 테스트, 정적 분석, 순차적 배포를 해도 규모가 커지면 예기치 못한 빈틈이 생길 수밖에 없음, 책에서 말하는 “또 다른 9를 추가하는 데 훨씬 더 많은 노력이 드는 것”과 동일한 이유임, 최악의 경우 전체 스택을 복제해서 수개월치 트래픽을 모두 재생해야 할 수도 있는데, 이런 수준의 비용/혜택은 아무도 감당하지 못함, OpenZFS 작업에서도 코드 자체는 정상적으로 보였지만 10년 전에 쓰여진 데이터 엣지 케이스에서 문제가 드러난 경험 있음, 시스템이 충분히 복잡해지면 모든 변형을 테스트하는 건 불가능해지므로 현실적으로 비용 대비 효용을 기준으로 결정할 수밖에 없음, 참고로 구글 SRE지만 이 사건과는 관련 없는 팀이며 개인 의견임
거의 모든 구글 글로벌 장애가 이와 비슷하게 전개됨, 즉 빠르게 글로벌로 배포된 맞춤 시스템이 잘못된 설정을 반영받음, 일반적인 바이너리 롤아웃이나 설정 푸시에선 점진적 롤아웃이 적용되는 게 보통임, 구글 클라우드에서도 예전엔 다양한 시스템이 글로벌로 묶여 있었으나 이젠 상당히 지역화되고 신뢰성이 높아짐, 이전에는 글로벌 장애가 종종 있었지만 공개되지 않아 대부분 사용자들은 자신의 ISP 문제로 인식했었음, 현재가 특별히 악화되고 있다고 생각하지 않음, 추가로 SRE 경험 있음
외부인 입장에서 생각해보면 대규모 구조조정, CEO의 '게으름' 발언 등 이후로 모두 품질보다는 속도와 가시적 성과에 치중하게 됨, 점차 이런 문화를 문제 삼으면 되려 배척 받는 환경 변화가 생김
더 자세한 정보가 공개되었으면 함, 본인은 여기에 언급된 대로 테스트가 안 된 게 아니라, 정책의 빈 필드(문제 되는 입력)에 대한 테스트가 없었다고 봄, 스테이징 환경에서 테스트가 없다는 설명도 아니고, 플래그가 있었다면 잡았을 것이란 언급임, 개인 의견임
“가장 위험한 도구도 익숙해지면 조심성을 잃고, 지침이 불필요하게 엄격하다고 여기게 된다”는 1864년 화약창고 보고서가 생각남
나는 Cloud 내 다른 팀 소속임, 일반적으로 모든 코드엔 유닛 및 통합 테스트가 있음, 바이너리나 설정 변경은 작업별, 지역별로 며칠에 걸쳐 점진적으로 이루어짐, 카나리아 분석도 동반함, 심지어 롤백도 너무 급하게 하면 오히려 상황 악화 가능성 있어 천천히 진행함, 예를 들어 전역 데이터베이스를 일시에 과부하시키기보단 40분 정전이 4시간 장애보다 낫다고 판단함, 이번 사고에 직접 관여하지 않았지만 PM을 보면 코드는 테스트되었으나 이 엣지 케이스는 누락된 것임, 쿼터 정책 설정이 바이너리나 설정 파일이 아닌 데이터베이스 업데이트로 적용되어 전세계 모든 데이터베이스에 몇 초 만에 변경이 번진 것이 문제임, 널 포인터 문제는 다른 언어에도 assert()로 발생했을 가능성이 있음, 이런 핵심 서비스를 다른 언어로 재작성하는 위험보다 모든 정책 점검에 플래그 가드 적용, 쿼터 정책 점검은 오픈 실패, DB 변경을 지역별로 천천히 확산시키는 쪽이 더 합리적임, 개인 의견임
assert는 정책적으로 금지하기 훨씬 쉬운 구조임
코드는 테스트됐지만 이 엣지 케이스는 누락된 거니까, 결국 테스트 안 한 셈이라는 반론임
DB 변경이 바이너리나 설정 변경이 아니라고 해서 문제가 달라지는 건 아님, 변경 자체가 동시에 전역에 퍼지면 어떤 종류든 재앙의 씨앗임, Crowdstrike 사태와 똑같은 흐름임
“언어를 바꿔 재작성하는 게 위험 부담이 너무 높다”는 의견이라면, 즉 서비스 요구사항이 제대로 파악되어 있지 않거나, 서비스가 신중한 마이그레이션이 필요할 만큼 중요하지 않은 것인지 궁금
적절한 에러 핸들링 없이 널 포인터로 바이너리가 크래쉬 됐다는 내용임, 이쯤이면 '트릴리언 달러 실수'라는 농담이 나올 만함
이번 사고로 몇 개의 SLA를 한 해 동안 날려버렸을지 궁금함
이런 문제를 막아줄 언어가 있었다면 하는 생각에 /s(비꼬는 투)임
Service Control(Chemist)이 꽤 오래된 서비스이며, 여러 GCP API에서 인증, 권한, 감시, 쿼터 등 핵심적 역할을 함, 요청 흐름상 대부분의 GCP API가 Chemist를 경유함(그래서 fail open 완화책이 실효적이지 않다고 봄), Chemist와 프록시 모두 C++로 작성되어 있으며 수년간 레거시 코드가 많이 쌓였음, 각 팀은 정적 분석, 테스트, 점진적 배포, 피처 플래그, red button, 강력한 모니터링 및 경보시스템을 갖추고 있음, 특히 SRE팀은 뛰어남, Chemist에서 IAM, 쿼터 등 다양한 정책을 검증하다 보니 여러팀이 코드베이스에 기여함, 변경할 때마다 Chemist 승인 과정을 거치지 않으려고 단축 경로로 개발한 부분이 많아짐, 최근엔 조직 개편과 오프쇼어가 많아서 L8/L9급 주도 화려한 신규 프로젝트에 치중, 정작 품질·유지보수·신뢰성은 후순위가 되었음(이런 문화 변화 때문에 Cloud에서 떠났음), 구글 일반 서버/서비스 모범 사례가 여기선 지켜지지 않을 때가 많음, 이번 이슈는 코드와 코드리뷰의 부실 쪽에 가까움, 결함이 있던 코드를 승인하고 Spanner로 설정 변경을 즉시 반영시켜 문제가 커짐
서비스 정책 데이터에 의도치 않은 빈 필드가 포함되었고, Service Control이 각 리전별로 쿼터 체크 시 빈 필드(널)를 읽어 예외가 발생했음, Hoare의 ‘십억 달러 실수’가 여러 구글 시스템에서 반복된 예시임, 애초에 이런 ‘빈 필드’(null)가 들어갈 수 있도록 허용한 게 문제인데, 스키마에서 null 불허(‘NOT NULL’)를 명시했어야 함, 불행히도 Spanner에서 기본값이 nullable이라 별도 지정 필요, 앱 코드 레벨에서 타입 시스템이나 스키마 언어를 통해 유효하지 않은 상태가 불가능하도록 설계할 기회가 또 있었음, 데이터스토어에서 앱 객체로 역직렬화하면서 스키마 강제 검증을 추가하는 방법도 있음, 본문 이슈가 새로운 코드 경로에서 터진 만큼 데이터 계층에서 걸러지지 않은 게 아닌가 싶음, Service Control 프로그램 자체가 널 포인터 참조를 허용하는 언어로 작성된 것도 문제임, 만약 내가 관리 담당자라면, 정책을 앱 코드에서 ‘태그드 enum 타입’ 등 null을 표현할 수 없는 구조로 바꾸는 최소 개입 플랜을 생각해보겠음, proto3에는 이런 제약이 없으나, 이런 예시는 있음
멀티리전이 회복력과 가용성 수단으로 자주 언급되지만, 실제로는 장애 상황에서 대형 클라우드 제공자도 리전 간 강하게 얽혀 있다는 게 흥미로움
이건 특히 GCP에서 두드러지는데, GCP는 리전을 타사보다 다르게 다룸, 회복성 관점에선 GCP를 다수 존이 묶인 단일 리전처럼 봐야 함
그럼에도 불구하고 “우리가 모르는 장애”는 여전히 있을 수 있으므로 리전/존 샤딩의 효과를 지나치게 과소평가하면 곤란함
멀티리전 배포 덕에 사고를 예방한 사례도 많으니 실제로 그런 케이스를 파악한 후 결론을 내리는 게 맞음
구글 포스트모템의 디테일에 늘 놀람, 회사 안팎 모두에서 느껴짐, 실수 반복하지 않도록 배우고, 프로토콜과 에러 핸들링 보강해 더욱 강인한 시스템으로 진화함, 구글처럼 규모가 큰 곳에선 항상 무언가가 잘못되고 있지만 핵심은 고객/사용자와 다른 시스템에 영향 가지 않게 차단하는 것임, 내부에 있더라도 팀에 따라 보이지 않는 이슈가 다양함, 이는 인간이 만든 시스템 중 가장 복잡한 축에 속한다고 봄, AGI가 아니라면 인간이 더 잘할 수 없는 영역임
하지만 이번 사고엔 주니어급 실수가 연달아 일어남, null 데이터 처리를 못 한 점, 테스트 부족, 신기능에 대한 테스트 커버리지 없음, 전면 배포 전 소규모 프로덕션에서 검증하지 않은 점 모두 문제임, 10년 전 구글에서라면 이런 실수에 다들 비웃었을 거라고 확신함
내 이해로는 이번 장애 원인은 1) 전역적 기능이 한번에 전체 배포됨 2) 널 포인터 역참조 발생 3) 적절한 재시도 정책 부재로 'thundering herd' 문제 야기, 모두 업계 사람이라면 익숙한 실수임, 신기하거나 복잡한 분산 시스템 로직이 아니라 전형적인 ‘초보 실수’가 복합적으로 터진 셈임
“다시는 같은 실수 반복하지 않는다”는 말이 있지만, 실제론 피처 플래그 없이 변경을 롤아웃했고, 클라이언트엔 지수 백오프도, 서버에 로드 셰딩도 구현하지 않았음, 이 모두가 수년 전부터 google SRE book에 나온 내용임
이 오류는 미처 잡지 못한 널 포인터 문제였음, 구글 정도 규모와 품질을 가진 회사가 이런 식으로 스택 대부분을 다운시키는 것은 심각한 이슈 재발 방지책이 부족하다는 신호로 읽힐 수 있음
이건 수없이 반복된 동일한 실수임, “새 기능을 조심스럽게 배포하지만, 새로운 데이터가 들어와야만 드러나는 버그”가 대부분의 글로벌 장애를 요약하는 문구임, 완벽한 시스템은 존재하지 않음, FAANG 장애 논쟁에서만 무결점인 건 ‘HN의 armchair 전문가’뿐임
대부분, 남의 다운타임을 볼 땐 ‘주니어급 실수’라고 쉽게 비판하지만, 정작 자기 일에선 불가피했다, 예측불가했다는 핑계가 남음, 인간 실수는 불가피하며 기대치 자체가 너무 높음, 오프라인 가게가 갑자기 문 닫아도 “죄송하다” 한마디에 끝남, 오직 IT 업계만 몇 시간짜리 장애로 과도하게 스트레스를 받는 데 모두 조금 더 여유를 갖길 바람
Hacker News 의견
내부자 입장이라 임시 계정 사용 중임, 이번 사고의 근본 원인은 리더십이 속도를 내기 위해 원칙을 무시한 것임, 이런 관행이 수년 동안 지속되어 결국 한계에 도달하게 됨, 이번에 일어난 ‘query of death’는 서버가 특정 쿼리로 인해 크래시 나는 오래된 C++ 서버에서 불가피하게 발생하는 전형적인 실패 유형임, Service Control은 C++로 작성되었고 다양한 엔지니어링 가이드라인을 활용해 이런 실패를 최소화하려고 노력했음, 10년 동안 큰 사고 없이 운영되었으나 최근 리더십 압박 아래 빨리 만든 글로벌 쿼터 정책이 문제였음, 이런 신규 기능은 별도 서비스로 개발하거나 최소한 기존 가이드라인을 준수했어야 함, 공식 보고서에 언급된 대책보다 팀이 원래 지켜온 표준이 훨씬 높음, 팀은 할 수 있는 한 기존 기준을 유지하려고 노력하고 있음
사고 보고서가 흥미롭다는 생각임, SRE 팀이 2분 만에 빠르게 대응하고, ‘red button’ 롤아웃이 시작됐음, 문제는 us-central-1처럼 대규모 리전에서 Service Control 태스크가 재시작될 때 인프라(Spanner 테이블)에 과부하가 걸리는 ‘herd effect’가 나타났다는 점임, Service Control에 무작위 지수 백오프가 구현되어 있지 않아 2시간 40분까지 완전한 복구가 지연됨, 이런 상황에서는 정상적인 쿼터가 빨리 초과되며 새로운 장애로 이어짐, 이런 경우 인프라가 견딜 수 있다면 쿼터를 임시로 중단하거나 복구 작업을 느리게 제한하는 것도 좋다고 생각함
이건 정말 아마추어 같은 실수라는 생각임, NPE, 에러 핸들링 없음, 지수 백오프 없음, 테스트 커버리지 없음, 스테이징 환경에서 테스트 없음, 점진적 롤아웃 없음, 모두 심각한 실패임, SRE 책에 이미 다 나와 있는 내용임 Google SRE Book 목차, Building Secure and Reliable Systems TOC, 기준이 너무 낮아진 것인지 아니면 책이 그냥 마케팅 용인지 궁금함
내 생각에는 인간이든 자동화든 방어책에 완벽함이란 없으며, 결국 트레이드오프의 연속임, 아무리 많은 유닛 테스트와 통합 테스트, 정적 분석, 순차적 배포를 해도 규모가 커지면 예기치 못한 빈틈이 생길 수밖에 없음, 책에서 말하는 “또 다른 9를 추가하는 데 훨씬 더 많은 노력이 드는 것”과 동일한 이유임, 최악의 경우 전체 스택을 복제해서 수개월치 트래픽을 모두 재생해야 할 수도 있는데, 이런 수준의 비용/혜택은 아무도 감당하지 못함, OpenZFS 작업에서도 코드 자체는 정상적으로 보였지만 10년 전에 쓰여진 데이터 엣지 케이스에서 문제가 드러난 경험 있음, 시스템이 충분히 복잡해지면 모든 변형을 테스트하는 건 불가능해지므로 현실적으로 비용 대비 효용을 기준으로 결정할 수밖에 없음, 참고로 구글 SRE지만 이 사건과는 관련 없는 팀이며 개인 의견임
거의 모든 구글 글로벌 장애가 이와 비슷하게 전개됨, 즉 빠르게 글로벌로 배포된 맞춤 시스템이 잘못된 설정을 반영받음, 일반적인 바이너리 롤아웃이나 설정 푸시에선 점진적 롤아웃이 적용되는 게 보통임, 구글 클라우드에서도 예전엔 다양한 시스템이 글로벌로 묶여 있었으나 이젠 상당히 지역화되고 신뢰성이 높아짐, 이전에는 글로벌 장애가 종종 있었지만 공개되지 않아 대부분 사용자들은 자신의 ISP 문제로 인식했었음, 현재가 특별히 악화되고 있다고 생각하지 않음, 추가로 SRE 경험 있음
외부인 입장에서 생각해보면 대규모 구조조정, CEO의 '게으름' 발언 등 이후로 모두 품질보다는 속도와 가시적 성과에 치중하게 됨, 점차 이런 문화를 문제 삼으면 되려 배척 받는 환경 변화가 생김
더 자세한 정보가 공개되었으면 함, 본인은 여기에 언급된 대로 테스트가 안 된 게 아니라, 정책의 빈 필드(문제 되는 입력)에 대한 테스트가 없었다고 봄, 스테이징 환경에서 테스트가 없다는 설명도 아니고, 플래그가 있었다면 잡았을 것이란 언급임, 개인 의견임
“가장 위험한 도구도 익숙해지면 조심성을 잃고, 지침이 불필요하게 엄격하다고 여기게 된다”는 1864년 화약창고 보고서가 생각남
나는 Cloud 내 다른 팀 소속임, 일반적으로 모든 코드엔 유닛 및 통합 테스트가 있음, 바이너리나 설정 변경은 작업별, 지역별로 며칠에 걸쳐 점진적으로 이루어짐, 카나리아 분석도 동반함, 심지어 롤백도 너무 급하게 하면 오히려 상황 악화 가능성 있어 천천히 진행함, 예를 들어 전역 데이터베이스를 일시에 과부하시키기보단 40분 정전이 4시간 장애보다 낫다고 판단함, 이번 사고에 직접 관여하지 않았지만 PM을 보면 코드는 테스트되었으나 이 엣지 케이스는 누락된 것임, 쿼터 정책 설정이 바이너리나 설정 파일이 아닌 데이터베이스 업데이트로 적용되어 전세계 모든 데이터베이스에 몇 초 만에 변경이 번진 것이 문제임, 널 포인터 문제는 다른 언어에도 assert()로 발생했을 가능성이 있음, 이런 핵심 서비스를 다른 언어로 재작성하는 위험보다 모든 정책 점검에 플래그 가드 적용, 쿼터 정책 점검은 오픈 실패, DB 변경을 지역별로 천천히 확산시키는 쪽이 더 합리적임, 개인 의견임
assert는 정책적으로 금지하기 훨씬 쉬운 구조임
코드는 테스트됐지만 이 엣지 케이스는 누락된 거니까, 결국 테스트 안 한 셈이라는 반론임
DB 변경이 바이너리나 설정 변경이 아니라고 해서 문제가 달라지는 건 아님, 변경 자체가 동시에 전역에 퍼지면 어떤 종류든 재앙의 씨앗임, Crowdstrike 사태와 똑같은 흐름임
“언어를 바꿔 재작성하는 게 위험 부담이 너무 높다”는 의견이라면, 즉 서비스 요구사항이 제대로 파악되어 있지 않거나, 서비스가 신중한 마이그레이션이 필요할 만큼 중요하지 않은 것인지 궁금
적절한 에러 핸들링 없이 널 포인터로 바이너리가 크래쉬 됐다는 내용임, 이쯤이면 '트릴리언 달러 실수'라는 농담이 나올 만함
이번 사고로 몇 개의 SLA를 한 해 동안 날려버렸을지 궁금함
이런 문제를 막아줄 언어가 있었다면 하는 생각에 /s(비꼬는 투)임
Service Control(Chemist)이 꽤 오래된 서비스이며, 여러 GCP API에서 인증, 권한, 감시, 쿼터 등 핵심적 역할을 함, 요청 흐름상 대부분의 GCP API가 Chemist를 경유함(그래서 fail open 완화책이 실효적이지 않다고 봄), Chemist와 프록시 모두 C++로 작성되어 있으며 수년간 레거시 코드가 많이 쌓였음, 각 팀은 정적 분석, 테스트, 점진적 배포, 피처 플래그, red button, 강력한 모니터링 및 경보시스템을 갖추고 있음, 특히 SRE팀은 뛰어남, Chemist에서 IAM, 쿼터 등 다양한 정책을 검증하다 보니 여러팀이 코드베이스에 기여함, 변경할 때마다 Chemist 승인 과정을 거치지 않으려고 단축 경로로 개발한 부분이 많아짐, 최근엔 조직 개편과 오프쇼어가 많아서 L8/L9급 주도 화려한 신규 프로젝트에 치중, 정작 품질·유지보수·신뢰성은 후순위가 되었음(이런 문화 변화 때문에 Cloud에서 떠났음), 구글 일반 서버/서비스 모범 사례가 여기선 지켜지지 않을 때가 많음, 이번 이슈는 코드와 코드리뷰의 부실 쪽에 가까움, 결함이 있던 코드를 승인하고 Spanner로 설정 변경을 즉시 반영시켜 문제가 커짐
서비스 정책 데이터에 의도치 않은 빈 필드가 포함되었고, Service Control이 각 리전별로 쿼터 체크 시 빈 필드(널)를 읽어 예외가 발생했음, Hoare의 ‘십억 달러 실수’가 여러 구글 시스템에서 반복된 예시임, 애초에 이런 ‘빈 필드’(null)가 들어갈 수 있도록 허용한 게 문제인데, 스키마에서 null 불허(‘NOT NULL’)를 명시했어야 함, 불행히도 Spanner에서 기본값이 nullable이라 별도 지정 필요, 앱 코드 레벨에서 타입 시스템이나 스키마 언어를 통해 유효하지 않은 상태가 불가능하도록 설계할 기회가 또 있었음, 데이터스토어에서 앱 객체로 역직렬화하면서 스키마 강제 검증을 추가하는 방법도 있음, 본문 이슈가 새로운 코드 경로에서 터진 만큼 데이터 계층에서 걸러지지 않은 게 아닌가 싶음, Service Control 프로그램 자체가 널 포인터 참조를 허용하는 언어로 작성된 것도 문제임, 만약 내가 관리 담당자라면, 정책을 앱 코드에서 ‘태그드 enum 타입’ 등 null을 표현할 수 없는 구조로 바꾸는 최소 개입 플랜을 생각해보겠음, proto3에는 이런 제약이 없으나, 이런 예시는 있음
멀티리전이 회복력과 가용성 수단으로 자주 언급되지만, 실제로는 장애 상황에서 대형 클라우드 제공자도 리전 간 강하게 얽혀 있다는 게 흥미로움
이건 특히 GCP에서 두드러지는데, GCP는 리전을 타사보다 다르게 다룸, 회복성 관점에선 GCP를 다수 존이 묶인 단일 리전처럼 봐야 함
그럼에도 불구하고 “우리가 모르는 장애”는 여전히 있을 수 있으므로 리전/존 샤딩의 효과를 지나치게 과소평가하면 곤란함
멀티리전 배포 덕에 사고를 예방한 사례도 많으니 실제로 그런 케이스를 파악한 후 결론을 내리는 게 맞음
구글 포스트모템의 디테일에 늘 놀람, 회사 안팎 모두에서 느껴짐, 실수 반복하지 않도록 배우고, 프로토콜과 에러 핸들링 보강해 더욱 강인한 시스템으로 진화함, 구글처럼 규모가 큰 곳에선 항상 무언가가 잘못되고 있지만 핵심은 고객/사용자와 다른 시스템에 영향 가지 않게 차단하는 것임, 내부에 있더라도 팀에 따라 보이지 않는 이슈가 다양함, 이는 인간이 만든 시스템 중 가장 복잡한 축에 속한다고 봄, AGI가 아니라면 인간이 더 잘할 수 없는 영역임
하지만 이번 사고엔 주니어급 실수가 연달아 일어남, null 데이터 처리를 못 한 점, 테스트 부족, 신기능에 대한 테스트 커버리지 없음, 전면 배포 전 소규모 프로덕션에서 검증하지 않은 점 모두 문제임, 10년 전 구글에서라면 이런 실수에 다들 비웃었을 거라고 확신함
내 이해로는 이번 장애 원인은 1) 전역적 기능이 한번에 전체 배포됨 2) 널 포인터 역참조 발생 3) 적절한 재시도 정책 부재로 'thundering herd' 문제 야기, 모두 업계 사람이라면 익숙한 실수임, 신기하거나 복잡한 분산 시스템 로직이 아니라 전형적인 ‘초보 실수’가 복합적으로 터진 셈임
“다시는 같은 실수 반복하지 않는다”는 말이 있지만, 실제론 피처 플래그 없이 변경을 롤아웃했고, 클라이언트엔 지수 백오프도, 서버에 로드 셰딩도 구현하지 않았음, 이 모두가 수년 전부터 google SRE book에 나온 내용임
이 오류는 미처 잡지 못한 널 포인터 문제였음, 구글 정도 규모와 품질을 가진 회사가 이런 식으로 스택 대부분을 다운시키는 것은 심각한 이슈 재발 방지책이 부족하다는 신호로 읽힐 수 있음
이건 수없이 반복된 동일한 실수임, “새 기능을 조심스럽게 배포하지만, 새로운 데이터가 들어와야만 드러나는 버그”가 대부분의 글로벌 장애를 요약하는 문구임, 완벽한 시스템은 존재하지 않음, FAANG 장애 논쟁에서만 무결점인 건 ‘HN의 armchair 전문가’뿐임
대부분, 남의 다운타임을 볼 땐 ‘주니어급 실수’라고 쉽게 비판하지만, 정작 자기 일에선 불가피했다, 예측불가했다는 핑계가 남음, 인간 실수는 불가피하며 기대치 자체가 너무 높음, 오프라인 가게가 갑자기 문 닫아도 “죄송하다” 한마디에 끝남, 오직 IT 업계만 몇 시간짜리 장애로 과도하게 스트레스를 받는 데 모두 조금 더 여유를 갖길 바람