높은 동시성 시스템-고 가용성

기사 출처 : Alibaba의 10 억 수준 동시 시스템 설계 (2021 버전)

링크 : https://pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA 추출 코드 : 8888

과정이 시작된 후 일부 학생들은 과정에 이론적 지식에 대한 설명이 더 많이 있다고보고했으며 예제를보기를 희망합니다. 이 목소리에 귀를 기울이고 제안 해주셔서 감사 드리며 04 년 초에 답변을 드리고자합니다.

강의를 디자인 할 때 기본 장의 처음 5 개 강의를 주로 사용하여 높은 동시성 시스템 디자인에 대한 몇 가지 기본 개념을 소개하고 싶습니다. 전반적인 프레임 워크를 구축하여 편리하게 사용할 수 있도록 도와 드리고자합니다. 후속 진화 장과 실제 전투 장. 관련된 지식 포인트를 하나씩 확장하고 확장합니다. 예를 들어 이번 강의에서는 다운 그레이드에 대해 언급 한 다음, 운영 및 유지 보수 장에서 다운 그레이드 유형과 적용 가능한 시나리오를 사례 형식으로 자세히 소개하겠습니다.이 디자인의 이유는 다음을 통해 과정이 서로 연결되기를 바랍니다. 이전 섹션의 작은 공간입니다. 점을 표면으로 가져가 점차 확장합니다. 물론 다양한 목소리가 코스의 내용을 지속적으로 최적화하려는 동기가되며, 모든 제안을 진지하게 받아들이고, 지속적으로 코스를 최적화하고, 열심히 노력하고 함께 진행할 것입니다.

다음으로, 공식적으로 코스에 들어 갑시다. 이 레슨에서는 높은 동시성 시스템 설계-고 가용성의 두 번째 목표를 이해하도록 계속 안내하겠습니다. 이 강의에서 시스템의 유용성을 향상시키기위한 아이디어와 방법에 대한 직관적 인 이해가 필요하므로 이러한 내용을 후속 단계의 요점까지 설명 할 때 즉시 대응할 수 있으며 참조 할 수도 있습니다. 시스템에 사용성 문제가 발생할 때 이러한 방법이 최적화됩니다.

고 가용성 (HA)

고 가용성 (HA)은 시스템을 설계 할 때 자주 듣게되는 용어로 시스템이 장애없이 작동 할 수있는 능력을 나타냅니다 .

많은 오픈 소스 구성 요소 문서에서 볼 수있는 HA 솔루션은 구성 요소 가용성을 개선하고 시스템이 다운 타임 및 서비스 불가능한 것을 방지하는 솔루션입니다. 예를 들어, Hadoop 1.0의 NameNode가 단일 지점이라는 것을 알고 있습니다. 일단 장애가 발생하면 전체 클러스터를 사용할 수 없게됩니다. Hadoop 2에서 제안한 NameNode HA 솔루션은 동시에 두 개의 NameNode를 시작하는 것입니다. 상태 및 다른 하나는 Standby State에있는 두 개의 공유 스토리지입니다. Active NameNode가 실패하면 Standby NameNode를 Active 상태로 전환하여 서비스를 계속 제공 할 수 있습니다. 이렇게하면 Hadoop이 실패없이 계속 실행될 수있는 능력이 향상됩니다. 그 가용성.

일반적으로 동시성이 높고 트래픽이 큰 시스템의 경우 시스템 장애는 낮은 시스템 성능보다 사용자 경험을 더 손상시킵니다. 매일 100 만 명 이상의 활성 사용자가있는 시스템에서 1 분 오류가 수천 명의 사용자에게 영향을 미칠 수 있다고 상상해보십시오. 그리고 시스템의 일일 활동이 증가함에 따라 1 분 장애 시간의 영향을받는 사용자 수도 증가하고 시스템의 가용성 요구 사항이 높아집니다.

그래서 오늘은 시스템 설계에 대한 몇 가지 아이디어를 제공하기 위해 높은 동시성에서 시스템의 고 가용성을 보장 할 수있는 방법을 이해하도록 안내하겠습니다.

사용성 측정

사용성은 추상적 인 개념이며 측정 방법을 알아야합니다. 관련 개념은 MTBF 및 MTTR 입니다.

: MTBF (고장 간 평균 시간) 두 고장 사이의 시간 나타내는 고장 간격 수단을 평균 시간 이며, 시스템이 정상적으로 작동하는 평균 시간. 이 시간이 길수록 시스템 안정성이 높아집니다 .

