Architect's Diary - 소프트웨어 고가용성 실습

저자: JD 소매 Liu Huiqing

I. 소개

소프트웨어의 고가용성은 일반적인 주제입니다. "고가용성"(고가용성)은 일반적으로 서비스의 고가용성을 유지하면서 다운타임을 줄이도록 특별히 설계된 시스템을 말합니다. 계산 공식은 가용성 비율 = ( 총 시간 - 사용 불가 시간 ) / 총 시간입니다.

이 기사는 진입점으로서 구현 사례의 관점에 초점을 맞추고 협업 효율성, 기술 구현 및 운영 사양 측면에서 고가용성의 구현 단계 및 구현 세부 사항을 보여주도록 유도합니다. 이해를 돕기 위해 먼저 언어와 어휘를 통일하고 다음 그림과 같이 소프트웨어 제공 프로세스의 다양한 단계를 살펴보겠습니다.



 

소프트웨어의 고가용성이 많은 문제에 직면해 있다고 말하는 이유는 무엇입니까?

◦ 수요 인도 연계 관점에서 목표 인도를 완료하기 위해서는 제품, R&D, 시험, 운영 및 유지보수, 운영 등 여러 이해관계자의 긴밀한 협력이 필요함. 일부 프로젝트 요구 사항의 경우 때로는 수백 명의 협력자가 있습니다.각 사람은 책임이 다르지만 서로 협력하고 서로 의존합니다.링크에 오류가 있으면 가용성 비율에 영향을 줄 수 있습니다.

◦ 시간적 관점에서 연간 가용률 99.99%를 달성하고자 한다면 1년 중 장애 허용 시간은 365*24*60*(100%-99.99%)=52분, if 5개의 9의 가용성 비율을 달성하기 위해 허용되는 실패 시간은 5분에 불과합니다. 이는 문제를 찾은 후 애플리케이션을 다시 시작하는 데 걸리는 시간과 거의 같습니다.

◦ 반복 효율성의 관점에서 반복이 없고 온라인이 없으면 문제의 확률이 훨씬 작아집니다. 소프트웨어 반복 효율성과 가용성 사이에는 음의 상관관계가 있으며, 이 둘 사이의 균형을 맞추는 것도 상당한 어려움에 직면할 것입니다.

요약하자면 우리가 직면한 구체적인 문제는 다음과 같습니다.

◦ 주문 배송과 관련된 많은 협력자와 긴 링크의 문제를 해결하는 방법은 무엇입니까?

◦ 다운타임 허용 오차가 낮은 문제를 어떻게 처리해야 합니까?

◦ 빈번한 수요 반복 상황에서 가용률이 크게 영향을 받지 않도록 하려면 어떻게 해야 합니까?

2. 협업 효율성 보장

인지적 오해

전체 수요 전달 링크에서 링크가 단계적으로 증가함에 따라 정보 전송 링크의 분기가 많아지고 전송 수준이 깊어짐을 알 수 있습니다. 이로 인해 두 가지 문제가 발생합니다.

1. 정보전달의 효율성이 떨어지는 경우

2. 정보 정확도가 나빠집니다.

이 두 가지 문제의 최종 결과는 협업 효율성의 감소입니다.





 

실무 경험이 없는 학생은 인원을 늘리면 수요 전달의 효율성이 높아진다고 생각하는 경우가 많습니다. 사실 이 생각은 완전히 옳지 않으며 구체적인 관계는 다음 그림을 참조하십시오.





 

마치 건물을 짓는 것과 같으니 한 사람이 한 단계씩 쌓으면 완성하는 데 100일이 걸립니다. 100명을 초대하면 하루 만에 집을 지을 수 있을까? 대답은 부정적입니다.

다음과 같은 협업 비용이 있습니다. 팀 이해(디자이너, 벽돌공, 석공, 배관공), 작업 연결, 위험 제어

예를 들어 프로세스 종속성이 있습니다. 구성은 디자인에 따라 다르며 부드러운 장식은 항상 단단한 장식 후에 나옵니다.

다음과 같은 비용 예산이 있습니다. 전체 조직(계약자, 대리인, 계약자)의 인재 구배 및 규모;

위의 모든 것은 단순히 인력을 배치한다고 해결되지 않습니다.

프로세스 사양

