애플리케이션을 호스팅하기 위해 클라우드로 전환하는 회사는 애플리케이션 호스팅을 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의 허가를 받아 복제

비즈니스 크리티컬 애플리케이션을위한 고 가용성 보호를 위해 SIOS Protection Suite (Linux 또는 Windows 용) 또는 SIOS DataKeeper Cluster Edition이 필요합니다.

제외

1. 무료 솔루션 만 선호합니다.

알겠습니다. 새로운 기술을 배우고, 빠른 팁을 얻거나, 몇 파운드를 줄이거 나, 빠른 데모를 설정해야 할 때 똑같은 일을 할 때가 있습니다. 구독을 신청하거나 라이선스를 구입하거나 둘을 조합하여 투자하는 대신 무료 경로를 택했습니다.

그러나 그 말은 종종 사실이며, 당신은 당신이 지불하는 것을 얻습니다. 무료 평가판은 괜찮습니다. 영구적으로 무료로 제공되는 고 가용성은 주유소 초밥과 같습니다. 위험이 정말로 가치가 있습니까? 무료로 인해 가동 시간을 최적화하고 가용성을 높이는 데 사용할 수있는 모든 기능을 사용할 수 없습니다. 미션 크리티컬 애플리케이션을 보호하는 것으로 입증 된 합리적인 가격의 고 가용성 솔루션을 넘기고 있지 않은지 확인하세요.

2. 단일 솔루션 숍 솔루션이되는 것이 HA 요구 사항을 충족하는 것보다 더 중요합니다.

우리는 수십 년 동안“Ford tough”가족이었습니다. 진지하게. 하나의 솔루션 샵이되는 것이 어떤 것인지 이해합니다. 우리 아버지는 업무용 포드 트럭, 레저 용 포드 머스탱, 농장 용 포드 3600 트랙터, 가족 여행용 포드 미니 밴을 소유하셨습니다. 파란 타원이 새겨진 모형 장난감 자동차를받는 계절도있었습니다.

하지만 제 아내와 제가 가족의 필요 사항을 해결하려고 할 때, 우리는 Ford 조타실 (당시)에서 떨어진 요구 사항을 해결하기 위해 단일 솔루션에서 탈피했습니다. 단일 상점 구매자 일 수 있지만 요구 사항이 변경되고 HA 공급자 또는 솔루션이 따라 가지 못한 경우 솔루션 집합을 확장하여 위험을 제거할지, 성공을 개선할지, 아니면 보완 솔루션에 투자 할 가치가 있는지 고려하십시오. 새로운 요구. 우리 가족을 위해 안정적이고 가스 효율적이며 세련되고 가족 친화적이며 경제적 인 솔루션이 필요했을 때, 우리는 Honda Odyssey로 Ford tough를 보완했습니다. 당신이 원 스톱 샵이고 벤더 종속에 대해 걱정하지 않는다면 행운을 빕니다.

3. 당신은 스스로하는 일에 더 가깝습니다.

당신은 코딩을 좋아합니다. 많은 스크립트를 작성하는 것을 좋아하고 bash, ksh, perl, python, powershell, 배치 또는 명령 도구 키트를 꺼내서 직접 연결하는 것을 신경 쓰지 마십시오. 유연성과 자신의 조정을 추가하는 즐거움을 중요하게 생각합니다.

저도 코드 작성을 좋아하지만, 해결되고 입증 된 문제에 대해 많은 코드와 스크립트를 작성하는 데 시간을 할애하는 것이 마지막으로 할 때가 있습니다. DIY (Do-it-Yourself) 관리자에게는 기성품이 선호되지 않을 수 있지만 20 년의 전문 지식과 경험을 기업에 맞게 재 설계하고 재구성해야하는지 고려하십시오. 그러나 코드 작성 수정 사항을 가져와야하는 경우 고 가용성 소프트웨어 SIOS는 코딩 수정 사항을 얻을 수있는 일반 애플리케이션 복구 키트를 제공합니다.

4. Ubuntu 지원 (또는 Solaris)이 필요합니다.