MTTR (평균 수리 시간) : 고장의 평균 복구 시간을 의미하며 평균 고장 시간으로도 이해할 수 있습니다. 값이 작을수록 오류가 사용자에게 미치는 영향이 작아집니다 .

가용성은 MTBF 및 MTTR의 값과 밀접한 관련이 있습니다. 다음 공식을 사용하여 이들 간의 관계를 표현할 수 있습니다. 가용성 = MTBF / (MTBF + MTTR)이 공식으로 계산 된 결과는 비율이며이 비율은 다음을 나타냅니다. 시스템의 가용성. 일반적으로 우리는 시스템의 가용성을 설명하기 위해 몇 개의 9를 사용할 것입니다.

사실이 그림을 보면 1 개의 나인과 2 개의 나인은 매우 쉽게 얻을 수 있으며 란샹 기술 학교에서 지게차가없는 한 기본적으로 사람의 조작과 유지 보수를 통해 달성 할 수 있습니다.

9 초 후 시스템의 연간 고장 시간이 3 일에서 8 시간으로 급격히 감소했습니다. Four nines 이후 연간 고장 시간이 1 시간 미만으로 단축되었습니다. 이 수준의 가용성을 사용하면 완전한 운영 및 유지 관리 의무 시스템, 문제 해결 절차 및 비즈니스 변경 절차를 설정해야 할 수 있습니다. 시스템 설계시 더 많은 고려가 필요할 수도 있습니다. 예를 들어, 개발 중에 장애가 발생하면 수동 개입없이 자동으로 복구 할 수 있는지 여부를 고려해야합니다. 물론 도구 구성 측면에서도 장애 원인을 신속하게 해결하고 시스템을 신속하게 복원하기 위해서는 더 많은 개선이 필요합니다.

99.999 %에 도달 한 후에는 인력으로 결함을 복구 할 수 없습니다. 오류 발생부터 알람을받을 때까지, 컴퓨터를 켜고 서버에 로그인하여 문제를 처리 할 때까지 10 분 정도 걸릴 수 있다고 상상해보십시오. 따라서이 수준의 가용성은 시스템의 재해 허용 및 자동 복구 기능을 검사하며, 시스템이 장애를 처리하도록 허용해야만 가용성 표시기가 더 높은 수준으로 올라갑니다 .

일반적으로 핵심 비즈니스 시스템의 가용성은 99.999 %에 도달해야하며 비 핵심 시스템의 가용성은 최대 3 개의 99까지 허용됩니다. 실제 작업에서 비슷한 말을 들었을 수도 있지만 수준과 비즈니스 시나리오가 다른 시스템에는 가용성 요구 사항이 다릅니다.

현재 가용성 평가 지표에 대해 어느 정도 이해하고 있습니다. 다음으로 고 가용성 시스템을 설계 할 때 고려해야 할 요소가 무엇인지 살펴 보겠습니다.

고 가용성 시스템 설계를위한 아이디어

성숙한 시스템의 가용성은 시스템 설계와 시스템 운영 및 유지 보수 라는 두 가지 측면에서 보장되어야합니다.이 두 가지 모두 함께 작동하며 필수 불가결합니다. 그렇다면 시스템 고 가용성 문제를 해결하기 위해이 두 가지 측면에서 시작하는 방법은 무엇입니까?

1. 시스템 설계

고 가용성 시스템을 설계 할 때 "실패를위한 설계" 는 우리의 첫 번째 원칙입니다. 백만 QPS를 수행하는 높은 동시성 시스템에서 클러스터의 머신 수는 수백 또는 수천이며 단일 머신의 실패는 정상이며 실패는 거의 매일 발생할 수 있습니다. 천 마일을 획득하기 위해 미리 계획하십시오. 시스템을 설계 할 때 장애 발생을 중요한 고려 사항으로 고려해야하며 , 장애가 발생한 후 자동으로 장애를 찾는 방법과 해결 방법을 미리 고려해야 합니다 . 물론 미리 생각하는 것 외에도 장애 조치 (장애 조치), 시간 초과 제어, 다운 그레이드 및 전류 제한과 같은 특정 최적화 방법을 마스터해야합니다 .

일반적으로 장애 조치되는 노드에는 두 가지 상황이있을 수 있습니다.

완전한 피어 노드 간의 장애 조치입니다.
동일하지 않은 노드 사이에 있습니다. 즉, 시스템에 기본 노드와 대기 노드가 있습니다.

