4월 29일 브레이즈 정전: 무슨 일이 일어났고, 왜 발생했으며, 어떻게 대응하고 있나요?

Braze 플랫폼의 서비스 아키텍처 이해

Braze는 8개의 미국 클러스터 각각에 대해 별도의 서버 세트를 유지 관리합니다. Braze US 01~07 클러스터는 Amazon Web Services(AWS)에서 호스팅되는 반면 Braze US 08 클러스터는 Microsoft Azure에서 호스팅됩니다. 이러한 각 환경에서 Braze는 여러 가용성 영역을 사용하고 시스템의 각 부분에 대한 중복성을 갖습니다. 가용성 영역에 장애가 발생하는 경우 당사는 손상된 가용성 영역의 라우팅 및 처리를 정기적이고 투명하게 비활성화합니다. 이를 통해 클라우드 서비스 제공업체의 가동 중단 중에도 서비스 제공 가능성을 안정적으로 유지할 수 있습니다.

몇 가지 예외를 제외하고 각 미국 클러스터에는 자체 전용 인프라가 있으며 특정 클라우드 지역의 모든 환경에서 사용되는 소수의 구성 요소를 제외하고 이러한 클러스터는 위험을 줄이기 위해 서로 엄격하게 격리됩니다. 한 클러스터의 중단이 다른 클러스터에 영향을 미칠 수 있습니다.

Braze 플랫폼의 실시간 처리 워크로드의 강도로 인해 2013년부터 우리는 Rackspace와 협력하여 MongoDB 데이터베이스를 실행하기 위해 사용자 정의 구성 하드웨어를 호스팅함으로써 AWS 및 Azure 사용을 보완했습니다. 당사의 AWS 및 Azure 환경은 AWS Direct Connect 및 Azure ExpressRoute 프라이빗 클라우드 커넥터로 구성되어 전용 광섬유 케이블을 통해 Rackspace 데이터 센터에서 유지 관리되는 내부 네트워크에 클라우드 환경을 연결합니다. 초당 100기가비트 이상의 네트워크 트래픽을 전송하는 여러 인터페이스를 지원하는 네트워크 링크로 구동되는 이 암호화된 연결은 클라우드와 Rackspace 환경 간에 고성능 액세스를 제공합니다.

Rackspace의 맞춤형 환경에는 Braze 전용 캐비닛에 수백 대의 물리적 서버가 보관되어 있습니다. 이 설정에는 중복 전원 공급 장치와 중복 랙 상단형 스위치가 포함됩니다. 랙 상단형 스위치는 서버 랙에 위치하며 동일한 서버 랙에 있는 장치와 서버를 함께 연결하는 네트워크 장치입니다. 이러한 스위치는 영향 없이 장애 조치가 이루어지도록 최소 1년에 한 번 테스트됩니다. 작년 테스트는 2023년 8월 3일에 성공적으로 개최되었습니다. 이 사용자 지정 환경에서는 MongoDB 데이터베이스용으로 수만 개의 가상화된 컨테이너를 유지 관리합니다. 클라우드 환경과 유사하게, 우리는 서로 다른 미국 클러스터의 컨테이너 간에 높은 수준의 물리적 격리를 유지하여 중단을 최소화하고 하나의 컨테이너가 데이터베이스 내의 다른 컨테이너에 영향을 미칠 수 있는 위험을 줄입니다.

4월 29일 정전 원인과 대응 방법

초기 부분 스위치 오류

4월 29일 09:15 UTC에 Rackspace 서버 캐비닛에 연결된 기본 Cisco Nexus 네트워크 스위치에 부분적인 오류가 발생했습니다. 장애 조치를 통해 보조 네트워크 스위치를 자동으로 활성화하지 않고 대신 오작동하는 스위치를 기본 스위치로 유지하는 방식으로 오작동하는 스위치가 실패했습니다.

네트워크 스위치는 "프레임"이라고 하는 네트워크 패킷을 대상으로 전달하여 트래픽을 라우팅합니다. 이를 효율적으로 수행하기 위해 이러한 스위치는 장치를 서로 연결하는 네트워크 토폴로지에 대한 이해를 유지합니다. 개별 구성 요소 오류 또는 속도 저하에 대응하여 네트워킹 경로가 동적으로 변경되는 것이 일반적입니다. 이러한 변경이 발생하면 스위치와 기타 네트워크 장치는 서로 통신하여 네트워크 토폴로지에 대한 정확한 이해를 유지합니다.

