관리 메뉴

피터의 개발이야기

[DOP-C01] AWS DevOps Engineer Professional : Part 20 본문

AWS/DOP

[DOP-C01] AWS DevOps Engineer Professional : Part 20

기록하는 백앤드개발자 2023. 3. 1. 10:34
반응형

 

  1. EBS 볼륨의 범위는 어떻게 됩니까?
    • VPC
    • Region
    • Placement Group
    • Availability Zone
    설명:

    Amazon EBS 볼륨은 가용 영역에 연결되어 있으며 동일한 가용 영역에 있는 인스턴스에만 연결할 수 있습니다.

  2. DynamoDB 테이블에 쓰는 성능 문제가 발생했습니다. 귀하의 시스템은 시장에서 비디오 게임의 최고 점수를 추적합니다. 가장 인기 있는 게임에서 모든 성능 문제가 발생합니다.

    가장 가능성이 높은 문제는 무엇입니까?
    • DynamoDB의 벡터 시계는 가장 인기 있는 게임에 대한 요청이 급격히 증가하여 동기화되지 않았습니다.
    • 게임 ID 또는 이와 동등한 식별자를 테이블의 기본 파티션 키로 선택했습니다.
    • 게임 ID 또는 이와 동등한 식별자를 테이블의 기본 파티션 키로 선택했습니다.
    • 테이블에 충분한 읽기 또는 쓰기 처리량을 프로비저닝하지 않았습니다.
    설명:

    기본 키 선택은 DynamoDB를 읽거나 쓸 때 성능 일관성에 큰 영향을 미칩니다. 게임의 ID와 연결된 키를 선택하여 DynamoDB가 테이블 파티션에 핫스팟을 생성하고 인기 있는 게임의 기본 키 파티션에 대해 초과 요청을 하도록 했습니다. DynamoDB는 데이터를 저장할 때 테이블의 항목을 여러 파티션으로 나누고 주로 파티션 키 값을 기반으로 데이터를 배포합니다. 테이블과 연결된 프로비저닝된 처리량도 파티션 간에 프로비저닝된 처리량을 공유하지 않고 파티션 간에 균등하게 나뉩니다.

  3. 한 달에 한 번 운영 팀과 만나 지난달 데이터를 검토합니다. 회의 중에 3주 전에 AWS 외부에서 HTTP를 통해 ping하는 모니터링 시스템이 3계층 웹 서비스 API에서 지연 시간이 크게 급증했음을 기록했습니다. 데이터베이스 계층에는 DynamoDB를, 비즈니스 로직 계층에는 ELB, EBS 및 EC2를, 프레젠테이션 계층에는 SQS, ELB 및 EC2를 사용합니다.

    다음 기술 중 발생한 일을 파악하는 데 도움이 되지 않는 것은 무엇입니까?
    • 속도 저하를 초래한 API 호출이 급증한 시점에 CloudTrail 로그 기록을 확인하십시오.
    • CloudWatch 지표 그래프를 검토하여 시스템 속도를 저하시킨 구성 요소를 확인하십시오.
    • S3에서 ELB 액세스 로그를 검토하여 시스템의 ELB에서 대기 시간이 발생했는지 확인하십시오.
    • 로그를 분석하여 해당 시점의 트래픽 급증을 감지합니다.
    설명:
    메트릭 데이터는 2주 동안 사용할 수 있습니다. 해당 기간을 초과하여 메트릭 데이터를 저장하려는 경우 GetMetricStatistics API와 AWS 파트너가 제공하는 여러 애플리케이션 및 도구를 사용하여 데이터를 검색할 수 있습니다.


  4. 다음 중 AWS CloudFormation의 고유 기능이 아닌 것은 무엇입니까?

    • Fn::Split
    • Fn::FindInMap
    • Fn::Select
    • Fn::GetAZs
    설명:

    다음은 내재 함수의 전체 목록입니다. Fn::Base64, Fn::And, Fn::Equals, Fn::If, Fn::Not, Fn::Or, Fn::FindInMap, Fn::GetAtt, Fn::GetAZs, Fn::조인, Fn::선택

  5. AWS CloudFormation의 경우 참인 것은 무엇입니까?
    • SNS를 사용하는 사용자 지정 리소스의 기본 제한 시간은 3분입니다.
    • SNS를 사용하는 사용자 지정 리소스에는 <code>ServiceToken</code> 속성이 필요하지 않습니다.
    • Lambda 및 <code>Code.ZipFile</code>을 사용하는 사용자 지정 리소스는 인라인 nodejs 리소스 구성을 허용합니다.
    • Lambda를 사용하는 사용자 지정 리소스에는 <code>ServiceToken</code> 속성이 필요하지 않습니다.
    설명:

    코드는 AWS Lambda(Lambda) 함수의 소스 코드를 지정할 수 있는 AWS::Lambda::Function 리소스의 속성입니다. Amazon Simple Storage Service(Amazon S3) 버킷의 파일을 가리키거나 소스 코드를 인라인 텍스트로 지정할 수 있습니다(nodejs 런타임 환경만 해당).

  6. API에는 AWS 지역 장애 중에 온라인 상태를 유지하는 기능이 필요합니다. 귀하의 API는 상태를 저장하지 않고 다른 소스의 데이터만 집계합니다. 귀하에게는 데이터베이스가 없습니다. 이 가동 시간 목표를 달성하기 위한 간단하지만 효과적인 방법은 무엇입니까?
    • CloudFront 배포를 사용하여 API를 제공합니다. API가 있는 리전이 다운되더라도 CloudFront에서 사용하는 엣지 로케이션은 문제가 없습니다.
    • ELB 및 교차 영역 ELB 배포를 사용하여 데이터 센터 전체에 중복성을 생성합니다. 지역에 장애가 발생하더라도 다른 AZ는 온라인 상태를 유지합니다.
    • Route53 가중 라운드 로빈 레코드를 생성하고 한 지역이 다운되면 해당 지역이 다른 지역으로 리디렉션되도록 합니다.
    • 장애 조치가 포함된 Route53 지연 시간 기반 라우팅 레코드를 생성하고 서로 다른 두 지역에 있는 두 개의 동일한 상태 비저장 API 배포를 가리킵니다. 두 지역 모두 ELB 뒤에 Auto Scaling 그룹을 사용하는지 확인하십시오.
    설명:
    대기 시간 기반 레코드는 모든 것이 두 지역 모두에 적합할 때 요청 배포를 허용하고 장애 조치 구성 요소는 지역 간 폴백을 활성화합니다. ELB 및 ASG를 추가하면 장애 조치가 발생할 때마다 생존 지역의 시스템이 원래 비율 대신 수요의 100%를 충족하도록 확장할 수 있습니다.

  7. 엔터프라이즈 데이터 스토리지 시스템을 설계하고 있습니다. 데이터 관리 소프트웨어 시스템에는 마운트 가능한 디스크와 실제 파일 시스템이 필요하므로 S3를 스토리지로 사용할 수 없습니다. 지속성이 필요하므로 시스템에 AWS EBS 볼륨을 사용하게 됩니다. 시스템은 가능한 한 저비용 스토리지가 필요하며 액세스가 빈번하지 않거나 처리량이 높지 않으며 대부분 순차적 읽기입니다.

    이 시나리오에 가장 적합한 EBS 볼륨 유형은 무엇입니까?
    • gp1
    • io1
    • standard
    • gp2
    설명: Amazon EBS 볼륨 유형

    표준 볼륨 또는 마그네틱 볼륨은 다음에 가장 적합합니다. 데이터에 자주 액세스하지 않는 콜드 워크로드 또는 최저 스토리지 비용이 중요한 시나리오.

  8. 여러 환경에서 반복 가능한 방식으로 AWS 스택을 배포해야 합니다. 이를 수행하기 위한 올바른 도구로 CloudFormation을 선택했지만 생성하고 모델링해야 하지만 CloudFormation에서 지원하지 않는 리소스 유형이 있음을 발견했습니다. 이 난관을 어떻게 극복해야 할까요?
    • 생성, 업데이트 및 삭제 작업을 위해 프록시에 대한 API 호출을 선택하여 CloudFormation 사용자 지정 리소스 템플릿을 사용합니다. CloudFormation은 모델링 중인 리소스 유형에 대한 상태 전환 기능으로 선택한 AWS SDK, CLI 또는 API 방법을 사용합니다.
    • AWS 포럼에 티켓을 제출하십시오. AWS는 GitHub의 AWS Labs 조직에 도구를 릴리스하여 CloudFormation 리소스 유형을 확장합니다. 응답 시간은 보통 1일이며 1~2주 이내에 요청을 완료합니다.
    • CloudFormation에 의존하는 대신 Chef, Puppet 또는 Ansible을 사용하여 OpenStack 하이퍼바이저 및 클라우드 환경에서 작동하는 선언적 스택 리소스 정의인 Heat 템플릿을 작성하십시오.
    • 사용자 지정 리소스 공급자를 SNS 주제에 구독하거나 AWS Lambda에서 로직을 구현하여 생성, 업데이트 및 삭제 기능을 구현하여 CloudFormation 사용자 지정 리소스 유형을 생성합니다.
    설명:

    사용자 지정 리소스는 AWS CloudFormation 템플릿에서 사용자 지정 프로비저닝 로직을 작성하고 스택을 생성, 업데이트 또는 삭제할 때와 같은 스택 작업 중에 AWS CloudFormation에서 실행하도록 하는 방법을 제공합니다. 자세한 내용은 사용자 지정 리소스를 참조하십시오.

  9. 2000명의 엔지니어 조직을 운영하고 있습니다. AWS를 처음으로 대규모로 사용하려고 합니다. 조직이 Active Directory의 고급 사용자이기 때문에 Microsoft Active Directory에서 실행되는 기존 ID 관리 시스템과 통합하려고 합니다. 가장 간단한 방법으로 AWS 자격 증명을 어떻게 관리해야 합니까?
    • 대규모 AWS Directory Service Simple AD를 사용합니다.
    • 대규모 AWS Directory Service AD ​​커넥터를 사용합니다.
    • AWS Directory Service에서 실행되는 동기화 도메인을 사용합니다.
    • AWS Lambda에서 실행되는 AWS 디렉터리 동기화 도메인 사용
    설명: AD Connector

    AD Connectory는 클라우드에서 정보를 캐시 저장하지 않고도 온프레미스 Microsoft Active Directory로 디렉터리 요청을 리디렉션할 수 있는 디렉터리 게이트웨이입니다.  Microsoft Active Directory의 고급 사용자로 AD Connector를 사용해야 합니다. 
    Simple AD는 AD 기능의 하위 집합에서만 작동합니다. 동기화 도메인이 없습니다. 그들은 대답을 구성합니다. AD Connector는 클라우드에 정보를 캐싱하지 않고 온프레미스 Microsoft Active Directory에 대한 프록시 디렉터리 요청을 허용하는 디렉터리 게이트웨이입니다. AD 커넥터는 2가지 크기로 제공됩니다. 작고 큰. 소규모 AD 커넥터는 사용자가 최대 500명인 소규모 조직을 위해 설계되었습니다. 대규모 AD 커넥터는 사용자가 최대 5,000명인 대규모 조직을 위해 설계되었습니다.

  10. 다음 중 AWS OpsWorks를 생각할 때 스택 계층에 할당할 수 있는 인스턴스 유형이 아닌 것은 무엇입니까?
    • 24/7 instances
    • Spot instances
    • Time-based instances
    • Load-based instances
    설명: 시간 기반 인스턴스와 로드 기반 인스턴스를 사용한 로드 관리
    AWS OpsWorks는 시작 및 중지 방법으로 특징지어지는 다음 인스턴스 유형을 지원합니다. 24/7 인스턴스는 수동으로 시작되어 사용자가 중지할 때까지 실행됩니다. 시간 기반 인스턴스는 지정된 일일 및 주간 일정에 따라 AWS OpsWorks에서 실행됩니다. 이를 통해 스택은 예측 가능한 사용 패턴을 수용하기 위해 인스턴스 수를 자동으로 조정할 수 있습니다. 로드 기반 인스턴스는 CPU 사용률과 같은 지정된 로드 지표를 기반으로 AWS OpsWorks에 의해 자동으로 시작되고 중지됩니다. 이를 통해 스택은 들어오는 트래픽의 변화를 수용하기 위해 인스턴스 수를 자동으로 조정할 수 있습니다. 로드 기반 인스턴스는 Linux 기반 스택에서만 사용할 수 있습니다.

    • 시간 기반 인스턴스
      이 인스턴스 유형은 특정 시간 또는 특정 요일에만 실행되는 인스턴스를 포함시켜 예측 가능한 패턴을 따르는 부하를 처리할 수 있게 해줍니다. 예를 들어 야간 백업 작업을 수행하기 위해 오후 6시부터 일부 인스턴스를 시작하거나 트래픽이 적은 주말에 일부 인스턴스를 중지할 수 있습니다.
    • 로드 기반 인스턴스
      이 인스턴스 유형은 스택이 다양한 로드 측정치를 기반으로 트래픽이 많을 때는 추가 인스턴스를 시작하고 트래픽이 적을 때는 인스턴스를 중지하여 가변적인 로드를 처리할 수 있게 해줍니다. 예를 들어 AWS OpsWorks Stacks에게 평균 CPU 사용률이 80%를 초과할 경우 인스턴스를 시작하고 평균 CPU 부하가 60% 미만으로 하락할 경우 인스턴스를 중지하도록 할 수 있습니다.
  11. 다음 중 CloudFormation 헬퍼 스크립트가 아닌 것은 무엇입니까?
    • cfn-signal
    • cfn-hup
    • cfn 요청
    • cfn-get-metadata
    설명: CloudFormation 헬퍼 스크립트

    다음은 CloudFormation 도우미 스크립트의 전체 목록입니다.

  12. 귀하의 팀은 버전이 지정된 전체 스택 또는 스택 계층의 자동화된 빌드 및 배포를 지원하기 위해 CloudFormation을 사용하여 지속적인 전달을 시작하려고 합니다. 3계층 미션 크리티컬 시스템이 있습니다. 다음 중 지속적인 제공 환경에서 CloudFormation을 사용하기 위한 모범 사례가 아닌 것은 무엇입니까?
    • AWS에 변경 사항을 게시하기 전에 AWS CloudFormation <code>ValidateTemplate</code> 호출을 사용하십시오.
    • 스택을 하나의 템플릿으로 모델링하여 CloudFormation의 상태 관리 및 종속성 해결을 활용하여 모든 변경 사항을 전파할 수 있습니다.
    • CloudFormation을 사용하여 푸시할 때마다 모든 상태 비저장 리소스에 대한 새로운 인프라를 생성하고 해당 인프라 세트에서 통합 테스트를 실행하십시오.
    • 템플릿을 매개변수화하고 <code>매핑</code>을 사용하여 템플릿이 여러 지역에서 작동하도록 합니다.
    설명:

    계층마다 수명 주기와 변경 빈도가 다르기 때문에 모든 리소스를 하나의 스택에 넣는 것은 좋지 않습니다. 스택 구성에 대한 추가 지침을 보려면 다중 계층 아키텍처와 서비스 지향 아키텍처(SOA)라는 두 가지 공통 프레임워크를 사용할 수 있습니다.

    다중 계층 아키텍처란 무엇인가요?
    다중 계층 아키텍처는 둘 이상의 계층을 갖는 애플리케이션 아키텍처를 의미합니다. 그러나 4개 이상의 계층을 둔 애플리케이션은 속도를 늦추고 관리와 실행이 비효율적이기 때문에 거의 없습니다. 다중 계층 아키텍처는 일반적으로 3계층 아키텍처를 의미합니다.
     3계층 아키텍처의 장점은 기능의 논리적 및 물리적 분리입니다. 각 계층은 별도의 운영체제 및 서버 플랫폼에서 실행될 수 있습니다. (웹 개발의 3계층예: 웹 서버, 애플리케이션 서버, 데이터베이스 서버) 이는 기능적 요구사항에 가장 적합합니다. 그리고 각 계층이 하나 이상의 전용 서버 하드웨어 또는 가상 서버에서 실행되므로, 다른 티어에 영향을 주지 않고도 각 계층의 서비스를 최적화할 수 있습니다.
     


    서비스 지향 아키텍처란 무엇인가요?
    서비스 지향 아키텍처(SOA)는 서비스라는 소프트웨어 구성 요소를 사용해 비즈니스 애플리케이션을 생성하는 소프트웨어 개발 방식입니다. 각 서비스는 비즈니스 기능을 제공하며, 플랫폼과 언어를 넘나들며 서로 통신할 수 있습니다. 개발자는 SOA를 사용해 서로 다른 시스템 내의 서비스를 재사용하거나 독립적인 여러 서비스를 결합하여 복잡한 태스크를 수행합니다.


  13. 실시간으로 두 시스템 간에 API 호출을 복제해야 합니다. API 호출 이벤트에 대한 버퍼 및 전송 메커니즘으로 어떤 도구를 사용해야 합니까?
    • AWS SQS
    • AWS Lambda
    • AWS Kinesis
    • AWS SNS
    설명:  Amazon Kinesis

    AWS Kinesis는 이벤트 스트림 서비스입니다. 스트림은 순서대로 프로그래밍된 이벤트를 위해 시스템 간에 버퍼 및 전송 역할을 할 수 있으므로 시스템 간에 API 호출을 복제하는 데 이상적입니다. 일반적인 Amazon Kinesis Streams 애플리케이션은 Amazon Kinesis 스트림에서 데이터 레코드로 데이터를 읽습니다. 이러한 애플리케이션은 Amazon Kinesis Client Library를 사용할 수 있으며 Amazon EC2 인스턴스에서 실행할 수 있습니다. 처리된 레코드는 대시보드로 전송되어 알림을 생성하거나 가격 및 광고 전략을 동적으로 변경하거나 다양한 기타 AWS 서비스로 데이터를 전송하는 데 사용할 수 있습니다. Streams 기능 및 요금에 대한 자세한 내용은 Amazon Kinesis Streams를 참조하십시오.

    스트림 로그 및 이벤트 데이터
    애플리케이션 및 서비스 로그, 클릭스트림 데이터, 센서 데이터 및 인앱 사용자 이벤트에서 매일 테라바이트의 데이터를 수집하여 라이브 대시보드를 구동하고, 지표 생성하고, 데이터 레이크에 데이터를 제공합니다.

    실시간 분석 실행
    클릭스트림 데이터와 같은 빈도가 높은 이벤트 데이터용 애플리케이션을 구축하고 AWS Lambda 또는 Amazon Kinesis Data Analytics를 사용하여 며칠이 아닌 몇 초 만에 인사이트에 액세스할 수 있습니다.

    이벤트 기반 애플리케이션 구동
    AWS Lambda와 빠르게 페어링하여 규모에 관계없이 환경의 이벤트 기반 애플리케이션 내에서 즉각적인 발생에 대응하거나 조정합니다.

  14. MySQL을 데이터베이스로 사용하는 비프로덕션 내부용으로 Ruby on Rails 애플리케이션을 구축하고 있습니다. AWS 경험이 많지 않은 개발자가 단일 명령줄 푸시로 새 코드를 배포할 수 있기를 원합니다. 또한 가능한 한 간단하게 설정하려고 합니다.

    이 설정에 이상적인 도구는 무엇입니까?
    • AWS CloudFormation
    • AWS OpsWorks
    • AWS ELB + EC2 with CLI Push
    • AWS Elastic Beanstalk
    설명: AWS Elastic Beanstalk란 무엇입니까?

    Elastic Beanstalk의 기본 작동 모드는 바로 이 사용 사례를 정확히 지원합니다. 이 질문에 대한 다른 모든 옵션보다 간단합니다. Elastic Beanstalk를 사용하면 해당 애플리케이션을 실행하는 인프라에 대해 걱정할 필요 없이 AWS 클라우드에서 애플리케이션을 빠르게 배포하고 관리할 수 있습니다. AWS Elastic Beanstalk는 선택이나 제어를 제한하지 않고 관리 복잡성을 줄입니다. 애플리케이션을 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, 조정 및 애플리케이션 상태 모니터링의 세부 정보를 자동으로 처리합니다.

  15. AWS IAM의 범위는 어떻게 됩니까?

    • Global
    • Availability Zone
    • Region
    • Placement Group
    설명:

    IAM 리소스는 모두 전역적입니다. 지역적 제약이 없습니다.

  16. 소비자가 고양이 사진을 온라인에 게시할 수 있는 모바일 앱을 만들고 있습니다. AWS S3에 이미지를 저장하게 됩니다. 시스템을 매우 저렴하고 간단하게 실행하기를 원합니다.

    값비싼 업로드 프로세스, 인증/권한 부여 등에 대해 걱정할 필요 없이 사진 공유 애플리케이션을 구축할 수 있는 옵션은 무엇입니까?
    • 사용자가 Facebook 또는 Google 계정을 사용하여 로그인할 수 있도록 AWS Cognito 및 웹 자격 증명 연동을 사용하여 애플리케이션을 구축합니다. 로그인하면 해당 사용자에게 전달된 비밀 토큰은 AWS S3와 같은 AWS의 리소스에 직접 액세스하는 데 사용됩니다.
    • JWT 또는 SAML 호환 시스템을 사용하여 인증 정책을 구축합니다. 사용자는 사용자 이름과 암호로 로그인하고 사진 인프라에 대해 전화를 걸기 위해 무기한 사용할 수 있는 토큰을 받습니다.
    • 지속적으로 교체되는 API 키와 함께 AWS API Gateway를 사용하여 클라이언트 측에서 액세스를 허용하십시오. SDK의 사용자 지정 빌드를 구성하고 여기에 S3 액세스를 포함합니다.
    • AWS oAuth 서비스 도메인 광고를 생성하여 도메인에 대한 공개 가입 및 액세스 권한을 부여합니다. 설정하는 동안 하나 이상의 주요 소셜 미디어 사이트를 사용자를 위한 신뢰할 수 있는 ID 공급자로 추가합니다.
    설명: Amazon Cognito란 무엇입니까?
    짧은 대답은 Amazon Cognito가 웹 자격 증명 연동에서 제공하는 기능의 상위 집합이라는 것입니다. 동일한 제공자를 지원하며 앱을 구성하고 동일한 방식으로 해당 제공자를 인증합니다. 그러나 Amazon Cognito에는 다양한 추가 기능이 포함되어 있습니다. 예를 들어 사용자가 게스트 사용자로 앱 사용을 시작하고 나중에 지원되는 ID 공급자 중 하나를 사용하여 로그인할 수 있습니다.


  17. CTO는 AWS 계정의 모든 사용자가 항상 리소스를 변경하기 위해 무엇을 하고 있는지 알고 있는지 확인하도록 요청했습니다. 그녀는 가능한 한 광범위한 자원 유형 그룹에 대해 시간이 지남에 따라 누가 무엇을 하고 있는지에 대한 보고서를 일주일에 한 번 보고받기를 원합니다.

    어떻게 해야 할까요?
    • 글로벌 AWS CloudTrail 추적을 생성합니다. 일주일에 한 번 S3에 전달된 로그 데이터를 집계하여 CTO에게 전달하도록 스크립트를 구성합니다.
    • 모든 AWS API 호출을 구독하는 SNS 주제와 함께 CloudWatch 이벤트 규칙을 사용합니다. 이 SNS 주제에 대한 이메일 유형 전달에 CTO를 구독하십시오.
    • AWS IAM 자격 증명 보고서를 사용하여 시간 경과에 따른 IAM 사용자 토큰의 모든 사용에 대한 CSV를 CTO에게 전달합니다.
    • Lambda에서 SNS 구독과 함께 AWS Config를 사용하고 시간 경과에 따라 이러한 변경 사항을 DynamoDB 테이블에 삽입합니다. 이 테이블의 내용을 기반으로 보고서를 생성합니다.
    설명: AWS CloudTrail이란 무엇입니까?
    이것은 AWS CloudTrail의 이상적인 사용 사례입니다. CloudTrail은 계정에서 이루어진 API 호출을 기록하여 사용자 활동에 대한 가시성을 제공합니다. CloudTrail은 API 이름, 호출자 ID, API 호출 시간, 요청 매개변수 및 AWS 서비스에서 반환한 응답 요소를 포함하여 각 API 호출에 대한 중요한 정보를 기록합니다. 이 정보는 AWS 리소스에 대한 변경 사항을 추적하고 운영 문제를 해결하는 데 도움이 됩니다. CloudTrail을 사용하면 내부 정책 및 규제 표준을 보다 쉽게 ​​준수할 수 있습니다.
  18. 가장 빠르게 확장되는 순서는 무엇입니까(가장 빠른 것부터 확장)?
    DOP-C01 AWS DevOps 엔지니어 전문가 파트 20 Q18 013
    •  B, A, C
    • C, B, A
    • C, A, B
    • A, C, B
    설명:
    Lambda는 즉시 확장되도록 설계되었습니다. EC2 + ELB + Auto Scaling을 확장하려면 한 자릿수 분이 필요합니다. RDS는 최소 15분이 소요되며 적용 시 OS 패치 또는 기타 업데이트를 적용합니다.

  19. AWS EBS 스냅샷에 대한 제한 사항이 아닌 것은 무엇입니까?
    • 공유된 스냅샷은 다른 스냅샷의 기반으로 사용할 수 없습니다.
    • AWS 액세스 키 ID 또는 AWS 보안 액세스 키가 포함된 스냅샷은 공유할 수 없습니다.
    • 암호화되지 않은 스냅샷은 공유할 수 없습니다.
    • 스냅샷 복원은 스냅샷이 생성된 지역으로 제한됩니다.
    설명: Amazon EBS 스냅샷

    다른 사용자와 공유된 스냅샷은 수정된 볼륨 및 스냅샷을 기반으로 하는 기능을 포함하되 이에 제한되어 받는 사람이 전체적으로 사용할 수 있습니다.

     지정 시간 스냅샷을 만들어 Amazon S3에 Amazon EBS 볼륨의 데이터를 백업할 수 있습니다. 스냅샷은 증분식 백업이어서 마지막 스냅샷 이후 변경된 디바이스의 블록만이 저장됩니다. 그러면 스냅샷을 만드는 데 필요한 시간이 최소화되며 데이터를 복제하지 않으므로 스토리지 비용이 절약됩니다. 각 스냅샷에는 (스냅샷을 만든 시점의) 데이터를 새 EBS 볼륨에 복원하는 데 필요한 모든 정보가 들어 있습니다.

  20. 프로덕션에 새 애플리케이션 버전을 배포해야 합니다. 배포는 위험도가 높기 때문에 모든 것이 올바르게 작동하는지 확인하려면 여러 시간에 걸쳐 사용자에게 새 버전을 롤아웃해야 합니다. 새 버전의 애플리케이션을 보는 사용자의 비율을 백분율 포인트까지 제어할 수 있어야 합니다. Auto Scaling 그룹 및 사용자 지정 AMI와 함께 ELB 및 EC2를 시작 구성에 할당된 사전 설치된 코드와 함께 사용합니다. 배포 중에는 데이터베이스 수준 변경이 없습니다. 너무 많은 돈을 쓸 수 없다는 말을 들었습니다. 따라서 배포하는 동안 EC2 인스턴스의 수를 크게 늘리면 안 되지만 문제가 발생하면 신속하게 원래 버전의 코드로 다시 전환할 수 있어야 합니다.

    이러한 요구 사항을 충족하는 가장 좋은 방법은 무엇입니까?
    • 시작 구성을 사용하여 두 번째 ELB, Auto Scaling 시작 구성 및 Auto Scaling 그룹을 생성합니다. 모든 코드가 사전 설치된 AMI를 생성합니다. 새 AMI를 두 번째 Auto Scaling 시작 구성에 할당합니다. Route53 Weighted Round Robin Records를 사용하여 두 ELB에 도달하는 트래픽의 비율을 조정합니다.
    • 블루-그린 배포 방법을 사용하여 필요한 경우 가장 빠르게 롤백할 수 있습니다. 인스턴스의 전체 두 번째 스택을 생성하고 DNS를 새 인스턴스 스택으로 자르고 롤백이 필요한 경우 DNS를 다시 변경합니다.
    • 모든 코드가 사전 설치된 AMI를 생성합니다. 새 AMI를 Auto Scaling 시작 구성에 할당하여 이전 AMI를 교체합니다. 이전 코드(이전 시작 구성으로 시작)를 실행하는 인스턴스를 점진적으로 종료하고 새 AMI가 부팅되도록 허용하여 트래픽 균형을 새 코드로 조정합니다. 롤백 시 동일한 작업을 수행하되 Launch Config의 AMI를 원래 코드로 다시 변경하여 프로세스를 반대로 합니다.
    • AWS Elastic Beanstalk를 사용하도록 마이그레이션합니다. AWS가 새로운 애플리케이션 환경에서 제공하는 확립되고 잘 테스트된 롤링 배포 설정을 사용하여 새 코드의 zip 번들을 게시하고 대기 기간을 조정하여 시간이 지남에 따라 배포를 분산시킵니다. 필요한 경우 이전 코드 번들을 다시 배포하여 롤백하십시오.
    설명:

    가중 라운드 로빈 DNS 레코드 및 역방향 프록시만이 이러한 트래픽 분할의 미세 조정을 허용합니다. Blue-Green 옵션은 비용을 완화하고 전체 EC2 플릿 크기를 일관되게 유지해야 하는 요구 사항을 충족하지 않으므로 WRR DNS 튜닝과 함께 2 ELB 및 ASG 옵션을 선택해야 합니다. 이 방법을 A/B 배포 및/또는 카나리아 배포라고 합니다.

 

반응형
Comments