당신의 환경은 독특합니다. Solaris에서 이빨을 잘 랐고 소중한 삶을 위해 매달리는 고객이 있습니다. 또는 Linux 영역을 완전히 수용하고 Ubuntu로 이전 한 사람들이 있습니다. 두 경우 모두 SIOS 제품 매트릭스를보고 Ubuntu는 현재 SIOS 버전과 일치하지 않습니다. 부머!

이것이 사실이지만 여전히 사용 가능한 풍부하고 방대한 지원 기능과 풍미를 고려하십시오. Solaris 및 Ubuntu 및 Linux의 최신 변형을 수용하기 위해 경쟁 한 기업의 일부가 있지만 RHEL, OEL, SuSE, CentOS 및 Windows를 다음과 같이 지원할 수있는 솔루션이 필요할 가능성이 높습니다. 잘. 고 가용성 솔루션이 제공하지 않는 부분을 골라 내지 말고 기능의 깊이를 고려하십시오.

5. 환경에서 하이브리드를 실행하지 않습니다.

지난주 영화 중간에 들었어요. 주인공은 지나치게 흥분한 주인의 새로운 아이디어로 앞으로 나아갈 생각에 대해 언급했습니다. 고전적인 표현 : "때때로 주스는 짜낼 가치가 없습니다." 당신은 하이브리드 환경을 실행하고 있지 않다고 생각합니다. 애플리케이션은 중요하지만 복잡하지는 않습니다. 움직이는 부분은 데이터베이스, 프런트 엔드 및 지원 응용 프로그램으로 간단합니다. 추가 프로세스, 제품, 솔루션 또는 서비스로 일을 "복잡하게"하고 싶지 않을 수 있으며, 주스가 그만한 가치가 없다고 느낄 수 있습니다.

고 가용성 소프트웨어에 대한 최종 결정을 내리기 전에 비 하이브리드 환경이 단순 환경과 동일한 지 평가하십시오. 움직이는 부분이 상상만큼 간단한 지 또는 장애 조치 오케스트레이션이있는 솔루션이 전체 RTO를 줄이고 RPO를 늘리는 데 도움이 될지 고려하십시오.

6. HA 전문가의 보증과 경험은 중요하지 않습니다.

4 월 중순에 온라인으로 헤드폰을 구입했습니다. 생각했듯이 누구나 블루투스 헤드폰을 할 수 있다는 것을 알게되었습니다. 그러나 모든 사람이 잘 할 수있는 것은 아닙니다. 인체 공학적으로 "신제품"헤드폰은 악몽입니다. 페어링은 매우 쉬웠지만 우발적 인 페어링 해제는 끊임없는 싸움입니다. 음질은 놀랍지 만, 시스템 사운드 나 노래 끝에서 헤드폰이 크고 선명하게 무작위로 울리면 내 성가심이 증폭됩니다.

고 가용성 및 애플리케이션 모니터링은 누구나 수행 할 수 있으며 그 경험은 중요하지 않다고 생각할 수 있습니다. 그러나 자신의 경험과 저의 경험을 고려하고 하이브리드 환경의 복잡성 또는 가장 많이 사용하는 애플리케이션에 필요한 종속성 및 애플리케이션 중심 지식에 대해 방금 생각하기 시작한 그룹에 대해 엔터프라이즈 환경을 신뢰하고 싶은지 물어보십시오. 자주.

환경에 적합한 고 가용성 소프트웨어를 결정할 때 동급 최고의 기능, 강화되고 테스트 된 솔루션, 지식이 풍부한 전문가, 광범위한 지원 애플리케이션 및 환경, 업계 최고의 경험과 수십 년간의 통찰력없이 사용할 것인지 신중하게 고려하십시오. . 그런 다음 신중하게 고려한 후 현명하게 선택하십시오.

-Cassius Rhue, SIOS 고객 경험 담당 부사장

Amazon EC2에서 호스팅되는 WordPress 사이트의 가동 중지 시간 줄이기

SIOS AppKeeper로 무지에서 행복으로

