현재 DB / 웹 서비스 / 프론트 엔드와 같은 n- 계층 애플리케이션이 있습니다. 다른 구성 요소가 있지만 기본 레이아웃입니다.

다음과 같은 세 가지 주요 이유로 응용 프로그램 가용성을 향상시키고 싶습니다.

1. 호스트는 때때로 정전을 경험하고 고객 모두에게 미치는 영향을 최소화하기 위해 데이터 센터 A가 다운되면 데이터 센터 B를 켤 수 있습니다.
2. 버전을 업그레이드 할 때 유지 관리를 위해 사이트를 종료하며 보통 몇 시간 (마이그레이션 스크립트 등)이 걸립니다. 다운 타임을 최소화하면서보다 원활한 전환을 원합니다 (서버 A가 업그레이드되는 동안 서버 B를 사용함).
3. 선택적으로, 우리의 고객은 전세계에 위치하고 있으며, 우리는 고객이 엉뚱한 관계에도 불구하고 가능한 최고의 경험을 갖기를 원합니다 (인도 개발자와 일한 사람은 내가 의미하는 바를 알아야 함). 이상적으로, 우리는 사무실에 서버를 연결하거나 도시 근처의 데이터 센터를 사용할 수 있기를 원하며 아키텍처에 완벽하게 통합 될 것입니다.

99 %가 아니라 99 %의 가용성이 원격으로 필요하지 않습니다. 문서 관리 앱입니다. 아무도 신경 쓰지 않습니다. 그러나 마이그레이션에 시간이 오래 걸리고 전 세계에 고객이 있기 때문에 고객이 하루 종일 일하지 못하는 경우가 있습니다.

SQL 부분의 경우 "적절한"DBA가 없지만 복제, 미러링 등과 같은 SQL 가능성에 대해 알고 있습니다 . DB 쪽에서는 이에 대한 리소스를 쉽게 찾을 수 있습니다. 세션, 코드 등을 저장하는 것이 더 어려운 것은 무엇입니까? 서버간에 세션이 어떻게 유지됩니까?

불행히도 우리 중 누구도이 분야에 경험이 없으며 어디서부터 찾아야할지조차 모릅니다. 이에 대한 모범 사례가 있습니까? 디자인 패턴? 도서관 (돈이 없어서 무료 여야합니까)?

우리는 중간에 WCF 웹 서비스와 함께 ASP.Net 및 SQL Server를 사용하고 있습니다. 우리는 주변에 많은 Windows 서비스가 있지만 미션 크리티컬하지는 않으며 웹 사이트를 처리하는 방법이 서비스에 적용된다고 가정합니다.

대부분의 클라우드 플랫폼은이를 위해 기본 제공 시스템을 제공하지만, 모든 것을 스스로 관리하고 누구에게도 의존하지 않기를 원하는 sysadmin 덕분에 클라우드 호스팅은 아무 문제가 없습니다.

찾고있는 고 가용성 유형을 명확히해야합니다. 내가 실행하는 고 가용성 응용 프로그램은 시간의 95 %가되어야합니다. 99 %로 실행해야하는 다른 것도 있습니다. 100 % 가동 시간이 필요한 인명 또는 사망 시나리오를 생각할 수 있습니다. 이 세 가지만이 접근 방식과 비용이 크게 다릅니다.

요구 사항과 95-99 % 가동 시간 SLA를 기반으로 추측하기 만하면됩니다.

