hyeeoni

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/what-is-systems-manager.html

AWS Systems Manager

- AWS Systems Manager는 AWS 클라우드에서 실행되는 애플리케이션 및 인프라를 관리하는 데 도움이 되는 기능 모음입니다. Systems Manager는 애플리케이션 및 리소스 관리를 간소화하고, 운영 문제를 감지하고 해결하는 시간을 단축하며, AWS 인프라를 규모에 따라 안전하게 운영 및 관리하는 데 도움이 됩니다.

Systmes Manager는 인스턴스와 관련된 작업을 할 수 있는 권한을 지니고 있지 않으므로 먼저 AmazoneEC2RoleforSSM 정책에서 인스턴스 프로파일 롤을 추가해야한다. 

- 주요기능으로는 액션, 노드관리 기능이 있다.

*액션

- 액션을 이용해서 자동 또는 수동으로 개별적 또는 일괄적으로 AWS 리소스에 대한 각종 작업을 수행한다. 이들 액션은 문서에 미리 정의돼 있어야 하며, Automation(자동화), Command(명령), Policy(정책) 으로 나뉜다.

• Automatation : AWS 리소스에 대해 일괄적으로 작업을 수행. 
• Command      : Linux 또는 Windows 인스턴스에 대한 작업을 수행

*노드관리

- Systems Manager에 사용하도록 구성된 시스템이다.

• Fleet Manager는 AWS 또는 온프레미스에서 실행되는 관리형 노드를 원격으로 관리하는 데 도움이 되는 통합 사용자 인터페이스(UI) 환경입니다
• Inventory는 관리형 노드에서 소프트웨어 인벤토리를 수집하는 과정을 자동화합니다. Inventory를 사용하여 애플리케이션과 파일, 구성 요소, 패치 등에 대한 메타데이터를 수집할 수 있습니다.
• Compliance를 사용하여 관리형 노드 플릿에 대해 패치 규정 준수 및 구성 일관성을 스캔할 수 있습니다. 여러 AWS 계정 및 AWS 리전의 데이터를 수집하여 집계한 후 규정을 준수하지 않는 특정 리소스로 드릴다운할 수 있습니다. 기본적으로 Compliance는 Patch Manager 패치 및 State Manager 연결에 대한 규정 준수 데이터를 표시합니다. 또한 IT 또는 비즈니스 요구 사항에 따라 서비스를 사용자 지정하고 자체 규정 준수 유형을 만들 수도 있습니다.
• Patch Manager를 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
• State Manager를 사용하여 관리형 노드를 정의된 상태로 유지하는 과정을 자동화합니다. State Manager를 사용하여 관리형 노드가 시작 시 특정 소프트웨어로 부트스트랩되거나, Windows 도메인에 연결되거나(Windows Server 노드만 해당), 특정 소프트웨어 업데이트로 패치되도록 할 수 있습니다.

EC2 Auto Scaling

- EC2 Auto Scaling 은 애플리케이션 실패 및 복구 상황을 방지하기 위한 서비스로 실패 발생 시 사용자가 지정한 수 만큼 인스터슨의 수를 동적으로 추가할 수 있다.

- EC2 Auto Scaling은 론치 환경설정 또는 론치 템플릿을 이용해 시작할 인스턴스의 환경을 자동으로 설정하며, 인스턴스의 기본 환경설정 파라미터 정의 및 론치 시점에 필요한 스크립트를 준비한다.

- 론치 템플릿은 론치 환경설정에 비해 좀 더 최신의 기술이 반영됐으며, aws 론치 템플릿 사용을 권장한다.

- 트래픽 분산을 위해 Application Load Balancer(ALB)를 사용하는데, Auto Scaling 생성 시 ALB 타겟 그룹에 연결하면 새 인스턴스 생성시 자동으로 ALB 타겟그룹(대상 그룹)을 추가한다.

- Auto Scaling 옵션을 사용하여 애플리케이션의 컴퓨팅 용량을 늘리거나 줄일 수 있는 기능이다.

*론치 환경설정(시작 환경설정)