WordPress는 수백만 회사에서 웹 사이트, 블로그 또는 앱을 만드는 데 사용하는 오픈 소스 콘텐츠 관리 시스템 (CMS)입니다.추정에 따르면 오늘날 WordPress를 사용하는 웹 사이트는 7,500 만 개가 넘고 많은 회사가 Amazon EC2에서 WordPress 인스턴스를 호스팅하기 시작했습니다. 사용자는 유연성과 레이아웃을 쉽게 만들고 수정할 수있는 WordPress를 좋아합니다.웹 사이트에 WordPress를 사용하고 있다면 좋은 회사에 있습니다.

많은 사용자가 WordPress에 의존하여 웹 사이트를 강화하고 있으므로 해당 사용자의 요구를 충족하도록 설계된 다양한 타사 도구 (플러그인 및 서비스)가 있다고 상상할 수 있습니다.이러한 플러그인 중 일부는 취약점을 조사하는 스캐너와 같은 보안 기능을 추가하기위한 것입니다.더 많은 플러그인이 더 많은 취약점을 유발할 수 있기 때문입니다.

신뢰하지만 확인하십시오.WordPress 가동 시간 모니터링이 중요한 이유.

제대로 모니터링하지 않고 WordPress에서 실행되는 웹 사이트 또는 응용 프로그램을 배포하는 것은 차 안에 키를 넣은 채 외부에서 실행되는 것과 같습니다.투자를 보호하고 싶을 것입니다.WordPress 사이트 (또는 해당 문제에 대한 모든 애플리케이션)를 관리하는 회사의 경우 모니터링해야하는 세 가지 주요 이유가 있습니다.

1. 방문자를 이해하고 경험을 최적화하기 위해
2. 사이트 속도를 모니터링하고 예상 서비스 수준 계약 (SLA)을 충족하는지 확인합니다. 과
3. 가동 시간을 극대화합니다.다운 타임은 WordPress에서 실행되는 모든 전자 상거래 사이트에서 (심각한) 수익 손실을 의미 할 수 있습니다.

WordPress 사이트가 제대로 작동한다고 생각하지만 실제로 무슨 일이 일어나고 있는지 알고 싶습니다.모니터링의 목표는 진행 상황과 이유를 빠르게 파악하여 문제에 신속하게 대응할 수 있도록하는 것입니다.

WordPress 사용자가 사이트를 모니터링하는 데 도움이되는 다양한 도구가 있습니다.일부는 ManageWP 및 JetPack과 같은 WordPress에 매우 중점을 두는 반면 다른 일부는 다양한 CMS 및 응용 프로그램에 적용되는 산업 표준 솔루션입니다.일부는 "심층"하여 Google Analytics 및 방문자 분석에 중점을 둔 모니터링과 같은 모니터링의 한 요소에 초점을 맞추고있는 반면, 다른 일부는 "광범위하게"모니터링의 세 가지 주요 측면을 모두 해결하려고합니다.사용하기로 결정한 것은 예산, 요구 사항 및 기술 능력에 따라 다릅니다.

여기 SIOS에서는 최상의 접근 방식이 타당하다고 믿습니다.우리는 응용 프로그램을 모니터링하고 해당 응용 프로그램에 대한 고객의 가동 중지 시간을 최소화하는 데 중점을 둡니다.오늘날 많은 고객이 SIOS AppKeeper를 사용하여 Amazon EC2에서 실행되는 WordPress 사이트를 모니터링하고 보호하고 있습니다.

SIOS AppKeeper – WordPress 사이트를위한 간단하지만 강력한 모니터링 및 자동 치료

많은 WordPress 모니터링 솔루션 (무료 플러그인에서 저렴한 부분 유료 서비스에 이르기까지)은 WordPress 사이트가 다운되면 알려줍니다.모니터링 솔루션의 정교함 (및 비용)에 따라 WordPress 사이트가 다운 된 이유를 알 수 있습니다.하지만 다운 타임을 줄이고 서비스를 자동으로 다시 시작하거나 다운 타임이 발생했을 때 인스턴스를 재부팅하는 데 도움이 될까요?

