<섹션 17 Elastic Beanstalk>
<184강 & 185강>
> Beanstalk 은 가장 어려운 부분 중 하나로, 애플리케이션을 안전하고 확장 가능하도록 배포하는 것을 도와준다
> Beanstalk 이 이 시험에서 중요한 이유는, 개발자 관점의 서비스임이 크기 때문
> LB, EC2s, Data Subnet 영역으로 3 Tier 로 만드는 아키텍처는 매우 보편적임. 하지만 항상 이와 같은 구조를 한다면 매번 똑같이 하기 어려움
> 사실 새발자로서는 인프라를 관리하는게 부담이며 코드만 배포하고 싶음, 하지만 DB, LB 는 모두 제어할 수 있어야 하고, Scalability 도 중요함
> 그 와중에 대부분 웹 앱은 유사한 아키텍처를 가져간다 (ALB + ASG)
> 이런 고민을 할 때 등장하는게 Beanstalk
> Developer 중심으로 앱을 배포하는 관점에 맞춰서 솔루션을 제시한다
> 우리가 봤던 모든 것을 재사용해서 알아서 배포해주는 솔루션 : EC2, ASG, ELB, RDS ... (Managed Service)
>> 용량 프로비저닝, 로드 밸런싱, 스케일링, Health 모니터링, 인스턴스 구성 등등
>> 내가 완벽히 제시해야하는 건 코드 밖에 없음. 그 와중에 각 Component 에 대해선 제어권이 모두 있음
> Beanstalk 은 Update 도 멋있게 제공한다
> Beanstalk 자체는 무료이지만, 얘가 사용하는 솔루션들은 무료가 아니다.
> Beanstalk 은 많은 언어/플랫폼을 지원 > Go, Java, Tomcat, .Net, Node.js, Php, Phython, Ruby, Docker, Custom 등등
<Components>
Application : Elastic Beanstalk Components 들의 집합 - (Environments, verisions, configs, ...)
App Versions : 앱 코드들의 현재 상태
Environments : 현재 Application Version (한번에 한 버전만 생각) 을 운영하는데 필요한 AWS 리소스들의 집합 (중요)
>>> Tiers : Beanstalk 에선 두개의 티어를 다루는데, Web Server Env Tier & Worker Env Tier (웹 서버, 작업 서버 환경)
>>> 원하는 환경을 여러 개 생성할 수 있다 (Dev / Test / Prod ...)
< Server Tier vs Worker Tier >
> Worker Tier 에서는 EC@에 직접 접근하는 클라이언트가 없고, SQS 큐가 있음.
> 메세지들이 SQS Queue 에 적재되고, EC2 인스턴스는 작업자들로 큐로부터 메세지를 가져온다. SQS 메세지의 갯수에 따라 작업자 환경이 스케일링 된다
> 개발 테스트 환경 같은 건가..?
<Beanstalk Deployment Mode>
1. Single Instance (개발 목적에 부합)
> 한 EC2 인스턴스가 한 Elastic IP 를 가지고, 이것을 기반으로 한다. 원한다면 RDS DB 를 가질 수도 있다.
2. High Availability with Load Balancer (운영 목적에 부합)
> 로드밸런서가 부하를 분산. RDS DB 마스터 /대기 인스턴스 를 필요시 등록할 수 있다
> AZ 별로 DB 가 다른건 복제 technique 을 쓰고 있다는 거겠지..?
---
<186강 - Beanstalk 첫번째 환경 실습>
Beanstalk 이동
> Web Server Env 선택 (큐 작업 처리는 Worker 선택하면 됨)
> 앱이름 선택, 그 안에서 Env Info 에 Env 이름을 기입할 수 있음 (내가 구성하려는 환경 버전) : my-app-dev
> 도메인은 자동 생성된다 + 플랫폼을 선택후, 자동 생서되는 설정으로 두었다 (Node.js 사용) / 샘플 코드 선택하면 원하는 플랫폼별로 설정된다
> 처음에는 무료 인스턴스 선택 ㅊㅊ (이게 위에서 말한 Single Instance 라, ALB 는 생성 안됨)
> 다음단계는 꽤나 복잡한 IAM 설정
> New Service Role 생성이 필요, 이 Beanstalk 은 Ec2 를 만들 것인데, 내가 원하는 권한을 구성하여 Ec2 인스턴스가 operation 을 수행할 수 있도록 권한을 묶어서 IAM Profile 을 만들어야 한다
> IAM 으로 이동후 Role 형성후 EC2 타입, 그리고 Permission policies 에 Beanstalk 을 입력 후 WebTier, WorkerTier, Multicontainer Docker 를 누른다. 이정도면 시작하는데 충분하다고 함.
> "aws-elasticbeanstalk-ec2-role" 이거라는 이름으로 Role 을 만들었음, 이걸 beanstalk 의 Service Role 이 이용할 것임
> 3~5단계는 Optional, Skip to Review 로 이동. 지금은 그냥 해보는 것이기 때문, 첫 Beanstalk Environment! 생성 완료
> 이 후 Events 에 뭐가찍히는 것을 볼 수 있는데, 이건 CloudFormation 에서 만드는 것임. CF를 보면 Stak 하나가 형성되어 있는데, Behind 에서 Resource 들을 만들기 위해 Stack 이 생성된 것임. Template 을 보면 지금 하고 있는 일을 볼 수 있
다. 이 때 Designer 를 선택하면 훨씬 설계 도면적으로 볼 수 있다 (현재 Application Composer)
> Security Group, Auto Scaling Group, Elastic IP 등등을 확인할 수 있음 (모든 Beastalk 이 만드는 리소스들은 내부적으로 CloudFormation 이 만들고 있음을 알 수 있다)
> Task 를 보면 SG, EC2 띄운다 이런 것들을 볼 수 있음. EC2 로 이동하면 EC2 하나가 띄워졌음을 볼 수 있음 (프리티어로 t3.micro 사용 중)
> Elastic IP 까지 형성되었고 매핑되었음을 알 수 있다. ASG 도 생성되었고 Instance Management 로 들어가보면 방금 만든 EC2 를 managing 하고 있음을 알 수 있음
> 다 완료되면 상태:OK 로 떠있고, 아래 도메인을 누르면 접속이 가능하다 (Beanstalk 으로 구성된 환경 즉, Ec2 단일 인스턴스에 접속할 수 있다, 설정한대로 Node.js 로 만들었음)
> 생성한 Env 살펴보기
> Env 에서 Upload and Deploy 를 누르면 새 버전으로 업데이트할 파일을 선택할 수 있다 (빌드 파일 올리는건가..? 빌드나 실행파일?)
> health / Log / monitoring 가능 / Alarm 도 조회 가능 / Managed Updates 도 확인 가능 / configuration 보면 내 Beanstalk 설정들을 확인할 수 있다. (제법 복잡한데, 당장 이정도로 충분하다)
> 내 애플리케이션에 대한 두번 째 환경도 생성할 수 있다. 가령, application-production 을 사용할 수 잇지만, 운영시에는 정말 많이 리소스를 점검해야 한다
<마무리>
> Beanstalk 은 코드 및 코드의 환경을 중심으로 동작한다
<187 강 - 두번째 환경 실습>
> 또 만드는데, 또 웹서버고, 이번엔 prod 로 만들어보겠다 (개발 환경과 운영 환경을 셋업한 거임)
> 다 똑같이 만들었는데, Preset 에 high availability 로 만든다. (비용은 좀 들것임, 걍 하자 ㅅㅂ 오늘 중으로 17강 다 들어야겠다), Role 도 그대로 사용
> 네트워킹을 좀 보자
>> VPC 요구사항 있따면 알아서 하면 됨 (내가 사용하고 있는 VPC 일단 선택하고 가자)
>> 고가용성이니까 모든 서브넷에서 시작하고 ㅣㅍ음
>> LB 쓸거니까 EC2 인스턴스에 Public IP 는 필요 없음
>> Database 쓸 거면 주의해야 하는게, Environment 라이프사이클에 DB도 포함된다. Env 종료 및 삭제시 DB도 모두 삭제됨을 반드시 명심 (스냅샷해서 복원 이런건 당연히 가능), 강의에선 안씀
>> 인스턴스를 구성해보자.
>> Root 저장소가 있는지 Security Group 제어할건지,
>> 용량에 Auto Scaling Group 에는 Load Balancing 을 설정해 줄 수 있고, 거의 모든 ASG 설정을 해줄 수 있다
>> Scaling 설정도 할 수 있다. network out, average, min, max, threshold 등등
>> 로드 밸런서 네트워크 설정 > Public 하며, 4개의 서브넷을 담당한다. Type 은 ALB 로 할 수 있다
>> 로드 밸런서 추가 설정 : 리스너, 프로세스, 규칙, 로그 파일 액세스 다 설정할 수 있다고 ㅏㄴ다.
>> Health Reporting 을 보자
>> Beanstalk env 에서 주요 event 들을 email notificaiton 으로 받을 수 있다
>> Rolling Update 도 곧 다룰 것, 시험에 매우 중요
>> Platform SW :: Amazon X-Ray 기능을 사용하고 싶은지, CloudWatch 에 로그 스트리밍을 하는지 등등을 설정할 수 있다
>> Beanstalk 은 이처럼 강력한 서비스이다. (prod 도 정상 배포 했다)
> 이와같이 Prod 까지 만들었으며 동일한 App 이 다른 방식 (다른 Env) 로 동작하는 두가지 환경을 구성했음을 알 수 있다 (개쩔긴 ㅏㄴ다 ㅋㅋㅋㅋㅋㅋ)
> 로드밸런서도 생성되었고, 등등을 확인할 수 있음
> 근데 궁금한게 ALB 는 기본으로 ㅏㄴ들어주는거임? 아까 DEV 했을 때는 안만들어줬다 아님?
>> Answer :: 싱글 인스턴스로 했는지, High Availability 로 했는지의 차이임.
< 여기서 잠시 각 Beanstalk 이 만들어 준 환경 살펴보기 >
1. Single Instance (my-application-dev Environment)
체크포인트
1. 기본적으로 Security Group 을 만들어주는데, 해당 인스턴스에 인바운드 80 번 포트를 열어줘서 외부로 HTTP 프로토콜로 접근할 수 있게 한다
2. EC2 에 대해 기본 Elastic IP 를 붙여준다
3. 필요시 RDS 를 붙여줄 수 있지만, default 로 만들어주진 않는다
4. Auto Scaling Group 도 만들어주지만, 한 서브넷에 종속 시켜서 그런지 최소 최대가 1로 지정되어 있다 (따라서 ASG 자체의 원초적인 역할에서는 무의미 하지만, 추후 설정 변경에 용이하도록 만들어주는 것인 듯 하다) 또한, ASG 자체는 Health 가 체크되지 않을경우, 자동으로 인스턴스를 재기동해주는 역할도 한다.
5. 한 서브넷에만 종속되어 있도록 생성된다. (좀 중요한 부분을 생각해봄)
(여기서 좀 이해 안되는게 있음. Beanstalk 싱글 인스턴스로 생성할 때 네트워크 가서 VPC 선택하면, 맨 처음에 단일 인스턴스로 한 설정이 사용자 지정으로 바뀜)
(모드 선택하는 [사전 설정] 탭 보면 이렇게 적혀 있음 : 사용 사례와 일치하는 사전 설정에서 시작하거나 사용자 지정 구서을 선택하여 권장 값을 설정 해제하고 서비스의 기본값을 사용합니다)
(내가 보기엔 VPC는 default VPC (해당 리전에 대한) 로 자동으로 설정되고 서브넷도 그 중 하나 알아서 골라서 단일 인스턴스를 배포해주는거임)
(직접 VPC 고르고, 서브넷 고르는 순간부터 단일 인스턴스는 아닌것인듯? 물론 내가 서브넷 하나만 고르면 사용자 지정으로 단일 인스턴스 배포를 하는 것일테고)
(이거 무조건 선택사항3번? 부터 설정하기 시작하면 맨 앞에 사용자 지정으로 변경됨!!, 사용자 지정 외에 것들은 무조건 시스템이 제안해주는 방식대로 가라는 것인듯)
2. High Availability (my-application-prod Environment)
체크포인트
1.로드밸런서가 생성되고, 기본적으로 세팅이 설정된다 (ALB 는 외부로 80 포트 열려져서 HTTP 통신을 수용하도록 개방된다. 생성된 EC2 의 보안 그룹은 ALB 의 보안그룹으로부터만 들어오는 요청을 80포트로 허용하는 규칙밖에 없다)
2. ASG 에서 최대 갯수가 4개로 늘어나고, 담당하는 Subnet 이 4 곳으로 늘어나있다. (즉 Scaling 이 가능한 상태이다)
3. EC2 에는 탄력적 IP 가 부여되지 않는다. 그대신 ALB 의 DNS 가 부여되고, 해당 부분으로 통신을 요청해도 정상적으로 EC2 에서 수신이 된다.
========================================
<188 강 - Beanstalk 배포 모드 : Deployment Options for Updates>
1. All At Once (Deploy all in one go)
> 한번에 모든 인스턴스를 배포함. 가장 빠르지만, 인스턴스들이 업데이트되는 동안 제공중이던 서비스들이 잠시 중단될 수 있다.
> 4개의 인스턴스 v1이 있다.
> v1 을 모두 멈춰버린다. 그리고 그 이후 v2 4개를 띄운다. (Beanstalk 이 "각 원래 있던 해당 인스턴스에 v2 를 배포시켜준다)
> 가장 빠른 배포, App 이 다운 타임이 있음
> 개발 환경에 좋고, 빠른 배포가 중요하고 다운타임을 그렇게 신경쓰진 않아도 될 때. 그리고 추가 요금이 없어서 싸게 하고 싶을 때
2. Rolling
> 한번에 진행이 아니라"Bucket"이라는 인스턴스 묶음으로 묶고, 그 단위별로 동시에 업데이트, 첫 번째 버킷 상태가 괜찮으면 두번째 버킷으로 넘어감
> 앱은 기본적으로 용량 이하로 실행되며, 얼마나 덜 쓸지는 설정해 놓을 수 있다. (Bucket Size 를 설정한다고 부름)
> v1 4개가 있따고 하고, Bucket Size 가 2 라고 하자. 그러면 첫 두 개의 앱이 종료된다. V1 두개는 기동중이다. v2 두개가 기동된다. 그 이후로 v1 두개가 다운되고, 나머지 v2 를 배포해서 v2 4개가 된다
> Rolling Update 그 때 했던 그거랑 똑같음. bucket size 도 그 때 다른 이름으로 설정했었음
> 어느 시점에 두 버전이 동시에 운영되고 있음, 추가 요금이 역시 없음, 설정에 따라 오래걸릴 수도 있는 배포
3. Rolling with Additional Batches
> Rolling + new Instance 할당하여 move the batch 를 진행 (기존 app 들을 계속 가동시킴?)
> 위에 2번은 어느 시점에 4개의 인스턴스 중 2개만 운영되기도 했다. 이것은 50% 의 용량만 사용하는 것이다.
> 이 옵션에서는 용량에 맞게 실행되고, bucket size 를 역시 설정할 수 있다. 참고로 살짝의 추가 요금이 있다.
> 배포가 조금 더 오래걸릴 수 있고, Production 에 적합한 방식이다.
> 4개의 V1 Ec2 인스턴스가 있다. Bucket Size 를 2로 설정했다면, 100% 기동중일때 4이므로 50% 를 설정한 것. 그러면 두개를 먼저 띄운다.
> 두개에는 V2 버전이 먼저 설치되어 있다.
> 따라서 6개의 인스턴스가 존재한다. (150%). 현재는 그 중 2개만 V2 이다.
> 이후 V1 두개를 다운 시킨다. 그리고 V2 두개를 더 만든다. 그리고 V1 두개를 또 다운시킨다. 그리고 V2 두개를 또 만든다. 이 시점에는 V2가 6개 돌아가고 있다.
> 마지막으로 두개가 종료된다
> 중요한점 : "언제나 용량에 맞춰 실행하고 있다" > 처음에 100% 기동중인 4개의 인스턴스 기준으로, 항상 100% 이상이 기동중이다. (최소 4개)
> 어떤 시점에는 over 100% 이기 때문에, 살짝의 요금이 더 붙는 것. (요금 더 붙냐 여부도 나올 수 있음)
4. Immutable (변경 불가능)
> ASG에 인스턴스가 있을 때, 새 인스턴스를 다같이 배포한다. (한번에 배포한 다음 버전 놈들이 다 "정상" 체크 되면 기존 것들을 삭제한다)
> Zero Downtime 보장이지만, 이거부터는 "새 인스턴스"에 배포되는 것.> 이 인스턴스는 임시 ASG에 연결된다 (정확한 동작은 예시랑 함께 읽으셈)
> 새 ASG가 필요하므로 용량을 두 배로 쓰게 됨. High Cost, Longest Deployment 이다. (다만, 실패시 Rollback 은 ㅈㄴ 빠르다. 새 ASG 삭제만 하면 됨)
> PROD 환경에서 돈을 좀 더 지불하면 제일 나은 옵션이라고 함
> Current ASG 3 개 V1 있으면, 새 Temp ASG 를 만들고, 하나를 우선 띄운다. 그리고 한 인스턴스가 정상이면 나머지 수요 갯수만큼 다 띄운다.
> 이 후 두 ASG를 MERGE 하게 된다!!! 임시 ASG에 있는 인스턴스들을 Current ASG 로 옮긴다. 현재 6개의 인스턴스가 Current ASG에 있다.
> 옮긴 뒤 v1 3개를 모두 삭제한다. 그리고 temp ASG 도 모두 삭제한다.
5. Blue Green
> 완전히 새로운 Environment 를 생성하고, 준비가 되면 switch over 한다
> Zero Downtime 보장, 새로운 환경을 주기 때문에 더 많은 Test 를 가능하게 하는 등의 Release Facility (기능) 들을 제공한다
> 새로운 Environment 를 설정하고, 다음 버전을 거기에 배포하는 것이다.
> 이전에는 모든 배포 전략은 다 같은 환경에서 ㅣ루어졌지만, 이 배포만큼은 "새 환경"을 생성한다
> 새 Environment (Green이라고 부름) 을 독립적으로 검증할 수 있고 문제 발생시 Rollback 할 수 있다.
>> 독립 검증에 대한 ex : Route 53 를 사용해 트래픽이 두 방향으로 흐르는 것을 제어하면서 진행할 수 있다. 이 때, 가중치 기반 정책 설정, 약간의 트래픽을 새 Green 환경으로 조금씩 흘려서 운영 테스트를 할 수 있다. (문제 없는지, 유저들 잘 사용하는지 등)
> 새 Environment 에 대한 Test 가 끝나면 "URL Swapping" 을 해서 즉시 전환을 진행할 수 있다. (블루환경 종료 후 URL 스와핑)
> Elastic Beanstalk 이 직접적으로 제공하는 기능은 아니라, 수동적인 작업이 제법 필요함
> 내가 보기엔 6번 같은 경우는 같은 환경 내부 ASG 정도 수준에서 분리시켜두는 거라 ALB 로 라우팅 해결이 가능하지만, 이거는 Environment 자체가 바뀌는 거라 Route 53 영역에서 해결하는 듯? 같은 환경 안에서는 URL 이 동일할테니
> Green Environment 인 V2 를 새로 만들어서, 10% 의 트래픽을 누수시키면서 전체적으로 정상 동작을 확인한다. (두 환경 모두 동시 운영)
6. Traffic Splitting
> Canary Testing 용 옵션으로, 카나리 테스트는 앱 트래픽의 일부%를 새로운 버전으로 전송해 나가면서 진행한다
> 새 버전의 앱들이 Temporary ASG 에 배포된다. (둘의 용량은 기본적으로 같은 양으로 채운다) // 따라서 ㅏ용하는 EC2 전체 용량이 두 배가 된다.
> 어느 정도의 시간동안 전체 트래픽의 일부 % 가 Temp ASG 로 요청된다.
> ALB 가 있고, 얘가 90%, 10% 분할하는 거다. 새 임시 ASG 의 상태를 모니토링한다. 배포 실패 혹은 메트릭이 이상하다면, 매우 빠르게 롤백이 동작한다. 빠른 이유는 임시 ASG 를 종료만 하면 되기 때문
> Zero Downtime, 모든 것이 안정되면 Temp ASG -> Main ASG 로 인스턴스들이 옮겨지고, 이 때는 200% 의 용량으로 실행된다
> 그리고 V1 인스턴스들을 삭제시키고, Temp ASG 도 삭제시킨다.
> "모든 과정의 자동화", "Blue Green" 방식에서 크게 발전한 방식
> AWS 에서 제공해주는 문서 참고, 매우 깔끔하게 정리된 표
>> https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html
> 표를 보며 다시 이해해보기!!! Beanstalk 의 배포 ㅐ커니즘 관련하여 배포 방법들 각각의 제약사항, 특징, 요구 조건을 기반으로 하는 시나리오 문제들이 1,2개 나옴
========================================
<189 - 배포 모드 실습>
> 만들었던 Prod Env 로 옴 > 구성 > 업데이트,모니터링, 로깅으로 이동 > 편집시 정책 설정 가능
> All at Once - 설정값은 상관 없음 (UI 만 있는 것)
> Rolling, R-with additional batch, 같은 경우 Batch Size 설정 가능 (ex: 30%, 1 instance at a time)
> Immutable - 설정값은 상관 없음 (UI 만 있는 것)
> Traffic Splitting - 새 버전으로 트래픽 나누고, % 설정 가능
> (참고) Configuration Update > EC2 자체를 업데이트 하거나 VPC 구성을 변경하는 등 사용하는 설정 (시험에 크게 나오진 않음)
> 실습에서는 Immutable 을 적용함
> Sample Applicatino Node.js Beanstalk 이라고 구글링을 하면 node.js.zip 을 다운받을 수 있음 > 다운받아서 변경후 업데이트 버전을 할 것임 (백그라운드를 Green -> Blue 로 변경)
> Upload and Depoy 에서 방금 이 zip 파일을 올려준다. MyApplication-Blue 라는 Label 로 올리면, UI 에선 Immutable 방식임을 확인해준다
> Immutable 의 동작 방식을 실제로 살펴볼 수 있다 (Events Log 를 볼 수 있다)
> Immutable 방식은 한 인스턴스를 배포하고 health 상태를 점검한다
> 그 전에 Temporary ASG 를 만든다. 이 ASG에 방금 말한 인스턴스를 띄울 것이다.
> EC2 가 생성되었고, health check 를 통과하는걸 기다리고, 성공하면 나머지를 띄우는데, 현재는 한개만 대상이므로 나머지를 띄우진 않는다.
> 그러면 옮기고 ASG 삭제하는건가? 정확한 로그를 이해하지 못하긴 함
> 아무튼 Immutable 배포가 종료되면 재접속시 파란색으로 변경되어 있는걸 확인할 수 있음
> 환경 도메인 Swapping 이란 기능이 있음
> 가령, 내가 새로운 production 환경을 SU 하기 위해 prod2 라는 환경에서 작업을 했음.
> 작업이 끝난 이후 prod2 가 기존 배포인 prod1 의 URL 에 배포되기를 원함 (유저들에게 배포된 것, 즉 사실상 prod2 는 staging 서버였던 것)
>> 과정 : prod 에서 Swap Environment Domain 을 선택 > Swap 선택
>> 이 과정에서 내부적으로 DNS 를 변경하는데, DNS 는 업데이트가 좀 느리기 때문에 5~10분 꽤 기다려야함. 그 이후로는 정상적으로 변경된것을 확인할 수 있음
>> 이 Swapping 이 그냥 URL Swap 인듯??
<190강 - Beanstalk CLI 및 배포 프로세스>
> Beanstalk CLI 라는 추가적인 CLI 를 설치할 수 있다 (EB cli)
> CLI 에서 Beanstalk 이 훨씬 쉽게 사용된다
>> ex : $ eb create, status, health, events, logs,...
> UI 콘솔에서 했던 것들을 명령어로 진행할 수 있음
> Pipeline SU 할 때 많이 사용하는 명령어로, CDA 시험에는 나오진 않음.
> 하지만 알아둬야 할 것은 CLI 를 사용해서 Beanstalk 의 효율성을 높이는데 사용할 수 있다는 점.
<CLI Beanstalk Deployment Process>
> Dependency 설명 필요 (requirements.txt for Python, package.json for NOde.js 등등)
> 모든 코드를 zip 으로 묶어야 하고, 위 dependency 파일에 종속성을 알려줘야함
> Upload Zip file to beanstalk -> 188강에서 배운 방식들로 새 버전을 업데이트하고 배포할 것이다 (CLI 나 Console 을 사용하는 것 똑같음)
>> CLI 를 사용할 때는 AWS 가 Application 용으로 자동으로 만들어준 S3 에 (이거 S3 가면 볼 수 있음) 우선 이걸 올리고, Beanstalk 에서 이 S3 를 참조하는 방식으로 진행된다
> EB CLI 는 시험 범위 밖의 내용, 이런 CLI 들이 배포 자동화에 도움을 준다는 것만 알아두자
<191강 - Beanstalk 수명 주기 정책 개요 + 실습>
> Beanstalk 에는 계정 내부 최대 1000개의 앱 버전을 저장할 수 있다 (어느 시점에 이전 버전들을 지우지 않으면 버전 업데이트가 안될 수도 있다 (용량문제))
> 따라서 Beanstalk Lifecycle Policy 를 사용해 Old Version 들을 순차적으로 삭제할 수 있어야 한다 (당연히 현 버전은 삭제하지 않는다)
>> Based on time (너무 오래된건 삭제), Based on space (too many version 이 존재할시 삭제)
> 혹시라도 나중에 이 버전을 확인해볼 필요가 있을 수도 있음에 따라, Source Bundle(?) 은 삭제하지 않고 S3에 보관할 수 있는 옵션이 있다
<실습>
> 환경이 아닌 Application 자체로이동 후, application versions 로 이동 > 배포한 버전을 확인할 수 있음)
> S3 로 이동하면 beanstalk 에서 자동으로 만들어준 S3 도 확인할 수 있다 (몰라씀) > Environment 가 아닌 Application 을 만들면 S3 를 만들어주는 것으로 추정, 그리고 Environment 구성시 내부적으로 resources/environments 경로 안에서 환경들을 구분을 지어준다
> 이 S3 는 내 Application Version 들을 들고 있기 위해 생성된 S3임
> 나는 버전 업데이트 하는걸 안했기 때문에 (환경에서 업데이트 하는거) Application Version 을 봤을 때 아무것도 있지 않다.
> 아까 Application Versions 에서 Setting 으로 들어가면 수명주기 정책을 설정할 수 있다
>> 활성화한 후, 갯수를 200~1000개로 조절할 수 있고, age 로도 조절할 수 있다 (ex: 180 일 뒤엣는 삭제해라) > "사용되지 않고 && 수명주기 정책에 걸리는 애들" == "삭제"
> 그 아래 "Retention" 이란 옵션을 확인할 수 있는데, 이 옵션은 Beanstalk 에서 삭제를 해도 S3에선 어떻게 할지 확인하는것이다
>> 나중에 혹여나 사용할 가능성이 있다면 REtain 옵션 선택
> service role 은 Beanstalk 권한들을 가지고 있는 Service Role 을 (예전에 만든거) 그대로 사용
<192강 - Beanstalk Extensions>
> beatsalk 에는 코드가 포함된 Zip 파일을 업로드 하는 방식으로 배포가 진행된다
> UI 로 세팅한 모든 것들을 FILE 을 통해서 코드와 함께 업로드 할 수 있다는 듯?
> Requirements
>> 설정을 위한 모든 Config 파일은 root 디렉토리 내 .ebextensions/ 라는 디렉토리 안에 있어야 한다
>> YML/JSON 포멧 이며, 확장자는 .config 로 끝나야 한다 (포맷과 확장자가 별개임)
>> Default Setting 도 조금은 변경할 수 있는데, option_settings 라는 document 를 사용한다
>> RDS, ElasticCache, DynamDB 와 같은 리소스들을 추가할 수 있다 (이런 것들은 콘솔을 통해서 할 수 없던 것들이다)
> .ebextensions 안에서 관리되는 이런 리소스들은 배포한 Environment 가 삭제되면 같이 삭제된다
<실습>
> 아까 다운받았던 node js 샘플 파일에서 놀아본다.
> Root 디렉토리에 .ebextensions 라는 폴더를 만들었다
>> 그 안에 environment-variables.config 라는 파일을 만들었다. (두가지 조건을 만족한다)
> 샘플이 다음과 같이 세팅되어있다
option_settings:
aws:elasticbeanstalk:application:environment:
DB_URL: "jdbc:postgresql://rds-url-here.com/db"
DB_USER: username
> 이제 Root 에서 전체를 zip 으로 만들고 upload & deploy 에 이 버전 zip 파일을 업데이트 했다
> 배포된 후 Environment Properties 를 확인하면, Key 와 Value 에 내가 넣은 option_setting 값들이 들어가 있는 것을 확인할 수 있다
> 콘솔에서 넣은게 아니라 위에 지정한 파일에 들어있는 값들
> EB Config 파일이 하는 역할을 이해해볼 수 있다
> 환경변수가 중요한게 아니라, ebextensions 폴더를 통해서 config 파일들을 넣어서 beastalk 의 기능을 extension 해줄 수 있는게 중요한 것
<193강 - Beanstalk 과 CloudFormation>
> Beanstalk 은 내부적으로 CloudFormation 이라는 리소스에 의존하고 있다
> CloudFormation 이란 다른 AWS 서비스를 프로비저닝 하는 리소스인, Infrastructure as Code 형식 (다음강에 배움)
> 이걸 왜 언급하냐면, 방금 살펴본 .ebextensions 폴더의 CloudFormation 리소스를 사용하면, AWS의 원하는 어떤 것이든 프로비저닝 할 수 있다 (Cache, S3 등등)
> Beanstalk 의 좋은 점은 비록 UI 가 config 할 수 있는 것은 적게 제공하지만, ebextensions 와 CloudFormation 을 활용하면 AWS 상에서 원하는 모든 것을 구성하도록 확장될 수 있다는 점
<실습>
> CloudFormation 으로 이동해본다
> 이번 강의에 두가지 Environment 를 만들었는데, 이에 맞춰 두가지 서로 다른 스택이 있다. (env, prod 각각)
> env 를 클릭해 보면, CloudFormation Template 을 확인 할 수도 있다.
> Resources 로 이동하면, CloudFormation 이 생성해준 모든 리소스들을 확인할 수 있다. (ASG, ASG Launch Config, Elastic IP, EC2 SG 정도)
> prod stack 으로 이동하면 16개의 리소스나 만들어줬음을 알 수 있다 (위에서 생성해준거 그려보겠답시고 그려본건 정말 새발의 피 수준이였던 것)
>> ASG, ASG Config, Scaling Policy 한두개, CloudWatch Alarm -> 스케일링 정책에 사용됨, EC2 SGs, Elastic Load Balancer, ELB Listening Rules, ELB Target Group (Elastic Load Balancer)
> CloudFormation 은 Beanstalk 과 연동되므로, 이를 사용해 Beanstalk 이 Elastic Cache, Dynamo DB, S3 등을 활용할 수 있다. (앱에 대해 사용자가 원하는 어떤 것이든!)
> 섹션 18 에서 CF 에 대해서 ㅈㄴ 배우니까 걱정 ㄴㄴ. 그냥 Beanstalk 도 CloudFormation 이 해주는거다 ㅇㅇ
------------------
<194강 - Elastic Beanstalk Cloning /복제>
> 기존 환경을 복사해서 동일한 환경을 구성할 수 있다
> 동일한 환경에서 Test 환경을 만들어버릴 수 있다. (운영 환경 복제해서 Test 환경 구성)
> 리소스와 설정 모두 보존됨
>> 로드밸런서 유형과 구성, RDS DB 타입 (데이터는 당연히 보존 안됨), 환경변수
<실습>
> 환경에서 > Action 에 Clone Environment 있음
> 설정할 수 있는게 맞지 않음. service role, platform 정도 필요시 변경해서 clone 할 수 있다
> 물론 Clone 뜬 다음에는 변경하고 싶은 설정을 변경할 수 있다.
> 보통 목적은 Test 용으로 새로운 버전을 Staging 하고, 배포 준비가 되었다면 운영 도메인과 Swap 하는 용도로 자주 사용된다
> 매우 유용한 기능인듯??
<195 강 - Beanstalk Migration>
> Env 를 생성하고 나면 Load Balancer 의 유형은 변경이 불가능, 구성만 바꿀 수 있다
> 원래 그런듯? 이전에도 Classic Load Balancer 생성 뒤에 ALB 로 변경 불가능했지? 이런 소리 하심
> Beanstalk 에서 CLB -> ALB -> NLB 등과 같이 업그레이드를 하고 싶으면, 단계에 따라 마이그레이션을 수행해야 한다
>> 1. Load Balancer 를 제외한 나머지를 생성한다 (지난번에 배운 복제 기능에서는 LB 까지 똑같이 Cloning 하기 때문에 수동으로 직접 나머지 Env 를 구성해야 한다 ㅋㅋ)
>> 2. 새 Env 에는 내가 원하는 업그레이드 된 LB 를 부착시킬 수 있다
>> 3. 이제 트래픽을 이전해야 하는데, 이 때 CNAME Swapping 을 하거나, Route 53 를 이용해서 DNS 업데이트를 수행할 수 있다. (이해 필요!)
>> 4. 이후 Old Beanstalk 을 삭제해준다
< RDS with Elastic Beanstalk >
> Beanstalk 로 RDS 를 프로비저닝 할 수 있다
> Production 환경에서 이런 적용은 그렇게 권장사항은 아니라고 한다 (Environment 생명주기에 RDS 가 종속되어 있기 때문에, 백업이 없다면 Env 종료시 모든 데이터가 날라갈 수 도 있다)
> 배스트는 DB 서버를 따로 두는 것. DB 를 외부로 두고, 환경 변수 등을 이용해서 Connectino 을 맺어준다.
< Beanstalk Stack 에 이미 있는 RDS 를 어떻게 분리할 수 있는가? >
> 1. 혹시 잘못될 상황을 대비해 RDS DB 의 Snapshot 을 생성해둔다 (백업 데이터 존재)
> 2. RDS 콘솔로 가서 RDS DB가 삭제되지 않도록 보호한다 (삭제되지 않는 방패)
> 3. 새로운 Elastic Beanstalk 을 생성해서 (RDS 빼고), 이미 존재하고 있는 RDS 로 pointing 을 한다 (이 RDS 는 이전 Beanstalk 에 종속된 RDS이다)
> 4. 이후에는 CNAME Swap (이거 Blue/Green Dep 방식 같이 수행하는거 말하는거임) 을 실행하거나, Route 53 업데이트를 실행하여, Working 을 확인한다
>> 4번의 목적은 Traffic 을 Old version 에서 New version 으로 모두 옮겨주는 것임.
> 5. 이전 환경을 삭제한다. RDS 삭제 보호를 2번에서 진행하였으니, Env 가 삭제되어도 RDS 는 삭제되지 않는다
> 6. 그렇게되면 CloudFormation 에서 Stack 삭제에 실패했다고 뜰 것이다. (DELETE FAILED STACK) >> 이 Stack 은 직접 CloudFormation 으로 가서 로그 삭제하듯이 삭제해주면됨
> 외부 RDS 처럼 이전하는 방법을 제시해줌!!
<퀴즈 타임>
1. 최소 비용은 단일 인스턴스 모드,
2. BS 애플리케이션 버전은 다수의 환경에 배포 가능 (Env 여러개 생성 가능)
3 (틀림) . Beanstalk 에서 Rust 를 제공하지 않음. 하지만 Rust 실행하라고 함. 해결책 아닌 것 : 모르겠음 ㅋㅋㅋㅋ
>> EC2 사용자 데이터 스크립트를 사용하여 스크립트 및 보안 SW 설치가 아니라고 함. ㅆㅃ 해설이 없어
5. Beanstalk 호스팅 예정 애 개발중. 새 버전이 나오면 다운타임 상관 없이 즉시 배포 : All at once ㄱㄱ
6 (공부한거 참고함). Beanstalk 호스팅 중. 문제가 있을 경우 빠르게 롤백 & 새로운 앱 버전을 지속적으로 릴리즈 하고 싶음 & 릴리즈 동안에도 전체 기능 제공.
>> "빠르게 Rollback" 에서 Immutable 생각이 나야 한다. ASG 바로 삭제하면 된다를 기억. 새로운 앱 버전 지속 릴리즈는 ㅅㅂ 뭔 다 해당하는 소리임
7. 사용자 사용동안 많은 업데이트 진행함, 가동 중지 및 추가 발생 비용 없이 새로운 기능 출시. 인스턴스 수 줄이는건 ㄱㅊ > 이건 무조건 뒷쪽으로 허용된 Rolling
8. 전체 용량 유지, 최소한의 추가ㅣ 비용으로 새 ㅓ전을 출시할 수 있음 > 추가 비용이 발생하므로 추가 batch rolling (약간 발생한다고 했음)
9. 성능 개선을 위해 Beanstalk 에서 호스팅 되는 앱에 ElasticChache 클러스터를 추가하려고함. 방법은? > CloudFormation 으로의 확장을 사용, ebextensions
> 1. 외부 굳이? 확장 가능한데? >2. 추가 구성은 ebextensions >3. ㄱㅊ아 보임. 근데config 가 뒤에 와야 하는거 아님? 4. 맞음
10 (틀림). 질문이 뭔소린질 모르겠음.. 해석이 이상한건가.. : Elastic Beanstalk의 배포 속도가 매우 느립니다. 로그를 확인한 후에는 배포할 때마다 각 인스턴스에서 애플리케이션 종속성이 해결되기 때문이라는 것을 알게 됩니다. 최소한의 영향으로 배포 프로세스의 속도를 높이려면 어떻게 해야 할까요?
> 앱 종속성이 문제라는 건가? 코드에서 제거? S3에서 제거? > 이거 ㅜㄹ다 아니고, 정답은 "사전에 종속성을 해결하고 EBstalk 에 업로드된 zip 파일로 패키징" 이라고 함. 뭔 종속성 씨발련아
11. EBStalk 은 내부적으로 CF 를 사용
12. EBStalk 에서 SSL 활성화 하려면? 3번이 제일 좋아 보임. (SSL 을 활성화한 ALB 를 extension 으로 추가하는 것)
13. EBStalk 에서는 수명주기 ㅓㅇ책을 사용하여 이전 앱 버전 삭제를 자동화해준다
14. EBStalk 에서 Test 환경 생성했고, 일부로 RDS DB 인스턴스를 연결했다. 삭제한 후 DB 를 쓰려면 RDS DB 인스턴스 삭제 를 꺼야 하는데, 그게 보기에 없으니 과정 중 하나였던 스냅샷 만들기로 함
15. EBStalk 으로 실행중, 방금 업데이트 완료. 배포한 뒤 문제가 있다. 이 때 이를 테스트 하고, 소량의 트래픽을 새 버전으로 보내면서 테스트하고 ㅣㅍ음. 씨발 해석 ㅈ같네 미친놈들. 아무튼 환경 이전을 통해 테스트 하고 싶다는 씹소린것 같으니, Route 53 이나 CNAME 교체를 할 수 있음
> 이는 트래픽 Splitting 방식임. 아 이거 잘못 생각함. 환경 단위로 하고 싶다는 건줄 알고 뒤에 Route 53, CNAME 소리 지껄인건데 그냥 새 버전 배포하고 싶다는 거임. 그럼 Traffic Splitting 으로도 충분함. 물론 Route 53 을 사용한 Blue/Green 방식도 가능. 하지만 EBStalk 에서 제공하는 옵션은 아님. 직접 해야하는 옵션이지.
16. 앱에서 테스트 실행하려고함. 현재 환경은 poord 환경이므로 테스트 하면 안됨. 이미 실행중인 환경과 유사하게 테스트 환경을 만들어야함. 어떻게 함? > 복제후, 테스트 후, 스테이징 완료되면 스와핑. (근데 나 사실 환경 Swap? 이거랑 URL Swap? 이런거 자꾸 나오는데 둘의 차이? 이런거 잘 모르겠음)
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 19 - AWS 통합 및 메시징: SQS, SNS (0) | 2024.07.21 |
|---|---|
| [CDA] 섹션 18 - AWS CloudFormation (0) | 2024.07.17 |
| [CDA] 섹션 16 - ECS, ECR 및 Fargate - AWS 의 도커 (0) | 2024.07.10 |
| [CDA] 섹션 15 - CloudFront (0) | 2024.07.09 |
| [CDA] 섹션 14 - Amazon S3 보안 (0) | 2024.07.08 |