- 인스턴스를 직접 생성하는 경우 AMI, 인스턴스 타입, SSH 키 페어, 시큐리티 그룹, 인스턴스 프로파일, 블록 디바이스 맵핑, EBS 최적화 여부, 플레이스먼트 테넌시, 앱 설치 및 환경설정을 위한 커스텀 스크립트 등 유저 데이터를 포함한 다양한 환경 설정 파라미터를 지정해야한다. 론치 환경설정에는 이러한 정보들이 담겨있다.

- 론치 환경설정은 기존 EC2 인스턴스의 설정 내용을 복사해서 생성하거나 처음부터 새롭게 작성할 수 있다.

- 론치 환경설정은 EC2 Auto Scaling에서만 사용할 수 있으며, 론치 환경설정만 가지고 인스턴스를 직접 론칭할 수 없으며,
한 번 론치 환경설정을 생성하면 수정할 수 없다. 설정 내용 중 수정이 필요한 경우 새 론치 환경설정을 생성해야한다.

*론치 템플릿(시작 템플릿)

- 론치 템플릿은 설정 방식 측면에서 론치 환경설정과 비슷하지만 사용 방식이 좀 더 직관적이고 이해하기 쉽다.

- Auto Scaling 작업시에도 사용할 수 있지만 EC2 인스턴스 사본 생성 또는 스팟 플릿 생성의 목적으로 사용할 수 있다.

- 모든 론치 템플릿 버전 목록을 관리하므로 필요에 따라 원하는 버전을 사용할 수있고 변경 이력을 추적할 수 있어 편리하다. 

*Auto Scaling 그룹

- Auto Scaling이 관리하는 EC2 인스턴스 그룹이다.

- Auto Scaling 그룹 생성 시
    > 시작 환경설정 또는 시작 템플릿을 생성해야한다. 
    > 그 후 몇 개의 인스턴스를 프로비전하고 실행할 것인지 템플릿에 지정한다.
    > Auto Scaling 그룹의 최소 및 최대, 희망 용량 지정이 가능하다.
ex) 최소 1, 최대 10, 희망 4 이에 해당하는 용량이 지정된다는 가정하에 4개의 인스턴스 중 누군가의 실수 또는 오류로 이들 인스턴스 중 하나가 종료되면 Auto Scaling은 희망 용량 4에 맞춰 새 인스턴스를 자동으로 추가한다.
             

* ALB 대상 그룹(Target Group)  (참고한 곳)

- 대상 그룹은 사용자의 요청을 처리할 EC2의 집합이다.

- 기본 설정으로는 "Protocol : Port" 는 HTTP 혹은 HTTPS를 정의한다. 이는 대상그룹에 소속된 EC2들이 설정된 "Protocol : Port" 만 받는다는 것을 의미한다.

- 헬스 체크는 대상그룹에 소속된 EC2들의 상태를 점검할 때 HTTP 혹은 HTTPS 를 사용하겠다는 것을 의미한다.

- ALB는 HTTP 헤더를 활용할 수 있는 로드 밸런서이기에 3-way handshake 가 끝난 후에도 웹 페이지를 요청하여 상태 체크를 실시할 수 있고 경로 또한 지정할 수 있다.

*애플리케이션 인스턴스에 헬스 체크

- Auto Scaling 그룹을 생성하면 미리 정한 최소 또는 희망 용량의 인스턴스가 항상 유지되며, 생성된 인스턴스의 헬스 상태가 좋지 못하면 이를 삭제하고 새 인스턴스로 대체한다.

*Auto Scaling 옵션

- 수동 스케일링(Menual Scaling) : 언제든지 기존 오토 스케일링의 용량을 수동으로 변경할 수 있으며 변경 즉시 반영된다.

- 동적 스케일링 정책(Dynamic Scaling Policies) : 동적 조정은 트래픽의 변화에 따라 오토 스케일링 그룹의 용량을 조정한다. CloudWatch의 경고 상황을 모니터링한 결과에 따라 희망 용량을 증가시키는 방식으로 작동한다.

