정리 블로그

1. 만료되는 인증서 확인하기.

만료 인증서 : recruit.---.com

DashBoard를 들어가면 'Scheduled Changes'를 통해 확인이 가능하다.

위의 사진을 보면 총 3개의 예정된 작업이 있으므로 확인이 필요함.

'Event' 내용 중 'CertificateManager renewal state change'는 인증서를 의미하며, 우측 화면을 보면 어떤 인증서가 만료되는지 확인이 가능하다.

기본적으로 Amazon에서 발급받은 인증서는 자동연장이 되는 것으로 교육을 받았으나, 아마존 초기에 발급받은 인증서라 자동 연장이 안되는 것으로 파악되며, 어느 시점의 인증서부터 수동 연장인지 확인 불가.

2. 'Certificate Manager' 서비스 확인

Certificate Manager를 들어가면 SSL 인증서를 확인할 수 있으며, 해당 화면의 'Type'에 Amazon Issued 라고 되어있는 것은 아마존에서 발급받았다는 것을 의미. 외부 인증서의 경우 'Imported'로 표기됨.

*참고로 외부에서 발급받은 인증서(Sectigo '예전 Comodo', Global Sign 등) Import가 가능함. Import 방법은 추후 인증서 교체 시기에 작성 예정

'recruit.---.com' 도메인을 찾아 클릭 후 Action -> Resend validation email 을 통해 메일로 수신 가능

(Resend validation email인 이유는...사실 인증서 만료일이 다가오면 등록된 이메일로 승인 요청 메일이 오지만, 일정 기한이 지나면 해당 메일은 유효하지 않아 재전송해야함. 만료일이 남아있더라도 이메일 유효 기간은 지남.)

- 이메일을 수신하면 위의 내용으로 메일을 받으며, Certificate Manager의 경우 글로벌 서비스가 아니라 인증서가 있는 지역을 선택. 예시 도메인은 'ap-northeast-2' 이므로, 서울 지역에 있음.

- 'Amazon Certificate Approval' 클릭

인증서 만료일이 연장되었다는 문구를 바로 확인 가능.

3. 웹콘솔에서 인증서 기한 연장 확인 방법

인증서 클릭 후 확장버튼을 클릭(체크박스 오른쪽에 화살표)하면, Validation status를 확인 가능.

'recruit.---.com' 인증서 상태 변경을 깜빡해서 다른 인증서 사진으로 교체..

4. 인터넷 창에서 인증서 확인 방법

인터넷 창에서 https://recruit.---.com 을 입력하여, 인증서를 확인.

발급대상 : recruit.---.com

발급자 : Amazon

5. 외부 인증서 만료 시

외부 인증서가 만료될 경우, 발급받은 사이트에서 연장하더라도 AWS에서는 확인이 불가능하기 때문에 다시 한번 인증서를 Import해야함.

- AWS의 ELB는 3개의 세부 항목으로 나뉘어져있으며, 인입되는 트래픽을 EC2, 컨테이너, IP 주소, Lambda 함수와 같은 대상으로 트래픽을 분산시키는 역할을 함. 애플리케이션의 고가용성, 자동 확장/축소, 보안 기능을 함.

- Health Check를 통해 LB 하단의 상태를 체크(EC2 등)

ALB(Application Load Balancer) / NLB(Network Load Balancer) / CLB(Classic Load Balancer)

- Application Load Balancer

  - 프로토콜 HTTP 및 HTTPS 트래픽의 로드 밸런싱에 가장 적합.

  - 마이크로서비스와 컨테이너 등 애플리케이션 아키텍처 전달을 위한 고급 요청 라우팅 기능 제공

     (인입된 트래픽을 PATH에 기반으로 처리)

  - 7계층(어플리케이션 단)에서 작동하며, VPC 내의 대상으로 트래픽을 라우팅

  - 1개의 EC2에서도 여러개의 포트(80, 8080)로 로드밸런싱 가능

  - URL Path 기반, Host 기반, Redirection, HTTP 헤더 기반, 쿼리 문자열 파라미터 기반, 소스 IP주소 CIDR 기반 라우팅을 지원 (Redirection의 경우, 하나의 URL에서 수신되는 요청을 다른 URL로 리디렉션 가능.)

  - Lambda 함수를 대상으로 사용 가능(Lambda 함수를 사용하여 EC2, 컨테이너, 온프레미스 서버 등으로 확장 가능)