피어 노드 간의 장애 조치는 비교적 간단합니다. 이 유형의 시스템에서 모든 노드는 읽기 및 쓰기 트래픽을 담당하며 노드에 상태가 저장되지 않으며 각 노드는 다른 노드의 미러 이미지가 될 수 있습니다. 이 경우 특정 노드에 대한 액세스가 실패하면 무작위로 다른 노드를 방문합니다 . 예를 들어 Nginx는 다음과 같이 500보다 큰 Tomcat 요청이 표시 될 때 다른 Tomcat 노드를 다시 요청하도록 구성 할 수 있습니다.

비 피어 노드에 대한 장애 조치 메커니즘은 훨씬 더 복잡합니다. 예를 들어, 기본 노드와 여러 개의 대기 노드가 있습니다. 이러한 대기 노드는 핫 스탠바이 (온라인 서비스도 제공하는 스탠바이 노드) 또는 콜드 스탠바이 (백업으로 만 사용됨) 일 수 있으며 제어 방법을 코드에 포함해야합니다. 메인 머신과 스탠바이 머신에 결함이 있는지 감지하고 메인 머신과 스탠바이 머신을 전환하는 방법. 가장 널리 사용되는 오류 감지 메커니즘은 "하트 비트"입니다 . 주기적으로 하트 비트 패킷을 클라이언트의 마스터 노드로 보내거나 백업 노드에서 주기적으로 하트 비트 패킷을 보낼 수 있습니다. 하트 비트 패킷이 일정 시간 동안 수신되지 않으면 마스터 노드가 실패한 것으로 간주되어 마스터 선택 작업이 트리거 될 수 있습니다. 마스터 선택 결과는 여러 백업 노드에서 합의 되어야 하므로 Paxos 및 Raft와 같은 특정 분산 합의 알고리즘 이 사용됩니다 .

장애 조치 외에도 시스템 간의 통화 시간 제한 제어는 고 가용성 시스템 설계에서 중요한 고려 사항입니다 .

복잡한 고 동시성 시스템은 일반적으로 많은 시스템 모듈로 구성되며 캐시 구성 요소, 대기열 서비스 등과 같은 많은 구성 요소 및 서비스에 의존합니다. 그들 사이에서 가장 두려운 호출은 실패보다는 지연입니다. 실패는 대개 즉각적이고 재 시도를 통해 해결할 수 있기 때문입니다. 특정 모듈 또는 서비스를 호출 할 때 상대적으로 큰 지연이 발생하면 호출자가이 호출에서 차단되고 점유 한 리소스를 해제 할 수 없습니다 . 이러한 차단 요청이 많으면 리소스가 부족하여 호출자가 전화를 끊습니다. 시스템 개발의 초기 단계에서는 일반적으로 시간 제한 제어가 무시되거나 올바른 시간 제한 기간을 결정할 방법이 없습니다.

RPC 프레임 워크를 통해 모듈이 호출되는 프로젝트를 경험 한 적이 있으며 시간 제한은 기본적으로 30 초입니다. 일반적으로 시스템은 매우 안정적으로 실행되지만 상대적으로 많은 양의 트래픽이 발생하고 RPC 서버에 특정 수의 느린 요청이 나타나면 RPC 클라이언트 스레드가 이러한 느린 요청에서 30 초 동안 차단되어 RPC 클라이언트가 스레드가 호출되는 동안 끊기를 사용하십시오. 나중에 실패 검토 중에이 문제를 발견 한 후 RPC, 데이터베이스, 캐시 및 타사 서비스 호출의 시간 초과 기간을 조정하여 전체 시스템 눈사태를 일으키지 않고 느린 요청이 발생할 때 시간 초과가 트리거 될 수 있도록했습니다. . 타임 아웃 제어가 수행되어야하므로 타임 아웃 기간을 어떻게 결정합니까? 이것은 더 어려운 문제입니다.

시간 초과 기간이 짧으면 많은 시간 초과 오류가 발생하고 사용자 경험에 영향을 미치며, 시간 초과 기간이 길면 작동하지 않습니다. 99 % 응답 시간을 계산하기 위해 시스템 간 통화 로그를 수집 한 다음이 시간을 기준으로 제한 시간을 지정하는 것이 좋습니다. 통화 기록이없는 경우 경험에 따라 제한 시간 만 지정할 수 있습니다. 그러나 어떤 방법을 사용하든 시간 초과 기간은 고정적이지 않으며 후속 시스템 유지 관리 프로세스에서 지속적으로 수정해야합니다.