• 대상(목표) 추적 조정(Target tracking scaling) -Amazon CloudWatch 지표와 목표 값을 기준으로 그룹의 현재 용량을 늘리거나 줄입니다. 이는 온도 조절기가 집안 온도를 유지하는 방식과 비슷하게 작동합니다. 사용자가 온도만 선택하면 나머지는 온도 조절기가 알아서 합니다.
• 단계 조정(Step scaling) - 그룹의 현재 용량을 일련의 조정 조절에 따라 늘리고 줄이며 경보 위반의 크기에 따라 달라지는 단계 조절이라고 합니다.
• 단순 조정(Simple scaling) - 단일 조정 설정에 따라 그룹의 현재 용량을 늘리고 줄입니다. 각 조정 작업 간에는 휴지 기간(cooldown period 알람이 울려도 반응하지 않는 기간)이 발생합니다.
  > changeInCapacity: 지정 숫자만큼 희망 용량을 증가 시킴.
  > ExactCapacity: 현재 값에 상관없이 용량을 지정 숫자만큼 증가 시킴.
  > PercentChangeInCapacity: 현재 용량의 비율을 기준으로 증가 시킴.

- 예약 정책:  워크로드 패턴이 예측 가능한 경우나 용량 변화에 선제적으로 대응해 수요 증가 이전에 충분한 인스턴스를 확보하고자 할 떄 유용하다. 예측 정책은 다음과 같은 상황에 매우 적합하다.

https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/as-scale-based-on-demand.html

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/Storage.html

EC2 스토리지 볼륨

- 스토리지 볼륨으로 지칭하는 스토리지 드라이브는 물리적인 저장 장치를 가상화한 대표적인 사례 중 하나다.
- 관련된 스토리지 볼륨으로는 EBS 볼륨, 인스턴스 스토어 볼륨, EFS(파일시스템), S3 등이 있다.

*EBS 볼륨

- 지속형 스토리지 이다.
- 하나의 인스턴스에는 다수의 Elastic Block Store(EBS)를 부착할 수 있다. 
- 현재는 4가지 EBS 볼륨이 제공되고 있으며, 두가지는 SSD 기반, 두가지는 HDD 기반 기술을 사용한다. 
- EBS 볼륨의 성능은 최대 IOPS/볼륨 으로 측정한다.(IOPS는 초당 input/output 작업 횟수를 의미한다.)
    > 프로비전 IOPS SSD : 높은 수준의 I/O 처리를 해야하는 경우
    > 범용 SSD: 일반적인 기업의 워크로드를 처리할 수 있는 적당한 속도 및 성능을 가짐.
    > 처리량 최적화 HDD: 처리량이 중요한 워크로드에 사용할 수 있음.
    > 콜드 HDD: 접근 빈도가 낮은 데이터 작업에 적합한 타입.
- EBS 볼륨의 스냅샷을 생성하여 Amazon S3에 저장하면 데이터의 백업 사본을 유지할 수 있다. 스냅샷에서 새 EBS 볼륨을 만든 후 다른 인스턴스에 연결할 수 있다. 또한 AMI 생성을 위한 이미지로 변환할 수 있다.

※EBS 스토리지 볼륨 타입별 비용 비교

*EBS 볼륨을 사용해야하는 경우

- 데이터에 빠르게 액세스하고 장기적으로 지속해야 하는 경우 Amazon EBS를 사용하는 것이 좋다.
- EBS 볼륨은 세분화된 업데이트가 필요하고 형식이 지정되지 않은 블록 수준의 원시 스토리지에 액세스해야 하는 파일 시스템, 데이터베이스 또는 애플리케이션의 기본 스토리지로 사용하기에 특히 적합합니다.
- Amazon EBS는 임의 읽기 및 쓰기에 의존하는 데이터베이스 스타일의 애플리케이션과 장시간의 지속적인 읽기 및 쓰기를 수행하는 처리량 집약적 애플리케이션에 모두 적합합니다.

*인스턴스 스토어 볼륨

- 비지속형(ephemeral) 스토리지 이다. 그렇기 때문에 인스턴스를 종료시키면 인스턴스 스토어에 저장된 데이터가 손실된다.
- 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다.

