클라우드로 마이그레이션 하시겠습니까? 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, 고객 경험