대규모 네트워크에서는 장치 사이에 둘 이상의 경로가 존재하는 경우가 많으며 이로 인해 라우팅 "루프"(즉, 패킷이 의도한 대상에서 중지되지 않고 대신 원래 위치로 루프백되는 조건)가 발생할 수 있습니다. 루프는 트래픽이 무한정 루핑되어 네트워크 링크를 포화시키고 중단을 일으키는 "브로드캐스트 폭풍"을 일으킬 수 있습니다. 이러한 일이 발생하지 않도록 스위치는 중복 링크를 식별하는 데 도움이 되는 메시지를 보내도록 프로그래밍되어 있습니다. 이러한 메시지를 스패닝 트리 브리지 프로토콜 데이터 단위(BPDU)라고 하며 STP(스패닝 트리 프로토콜)라는 네트워크 프로토콜의 일부입니다. 그런 다음 스위치는 트래픽을 라우팅할 때 루프가 발생하는 것을 방지하기 위해 이 정보를 사용하여 트래픽 포트를 차단합니다. 물리적 링크나 스위치에 장애가 발생하는 경우 STP는 트래픽이 전송될 수 있는 다른 물리적 링크를 식별하고 연결을 유지하기 위해 이전의 수동(예: 차단된) 링크를 활성 링크로 승격시키는 데 사용될 수 있으므로 중복성을 제공하는 데 도움이 됩니다.

4월 29일 사건이 시작되자 스위치가 오작동하기 시작하면서 토폴로지 변경 알림과 BPDU를 지속적으로 전달하기 시작했고, 이러한 변경 알림이 네트워크에 넘쳐났습니다. 이러한 패킷은 배포 스위치 및 기타 스위치로 전파되어 스패닝 트리 스위칭 루프를 발생시켜 완전한 네트워크 중단을 초래했습니다. STP는 루핑이 감지된 네트워크 포트를 차단하여 네트워크 루프를 줄이기 위해 마련되었지만, 4월 29일 사건 당시 오작동하는 스위치에서 잘못 전달된 스패닝 트리 트래픽으로 인해 네트워크의 다른 스위치가 스패닝 트리 토폴로지를 다시 분석하게 되었습니다. 그런 다음 다른 스위치가 오작동하는 스위치에서 우선 순위가 높은 BPDU 패킷이 들어오는 것을 감지했기 때문에 배포 스위치는 이전에 차단된 포트에서 전달을 시작했고 그 결과 네트워크에 과부하가 걸려 네트워크가 다운되는 스위칭 루프가 발생했습니다.

Rackspace 교정

이 활동의 ​​결과로 Rackspace 데이터 센터 엔지니어는 UTC 기준 약 9시 20분에 예상치 못한 네트워크 연결 문제에 대한 경고를 받고 문제를 해결하기 시작했습니다. UTC 09:39부터 10:03 사이에 Rackspace 데이터 센터 엔지니어는 네트워크 스위치를 일시 중단하고 기본 스위치의 전원을 껐다 켜고 서버 캐비닛의 NIC(네트워크 인터페이스 카드)를 강제로 보조 스위치로 장애 조치했습니다. NIC 장애 조치 후 Braze 환경의 물리적 서버에 대한 연결이 복원되었습니다.

Braze MongoDB 데이터베이스의 작동 방식

Braze에서 사용하는 MongoDB 데이터베이스를 사용하면 "샤드"라고 알려진 여러 데이터베이스 서버에 데이터를 저장할 수 있습니다. MongoDB는 Braze 플랫폼 서비스의 쿼리를 처리하고 샤딩된 클러스터에서 관련 데이터의 위치를 ​​확인한 다음 쿼리를 적절한 MongoDB 데이터베이스로 라우팅하는 "mongoS"라는 라우팅 서비스를 제공합니다. Braze에는 데이터베이스를 실행하고 특정 MongoDB 샤드에 대한 데이터를 저장하는 프로그램인 15,000개 이상의 "mongoD" 프로세스로 구성된 수백 개의 개별 MongoDB 데이터베이스가 있습니다.

각 데이터베이스 샤드는 하나의 기본 mongoD와 두 ​​개 이상의 보조 mongoD 프로세스로 구성되어 오류 발생 시 고가용성을 제공합니다. 각 mongoS 서버는 쿼리를 라우팅할 수 있는 모든 mongoD에 대한 네트워크 연결을 유지합니다. 이러한 mongoD 프로세스는 해당 구성의 기본 및 보조에도 연결됩니다. 이것을 복제 세트라고 합니다. mongoS가 특정 mongoD에 연결할 수 없는 경우 해당 프로세스를 오프라인으로 표시하고 재시도를 예약합니다. 마찬가지로, mongoD가 1초 내에 복제본 세트의 다른 mongoD 구성원에 연결할 수 없으면 시간 초과되고 해당 프로세스를 오프라인으로 표시하고 재시도를 예약합니다.

