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

 

 

 

1. 당신은 SaaS 회사의 새로운 운영 책임자로 고용되었습니다. 귀하의 CTO는 전체 작업의 일부를 가능한 한 간단하고 빠르게 디버깅하도록 요청했습니다. 그녀는 복잡한 서비스 지향 아키텍처에서 무슨 일이 벌어지고 있는지 전혀 모른다고 불평합니다. 개발자는 디스크에 로그인하기만 하고 너무 많은 서비스에서 로그에서 오류를 찾기가 매우 어렵기 때문입니다. 이 요구 사항을 가장 잘 충족하고 CTO를 만족시킬 수 있는 방법은 무엇입니까?
   • 각 인스턴스에서 cron 작업을 사용하여 모든 로그 파일을 AWS S3에 복사합니다. <code>PutBucket</code> 이벤트에서 S3 알림 구성을 사용하고 이벤트를 AWS Lambda에 게시합니다. 로그가 들어오는 즉시 Lambda를 사용하여 로그를 분석하고 문제에 플래그를 지정합니다.
   • 모든 서비스에서 CloudWatch Logs 사용을 시작하십시오. 모든 로그 그룹을 S3 객체로 스트리밍합니다. AWS EMR 클러스터 작업을 사용하여 임시 MapReduce 분석을 수행하고 필요할 때 새 쿼리를 작성합니다.
   • 각 인스턴스에서 cron 작업을 사용하여 모든 로그 파일을 AWS S3에 복사합니다. <code>PutBucket</code> 이벤트에서 S3 알림 구성을 사용하고 이벤트를 AWS Kinesis에 게시합니다. AWS EMR에서 Apache Spark를 사용하여 로그 청크 및 플래그 문제에 대한 대규모 스트림 처리 쿼리를 수행합니다.
   • 모든 서비스에서 CloudWatch Logs 사용을 시작하십시오. 모든 로그 그룹을 Kibana 4를 실행하는 AWS Elasticsearch Service 도메인으로 스트리밍하고 검색 클러스터에서 로그 분석을 수행합니다.
   설명:

   Elasticsearch와 Kibana 4의 조합을 ELK 스택이라고 하며 실시간 임시 로그 분석 및 집계를 위해 특별히 설계되었습니다. 다른 모든 답변에는 추가 지연이 발생하거나 사전 정의된 쿼리가 필요합니다. Amazon Elasticsearch Service는 AWS 클라우드에서 Elasticsearch를 쉽게 배포, 운영 및 확장할 수 있게 해주는 관리형 서비스입니다. Elasticsearch는 로그 분석, 실시간 애플리케이션 모니터링, 클릭 스트림 분석과 같은 사용 사례를 위한 인기 있는 오픈 소스 검색 및 분석 엔진입니다.

2. AWS Elastic Beanstalk의 모델을 생각할 때 무엇이 ​​사실입니까?
   • 애플리케이션에는 많은 배포가 있고 배포에는 많은 환경이 있습니다.
   • 환경에는 많은 애플리케이션이 있고 애플리케이션에는 많은 배포가 있습니다.
   • 애플리케이션에는 많은 환경이 있고 환경에는 많은 배포가 있습니다.
   • 배포에는 많은 환경이 있고 환경에는 많은 애플리케이션이 있습니다.
   설명:

   응용 프로그램은 논리 서비스를 그룹화합니다. 환경은 애플리케이션에 속하며 일반적으로 다양한 배포 수준(개발, 단계, 제품 등)을 나타냅니다. 배포는 환경에 속하며 실행할 환경에 대한 코드 번들 푸시입니다.
   
   
   