- Network Load Balancer

  - 프로토콜 TCP, UDP 및 TLS(Transport Layer Security, 전송 보안 계증) 트래픽의 로드 밸런싱에 가장 적합.

  - 4계층(Transport 단)에서 작동하며, VPC 내의 대상으로 트래픽을 라우팅.

  - 초당 수백만 개의 요청을 처리하며 지연 시간을 매우 낮게 유지

  - 갑작스러운 일시적 트래픽 패턴 처리 최적화

  - 1개의 EC2에서도 여러개의 포트(80, 8080)로 로드밸런싱 가능

  - EC2 인스턴스, 마이크로 서비스 및 ECS로 라우팅 가능.

  - ALB, CLB의 IP는 한번 씩 변경되는 것에 반하여, NLB는 IP 변경이 없음.

- Classic Load Balancer

  - EC2 인스턴스에 기본적인 로드 밸런싱을 제공

  - 기본 로드밸런서라고 생각하면 됨.

** 내용을 정리하고 보니, CLB의 특징이 제일 적어 다른 장점이 많은 LB를 사용할 것이라는 생각을 하실 수도 있겠습니다만, 실제로 사용하다보면 저는 특수한 케이스가 아닌 이상 제일 설정이 간편하다는 이유로 CLB를 많이 사용하고 있습니다 :) AWS에서 제공하는 ELB 개념을 정리해보고자 작성하였으며, 추후 AZURE의 LB에 대해서도 정리를 진행하여 두 개의 서비스를 비교해보면 유익할 것 같습니다.

서로 다른 계정의 AMI를 공유하는 방법.

- EC2의 이미지를 생성하여 저장한다.

- 저장된 이미지는 AWS Console 좌측 'AMI'에서 확인 가능

(원본 계정)

'AMI'에서 공유하고자 하는 이미지를 클릭 후 우클릭 시,

'Modify Image Permissions' 클릭.

클릭했을 때, 팝업창.

- 'This Image is currently' 에서 Public를 클릭하면 전체 공유가 되는것 같은데, 불안해서 못해봤습니다..

- Private으로 공유하였고, AWS Account Number에 공유받고자 하는 계정의 Number 입력.

   (입력 후 Add Permission 필수)

- Add "create volume" permissions to the following associated snapshots when creating permissions: 에는 해당 이미지 원본 EC2의 Volume들이 나타나며, 박스 클릭 시 이미지 공유와 함께 Volume 스냅샷도 같이 공유됨.

(해당 내용은 아래에서 한번 더 언급 예정)

(공유 받는 계정)

