클라우드 마이그레이션이 중단 된 6 가지 이유

점점 더 많은 고객이 클라우드의 유연성, 확장 성 및 성능을 활용하고자합니다. 변화하는 애플리케이션, 솔루션, 고객 및 파트너의 수가 증가함에 따라 마이그레이션이 중단되지 않도록하십시오.

클라우드 마이그레이션이 중단되는 다음 6 가지 이유 방지

1. 불완전한 클라우드 마이그레이션 프로젝트 계획

프로젝트 계획은 프로젝트 성공의 핵심 기여자로 널리 알려져 있습니다. 계획은 프로젝트 단계에서 이해 관계자, 다양한 구현 팀 및 파트너를 안내하는 데 필수적인 역할을합니다. 계획은 원하는 목표를 식별하고, 리소스와 팀을 이러한 목표에 맞추고, 위험을 줄이고, 기한을 놓치는 것을 방지하고, 궁극적으로 클라우드에서 고 가용성 솔루션을 제공하는 데 도움이됩니다.불완전한 계획과 불완전한 계획은 종종 프로젝트 중단의 큰 원인입니다.9 시간에 주요 종속성이 식별됩니다. 예기치 않은 서버 재부팅 중에 애플리케이션 모니터링 및 HA 홀이 식별됩니다 (아래 참조). 클라우드 마이그레이션에 계획이 있는지 확인하고 계획을 실행하십시오.

2. 온 프레미스 오버 엔지니어링

“이것이 우리가 온 프레미스 노드에서 수행 한 방법입니다.”라는 문구가 최근 고객 대화를 시작했습니다. 고객은 클라우드로의 마이그레이션 시도가 중단되었을 때 SIOS 전문 서비스의 프로젝트 관리자 인 Edmond Melkomian과 협력했습니다.발견 세션 중에 Edmond는 온 프레미스 대 클라우드 아키텍처와 관련된 과잉 엔지니어링 된 항목을 발견 할 수있었습니다. 일부 프로젝트의 경우 온 프레미스에서 수행 한 작업을 재현하는 것은 부풀음, 복잡성 및 지연에 대한 이력서가 될 수 있습니다. 아키텍처 및 마이그레이션 계획을 분석하고 특히 네트워킹 및 스토리지를 사용하여 과도하게 엔지니어링 된 구성 요소 및 설계를 무자비하게 제거하십시오.

3. 언더 프로비저닝

비용을 제어하고 무분별한 확장을 방지하는 것은 클라우드 마이그레이션의 중요하고 중요한 측면입니다.그러나 일부 고객은 디스크 및 대역폭에 대한 시간당 요금과 관련 비용에 대해 걱정하는 것이 부족한 프로비저닝의 함정에 빠집니다.이 트랩에서 리소스는 잘못된 속도 특성을 가진 디스크, 잘못된 CPU 또는 메모리 풋 프린트가있는 컴퓨팅 리소스, 잘못된 노드 수가있는 클러스터 등 부적절한 크기입니다.이와 같이 프로비저닝이 부족한 경우 UAT (User Acceptance Test)가 시작되고 예상 / 예상 워크로드로 인해 규모가 작은 리소스에 대한 로그 잼이 발생하면 문제가 발생합니다.또는 대상 노드의 비용 최적화가 장애 조치 시나리오에서 리소스를 제대로 처리 할 수 없습니다. 클라우드에서 가상 머신의 크기를 조정하는 것은 간단한 프로세스이지만 이러한 크기 조정 문제는 종종 설계자와 최고 재무 책임자가 리소스 재 프로비저닝의 영향을 이해하려고하는 동안 지연을 유발합니다.

4. 내부 IT 프로세스

모든 대기업에는 일련의 내부 프로세스가 있으며 팀과 회사도 예외는 아닙니다.IT 프로세스는 일반적으로 클라우드 마이그레이션 전략의 성공에 큰 영향을 미칠 수있는 프로세스 중 핵심입니다. 과거에는 많은 기업들이 입찰, 사이징 가이드, 주문 승인, 서버 준비 및 구성, 최종 배포를 포함한 긴 요청 및 인수 프로세스를 가지고있었습니다.클라우드 프로세스는 무엇보다도 컴퓨팅, 스토리지 및 네트워크 리소스를 획득하고 배포하는 방식을 획기적으로 변경했습니다.그러나 프로세스가 클라우드의 속도를 따라 가지 못한 경우 계획이 변경 될 때 마이그레이션이 중단 될 수 있습니다.

