애플리케이션 가용성 문제가있는 9 가지 신호

"문제를 인식하는 것이 문제 해결의 첫 번째 단계"라는 말을 들어 보셨을 것입니다. 그러나 놀랍게도 많은 중소기업 및 놀랍게도 대기업에서도 애플리케이션 가용성이 당연한 것이 아니라는 사실을 인식하지 못하고 있습니다.

여전히 애플리케이션 가용성 문제가 있음을 나타내는 다음 9 가지 징후를 읽으십시오.

1. 응용 프로그램을 사용하는 것보다 다시 시작하는 데 더 많은 시간을 소비합니다.

응용 프로그램 충돌은 일상적인 일이 될 수 있지만 응용 프로그램이 작동 중보 다 자주 중단되면 문제가됩니다.

2.받은 편지함 또는 제어 센터에서 경고 폭풍을 통해 일시 중지하기 시작했습니다.

애플리케이션 또는 서버 다운 타임에 대한 경고를 배포했지만 경고 폭풍으로받은 편지함이 너무 많아서 모두 무음 처리했습니다.

3. 모든 중요한 작업을위한 하나의 데이터 센터가 있습니다.

운영을위한 단일 데이터 센터는 편리하게 들릴 수 있지만 의도는 좋지만 방향이 잘못된 건설 직원 한 명이 단일 데이터 센터를 비용이 많이 드는 비가 용 영역으로 전환하는 것으로 알려져 있습니다.

4. 데이터 보호에 대한 귀하의 아이디어에는 백업 검색 및 아카이브가 포함됩니다.

데이터 보호 전략이 중요합니다.데이터 복제 기술 및 사이트 간 복제, 지역 간 복제가 중심이되었으므로 복제 또는 데이터 보호 전략이 존재하지 않거나 저장소에 대한 긴 조그가 포함 된 경우 큰 문제가 될 수 있습니다.

5. 복구 절차에는 항상 수동 개입이 필요합니다.

수동 개입 자체는 문제가되지 않습니다. 일부 이벤트는 너무 어렵고 복잡하여 어느 정도의 수작업이 필요할 수 있습니다.그러나 수동 개입이 항상 서버 또는 애플리케이션 중단 후 비즈니스의 첫 번째, 두 번째 및 세 번째 순서라면 문제가됩니다.

6. RTO는 몇 시간 또는 몇 분이 아닌 일 단위로 측정됩니다.

RTO (복구 시간 목표)를 어떻게 측정하고 있습니까? RTO를 한 달에 몇 분이 아닌 며칠 또는 몇 시간으로 측정합니까?사실 모든 비즈니스에는 RTO에 대한 허용 수준이 있습니다.그러나 RTO는 아키텍처의 서버 재 구축 및 전체적인 불안정성의 기능이되어서는 안됩니다.

7. 대기 상태가 안정적으로 동기화되지 않기 때문에 RPO를 모릅니다.

애플리케이션의 안정적인 모니터링 및 복구 확인란을 선택하고 한 단계 더 나아가 대기 클러스터 지원 시스템을 제공했습니다.잘 했어.하지만 해결하기 전에 RPO (복구 지점 목표)는 무엇입니까? RPO는 "0 일차와 어제 밤 사이의 어딘가"보다 더 정확한 것이어야합니다.

8. 단일 실패 지점은 단순히 존재하는 것이 아니라 표준입니다.

단일 실패 지점은 어디에 있습니까?예산으로 모든 단일 장애 지점을 제거 할 수는 없지만 모든 주요 범주와 기업의 모든 중요 구성 요소에서 단일 장애 지점을 식별 할 수 있다면…

9. 귀하의 마지막 재난이 지역, 지역 또는 전국 뉴스를 만들었습니다.

마지막 주요 폭풍, 그리드 장애 또는 장애 이벤트로 인해 다운 타임으로 인해 비즈니스에 문제가 발생한 경우 다음 비즈니스 순서는 더 높은 가용성입니다.

다운 타임은 고객, 생산성 및 마음의 평화 측면에서 비즈니스에 손실을줍니다.해결되지 않은 위험은 비즈니스와 평판에 확실한 영향을 미칩니다.이러한 경고 서명이 있으면 가용성 문제가있을 수 있습니다.그리고이를 무시하면 곧 더 큰 문제가 발생할 수 있으므로 애플리케이션 가용성이 중요합니다.