* 인스턴스 스토어 볼륨을 사용해야하는 경우

- 인스턴스 스토어 볼륨은 인스턴스 서버 호스팅 시 물리적으로 부착되는 SSD 저장장치이며,  NVMe 인터페이스로 연결된다. 
- NVMe란 PCI 인터페이스를 통해 CPU에 바로 연결되는 SSD구조로, 기존의 HDD를 위해서 만들어진 SATA 인터페이스를 사용하는 SSD 보다 월등히 빠른 속도를 제공하는 차세대 SSD
- 인스턴스를 생성하면 자동적으로 인스턴스 스토어 볼륨이 생성되며 별도의 비용을 부담하지 않는다.
- 인스턴스 스토어 볼륨은 단기적인 목적으로 인스턴스를 시작하는 배포 모델에 적합하며, 외부에서 데이터를 임포드해서 사용하므로 내부에 저장된 데이터는 작업 후 삭제되도 무방하다.

*EC2 인스턴스 접속하기

- 모든 인스턴스는 최소 하나 이상의 프라이빗 IPv4 주소를 지니며 아래 범위와 같다.
    > 10.0.0.0 ~ 10.255.255.255
    > 172.16.0.0 ~ 172.31.255.255
    > 192.168.0.0 ~ 192.168.255.255
- 처음 인스턴스를 생성하면 서브넷 내에서만 인스턴스를 연결할 수 있으며, 인터넷과 인스턴스를 바로 연결할 수 없다.
- 외부 리소스와 연결하기 위한 다중 네트워크 인터페이스 환경 설정에서 인스턴스에 하나 이상의 가상 네트워크 인터페이스를 부착할 수 있다.
- 인터페이스는 기존의 서브넷 또는 시큐리티 그룹과 반드시 연결돼야 하고, 필요에 따라 서브넷 범위 내에 정적 IP 주소를 할당해서 사용할 수 있다.

* EC2 인스턴스의 보안 유지

- 시큐리티 그룹: 방화벽 같은 역할을 하며 인스턴스로 향하는 모든 유입 트래픽은 거부하고 , 인스터스에서 나가는 모든 유출 트래픽은 허용한다. 이에 그룹 동작 정의 후 유입 및 유출되는 트래픽에 대해 해당 규칙에 따라 다르게 할 수 있다.
- IAM 롤: EC2 이외 리소스에도 접속 제어가능, 특정 계정별로 리소스 접근을 관리함.
- NAT 디바이스(NAT 인스턴스, NAT 게이트웨이): 인터넷 연결 허용 없이 프라이빗 IP 주소를 통해 인터넷에 접속할 수 있다.
- 키페어
    > 퍼블릭 키와 프라이빗 키로 구성되어 있다.
    > Amazon EC2는 퍼블릭 키를 인스턴스에 저장하며 프라이빗 키는 사용자가 저장합니다
    > Linux 인스턴스의 경우 프라이빗 키를 사용하여 인스턴스에 안전하게 SSH로 연결할 수 있습니다
    > 프라이빗 키를 소유하는 사람은 누구나 인스턴스에 연결할 수 있으므로 보안된 위치에 프라이빗 키를 저장해 두는 것이 중요함.

영역 1: 복원성 아키텍처 설계
    - 멀티 티어 아키텍처 솔류션 설계
    - 고가용성 및 내오류성 아키텍처 설계
    - 적절한 복원성 스토리지 선택
    
영역 2: 고성능 아키텍처 설계
    - 워크로드 처리를 위한 탄력적이며 확장성 높은 컴퓨트 솔루션 선택
    - 워크로드 처리를 위한 고성능의 확정성 높은 스토리지 솔루션 선택
    
영역 3: 보안성 높은 애플리케이션 및 아키텍처 설계
    - AWS 리소스에 대한 안전한 접속 방식 설계

영역 4: 비용최적화 아키텍처 설계
    - 비용효율적인 스토리지 솔루션 선택
    - 비용효율적인 컴퓨트 및 데이터베이스 서비스 선택
    - 비용효율적인 네트워크 아키텍처 설계