협업 효율성을 향상시키는 기본 논리는 전달 링크 수준을 낮추고 정보 전송 링크를 단축하여 정보의 정확성과 전송 효율성을 보장하는 것입니다. (조직 구성 수준의 내용은 여기에서 확장하지 않습니다)

이를 위해서는 오늘의 작업을 수행하고 오늘의 작업을 완료할 수 있는 능력이 필요합니다. 조직 차원에서는 이를 프로세스 명세라 하고, 개인 차원에서는 업무 방식 및 책임감이라 부른다.

현재 문제를 다음 링크로 지연시키지 않도록 하십시오. 그렇지 않으면 후속 링크의 일정 및 전달 효율성에 영향을 미치고 극단적인 경우 재작업이 발생할 수도 있습니다. 즉, 명확하게 생각하고 구멍을 묻지 마십시오. 제품 요구사항은 R&D용, R&D 설계는 테스트용, 테스트 케이스는 제품과 같은 각 전달 노드에 대한 것입니다.

세 가지 기술 착륙 보장

수요 응답 주기에서 아키텍처 설계, 코딩 구현, 안전한 시작, 배포 및 운영 및 기타 생산 단계의 고품질 구현은 고가용성 소프트웨어 구현의 전제이자 기초입니다.

건축 디자인

아키텍처 설계는 종종 시스템의 초기 구현 비용(ROI)과 후속 운영 및 유지 관리의 어려움에 영향을 미치며, 구현 세부 사항에 매크로 설계 체계와 패러다임 제약 조건을 모두 포함하는 소프트웨어의 최상위 설계에 속합니다. .

• 프로세스 보증

설계자 참여 초대: 설계자를 초대하여 핵심 트랜잭션 노드 및 주요 수요 변화에 참여하도록 합니다. 이는 구덩이를 닫는 가장 직접적이고 효과적인 방법입니다.

설계 문서에 대한 강조: 계획에 대한 명확한 설명과 관련 이해 관계자의 승인은 올바른 길을 걷기 위한 전제 조건입니다.

• 설계 보증

재해 복구 설계: 탈출구를 확보하고 미리 명확하게 생각하고 재해 복구 설계를 잘 수행해야 합니다. 롤백, 융합, 재시도 및 다운그레이드가 가능합니다.

견고한 디자인: 무상태형 디자인, 헤비 방지 디자인, 멱등성 디자인, 데이터 일관성 디자인

인코딩 구현

건축 설계가 뼈대라면 코딩 구현은 신경, 혈관, 근육입니다. 전자는 얼마나 안정적이고 얼마나 오래 걸을 수 있는지를 결정하는 반면, 후자는 얼마나 빨리 그리고 얼마나 멀리 갈 수 있는지를 결정합니다. 코딩 수준에서 구현되며 코드의 노후화 및 손상 정도입니다.

• 프로세스 사양

코드 검토 메커니즘: 코드 검토는 시스템에서 문제를 찾는 것만큼 간단하지 않습니다. 그것은 조직 문화의 구현과 계승을 위한 장기적인 행동이자 형식이자 매개체입니다. 검토 과정에서 비즈니스 책임의 경계, 설계 및 코딩 합의, 우수한 표준 지향 연구 및 개발 합의가 명확해졌습니다. 팀의 전투 효율성을 보장하는 초석이되는 구체적인 사례를 통해 구체적인 지침을 제공하는 것과 같습니다.

R&D 프로세스의 많은 문제는 다음과 같은 코드 검토 메커니즘을 통해 발견하고 해결할 수 있습니다.

◦ 임시 요구사항의 설계 및 구현을 어떻게 처리합니까?

◦N으로 "Hello World!"라고 쓰는 것에 대해 어떻게 생각하세요?

◦ 디자인 패턴과 오버엔지니어링의 경계를 어떻게 이해할 것인가?

◦ 현재 단계의 산출물은 어떻게 평가할 것인가?

◦ 단위 테스트를 도입해야 합니까?

• 코딩 표준

◦ 오류 처리가 있습니까? 호출된 외부 서비스에 대해 반환 값을 확인하거나 예외를 처리합니까?

◦ 디자인이 알려진 디자인 패턴이나 프로젝트에서 일반적으로 사용되는 패턴을 따르고 있습니까?

