요약

  • Fastly 서비스 버전은 이전 구성을 쉽게 재활성화할 수 있게 해 주지만, API에서 보이는 활성 버전은 컨트롤 플레인 상태이며 모든 서빙 인구집단이 수렴을 마쳤다는 요청 수준의 증거가 아닙니다.
  • 롤백 승인은 각 관찰된 POP에서 철회된 버전이 마지막으로 제어한 응답, 복구된 버전, 정확한 유해 테스트, 그리고 별도의 퍼지 또는 캐시 세대 상태가 있는지 여부를 기록해야 합니다.

중앙 화면에는 롤백이 성공했다고 표시됩니다. 이전 서비스 버전이 다시 활성 상태입니다. 오류율은 떨어집니다. 그런데도 어느 먼 지점(point of presence)에 도달한 요청이 운영자가 철회하려던 규칙을 그대로 따릅니다. 이 시나리오는 가상의 수용 테스트일 뿐이며, 보고된 Fastly 사건이 아닙니다. 그 목적은 명령과 결과를 구별하는 데 있습니다.

Fastly의 구성 모델은 운영자에게 유용한 통제 수단을 제공합니다. 서비스 버전은 복제, 잠금, 활성화 또는 비활성화가 가능한 정의된 구성 인스턴스입니다. 한 번에 한 버전만 활성 상태이며, 비활성화된 오래된 버전을 다시 활성화할 수 있습니다. 이는 복구할 명확한 대상을 만들어 줍니다. 동시에 유혹적인 완료 타임스탬프도 만듭니다. 활성화 요청이 반환되고 대시보드가 의도한 숫자를 보여주는 그 순간이 바로 그것입니다.

Fastly 자체 입문 튜토리얼은 구성 변경이 전파되는 데 몇 분 정도 걸릴 수 있다고 말합니다. 이 진술은 결함의 증거가 아니며, 분산 시스템이 상태를 분산하는 데 시간이 필요하다는 의미일 뿐입니다. 다만 이는 중앙 승인과 전역 요청 동작이 서로 다른 관찰이라는 것을 의미합니다. 첫 번째에서 롤백을 정의한 운영자는 아직 두 번째를 측정하지 않은 것입니다.

POP는 지도 위의 점이 아니라 실행 인구집단이다

Fastly는 접점(point of presence)을 캐시 서버 군집으로 설명합니다. 클러스터링과 셸딩을 거치면 요청은 오리진에 도달하기까지 둘 이상의 사이트나 POP를 경유할 수 있습니다. Fastly는 VCL에서는server.데이터센터로, Compute에서는FASTLY_POP으로 서빙 위치를 노출합니다. 또한 엣지 코드에 서비스 버전 환경 값을 노출합니다. 이 식별자들이 요청 수준 롤백 장부의 기초입니다. 어떤 버전이 이 결정을 내렸는지, 어떤 인구집단에서, 언제, 어떤 정확한 테스트에 대해 내렸는지 기록하는 것입니다.

일반적인 헬스 엔드포인트로는 부족합니다. 카나리아 테스트는 철회된 동작—즉 롤백을 유발한 경로 재작성, 접근 규칙, 오리진 선택, 헤더 정책, 캐시 키, Compute 분기 또는 보안 결정—을 실제로 실행해야 합니다. 관련 없는 코드의 녹색 응답은 네트워크가 응답할 수 있다는 것만 증명합니다.

첫 번째 유용한 타임스탬프는 중앙 활성화 승인입니다. 결정적인 타임스탬프는 철회된 버전이나 규칙이 제어한 마지막 관찰 응답입니다. 그 사이가 롤백 수렴 구간입니다. 평균이 아니라 관찰된 POP 전반에서의 최댓값을 측정하십시오. 드문 부실 결정 하나가 올바르고 위험이 낮은 대규모 요청 집단보다 더 중요할 수 있습니다.

로그는 증거이지 전지(全知)가 아니다

Fastly는 거의 실시간에 가까운 스트리밍 로그를 지원하며, 고객이 요청을 처리한 데이터센터를 기록하도록 합니다. 이는 강력한 긍정 증거입니다. 로그는 특정 POP가 어떤 버전을 실행했거나 어떤 결과를 반환했음을 보여줄 수 있습니다. 다만 Fastly는 실시간 로그 전달이 최선 노력(best effort)이며 보장되지 않는다고 명시합니다. 분산 시스템이 성능과 안정성을 우선할 때 기록이 누락될 수 있습니다.

함의는 미묘합니다. 기한 이후에 철회된 버전이 관찰되면 롤백 실패가 증명됩니다. 그러나 최선 노력 스트림에서 그것이 보이지 않는다고 해서 그 자체로 전역 부재가 증명되지는 않습니다. 신뢰할 수 있는 승인 기록은 능동 프로브, 요청 수준의 버전 및 POP 마커, 플랫폼 텔레메트리 또는 지원 증거, 그리고 관찰되지 않은 인구집단의 명시적 목록을 결합해야 합니다. 침묵은 확실성으로 변환되지 않고 커버리지 공백으로 표기되어야 합니다.