— Cassius Rhue, VP, 고객 경험

애플리케이션을 호스팅하기 위해 클라우드로 전환하는 회사는 애플리케이션 호스팅을 Amazon Web Services와 같은 타사 클라우드 공급 업체에 아웃소싱했지만 일반적으로 애플리케이션 성능 모니터링을 통해 해당 애플리케이션을 직접 모니터링하고 관리해야한다는 점을 이해합니다. 솔루션 또는 APM. 어제의 클라이언트-서버 컴퓨팅 애플리케이션 인 I.T. 부서는 서버, 네트워크 및 최종 사용자 컴퓨팅 환경을 거의 완벽하게 제어했습니다.하지만 오늘날의 클라우드 환경은 더 복잡 해져서 제어 할 수없는 움직이는 부분이 더 많습니다.

일부 회사는 디지털 전환에 착수하여 고객 상호 작용을 중요한 웹 기반 애플리케이션으로 밀어 넣었습니다.이제 APM 자동화 솔루션을 통해 모든 애플리케이션 성능 및 다운 타임 문제에 신속하게 대응하는 것이 그 어느 때보 다 중요합니다.

APM 솔루션을 선택하는 방법

많은 회사에서 AppDynamics, Datadog, Dynatrace 또는 New Relic과 같은 애플리케이션 성능 관리 솔루션을 사용합니다.APM 솔루션은 코드에서 성능 병목 현상을 식별하고 사용자가 영향을 받기 전에 이러한 문제를 해결하는 데 도움이됩니다.

좋은 APM 솔루션은 어떤 일이 일어 났는지, 왜 그런지, 그리고 미래에 이런 일이 발생하지 않도록 방지하는 방법을 알려줍니다.APM 솔루션은 모니터링중인 애플리케이션 또는 시스템이 특정 조건 (부하, 응답 시간 등)을 충족 할 때 경고합니다.경고를 받으면 응용 프로그램이 제대로 작동하지 않는 이유를 식별 할 수 있어야합니다.이 정보로 무장하면 개발 팀이 문제를 해결하고 향후 문제가 발생하지 않도록하는 매우 상세한 진단을 제공 할 수 있습니다.

그러나 올바른 애플리케이션 성능 모니터링 솔루션 솔루션을 어떻게 선택합니까?Google에서 "클라우드 APM 솔루션"을 빠르게 검색하면 5,830,000 개의 결과가 반환됩니다!공간에 익숙하지 않은 사람에게는 압도적 일 수 있습니다.고맙게도 또 다른 Google 검색은 귀하에게 적합한 APM 솔루션을 선택하는 방법에 대한 많은 조언과 리소스를 제공합니다.요구 사항을 구성하고 이러한 요구 사항을 충족하는 짧은 선택 목록을 개발하는 데 도움이되는 타사의 비 공급 업체 조언을 찾아야합니다.Gartner는이 카테고리를 한동안 지켜보고 있으며 매년 APM Magic Quadrant를 게시합니다.애플리케이션 성능 모니터링 솔루션 솔루션을 평가하는 방법을 이해하고 최고 공급 업체에 대한 좋은 개요를 제공하는 방법을 이해하는 데 유용한 리소스입니다.

수정 요구 사항 목록에 APM 자동화 추가

여기 SIOS Technology Corporation에서는 애플리케이션을 클라우드로 마이그레이션하는 고객과 항상 협력하고 있습니다.그들은 종종 불필요한 다운 타임으로부터 애플리케이션을 보호하는 방법을 알고 싶어하고 저희에게 조언을 요청합니다.애플리케이션을 보호하는 방법의 선택은 해당 애플리케이션의 중요도에 따라 결정됩니다 (더 중요한 애플리케이션에는 종종 장애 조치 솔루션 등이 필요함). 그러나 우리는 또한 그들의 애플리케이션이 취약한 이유를 이해하도록 도와줍니다.

이전에는 백업 및 데이터 보호가 별도의 기능이었습니다 (APM 솔루션이 다운 타임을 식별 한 경우에만 필요했던 기능).그러나 오늘날의 복잡한 클라우드 환경에서는 조직이 중요한 애플리케이션을 모니터링하고 관리 할 때 전체적인 접근 방식을 찾아야한다고 생각합니다.기존 APM 솔루션이 문제가 발생하는시기를 식별하고 그 원인을 진단 할 수있게 해준다면 가능한 경우 불필요한 다운 타임을 방지하지 못하는 이유는 무엇인가요?

