Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- 코틀린 코루틴의 정석
- Linux
- 정보처리기사 실기
- Spring
- APM
- minikube
- aws
- kotlin coroutine
- Elasticsearch
- 오블완
- Kubernetes
- PETERICA
- 티스토리챌린지
- Java
- 정보처리기사실기 기출문제
- AWS EKS
- CKA
- kotlin spring
- 공부
- CloudWatch
- AI
- kotlin
- 정보처리기사 실기 기출문제
- CKA 기출문제
- Pinpoint
- IntelliJ
- kotlin querydsl
- 기록으로 실력을 쌓자
- MySQL
- mysql 튜닝
Archives
- Today
- Total
피터의 개발이야기
[DOP-C01] AWS DevOps Engineer Professional : Part 15 본문
반응형
- 지속적인 배포 프로세스의 일부로 애플리케이션은 새 AMI를 사용하여 프로덕션에 배포되기 전에 I/O 로드 성능 테스트를 거칩니다. 애플리케이션은 인스턴스당 하나의 Amazon Elastic Block Store(EBS) PIOPS 볼륨을 사용하며 일관된 I/O 성능이 필요합니다.
다음 중 I/O 로드 성능 테스트가 반복 가능한 방식으로 올바른 결과를 내도록 하기 위해 수행해야 하는 것은 무엇입니까?
- 테스트를 위한 I/O 블록 크기가 무작위로 선택되었는지 확인하십시오.
- 테스트 전에 모든 블록을 읽어 Amazon EBS 볼륨이 미리 예열되었는지 확인합니다.
- Amazon EBS 볼륨의 스냅샷이 백업으로 생성되었는지 확인합니다.
- Amazon EBS 볼륨이 암호화되었는지 확인합니다.
- 테스트 전에 볼륨의 스냅샷을 생성하여 Amazon EBS 볼륨이 미리 예열되었는지 확인합니다.
- 지난 분기의 월별 청구서를 검토한 후 경영진은 Amazon의 전체 청구액이 증가한 것을 발견했습니다. 이러한 비용 증가를 조사한 후 새로운 서비스 중 하나가 애플리케이션 버킷에 있는 모든 객체의 메타데이터 캐시를 구축하기 위해 Amazon S3에 대한 많은 GET Bucket API 호출을 수행하고 있음을 발견했습니다.
당신의 상사는 이러한 새로운 GET Bucket API 호출의 양을 줄이는 데 도움이 되는 새로운 비용 효율적인 방법을 찾아달라고 요청했습니다.
비용을 줄이기 위해 어떤 프로세스를 사용해야 합니까?- 객체 목록을 새 버킷으로 자동 푸시하도록 Amazon S3 버킷의 수명 주기 정책을 업데이트하고 이 목록을 사용하여 애플리케이션의 버킷과 연결된 객체를 봅니다.
- 새 DynamoDB 테이블을 생성합니다. 새로운 DynamoDB 테이블을 사용하여 Amazon S3에 업로드된 모든 객체에 대한 모든 메타데이터를 저장합니다. 새 객체가 업로드될 때마다 DynamoDB에서 애플리케이션의 내부 Amazon S3 객체 메타데이터 캐시를 업데이트합니다.
- Amazon SNS를 사용하여 새 DynamoDB 테이블을 자동으로 업데이트하여 새 객체에 대한 모든 메타데이터를 저장하는 모든 새 Amazon S3 객체에 대한 알림을 생성합니다. Amazon SNS 주제에 대한 애플리케이션을 구독하여 DynamoDB 테이블에서 내부 Amazon S3 객체 메타데이터 캐시를 업데이트합니다.
- 모든 이미지를 Amazon SQS에 업로드하고, 모든 이미지를 Amazon S3로 이동하도록 SQS 수명 주기를 설정하고, 애플리케이션에 대한 Amazon SNS 알림을 시작하여 애플리케이션의 내부 Amazon S3 객체 메타데이터 캐시를 업데이트합니다.
- 모든 이미지를 ElastiCache 파일 캐시 서버에 업로드합니다. 이제 ElastiCache 파일 캐시 서버에서 모든 파일 메타데이터를 읽도록 애플리케이션을 업데이트하고 장기 저장을 위해 모든 파일을 Amazon S3에 푸시하도록 ElastiCache 정책을 구성합니다.
- 현재 로그 분석 애플리케이션은 웹 애플리케이션의 상위 10개 사용자에 대한 보고서를 생성하는 데 4시간 이상 걸립니다. 이 정보를 실시간으로 보고할 수 있는 시스템을 구현하고, 보고서가 항상 최신 상태인지 확인하고, 웹 애플리케이션에 대한 요청 수의 증가를 처리하라는 요청을 받았습니다. 비용 효율적이고 요구 사항을 충족할 수 있는 옵션을 선택하십시오.
- 데이터를 CloudWatch Logs에 게시하고 애플리케이션이 자동 확장되도록 구성하여 온디맨드 로드를 처리합니다.
- 로그 데이터를 Amazon S3 버킷에 게시합니다. AWS CloudFormation을 사용하여 Auto Scaling 그룹을 생성하여 Amazon S3에 저장된 로그 파일을 풀다운하도록 구성된 사후 처리 애플리케이션을 확장합니다.
- Amazon Kinesis 데이터 스트림에 로그 데이터를 게시하고 로깅 데이터를 처리하도록 구성된 로그 처리 애플리케이션을 구독합니다.
- Amazon EMR 더스터의 크기를 늘리려면 Auto Scaling 그룹을 구성하십시오.
- 다중 AZ Amazon RDS MySQL 클러스터를 생성하고 로깅 데이터를 MySQL에 게시하고 맵 축소 작업을 실행하여 사용자 수에 대한 필수 정보를 검색합니다.
- Elastic Beanstalk를 사용하여 전자상거래 스토어를 관리하고 있습니다. 스토어는 오픈 소스 전자 상거래 플랫폼을 기반으로 하며 Auto Scaling 그룹의 여러 인스턴스에 배포됩니다. 귀하의 개발 팀은 종종 전자 상거래 상점을 위한 새로운 "확장 프로그램"을 생성합니다. 이러한 확장에는 PHP 소스 코드와 데이터베이스 스키마에 필요한 업데이트를 수행하는 데 사용되는 SQL 업그레이드 스크립트가 포함됩니다. SQL 업그레이드 스크립트를 실행할 때 오류로 인해 일부 확장 배포가 실패하는 것을 확인했습니다. 추가 조사 후 SQL 스크립트가 모든 Amazon EC2 인스턴스에서 실행되고 있기 때문임을 알게 됩니다.
당시 실행 중인 Amazon EC2 인스턴스 수에 관계없이 SQL 스크립트가 배포당 한 번만 실행되도록 하려면 어떻게 해야 합니까?
- Elastic Beanstalk 구성 파일 내에서 "컨테이너 명령"을 사용하여 스크립트를 실행하고 "leader only" 플래그가 true로 설정되었는지 확인합니다.
- Amazon EC2 메타데이터 서비스를 사용하여 Auto Scaling 그룹에서 인스턴스가 리더로 표시되었는지 여부를 쿼리하십시오. "true"가 반환되는 경우에만 스크립트를 실행합니다.
- Elastic Beanstalk 구성 파일 내에서 "Solo Command"를 사용하여 스크립트를 실행합니다. Elastic Beanstalk 서비스는 명령이 한 번만 실행되도록 합니다.
- Auto Scaling 그룹에 있는 단일 인스턴스의 쓰기 액세스만 허용하도록 Amazon RDS 보안 그룹을 업데이트합니다. 이렇게 하면 하나의 인스턴스만 데이터베이스에서 스크립트를 성공적으로 실행할 수 있습니다.
- 변경 사항에 대한 버전 제어를 폴링한 다음 전체 빌드 테스트 제품군을 위해 새 Amazon EC2 인스턴스를 시작하는 지속적 통합 애플리케이션을 관리하고 있습니다. 최대한 많은 테스트를 병렬로 실행하면서 전체 비용을 가장 낮추려면 어떻게 해야 합니까?
- 빌드 테스트, 단위 및 통합 테스트를 위해 새로운 Amazon EC2 인스턴스를 시작하기 전에 지속적 통합 시스템에서 구문 검사를 수행하십시오.
- 새로운 Amazon EC2 인스턴스 단위 및 통합 테스트를 시작하기 전에 지속적 통합 시스템에서 구문 및 빌드 테스트를 수행하십시오.
- 단위, 통합 및 빌드 테스트에 AWS OpsWorks를 사용하여 지속적 통합 시스템에서 모든 테스트를 수행합니다.
- 단위, 통합 및 빌드 테스트의 출력을 조정하기 위해 새로운 AWS Data Pipeline을 시작하기 전에 지속적 통합 시스템에서 구문 검사를 수행하십시오.
- AWS에서 호스팅되는 애플리케이션에 대한 부하 테스트 연습을 수행하고 있습니다. Amazon RDS MySQL DB 인스턴스를 테스트하는 동안 CPU 사용률이 100%에 도달하면 애플리케이션이 응답하지 않는 것을 발견했습니다. 귀하의 응용 프로그램은 읽기가 많습니다.
애플리케이션의 요구 사항을 충족하기 위해 데이터 계층을 확장하는 방법은 무엇입니까? (3개를 선택하세요.)
- Amazon RDS DB 읽기 전용 복제본을 추가하고 애플리케이션에서 읽기 쿼리를 직접 읽도록 합니다.
- Auto Scaling 그룹에 Amazon RDS DB 인스턴스를 추가하고 CPU 사용률을 기준으로 CloudWatch 지표를 구성합니다.
- Amazon SQS 대기열을 사용하여 Amazon RDS DB 인스턴스로 가는 데이터를 제한합니다.
- Amazon RDS DB 앞에서 ElastiCache를 사용하여 일반적인 쿼리를 캐시합니다.
- 여러 Amazon RDS DB 인스턴스 간에 데이터 세트를 분할합니다.
- Amazon RDS DB 인스턴스에 대해 다중 AZ를 활성화합니다.
- 귀하의 모바일 애플리케이션에는 출시 시 수만 명의 사용자가 예상되는 사진 공유 서비스가 포함되어 있습니다. Amazon Simple Storage Service(S3)를 활용하여 사용자 이미지를 저장하고 이러한 이미지에 액세스하기 위해 사용자를 인증하고 권한을 부여하는 방법을 결정해야 합니다. 또한 이러한 이미지의 스토리지를 관리해야 합니다.
다음 접근 방식 중 사용해야 하는 두 가지 방법은 무엇입니까? (두 가지를 선택하세요.)
- 사용자별로 Amazon S3 버킷을 생성하고 애플리케이션을 사용하여 적절한 콘텐츠에 대한 S3 URI를 생성합니다.
- AWS Identity and Access Management(IAM) 사용자 계정을 애플리케이션 수준 사용자 데이터베이스로 사용하고 애플리케이션 코드에서 인증 부담을 덜 수 있습니다.
- 애플리케이션 수준에서 사용자를 인증하고 AWS Security Token Service(STS)를 사용하여 S3 객체에 토큰 기반 권한을 부여합니다.
- 애플리케이션 수준에서 사용자를 인증하고 사용자에게 SMS 토큰 메시지를 보냅니다. SMS 메시지 토큰과 동일한 이름으로 Amazon S3 버킷을 생성하고 사용자 객체를 해당 버킷으로 이동합니다.
- 단일 Amazon S3 버킷의 모든 사용자 객체에 대해 사용자 ID로 구성된 키 기반 이름 지정 체계를 사용합니다.
- Amazon Simple Queue Service(SQS) 대기열의 메시지를 처리하는 Auto Sealing 인스턴스 그룹이 있습니다. 그룹은 대기열 크기에 따라 확장됩니다. 처리 타사 웹 서비스 호출이 포함됩니다. 웹 서비스에서 수신하는 실패 및 반복 호출 수에 대해 불평하고 있습니다. 그룹이 축소되면 처리하는 동안 인스턴스가 종료되는 것을 확인했습니다.
불완전한 프로세스 시도 횟수를 줄이기 위해 어떤 비용 효율적인 솔루션을 사용할 수 있습니까?
- 최소 및 최대 2개와 웹 프록시 소프트웨어를 실행하는 인스턴스로 새 Auto Scaling 그룹을 생성합니다. HTTP 트래픽을 이러한 웹 프록시로 라우팅하도록 VPC 라우팅 테이블을 구성합니다.
- 작업을 처리하는 동안 종료 방지 기능을 활성화하고 처리가 완료되면 비활성화하도록 인스턴스에서 실행 중인 애플리케이션을 수정합니다.
- Auto Scaling 그룹의 최소 및 최대 크기를 늘리고 동적으로 덜 확장되도록 조정 정책을 변경합니다.
- 인스턴스에서 실행 중인 애플리케이션을 수정하여 작업을 처리하는 동안 Auto Scaling Standby 상태로 전환하고 처리가 완료되면 InService로 돌아갑니다.
- 운영 팀과 개발 팀은 운영 체제와 애플리케이션 로그를 모두 볼 수 있는 단일 위치를 원합니다. AWS 서비스를 사용하여 이를 어떻게 구현해야 합니까? (두 가지를 선택하세요.)
- AWS CloudFormation을 사용하여 CloudWatch Logs LogGroup을 생성하고 CloudWatch Logs 에이전트를 사용하여 관심 있는 운영 체제 및 애플리케이션 로그를 보냅니다.
- AWS CloudFormation 및 구성 관리를 사용하여 UDP 패킷을 통해 이벤트를 CloudTrail로 전송하도록 원격 로깅을 설정합니다.
- 구성 관리를 사용하여 이벤트를 Amazon Kinesis로 보내고 사용 가능한 분석 도구에 따라 이를 Amazon CloudSearch 또는 Amazon Redshift에 삽입하도록 원격 로깅을 설정합니다. D. AWS CloudFormation을 사용하여 CloudWatch Logs LogGroup을 생성합니다. Cloudwatch Log 에이전트는 모든 운영 체제 로그를 자동으로 전송하므로 오프 머신 전송을 위한 애플리케이션 로그만 구성하면 됩니다.
- AWS CloudFormation을 사용하여 애플리케이션 로그를 운영 체제 로그와 병합하고 IAM 역할을 사용하여 두 팀 모두 Amazon EC2의 콘솔 출력을 볼 수 있는 액세스 권한을 부여합니다.
- 현재 작업 중인 프로젝트는 단일 AWS CloudFormation 템플릿을 사용하여 다중 계층 웹 애플리케이션을 지원하는 AWS 인프라를 배포합니다. AWS CloudFormation 리소스를 나중에 유지 관리할 수 있도록 구성하고 네트워킹 및 보안과 같은 여러 부서에서 프로덕션으로 이동하기 전에 아키텍처를 검토할 수 있도록 하는 임무를 받았습니다.
기존 워크플로를 사용하여 각 부서를 수용하는 방식으로 이 작업을 수행하려면 어떻게 해야 합니까?
- 네트워킹 및 보안 그룹에 대한 라우팅 규칙과 VPC 서브넷, 보안에 대한 IAM 정보와 같은 관련 리소스가 템플릿에서 서로 옆에 있도록 AWS CloudFormation 템플릿을 구성합니다.
- AWS CloudFormation 템플릿을 서로 다른 부서에서 관리할 리소스에 대한 개별 템플릿이 있는 중첩 구조로 분리하고 제어하는 애플리케이션 템플릿에 대해 네트워킹 및 보안 스택의 출력을 사용합니다.
- AWS CloudFormation 템플릿을 구성하여 관련 리소스가 템플릿에서 각 부서에서 서로 옆에 있도록 하고 기존 지속적 통합 도구를 활용하여 모든 당사자의 변경 사항을 생산 환경에 지속적으로 배포한 다음 검증을 위해 테스트를 실행합니다.
- 사용자 지정 애플리케이션과 AWS SDK를 사용하여 현재 AWS CloudFormation 템플릿에 정의된 리소스를 복제하고 기존 코드 검토 시스템을 사용하여 향후 배포를 위해 애플리케이션을 변경하기 전에 다른 부서에서 변경 사항을 승인할 수 있도록 합니다.
- 현재 Auto Scaling 그룹 뒤에 있는 Amazon EC2 인스턴스에서 인프라를 실행하고 있습니다. 애플리케이션의 모든 로그는 현재 임시 저장소에 기록됩니다. 최근 귀하의 회사는 테스트를 통과하고 궁극적으로 플릿에 배포된 코드에서 주요 버그를 경험했습니다. 이 버그는 Auto Scaling 그룹이 확장 및 축소되도록 트리거한 후 버그를 해결하는 데 도움이 되도록 서버에서 로그를 성공적으로 검색할 수 있습니다. 인스턴스가 종료된 후 로그를 검토할 수 있도록 하려면 어떤 기술을 사용해야 합니까?
- 종료 시 백업하도록 Auto Scaling 그룹에서 임시 정책을 구성합니다.
- 종료 시 모든 임시 스토리지의 스냅샷을 생성하도록 Auto Scaling 정책을 구성합니다.
- AMI에 CloudWatch Logs 에이전트를 설치하고 로그를 스트리밍하도록 CloudWatch Logs 에이전트를 구성합니다.
- AMI에 CloudWatch 모니터링 에이전트를 설치하고 임시 드라이브의 모든 로그를 백업하도록 CloudWatch 모니터링 에이전트를 트리거하는 CloudWatch 지표에 대한 새 SNS 알림을 설정합니다.
- AMI에 CloudWatch 모니터링 에이전트를 설치하고 Auto Scaling 정책을 업데이트하여 자동화된 CloudWatch Log 복사를 활성화하십시오.
- 경영진은 Amazon 웹 서비스의 월 청구액이 증가했다고 보고했으며 이러한 비용 증가에 대해 매우 우려하고 있습니다. 경영진은 이러한 증가의 정확한 원인을 확인하도록 요청했습니다. 결제 보고서를 검토한 후 데이터 전송 비용이 증가한 것을 확인했습니다. 데이터 전송 사용에 대한 더 나은 통찰력을 경영진에게 어떻게 제공할 수 있습니까?
- 5초 단위를 사용하도록 Amazon CloudWatch 지표를 업데이트하면 청구 데이터와 결합하여 이상을 정확히 찾아낼 수 있는 더 자세한 지표를 제공합니다.
- Amazon CloudWatch Logs를 사용하여 로그에서 map-reduce를 실행하여 높은 사용량 및 데이터 전송을 확인합니다.
- 애플리케이션 데이터 전송을 여러 개의 보다 구체적인 데이터 포인트로 세분화하는 애플리케이션별로 Amazon CloudWatch에 사용자 지정 지표를 제공합니다.
- Amazon CloudWatch 지표를 사용하여 매월 Elastic Load Balancing 아웃바운드 데이터 전송 지표를 가져와 결제 보고서에 포함하여 더 높은 대역폭 사용을 유발하는 애플리케이션을 보여줍니다.
- 메트릭 분석 중에 귀하의 팀은 회사 웹 사이트에서 예상보다 높은 피크 시간 동안 응답 시간이 발생하고 있음을 확인했습니다. 현재 Auto Scaling을 사용하여 사용량이 가장 많은 기간 동안 환경을 조정하고 있는지 확인합니다. 이 높은 응답 시간을 줄이기 위해 Auto Scaling 정책을 어떻게 개선할 수 있습니까? (두 가지를 선택하세요.)
- 사용자 정의 지표를 CloudWatch로 푸시하여 서버에서 CPU 및 네트워크 대역폭을 모니터링하면 Auto Scaling 정책이 보다 세분화된 통찰력을 가질 수 있습니다.
- Auto Scaling 그룹의 최대 서버 수를 늘립니다.
- 서버를 실행하고 모니터링하는 스크립트를 만듭니다. 로드에서 이상을 감지하면 로드 밸런서에 더 많은 서버를 추가하기 위해 Elastic Load Balancing을 트리거하는 Amazon SNS 주제에 게시합니다.
- 처리 중인 요청 수 및 처리 대기 중인 요청 수와 같은 웹 애플리케이션에 대한 자세한 정보가 포함된 애플리케이션에 대한 사용자 지정 지표를 CloudWatch로 푸시합니다.
- Auto Scaling 정책에 사용되는 CloudWatch 지표를 업데이트하고 Auto Scaling이 더 빠르게 트리거되도록 1분 미만의 세분성을 활성화합니다.
- 로드 밸런서 뒤에 있는 Amazon EC2 인스턴스에서 실행되는 회사의 대규모 다중 계층 Windows 기반 웹 애플리케이션을 담당하고 있습니다.
메트릭을 검토하는 동안 느린 고객 페이지 로드 시간이 증가하는 경향을 발견했습니다. 관리자가 고객 로드 시간이 초당 너무 많은 요청에 의해 영향을 받지 않도록 하는 솔루션을 제안하도록 요청했습니다.
이 문제를 해결하기 위해 어떤 기술을 사용하시겠습니까?
- AWS CloudFormation 템플릿을 사용하여 인프라를 재배포하십시오. 상태 확인이 실패하면 새 AWS CloudFormation 스택을 시작하도록 Elastic Load Balancing 상태 확인을 구성합니다.
- AWS CloudFormation 템플릿을 사용하여 인프라를 재배포하십시오. 두 번째 AWS CloudFormation 스택을 가동합니다. Elastic Load Balancing SpillOver 기능을 구성하여 두 번째 AWS CloudFormation 스택에 대한 느린 연결을 넘깁니다.
- AWS CloudFormation, Elastic Beanstalk 및 Auto Scaling을 사용하여 인프라를 재배포하십시오. Auto Scaling 그룹 정책을 설정하여 초당 요청 수와 현재 고객 로드 시간을 기준으로 확장합니다.
- Auto Scaling 템플릿을 사용하여 애플리케이션을 재배포합니다. 고객 로드 시간이 임계값을 초과할 때 새 Elastic Beanstalk 애플리케이션을 가동하도록 Auto Scaling 템플릿을 구성합니다.
- 귀사에는 AWS에서 실행되는 여러 애플리케이션이 있습니다. 회사는 환경에서 경보가 트리거될 때 이메일을 통해 즉시 대기 중인 팀에 알리는 도구를 개발하려고 합니다. 서로 다른 교대 근무를 하는 여러 대기 팀이 있으며 도구는 올바른 시간에 올바른 팀에 알리는 작업을 처리해야 합니다. 이 솔루션을 어떻게 구현해야 합니까?
- Amazon SNS 주제와 Amazon SQS 대기열을 생성합니다. Amazon SQS 대기열을 Amazon SNS 주제에 대한 구독자로 구성합니다. 경보가 트리거될 때 이 주제에 알리도록 CloudWatch 경보를 구성합니다. 최소 및 원하는 인스턴스가 모두 0으로 구성된 Amazon EC2 Auto Scaling 그룹을 생성합니다. 메시지가 대기열에 추가되면 이 그룹의 작업자 노드가 생성됩니다. 그런 다음 작업자는 Amazon Simple Email Service를 사용하여 대기 중인 팀에 메시지를 보냅니다.
- Amazon SNS 주제를 생성하고 대기 중인 팀 이메일 주소를 구독자로 구성합니다. AWS SDK 도구를 사용하여 애플리케이션을 Amazon SNS와 통합하고 이 새로운 주제로 메시지를 보냅니다. CloudWatch 경보가 트리거되면 대기 중인 사용자에게 알림이 전송됩니다.
- Amazon SNS 주제를 생성하고 대기 중인 팀 이메일 주소를 구독자로 구성합니다. 경보에 대한 보조 Amazon SNS 주제를 생성하고 CloudWatch 경보가 트리거될 때 이 주제를 알리도록 구성하십시오. 경보가 트리거될 때 HTTP POST를 통해 애플리케이션에 알리는 이 주제에 대한 HTTP 구독자를 생성합니다. AWS SDK 도구를 사용하여 애플리케이션을 Amazon SNS와 통합하고 대기 중인 엔지니어가 알림을 받을 수 있도록 첫 번째 주제로 메시지를 보냅니다.
- 각 대기 그룹에 대해 Amazon SNS 주제를 생성하고 팀원 이메일을 구독자로 사용하여 이들 각각을 구성합니다. 다른 Amazon SNS 주제를 생성하고 CloudWatch 경보가 트리거될 때 이 주제에 알리도록 구성하십시오. 경보가 트리거될 때 HTTP POST를 통해 애플리케이션에 알리는 이 주제에 대한 HTTP 구독자를 생성합니다. AWS SDK 도구를 사용하여 애플리케이션을 Amazon SNS와 통합하고 근무 중에 올바른 팀 주제로 메시지를 보냅니다.
- 귀사는 높은 애플리케이션 가용성을 요구하면서 높은 빈도로 새로운 기능을 릴리스합니다. 애플리케이션의 A/B 테스트의 일부로 애플리케이션의 업데이트된 각 Amazon EC2 인스턴스의 로그를 거의 실시간으로 분석하여 각 배포 후 애플리케이션이 완벽하게 작동하는지 확인해야 합니다. 로그에 비정상적인 동작이 표시되면 인스턴스의 애플리케이션 버전이 더 안정적인 버전으로 변경됩니다. 고가용성 방식으로 로그를 전달하고 분석하기 위해 다음 중 어떤 방법을 사용해야 합니까?
- 내구성을 위해 로그를 Amazon S3로 전송하고 Amazon EMR을 사용하여 매시간 배치 방식으로 로그를 분석합니다.
- 로그를 Amazon CloudWatch Logs로 전송하고 Amazon EMR을 사용하여 매시간 배치 방식으로 로그를 분석합니다.
- 로그를 Amazon Kinesis 스트림으로 전송하고 소비자가 실시간 방식으로 로그를 분석하도록 합니다.
- 로그를 대규모 Amazon EC2 인스턴스로 전송하고 라이브 방식으로 로그를 분석합니다.
- 로그를 각 인스턴스에 로컬로 저장한 다음 Amazon Kinesis 스트림이 실시간 분석을 위해 로그를 가져오도록 합니다.
- Amazon S3를 데이터 저장소로 사용하는 코드 리포지토리가 있습니다. 보안 제어에 대한 최근 감사 중에 Amazon S3 버킷의 데이터 무결성 유지에 대한 몇 가지 우려가 제기되었습니다. Amazon S3에서 가상 사설 클라우드의 Amazon EC2에서 실행되는 애플리케이션으로 코드를 안전하게 배포하는 것과 관련하여 또 다른 우려가 제기되었습니다. 이러한 우려를 완화하기 위해 구현할 수 있는 몇 가지 조치는 무엇입니까? (두 가지를 선택하세요.)
- RFC 1918 IP 주소가 있는 Amazon EC2 인스턴스에서만 액세스를 허용하고 버킷 버전 관리를 활성화하는 조건문과 함께 Amazon S3 버킷 정책을 추가합니다.
- 객체를 삭제하고 버킷 버전 관리를 활성화하려면 다단계 인증이 필요한 조건문과 함께 Amazon S3 버킷 정책을 추가합니다.
- 구성 관리 서비스를 사용하여 AWS Identity and Access Management 사용자 자격 증명을 Amazon EC2 인스턴스에 배포합니다. 코드를 배포할 때 이러한 자격 증명을 사용하여 Amazon S3 버킷에 안전하게 액세스하십시오.
- Amazon 53 버킷에 대한 액세스 권한이 있는 Amazon Identity and Access Management 역할을 생성하고 이 역할로 애플리케이션의 모든 Amazon EC2 인스턴스를 시작합니다.
- AWS Data Pipeline을 사용하여 매주 Amazon S3 버킷의 데이터를 Amazon Glacier로 수명 주기를 지정하십시오.
- 다단계 인증과 함께 AWS Data Pipeline을 사용하여 Amazon .5.3 버킷에서 Amazon EC2 인스턴스로 코드를 안전하게 배포합니다.
- 로드 밸런서 뒤의 Amazon EC2 인스턴스에서 실행되는 상태 비저장 웹 서버 계층으로 구성된 애플리케이션이 있고 읽기 전용 복제본과 함께 Amazon RDS를 사용하고 있습니다. 자가 치유 및 비용 효율적인 아키텍처를 구현하려면 다음 중 어떤 방법을 사용해야 합니까? (두 가지를 선택하세요.)
- 비정상 Amazon EC2 인스턴스의 종료를 트리거하는 사용자 지정 CloudWatch 지표를 내보내려면 Amazon EC2 인스턴스 클러스터에 타사 모니터링 솔루션을 설정하십시오.
- 각 Amazon EC2 인스턴스에서 스크립트를 설정하여 ICMP ping을 로드 밸런서에 자주 보내 비정상 인스턴스를 확인하고 교체하십시오.
- Amazon RDS DB CPU 사용률 CloudWatch 지표를 사용하여 인스턴스를 확장하는 Auto Scaling 정책과 함께 웹 서버 계층에 대한 Auto Scaling 그룹을 설정합니다.
- Amazon EC2 CPU 사용률 CloudWatch 지표를 사용하여 인스턴스를 확장하는 Auto Scaling 정책과 함께 웹 서버 계층에 대한 Auto Scaling 그룹을 설정합니다.
- 웹 서버 계층에는 더 큰 Amazon EC2 인스턴스 유형을 사용하고 데이터 스토리지 계층에는 더 큰 DB 인스턴스 유형을 사용하여 비정상 상태가 되지 않도록 합니다.
- Amazon RDS 읽기 전용 복제본 지연 CloudWatch 지표를 사용하여 Amazon RDS 읽기 전용 복제본을 확장하는 Auto Scaling 정책과 함께 데이터베이스 계층에 대한 Auto Scaling 그룹을 설정합니다.
- Amazon RDS 다중 AZ 배포를 사용합니다.
- 애플리케이션이 현재 로드 밸런서 뒤의 Amazon EC2 인스턴스에서 실행 중입니다. 경영진이 블루/그린 배포 전략을 사용하기로 결정했습니다.
각 배포에 대해 이를 어떻게 구현해야 합니까?
- 현재 배포 중인 모든 Amazon EC2 인스턴스에서 장애 조치하도록 Amazon Route 53 상태 확인을 설정합니다.
- AWS CloudFormation을 사용하여 코드를 검증하기 위한 테스트 스택을 생성한 다음 각 프로덕션 Amazon EC2 인스턴스에 코드를 배포합니다.
- 새 Amazon EC2 인스턴스로 새 로드 밸런서를 생성하고 배포를 수행한 다음 테스트 후 Amazon Route 53을 사용하여 DNS를 새 로드 밸런서로 전환합니다.
- 더 많은 Amazon EC2 인스턴스를 시작하여 고가용성을 보장하고 로드 밸런서에서 각 Amazon EC2 인스턴스를 등록 취소하고 업그레이드하고 테스트한 다음 로드 밸런서에 다시 등록하십시오.
- 귀사는 현재 대규모 다중 계층 웹 애플리케이션을 실행하고 있습니다. 한 구성 요소는 애플리케이션의 다른 모든 구성 요소가 읽기/쓰기 작업을 수행하는 데 의존하는 API 서비스입니다. 이 서비스는 배포 중에 고가용성과 가동 중지 시간이 없어야 합니다.
이 구성 요소에 대해 비용 효율적이고 중단 시간이 없는 배포를 제공하려면 어떤 기술을 사용해야 합니까?
- AWS CloudFormation 템플릿을 사용하여 로드 밸런서 뒤에 애플리케이션을 재배포하고 각 배포 중에 새 AWS CloudFormation 스택을 시작합니다. 로드 밸런서를 업데이트하여 트래픽을 새 스택으로 보낸 다음 소프트웨어를 배포하십시오. 이전 스택을 실행 중인 상태로 두고 롤백용 버전으로 해당 리소스에 태그를 지정합니다.
- Elastic Beanstalk에 애플리케이션을 재배포합니다. 배포 중에 애플리케이션의 새 버전을 만들고 Elastic BeanStalk에서 해당 버전을 실행하는 새 환경을 만듭니다. 마지막으로 Elastic Beanstalk Swap CNAME 작업을 활용하여 새 환경으로 전환합니다.
- Auto Scaling 그룹을 사용하는 로드 밸런서 뒤에 애플리케이션을 재배포합니다. 동일한 새 Auto Scaling 그룹을 생성하고 Amazon Route53 영역에 연결합니다. 모든 인스턴스가 정상으로 표시되면 새 Auto Scaling 그룹으로 트래픽을 자동 가중치로 지정하도록 Amazon Route53을 구성합니다.
- AWS OpsWorks 스택을 사용하여 로드 밸런서 뒤에서 애플리케이션을 재배포하고 AWS OpsWorks 스택 버전 관리를 사용합니다. 배포하는 동안 애플리케이션의 새 버전을 생성하고 로드 밸런서 뒤에서 새 버전을 시작하도록 AWS OpsWorks에 지시합니다. 이전 AWS OpsWorks 스택을 종료합니다.
반응형
'AWS > DOP' 카테고리의 다른 글
[DOP-C01] AWS DevOps Engineer Professional : Part 17 (0) | 2023.03.01 |
---|---|
[DOP-C01] AWS DevOps Engineer Professional : Part 16 (0) | 2023.03.01 |
[DOP-C01] AWS DevOps Engineer Professional : Part 14 (0) | 2023.03.01 |
[DOP-C01] AWS DevOps Engineer Professional : Part 13 (2) | 2023.03.01 |
[DOP-C01] AWS DevOps Engineer Professional : Part 12 (0) | 2023.02.28 |
Comments