비교적 복잡한 인프라에서 AWS EC2 인스턴스 그룹의 자동 크기 조정을 올바르게 수행하는 방법은 무엇입니까?

Question

Amazon Cloud에서 서버를 마이그레이션하기 위해 노력하고 있습니다. 이유는 자동 확장 가능성, 비용, 서비스 등입니다.

지금까지 열심히 실험하고 있으며 모든 기능을 갖춘 문서로 다이빙을 시도했지만 이전 경험이 없으므로 많은 질문이있었습니다. 다시 보내드립니다 내부 탄성로드 밸런서로 트래픽을 보낼 것이다, 바니시 인스턴스에 트래픽을 보낼 것이다

즉

        +-----+ 
            | ELB | 
            +--+--+ 
            | 
       +--------------------|--------------------+ 
       |   Auto-Scaling Group   | 
       |--------------------|--------------------| 
       |     |     | 
       | +---------+  |  +---------+ | 
       | | varnish |<------+------>| varnish | | 
       | +----+----+    +---------+ | 
       |  |       |  | 
       +-----------------------------------------+ 
         |       | 
         |       | 
         |  +------------+  | 
         +---->|Internal ELB|<-----+ 
           +------+-----+ 
            | 
       +-----------------------------------------+ 
       |   Auto-Scaling Group   | 
       |-----------------------------------------| 
       | +---------+  |  +---------+ | 
       | | Apache |<------+------>| Apache | | 
       | +----+----+    +----+----+ | 
       |  |       |  | 
       +-----------------------------------------+ 
         |   +-----+   | 
         +-------->| RDS |<--------+ 
            +-----+ 

, 내가 가진 것 탄성로드 밸런서 :

예견된 인프라는 다음과 아파치 프론트 엔드에 대한 트래픽.

지금은 템플릿을 사용하여 인스턴스를 부트 스트랩 할 수있는 CloudFormation 서비스와 같은 AWS 도구를 발견했습니다.이 방법은 훌륭하게 보이지만 부트 스트랩 만 가능합니다.

Puppet에 약간의 경험이 있고 (주제에 대한 AWS 권장 사항이 주어짐) 나는 꼭두각시 인물을 비웃었습니다.이 도구는 훌륭한 도구입니다.

실용적이지 않거나 사실적이지 않은 아이디어는 CloudFormation 템플릿을 사용하여 "퍼핏 노드 스택"을 만드는 것입니다.이 템플릿은 필요한대로 인스턴스를 구성하고 프로비저닝 할 퍼핏 마스터를 연결합니다. 내가 스택 준비하면

, 내가 구성하는 방법 를 궁금하네요/모두 Varnish 및 Apache 인스턴스에 대한 자동 스케일링 그룹을 만듭니다.

CFN에 자동 크기 조정 그룹 & 정책을 구성하는 리소스가있는 것 같습니다. 그래서 각각에 대해 서로 다른 두 개의 템플릿을 만들 수 있습니다.

하지만 AS 기능을 통해 CFN 서비스를 실행 한 다음 모든 초기화 작업을 수행하고 user-data을 실행합니까?

또한 꼭두각시가 EC2 태그를 사용할 수 있다는 것을 읽었습니다. 해당 태그 (역할과 같은)가있는 일반적인 스택 템플릿이 트릭을 수행 할 수 있습니까?

이 아키텍처는 현실적이고 실용적입니까? 의견이 있으십니까?

귀하의 조언에 감사드립니다.

Answer 1

자동 크기 조정은 실행 구성을 기반으로 새 노드를 만듭니다. 따라서 두 개의 별도 자동 실행 그룹과 두 개의 개별 실행 구성이 필요합니다. ie

"VarnishScalingGroup" : { 
    "Type" : "AWS::AutoScaling::AutoScalingGroup", 
    "Properties" : { 
    "LaunchConfigurationName" : {"Ref" : "VarnishLaunchConfiguration" }, 
    "LoadBalancerNames" : {"Ref" : "ELB"}, 
    ... 
    } 
}, 
"VarnishLaunchConfiguration" : { 
    "Type" : "AWS::AutoScaling::LaunchConfiguration", 
    "Properties" : { 
    ... 
    "UserData" : { 
     .... 
    }, 
    "MetaData" : { 
     ... 
    } 
}, 
"ApacheScalingGroup" : { 
    "Type" : "AWS::AutoScaling::AutoScalingGroup", 
    "Properties" : { 
    "LaunchConfigurationName" : {"Ref" : "ApacheLaunchConfiguration" }, 
    "LoadBalancerNames" : {"Ref" : "InternalELB"}, 
    ... 
    } 
}, 
"ApacheLaunchConfiguration" : { 
    "Type" : "AWS::AutoScaling::LaunchConfiguration", 
    "Properties" : { 
    ... 
    "UserData" : { 
     .... 
    }, 
    "MetaData" : { 
     ... 
    } 
} 

다른 옵션은 각 스케일링 그룹에 대한 별도의 확장 정책과 해당 CloudWatch 메트릭을 일치시키는 것입니다.

CloudFormation도 스택에 대한 업데이트를 시작할 수 있습니다. cfn-hup의 사용자 데이터의 일부로 스택 메타 데이터의 변경 사항을 주기적으로 확인한 다음 원하는대로 실행합니다. cfn-init의 다른 버전을 시작하는 경향이 있습니다. cfn-init은 메타 데이터를 구문 분석하고 업데이트합니다.

요점 - cfn-hup 경로 아래로 이동하면 이은 사용자 데이터를 다시 실행하지 않습니다. 단, CloudFormation 스택을 삭제하고 새 인스턴스를 생성해야합니다.

LaunchConfiguration이 롤아웃되도록 업데이트하려면 LaunchConfiguration에도 UpdatePolicy가 적용되어 있어야합니다.

Answer 2

"퍼핏 노드 스택"대신에 패커가있는 기계를 프로비저닝하고 AMI를 생성 할 수있는 패커 (http://www.packer.io/)와 같은 도구를 사용하여 AMI를 미리 빌드하는 것이 좋습니다. 그런 다음 프로비저닝 된 AMI를 클라우드 정보 템플릿에 추가하십시오.

피터 H.가 말한 것처럼, 구름 정보는 스택에 대한 업데이트를 처리 할 수 ​​있습니다. 따라서 꼭두각시 설정을 변경하면 새로운 AMI를 구축하고 실행 구성을 클라우드 정보로 업데이트 할 수 있습니다. 자동 확장은 새로운 인스턴스 자동 조정을 위해 새로운 AMI를 사용하여 시작됩니다.

인형을 clouduing에서 가져 오면 인프라와 서버 구성 사이에 관심이 따로 있습니다.

이미 Apache/Varnish 설정이되어있는 사전 빌드 된 AMI로 확장이 빨라집니다.

마스터없는 인형 설정에도 장점이 있습니다. 즉. 분산 형, 실패 지점으로 puppetmaster가없는 등을 참조하십시오. https://serverfault.com/questions/408261/pros-and-cons-of-a-decentralized-puppet-architecture