'SungtaekYoo' 계정에서 공유한 AMI를 확인할 수 있습니다.(해당 이미지는 다른 AMI 공유 스크린샷이라 이름이 다르니 참고.

- 공유 완료 후 다른 계정에서 EC2내 AMI를 들어가면 보이지 않음.

- 글쓰기박스 왼쪽에 기본설정 'Owned by me'이기 때문에 보이지 않고, 클릭 후 'Private images'로 변경 후 확인 가능함.

** 이 작업은 원래 계정의 이미지를 다른 계정의 이미지로 복사하는 개념이 아님.

원래 계정의 이미지를 공유하는 개념이기때문에 공유되어있는 이미지가 원래 계정에서 이미지 삭제 혹은 Permission 제거를 한다면 공유받는 계정에서도 사라지게됩니다.(직접 테스트 결과)

** 위에서 언급하였던 'Modify Image Permission'에서 'Add ~~~블라블라' 체크하여 볼륨의 스냅샷까지 체크된 경우에 원본에서 이미지를 삭제하여도 볼륨의 스냅샷은 유지되어있으며, 해당 스냅샷으로 볼륨 생성 가능합니다.(직접 테스트 결과)

** AWS의 마켓플레이스를 통해 생성한 경우, AMI 이전을 통해 바로 생성되지 않을 수 있습니다.(저의 경우 마켓을 통해 생성한 MQ였습니다.)

이 때, 서버 생성 시에 발생하는 에러의 주소를 복사하여 이동하면 서버 생성 마켓플레이스로 들어가지는데, 해당 서비스를 Subscribe해야 생성 가능합니다.(제 기준 MQ서버 이전 시, MQ 서버 내에 모든 설정 동일. 물론 MQ서버기 때문에 송수신하는 메세지 경로 혹은 IP 설정을 다시해줘야함.)

Redis는 AWS에만 존재하는 것이 아니지만, AWS TAM을 통해 들은 내용을 기반으로 작성하였음.

EC2 RightSizing을 진행하는 방법 중 CloudFormation을 사용하는 방법.

AWS Console Login -> CloudFormation -> 'Create stack' 에서 진행.

https://s3.amazonaws.com/solutions-reference/cost-optimization-ec2-right-sizing/latest/cost-optimization-ec2-right-sizing.template

위 URL을 'Amazon S3 URL'에 넣어주면 됨.

사용중인 대역을 고려하여, CIDR Block를 설정해줌.(특정 리젼에 대한 RightSizing, 전체 RightSizing도 가능할 것 같음.) 해당 내용은 별도 문의 후 수정 예정.

이후 페이지부터는 별도의 설정이 필요하지 않음.

Stack 생성 후 RightSizing을 살펴보면 됨.

++ 해당 작업이 완료되면 S3에 Excel 파일로 생성이 되는데,

 'Compute Optimizer' 서비스를 사용할 경우에는 'CloudFormation' 보다 보기 편리함.

 - Compute Optimizer에 대한 내용은 하이퍼링크 클릭. (AWS 공식 가이드)

 -. CI/CD (Continuous Integration / Continuous Deploy || Delivery)
   >> 지속적 통합, 지속적 서비스제공, 지속적 배포
   >> 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포까지 라이프사이클 전체에 걸쳐 자동화
   >> CI : 개발자를 위한 자동화 프로세스
   >> CD : 지속적 서비스 제공 혹은 지속적 배포 
      - 적용한 변경 사항이 레포지토리에 자동으로 업로드. 운영팀은 레포지토리에서 애플리케이션을 실시간 프로드 환경에 배포.
  - CI 빌드 자동화, 유닛 및 통합 테스트 수행 후 지속적 제공 프로세스에서는 유효한 코드를 자동 릴리즈
 -. Commit 시, Build, TEST, Deploy를 자동화하는 도구
 -. 코드가 변경될 때마다 빌드, 테스트, 배포
 -. 소프트웨어 릴리즈 단계 : Commit >> Build >> Test >> Prod

** Lambda는 Deploy 시, 오류가 발생하면 Roll Back 할 수 있는 역할도 할 수 있으며, 배포 완료 후 담당자에게 Alarm을 주는 역할도 가능하기 때문에 양쪽에 포함.

* 해당 자료는 re:Invent(Goldman Sachs사 발표 자료 내용)

Amazon RDS(Relational Database Service)
- 데이터베이스를 쉽게 설치, 운영 및 확장할 수 있는 웹서비스
- 백업, 소프트웨어 패치, 자동 장애 감지 및 복구
 * Shell Access를 제공하지 않기 때문에 고급 권한을 필요로 하는 특정 시스템 절차와 테이블에 대한 접근 제한.
- 자동화된 백업 수행, 백업 스냅샷을 수동으로 생성 가능.(장애 발생 시, 데이터베이스 복원 가능)
- MySQL(3306), Aurora(3306) MariaDB(3306), PostgreSQL(5432), Oracle(1521), MS SQL(1433)을 생성하여 사용 가능.
- DB 스토리지는 세 가지 유형 (마그네틱, 범용(SSD), 프로비저닝된 IOPS(POIPS))
 * IOPS(아이옵스) Input, Output Per Second. ----> 더 상세히 찾아서 적어볼 것.

- RDS Vs. DB on  AWS EC2
  1) RDS : DBMS, HOST(VM), Datacenter, OS를 AWS가 관리 // Data, Schema 고객이 관리
  2) DB on EC2 : HOST(VM), Datacenter, OS를 AWS가 관리 // Data, Schema, DBMS, OS를 고객이 관리
 * 관리가 평이하다는 평이 있으나, 고급 권한을 필요로 하는 경우에는 RDS사용이 부적절하다. 특별한 경우가 아닌 이상은 고급 권한을 필요로하는 제약사항을 제거 후 RDS 이용
  
- RDS Sing-AZ Vs. Multi-AZ
  1) 조금이라도 이상 발생 시, 서비스에 문제가 생길 경우에는 Multi-AZ 구성 필요.
  2) Multi-AZ를 이용한다고 하더라도 비용이 2배가 느는 것은 아님. 2배 이하의 비용 발생
  3) RDS의 Multi-AZ는 옵션임.