많은 회사가 Apache 또는 NGINX 웹 서버를 사용하여 Amazon EC2에서 WordPress 사이트를 호스팅합니다.SIOS AppKeeper는 Amazon EC2 인스턴스 및 해당 서비스에서 실행중인 WordPress 사이트 또는 애플리케이션을 자동으로 검색 한 다음 다운 타임이 발생하는 경우 자동으로 여러 작업을 수행하도록 구성 할 수있는 SaaS 서비스입니다.따라서 문제가 있다는 알림 만받는 대신 문제가 발생하고 자동으로 해결되었다는 알림을받습니다.

다운 타임이 중요합니다.WordPress를 사용하여 전자 상거래 사이트를 운영하는 경우 다운 타임으로 인해 수익이 손실됩니다.수익은 얼마입니까?연간 수익을 365 일 24 시간 (연간 수익 / 365 / 24)으로 나누면 시간당 수익을 파악할 수 있습니다.2013 년 Google은 5 분 동안 중단되어 수익이 $ 545,000에 달했습니다. 이제 Google이 아닐 수도 있지만 가능한 한 다운 타임을 없애고 싶을 것입니다.

이제 WordPress 사이트가 다운되었다는 경고를 받으면 어떻게되는지 상상해보십시오.즉시 응답 할 준비가 되셨습니까?WordPress 사이트를 백업하고 실행하기 위해 해결해야 할 사항을 알고 있습니까?고객 조사에 따르면 Amazon EC2 인스턴스를 3 개만 사용하는 평균 고객은 적어도 한 달에 한 번 다운 타임을 경험합니다.

SIOS AppKeeper는 Amazon EC2를 모니터링하고 다운 타임에 대해 경고하고 Amazon EC2 서비스를 다시 시작하거나 인스턴스를 재부팅하여 상황을 해결하기위한 조치를 취합니다.

AppKeeper는 고객의 Amazon EC2 다운 타임 문제의 85 % 이상을 자동으로 해결합니다.즉, 모든 것을 삭제하거나 상당한 수익을 잃지 않고도 오류가 식별되고 해결되었다는 알림을받습니다.

오늘날 수백 개의 기업이 AppKeeper를 사용하여 클라우드 환경을 계속 실행하고 있습니다. AppKeeper를 설치하고 사용하는 것이 얼마나 쉬운 지 아래 비디오를 확인하십시오.

비디오 : AppKeeper 설치 및 AWS EC2 실패에서 복구 데모

마음에 드시면 AppKeeper 14 일 무료 평가판에 자유롭게 등록하세요. AppKeeper는 인스턴스 당 월 40 달러부터 시작합니다.

클라우드로 마이그레이션 하시겠습니까? Amazon EC2로 이동할 때 DevOps 우선 순위가 어떻게 변경되어야하는지 다음과 같습니다.

클라우드로 마이그레이션하거나 "클라우드 네이티브"애플리케이션을 만드는 대부분의 회사는 Amazon Web Services (AWS)를 사용하여 마이그레이션하고 있습니다.AWS는 많은 비용 및 기능상의 이점을 제공합니다.온 프레미스 환경을 모니터링하고 관리하기 위해 업계 표준 개발자 운영 ( "DevOps") 모범 사례를 채택한 회사는 종종 새로운 클라우드 환경 및 애플리케이션에 어떻게 적응하는지 스스로에게 묻습니다.

온 프레미스 애플리케이션에서 Amazon EC2로 이동할 때 DevOps 우선 순위가 어떻게 변경됩니까?다음은 둘의 차이점과 유의해야 할 사항에 대한 설명입니다.

클라우드에서의 DevOps 우선 순위?똑같다. 그러나 다릅니다.

AWS로 이전하면 운영이 더 쉬워진다는 고객의 말을 자주 듣습니다. 클라우드 (또는 AWS)로 이동한다고해서 더 이상 애플리케이션을 모니터링하고 관리 할 필요가 없다는 의미는 아닙니다.