MongoDB 프로세스에 대한 네트워크 루프의 영향과 대응 방법

네트워크 루프 중에 MongoDB 프로세스가 정상적으로 연결되지 않았기 때문에 각 프로세스는 관련된 모든 프로세스를 오프라인으로 표시했습니다. 즉, 각 mongoS 프로세스는 연결된 모든 mongoD 프로세스를 오프라인으로 표시하고 각 mongoD 프로세스는 관련 복제본 세트 구성원을 오프라인으로 표시했습니다. 그러나 Rackspace에 의해 물리적 서버에 대한 네트워크 연결이 복원된 후에도 mongoS 또는 mongoD 프로세스는 오프라인으로 표시된 다른 프로세스에 대한 모든 연결을 다시 설정하지 않았습니다.

이 시점에서 Rackspace 데이터베이스 관리자(DBA) 팀의 수정 노력을 지원하기 위해 Braze DevOps 팀은 해당 연결을 복원하는 방법을 신속하게 디버깅하고 테스트하기 시작했습니다. 우리 조사에 따르면 사용 가능한 유일한 옵션은 가상화된 컨테이너에서 거의 16,000개의 mongoD 및 6,000개 이상의 mongoS 프로세스를 모두 다시 시작하는 것이었습니다. 이 사업의 엄청난 규모와 많은 컨테이너를 신속하게 다시 시작할 수 있는 자동화가 존재하지 않는다는 사실을 고려하여 Rackspace 엔지니어는 사고 중에 즉각적인 자동화 기능을 만들기 위해 새로운 코드를 작성했습니다.

불행하게도 재시작 프로세스가 가속화되면서 DNS(Domain Name System) 시스템에서 또 다른 문제가 발생했습니다. mongoS 및 mongoD 프로세스가 온라인 상태가 되면 DNS 조회라는 프로세스를 통해 DNS 확인자에게 정보를 요청합니다. 재시작 속도에 따른 지속적인 DNS 조회로 인해 DNS 서버에 과부하가 걸리고 mongoD 프로세스에 다시 연결할 때 mongoS 계층에서 연결 시간 초과가 발생했습니다. 이렇게 증가하는 로드를 수용하기 위해 Rackspace 팀은 DNS CPU 용량을 늘렸지만 각 mongoS에서 관련 mongoD 프로세스로의 정상적인 연결을 생성하기 위해 mongoS 계층을 두 번째로 다시 시작해야 했습니다.

UTC 17:05 경에 재시작 프로세스를 통해 일부 클러스터가 다시 온라인 상태로 돌아오기 시작했습니다. 데이터베이스 성능이 회복되고 클러스터가 안정화됨에 따라 Braze는 데이터 처리 및 메시징 전송 용량을 계속해서 늘렸습니다. 그러나 이러한 노력은 사전에 사용할 수 없게 되어 발생하는 막대한 백로그로 인해 복잡해졌습니다.

수백 개의 서로 다른 데이터베이스로 구성된 Rackspace 데이터베이스 환경의 규모와 정교함, 중단 기간, 그에 따른 백로그의 양(수십억 개의 메시지와 수십억 개의 수집된 데이터 포인트를 나타냄)을 고려할 때 필요한 복구 프로세스는 다음과 같습니다. -정상적인 복구 프로세스의 순간적 적응. 이는 대량의 전체 처리 용량 도입을 포함하여 데이터베이스 리소스가 지속적인 처리 요구와 균형을 유지하도록 하기 위해 필요했습니다.

그러나 그 과정에서 Braze는 우리가 프로비저닝할 수 있는 가상 CPU 수에 대한 AWS 제한에 도달하여 추가 서버 용량을 추가할 수 없게 되었습니다. Braze 팀은 AWS 팀과 함께 이러한 상황을 신속하게 확대하고 증가분을 받아 엔지니어들이 서버 처리 용량을 기록적인 수준으로 확장할 수 있었습니다. 이는 Black에서 도달했던 이전 최대 용량보다 50% 이상 더 높은 수치입니다. 2023년 금요일.

UTC 20시 30분까지 US 01, US 03 및 US 08을 제외한 모든 미국 클러스터는 백로그 처리를 완료했으며 나머지 클러스터는 사고 전날의 최고 속도 이상으로 처리하고 있었습니다. 몇 시간 내에 모든 클러스터가 실시간 처리로 백업되었고 우리는 사건이 해결되었음을 선언했습니다.