자동화는 대부분의 클라우드 APM 솔루션에서 누락 된 요소라고 믿습니다.많은 고객이 APM 솔루션에서 너무 많은 경고를 수신하여 어떻게 압도 당하고 있는지 알려주며, 각각은 중단하고 발생한 일과 이유를 이해해야합니다.그들은 무엇을 무시하고 무엇에주의를 기울여야하는지 빠르게 이해합니다 (그리고 좋은 APM 솔루션은 기계 학습을 통해이를 수행하는 데 도움이됩니다).또한 애플리케이션이 다운되면 APM 솔루션은 다운 타임에 대해 경고하고 다시 발생하지 않도록 도와야하는 이유를 진단합니다.그러나 APM 솔루션은 즉각적인 다운 타임을 줄이지 않습니다.

이것이 바로 SIOS AppKeeper가 등장하는 곳입니다. AppKeeper는 Amazon EC2에서 실행되는 고객의 애플리케이션을 모니터링하고 EC2에서 서비스를 자동으로 다시 시작하거나 가동 중지 시간이 감지되면 EC2 인스턴스를 재부팅합니다.Amazon EC2 인스턴스가 3 개 뿐인 평균 고객은 적어도 한 달에 한 번 다운 타임을 경험합니다.이는 중요하고 종종 고객을 대상으로하는 애플리케이션을 사용할 수없는 경우와 I.T. 팀은 모든 것을 버리고 대응해야합니다.

AppKeeper의 APM 자동화 솔루션은 고객이 Amazon EC2 다운 타임 상황의 85 % 이상을 자동으로 복구 할 수 있도록합니다.AppKeeper가 작동하는 모습을보고 싶다면 빠른 동영상 링크가 있습니다.

AppKeeper의 API를 통해 고객은 APM 솔루션의 알림이 AppKeeper를 트리거하여 영향을받는 Amazon EC2 서비스를 자동으로 다시 시작하거나 필요한 경우 인스턴스를 재부팅하도록함으로써 APM 솔루션의 가치를 프로그래밍 방식으로 확장하고 있습니다.

애플리케이션 성능 모니터링 및 자동화 된 수정.땅콩 버터와 젤리보다 낫습니까?

대부분의 경우 AppKeeper 고객은 Amazon EC2 인스턴스가 8 개 미만인 Amazon EC2 환경을 쉽게 관리 할 수 있습니다.이들에게는 AppKeeper의 기본 모니터링 및 자동화 된 치료 기능으로 인해 다운 타임이 발생하는 경우 사전에 감소하고 있음을 알기 때문에 밤에 푹 잠들 수 있습니다.

그러나 우리는 많은 고객이보다 정교한 클라우드 환경을 보유하고 있으며 New Relic, Datadog, Dynatrace, LogicMonitor 또는 Zabbix와 같은 APM 솔루션에 이미 투자 한 것으로 알고 있습니다.그들은 무슨 일이 일어 났고 왜 일어 났는지 진단하는 데 도움이되는 즉각적인 경고와 풍부한 데이터 세트를 기대하게되었습니다.이 고객들은 APM 툴킷에 AppKeeper의 자동 치료 기능을 추가함으로써 애플리케이션 성능 제어와 다운 타임 감소라는 두 가지 장점을 모두 누릴 수 있다고 생각합니다.

향후 몇 개월 동안 SIOS Technology는 여러 주요 APM 공급 업체와 협력하여 APM 솔루션과 AppKeeper 간의 패키지 및 인증 통합을 제공 할 것입니다.이러한 AppKeeper와의 통합을 사용하면 이러한 사용자는 이제 폐쇄 루프 시스템을 즐길 수 있으며, 여기에서 감지 된 Amazon EC2 다운 타임과 AppKeeper가 취한 교정 조치에 대한 알림을 받게됩니다.

그러니 흥미로운 소식을 기대해주세요.한편, SIOS AppKeeper를 직접 사용해보고 싶다면 AppKeeper 14 일 무료 평가판에 자유롭게 등록하세요. AppKeeper는 인스턴스 당 월 40 달러부터 시작합니다.

SIOS의 허가를 받아 복제