• 데이터베이스 마이그레이션은 대부분의 변경에 대해 실시간으로 발생할 수 있어야합니다. 혁신적인 데이터베이스 설계를 연습하십시오 . 보다 침습적 인 동작이 필요한 변경에는 몇 가지 옵션이 있습니다. 하나는 가동 중지 시간입니다. 가능하면 서비스를 읽기 전용 모드로 실행하면 작동 할 수 있습니다. 전체 기능을 위해 한동안 ScaleArc를 사용 해보고 싶었습니다. SQL Server 세계에서 확장 및 복원력을위한 정말 매끄러운 도구처럼 보입니다.
• 고객의 사이트에 서버를 배치하는 것은 세계적 수준의 배포 전략 (이주에 대한 설명에 따라 아직없는)을 얻지 않는 한 관리 할 수없는 재난의 레시피입니다. 성능 문제가 있으므로 클라우드 서비스를 온 프레미스로 푸시하지 마십시오. 이제 성능 문제를 해결하면 비용이 많이 드는 문제를 처리 할 필요가 없습니다.
• 상태 서버는 일종의 데이터베이스 여야합니다. HA 지침을 따르십시오. 이미 사용할 수 있으므로 SQL Server를 사용할 수 있습니다.
• 데이터베이스에 대해 말하면 복제는 HA를 활성화하지 않습니다. 실제로, SQL 복제는 매번 (다중 노드 복제 시나리오에 대한 경험으로 말하면) 골칫거리가됩니다. 미러링은 작동 할 수 있지만 SQL 클러스터링은 새 서버로 장애 조치하는 데 1-5 분이 걸립니다. AlwaysOn에 대해 좋은 소식을 들었지만 Microsoft의 실적을 보면 여전히 의심 스럽습니다. ScaleArc와 같은 것이 더 도움이 될 것입니다.
• 웹 서버는 상태 비 저장 상태 여야합니다. 서너 개를 돌려로드 밸런서 뒤에 놓습니다. 이렇게하면 가동 시간이 걱정됩니다. Frederik이 앞에서 언급했듯이 이런 방식으로 롤링 배포를 수행 할 수도 있습니다.
• 귀하의 웹 서비스는 아마도 상태가 없어야합니다. 그렇지 않은 경우이를 상태 비 저장 및 상태 저장 비트로 분리 할 수 ​​있는지 확인하십시오. 동일한로드 밸런서 뒤에 여러 인스턴스를 배치하면 가동 시간 문제가 해결되고보다 관심있는 배포 시나리오 (예 : 블루 / 그린 배포)가 가능합니다.

프레드릭과는 달리, 나는 당신의 클라우드 편집증을 보증하지 않습니다. 가동 시간 요구 사항에 따라 다릅니다. 중복성을 위해 서비스를 다른 국가의 다른 공급자가 운영하는 여러 데이터 센터에서 실행해야 할 수도 있습니다. 그러나 현재 상태를 감안할 때 AWS, Azure 또는 이와 유사한 것이 회사에 안전한 내기 일 것입니다.

웹 및 애플리케이션 계층에서 일정 수준의 HA 확보 :

1. 이상적으로는 세션 상태를 포함하여 데이터베이스 또는 메모리 내 세션 상태 서버와 같은 공유 상태 시스템으로 모든 상태를 고려하십시오. 애플리케이션 디자인에 따라 대기 시간이 길어지면서 성능 문제가 발생할 수 있습니다.

2. 웹 사이트 및 애플리케이션 계층에는 각각 독립적 인로드 밸런서가 있어야합니다. NGINX는 트릭을 수행하지만 IIS 도이 작업을 수행 할 수 있습니다 (ARR).

3. 단일 데이터베이스가로드를 처리 할 수없는 경우 세션 상태 파티셔닝 (또는 샤딩 또는 일관된 해싱)을 활용하여 특정 요청을 특정 데이터베이스 상자로 라우팅하십시오.

상태를 분해하는 것이 너무 어려운 경우 부하 분산을 위해 서버 선호도를 사용할 수 있습니다 (즉, 사용자는 쿠키 기반의 동일한 상자로 일관되게 라우팅됩니다). 박스 중단은 해당 박스의 모든 사용자 및 상태에 영향을 미치지 만 완전한 정전 (사용 사례에 따라 다름)을 능가하기 때문에 상태 비 저장 라운드 로빈 방식만큼 고 가용성이 아닙니다.

업그레이드 측면에서 :

1. 시스템이 실행되는 동안, 즉 하위 호환성을 유지하면서 데이터베이스 업그레이드를 수행 할 수 있도록 데이터베이스 스크립트를 설계하십시오. 이를 위해 잘 작동하는 패턴은 "확장 후 계약"입니다.-> 이전 버전과 호환되는 변경 사항 만 추가하지만 제거하려는 필드 (예 : 기타)에 대한 종속성은 제거합니다. 그런 다음 데이터베이스의 모든 클라이언트를 v-latest로 업그레이드하십시오. 그런 다음 데이터베이스에서 이전 필드 등을 제거하기 위해 다른 db-upgrade를 수행하십시오. 큰 데이터베이스가 있고 시스템 성능이 저하되지 않도록주의해야하는 경우 느린 프로세스 일 수 있습니다.

2. 앱 계층 업그레이드 : 클라우드 환경을 사용하지 않기 때문에 카나리아 배포 패턴을 따르는 것이 좋습니다. 웹 및 중간 계층 상자의 롤링 업그레이드를 수행하십시오. 배포가 잘못되면 실패한 것처럼로드 밸런서에서 상자를 꺼냅니다.

경고의 말씀 : HA 용으로 설계되지 않은 시스템을 시스템으로 발전시키는 것은 길고 비용이 많이 드는 과정 일 수 있습니다. 그 과정에서 균형을 유지해야합니다 (특정 수준의 가용성에 도달하기위한 비용과 노력)