Braze가 사고 발생 시 업데이트를 전달하는 방법

이와 같은 사고 발생 시 명확하고 빈번한 의사소통은 필수적입니다. 일반적으로 기술적 문제는 드물게 발생하고 이 정도 규모의 문제는 이전에 Braze에서 들어본 적이 없지만, 우리는 항상 명확하고 신속하게 영향을 받는 당사자와 소통하기 위해 최선을 다합니다.

이와 같은 상황에서 우리의 커뮤니케이션 전략을 결정하는 기본 원칙은 정직성, 투명성, 신뢰입니다. 우리는 현재 일어나고 있는 일에 대해 정직하고 솔직하게 말할 수 있는 기회는 단 한 번 뿐이라는 것을 알고 있으며, 사건에 대한 투명성(현재와 해결 이후 모두)이 신뢰를 유지하는 데 필수적이라는 것을 알고 있습니다. 결국, 우리는 Braze가 사건의 재발을 설명하고, 해결하고, 예방하기 위해 항상 최선을 다할 것이라는 점을 고객이 확신할 수 있기를 바랍니다.

사고가 발생하는 동안 당사는 상태 페이지를 사용하여 커뮤니케이션을 관리하고 상황에 대한 정기적인 업데이트를 제공합니다. 최신 정보를 얻으려면 고객이 해당 페이지에서 업데이트에 등록할 것을 강력히 권장합니다. 4월 29일의 중단 기간 동안 우리는 동료 공동 창립자이자 CEO인 Bill Magnuson이 보낸 이메일을 통해 이러한 빈번한 상태 페이지 업데이트를 보완했습니다. 해당 메시지는 모든 Braze 대시보드 사용자에게 전송되었으며 필요에 따라 다른 고객 이해관계자와 공유할 수 있도록 계정 팀에 제공되었습니다.

Braze가 사건을 추적한 방법과 향후 예방 계획

이 사건 이전에 우리는 중복된 네트워크 스위치로 인해 네트워크가 탄력적이라고 ​​믿게 되었습니다. 그러나 이번 중단으로 인해 10년 넘게 우리를 잘 지원해 왔던 네트워크 토폴로지가 치명적인 오류에 취약하다는 사실이 드러났습니다. 이제 이를 더욱 강화해야 한다는 점은 분명해졌습니다.

사건 이후 Braze와 Rackspace는 결함이 있는 스위치를 교체하고 교체했으며 Rackspace 엔지니어링 팀은 Braze 서비스가 의존하는 네트워킹 인프라에 대한 전체 감사를 완료했습니다. 하드웨어 오류는 특히 보증 기간 내 장비의 경우 예측하기가 매우 어렵지만, 이상을 감지하고 신속한 대응을 보장하기 위한 모니터링이 마련되어 있습니다. 두 팀은 장비가 오작동하는 경우에도 향후 네트워크 루프를 방지할 수 있는 변경 작업을 수행하기 위해 현재 협력하고 있습니다. 루프에 대한 보호를 더욱 향상시키기 위해 네트워크 토폴로지를 의미 있게 변경할 계획이므로 일부 네트워킹 변경 사항을 구현하는 데 시간이 걸릴 것입니다. 또한 우리는 경험한 오류 시나리오를 더 잘 이해하고 네트워크 오류 발생 시 mongoD 및 mongoS 프로세스의 자가 복구 기능을 향상시키기 위해 Cisco와 MongoDB 모두에 지원 티켓을 공개했습니다.

우리는 사건 이후 단기적인 변화에 대한 조치를 취하고 대규모 네트워크 개선을 수행하기 위해 Rackspace와 매일 접촉해 왔으며, 개선되고 탄력적인 네트워크 설계가 달성되었다는 확신을 가질 때까지 계속 그렇게 할 것입니다.

이번 사건과 귀하의 비즈니스 및 고객과의 관계에 끼친 영향에 대해 다시 한 번 사과드리고 싶습니다. Braze를 사용할 수 없는 시간은 허용되지 않습니다. 당사의 엔지니어링 리더십과 경영진은 가동 중단 취약성을 최대한 빠르고 효율적으로 식별하고 해결하는 데 필요한 모든 변경 작업을 수행하여 신뢰할 수 있고 성과가 뛰어난 파트너로서 다시 한 번 귀하의 신뢰를 얻을 수 있도록 최선을 다하고 있습니다.

— 존