EC2 인스턴스
- 물리적 서버를 가상화 또는 추상화한 것, 실제 서버와 차이가 없음.
- OS는 AMI로 정의돼 있으며, 하드웨어 사양은 인스턴스 타입에 따라 달라짐.
- EC2 생성 위치(aws 리전, vpc, 테넌시)는 성능의 환경 설정 측면에서 중요함.
- 인스턴스는 기본 하드웨어 전반에 분산되도록하여 장애를 줄이지만 배치를 조정하는 것이 더 유리한 경우가 있음.
- 인스턴스의 배치 그룹(Placement Group)을 사용하여 워크로드에 따라 최적의 배치를 할 수 있다. 비용 발생하지 않음.
- 온디맨드, 예약, 스팟 등 세가지 선택하여 사용할 수 있다.
- 인스턴스 라이프사이클

* AMI 종류
- Amazone 퀵 스타트 AMI
- AWS 마켓플레이스 AMI
- 프라이빗 AMI 

* 인스턴스 타입
- 범용타입(일반적), 컴퓨트 최적화(고사양 웹or 머신러닝), 메모리 최적화(DB관련), 가속 컴퓨팅(그래픽), 스토리지 최적화(대용량 파일)

*VPC
- 웹 개발 단계에서 하나의 VPC를 생성하고, 이후 베타 버전용, 최종 상용화 버전용으로 VPC를 생성해서 프로젝트를 관리할 수 있음.
- VPC를 추가하더라도 NAT 게이트웨이 or VPN에 연결하지 않으면 비용 발생하지 않는다.

*테넌시
- 종류
    > 공유 테넌시(멀티 테넌시): 하나의 하드웨어에 사용자 A,B의 인스턴스가 들어가는 방식
    > 전용 인스턴스 테넌시: 하드웨어에  A 인스턴스만 들어가고 다른 인스터는스는 들어올 수 없음. 물리적으로 분리됨.
    > 전용 호스트 테넌시: 하드웨어에 사용자 A의 인스턴스 1개만 들어가는 방식, A의 다른 인스턴스는 들어갈 수 없음.

*배치 그룹(Placement Group) (배치그룹 참고한 곳)
- 클러스터(Cluster): 근거리에 위치한 단일 AZ에 연관된 인스턴스를 론칭한다. 전송 지연 수준이 낮은 상호 연결형 네트워크를 제공하므로 고성능 컴퓨팅(HPC)에 적합하다.
- 분산(Spread): 다수 AZ를 사용하고, 서로 다른 하드웨어 랙에 인스턴스를 배치하여 인스턴스간 장애 최소화. 
- 파티션(Partition):  논리적 파티션 분리를 통해, 한 파티션에 있는 인스턴스 그룹이 다른 파티션의 인스턴스 그룹과 기본 하드웨어를 공유하지 않도록 함.

*EC2 인스턴스 라이프사이클
- 인스턴스 중지 시
    > EBS 볼륨데이터는 유지되지만, 인스턴스 스토어 볼륨 데이터는 삭제됨.
    > 인스턴스를 재실행하게 되면 Public IP는 변경되지만, Elastic IP를 사용하게 되면 고정 IP가 된다.
- 인스턴스 설정 변경 시
    > 시큐리티 그룹 정책은 언제든지 업데이트가 가능함. 
    > 인스턴스 타입 변경은 인스턴스를 중지 시킨 뒤 변경 사항을 적용한 뒤 다시 시작함.

주요내용

• 클라우드 컴퓨팅과 다른 애플리케이션 및 클라이언트-서버 모델의 차이점
• AWS 플랫폼이 안전하고 유연하게 가상의 네트워크 환경을 제공하는 방식
• AWS 기반 리소스에 접근 및 관리하는 방식
• AWS 리소스 관리와 배포를 돕는 개발자 문서 및 도움말 활용방법

1. 클라우드 컴퓨팅과 가상화

*클라우드 컴퓨팅: 실제 자신이 물리적인 서버가 없더라도 누군가가 만들어둔 물리적인 서버를 돈을 지불하고 쓸 수 있게 하는 서비스 ex) Iaas, PaaS, SaaS

