카오스 엔지니어링

19장. 데이터베이스의 카오스 엔지니어링

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

리우 탕과 하오 웡

카오스 엔지니어링이 필요한 이유는 무엇인가요?

2011년 넷플릭스가 카오스 몽키를 오픈소스화한 이후, 이 프로그램은 점점 더 인기를 얻고 있습니다. 분산 시스템을 구축하려는 경우 클러스터에서 Chaos Monkey를 약간 미치게 하면 보다 내결함성 있고 견고하며 안정적인 시스템을 구축하는 데 도움이 될 수 있습니다.¹

TiDB는 오픈 소스, 분산형, 하이브리드 트랜잭션/분석 처리(HTAP)² 에서 주로 개발한 데이터베이스입니다. 여기에는 모든 데이터베이스 사용자에게 가장 중요한 자산이라고 생각되는 데이터 자체가 저장됩니다. 저희 시스템의 기본적이고 가장 중요한 요구사항 중 하나는 내결함성입니다. 기존에는 단위 테스트와 통합 테스트를 실행하여 시스템이 프로덕션 준비가 완료되었는지 확인했지만, 클러스터의 규모와 복잡성, 데이터 볼륨이 PB 단위로 증가함에 따라 이러한 테스트는 빙산의 일각에 불과합니다. 카오스 엔지니어링은 우리에게 매우 적합합니다. 이 장( )에서는 저희의 사례와 TiDB와 같은 분산 시스템에 카오스 엔지니어링이 필요한 구체적인 이유에 대해 자세히 설명합니다.

견고성 및 안정성

서로 통신하는 여러 노드에 데이터가 저장되는 TiDB와 같이 새로 출시된 분산 데이터베이스에 대한 사용자의 신뢰를 구축하려면 데이터 손실이나 손상을 언제든지 방지할 수 있어야 합니다. 하지만 현실에서는 언제 어디서나 예상치 못한 방식으로 장애가 발생할 수 있습니다. 그렇다면 어떻게 하면 장애로부터 살아남을 수 있을까요? 한 가지 일반적인 방법은 시스템을 내결함성으로 만드는 것입니다. 한 서비스가 다운되면 온라인 서비스에 영향을 주지 않고 다른 폴오버 서비스가 즉시 그 역할을 대신할 수 있습니다. 실제로 내결함성은 분산 시스템의 복잡성을 증가시킨다는 점에 유의해야 합니다.

어떻게 하면 내결함성을 견고하게 유지할 수 있을까요? 장애 허용 오차를 테스트하는 일반적인 방법으로는 단위 테스트와 통합 테스트를 작성하는 것이 있습니다. 내부 테스트 생성 도구의 도움으로 2천만 개 이상의 단위 테스트 사례를 개발했습니다. 또한 MySQL 테스트 케이스와 ORM 프레임워크 테스트 케이스와 같은 수많은 오픈 소스 테스트 케이스도 활용했습니다. 그러나 단위 커버리지가 100%라고 해서 내결함성 시스템이 되는 것은 아닙니다. 마찬가지로 잘 설계된 통합 테스트를 통과한 시스템이 실제 프로덕션 환경에서도 충분히 잘 작동한다는 보장은 없습니다. 실제 환경에서는 디스크 장애나 NTP(네트워크 시간 프로토콜)가 동기화되지 않는 등 어떤 일이든 발생할 수 있습니다. TiDB와 같은 분산 데이터베이스 시스템을 더욱 견고하게 만들려면 예측할 수 없는 장애를 시뮬레이션하고 이러한 장애에 대한 대응을 테스트할 수 있는 방법이 필요합니다.

실제 사례

TiDB에서는 Raft 합의 알고리즘을 ...