클라우드 편집증은 보증하지 않습니다. AWS와 같은 제공 업체는 모범 사례와 함께 대부분의 위험을 제어 / 완화 할 수 있습니다. 규정 준수 페이지를 검토하여 규정 준수 여부를 확인하십시오. https : // aws .amazon.com / compliance /

TL; DR : 중복, 모듈 식 구축; 가용성 테스트; 면밀히 모니터링하십시오.

어떤 설명 으로든 짜내려고 시도하는 것은 매우 오래 걸릴 수 있다는 것을 깨닫고 나서 내가 한 모든 관찰 내용을 기록 할 것입니다.

전제 질문

클라우드 시스템은 만병 통치약입니다

최고의 클라우드 제공 업체와 함께 클라우드를 완전히 사용하더라도 탄력성을 위해 애플리케이션을 설계해야합니다. AWS가 VM을 대체 할 수 있지만 계산 중에 남아 있으면 애플리케이션을 다시 시작할 수 있어야합니다.

x / y / z로 인해 클라우드 시스템을 사용하고 싶지 않습니다.

초대형 조직이 아니라면 클라우드 시스템을 사용하는 것이 좋습니다. 3 대 클라우드 시스템 (AWS, MSFT, Google)은 수천 명의 엔지니어를 고용하여 약속 된 SLA와 관리하기 쉬운 대시 보드를 제공합니다. 실제로이 사내에서 한푼도 소비하는 대신에 사용하는 것이 좋습니다.

범위 지정 및 디자인 문제

서비스 가용성을 정의, 수량화 및 지속적으로 측정하는 것은 가용성 문제에 대한 솔루션을 작성하는 것보다 더 큰 과제입니다.

'가용성'정의 및 측정이 예상보다 어렵다

다수의 이해 관계자는 가용성에 대한 관점이 다르며, 급여가 가장 높은 사람이 선호하는 정의가 다른 정의보다 우선합니다. 이것은 때때로 정확한 정의이지만, 이상적인 정의는 실시간으로 모니터링 할뿐만 아니라 측정하기가 까다로워서 동일한 시스템을 측정하기 위해 종종 생태계가 구축되지 않습니다. 실시간으로 모니터링 할 수없는 가용성에 대한 정의가있는 경우 자체 유사 유사한 프로젝트를 여러 번 반복해서 발견 할 수 있습니다. 이해하기 쉬운 것과 쉽게 모니터링 할 수있는 것을 고수하십시오.

사람들은 항상 사용 가능한 시스템의 복잡성을 과소 평가합니다.

방 안에있는 코끼리를 해결하기 위해 다음과 같이 말하겠습니다. "다중 컴퓨터 시스템을 100 % 사용할 수는 없습니다. 미래에는 있지만 현재 기술로는 사용할 수 없습니다." 현재의 기술에 따르면, 나는 빛의 속도와 같은 것들보다 신호를 더 빨리 보낼 수 없다는 것을 언급하고 있습니다. 솔트 가치가있는 모든 comp-sci 엔지니어들은 분산 컴퓨팅의 한계를 알고 있으며 대부분은 회의에서 언급하지 않고 멍청한 것처럼 보일 것입니다. 분산 컴퓨팅 제한 사항을 언급하지 않는 모든 사람들을 보완하기 위해 복잡하지만 항상 컴퓨터를 신뢰하는 것은 아닙니다 .

사람들은 엔지니어의 능력을 과대 평가합니다

불행히도, 가용성은 원하는 것을 모르지만 원하지 않는 것을 아는 범주에 속합니다. UI와 같은 '원하는 것'범주를 이해하는 것은 조금 까다 롭습니다. 다른 사람의 경험과 더 많은 것을 배우려면 약간의 경험과 많은 독서가 필요합니다.

처음부터 사용 가능한 시스템 구축

시스템 요구 사항으로서 가용성의 올바른 우선 순위에 대해 모든 아키텍처 및 디자인 팀에 전파해야합니다.

가용성을 돕는 시스템 속성

다음 시스템 특성은 시스템 가용성에 기여한 것으로 나타났습니다.

여분

이에 대한 몇 가지 예는 VIP 뒤에는 단일 VM 만 있거나 데이터의 단일 복사본 만 저장하지 않아야합니다. 좋은 IAAS를 사용하면보다 쉽게 ​​해결할 수 있지만 여전히 이러한 결정을 내려야합니다.

모듈성

모듈 식 REST 는 단일 SOA보다 낫습니다. 심지어 모듈 식 마이크로 서비스조차도 일반적인 HATEOS REST 보다 더 유용합니다 . 추론은 다음 섹션의 수율 관련 토론에서 찾을 수 있습니다. 배치 처리를 수행하는 경우 1,000,000 배치를 처리하는 것과 비교하여 합리적인 10 배치로 배치 처리하는 것이 좋습니다.