• Infrastructure as a Service(IaaS)는 컴퓨팅, 스토리지, 네트워킹, 가상화 등 IT 인프라 서비스에 대한 주문형 액세스를 제공합니다. IT 리소스를 가장 높은 수준으로 제어하며 기존 온프레미스 IT 리소스와 가장 유사합니다.
• Platform as a Service(PaaS)는 클라우드 애플리케이션 개발에 필요한 모든 하드웨어 및 소프트웨어 리소스를 제공합니다. PaaS를 사용하면 기업은 기본 인프라의 관리 및 유지보수에 대한 부담 없이 애플리케이션 개발에 집중할 수 있습니다.
• Software as a service(SaaS)는 기본 인프라에서 유지보수 및 앱 소프트웨어 자체 업데이트에 이르기까지 전체 애플리케이션 스택을 서비스로 제공합니다. SaaS 솔루션은 클라우드 인프라 제공업체에서 서비스와 인프라를 모두 관리하고 유지보수하는 최종 사용자 애플리케이션인 경우가 많습니다.

*가상화: 하나의 물리적 서버 형태로 존재하는 하드웨어 리소스를 여러 개의 작은 유닛으로 나누는 것.
*프로비저닝: 어떤 종류의 서비스를 사용자의 요구에 맞게 시스템 자체를 제공.

1) 클라우드 컴퓨팅 아키텍처

클라우드 컴퓨팅 아키텍처는 스토리지, 메모리, 컴퓨트 사이클을 이용한 가상 서버를 제공하고, 활용 가능 리소스의 최적 이용이 가능하도록 네트워크 서비스를 제공한다. 사용자는 워크로드 처리를 위해 on-demend 및 셀프서비스 기반의 컴퓨트 리소스 풀에 접속하며, 이에 따른 사용 내역은 정확하게 측정돼 사용량에 따라 과금된다.

2)  클라우드 컴퓨팅 최적화

클라우드는 확장성 및 탄력성을 지니고 있으며, 전통적인 시스템에 비해 훨씬 낮은 비용이 소요되므로 변동성 높은 워크로드 처리를 위한 탁원한 선택이 될 수 있다.

• 확장성(Scalability): 확장성은 수요 증가에 따라 리소스를 증대시키는 개념. Aws 는 Auto Scaling을 사용하여 쉽게 구현 가능. 
  - Scale up : 기존 하드웨를 더 크게 교체
  - Scale down : 서버를 추가하는 것

• 탄력성(Elasticity):  탄력성은 수요 감소에 따라 리소스를 감소시키는 개념을 포함.
• 비용관리(Cost Management): 사용자가 장기적인 수요의 관점에서 불필요한 자본적 지출의 리스크를 줄일 수 있다.

2. AWS 클라우드

• 컴퓨트: 물리적 서버를 클라우드에 복제한 개념의 서비스, Auto Scailing, Load Balencing
• 네트워킹: 애플리케이션 연결성, 액세서 컨트롤, 강화된 원격 연결성 제공
• 스토리지: 다양한 객체 저장 목적, 즉각 접근 및 장기적인 백업 기능을 제공
• 데이터베이스: 관계형, NoSQL, 캐싱 등 다양한 데이터 포맷을 지원하는 dbms
• 애플리케이션 관리: aws 리소스에 대한 모니터링, 감사, 환경설정 기능
• 보안 및 권한 증명: 권한 인증, 권한 부여, 데이터 및 연결 암호화, 서드파티 인증과리 시스템과의 통합기능 제공

3. AWS 플랫폼 아키텍처

AWS는 전세계에 자사의 물리적 서버를 관리하기 위해 자체 데이터 센터를 운영 중이다.
데이터 센터는 리전(나라) 별로 여러개의 데이터 센터가 존재한다.
사용자는 자신과 더 가까운 데이터 센터에서 워크로드를 처리함으로써 네트워크 전송 지연을 줄일 수 있다.
AWS 계정으로 접속 가능한 물리적인 AWS 데이터 센터를 가용성 지역 또는 Availability Zone(AZ) 라 부른다.