3. 당신은 C++를 사용하여 GPU에서 실행되는 인공 신경망(ANN)을 사용하여 사진에 자동으로 태그를 지정하는 회사에서 근무합니다. 한 번에 수백만 개의 이미지를 받지만 하루 평균 3번만 받습니다. 이러한 이미지는 귀하가 제어하는 ​​AWS S3 버킷에 배치로 로드된 다음 고객이 JSON 형식의 매니페스트를 귀하가 제어하는 ​​다른 S3 버킷에도 게시합니다. 전체 GPU를 사용하여 각 이미지를 처리하는 데 10밀리초가 걸립니다. 신경망 소프트웨어를 부트스트랩하는 데 5분이 필요합니다. 이미지 태그는 JSON 객체이며 S3 버킷에 게시해야 합니다. 다음 중 이 시스템에 가장 적합한 시스템 아키텍처는 무엇입니까?
   • 두 개의 레이어가 있는 OpsWorks 스택을 생성합니다. 첫 번째는 ANN 이미지 처리를 위해 G2 인스턴스에서 HTTP API를 시작하고 부트스트랩하기 위한 수명 주기 스크립트를 포함하고 두 번째는 S3 매니페스트 버킷에서 새 파일을 모니터링하는 상시 가동 인스턴스를 포함합니다. 새 파일이 감지되면 인스턴스가 ANN 계층에서 부팅되도록 요청합니다. 인스턴스가 부팅되고 HTTP API가 실행되면 개별 인스턴스에 처리 요청을 제출합니다.
   • 매니페스트 버킷의 AWS Lambda에 게시하는 S3 알림 구성을 만듭니다. Lambda가 각 인스턴스의 ANN 코드를 사용하여 EC2 G2 인스턴스의 자동 확장 작업자 계층을 구성하는 논리가 포함된 CloudFormation 스택을 생성하도록 합니다. 매니페스트에서 이미지의 SQS 대기열을 만듭니다. 대기열이 비어 있을 때 스택을 분해합니다.
   • ANN 코드를 C++ 확장용 번들 바이너리로 AWS Lambda에 배포합니다. 매니페스트에서 컨트롤러 코드를 실행하는 다른 AWS Lambda에 게시하는 S3 알림 구성을 만듭니다. 이 컨트롤러 코드는 매니페스트의 모든 이미지를 AWS Kinesis에 게시합니다. ANN 코드 Lambda 함수는 Kinesis를 이벤트 소스로 사용합니다. 스트림에 이미지 이벤트가 포함되면 시스템이 자동으로 확장됩니다.
   • Auto Scaling, 로드 밸런싱된 Elastic Beanstalk 작업자 계층 애플리케이션 및 환경을 생성합니다. 이 계층의 G2 인스턴스에 ANN 코드를 배포합니다. 원하는 용량을 1로 설정합니다. 코드가 주기적으로 S3에서 새 매니페스트를 확인하도록 합니다. 새 매니페스트가 감지되면 매니페스트의 모든 이미지를 Elastic Beanstalk 작업자 계층과 연결된 SQS 대기열로 푸시합니다.
   설명:
   Elastic Beanstalk 옵션은 지속적으로 폴링되는 인스턴스가 필요하기 때문에 올바르지 않습니다. 이는 중단될 수 있고 비용이 발생할 수 있습니다. AWS Lambda는 GPU 사용을 지원하지 않기 때문에 Lambda 플릿 옵션이 올바르지 않습니다. OpsWorks 스택 옵션에는 지속적으로 폴링하는 인스턴스가 필요하고 복잡한 타이밍 및 용량 계획 논리도 필요합니다. CloudFormation 옵션은 폴링이 필요하지 않고 항상 켜져 있는 인스턴스가 없으며 인스턴스 수를 필요한 만큼 높게 설정하여 임의로 빠르게 처리할 수 있습니다.
   
   
   
4. 트래픽을 처리하기 위해 작동하는 최소 8개의 m4.large 인스턴스가 필요한 시스템을 설계하고 있습니다. 6개의 가용 영역이 있는 us-east-1 지역에서 고가용성을 위한 시스템을 설계할 때 회사는 전체 가용 영역의 종료를 처리할 수 있어야 합니다. 모든 EC2 노드가 ELB에 올바르게 연결되어 있다고 가정할 때 가능한 한 많은 비용을 절약하기 위해 서버를 어떻게 배포해야 합니까?
   
   VPC 계정은 us-east-1의 AZ의 a~f를 활용할 수 있습니다.
   
   • AZ의 a~d 각각에 3개의 서버가 있습니다.
   • AZ의 a 및 b 각각에 8개의 서버.
   • AZ의 a에서 e까지 각각에 2개의 서버.
   • AZ의 a에서 c까지 각각에 있는 4개의 서버.
   설명:

   가용 영역에서 N+1 중복성을 설계해야 합니다. ZONE_COUNT = (REQUIRED_INSTANCES / INSTANCE_COUNT_PER_ZONE) + 1. 비용을 최소화하려면 가능한 한 많은 영역에 인스턴스를 분산시키십시오. e를 사용하여 5개의 영역을 할당합니다. 2개의 인스턴스를 사용하면 총 10개의 인스턴스가 있습니다. 단일 영역이 실패하면 각각 2개의 인스턴스가 있는 4개의 영역이 남아 총 8개의 인스턴스가 됩니다. 최대한 분산시키면 비용이 25%만 증가하고 가용 영역 장애 위험이 크게 줄어듭니다.

