[AWS] 클라우드 인프라 구축 기본 - 리소스 사용관리(CloudWatch), 가용성(LoadBalancer), 글로벌 부하분산(Route53,CloudFront), 권한 관리(IAM)

Chapter 6. 클라우드 리소스 사용 관리

Section 1. Cloud Watch/Cloud Trail

1.1 CloudWatch

- AWS CloudWatch는 준실시간 로그, 지표 및 이벤트 데이터를 자동화된 대시보드에 수집하고 이를 시각화하여 인프라 및 애플리케이션 유지 관리를 간소화합니다. 모니터링을 해야 Scale In/Out을 할지 결정할 수 있다.

- On-Prem도 붙일 수 있다.

- 알림도 붙일 수 있다.

- Auto Scaling도 자동으로 진행되도록 할 수 있다.

 

네임스페이스

어떤 서비스에서 발생한 지표인지 알아야 하므로, Cloud Watch에서는 서비스 네임스페이스를 보고 어떤 서비스에서 발생한 지표인지 알 수 있다.

 

Cloud Watch 지표(metrics)

서비스별로 정의된 지표들이 있고, 해당 지표들을 그래프 형태로 볼 수 있다.

CloudWatch 알람

- 특정 Metrics의 조건을 통해, EC2 Action, AutoScaling, Notification(SNS) 서비스를 Trigger 할 수 있다.

 

CloudWatch Logs

아래와 같은 순서로 진행된다.

Logs > Metrics > alerts > actions

 

1.2 CloudTrail

CloudWatch는 그냥 Monitoring이지만, AWS의 모든 서비스의 모든 사용 이력을 API를 통해 저장해둠

AWS의 보안 및 감사를 위한 서비스

AWS의 모든 서비스가 사용될 때마다 언제 어디서 누구에 의해 사용되었는지 로그 저장

AWS 리소스의 변경 사항을 모두 추적할 수 있음(ex. CCTV)

여러 서비스에 대해 API 이용 로그 등을 제공

- 모든 서비스는 아래와 같이 REST API Endpoint를 가지고 있음

- https://서비스코드.리전코드.amazonanows.com/...

Logs를 모아서 S3 Bucket에 적재해둔다.

 

Cloud Trail 이벤트

- 관리 이벤트, 데이터 이벤트 등이 있어서 문제가 생겼을 때, 추적을 할수 있다.

 

CloudTrail vs CloudWatch

- CloudTrail : AWS 환경에서 수행된 모든 작업 로그

- CloudWatch : AWS를 모니터링하기 위한 서비스, 대시보드, 상태와 성능, 상황에 따른 Noti, Action

- CloudTrail이 로그를 모으고, CloudWatch는 로그를 통해 대시보드와 알림 등을 제공해준다.

 

VPC Flow Log

Agentless 기반 방화벽 로그

- Netflow와 유사

- Elastic Network Interface, Subnet, VPC당 활성화(어떤 사용자가 어떤 네트워크에 접속 시도하고 Deny 되었는지)

- CloudWatch Logs에 로깅

- CloudWatch 메트릭 생성하고 Alarm 설정

 

보통은 Prometheus & Grafana 오픈 소스를 통해, 모니터링 & 대시보드를 수행함

 

Section 2. AWS Budget / Cost Explorer

AWS Budgets

- 사용자 지정 예산을 설정하여 비용 & 사용량을 추적하고, 임계값 초과 시 이메일 또는 SNS 알림에서 수신된 알림에 빠르게 대응 가능

예산 유형을 지정할 수 있다.

- 요구에 맞는 사용자 지정 예산 책정 가능, 알림 보고서를 통해 지속적으로 정보 파악, 예산 기간 세부 지정

 

Cost Explorer

- 계정에 연결된 요금과 사용량을 검토
- 비용 및 사용량 데이터 보고서를 조회하고 작성

- 향후 3개월 동안의 예상 지출을 예측

- 예약형 인스턴스(RI)의 사용률 적용 범위에 대한 권장 사항을 확인

- 절감형 플랜의 사용률과 적용 범위에 대한 권장 사항을 확인

 

Section 3. CloudFormation

IaC[Infra As Code]란?

- Terraform과 같이 코드를 이용해서 infra 리소스를 생성할 수 있도록 한다.
  <주로 Terraform 문법을 자주 사용한다.>

- 정말 잘 만들어 놓은 Infra를 다른 Region에 동일하게 구성할 때 훨씬 더 효율적이다.

 