시간 제한 제어는 실제로 요청을 영원히 유지하는 것이 아니라 일정 시간 후에 요청을 실패하고 다음 요청을 위해 리소스를 해제하는 것 입니다. 이는 사용자에게 해롭지 만 전체 시스템의 가용성을 보장하면서 적은 수의 요청을 희생하기 때문에 필요합니다.

그리고 시스템의 고 가용성을 보장하기 위해 두 가지 다른 손실 솔루션이 있습니다. 성능 저하 및 전류 제한입니다.

다운 그레이드는 핵심 서비스의 안정성을 보장하기 위해 비 핵심 서비스를 희생하는 관행입니다 . 예를 들어 Weibo를 게시 할 때 먼저 스팸 방지 서비스 검사를 거쳐 콘텐츠가 광고인지 여부를 확인한 다음 전달한 후 데이터베이스에 쓰는 것과 같은 논리를 완료합니다. 안티 스팸 탐지는 많은 정책 일치를 포함하기 때문에 상대적으로 무거운 작업이며 일일 트래픽에서는 시간이 많이 걸리지 만 여전히 정상적으로 응답 할 수 있습니다. 그러나 동시성이 높으면 병목 현상이 발생할 수 있으며 Weibo 게시의 주요 프로세스가 아니므로 스팸 방지 서비스 감지를 일시적으로 해제하여 주요 프로세스를보다 안정적으로 유지할 수 있습니다.

전류 제한은 또 다른 사고 방식으로 동시 요청 속도를 제한하여 시스템을 보호합니다. 예를 들어, 웹 애플리케이션의 경우 단일 시스템이 초당 1,000 개의 요청 만 처리하도록 제한하고 초과하는 부분은 클라이언트에 직접 오류를 반환합니다. 이 접근 방식은 사용자의 경험에 해를 끼치지만 극도의 동시성 하에서는 무력한 행동이며 수명이 짧은 행동이므로 허용됩니다. 실제로 다운 그레이드이든 전류 제한이든 세부적으로 논의해야 할 부분이 많이 남아 있습니다. 시스템이 나중 과정에서 계속 발전함에 따라 심도있게 분석 할 것이며 기본 사항에서는 이에 대해 이야기하지 않겠습니다.

2. 시스템 운영 및 유지 보수

시스템 설계 단계에서는 시스템의 가용성을 보장하기 위해 위의 방법을 채택 할 수 있습니다. 시스템 운영 및 유지 보수 수준에서 무엇을 할 수 있습니까? 실제로 두 가지 시스템을 개선하는 방법을 고려할 수 있습니다. 그레이 릴리스 및 오류 드릴의 측면 가용성.

비즈니스가 원활하게 운영되는 동안 시스템은 거의 실패하지 않으며 온라인 변경 단계에서 90 %의 실패가 발생한다는 것을 알아야합니다. 예를 들어 새로운 기능이있는 경우 설계 문제로 인해 느린 데이터베이스 요청 수가 두 배로 증가하여 시스템 요청이 느려지고 오작동합니다. 변화가 없다면 어떻게 데이터베이스가 왜 이유없이 느린 요청을 많이 생성 할 수 있겠습니까? 따라서 시스템의 가용성을 높이기 위해서는 변화 관리에주의를 기울이는 것이 중요합니다. 문제 발생시 신속하게 롤백하고 복구하는 데 필요한 롤백 계획을 제공하는 것 외에도 또 다른 주요 방법은 그레이 릴리스입니다.

그레이 릴리스는 시스템 변경 사항이 한꺼번에 온라인으로 푸시되지 않고 일정 비율에 따라 점진적으로 진행된다는 사실을 의미합니다. 일반적으로 그레이 스케일 게시는 시스템 차원에서 수행됩니다. 예를 들어 먼저 컴퓨터의 10 %를 변경하고 대시 보드에서 시스템 성능 표시기와 오류 로그를 관찰합니다. 일정 기간 실행 후 시스템 표시기가 비교적 안정되고 오류 로그가 많지 않으면 전체 변경 사항이 승격됩니다.

그레이 릴리스는 개발 및 운영 및 유지 보수 학생들에게 훌륭한 기회를 제공하여 변경 사항이 온라인 트래픽에 미치는 영향을 관찰 할 수 있도록합니다. 이는 시스템의 고 가용성을 보장하는 중요한 수준입니다.