5. 모든 템플릿 실행 중에 프로덕션에서 실행되지 않는 경우 CloudFormation에서 자동으로 Route53 레코드를 생성해야 합니다.
   
   이것을 어떻게 구현해야 합니까?
   
   • <code>environment</code>에 <code>Parameter</code>를 사용하고 템플릿의 Route53 <code>Resource</code>에 <code>Condition</code>을 추가하여 레코드만 생성 <code>환경</code>이 <code>프로덕션</code>이 아닌 경우.
   • Route53 레코드 값이 있는 템플릿과 레코드에 대한 null 값이 있는 템플릿 두 개를 만듭니다. 프로덕션에 배포할 때 없는 것을 사용하십시오.
   • <code>environment</code>에 <code>Parameter</code>를 사용하고 템플릿의 Route53 <code>Resource</code>에 <code>Condition</code>을 추가하여 레코드를 생성합니다. <code>environment</code>가 <code>production</code>인 경우 null 문자열입니다.
   • Route53 레코드가 있는 템플릿과 없는 템플릿의 두 가지 템플릿을 만듭니다. 프로덕션에 배포할 때 없는 것을 사용하십시오.
   설명:

   이를 수행하는 가장 좋은 방법은 하나의 템플릿과 리소스에 대한 조건을 사용하는 것입니다. Route53은 레코드에 대해 null 문자열을 허용하지 않습니다.
   
   

   • Use a <code>Parameter</code> for <code>environment</code>, and add a <code>Condition</code> on the Route53 <code>Resource</code> in the template to create the record only when <code>environment</code> is not <code>production</code>.
   • Create two templates, one with the Route53 record value and one with a null value for the record. Use the one without it when deploying to production.
   • Use a <code>Parameter</code> for <code>environment</code>, and add a <code>Condition</code> on the Route53 <code>Resource</code> in the template to create the record with a null string when <code>environment</code> is <code>production</code>.
   • Create two templates, one with the Route53 record and one without it. Use the one without it when deploying to production.
6. 웹 자격 증명 연합이란 무엇입니까?
   • Google 또는 Facebook과 같은 자격 증명 공급자를 사용하여 AWS IAM 사용자가 됩니다.
   • Google 또는 Facebook과 같은 자격 증명 공급자를 사용하여 임시 AWS 보안 자격 증명을 교환합니다.
   • AWS IAM 사용자 토큰을 사용하여 Google 또는 Facebook 사용자로 로그인합니다.
   • AWS STS 토큰을 사용하여 Google 또는 Facebook 사용자로 로그인합니다.
   설명: 웹 아이덴티티 페더레이션 정보 AWS 문서

   앱 사용자는 Login with Amazon, Facebook, Google 또는 기타 OIDC(OpenID Connect) 호환 IdP와 같은 잘 알려진 자격 증명 공급자(IdP)를 사용하여 로그인하고 인증 토큰을 받은 다음 해당 토큰을 교환할 수 있습니다. AWS 계정의 리소스를 사용할 수 있는 권한이 있는 IAM 역할에 매핑되는 AWS의 임시 보안 자격 증명.
   
   

