고가용성 아키텍처 및 모범 사례
고가용성에 대해 거의 알려지지 않은 사실 13가지
1. 하이퍼바이저 HA는 애플리케이션 HA와 동일하지 않습니다.
주요 오해는 하드웨어 또는 하이퍼바이저에 중복성이 있기 때문에 고가용성을 갖는다는 것입니다. 그러나 하드웨어 및 하이퍼바이저 중복성은 다음을 보장하지 않습니다. 고가용성 응용 프로그램을 위해. 또한 오류 발생 시 응용 프로그램의 오케스트레이션이 올바르게 실행된다는 보장도 없습니다.
2. 고가용성에서 더 큰 것이 더 나은 것은 아닙니다.
당신이 파워리프터라면 더 큰 중량이 더 좋고 더 적은 횟수가 더 좋습니다. 또는 포옹에 대해 이야기하는 경우. (포옹은 우리가 다른 도시에서 온 친구를 만났을 때 하던 일, 한동안 보지 못했던 일을 기억합니다.) 그러나 더 크다는 것이 항상 더 좋은 것을 의미하지는 않습니다. 예를 들어, 더 큰 신장 결석은 확실히 더 좋지 않습니다. 고가용성에서 더 크고 더 복잡한 솔루션을 만든다고 해서 항상 고가용성을 높일 수 있는 것은 아닙니다. 가용성이 같거나 더 적음을 의미할 수 있습니다. 또한 가동 중단 시 처리해야 할 이동 부분이 많은 더 크고 복잡한 시스템이 있음을 의미할 수도 있습니다.
3. 모든 것이 실패… 때때로
응용 프로그래밍 언어는 1950년대로 거슬러 올라갑니다. 그리고 언어, 프로세서, IDE 및 코드 품질이 향상되었지만 현실은 "모든 응용 프로그램은 어느 시점에서 실패"합니다. 예외, 버그, 처리되지 않은 종료, 우발적인 종료, 리소스 고갈 등으로 인한 실패가 발생합니다. 능동/능동 또는 능동/수동 애플리케이션 가용성 전략이 여전히 필요합니다.
4. '어떻게'보다 '왜'에 집중하라
작업 완료 모드로 뛰어드는 우리의 자연스러운 경향은 필수 자산이지만, 이유에 대한 우리의 질문에 대한 답변에 따라 조정되고 안내되어야 합니다. 비즈니스, 애플리케이션, 데이터베이스 및 이해 관계자 요구 사항을 이해하지 않고 환경에 솔루션을 추가하면 다음 중 하나가 발생합니다.
- 실패
- 초과 지출
- 실적 부진
- 혼돈과 건축
- 무엇보다도
가용성 구현에만 집중하는 대신 비즈니스 요구 사항을 이해하고 "이유"에 대한 답을 찾는 데 필요한 리소스와 노력을 투자하십시오.
5. 패치되지 않은 문제는 일반적인 후회의 원인입니다.
하거나 하지 않으면 결과가 있습니다. 패치되지 않은 모든 문제의 결과는 후회입니다. 고객 경험 담당 부사장으로서 저는 고객이 알려진 문제를 적시에 해결하지 못해 발생하는 가동 중지 시간을 직접 목격했습니다.
6. 문서화되지 않은 문제로 인해 다운타임도 발생합니다.
장면을 그려보세요. 새 관리자가 네트워크의 서버를 조사하고 있습니다. 사용 보고서는 서버가 활성 상태가 아니며 연결된 클라이언트가 없음을 나타냅니다. 서버를 인식하지 못하고 "태그", 문서 또는 기타 식별자를 찾지 못한 새 관리자는 서버를 종료해야 한다고 생각합니다. 불행히도 문서화되지 않고 통신되지 않은 인스턴스는 실제로 대기 서버로, 기본 서버가 예기치 않게 충돌할 때 제거로 인해 가동 중지 시간이 발생합니다. 이것은 허구의 이야기가 아닙니다. 이것은 서버를 유휴 QA 시스템으로 잘못 식별하고 패치 작업 전에 종료한 새 관리자의 실화입니다.
7. 안일함도 적이다
온프레미스나 클라우드 또는 그 사이의 어느 곳에서든 가용성이 "설정하고 잊어버릴 수 있는" 것이라면 모두가 좋아할 것입니다. 그러나 인생에서 "설정하고 잊어버리십시오"만큼 간단한 것은 거의 없습니다. 미래 가용성의 가장 큰 적 중 하나는 지금 고가용성을 통한 성공입니다. 재해가 거의 없고 팀이 지속적인 안정성을 실현했다고 확신할 때 안주가 개입할 수 있습니다. 성공은 우리로 하여금 아무 것도 변하지 않을 것이라고 생각하게 만들고 고가용성에 대한 안일함은 고가용성의 적입니다. 기업 주변과 기업 내부의 상황이 변화하고 있습니다. 클라우드가 변하고 비즈니스 요구가 변하고 애플리케이션과 운영 체제도 변하고 있습니다.
8. 변화는 어렵다
변화는 어렵다. 취침 전에 케이크의 두 번째 조각을 포기하려고 애쓰는 단 것을 좋아하는 사람에게 물어보십시오. 고가용성에서도 유사한 저항이 발생합니다. 팀은 재난을 경험한 팀이라도 좋은 변화라도 변화를 꺼리는 경우가 많습니다. 그들에게는 비전, 이유에 대한 이해, 지원이 필요합니다. 솔루션을 갖춘 다른 팀은 불안정을 초래하거나 새로운 위험에 노출될까 두려워 고가용성을 개선하기를 꺼립니다.
9. 모든 변화가 좋은 변화는 아니다
변화가 좋을 때 변화가 좋다. 고가용성 솔루션 및 아키텍처에 대한 변경을 고려할 때 목표, 요구 사항 및 가용성 증가 범위 내에서 변경 사항을 분석하는 것이 중요합니다. 안정성을 높이고, 중요한 구성 요소에 대한 보호를 추가하고, 대안을 제거하고, 서비스 가용성을 최적화하고, 철저하게 테스트하는 변경은 좋은 변경입니다.
10. 더 싼 것이 항상 좋은 것은 아니다
저렴하다고 항상 좋은 것은 아닙니다. 저렴한 솔루션은 일반적으로 가격표가 더 낮지만 이상적이지 않은 여러 제한 사항이 있을 수도 있습니다. 더 낮은 가격표가 있는 경우 애플리케이션 인식 부족, 제한된 오케스트레이션, 숨겨진 복잡성, 수동 복구 및 장애 조치 , 사용자 검증이 없는 것으로 제한됩니다. 저렴한 솔루션에는 고객 지원이 포함되지 않을 수도 있습니다. 더 저렴한 솔루션에 지원이 포함되는지 또는 지원이 추가 및 상당한 애드온 비용인지 이해해야 합니다.
컴퓨팅, 디스크 또는 스토리지가 감소된 저렴한 배포에도 동일하게 적용됩니다. 가격표와 월별 비용이 더 낮을 수 있지만 솔루션이 이상적인 용량보다 적게 작동할 수도 있습니다.
11. 시끄러운 것은 효과적이지 않다
늑대 우는 소년의 이야기를 들어본 적이 있습니다. 경고 폭풍을 생성하는 애플리케이션 모니터링 솔루션은 나중에 무시되는 솔루션입니다. 경고를 제공하는 솔루션을 갖는 것은 좋지만 해당 솔루션이 오류 또는 초과로 중요한 경고를 트리거하면 효과가 없습니다.
12. 고가용성은 단순한 제품이나 하드웨어 솔루션이 아닌 문화이자 사고방식입니다.
소프트웨어, 하드웨어, 프로세스, 솔루션 및 서비스는 모두 고가용성의 일부입니다. 그러나 IT 기능 및 사업부 전반에 걸친 동의 없이는 가치, 비즈니스 안정성, 고객 만족도 향상 및 위험 감소에 대한 논의 대신 좌절감과 계속해서 예산 논의의 원천이 될 것입니다.
13. 아직 늦지 않았다
희망은 고가용성을 위한 전략이 아니며 치명적인 재해나 애플리케이션 오류가 발생하지 않기를 바라는 것도 전략일 필요가 없습니다. 고가용성 엔터프라이즈 아키텍처를 설계하고 설계하는 것은 마지막 재해 이후 몇 주 또는 몇 달이 지난 경우에도 가능합니다.
SIOS에 문의 에 대해 자세히 알아보기 고가용성 솔루션 당신의 신청을 위해.
– Cassius Rhue, VP, 고객 경험 재현 시오스