애니캐스트는 이를 어렵게 만듭니다. 고객이 모든 POP를 거치도록 프로브를 지시할 수는 없습니다. 라우팅이 네트워크상 가까운 위치를 선택하기 때문입니다. 답은 전체 커버리지를 가장하는 것이 아닙니다. 분산 프로브, 실사용자 트래픽, 지역 테스트 클라이언트, 그리고 Fastly 증거를 사용하고, 실제로 관찰된 인구집단 분모를 보고하십시오. 고위험 서비스가 충분한 커버리지를 확보하지 못한다면, 결정 소유자는 검증 창을 연장하거나, 트래픽을 제한하거나, 잔여 불확실성을 수용해야 합니다.

구성과 캐시는 서로 다른 롤백 표면이다

서비스 버전을 복구하는 것만으로 모든 캐시 문제가 해결되지는 않습니다. Fastly의 퍼지 문서는 여러 메커니즘과 시계를 설명합니다. 전체 퍼지는 최대 2분까지 걸릴 수 있습니다. URL 및 서러게이트 키 퍼지는 거시 스타일 메커니즘을 통해 약 150밀리초 내에 전파됩니다. 엣지 코드가 발행한 캐시 키 퍼지는 전역 범위를 선택하지 않는 한 해당 POP에 국한됩니다. 소프트 퍼지는 일부 상황에서 콘텐츠를 의도적으로 스테일 상태로 유지합니다.

Fastly는 또한 셸드가 퍼지 이전 콘텐츠를 엣지에 반환하여 오래된 콘텐츠가 캐시에 남을 수 있는 경쟁 상태를 문서화하고 있습니다. 전체 퍼지에 대해서는 VCL과 Compute를 통해 캐시 세대 값을 노출하며 셸드와 엣지 세대를 비교하는 방법을 설명합니다. 바로 이 때문에 롤백 증거가 단일 버전 번호일 수 없습니다. 구성은 복구되었을 수 있지만, 캐시된 콘텐츠, 캐시 키, 동적 데이터 또는 오리진 상태는 독립적으로 잘못된 채 남아 있을 수 있습니다.

운영자는 유해 결과가 실행 가능한 구성에 있는지, 캐시된 객체에 있는지, 둘 다인지, 혹은 Fastly 밖에 있는지 판단해야 합니다. 퍼지가 필요하다면 복구 계획은 오리진을 재충전 급증으로부터 보호해야 합니다. 오리진을 과부하에 빠뜨리는 기술적으로 완전한 퍼지는 비즈니스 복구가 아닙니다.

2021년 장애가 주는 교훈

Fastly는 2021년 6월 8일 전역 장애가 유효한 고객 구성 변경에 의해 트리거된 미확인 소프트웨어 버그 때문이었다고 밝혔습니다. 공개 타임라인은 09:47 UTC에 발생, 10:27에 트리거 구성 식별, 10:36에 복구 시작, 11:00까지 대부분 서비스 복구, 12:35에 완화, 17:25부터 영구 수정 배포를 기록합니다.

이 사건은 유효한 구성이 플랫폼 소프트웨어와 전역 규모에서 상호작용할 수 있으며, 복구에는 단계가 있음을 보여줍니다. 특정 POP가 철회된 규칙을 계속 실행했다고 진술하지는 않으며, 그런 주장을 만들어내는 데 사용해서는 안 됩니다. 조달에 주는 교훈은 더 좁습니다. 롤백은 복구 시간과 관찰 가능한 완료가 별도의 수용 증거를 요구하는 역량이라는 점입니다.

롤백 증거 장부

모든 고영향 변경에 대해 서비스 ID, 철회된 버전과 의도된 복구 버전, 중앙 요청과 응답, POP별 요청 관찰 버전, POP·지역·셸드 경로·추적 식별자, 정확한 유해 카나리아, 캐시 세대 또는 퍼지 식별자, 첫 복구 응답과 마지막 철회 응답, 인구집단 커버리지와 로그 공백, 그리고 인시던트 종료를 선언할 권한자를 기록하십시오.

목표를 배포 전에 정하십시오. 예를 들면: 허용된 수렴 창 이후 철회된 보안 규칙에 의해 제어되는 응답이 없을 것, 합의된 관찰 인구집단 전반에서 그럴 것, 캐시 세대 불일치가 0일 것, 고위험 지역에 설명되지 않은 공백이 없을 것입니다. 그 수치는 이 글이 공개 문서에서 도출할 수 없는 보편적 약속이 아니라 비즈니스 결과를 반영해야 합니다.

이사회 수준의 결론은 Fastly가 전파 시간을 없애야 한다는 것이 아닙니다. 구매자가 API 응답을 의미적 증명으로 바꿔서는 안 된다는 것입니다. 롤백은 합의된 커버리지 내에서 이전 결정이 더 이상 관찰되지 않고 나머지 불확실성이 소유된 경우에 완료된 것이지—버튼 색이 바뀌었을 때가 아닙니다.

출처