7. 회사에서 배포 위험을 제거하라는 요청을 받았습니다. 특히 CEO는 스테이징과 프로덕션 사이의 우발적인 불일치로 인해 발생하는 중단에 대해 우려하고 있으며, 이로 인해 스테이징 테스트를 통과하더라도 프로덕션에서 예기치 않은 동작이 발생하는 경우가 있습니다. 이미 Docker를 사용하여 EC2 인스턴스의 애플리케이션 환경에 대한 스테이징과 프로덕션 간에 높은 일관성을 얻고 있습니다.
   
   AWS에는 EC2 가상 머신 외에 사용할 수 있는 서비스 구성 요소가 많기 때문에 나머지 실행 환경의 위험을 어떻게 더 제거합니까?
   
   • CloudFormation에서 전체 클라우드 시스템의 모델을 개발하십시오. 더 큰 패리티를 달성하려면 스테이징 및 프로덕션에서 이 모델을 사용하십시오.
   • AWS Config를 사용하여 Staging 및 Production 스택이 구성 패리티를 갖도록 합니다. 위험을 인식할 수 있도록 모든 차이점이 감지됩니다.
   • Docker는 LXC(Linux Container) 기술을 사용하므로 가상 머신의 커널을 포함한 전체 머신이 일관성이 있는지 확인하려면 AMI를 사용하고 컨테이너 환경이 일관성이 있는지 확인해야 합니다.
   • AWS ECS 및 Docker 클러스터링을 사용합니다. 이렇게 하면 AMI와 머신 크기가 두 환경에서 동일하게 됩니다.
   설명:

   CloudFormation의 JSON 템플릿만이 전체 AWS 클라우드의 반복적으로 배포 가능한 모델의 선언적 버전 제어를 허용합니다.
   
   
   

8. 비디오 게임 점수를 위한 새 API를 만들고 있습니다. 읽기는 쓰기보다 100배 더 일반적이며 점수의 상위 1%는 나머지 점수보다 100배 더 자주 읽습니다.
   
   DynamoDB를 사용하는 이 시스템에 가장 적합한 설계는 무엇입니까?
   
   • CloudFront 캐싱을 사용하여 쓰기 처리량보다 읽기 처리량이 100배 더 높은 DynamoDB 테이블.
   • CloudFront 캐싱을 사용하여 거의 동일한 읽기 및 쓰기 처리량을 제공하는 DynamoDB 테이블.
   • ElastiCache 캐싱을 사용하여 쓰기 처리량보다 읽기 처리량이 100배 더 높은 DynamoDB 테이블.
   • ElastiCache 캐싱을 사용하여 거의 동일한 읽기 및 쓰기 처리량을 제공하는 DynamoDB 테이블.
   설명:

   100x 읽기 비율은 대부분 캐싱을 사용하는 작은 하위 집합에 의해 결정되기 때문에 거의 동일한 수의 읽기와 쓰기만 캐시를 놓치게 됩니다. 압도적 다수가 상위 1% 점수에 도달하기 때문입니다. 캐싱을 사용할 때 값을 거의 동일하게 설정해야 한다는 점을 알고 AWS ElastiCache를 선택합니다. CloudFront는 DynamoDB 쿼리를 직접 캐싱할 수 없고 ElastiCache는 콘텐츠 전송을 위한 분산 프록시 캐시가 아니라 데이터베이스 쿼리를 위한 탁월한 메모리 내 캐시이기 때문입니다. … 한 가지 해결책은 애플리케이션 계층에서 이러한 읽기를 캐시하는 것입니다. 캐싱은 처리량이 많은 많은 응용 프로그램에서 사용되는 기술로 핫 항목에 대한 읽기 작업을 데이터베이스가 아닌 캐시로 오프로드합니다. 애플리케이션은 가장 인기 있는 항목을 메모리에 캐시하거나 ElastiCache와 같은 제품을 사용하여 동일한 작업을 수행할 수 있습니다.