Amazon AWS로 이전하는 회사는 하드웨어 조달, 프로비저닝 및 유지 관리와 관련하여 비용과 인력 리소스를 절감 할 수 있습니다.그러나 Amazon EC2에서 애플리케이션을 호스팅하기로 결정할 때 운영 체제 계층 위에있는 모든 것이 귀하의 책임이라는 점을 고려해야합니다.

Amazon EC2 환경에 대한 백업 / 가용성 보장 / 보안 조치 등과 관련하여 우선 순위는 온 프레미스 애플리케이션과 동일합니다. 그리고 Amazon은 몇 가지 기본 도구와 기능을 제공합니다.그러나 요구 사항에 적합한 지 결정해야합니다.

보안, 백업… Amazon AWS 환경을 관리 할 때 무엇을 알아야합니까?

그렇다면 Amazon EC2로 이동할 때 염두에 두어야 할 AWS 관련 고려 사항은 무엇입니까?귀하에게 적합한 도구는 무엇입니까?응용 프로그램을 설계하는 데 초기에 투자 한 시간과 응용 프로그램을 배포 및 관리하는 방법은 성과를 거둘 것입니다.

가장 먼저 고려해야 할 사항은 Amazon EC2 애플리케이션을 보호하는 방법입니다."열어야 할 포트"및 "액세스를 허용 할 위치"와 같은 네트워크 설계는 온-프레미스 애플리케이션과 동일한 방식으로 고려해야합니다.보안 그룹 및 네트워크 ACL (액세스 제어 목록)을 사용하여 AWS에서 구성 할 수 있습니다.

AWS 환경을 자동으로 검사하고 권장 설정으로 설정되었는지 여부를 지적하는 AWS Trusted Advisor 기능 *을 사용하여 회사의 AWS 환경에서 보안 문제를 확인할 수 있습니다.구현 시점과 주기적으로 AWS Trusted Advisor에 확인하는 것이 좋습니다.

보안의 또 다른 필수 측면은 인증 및 액세스 권한 관리입니다.AWS는이 모든 것을 AWS Identity and Access Management (AWS IAM)로 통합합니다.누가 어떤 EC2 인스턴스에 액세스 할 수 있는지 제어하는 것 외에도 AWS IAM을 사용하여 EC2 인스턴스에서 다른 리소스 (예 : DB) 등에 대한 액세스 권한을 설정할 수도 있습니다. AWS로 마이그레이션 한 후 가장 먼저해야 할 일은 AWS IAM에서 계정 및 액세스 제한을 올바르게 설정하는 것입니다.

다음 고려 사항은 "Amazon EC2에서 내 애플리케이션을 어떻게 백업합니까?"입니다. Amazon EC2는 스냅 샷을 생성 할 수있는 기능을 제공합니다.또한 "Amazon Data Lifecycle Manager"를 사용하면 주기적 스냅 샷과 증분 백업을 쉽게 설정할 수 있습니다.스냅 샷 파일은 Amazon S3 스토리지 서비스에 저장됩니다.용량에 따라 요금이 부과되므로 보유한 데이터의 양을 파악하고 "증분 백업으로 용량 줄이기"및 "이전 데이터에서 삭제"와 같은 설정을 지정해야합니다.

"가용성"을 미리 고려해야합니다. 핵심은 시스템의 우선 순위에 따라 시스템을 운영하는 것입니다.

마지막 고려 사항은 가용성입니다.Amazon EC2 애플리케이션과 온 프레미스 애플리케이션의 경우 비용 및 시스템 중요도에 따라 필요한 가용성 수준을 고려해야합니다. 그러나 Amazon의 다중 AZ 배포 기능을 사용하는 경우 서로 다른 데이터 센터간에 중복 구성을 지정할 수 있습니다.그러나 다중 AZ를 사용하는 것은 단일 AZ 구성을 사용하는 것보다 비용이 더 많이 듭니다 (중복 온 프레미스 시스템이있는 것만 큼은 아니지만).애플리케이션을 설계 할 때 다중 AZ가 필요한지 여부와 가용성에 얼마나 투자해야하는지 고려해야합니다.