CloudFormation

- 템플릿 기반 인프라 프로비저닝을 위한 관리형 서비스
(어찌되었건 코드를 실행하려면 서버가 필요한데, 실행할 서버 자체는 관리형으로 제공해주고 코드만 작성하면 됨)

- 인프라 환경을 코드(Yaml 또는 Json 형태 템플릿파일)로 작성

 

CloudFormation 템플릿

- 주로 yaml 형식을 사용

 

CloudFormation Designer

- UI Builder에서 만들고 코드로 변환해주는 기능

 

CloudFormation 스택

- IaC라고 하더라도 한번에 구성하는 것보다, 벽돌처럼 단위 단위별로 구분 지어 놓아서 구현해 놓고, 추후에 특정 서비스만 변경될 경우에 그부분만 수정 반영하도록 하기 위해서 스택 형식을 채용한다.

- 템플릿을 구분해서 만들면 하나의 템플릿이 하나의 Stack이 되고, 여러개의 Stack이 쌓여 전체 Infra가 구성된다.

- VPC, EC2 Instance 생성 등등 여러가지 리소스를 생성하는 템플릿을 모두 하나에 모아서 관리해도 되겠지만, 그렇게 되면 VPC 하나만 바꾸고 싶어도 수정하기가 부담스러워진다.

 

스택생성 Workflow

 

Chapter 7. 클라우드 인프라에 대한 가용성 처리

 

Section 1. ELB(Elastic Load Balancer) / ASG(Auto Scaling Group)

 

AWS Availability

동일 역할을 수행하는 Instance를 각 가용 영역에 분산 배치하면 서비스 가용성을 높일 수 있음

분산 배치 및 이중화 된 인스턴스로 어떻게 트래픽을 분배할 것인가?

Load Balancer(단일 진입접, 로드 분산)가 해당 역할을 해준다.

Load Balancer는 Health Check를 통해 인스턴스의 상태를 주기적으로 확인한다.

 

AWS Networking - ELB(Elastic Load Balancer)

Region 내 Load Balancing 서비스

- 다수의 가용영역으로 Traffic 분배

- HTTP/S, TCP/S 프로토콜 지원

- Backend Instance에 대한 Health Check

- 고가용성 기반의 L4(Transport, TCP 기반 Port 기반 로드 벨런싱), L7(Application, Http 기반 Path 기반? 로드 벨런싱) 서비스

 

ELB 유형

- ALB ->  Application Load Balancer(L7, 분배 대상이 Application, Http 통신 기반 로드 밸런싱)

- NLB -> Network Load Balancer(L4, 분배 대상이 Network, Tcp 통신 기반 로드 벨런싱)

- GLB -> Gateway Load Balancer(분배 대상이 네트워크 장비 단위)

- 기존 Classic Load Balancer : 위처럼 유형 구분 없이, 분배

 

ALB 구조

트래픽을 수신하게 되면 Listener의 Rule에 따라 Target Group에 분배 후, Balancing Algorithm에 따라 각 서버에 분산

Target Group은 Instance 그룹 또는 Lambda라고 할 수 있다.

 

Balancing Algorithm

- Round Robin : 공평하게 돌아가면서 한번 씩

- Hashing : 헤시 알고리즘에 따라 요청 분기

- Weighted Round Robin : 가중치를 둔 Round Robin

 

NLB Balancing Algorithm

- Flowing Hash 알고리즘(ip, port)

 

AWS Networking Protocol

- L4 : TCP / UDP

 

ELB 주의 사항

- ELB를 생성할 때 반드시 AZ별 활성화가 필요하다.

- LB 등록 시, 활성화 되지 않은 AZ에 배치된 타겟(인스턴스)에는 트래픽이 수신되지 않는다.

- ALB의 IP Address는 지속적으로 변경될 수 있으므로, DNS를 사용해야함

- NLB는 고정 IP 부여 가능하다. ALB는 불가능

- SSL(Secure Socket Layer) 지원

- Client의 SLL을 ELB에서 처리(BE 부하 감소 효과)

- CrossZone Load Balancing(단, AZ별로 LB를 만들어야 하나봄)
- Sticky Sessions : 특정 경우에 A라는 Target Group으로 요청을 보내야한다는 기능을 적용 가능

 

ELB 라우팅 요청 구조

- ELB는 기본적으로 DNS 주소를 통해 접속 (DNS 주소 관리는 Route53 서비스가 담당)