9. 스타트업의 DevOps 엔지니어로 채용되었습니다. 귀하의 스타트업은 인프라의 100%에 AWS를 사용합니다. 그들은 현재 배포를 위한 자동화가 전혀 없으며 프로덕션에 배포하는 동안 많은 실패를 겪었습니다. 회사는 현재 배포 프로세스 위험 완화가 가장 중요하며 도구 및 AWS 리소스에 대한 예산이 많다고 말했습니다. 스택:

   

   DOP-C01 AWS DevOps 엔지니어 전문가 파트 18 Q09 012

   
   scaling group은 4~12개의 EC2 서버 사이에서 적절하게 다릅니다.
   다음 중 이 회사의 스택과 우선 순위를 고려할 때 회사의 요구 사항에 가장 적합한 접근 방식은 무엇입니까?
   • AWS Elastic Beanstalk의 스택을 여러 환경이 있는 단일 애플리케이션으로 모델링합니다. 여러 환경에서 승격할 때 Elastic Beanstalk의 롤링 배포 옵션을 사용하여 애플리케이션 코드 변경 사항을 점진적으로 롤아웃합니다.
   • 3가지 CloudFormation 템플릿(데이터 계층, 컴퓨팅 계층 및 네트워킹 계층)에서 스택을 모델링합니다. Blue-Green 방법론에 따라 스택 배포 및 통합 테스트 자동화를 작성합니다.
   • AWS OpsWorks의 스택을 1개의 컴퓨팅 계층과 관련 ELB가 있는 단일 스택으로 모델링합니다. Chef 및 앱 배포를 사용하여 롤링 배포를 자동화합니다.
   • 일관성 및 종속성 그래프 해결을 보장하기 위해 1개의 CloudFormation 템플릿에서 스택을 모델링합니다. 롤링 배포 방법론에 따라 배포 및 통합 테스트 자동화를 작성합니다.
   설명:

   AWS는 중단 시간이 없는 배포를 위해 Blue-Green을 권장합니다. DynamoDB를 사용하고 AWS OpsWorks나 AWS Elastic Beanstalk 모두 DynamoDB를 직접 지원하지 않으므로 CloudFormation 및 Blue-Green을 선택하는 옵션이 올바릅니다. 다양한 전략을 사용하여 현재 애플리케이션 스택(파란색)에서 새 버전의 애플리케이션(녹색)으로 트래픽을 마이그레이션합니다. 이는 다운타임 없이 애플리케이션을 배포하는 데 널리 사용되는 기술입니다. AWS Elastic Beanstalk, AWS CloudFormation 또는 AWS OpsWorks와 같은 배포 서비스는 실행 중인 애플리케이션 스택을 복제하는 간단한 방법을 제공하므로 특히 유용합니다. 애플리케이션의 현재 버전(파란색)을 간단히 복제하여 새 버전의 애플리케이션(녹색)을 설정할 수 있습니다.
   
   

10. EBS 스냅샷의 범위는 어떻게 됩니까?
    • 가용 영역
    • 배치 그룹
    • 지역
    • VPC
    설명:

    EBS 스냅샷은 해당 지역에 연결되어 있으며 동일한 지역에서 볼륨을 생성하는 데만 사용할 수 있습니다. 한 지역에서 다른 지역으로 스냅샷을 복사할 수 있습니다. 자세한 내용은 Amazon EBS 스냅샷 복사 단원을 참조하십시오.
    
    

11. 시스템은 고가용성을 달성하기 위해 두 리전에 걸쳐 있는 다중 마스터, 다중 리전 DynamoDB 구성을 사용합니다. 시스템을 시작한 이후 처음으로 작업을 수행하는 AWS 리전 중 하나가 3시간 동안 중단되었고 장애 조치가 올바르게 작동했습니다. 그러나 복구 후 사용자는 지구 반대편에 있는 사용자가 다른 데이터를 보는 이상한 버그를 경험하고 있습니다.
    
    출시할 때 설명되지 않은 가능성 있는 설계 문제는 무엇입니까?
    
    • 시스템에는 복구된 리전의 테이블 내에서 손상된 파티션 블록에 대해 테이블 ​​스캔 및 확인을 수행하기 위한 Lambda Functor Repair Automatons가 없습니다.
    • 시스템은 중단이 발생한 리전에서 파티션 성능을 복원하기 위해 DynamoDB 테이블 조각 모음을 구현하지 않았으므로 데이터가 오래되었습니다.
    • 시스템에는 몇 시간 동안 사용할 수 없는 리전으로 데이터를 재동기화하기 위한 복구 논리 및 요청 재생 버퍼링 논리가 포함되지 않았습니다.
    • 시스템은 DynamoDB Consistent Read 요청을 사용하지 않았으므로 다른 영역의 요청은 런타임 시 리전 전체의 합의를 활용하지 않습니다.
    설명:

    다중 리전 DynamoDB 시스템을 사용하는 경우 한 리전에 대한 모든 요청이 다른 리전으로 복제되도록 하는 것이 가장 중요합니다. 정상적인 작동에서 문제의 시스템은 다른 지역에 대한 쓰기 재생을 올바르게 수행합니다. 전체 리전이 다운되면 시스템은 다운타임 동안 이러한 쓰기를 수행할 수 없습니다. 어떻게든 쓰기 요청을 버퍼링하지 않으면 시스템이 삭제된 지역 간 쓰기를 재생할 방법이 없으며 요청은 복구 후 제공되는 지역에 따라 다르게 서비스됩니다.

