정리 블로그

1. AWS에서 25번 포트(SMTP)를 제한하는 이유

 -. 인스턴스에서 아웃바운드 통신정책 중 25번 포트가 오픈되어있더라도, 사용이 제한된다.(정확히는 통신이 정상과 비정상을 왔다갔다 함)

 -. 무분별한 스팸메일 발송을 제한하기 위해 필요한 목적 기재.

2. 25 포트(SMTP) 사용 신청 방법

aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

로 접속하여, 사용 신청 필요.

1) Email address는 25번포트 제한 해제 요청 후 처리 결과를 받을 수 있는 주소를 입력.

2) 
  -. 인스턴스에서 포트를 사용하고자 하는 이유 및 목적을 상세하게 입력.(스팸 발송용 방지)
     => 가급적 명확하고 자세하게 작성
  -. 사용하고자 하는 인스턴스의 리전 기재 필수
     => 한국의 경우, ap-northeast-2 

3) Elastic IP address : 해당 부분은 Optional로 기록되어있으나, 필수 기재할 것.

EIP가 있는 경우, EIP를 기재하고, Private 인스턴스인 경우, 외부와 통신할 때 사용되는 IP를 적어줄 것(ex. NAT 인스턴스 IP 등)

1. IGW가 설정되어야 구성한 VPC가 외부와 인터넷 통신이 가능. 만약 인터넷을 쓰지 않으려면 IGW가 없어도 됨. 단, VPC로 연결하려면 VPN과 VPC를 연결하는 IPSec-VPN을 연결하거나, Custom Gateway 등의 구성을 해야 VPC 내부로 접속이 가능하다. 보통의 경우, NAT-Gateway나 Bastion Host를 통해 VPC 내부와 통신하기 때문에 IGW가 필요함.

2. WEB 서버일지라도 Public Subnet보다는 Private Subnet에 위치시키고, Internet-facing LB를 통해 WEB용도의 인스턴스에 접속되게 하는 것이 보안상 안전.

3. NAT 인스턴스의 역할은 VPC내 생성된 인스턴스를 터미널(linux계열) 혹은 원격데스크톱(윈도우 계열)을 통해 접속하기 위해 필요함. 또한, Private Subnet에 위치한 인스턴스가 인터넷을 사용할 수 있게 해주는 역할도 할 수 있다.

4. AZ는 이중화를 하여 구성할 것을 추천. 단일 AZ를 사용할 경우, LB를 통해 무중단을 위한 구성에 제약이 있음.(사용 가능한 AZ 개수는 리전마다 다름)

5. Subnet은 기본적으로 6개의 구성(Public Subnet 2EA, Private Subnet 4EA)을 하고, 특별한 이유가 있지 않다면 Private Subnet에 인스턴스를 구성하여 외부에 노출되지 않도록 한다. 각각의 subnet은 필요에 따라 라우팅을 달리하여 용도에 따라 통신경로를 지정해줄 수 있다.

6. LB는 Internet-facing을 통해 대외 서비스를 할 수 있도록 한다. 대내 서비스의 경우, Internal 구성을 하도록 하자.

*위 구성도에서 DevOps User도 IGW를 통해 VPC 내부로 접속하는게 맞음.

1. Linux 부팅 문제 발생 확인

 AWS 콘솔창에서 인스턴스 우클릭 후 'Get Instance Screenshot'을 보면 위와 같이 부팅에 문제가 생긴 것을 확인할 수 있음.

화면에 Control-D를 누르면 계속할 수 있다지만, On-Prem 환경이 아니기때문에 직접 누를 수 없음. 재부팅을 계속 한다고해서 해결되지 않고 같은 부분에서 부팅 문제가 발생한다.

2. 해결방안

1. Volume Tag.

문제가 발생한 Volume에 Tag를 먼저 할 것.(다른 Volume과 헷갈릴 수 있음)

2. 새로운 인스턴스 생성 및 Mount

 인스턴스를 새롭게 생성해서 해당 인스턴스를 Attach.

Root Volume이지만, 다른 인스턴스에 Mount 시키기 때문에 위에서는 /dev/sdf 로 Attach.

parted -l

디스크 확인은 parted -l로 했음.

/dev/xvdf를 보니, Attach는 제대로 됐음.

'xvdf1' 디스크를 마운트 시킨다

'/FIX' 위치에 마운트 시켰음

'/FIX'에 들어가보면 위와 같이 Linux 기본 디렉토리들이 확인 가능함

내가 겪은 문제의 원인은 fstab을 수정했는데, 정상적으로 적용이 되지 않고 임시파일(?) 비슷한 문서 에디터 비정상종료에 따른 swap파일이 생겼음.

rm /FIX/etc/.fstab.swp

rm 명령어를 통해 삭제했음

삭제 후 umount를 통해 정상적으로 마운트 제거하여 나머지 작업 진행!

작업 완료 후 처음 인스턴스에 다시 Attach하고 부팅하면 끝!

- 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 설정을 다시해줘야함.)

1. WEB-LB와 mod_proxy & mod_jk를 통한 서버 구성
 -. WEB-Server의 Apache에 mod_jk 혹은 mod_proxy 설정을 통해 로드밸런싱 가능.
 -. WEB-Server와 WAS-Server 간의 통신 에러 발생 시, src IP 확인이 가능함.
   (src IP가 확인 가능할 경우, 통신이 비정상적인 상황에서 통신 확인 가능)

2. WEB-LB와 WAS-LB를 통한 서버 구성
 -. 통신 에러 발생 시, WEB, WAS간의 통신 에러인지, LB와 WAS간의 통신 에러인지 확인 불분명.
   (WAS-Server에서 확인 시, LB IP가 출력됨)
 -. 이벤트 등으로 인한 WAS-Server 증설 시, 추가 설정이 적음.

 -. AWS&AZURE 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 공식 가이드)

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는 옵션임.