Alibaba Cloud와 Tencent Cloud 모두 구성 요소 오류로 인해 모든 가용 영역이 동시에 마비되는 상황을 경험했습니다. 이 글에서는 아키텍처 설계 관점에서 장애 영역을 줄이고 장애 발생 시 비즈니스 손실을 최소화하는 방법을 살펴보고, Sealos의 안정성 사례를 예로 들어 경험과 교훈을 공유할 것입니다.
마스터-슬레이브를 버리고 P2P 아키텍처를 채택합니다.
Tencent Cloud 오류 보고서에서 동시에 여러 가용 영역의 오류가 기본적으로 통합 API, 통합 인증 및 기타 시스템 오류와 같은 일부 중앙 집중식 구성 요소로 인해 발생한다는 것을 알 수 있습니다.
따라서 X 시스템이 실패하면 오류 도메인이 매우 커집니다.
대조적으로, 분산형 P2P 아키텍처는 이러한 위험을 잘 피할 수 있습니다. 비트코인 네트워크를 예로 들면, 중앙 노드가 없기 때문에 기존 마스터-슬레이브 클러스터보다 안정성이 훨씬 높으며 끊기가 거의 어렵습니다.
따라서 Sealos는 다중 가용 영역을 설계할 때 Alibaba Cloud 및 Tencent Cloud의 교훈을 완전히 흡수하고 소유자 없는 아키텍처를 채택했습니다. 주요 문제는 사용자 계정과 같은 데이터가 여러 가용 영역에 저장되는 방식입니다. 문제. 다음과 같은 구조가 되었습니다.
각 가용 영역은 완전히 자율적이며 지역 간 분산 데이터베이스(CockroachDB 사용)를 통해 주요 공유 데이터(예: 사용자 계정 정보)만 동기화합니다. 각 가용 영역은 분산 데이터베이스 CockroachDB의 로컬 노드에 연결됩니다.
이렇게 하면 단일 가용 영역의 장애가 다른 지역의 비즈니스 연속성에 영향을 미치지 않습니다. 분산 데이터베이스 클러스터에 전반적인 문제가 발생한 경우에만 모든 가용 영역의 제어 평면을 사용할 수 없게 됩니다. 다행스럽게도 CockroachDB 자체는 내결함성, 재해 복구, 네트워크 파티션 대응 성능이 뛰어나 이러한 상황이 발생할 가능성이 크게 줄어듭니다. 이런 식으로 전체 아키텍처는 간단하며 데이터베이스의 안정성 향상, 모니터링 및 파괴 테스트에만 집중할 수 있습니다.
또 다른 이점은 그레이스케일 릴리스 및 차별화된 작업에 대한 편의성을 제공한다는 것입니다. 예를 들어, 일부 지역에서는 적은 트래픽으로 새로운 기능을 먼저 검증한 후 안정화 후 본격 출시할 수 있으며, 각 지역에서는 완전히 일관되지 않고도 고객 그룹의 특성에 따라 맞춤형 서비스를 제공할 수 있습니다.
절대적으로 안정적인 시스템은 없습니다.
모두가 클라우드의 안정성에 대해 많은 불만을 토로하지만, 모든 클라우드 공급업체는 예외 없이 많은 실패를 경험했습니다. 여기서 가장 중요한 것은 기술적인 문제일 뿐만 아니라 조직적인 문제이기도 합니다. 경영 문제도 비용 문제입니다. 창업 과정에서 겪은 구체적인 사례를 바탕으로 여러분과 공유하겠습니다.
실패로부터 배운 씰로스의 교훈
2023년 3월 17일 Laf의 주요 실패
이것은 우리가 사업을 시작하면서 마주한 첫 번째 큰 실패였습니다. 제품이 출시된 지 불과 이틀 만에 우리가 뺨을 맞았던 이유는 바로 회사의 1주년 축하 행사였기 때문입니다. , 그리고 우리는 케이크를자를 시간조차 없었습니다. 밤 3 시까 지 지속되었습니다.
실패의 최종 원인은 매우 이상했습니다. 경량 서버에서 컨테이너의 네트워크 가상화로 인해 결국 전체 클러스터를 일반 VPC 서버로 마이그레이션하여 문제가 발생했습니다. 안정적이었습니다. 섹스와 비용은 분리될 수 없습니다.
따라서 많은 사람들은 퍼블릭 클라우드가 비용이 많이 든다고 생각하는데, 나머지 10%의 문제를 해결하는 데에는 많은 비용이 듭니다.
Laf는 여러 테넌트가 MongoDB 라이브러리를 공유 하는 모델을 사용했기 때문에 일련의 데이터베이스 관련 안정성 문제에 직면했습니다 . 최종 결론은 이 방법이 작동하지 않을 것이며 데이터베이스 격리를 해결하기 어렵다는 것입니다. 문제가 발생하여 이제는 모두 독립된 데이터베이스 방식을 채택하여 마침내 문제가 해결되었습니다.
게이트웨이의 안정성 문제도 있습니다. 처음에는 신뢰할 수 없는 Ingress 컨트롤러를 선택했는데 , 이로 인해 특정 컨트롤러의 이름을 밝히지 않겠습니다. 마지막으로 이를 Higress로 교체하여 현재는 문제를 완전히 해결했습니다. 리소스를 덜 차지하고 더 안정적입니다. 또한 Alibaba Higress 팀의 개인적인 지원에 매우 감사드립니다. 또한 우리가 노출한 문제는 Higress가 더욱 성숙해지고 윈윈(win-win)되는 데 도움이 되었습니다.
2023년 6월 Sealos 퍼블릭 클라우드가 공식적으로 출시되었습니다. 우리가 직면한 가장 큰 문제 중 하나는 보호 기능을 추가하면 이를 해결할 수 있지만 비용이 급증한다는 의미이기도 합니다. 둘은 매우 혼란스럽습니다. 안정성을 막지 않으면 해결하기 어렵습니다. 이를 막으면 판매하여 비용을 회수할 수 없습니다. 나중에 게이트웨이를 교체한 후 Envoy가 정말 강력 하고 실제로 공격 트래픽에 저항할 수 있다는 것을 알게 되었습니다. 그 전에는 원스톱인 Nginx를 사용했습니다. 게다가 K8s의 가장 큰 장점은 강력한 자가 치유 능력입니다. 게이트웨이가 다운되더라도 동시에 다운되지 않는 한 5분 이내에 자가 치유가 가능합니다.
안정성 융합을 위한 모범 사례
문제 해결 프로세스
시스템 안정성을 지속적으로 개선하기 위해 Sealos는 내부적으로 엄격한 오류 관리 프로세스를 확립했습니다.
장애가 발생할 때마다 자세히 기록하고 지속적으로 후속 조치를 취해야 합니다. 많은 기업이 실패 검토 프로세스를 종료하지만 실제로 검토는 유사한 실패가 다시 발생하지 않도록 실질적인 시정 조치를 수립하고 실행하는 것이 핵심입니다. 오류 처리가 완료된 후에도 문제가 더 이상 발생하지 않는다는 것이 확인될 때까지 일정 기간 동안 계속 관찰해야 합니다.
경영목표 측면에서는 2024년 1분기 OKR에서 안정성과 융합이라는 목표를 당초 다음과 같이 정의했습니다.
나중에 이런 일반적인 슬로건 스타일의 OKR이 신뢰성이 없고, 안정성의 수렴이 좀 더 구체적이어야 한다는 것을 알게 됐습니다. 이번 KR의 결과는 우리가 그것을 달성하지 못했고, 거의 효과가 없었다는 것이었습니다. 수렴 과정에서 분기마다 몇 가지 핵심 사항에 집중하고 몇 분기 동안 계속 반복하면 수렴이 매우 좋아질 필요는 없습니다.
그래서 2분기에는 더욱 구체적인 목표를 설정했습니다.
안정성 설정은 단지 지표 설정에만 국한될 수도 없고, 너무 일반적일 수도 없습니다. 구체적이고 가시적인 조치와 구체적인 측정 방법이 필요합니다.
예를 들어 99.9%가 설정되어 있다면 어떻게 달성할 수 있나요? 그렇다면 현재 가용성은 얼마나 됩니까? 당면한 핵심 문제는 무엇입니까? 측정하는 방법? 무엇을 해야 합니까? 누가 할 것인가? 설정은 사용 가능한 시간에 국한되지 않고 장애 수준, 장애 수, 장애 지속 시간, 대규모 고객 장애 관찰 등 세부적으로 나열되어야 합니다.
데이터베이스 안정성, 게이트웨이 안정성, 대규모 고객 서비스 가용성 지표, CPU/메모리 리소스 과부하 오류와 같은 특수 범주를 분리하고 우선 순위를 나열해야 합니다.
또한 Auto Chess, FastGPT 상용 고객, Chongchunxue Studio 등과 같은 대규모 고객을 모니터링하는 데 중점을 두어야 합니다(월간 코어 사용량이 30개 이상, 대표적인 코어 5개 선택).
안정성 문제는 너무 많습니다. 이러한 대규모 고객에게 서비스가 제대로 제공되면 소규모 고객도 기본적으로 다룰 수 있습니다. 너무 많은 것을 추구하지 말고 현재 핵심 안정성 문제를 해결하는 데 집중한 다음 완전한 추적 프로세스를 구축하십시오.
오작동을 일으키는 학생은 처벌을 받거나 보너스가 차감되거나 퇴학될 수도 있습니다. 저희는 스타트업 회사로서 처벌적 조치를 취하지 않는 경우가 많습니다. 당사자들이 오작동을 일으키고 싶지 않고, 모두가 문제를 해결하기 위해 정말 열심히 노력하고 있기 때문입니다. 실제로 싸울 수 있는 사람은 피해를 입은 사람들입니다. 분기별 실패 빈도가 감소하면 적절한 인센티브를 제공하는 등 긍정적인 인센티브를 선호합니다 .
단순한 건축 디자인
시스템 아키텍처는 설계 초기부터 안정성과 관련되어 있어, 아키텍처가 복잡할수록 문제가 생기기 쉬우므로 이에 대해 관심을 두지 않는 기업이 많습니다. 디자인이 너무 복잡해서 제가 이해하기에는 뭔가 잘못된 것 같아요. Sealos 다중 가용성 영역이 아주 좋은 예입니다. 복잡한 것을 간단한 CRUD로 바꾸려면 데이터베이스 안정성만 향상하면 됩니다. 데이터베이스 테이블 구조 설계가 간단하고 많은 안정성 문제가 해결되었습니다.
우리의 미터링 시스템도 마찬가지인데, 원래는 12개 이상의 CRD를 갖도록 설계했지만, 반년 넘게 애를 먹은 끝에 안정성이 안정되지 않아 결국 시스템을 다시 설계하고 선택하게 되었습니다. 개발하는데 2주가 걸렸고, 한 달 만에 안정적으로 온라인에 올라왔습니다.
따라서 단순한 디자인은 안정성에 매우 중요합니다!
중간 정도의 모니터링, 표적화
감시는 양날의 검이므로 너무 많아도 충분하지 않습니다. 많은 Sealos 장애는 모니터링으로 인해 발생했습니다. Prometheus는 너무 많은 리소스를 점유하고 API 서버가 압도되어 새로운 안정성 문제가 발생했습니다. 교훈을 얻은 후 우리는 VictoriaMetrics와 같은 보다 가벼운 모니터링 솔루션으로 전환하면서 모니터링 지표 수를 엄격하게 제어했습니다. Uptime Kuma와 같은 도구는 여러 지역에서 서로를 테스트하고 제때에 문제를 찾아낼 수 있어 매우 유용합니다.
통화 중도 마찬가지입니다. 매일 수천 개의 알람이 발생합니다. 그래서 여기서는 기본적으로 0부터 시작하여 천천히 추가합니다. 예를 들어, 먼저 "대규모 고객 비즈니스의 최종 안정성" 관점에서 수행합니다. , 전화가 계속 울릴 것입니다. 그런 다음 호스트가 준비되지 않은 것과 같은 항목을 천천히 추가하세요. 이론적으로 호스트는 아직 준비가 되어 있지 않으며 비즈니스에 영향을 주어서는 안 됩니다. 시스템이 점차 성숙해짐에 따라 결국 대기 상태가 아닌 호스트를 준비되지 않은 상태로 만드는 것이 가능해집니다.
잘못을 보고할 때 당황하지 마세요.
Tencent Cloud의 리뷰 보고서는 매우 훌륭했습니다. 실패 이유를 솔직하게 설명하고, 무엇이 부족한지 객관적으로 분석했으며, 적극적으로 시정하겠다고 약속했습니다. 이러한 솔직하고 책임감 있는 태도는 실제로 사용자의 신뢰를 얻기 더 쉽게 만듭니다. 반면, 여론이 발효될까봐 문제를 비밀로 하는 것은 갈증을 해소하기 위해 독약을 마시는 것과 다름없으며, 오히려 불투명한 블랙박스라는 느낌을 갖게 하고, 앞으로 무슨 일이 일어날지 알 수 없게 만든다 . 귀하의 제품을 진심으로 사랑하고 귀하와 함께 성장할 의지가 있는 고객은 원칙에 어긋나는 실수도 용인할 수 있습니다. 핵심은 실질적인 개선을 위한 성실성과 행동을 보여주는 것입니다.
요약하다
Sealos 퍼블릭 클라우드 서비스는 출시된 지 1년이 넘었으며 누적 등록 사용자 수 는 100,000명이 넘었습니다 . 뛰어난 기능과 경험, 경제성으로 인해 많은 개발자들이 선호하고 있으며 일부 대규모 고객들도 Sealos 클라우드로 비즈니스를 마이그레이션하기 시작했습니다. 그 중에는 대규모 인터넷 제품도 있습니다. 예를 들어 '해피 오토 체스(Happy Auto Chess)' 게임의 활성 사용자 수는 400만 명이 넘 습니다 .
앞으로도 체계적인 장애 관리를 통해 단순하고 효율적인 아키텍처 설계, 꾸준하고 지속적인 모니터링 전략, 그리고 개방적이고 정직한 커뮤니케이션 태도로 보완된 클라우드인 Sealos를 통해 안정성을 지속적으로 수렴할 것이라고 믿습니다. 국내 소규모 오픈소스 기업이 육성하고 개발한 클라우드는 분명 매우 발전된 클라우드가 될 것입니다!
Linus는 커널 개발자가 탭을 공백으로 대체하는 것을 막기 위해 문제를 직접 해결했습니다. 그의 아버지는 코드를 작성할 수 있는 몇 안 되는 리더 중 한 명이고, 둘째 아들은 오픈 소스 기술 부서의 책임자이며, 막내 아들은 핵심입니다. Huawei: 일반적으로 사용되는 모바일 애플리케이션 5,000개를 변환하는 데 1년이 걸렸습니다. Hongmeng으로의 포괄적인 마이그레이션 Java는 타사 취약점에 가장 취약한 언어입니다. Hongmeng의 아버지인 Wang Chenglu: 오픈 소스 Hongmeng은 유일한 아키텍처 혁신입니다. 중국 기초 소프트웨어 분야의 마화텅(Ma Huateng)과 저우홍이(Zhou Hongyi)가 악수를 하며 "원한을 풀다" 전 마이크로소프트 개발자: 윈도우 11 성능은 "터무니없을 정도로 나쁘다" 라오샹지가 오픈소스인 것은 코드는 아니지만 그 이유는 다음과 같다. Google이 대규모 구조 조정을 발표 했습니다 .