5. 불량한 고 가용성 계획

클라우드 마이그레이션이 중단 될 수있는 또 다른 이유는 고 가용성 계획과 관련이 있습니다. 고 가용성에는 도구 번들 또는 엔터프라이즈 라이선스 이상의 것이 필요합니다.HA에는 신중하고 철저하며 사려 깊은 시스템 설계가 필요합니다.HA 솔루션을 배포 할 때 계획은 용량, 중복성 및 복구 및 수정 요구 사항을 고려해야합니다. 계획을 통해 요구 사항을 적절하게 식별하고, 솔루션을 제안하고, 위험을 고려하고, 배포 및 유효성 검사에 대한 종속성을 관리합니다. 계획이 없으면 프로젝트 및 배포는 위험, 단일 장애 지점 문제, 적합하지 않음, 누락 된 계층 및 애플리케이션 보호 또는 복구 전략 수준에 취약합니다.종종 HA 계획이 부족한 경우 요구 사항이 분류되는 동안 프로젝트가 중단됩니다.

6. 불완전하거나 유효하지 않은 테스트

최종 고객을 클라우드로 마이그레이션하는 파트너 인 Ron은 다가오는 3 일 주말 동안 가동을 계획했습니다. 'go / no-go'의 마지막 결정 지점은 스테이징 서버에 대한 사용자 승인 테스트의 배치였습니다.첫 번째 테스트가 실패했습니다.다른 마이그레이션 문제로 인한 손실 된 시간을 보충하기 위해 Ron과 팀은 최신 OS에서 보안 및 백업 소프트웨어의 최종 컬렉션을 지원 패치와 통합하는 것과 관련된 여러 테스트 사례를 건너 뛰었습니다. 시뮬레이션 된로드는 새로 생성 된 서버에서 처음으로 발생했으며 커널 버그, CPU 및 메모리 프로비저닝 문제, 스토리지 레이아웃 및 용량 문제 등 Ron의 아키텍처 내에서 일련의 문제가 발생했습니다. 이 프로젝트는 고객 신뢰, 적절한 테스트 및 검증, 크기 조정 및 아키텍처를 해결하고 소프트웨어 및 OS 수정 사항을 적용하기 위해 4 주 이상 지연되었습니다.

클라우드의 약속은 매력적이며 잘 계획된 클라우드 마이그레이션을 통해 귀하와 귀하의 팀은 이러한 이점을 활용할 수 있습니다. 클라우드 마이그레이션을 시작하든 중간에 있든이 기사가 일반적인 함정을 더 잘 인식하여 피할 수 있기를 바랍니다.

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

Amazon EC2 모니터링에 Datadog을 사용하십니까? 자동화 된 수정을 위해 SIOS AppKeeper와 페어링

"Datadog이 Amazon EC2 서비스를 모니터링하고 실패를 감지하면 자동으로 다시 시작할 수 있다면 좋을 것 같습니다."라고 생각한 적이 있습니까? 저도 같은 생각을했고 직접 시도해보기로했습니다.

SIOS AppKeeper는 Amazon EC2 인스턴스에서 오류를 자동으로 모니터링하고 인스턴스를 자동으로 다시 시작하거나 오류가 감지되면 서비스를 재부팅합니다."Datadog의 모니터링 기능과 AppKeeper의 자동 치료 기능을 결합하면 어떨까요?"라고 생각했습니다.

효과가 있었고 여기에 내가 한 방법이 있습니다.

이미 Datadog을 사용 중이고 직접 시도해보고 싶다면이 기사의 끝에 등록하여 API에 액세스하십시오.

다음은 Datadog에서 알림을 수신하고 가동 중지 시간이 감지되면 Amazon EC2에서 웹 서버를 다시 시작하도록 AppKeeper를 설정하기 위해 수행 한 단계입니다.

이 실험을 성공적으로 실행하기 위해 Amazon EC2 (Linux 2 사용)에서 실행되는 Datadog 계정, AppKeeper 계정 및 NGINX 웹 서버가 이미있었습니다.

Datadog을 AppKeeper와 통합하여 자동 수정을 제공하는 방법

1 단계 : AppKeeper에서 다시 시작 API 토큰 가져 오기