◦ 개발자가 새로 작성한 코드를 기존 SDK/Framework의 기능으로 구현할 수 있나요? 이 프로젝트에서 모든 것을 다시 구현하지 않고 호출할 수 있는 유사한 함수가 있습니까?

◦ 무용지물, 중복 기능, 다른 버전의 jar 패키지 종속성이 프로젝트에 도입되었습니까? (json 라이브러리, 다양한 유틸리티)

◦ 제거할 수 있는 쓸모없는 코드가 있습니까?

◦ 코드의 가독성은 어느 정도입니까? 충분한 의견이 있습니까?

◦ 파라미터 전달에 오류가 있는지, 우리가 불변이라고 생각하는 조건이 실제로 충족되는지 확인하기 위한 어설션(Assert) 또는 판단이 있습니까?

◦ 경계 조건은 어떻게 처리됩니까? switch 문의 기본 분기는 어떻게 처리됩니까? 루프가 무한 루프를 가질 수 있습니까?

◦ 자원 신청 및 공개는 어디에서 하나요? 가능한 리소스 누수(시간 초과, 메모리, 파일, 개체 참조, 큰 개체, 스레드 수 등 포함)가 있습니까? 최적화의 여지가 있습니까?

◦ 코드가 얼마나 효과적인가? 최악의 시나리오는 무엇입니까?

◦ 코드에서, 특히 루프에서 확실히 최적화할 수 있는 부분이 있나요(StringBuilder로 문자열 연산을 최적화할 수 있나요)?

◦ 시스템 및 네트워크 호출 시간이 초과됩니까? 그것을 처리하는 방법?

◦ 코드는 테스트하기 쉬운가(메서드 라인 수, 순환 복잡성, 입력 및 출력 매개변수의 정의가 합리적인지 여부)?

◦ 변경 사항이 이전 버전, 과거 데이터 및 업스트림 호환성에 영향을 줍니까?

◦ 인터페이스 디자인이 멱등성, 동시성, 초과 도달 및 성능 저하와 같은 문제를 고려합니까?

◦ 여러 데이터 소스에서 캐싱, 데이터베이스 성능 문제 및 데이터 일관성 문제가 있습니까?

◦ 온라인 계획은 그레이스케일 계획과 불일치 데이터 상태를 고려합니까?

안전한 온라인

온라인 장애의 70%는 어떤 종류의 변화에 ​​의해 촉발되며, 그 중 상당 부분이 불규칙한 온라인으로 인해 발생합니다. 따라서 안전하게 온라인에 접속하는 것은 매우 중요합니다.

• 프로세스 사양

◦ 인터넷에 자주 접속하는 것은 엄격히 금지되어 있습니다. 예를 들어, 일주일에 2회 이하;

◦ 피크 기간 동안 온라인에 접속하는 것은 엄격히 금지됩니다. 문제의 범위를 줄입니다.

◦ 무단으로 접속하는 것을 엄격히 금지합니다. 변경 사항이 있는 경우 테스트 검증 및 반품 확인을 통과해야 합니다.

• 프로세스 사양

◦ 트래픽 픽업: 트래픽을 픽업하기 위해 jsf off-line/np 머신의 첫 번째 배치를 선택합니다(콜드 대기로 선택).

◦ 로그 보기: 로그를 관찰하여 제거된 머신에 트래픽이 없는지 확인합니다.

◦ 서비스 예열: 기계가 성공적으로 시작되었는지 확인하고 핵심 비즈니스 인터페이스를 예열해야 합니다.

◦ 행잉 트래픽: 온라인 머신 트래픽을 탑재합니다.

◦ 지표 보기: 온라인 머신의 mdc 지표가 비정상인지(cpu, memory, load), 로그가 비정상인지 관찰

배치 작업

고가용성을 달성하기 위한 매우 중요한 수단은 용량 중복입니다. 방향과 아이디어는 물론 특정 상황에 따라 확장될 수 있는 특정 구현 세부 사항 및 전략이 아래에 제공됩니다.

• 네트워크

◦ 통신사 수준에서 China Unicom, China Telecom, China Mobile 등

◦ 링크 노드, VIP, CDN, 라우터/스위치, 리버스 프록시, 클라이언트, 브라우저 등

• 보관

◦ 데이터베이스 마스터-슬레이브 아키텍처든 ES의 카피 아키텍처든 스토리지의 고가용성을 확보하기 위한 수단이며 중요한 데이터는 해당 기능을 잘 활용해야 한다.