그레이 릴리스는 시스템의 정상적인 작동 조건에서 시스템의 고 가용성을 보장하는 운영 및 유지 관리 방법입니다. 따라서 장애 발생시 시스템의 성능을 어떻게 알 수 있습니까? 여기서는 다른 방법 인 장애 훈련에 의존합니다.

장애 훈련은 시스템에서 잠재적 인 가용성 문제를 발견하기 위해 로컬 장애가 발생할 때 전체 시스템이 어떻게 작동하는지 관찰하는 시스템에 대한 몇 가지 파괴적인 방법을 참조 합니다.

복잡한 높은 동시성 시스템은 디스크, 데이터베이스, 네트워크 카드 등과 같은 너무 많은 구성 요소에 의존합니다. 이러한 구성 요소는 언제 어디서나 실패 할 수 있으며 실패하면 전체 서비스를 나비 효과처럼 사용할 수 없습니까? 모르기 때문에 오류 훈련이 특히 중요합니다.

제 생각에 오류 드릴은 더 인기있는 "Chaos Engineering"사고와 동일합니다. 카오스 엔지니어링의 창시자 인 2010 년 Netfix에서 출시 한 "Chaos Monkey"도구는 오류 드릴을위한 훌륭한 도구입니다 . 온라인 시스템에서 온라인 노드를 임의로 종료하여 오류를 시뮬레이션하므로 엔지니어가 이러한 오류의 영향을 이해할 수 있습니다.

물론이 모든 것은 시스템이 일부 비정상 상황을 견딜 수 있다는 전제를 기반으로합니다. 시스템이 아직이를 달성하지 못한 경우 온라인 배포 구조와 정확히 동일한 다른 오프라인 시스템을 구축 한 다음 프로덕션 시스템에 영향을주지 않도록이 시스템에서 오류 드릴을 수행하는 것이 좋습니다.

코스 요약

이 레슨에서는 시스템의 가용성을 측정하는 방법과 동시성이 높은 시스템을 설계 할 때 고 가용성을 보장하는 방법을 이해했습니다. 하지만 개발 및 운영의 관점에서 유용성을 개선하는 방법이 다르다는 것을 알 수 있습니다.

개발은 실패를 처리하는 방법에 초점을 맞추고 키워드는 중복성과 트레이드 오프 입니다. 중복성은 기사에서 언급 한 장애 조치, 다중 활성 아키텍처 등과 같은 실패한 서비스를 대체 할 예비 노드와 클러스터가 있다는 사실을 의미합니다. 선택은 경찰의 손실과 보안을 의미합니다. 주요 서비스.

운영 및 유지 관리의 관점에서는 변경 관리에 더 많은주의를 기울이고 실패 훈련을 수행하는 방법과 같이 실패를 방지하는 방법에 초점을 맞추며보다 보수적입니다.

이 둘의 조합은 완전한 고 가용성 시스템을 형성 할 수 있습니다.

또한 시스템의 유용성 을 향상시키는 것은 사용자 경험을 희생하거나 시스템 성능을 희생하는 데 기반을 두는 경우가 있으며 해당 시스템을 구축하고 메커니즘을 개선하려면 많은 인력이 필요합니다. 그러므로 우리는 어느 정도를 파악해야하며 과도한 최적화를하지 않아야합니다. 기사에서 언급했듯이 코어 시스템에서 4 개의 9가 이미 수요를 충족시킬 수 있으므로 5 개의 9 또는 6 개의 9를 맹목적으로 추구 할 필요가 없습니다.

또한 일반적인 시스템이나 구성 요소는 궁극의 성능을 추구하는데 성능을 추구하지 않고 궁극의 사용성을 추구하는 분이 있습니까? 답은 '예'입니다. 예를 들어 구성 배포가있는 시스템의 경우 다른 시스템이 시작될 때만 구성을 제공하면되므로 몇 초 안에 반환 할 수 있으며 10 초 안에 OK입니다. 이는 다른 시스템의 시작 속도를 높이는 것 이상입니다. 시스템. 그러나 가용성에 대한 요구 사항은 6 나인에 이르기까지 매우 높기 때문에 구성을 느리게 얻을 수 있지만 얻을 수 없기 때문입니다.

이 예제를 통해 유용성과 성능간에 균형이 맞지 않는 경우가 있지만 선택은 다른 시스템에 따라 다르며 일반화 할 수 없음을 알려드립니다.