다음 양식에서 Datadog 통합을위한 API 토큰을 요청하십시오.

https://mk.sios.jp/BC_AppKeeper_Datadog_api_application

양식에서 요청하면 제공 한 이메일 주소로 토큰이 전송됩니다.

2 단계 : AppKeeper에서 테넌트 만들기

다음 단계는 모니터링되는 인스턴스가 속한 AWS 계정을 AppKeeper에 등록하는 것이 었습니다. (AppKeeper는 등록 된 AWS 계정을 "테넌트"라고합니다.)

https://sioscoati.zendesk.com/hc/en-us/articles/900000123406-Quick-Start-Guide#h_39404cfb-4a76-450f-99c2-e197cc63e50d

3 단계 : AWS에서 IAM 역할 생성

그런 다음 AWS에서 IAM 역할을 생성했습니다 (AppKeeper 계정을 설정하는 데 필요함).이 절차에 대해 잘 모르는 경우 다음 안내를 따르세요.

4 단계 : AppKeeper에서 테넌트 추가

다음 단계는 AppKeeper에 "테넌트"를 추가하는 것이 었습니다 (AppKeeper는 AWS 계정을 "테넌트"로 간주 함).다음은이를 수행하는 방법에 대한 자세한 안내 링크입니다.

5 단계 : Datadog에서 합성 테스트 설정

그런 다음 모니터링하려는 Nginx 서버 (EC2 인스턴스)에 대해 Datadog의 개요 모니터링을 구성해야했습니다.방법은 다음과 같습니다.

Datadog 대시 보드를 열고 메뉴에서 UX Monitoring> Synthetic Tests를 선택하십시오.

오른쪽 [New Test]상단 모서리에있는 버튼을 클릭하고 개요 [New API Test]모니터링 사례 생성을 선택합니다.

개요 모니터링 사례를 생성하려면 양식에 다음 정보를 입력하십시오.

1. 요청 유형 선택
   "HTTP"를 선택합니다.
2. 요청 정의 :
   다음 값을 설정하십시오.
   URL : GET http : // {{{EC2 IP 주소}}
   이름 : AppKeeper Datadog 통합 테스트 (모든 이름)
   위치 : 도쿄

삼. 테스트 빈도 지정
변경 없음

4. 어설 션 정의
"새 어설 션"을 클릭하고 다음 값을 설정합니다.

언제 :
[status code]
[is][200]

5. 경고 조건 정의
변경 없음

6.팀에 알리기
변경 없음

6 단계 : Datadog에서 합성 테스트 실행

위의 입력이 완료되면“Create Test”를 눌러 외부 모니터링을위한 테스트 케이스를 생성합니다.

결과가 표시되고 "테스트 결과"섹션에서 웹 서버가 제대로 작동하고 있음을 확인할 수 있습니다.

Datadog을 사용하여 Synthetics 모니터링을 구성하기 위해 수행해야하는 모든 작업입니다.

7 단계 : Synthetics 경고를 받도록 AppKeeper 설정

다음으로 AppKeeper를 알림 대상으로 설정해야했습니다.Datadog 메뉴에서 통합으로 이동하여 통합 탭을 선택합니다.

검색 상자에 "Webhooks"를 입력하여 Webhooks 통합을 찾습니다.

"사용 가능"을 클릭하여 Datadog 계정에서 Webhook 통합을 활성화합니다. (활성화되면 "설치됨"열에 나타납니다.)

"구성"을 클릭하여 Webhook 통합 구성 페이지를 엽니 다.

페이지 하단의 "Webhooks"열에서 "New +"를 클릭하여 새 Webhooks 알림 대상을 만듭니다. 매개 변수에 대해 다음을 입력하십시오.

이름 : 통합 이름 (모든 이름)

URL : https://api.appkeeper.sios.com/v2/integration/ {{AWS 계정 ID}} / actions / recover

페이로드 :

{ “instanceId”:“{{EC2 Instance ID}}”, "이름": "nginx" }

맞춤 헤더 : 체크 박스를 선택하고 다음을 입력합니다.

{ “Content-type”:“application / json”, “accept”:“application / json”, "appkeeper-integration-token": "{{AppKeeper 외부 통합 토큰 가져 오기}}에서 얻은 토큰" }

완료되면 "저장"을 누르십시오.

8 단계 : AppKeeper를 합성 테스트에 연결