◦ 데이터 구조를 설계할 때 분기 전략, 용량 계획, 데이터 분할 또는 이질성도 잘 수행해야 합니다. 예: 핫 키 캐싱, 데이터베이스 테이블 처리량의 병목 현상, 데이터베이스 연결 수 제한 및 고가용성에 영향을 미치는 기타 문제를 피하십시오.

• 서비스

◦수평적 확장: 서비스는 자원을 추가하여 용량을 확장할 수 있도록 하는 것이 매우 중요합니다.

◦ 서비스 그룹화: 비즈니스 당사자 또는 사용 시나리오에 따라 극한 상황이 서로 영향을 미치지 않도록 서비스를 서로 다른 세분화로 격리합니다.

◦ 극한 전략 : 주로 극단적인 비정상 상황에서의 방어전략으로, 사고 발생 후 서비스의 신뢰도를 최대한 유지하는데 목적이 있음. 예: 전류 제한, 퓨즈, 재시도, 빠른 실패 등

◦ 그레이 스케일 전략: 새로운 기능이 출시될 때 문제가 발생할 가능성이 가장 높음 트래픽 그레이스케일 기능을 성숙시키는 것이 문제의 범위를 제어하는 ​​열쇠입니다.

4개의 작동 표준 보증

작동 사양

1. 모니터링 가능 : 시스템 실행 상태

2. 경찰에 신고 가능 : 이상 상황 발생 시 관련 담당자에게 시스템 통보 가능

3. 찾을 수 있음 : 문제 발생 후 문제의 원인을 빠르게 찾을 수 있음

4. 수리 가능 : 비정상적인 상황 발생시 최초 수리가 가능합니다.

비상 계획

고가용성은 가동 중지 시간에 대한 허용 오차가 낮고 문제 해결 및 복구를 위한 시간이 없으며 취약성 문제 해결을 위해 코드를 열 시간이 없음을 의미합니다. 이를 위해서는 예측 가능한 대부분의 고장 문제를 해결할 수 있는 완전한 비상 계획 세트가 필요합니다.

• 프로세스 사양

◦ 먼저 생산을 재개하십시오.

◦ 두 번째 문제 해결;

자세한 사고 응급처치 매뉴얼은 다음 그림을 참조하십시오.





 

• 프로세스 사양

◦ 네트워크, 서비스, 스토리지의 3차원에서 해당 계획을 수립하고, 비상 계획 목록(파일명: 체크리스트)을 자체 코드 베이스에 작성하여 콘텐츠를 상속 및 업데이트합니다.

◦ 예측 가능성 , 즉 문제 유발 시나리오가 명확하게 작성되어야 합니다. 예: 현재 진행률(10,000/일)에 따르면 데이터베이스 데이터가 증가함에 따라 10개월 후 데이터베이스 테이블(xxx 테이블 이름)에 느린 쿼리가 나타날 것으로 예상됩니다.

◦ 달성 가능성 , 문제에 대한 해결책을 제거하는 능력. 예: 기록 데이터 보관 작업(xxxWorker)을 시작하고 기록 데이터를 보관 데이터베이스로 전송합니다.

표준 준수

프로세스와 규범이 아무리 좋아도 이를 구현하기 위한 상응하는 메커니즘이 있어야 하며, 그렇지 않으면 거울 속의 꽃, 물 속의 달이 아름다워 보이지만 실제로는 쓸모가 없습니다. 실행 가능하고 측정 가능한 것은 목표에 따라 더 나아지기 위한 전제 조건입니다. 그래서 여기에 사양 구현을 지원하기 위한 "고가용성 및 규정 준수 주기적 자체 검사 테이블"이라는 도구가 있습니다.

다섯 가지 요약

이 기사에서는 "고가용성에 왜 큰 문제가 있는가? ". 아키텍처 설계, 코딩 구현, 안전한 실행, 배포 및 운영 등의 측면에서 기술 구현 보장과 관련된 지침 및 구현 세부 사항을 자세히 소개합니다. 마지막으로 발사 후 운영 관점에서 비상대책, 정기 자가점검표 등 실질적인 운영 보장 수단을 제공한다. 독자들에게 도움이 되기를 바랍니다.

{{o.이름}}

{{이름}}