12. AWS에서 컴퓨팅 용량을 구매하는 방법에는 여러 가지가 있습니다. 평균적으로 컴퓨팅 또는 메모리 단위당 가격을 LOW에서 HIGH(가장 저렴한 순)로 주문하는 것은 무엇입니까?
    • 온디맨드 B. 스팟 C. 예약됨
    • A, B, C
    • 씨, 비, 에이
    • 비, 씨, 에이
    • A, C, B
    설명:

    스팟 인스턴스는 일반적으로 온디맨드 가격보다 훨씬 저렴합니다. 예약 인스턴스는 기간과 사용률에 따라 약 33%~66%의 비용 절감 효과를 얻을 수 있습니다. 온디맨드 가격은 기본 가격이며 EC2 컴퓨팅 시간을 구매하는 가장 비싼 방법입니다.

13. 귀하는 디지털 지갑 결제를 대량으로 처리하는 회사를 위해 운영합니다. 지불을 중단하거나 사용할 수 없는 1초의 가동 중지 시간은 평균 USD 100의 손실입니다. 하루에 한 번 거래 시스템의 재정 균형을 맞춥니다.
    
    이 비즈니스 위험을 해결하는 데 가장 적합한 데이터베이스 설정은 무엇입니까?
    
    • 빠른 장애 조치 및 ACID 속성을 위해 여러 대기 및 읽기 복제본에 대한 동기식 복제가 포함된 다중 AZ RDS 배포.
    • 복제를 위한 데이터베이스 트리거 쓰기와 함께 데이터베이스 수준 ACID 설계 원칙을 사용하는 다중 지역, 다중 마스터, 활성-활성 RDS 구성입니다.
    • 복제를 위한 변경 스트림 쓰기 대기열 버퍼와 함께 애플리케이션 제어 수준 BASE 설계 원칙을 사용하는 다중 리전, 다중 마스터, 활성-활성 DynamoDB 구성.
    • 내구성이 뛰어난 스토리지 및 BASE 속성을 위해 변경 사항이 AWS Kinesis를 통해 S3로 스트리밍되는 다중 AZ DynamoDB 설정.
    설명:

    다중 마스터, 다중 리전 DynamoDB 답변만 의미가 있습니다. 다중 AZ 배포는 기업이 가용성을 상실하여 시간당 USD 360,000의 손실을 입을 때 충분한 가용성을 제공하지 않습니다. RDS는 기본적으로 다중 리전을 지원하지 않고 ACID는 리전 간 먼 거리에서 잘/전혀 수행되지 않으므로 DynamoDB 답변만 작동합니다.

14. DynamoDB를 생각할 때 Local Secondary Key 속성에 해당하는 것은 무엇입니까?
    • 파티션 키 또는 정렬 키는 테이블과 다를 수 있지만 둘 다 다를 수는 없습니다.
    • 정렬 키만 테이블과 다를 수 있습니다.
    • 파티션 키와 정렬 키는 테이블과 다를 수 있습니다.
    • 파티션 키만 테이블과 다를 수 있습니다.
    설명:

    Global secondary index – 파티션 키와 정렬 키가 테이블에 있는 것과 다를 수 있는 인덱스입니다. 글로벌 보조 인덱스는 인덱스에 대한 쿼리가 모든 파티션에서 테이블의 모든 데이터에 걸쳐 있을 수 있기 때문에 "글로벌"로 간주됩니다.

15. AWS Auto Scaling 그룹 및 Auto Scaling 시작 구성을 사용할 때 개별 서버의 수명이 가장 짧은 배포 방법은 무엇입니까?
    
    • 배포 시 모든 코드 및 구성으로 AMI를 사전 베이킹합니다.
    • 인스턴스 시작 시 Dockerfile 부트스트랩 사용.
    • UserData 부트스트래핑 스크립트 사용.
    • AWS EC2 Run Commands를 사용하여 플릿에 동적으로 SSH 연결.
      
      원본
    • Pre-baking AMIs with all code and configuration on deploys.
    • Using a Dockerfile bootstrap on instance launch.
    • Using UserData bootstrapping scripts.
    • Using AWS EC2 Run Commands to dynamically SSH into fleets.
    설명:

    복잡한 응용 프로그램이나 설치할 응용 프로그램이 여러 개인 경우 부트스트래핑 프로세스가 느려질 수 있습니다. 여러 빌드 도구 및 종속성을 사용하여 여러 애플리케이션을 관리하는 것은 롤아웃 중에 어려운 작업이 될 수 있습니다. 또한 배포 서비스는 Auto Scaling을 활용하기 위해 더 빠른 롤아웃을 수행하도록 설계되어야 합니다. 사전 베이킹은 기본 AMI 내에 애플리케이션 아티팩트의 상당 부분을 포함하는 프로세스입니다. 배포 프로세스 중에 인스턴스 태그, 인스턴스 메타데이터 및 Auto Scaling 그룹과 같은 EC2 인스턴스 아티팩트를 사용하여 애플리케이션 설치를 사용자 지정할 수 있습니다.
    
    