다음으로 Synthetics 모니터링 경고가 발생할 때 호출되도록 AppKeeper (등록 된 Webhooks 통합)를 구성해야했습니다.

메뉴의 UX Monitoring> Synthetic Tests에서 "Configuring the Synthetic Monitoring with Datadog"에서 설정 한 테스트 케이스를 엽니 다.

오른쪽 상단 기어 박스에서 "테스트 세부 정보 편집"을 선택하고 "5. Notify Your Team”상자를 눌러 변경 사항을 저장하십시오.

@webhook-{{Datadog의 Webhook 통합 이름}}

※“모니터가 해결되지 않은 경우 다시 알림”을 설정할 수 있습니다.AppKeeper가 처음으로 복구에 실패하면 다시 시도 할 수 있습니다.테스트 목적으로는 필요하지 않지만 (최소 간격)으로 설정하는[10 minutes] 것이 좋습니다.

이제 설치가 완료되었습니다.

9 단계 : 테스트를 다시 실행하여 통합 확인

그런 다음 Datadog이 다운 된 것으로 감지되면 AppKeeper가 웹 서버를 복원 할 것임을 확인했습니다.

UX Monitoring> Synthetic Tests in Datadog에서 방금 설정 한 Synthetics 모니터링 테스트 케이스를 엽니 다.

오른쪽 상단의 "Resume Test"를 클릭하고 Synthetics 모니터링을 켭니다.

이제 Datadog은 정기적으로 Synthetics 모니터링을 수행합니다.

테스트 결과는 서버가 성공적으로 액세스되었음을 보여줍니다.

다음으로 AppKeeper의 자동 수정을 테스트하기 위해 웹 서버의 의사 오류를 생성했습니다.

실제 장애를 일으키기 어렵 기 때문에 서비스를 중단하고 웹 페이지를 볼 수없는 상황을 만들었습니다.이를 위해 SSH를 사용하여 Nginx 서버가 설치된 EC2 인스턴스에 연결하고 Nginx를 중지했습니다.

sudo systemctl stop nginx

잠시 후 Datadog은 웹 서버에 더 이상 액세스 할 수 없음을 감지했습니다.

Datadog의 합성 테스트 페이지에도 테스트 케이스가 실패했음을 표시합니다.

테스트 케이스가 실패하면 Datadog은 Synthetics 모니터링이 실패했음을 AppKeeper에 알립니다.

AppKeeper가 알림을 받으면 자동으로 Nginx를 다시 시작합니다.

따라서 잠시 기다리면 Datadog의 Synthetics 모니터링 검사가 다시 통과되는 것을 볼 수 있습니다.

또한 AppKeeper 대시 보드에 로그인하면 복구가 수행되었음을 알 수 있습니다.

—

이 연습에서는 웹 서버 (Nginx)를 예로 사용하여 Datadog에서 오류를 감지하고 AppKeeper로 서비스를 복원하는 프로세스를 자동화했습니다.

Datadog을 EventBridge 및 Lambda와 통합하거나 사용자 지정 스크립트를 생성하여 유사한 자동화를 달성 할 수 있습니다.

그러나 대상 인스턴스를 자주 추가하거나 다양한 서비스를 다시 시작하면 EventBridge 및 Lambda 또는 스크립트를 유지 관리하는 데 드는 비용과 복잡성이 증가합니다.

AppKeeper는 Datadog과의 입증 된 통합 및 애플리케이션에 대상 인스턴스를 쉽게 추가 할 수 있으므로 DevOps 환경에 자동화를 쉽게 추가하여 다운 타임을 줄일 수 있습니다.

현재 Datadog을 사용 중이고 AppKeeper의 Restart API를 사용해 보려면 먼저 여기에서 14 일 무료 평가판에 가입하세요 (무료 평가판을 설치 한 후 구독을 구매할 수 있음).그런 다음 여기를 클릭하여 무료 평가판을 요청하세요. 프로세스를 안내하고 시작하는 데 도움이되는 무료 평가 토큰을 제공합니다.

평가 토큰 신청

감사합니다.이번 기회에 EC2에서 실행되는 애플리케이션의 자동 모니터링 및 복구를 제공하는 SIOS AppKeeper에 대해 자세히 알아 보시기 바랍니다.

— SIOS 기술 기술팀의 Tatsuya Hirao.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Cassius Rhue, VP, 고객 경험