장애 조치에 투자하지 않는 경우 적어도 애플리케이션을 모니터링하고 다운 타임이 발생할 때 복구 방법을 계획해야합니다. Amazon CloudWatch를 사용하여 CPU, 메모리 및 디스크와 같은 일반 항목을 쉽게 모니터링 할 수 있으며, EC2에서 오류가 발생할 때 인스턴스를 자동으로 복구하도록 Amazon EC2 자동 복구 기능을 프로그래밍 할 수도 있습니다.

애플리케이션이 미션 크리티컬 한 경우 가용성에 더 많은 투자를하고 싶을 것입니다.AWS 커뮤니티에 귀중한 기능을 제공하는 우수한 타사 솔루션을 많이 고려해야합니다.한 가지 선택은 Amazon EC2 인스턴스를 모니터링하고 서비스를 자동으로 다시 시작하거나 시스템 오류가 발생하는 경우 인스턴스를 재부팅하는 구성 및 사용이 간편한 솔루션 인 SIOS AppKeeper입니다.다음은 AppKeeper의 작동 방식에 대한 간단한 비디오입니다.

애플리케이션을 위해 클라우드로 이동하는 것은 의미가 있지만 DevOps 모범 사례를 포기할 수는 없습니다.Amazon AWS는 다양한 기능과 도구를 제공하지만 여전히 애플리케이션의 보안, 백업 및 가용성에 대한 기본 책임을 져야합니다.이를 수행하는 방법은 사용자의 기술과 응용 프로그램 자체의 중요성에 따라 다릅니다.

14 일 무료 평가판에 가입하여 Amazon EC2 다운 타임을 줄이기 위해 AppKeeper를 활용 해 온 수백 명의 고객과 함께하시기 바랍니다.

* 참고 : AWS Trusted Advisor를 사용하려면 비즈니스 지원 이상의 계약이 필요합니다.

SIOS의 허가를 받아 재현

고 가용성 지표 확장

기술 분야에서 우리는 데이터를 좋아합니다. 우리는 데이터에 대한 데이터와 우리 도구가 가져올 수있는 모든 지표와 측정을 좋아합니다. 수천 개의 연결된 장치에서 모든 세부 사항을 캡처하는 제품인 분석을 중심으로 산업을 만들었습니다. 우리는 메트릭과 측정을 좋아합니다. 고 가용성 공간 내의 많은 경우에 우리는 시스템이 장애로부터 얼마나 빨리 복구되었는지 알려주는 고 가용성 메트릭을 좋아합니다. 탐지와 치료 사이의 시간을 계산하고 추적하며 재해, 시스템 장애 또는 디스크 충돌로 인해 손실되는 트랜잭션 데이터의 양을 파악하고 측정하는 데 집착합니다.

아이러니하게도 고 가용성 및 재해 복구 (HA / DR) 시스템에는 충분한주의를 끌지 못하는 몇 가지 메트릭이 있습니다.

다음은 환경을 관리하기 위해 지켜봐야 할 8 가지 다른 고 가용성 지표입니다.

1.  보안 경고

가용성은 단순히 애플리케이션 모니터링 및 복구에 관한 것이 아닙니다.  공개적으로 사용 가능한 시스템은 항상 공격을받습니다.  보안 경고 및 경고를 모니터링하지 않는 경우 애플리케이션은 완벽하게 실행되고 지적 재산은 완벽하게 유출 될 수 있습니다.

2. 유휴 연결

유휴 연결은 무해한 것처럼 들리지만 남쪽 잔디밭에있는 녹색 잎이 많은 칡과 같이 무해합니다.  유휴 연결은 리소스를 차지하고 데이터베이스 풀을 채우고 네트워크를 정체시키고 성능을 저하 시키도록 위협합니다.  또한 유휴 연결은 응용 프로그램 계층 또는 데이터베이스 구성에 문제가 있음을 나타낼 수 있습니다.