16. 다음 중 배포에 실패한 경우 가능한 가장 빠른 롤백 시간을 가능하게 하는 기술은 무엇입니까?
    
    • Rolling; Immutable
    • Rolling; Mutable
    • Canary or A/B
    • Blue-Green
    설명:

    AWS는 특히 초고속 제로 다운타임 배포를 위해 Blue-Green을 권장하며 따라서 이전 코드를 재배포하는 롤백을 권장합니다. 다양한 전략을 사용하여 현재 애플리케이션 스택(파란색)에서 새 버전의 애플리케이션(녹색)으로 트래픽을 마이그레이션합니다. 이는 다운타임 없이 애플리케이션을 배포하는 데 널리 사용되는 기술입니다.
    
    

17. 다음 중 OpsWorks 사용자 지정 쿡북 리포지토리의 유효한 소스가 아닌 것은 무엇입니까?
    
    • HTTP(S)
    • Git
    • AWS EBS
    • Subversion
    설명:

    Linux 스택은 HTTP 또는 Amazon S3 아카이브와 같은 리포지토리 유형에서 사용자 지정 쿡북을 설치할 수 있습니다. 공개 또는 비공개일 수 있지만 일반적으로 Amazon S3가 비공개 아카이브에 선호되는 옵션입니다. Git 및 Subversion 리포지토리는 소스 제어와 여러 버전을 보유할 수 있는 기능을 제공합니다.
    
    

18. AWS에서 배포 시스템을 구축하고 있습니다. 코드가 저장된 S3 zip 파일 객체를 가리키는 UserData 스크립트를 사용하여 런타임에 VPC의 프라이빗 서브넷에 있는 인스턴스를 부트스트래핑하여 새 코드를 배포합니다. 퍼블릭 서브넷의 ELB에는 인스턴스에 대한 네트워크 인터페이스 및 연결성이 있습니다. 시스템 사용자의 요청은 Route53 A 레코드 별칭을 통해 ELB로 라우팅됩니다. VPC 엔드포인트를 사용하지 않습니다.
    
    이 접근 방식을 사용하면 어떤 위험이 있습니까?
    
    • Route53 별칭 레코드는 배포 후 ELB 네트워크 변경 사항에 따라 항상 동적으로 업데이트되지 않습니다.
    • 프라이빗 서브넷에 대한 NAT 라우팅이 실패하면 배포가 실패합니다.
    • 기본 AMI에 대한 커널 변경으로 인해 코드가 작동하지 않을 수 있습니다.
    • ELB가 퍼블릭 서브넷에 있는 경우 인스턴스는 프라이빗 서브넷에 있을 수 없습니다.
    설명:

    VPC 엔드포인트를 사용하지 않기 때문에 S3에 있는 코드에 대한 아웃바운드 요청은 VPC의 프라이빗 서브넷에 대한 NAT를 통해 라우팅됩니다. 이 네트워킹이 실패하면 코드 다운로드를 통한 런타임 부트스트래핑은 네트워크 사용 불가능과 인터넷 액세스 부족, 따라서 Amazon S3로 인해 실패합니다.
    
    

19. BYO(Bring Your Own) 라이선스가 필요한 주요 데이터베이스는 무엇입니까?
    
    • PostgreSQL
    • MariaDB
    • MySQL
    • Oracle
    설명:

    Oracle은 오픈 소스가 아니며 BYOL(Bring Your Own License) 모델이 필요합니다.
    
    
    

20. EBS에서 지원되는 최대 단일 볼륨 처리량은 얼마입니까?
    • 320MiB/s
    • 160MiB/s
    • 40MiB/s
    • 640MiB/s
    설명:

    EBS에서 IOPS의 상한 처리량은 320MiB/s입니다.