- Client가 ELB DNS 주소로 접근 요청시 (Route53은 Client에게 1개 이상의 LB 노드 IP를 반환

 

Scale out & Scale in

- Scale out : 서비스 부하가 증가되어 인스턴스 증설 (주로 WAS 서버)

- Scale in : 서비스 부하 감소시 인스턴스 제거 (주로 WAS 서버)

- Scale up : 인스턴스 하나의 사양을 더 높임 (재기동 필요해서 약간의 다운 타임 존재, 주로 DB)

- Scale down : 인스턴스 하나의 사양을 더 낮춤 (재기동 필요해서 약간의 다운 타임 존재, 주로 DB)

 

Auto Scaling Group

- 자동 Scaling 기능

- ELB & Auto Scaling Group 조합으로 자동으로 Scale-in & out 되도록 운영

- ELB와 Auto Scaling Group은 조합으로 같이 사용된다. ELB 입장에서는 Auto Scale된 Instance 정보들을 다 파악해야되기 때문이다.

 

AWS Auth Scaling 구성 요소

- 무엇을 Scale-in & Scale-out 할 것인가? Launch Template(AMI, Instance Type, 자동으로 생성 or 삭제되는 Instance 정의)

- 자동화 동작은 어떤 방식으로 할 것인가? Auto Scaling Group(원하는 Capacity, Min/Max instance 개수, Target Group 등 자동 변경과 관련한 정의)

 

아래는 Autoscale 실습 중, 특정 Instance에 접속하여 CPU 이용률를 100% 찍도록 하는 방법이다.

sudo yum install -y stress
stress --cpu <vm cpu 갯수> --timeout <지속할 시간>

 

Chapter 8. 글로벌 서비스를 위한 부하 분산

Section 1. Route 53 / Transit GW

Route53

AWS가 제공하는 Domain Name System 서비스 입니다.
(도메인 텍스트 기반 주소로 접근해도 자동으로 IP주소를 변환하여 접근할 수 있도록 해주는 서버)

도메인 등록, 도메인 이전, DNS 라우팅, 상태 확인 등 기능을 제공함

가용성과 확장성이 뛰어난 DNS 웹서비스

 

DNS란?
Domain Name System (Nomain Name을 네트워크 주소로 변환해주는 시스템)

원래는 서버에 접속하려면 서버 IP 숫자를 입력해서 접근해야하는데, 다 알기 어렵다.

아주 예전에는 OS의 hosts 파일에, 아래 같이 domin과 ip를 매핑해서 쓰기도 했다.

```

google.com 216.58.220.142

```

단점은 계속 ip가 바뀌는 경우도 있고 해서, Domain 매핑해서 원하는 IP로 연결시켜주는 DNS가 등장하게 되었음

 

DNS의 동작순서

1. 가장 먼저 Local DNS를 보고 일치하는 domain이 있으면 해당 IP를 캐싱한 상태로 사용해서, Browser에 보낸다.

2. root dns -> com dns -> domain.com dns 순으로 찾아서 온다.

Route53의 특징 - Weight Round Robin

- 서버의 IP 주소나 도메인마다 가중치를 설정하여 트래픽을 조절하여, Region 레벨 LoadBalancer 역할을 해줄 수 있다.

- Failover 기능을 제공하여, 장애가 있는 Region에는 요청을 보내지 않는 기능이 있다.

- 지연이 제일 낮은 Region IP를 반환해줄 수 있다.

- ALB와 차이가 뭘까? 

- Route53은 Region 별 Load Balancing 하는 것이고, ELB는 Region 내에서 Load Balancing 해준다.

 

Transit Gateway

가상 사설 클라우드(VPC)와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브

- VPC를 만들었는데, 다른 VPC와 연결하고 싶을 때 보통 VPC Peering을 사용해야 하는데, 문제점이 있어서 이를 해결하기 위해 사용해야 하는 서비스이다.

- VPC는 보통 팀별/프로젝트별/회사별로 만들어 지는데, 상황에 따라 가상 사설망끼리 연결해주고 싶은 요건이 생긴다.

- VPC는 가상 사설망이기 때문에, A VPC도 네트워크 대역을 10.0.xx.xx/16로 했을 경우도 있고, B VPC도 네트워크 대역을 10.0.xx.xx/16로 했을 경우도 있다. 즉 중복될 수 있다.

- VPC Peering의 단점은 연결해야할 VPC가 2개를 넘어서 3개 이상이 될 때, VPC간 연결을 위해 VPC간 모두 선을 연결해줘야 한다는 단점이 존재한다.

- Transit Gateway는 중앙에 Gateway 형태의 TG가 있고 VPC들은 Transit Gateway에 연결해두면 별도로 VPC간 연결을 하지 않아도 VPC 간 연결이 가능하도록 해준다.

- On-prem 과도 연결이 가능하다는 단점이 있다.

 

Section 2. Cloud Front / Global Accelator

Cloud Front

AWS가 제공하는 Cloud native한 Content Delivery Network(CDN) 서비스입니다.

- AWS는 이미 전 세계 각지에 사용자에게 최적의 Edge Server(Edge Loacation)을 찾아 캐시 및 AWS 글로벌 네트워크를 통해 빠르게 전송

- 사용자 기준 최적의 Edge Server를 통해 컨텐츠를 캐시해두고 전송해줌

- 다른 AWS 서비스와 쉽게 연동(AWS WAF, S3, Media, ACM...)

 

CloudFront 용어

- Origin Server : 기존 컨텐츠가 저장되어 있는 서버

- Cache Server : 빠른 콘텐츠 전달을 위해 지리적으로 사용자와 가깝게 위치한 서버

원본 서버와 컨텐츠가 먼 대륙에 있어도, 사용자 경험이 떨어지지 않도록 해준다.

원래는 Origin Server에 요청해야 하나, 먼저 Edge Server에 있는 Cache Server에 요청한다.

 

CloudFront 구성

Origin Server 정보와 도메인 할당이 필수적이고, 글로벌에 배포하는 방식이다.

 

 

 

CND이란?

컨텐츠를 전송하기 위한 네트워크이다. 짧은 지연시간, 사용자 경험(UX) 향상, 빠른 전송 속도 지원을 위한 Network

사용자에게 최대한 가까운 위치에서 컨텐츠를 빠르게 받아볼 수 있도록 해주는 서비스

 

Global Accelarator

엣지 로케이션을 사용하여 사용자에게서 애플리케이션까지 최적의 경로를 찾는 서비스

- 고정된 IP로 엔드포인트 제공

- 다중 리전 구성에서 최적의 리전으로 연결

- 헬스 체크를 통한 자동 트래픽 제어

- AWS 글로벌 네트워크를 통해 빠른 전송

글로벌 인터넷망은 속도를 보장할 수 없지만, 인터넷망에서 AWS망으로 요청만 주면 그 내부 AZ간의 통신 측면에서는 초고속 속도를 보장해 주겠다.

 

Chapter 9. 클라우드 신원 및 접근 관리 - 인증과 권한

Section 1. AWS IAM 자격 증명

IAM(Identity and Access Management)

- 인증(Authentication), 권한(Authorization)

 

인증과 권한의 차이가 뭘까?

- 인증(Auth) : 내가 어느 시스템, 서비스에 접근하고 싶어. 내가 그 서비스를 사용할 수 있는지 자격을 증명

- 권한(AuthR) : 이미 서비스에는 들어갈 수 있으나, 어느 행위까지 할 수 있는 레벨을 결정

 

자격 증명 (사용자 / 역할)

초기에 AWS에 가입하면 email + pw + MFA 인증으로 로그인하게 되는데 이를 Root 계정이라고 하고, 관리자 계정이고 모든 것을 할 수 있는 계정이라 해킹당하면 매우 위험하기 때문에, 일상 Task 용도에는 사용하지 않는다. 그래서 무조건 MFA 인증을 해야한다.

Root 계정을 가지고, IAM 계정(사용자, Admin 권한 부여)을 만들고 해당 계정으로 로그인한다.

Admin IAM User가 Role(Dev, Test, Analyze...) 을 만들고 여러 IAM User 들에게 Role을 할당한다.

최소 권한의 원칙이 맞지만, 너무 번거롭기 때문에 MFA 인증을 강제하는 방향으로 하는 경우가 많다.

- 장기 자격 증명 = 사용자(user) // IAM 사용자 자체에 할당된 권한 (보통 Policy(정책)을 통해 매핑한다)

  -> 적절한 정보를 통해 특정 유저임을 확인 하는 자격 증명 방식

  -> AWS가 미리 제공하는 권한을 정의해놓은 Policy들이 있다.

  -> 직접 Policy들을 IAM User에 할당하거나, 여러 Policy를 가진 IAM Group에 해당 IAM User를 포함시킨다.

  -> 주로 IAM Group으로 그룹화하여 관리

- 임시 자격 증명 = 역할(Role) // 모자라고 생각하면 좋다. 평소에는 개발자였다가 특정 Role 모자를 씌워주면 임시적으로 해당 Role도 할

당된 권한도 사용할 수 있게 된다.

  -> 적절한 정보를 통해 특정 역할을 수행할 수 있는 권한을 일정기간 취득하여 사용하는 방식

  -> 주의할 점은 Role을 사용하게 되면, Role을 할당하기 직전의 권한은 사용할 수 없다.

 

Root User / IAM User

- Root User : 모든 권한, 계정 생성 후 직접 사용하지 않을 것을 권장

- IAM User : 장기자격증명(Access Key, Secret Key 또는 ID/PW) // SDK,CLI 형태로 사용할 것이면 KEY 발급 필요

(번외) SSO 계정이란? 현재는 하나의 AWS 계정 내에서의 권한들을 이야기 하고 있지만, 회사 규모가 크면 여러개의 팀별로 AWS 계정을 두고 사용한다. 여러개의 계정을 통합하여 관리하고 싶을 때, SSO 계정의 필요성이 등장된다.

 

IAM 그룹

- IAM 사용자의 집합

- 그룹을 사용 안해도 되지만, 권한을 지정 시, 다수의 사용자에게 일괄 권한 할당이 가능하다.

- A그룹 안에 B그룹을 넣을 수는 없다. 즉 중첩 구조는 불가능하다.

- 한명의 사용자가 여러명의 그룹에 속하는 것인 가능하다.

 

보안자격증명

- AWS 관리 콘솔의 경우 ID + Password로 보안 자격 증명을 진행함

- API / CLI / SDK 의 경우 Access Key, Secret Key로 보안 자격 증명을 진행함

 

임시 자격증명 연동

- 임시 자격증명 할당을 통한 권한 연동은 리소스에게도 가능

- 외부 사람이지만 임시로 권한을 주고 싶을 때 Role을 사용한다. 그런 사용자를 Federation 사용자라고 한다.

 

Section 2. IAM 권한 / 정책

IAM 정책(Policy)

- 사용자(User)와 그룹(Group), 역할(Role)이 무엇을 할 수 있는지에 대한 권한(permission) 설정 데이터 문서 

- AWS가 만들어 높은 관리형 정책들을 미리 제공한다.

- 가장 높은 정책은 "AdministatorAccess" 권한이다. 모든 AWS 서비스와 리소스에 대해서 접근 권한을 가짐

{
 "Effect": "Allow",
 "Action": "*",
 "Resource": "*"
}

 

IAM 정책(Policy) 구조

보통 아래에서 부터 해석하는 게 좋다.

Resource : 어떤 서비스에 대해서

Action : 그 서비스에 대한 어떤 액션을

Principal : 접근을 허용하고자 또는 차단하고자 하는 대상

Effect : 허용 또는 차단

 

IAM 정책(Policy) 종류(Type)

IAM 정책도 여러 유형이 많다. 총 6종류

- 권한 부여 정책 (권한을 부여하기 위한 정책)

  1. 자격증명 기반 정책 (User, Group, Role에 부여하는 정책 - 사용자 관점이다! 사용자에게 부여하는 정책이다.)

  -> 사용자가 어떤 리소스에 접근할 수 있는지

  2. 리소스 기반 정책 (S3 버킷과 같은 리소스에 연결하는 JSON 정책 문서, 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 조건 정의 및 권한 부여, 리소스 기반 정책은 인라인 정책 - 리소스 관점이다! 리소스에 부여하는 정책이다.)

  -> 리소스에 어떤 사용자가 접근할 수 있는지

  -> 자격증명 기반 정책만 있으면 동일한 계정에 있는 리소스에 대해서면 접근을 제어할 수 있지만, 리소스 정책을 사용하면 다른 계정에 있는 사용자가 현 계정에 있는 리소스에 접근 가능하도록 허용해줄 수 있다.

  3. Access Control Lists(ACLs)

 

- 가드레일 (부여 가능한 권한 범위를 제한하는데 사용되는 정책) :
자유 이용권이 있더라도 어리면 놀이기구를 못타는 제한이 있듯이, 권한이 부여되어 있더라도 조직 차원의 안전장치 가드레일로 인해 동작하지 못하도록 할 수 있다.

  1. 권한 경계

  2. Organication SPCs

  3. 세션 정책