복원력

"I am always angry"
                    - Hulk

복원력있는 시스템은 항상 복구 할 준비가되었습니다. 이 복원력은 RAID 디스크에 기록한 후에 만 ​​쓰기에 대한 ACK 승인과 두 개 이상의 데이터 센터에 대한 승인과 같은 인스턴스에 적용됩니다. 또 다른 최신 동향은 충돌이없는 데이터 구조 를 사용하는 것인데 , 여기서 데이터 구조는 서로 다른 두 가지 버전이 제공 될 때 충돌을 해결할 책임이 있습니다. 시스템은 나중에 생각할 때 복원력을 발휘할 수 없으므로 예측하고 내장해야합니다. 고장은 장기적으로 보장되므로 항상 복구 계획을 세워야합니다.

로그 트레일

이것은 기술적으로 복원력의 하위 유형이지만 모든 기능을 포착하기 때문에 매우 특별합니다. 최선의 노력에도 불구하고 사용할 수없는 패턴을 예측하지 못할 수 있습니다. 가능하면 시스템 이벤트를 재생할 수 있도록 시스템 활동의 로그 추적을 충분히 유지하십시오. 이렇게하면 수동 비용이 많이 들기 때문에 예기치 않은 상황에서 복구 할 수 있습니다.

가용성의 속성

'사용 가능 여부'의 포괄적 인 최상위 속성 목록 : 토론을 위해 사용자가 묻는 질문은 "내 장바구니에 몇 개의 품목이 있습니까?"라고 가정 해 봅시다.

단정

가장 정확한 답변 을 작성 해야 합니까? 아니면 실수를해도 괜찮습니까? 참고로 ATM에서 돈을 인출 할 때 정확하지는 않습니다. 은행에서 실수 한 것을 발견하면 거래를 취소 할 수 있습니다. 당신의 시스템이 소수를 생산한다면, 당신은 항상 정답을 원할 것입니다.

수율

이전 주제 질문에 대해 항상 올바른 대답을 한 경우이 지점을 건너 뛰십시오. 때때로 질문에 대한 대답이 정확할 필요는 없습니다. 예를 들어, 지금 Facebook에 얼마나 많은 친구가 있습니까? 그러나 대답은 항상 야구장 +/- 1에있을 것으로 예상됩니다. 예상 결과를 생성 할 때 수율은 100입니다.

일관성

당신의 대답은 한 순간에 정확할 수 있지만, 빛이 화면을 떠나 관찰자의 망막에 들어갈 때까지 상황이 바뀔 수 있습니다. 대답이 잘못 되었습니까? 아니요, 일관성이 없습니다. 대부분의 응용 프로그램은 최종적으로 일관성이 있지만 응용 프로그램에서 제공 할 일관성 모델의 종류를 정의하는 것이 요령입니다. 우연히 응용 프로그램이 단일 컴퓨터에서 실행될 수 있으므로 CAP 정리 에서이 멋진 독서를 건너 뛸 수 있습니다 .

비용

단기 효과 (수익 손실)와 장기 효과 (불평, 고객 유지율)의 총 영향에 따라 달라집니다. 고객 유형 (유료 / 무료, 반복 / 고유, 포로) 및 리소스 가용성에 따라 다른 수준의 가용성 보장이 내장되어야합니다.

기존 시스템의 가용성 향상을 향해

개별 시스템과 네트워크의 운영 관리는 매우 복잡하므로 클라우드 제공 업체에 맡기거나 이미 수행중인 작업을 알기에 충분히 전문가라고 가정합니다. 가능한 경우 다른 주제를 다룰 것입니다. 장기 전략을 위해 Define-Measure-Analyze-Control 은 하늘의 일치입니다.

1. 이해 관계자에게 '가용성'을 정의하십시오.
2. 정의한 것을 어떻게 측정 할 것인가
3. 병목 현상을 식별하기위한 근본 원인 분석
4. 개선을 위한 작업
5. 시스템의 지속적인 모니터링 ( 제어 )

사용할 수없는 원인

물리적 인프라 관리를 포괄하는 운영 관리는 전문가가 수행해야한다는 데 동의 했으므로, 완전성을 위해 사용할 수없는 다른 원인을 다루겠습니다. IMO 가용성에는 예상되는 동작 부족이 포함되어야합니다. 즉, 사용자에게 예상 된 경험이 표시되지 않으면 사용할 수없는 것이 있습니다. 이러한 광범위한 정의를 염두에두고 다음과 같은 기능을 사용할 수 없게 될 수 있습니다.-코드 버그-보안 문제-성능 문제