삼. 장기 실행 쿼리, 명령 또는 작업

이는 데이터베이스 쿼리 또는 작업뿐만 아니라 명령 및 백업에도 적용됩니다.  오래 실행되는 쿼리, 명령 및 작업은 시스템 상태 불량, 느린 디스크 속도, CPU 또는 기타 리소스 경합 또는 더 심층적 인 시스템, 응용 프로그램 호환성 또는 OS 문제의 지표가 될 수 있습니다.

4. 디스크 IO

디스크 IO는 일반적으로 디스크 활동과 관련된 시스템의 입력 / 출력 작업을 나타냅니다. 디스크 I / O를 측정하면 주어진 워크로드에 대해 병목 현상, 불량한 하드웨어 구성, 부적절한 크기의 디스크 또는 잘못 조정 된 디스크 레이아웃을 식별하는 데 도움이 될 수 있습니다.  디스크 I / O를 모니터링하면 장기 실행 쿼리가 잘못된 SQL 구문의 기능인지, 잘못 코딩 된 애플리케이션인지, 지연 시간 및 액세스 문제인지 알 수 있습니다.

5. 기억

우리 모두는 얼마나 많은 메모리가 사용되는지에 대해 생각하지만 메모리 모니터링은 사용 가능한지 여부를 측정하고 보는 것 이상입니다.  메모리 모니터링은 병목 현상, 누수를 조사하고 부적절한 크기의 시스템을 식별하고로드,로드 평균 및 스파이크를 이해하는 데 도움이됩니다.  또한 메모리 집약적 패턴에 대해 알면 가용성 제품군을 조정하여 잘못된 실패를 방지 할 수 있습니다.

6. 디스크 공간

고객 경험 담당 부사장으로서 저는 한때 긴급 전화를 위해 아침 일찍 깨어 난 불행한 경험을했습니다.  고객은 정전 후 생산 시스템이 다운되었습니다.  시스템을 다시 시작하려고 할 때 보호 된 응용 프로그램이 시작되지 않았습니다.  오류 로그를 빠르게 확인한 후 루트 드라이브가 100 % 찼음을 확인했습니다.  애플리케이션이 파일 시스템에 쓸 수 없습니다.  디스크 공간 모니터링은 다양한 형태와 방식으로 사용할 수 있으며이를 메트릭으로 사용하면 불필요한 문제를 방지하고 추가 비용이 많이 드는 막판 스크램블을 방지 할 수 있습니다. .

7. 오류 및 경고

로그의 오류, 경고 및 복구 메시지는 고려해야 할 또 다른 좋은 지표입니다.  가용성 솔루션은 고객을 온라인 상태로 유지하고 행복하게 만들 수 있지만 조만간주의가 필요한 문제를 가릴 수도 있습니다.  FATAL, PANIC 및 주요 ERROR 메시지에 대한 로그 모니터링을 추가하면 데이터베이스 충돌, 애플리케이션 패닉 또는 코어 덤프 또는 콜드 재시작이 필요한 치명적인 오류와 같이 가용성 솔루션이 자주 복구하는 문제를 식별하는 데 도움이 될 수 있습니다.

8. 복구 번호

오류 및 경고 모니터링과 마찬가지로 복구 번호는 시스템 가용성 상태에 대해 많은 정보를 제공합니다.  매주 평균적으로 두 번 이상의 애플리케이션 복구를 수행하는 경우 정상적인 가용성 보호보다 더 많은 것을 경험하고있을 가능성이 있습니다.  복구를 통해 애플리케이션이나 시스템을 다시 시작했지만 이러한 잘못된 복구 또는 실제 복구 중 너무 많은 것은 정상적이지 않습니다.

모니터링 할 수있는 HA / DR 메트릭 목록과이를 모니터링하는 도구가 급격히 증가하고 있습니다.  귀하와 귀하의 팀이 현재 데이터 캡처 및 분석을 확장하여 가능한 최상의 고 가용성 시스템을 만드는 데 필요한 정보를 포함하도록하십시오.

— Cassius Rhue, VP, 고객 경험