sehee

VPC Components Diagram

AWS Site-to-Site VPN

기업 데이터 센터를 AWS와 비공개로 연결하기 위해 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 함
공용 인터넷을 통해 사설 Site-to-Site VPN 연결

Site-to-Site VPN Connection

고객 게이트웨이가 있는 기업 데이터 센터와 가상 프라이빗 게이트웨이를 갖춘 VPC가 있음
온프레미스 고객에게 게이트웨이를 어떻게 구축해야 할까?

-> 고객 게이트웨이가 공용이라면 인터넷 라우팅이 가능한 IP 주소가 고객 게이트웨이 장치에 있음

고객 게이트웨이의 공용 IP를 사용해서 VGW와 CGW를 연결하면 됨

-> 고객 게이트웨이를 비공개로 남겨 사설 IP를 갖는 경우, 대부분 NAT-T를 활성화하는 NAT 장치 뒤에 있음
NAT 장치에 공용 IP가 있을 시 이 공용 IP를 CGW에 사용해야 함

+ 서브넷의 VPC에서 라우트 전파를 활성화해야 Site-to-Site VPN 연결이 실제로 작동함

+ 온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때 보안 그룹 인바운드 ICMP 프로토콜이 활성화됐는지 확인해야 함(그렇지 않으면 연결되지 않음)

AWS VPN CloudHub

VGW를 갖춘 VPC가 있고, 고객 네트워크와 데이터 센터마다 고객 게이트웨이가 마련된 상황

Hands-on#0n - Site-to-Site VPN

1) create customer gateways

- Site-to-Site VPN 연결을 구성하기 위해서는 온프레미스 호스팅이 된 고객 게이트웨이가 필요하므로

- create Site-to-Site VPN connections ...

Direct Connect (DX)

원격 네트워크로부터 VPC로의 전용 프라이빗 연결을 뜻함
DX를 사용할 때는 전용 연결을 생성해야 하고, AWS DX 로케이션을 사용함

VPC에는 가상 프라이빗 게이트웨이를 설치해야 온프레미스 데이터 센터와 AWS 간 연결이 가능

설치 기간이 한 달보다 길어질 때도 있음

Direct Connect Gateway

다른 리전에 있는 하나 이상의 VPC와 연결할 경우

Direct Connect - Resiliency

복원력, 아키텍처 모드

핵심 워크로드의 복원력을 높이기 위해서는 여러 DX를 설치하는 것이 좋음
기업 데이터 센터가 2개이고 DX location도 둘일 때 중복이 발생 - 프라이빗 VIF가 하나 있는데 다른 곳에 또 있다면 하나의 연결을 여러 로케이션에 수립한 것이므로 DX 하나가 망가져도 다른 하나가 예비로 남아있기 때문에 복원력이 강해짐

핵심 워크로드 복원력을 최대로 끌어올리고 싶다면, (Maximum Resiliency for Critical Workloads)

각 DX location에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있음

Transit Gateway

네트워크 토폴로지 복잡성 문제로 만듦

IP Multicast할 때 사용

Transit Gateway: Site-to-Site VPN ECMP

Site-to-Site VPN 연결 대역폭을 ECMP를 사용해 늘리는 경우

- ECMP: Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략

Transit Gateway: throughput with ECMP

VPN을 Transit Gateway로 연결하면 Site-to-Site VPN 하나가 여러 VPC에 생성됨 (동일한 Transit Gateway에 모두 전이적으로 연결되기 때문)

VPC - Traffic Mirroring

사례: 콘텐츠 검사, 위협 모니터링, 네트워킹 문제 해결

IPv6 Troubleshooting

IPv4는 VPC 및 서브넷에서 비활성화될 수 없음
IPv6가 활성화된 VPC가 있을 때, 서브넷에서 EC2 인스턴스를 실행할 수 없다고 하면 인스턴스가 IPv6를 받지 못해서가 아님 (실제로 공간이 크고 EC2 인스턴스를 위한 IPv6도 충분하기 때문)

-> 진짜 원인은 서브넷이나 VPC에 이용 가능한 IPv4가 없기 때문

-> solution: 서브넷에 IPv4 CIDR를 생성하는 것 (create a new IPv4 CIDR in your subnet)

Hands-on#0n -

1) VPC Edit CIDRs - Amazon-provided IPv6 CIDR block

2) Subnet - edit IPv6 CIDRs > subnet CIDR block

3) Subnet - edit subnet settings > auto-assign IP settings: Enable auto-assign IPv6 address

4) Instance (BastionHost) - networking: Manage IP addresses > eth0: IPv6 addresses Auto-assign

5) 해당 instance security group edit inbound rules - add SSH IPv6

Test your IPv6

6) Route tables - Public routes > IPv6 target: local로 설정되어 있음

Egress-only Internet Gateway

송신 전용 인터넷 게이트웨이, NAT Gateway와 비슷하지만 IPv6 전용

Hands-on#0n - Egress only internet gateway

1) create egress only internet gateway (DemoEIGW)

2) private route tables edit routes - ::/0, eggress only internet gateway

-> 사설 서브넷의 EC2 인스턴스가 IPv6로 인터넷에 액세스하지만 인터넷에는 도달하지 못함

VPC Section Summary

01. CIDR: IP Range

02. VPC: virtual private cloud, IPv4와 IPv6를 위해 작동함

03. Subnets: CIDR를 정의하는 AZ에 연결됨, public/private

04. Internet Gateway: at the VPC level, public subnet은 인터넷 게이트웨이 연결시키고, 퍼블릭 서브넷에서부터 인터넷 게이트웨이로 경로 생성

05. Route Tables: 네트워크가 VPC 내에서 흐르도록 하는 키, 수정됨, 인터넷 게이트웨이 경로들, VPC Peering connections, VPC Endpoints 등 포함

06. Bastion Host: SSH에 들어갈 수 있는 public EC2 instance, 비공개 서브넷의 다른 EC2 인스턴스들과 SSH 연결

07. NAT Instances: 퍼블릭 서브넷에 배포된 EC2 인스턴스, 프라이빗 서브넷의 EC2 인스턴스에게 인터넷 접근을 제공, 오래되었고 사용이 권장되지 않고 있기 때문에 소스 / 대상 확인 플래그를 비활성화해야 함 (그렇게 해야 작동을 할 것이고 보안 그룹 규칙을 수정할 수 있음)

08. NAT Gateway: 프라이빗 EC2 인스턴스에 확장 가능한 인터넷 접근을 제공하고, 요청의 타켓이 IPv4 주소일 때 사용

09. NACL: 네트워크 ACL, 서브넷 레벨에서 인바운드와 아웃바운드 접근을 정의하는 방화벽 규칙, stateless 상태라 인바운드와 아웃바운드 규칙은 항상 평가되고 있음

10. Security Groups: Stateful 상태 - 인바운드가 허용되었을 경우 아웃바운드도 자동적으로 허용되고 그 반대도 마찬가지, 보안 그룹 규칙은 EC2 인스턴스 레벨에 적용됨

11. VPC Peering: 두 개의 VPC를 연결, 겹치지 않는 CIDR을 가지는 경우에 해당, VPC 피어링 연결은 비전이적 (따라서 세 개의 VPC를 연결하고자 한다면 세 개의 VPC 피어링 연결이 필요함)

12. VPC Endpoints: 프라이빗 접근을 허용 - VPC 내의 AWS 서비스라면 Amazon S3, DynamoDB, CloudFormation, SSM 등 무엇이든 가능 (Amazon S3와 DynamoDB에는 게이트웨이 엔드포인트가 있는 것도 보았고 나머지는 모두 인터페이스 엔드포인트)

13. VPC Flow Logs: VPC 내의 모든 패킷에 관련된 로그 레벨의 메타데이터를 갖는 데 가장 좋은 방법, 허용과 비허용 트래픽과 관련된 정보도 조금 있음, VPC 서브넷이나 ENA 레벨에서 생성 (Amazon S3로 전송되어 분석되고 Athena에서 분석될 수 있었으며, CloudWatchLogs로 전송되어 CloudWatchLog Insights를 통해 분석될 수도 있었음)

VPC를 데이터 센터로 연결하기 위한 두 가지 방법

14. 1) Site-to-Site VPN: 공공 인터넷을 통한 VPN 연결이기 때문에 AWS에 버추얼 비공개 게이트웨이를 생성해야 하고 데이터 센터에 고객 게이트웨이를 생성하고 그 후에 VPN 연결을 설립, 여러개의 VPN 연결을 설립할 때 같은 virtual private gateway를 사용하면 VPN CloudHub를 사용해서 hub-and-spoke VPN모델을 만들어 사이트들을 연결할 수 있기도 함

15. 2) Direct Connect: 연결이 완전히 프라이빗 상태, 공공 인터넷을 통하지 않지만 설립하는 데에 시간이 소요됨, 데이터 센터를 Direct Connect 위치로 연결해야 작동함 (더 복잡하지만 더 보안적으로 안전함, 연결도 안정적)

16. Direct Connect Gateway: 다른 AWS 리전의 많은 VPC와 Direct Connect를 만들기 위한 것

17. AWS PrivateLink / VPC Endpoint Services: 고객 VPC에 직접 생성한 VPC 내에서 서비스로 비공개적으로 연결하기 위한 것, 좋은 점은 VPC 피어링이나 공공 인터넷이나 NAT 게이트웨이나 라우팅 테이블을 요구하지 않음, 주로 Network Load Balancer와 ENI와만 사용됨 - VPC 내의 서비스를 네트워크를 노출시키지 않고 수백, 수천개의 고객 VPC에게 노출시킬 수 있도록 함

18. ClassicLink: EC2-Classic 인스턴스를 VPC로 비공개로 연결하기 위한 것, 사용이 권장되지 않음

19. Transit Gateway: VPC, VPN, 그리고 Direct Connect를 위한 전송 피어링 연결

20. Traffic Mirroring: 네트워크 트래픽을 ENI에서 복사하여 분석을 하는 것

21. Egress-only Internet Gateway: NAT Gateway와 비슷하지만 IPv6 트래픽이 인터넷 밖으로 가는 것을 위한 것

Networking Costs in AWS per GB - Simplified

첫번째 AZ에 EC2 인스턴스가 있을 경우 EC2 인스턴스로 향하는 트래픽은 무료

같은 가용영역 내 두 EC2 인스턴스 간 트래픽은 사설 IP로 통신할 시 무료

같은 리전 내 다른 두 AZ에 있는 EC2 인스턴스 두 개가 소통하기 위해 공용 IP나 탄력적 IP를 사용하는 경우, 청구 비용은 GB당 2센트(사설 IP를 사용할 경우 반으로 절감)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

VPC Components Diagram

VPC Peering

다양한 리전과 계정에서 VPC를 생성할 수 있는데, AWS 네트워크를 통해 연결하고 싶을 때 사용
왜 필요한가? VPC가 모두 같은 네트워크에서 작동하도록 만들기 위해

서로 다른 VPC가 통신하려면 VPC 피어링을 활성화해야 함

A-B, B-C가 연결되어 있더라도 A와 C의 VPC 피어링 연결을 활성화해야 그 둘이 통신할 수 있음

VPC Peering - Good to know

다른 계정 간에도 가능 - 계정 A에서 계정 B로 VPC 연결이 가능
리전 간 연결도 가능

Hands-on#05 - VPC Peering

1) edit default VPC name: DefaultVPC

2) launch Instance (DefaultVPCInstance)
- private IPv4 address: 172.31.0.0/16 (PrivateInstance: 10.0.0.0/16, 다른 VPC)
- BastionHost IP(10.x.x.x)로 DefaultVPCInstance ssh에서 curl 명령시 연결되지 않음

3) create Peering connections
- VPC ID (Requester): DemoVPC, 10.0.0.0/16
- VPC ID (Accepter): DefaultVPC, 172.31.0.0/16

+ Actions: Accept request

4) edit default Route tables name: DefaultVPCMainRouteTable
5) public route table - add Routes > peering connection
- DefaultVPC IPv4 CIDR(172.31.0.0/16)

6) default route table - add Routes > peering connection - 10.0.0.0/16

(The destination CIDR block 10.0.0.0/16 is equal to or more specific than one of this VPC's CIDR blocks. This route can target only an interface or an instance.)

VPC Endpoints (AWS PrivateLink)

프라이빗 서브넷의 EC2 인스턴스를 VPC 엔드포인트를 거쳐 직접 Amazon SNS 서비스에 연결할 수 있음, 이 때 네트워크가 AWS 내에서만 이루어짐

VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 프라이빗으로 액세스하므로 AWS에 있는 모든 서비스에 액세스할 때 퍼블릭 인터넷을 거치지 않고도 프라이빗 네트워크를 사용할 수 있음

Types of Endpoints

1. Interface Endpoints (powered by PrivateLink)

인터페이스 엔드포인트는 ENI를 프로비저닝하는데 ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트임

ENI가 있으면 반드시 보안 그룹을 연결해야 함, 대부분의 AWS 서비스를 지원함

2. Gateway Endpoints

게이트웨이를 프로비저닝, 게이트웨이는 라우팅 테이블의 대상이 되어야 함

IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상이 될 뿐임

게이트웨이 엔드포인트 대상: Amazon S3, DynamoDB

Gateway or Interface Endpoint for S3?

Amazon S3에 액세스하는 방법 중 게이트웨이를 선택하는 편이 대부분 유리함 - 라우팅 테이블만 수정하면 되기 때문

인터페이스 엔드포인트가 권장되는 경우: 온프레미스에서 액세스해야 할 필요가 있을 때, 다른 VPC에 연결할 때

Hands-on#05 - VPC Endpoints

7) PrivateInstance > Security - Modify IAM role > role 생성 후 추가

- create role: AWS service, EC2, policies-AmazonS3ReadOnlyAccess

8) BastionHost > PrivateInstance ssh connect + 명령 입력

aws s3 ls
curl google.com

9) Private Route Table의 NAT Gateway로 인터넷에 연결하는 라우트 0.0.0.0/0 삭제

- 이 인스턴스가 인터넷에 접속하지 못하게 하도록

- 8번 동일 명령 실행되지 않음

-> VPC 엔드포인트를 통해 Amazon S3에 프라이빗 접속이 가능해짐

10) VPC Endpoints create (DemoVPC) - 아래 둘 중 Gateway endpoints로 생성

Interface

- service name: 맨 상단(aws.sagemaker.ap-northeast-2.notebook)

- subnets: Private subnet A, B 지정

Gateway

- service name: com.amazonaws.ap-northeast-2.s3

- Route tables: PrivateRouteTable

-> PrivateRouteTable routes edit 시 NAT Gateway 생성되어 있음

11) 이후 PrivateInstance ssh connect 후 명령 실행

- CLI 리전은 기본적으로 us-east-1으로 설정됨

# 해당하는 리전으로 입력
aws s3 ls --region ap-northeast-2

VPC Flow Logs

인터페이스로 들어오는 IP 트래픽에서 정보를 포착할 수 있음

Hands-on#06 - VPC Flow Logs

1) DemoVPC create flow log (DemoS3FlowLog)

- send to an Amazon S3 bucket
- 2)의 buckets properties ARN(Amazon Resource Name) 붙여넣기

2) create S3 (demo-(alias) vpc-flow-logs-v2)

3) DemoVPC create flow log 2nd (DemoFlowLogCWLogs)
- send to CloudWatch Logs

- 4)에서 생성한 flowlogsRole

4) create IAM role
- type: custom trust policy

"Principal": {
    "Service": "vpc-flow-logs.amazonaws.com"
},

- CloudWatchLogsFullAccess

- role name: flowlogsRole

5) CloudWatch create Log groups (VPCFlowLogs)

6) S3 Buckets / CloudWatch Log groups 확인

- BastionHost network interface ID에 해당하는 CloudWatch log streams: EC2 인스턴스에서 일어나고 있는 트래픽

7) Amazon Athena를 사용해서 S3 버킷에 들어가는 데이터 쿼리 연습
(1) query editor - settings - S3에서 생성한 bucket 추가

- S3에서 create bucket (demo-athena-(alias)-v2)

search > aws vpc logs athena query 붙여넣기

CREATE EXTERNAL TABLE IF NOT EXISTS `vpc_flow_logs` (
  version int,
  account_id string,
  interface_id string,
  srcaddr string,
  dstaddr string,
  srcport int,
  dstport int,
  protocol bigint,
  packets bigint,
  bytes bigint,
  start bigint,
  `end` bigint,
  action string,
  log_status string,
  vpc_id string,
  subnet_id string,
  instance_id string,
  tcp_flags int,
  type string,
  pkt_srcaddr string,
  pkt_dstaddr string,
  region string,
  az_id string,
  sublocation_type string,
  sublocation_id string,
  pkt_src_aws_service string,
  pkt_dst_aws_service string,
  flow_direction string,
  traffic_path int
)
PARTITIONED BY (`date` date)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://DOC-EXAMPLE-BUCKET/prefix/AWSLogs/{account_id}/vpcflowlogs/{region_code}/'
TBLPROPERTIES ("skip.header.line.count"="1");

- query LOCATION에 - S3 region url 대체 (demo-(alias) vpc-flow-logs-v2)

(2) query 변경

ALTER TABLE vpc_flow_logs
ADD PARTITION (`date`='YYYY-MM-dd')
LOCATION 's3://DOC-EXAMPLE-BUCKET/prefix/AWSLogs/{account_id}/vpcflowlogs/{region_code}/YYYY/MM/dd';

- S3 일자까지 클릭 후 properties S3 URL 붙여넣기

- query results: 테이블에 파티션 하나 추가

(3) 데이터 쿼리

SELECT day_of_week(date) AS
  day,
  date,
  interface_id,
  srcaddr,
  action,
  protocol
FROM vpc_flow_logs
WHERE action = 'REJECT' AND protocol = 6
LIMIT 100;

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

VPC Components Diagram

Understanding CIDR - IPv4

클래스 없는 도메인 간 라우팅: Classless Inter-Domain Routing

IP address range
1) ww.xx.yy.zz/32 : one IP
2) 0.0.0.0/0 : all IPs
3) we can define 192.168.0.0/26 : 192.168.0.0 - 192.168.0.63 (64 IP addresses)

octets: 1st . 2nd . 3rd . 4th
/32: no octet can change, /24: last octet can change

https://www.ipaddressguide.com/cidr

Public vs. Private IP (IPv4)

10.0.0.0 - 10.255.255.255 (10.0.0.0/8) <- in big networks
172.16.0.0 - 172.31.255.255 (172.16.0.0/12) <- AWS default VPC in that range
192.168.0.0 - 192.168.255.255 (192.168.0.0/16) <- e.g., home networks

Default VPC Walkthrough

새로운 AWS 계정은 모두 기본 VPC가 있음, 새로운 EC2 인스턴스는 서브넷을 지정하지 않으면 기본 VPC에 실행됨

VPC in AWS - IPv4

단일 AWS 리전에 여러 VPC를 둘 수 있음, 리전 당 최대 5개까지 가능(늘릴 수 있음), VPC마다 할당된 CIDR는 다섯 개
각 CIDR의 최소 크기는 /28, IP 주소는 최소 16개(2^4), 최대 크기는 /16, IP 주소는 최대 65,536개
VPC가 사설 리소스이기 때문에 사설 IPv4 범위만 허용됨
VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의할 것

VPC - Subnet (IPv4)

서브넷이란: VPC 내부에 있는 IPv4 주소의 부분 범위
범위 내 AWS가 IP 주소 다섯 개를 예약함

Example: if CIDR block 10.0.0.0/24, then reserved IP addresses are:
.0: network address
.1: reserved by AWS for the VPC router
.2: reserved by AWS for mapping to Amazon-provided DNS
.3: reserved by AWS for future use
.255: network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved

EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때, /27 서브넷은 사용할 수 없음 (32 - 5 = 27 < 29)

Hands-on#01 - Adding Subnets

1) VPC 생성
2) Public/Private Subnet 생성

Internet Gateway (IGW)

인터넷 Gateway는 VPC의 리소스를 인터넷에 연결하도록 하는 EC2 인스턴스나 람다 함수 등
수평 확장, VPC와 별개로 생성해야 함
VPC는 인터넷 Gateway 하나에만 연결됨
VPC에 인터넷 Gateway를 만드는 정도로는 서브넷에 인터넷 액세스를 제공하지 못함, 라우팅 테이블도 수정해야 함

∴ 공용 서브넷에 공용 EC2 인스턴스 만들기 -> 라우팅 테이블을 수정 -> EC2 인스턴스를 라우터에 연결 -> 인터넷 Gateway에 연결

Hands-on#02 - Adding Internet Gateway & Editing Route Tables

1) launch instance (BastionHost)
- 퍼블릭 서브넷을 위한 자동 할당 퍼블릭 IPv4 주소 활성화 시 Network settings에서 Auto-assign public IP 활성화(enable)된 상태
2) Internet gateways 생성 및 attach to VPC
- VPC에 인터넷 액세스 제공
3) public/private route table 생성
- subnet associations 추가
- routes 0.0.0.0/0 target Internet GW 추가

4) Instance connect

Bastion Hosts

사용자가 프라이빗 서브넷에 없는 EC2 인스턴스에 액세스하고자 함, 이 때 배스천 호스트를 통해 프라이빗 EC2 인스턴스에 SSH로 액세스할 수 있으며 배스천 호스트는 반드시 퍼블릭 서브넷에 있어야 함

배스천 호스트를 위해서는, 
- 보안 그룹이 반드시 인터넷 액세스를 허용해야 함(기업의 퍼블릭 CIDR 액세스, 사용자 인터넷 액세스만 허용하는 등 EC2 보안 그룹을 제한하여 인프라 보안상 위험 방지)
- 프라이빗 서브넷의 EC2 인스턴스 보안 그룹에서는 반드시 SSH 액세스를 허용해야 함(포트 22번이 배스천호스트의 프라이빗 IP가 되거나 배스천 호스트의 보안 그룹이 되는 셈)

Hands-on#03 - NAT Instance

1) launch instance (PrivateInstance)
- private, network settings - Inbound Security Group Rules custom (Allow SSH from the Bastion Host)

- 프라이빗 서브넷에 위치하므로 EC2 인스턴스로 연결할 수 없음 (∵ 인터넷 게이트웨이 라우팅 테이블을 수정하면 이 서브넷이 공개되기 때문)

2) public instance 실행 후 SSH

# copy + paste
vi EC2KeyPair.pem

chmod 0400 EC2KeyPair.pem
ssh ec2-user@(private IP) -i EC2KeyPair.pem

# doesn't work
ping google.com

- private subnet의 Amazon Linux 2 AMI에 SSH 액세스 실행

NAT Instance (outddated, but still at the exam)

NAT: 네트워크 주소 변환, 사설 서브넷 EC2 인스턴스가 인터넷에 연결되도록 허용함
NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 함

NAT 인스턴스의 작동 방식: 공용 서브넷에 NAT 인스턴스를 생성하고, 거기에 탄력적 IP를 연결, 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 함

Hands-on#03 - NAT Instance

3) launch instance (NAT Instance)

- Community AMIs - architectures: x86_64bit, vpc-nat

- Security group name: nat-instance-sg
- Security group rule: add HTTP, HTTPS
4) Change source/destination check
- Stop to allow your instance to send and receive traffic when the source or destination is not itself.

- NAT 인스턴스 자체가 소스 및 목적지가 아니라면 트래픽을 송수신할 수 있어야 함

5) private Route Table 인터넷 통신하기 위한 인스턴스 추가
- routes: 0.0.0.0/0 NAT Instance
6) NAT Instance 포트 추가
- All ICMP
7) PrivateInstance ping google.com
- BistionHost SSH connect > ssh Private

NAT Gateway

AWS-managed NAT, 높은 대역폭, 가용성이 높고 관리할 필요가 없음

특정 AZ에서 생성되고 탄력적 IP를 이어 받음

NAT Gateway with High Availabiltiy

AZ가 중지될 경우를 위해 다중 NAT Gateway를 여러 AZ에 두면 결함 허용을 할 수 있음

Hands-on#04 - NAT Gateway

1) create NAT gateway
- subnet: public subnet A
- Elastic IP allocation

2) edit private routes
- 기존 NAT Instance stop/terminal 시 status: Blackhole로 변경됨
- NAT Instance network interface -> NAT Gateway로 변경

Security Groups & NACLs

NACL: 요청이 EC2 인스턴스 내부로 이동하는 것

Network Access Control List (NACL)

서브넷을 오가는 트래픽을 제어하는 방화벽
서브넷마다 하나의 NACL이 있고, 새로운 서브넷에는 기본 NACL이 할당됨

1-32766번 (우선순위가 제일 높은 것은 1)
newly created NACLs will deny everything

Default NACL

연결된 서브넷을 가지고 inbound/outbound의 모든 요청을 허용하는 특수성을 가짐
기본 NACL을 수정하지 않는 것을 추천
기본적으로 NACL이 서브넷과 연결된다면 모든 것이 드나들도록 허용된다는 뜻

Ephemeral Ports

클라이언트와 서버가 연결되면 포트를 사용해야 함

Create NACL rules for each target subnets CIDR

다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 함, CIDR 사용 시 서브넷이 고유의 CIDR를 갖기 때문

NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야 함

Hands-on#04 - NACLs

3) BastionHost ssh 연결

sudo yum install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd
echo "hello world" > /var/www/html/index.html
# 이전 명령을 sudo로 실행
sudo !!

# if permission denied
sudo su
echo "hello world" > /var/www/html/index.html

4) add security group HTTP

- public IP 접속 허용

5) edit Network ACLs inbound/outbound rules (for test)

- inbound rule: 80, type: http, source: 0.0.0.0/0, Deny
or outbound rules 100 Deny

- public IP 접속 차단

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

Vertical Scalability

수직 확장성, 인스턴스의 크기를 확장

Horizental Scalability

수평 확장, 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법, 분배 시스템

High Availability

수직 확장, 적어도 2 데이터 센터(AZ)에서 애플리케이션을 구동시키는 것

High Availability & Scalability For EC2

scale out / in

What is load balancing?

서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 instances 또는 서버들로 전달하는 역할
EC2 인스턴스가 3개, 인스턴스 앞에는 Load Balancer, 사용자는 ELB로 바로 연결됨

Why use a load balancer?

부하를 다수의 다운스트림 인스턴스로 분산하기 위해

Why use an Elastic Load Balancer?

a managed load balancer

다른 서비스들과 통합 가능

Health Checks

EC2 인스턴스가 잘 동작하는지 상태 확인, 포트와 라우트에서 이루어짐
e.g., protocol: HTTP, port: 4567, endpoint: /health -> 인스턴스 응답 200(OK)이 아니라면 unhealthy하다고 판단

Types of load balancer on AWS

Classic load balancer: HTTP, HTTPS, TCP, SSL (secure TCP), 현재는 AWS에서 지원하지 않음

Application Load Balancer(ALB): HTTP, HTTPS, WebSocket
Network Load Balancer(NLB): TCP, TLS (secure TCP), UDP
Gateway Load Balancer(GLB): Operates at layer 3 (Network layer)

Application Load Balancer (v2)

HTTP/2와 WebSocket이 가능
URL 대상 경로에 의한 라우팅이 가능함

Application Load Balancer (v2) Target Groups

EC2 인스턴스가 대상 그룹, ECS tasks, Lambda functions

Network Load Balancer (v2)

가용 영역별로 하나의 고정 IP를 갖는다는 점

Network Load Balancer - Target Groups

NLB를 ALB 앞에 배치하는 경우

NLB: 고정 IP 주소를 얻음, ALB: HTTP 유형의 트래픽을 처리하는 규칙을 얻음

Gateway Load Balancer

모든 로드밸런서보다 낮은 계층에서 동작

Users - GWLB - Target Group - GWLB - Application

uses the GENEVE protocol on port 6081

Sticky Sessions (Session Affinity)

고정성, 고정 세션을 실행, 1번째 클라이언트가 요청을 생성해 EC2에서 첫번째 인스턴스로 이동한다면, 새로운 요청을 했을 때에도 동일한 인스턴스로 이동하도록 함

Sticky Sessions - Cookie Names

고정 세션에는 2가지 유형의 쿠키가 있음, 애플리케이션 기반, 기간 기반 쿠키

Application-based Cookies

Logging IP traffic using Flow Logs

Target Group attributes stickiness 활성 시

Cross-Zone Load Balancing

EC2 인스턴스 2개짜리 로드 밸런서

Without Cross Zone Load Balancing: 각 가용영역 안에서 부하 분산됨

ALB의 Cross-zone LB는 항상 켜져 있음

SSL/TLS - Basics

SSL 인증서: 클라이언트와 로드 밸런서 사이 트래픽이 이동하는 동안 암호화, 전송 중(in-flight) 암호화

송신자-수신자 측에서만 복호화 가능

SSL: 보안 소켓 계층을 의미, 연결을 암호화하는데 사용
TLS: 새로운 버전의 SSL, 전송 계층 보안

퍼블릭 인증서는 인증 기관(CA)에서 발급, 인증 기관에는 Comodo, Symantec, GoDaddy, ...

Load Balancer - SSL Certificates

ACM: AWS Certificate Manager

SSL - Server Name Indication

SNI: 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트에 지원할 수 있게 해줌

What's an Auto Scaling Group?

자동화

ASG(Auto Scaling Group)의 목표: scale out - 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나, scale in - 감소한 로드에 맞춰 EC2 인스턴스를 제거하는 것

로드 밸런싱과 페어링하는 경우

Auto Scaling - CloudWatch Alarms & Scaling

CloudWatch 기반으로 ASG를 스케일 인 및 아웃할 수 있음

지표(metric), ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스가 필요 -> 지표에 따라 경보가 울림 -> 경보가 ASG의 스케일링 활동을 유발함 -> 오토 스케일링 그룹이라고 불림 (경보에 의해 내부에서 자동적인 스케일링이 이루어짐)

Auto Scaling Groups - Dynamic Scaling Policies

세 가지 유형

Target Tracking Scaling(대상 추적 스케일링): 기본 기준선을 기준으로 상시 사용이 가능하도록
Simple / Step Scaling: CloudWatch 알람으로 CPU 사용률에 따라 유닛 하나를 추가/제거하는 설정 가능
Scheduled Actions

Auto Scaling Groups - Predictive Scaling

CPU 사용량, 인스턴스 요청이 갈 때마다 연산이 수행되어야 하므로
EC2 인스턴스를 갖는 오토스케일링 그룹, e.g., 요청 수 지표는 3
애플리케이션이 네트워크에 연결된 경우 평균 네트워크 입출력량을 기반으로 스케일링을 수행해서 임계값에 도달할 때 스케일링ㅇ을 수행하도록 설정
직접 CloudWatch에서 애플리케이션 별 지표를 설정하고 이를 기반으로 스케일링 정책을 변경

Auto Scaling Groups - Scaling Cooldowns

EC2 인스턴스 구성 시간을 단축하고 요청을 속히

search > install stress amazon linux 2

sudo amazon-linux-extras install epel -y
sudo yum install stress -y

stress -c 4

[Quiz#05]

1) EC2 인스턴스를 r4.large에서 r4.4xlarge로 확장하는 것은 수직 확장성

2) EC2 인스턴스 수를 스케일링하는 오토 스케일링 그룹을 실행하는 것은 수평 확장성

3) ELB는 애플리케이션에 사용 가능한 정적 DNS 이름을 제공함
- AWS 기반 인프라가 변경되어도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유

4) Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 대마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요? - ELB가 고정 세션을 활성화하지 않은 것
- ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줌.(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줌

5) ALB
- X-Forwarded-Port: 클라이언트의 요청 포트를 가져오기 위해 사용
- X-Forwarded-Proto: 클라이언트의 요청 프로토콜을 가져오기 위해 사용

- X-Forwarded-For: (웹사이트로 연결된) 클라이언트의 IP 주소를 포함하는 헤더

6) Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?

- ELB 상태 확인 활성화 -> ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됨

7) NLB: 가장 높은 성능, 가장 낮은 지연 시간

8) ALB 지원 프로토콜: HTTP, HTTPS, WebSocket / NLB: TCP, UDP

9) ALB는 트래픽을 다른 대상 그룹으로 라우팅할 수 있음 - 기반: 요청 URL 경로, 호스트 이름, HTTP 헤더, 쿼리 문자열, 소스 IP 주소

10) ALB 대상 그룹에 등록된 대상: EC2 인스턴스, 사설 IP 주소, Lambda 함수 등 (NLB는 등록된 대상이 될 수 없음)

11) ALB에 탄력적 IP를 연결할 수 없음, NLB는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있음. ALB와 CLB를 정적 DNS 이름으로 사용할 수 있음

12) ELB가 선점하고 있는 쿠키 이름: AWSALB, AWSALBAPP, AWSALBTG

13) 영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됨

14) ALB 기능 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 기능: 서버 이름 표식(SNI)

15) 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 ALB에서 각 호스트 이름에 HTTPS를 구성하려고 할 때 ALB에 서버 이름 표식(SNI)을 사용함

16) 오토 스케일링 그룹은 스케일 아웃 시, 구성된 최대 용량을 넘어설 수 없음

17) Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요?
- 오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있음. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행함

18) 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링할 때: 백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않기에 CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 함
- CloudWatch 사용자 지정 지표를 생성한 후 ASG를 스케일링하기 위한 CloudWatch 경보를 생성

19) ALB의 크기를 수동으로 조정해 EC2 인스턴스의 평균 연결 개수를 약 1,000개가 되도록 조정 정책을 정의하려고 할 때, 대상 추적 조정 정책을 수행함
- ALB만이 EC2 인스턴스로 액세스할 수 있게 하는 가장 안전한 방법임. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙⭐️

20) 한 웹 사이트가 애플리케이션 로드 밸런서 뒤에 있는 오토 스케일링 그룹의 EC2 인스턴스에서 호스팅되고 있습니다. 현재 HTTP로 서비스 중인 웹 사이트를 HTTPS로 바꾸는 작업을 진행하고 있습니다. ACM 인증서를 발급받아 애플리케이션 로드 밸런서에 적용한 상태입니다. 사용자들이 HTTP가 아닌 HTTPS를 사용해 웹 사이트에 접속하게 하려면 어떻게 해야 합니까?
- 애플리케이션 로드 밸런서가 HTTP를 HTTPS로 리디렉션하도록 설정함

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 8

What's an EBS Volume?

EBS(Elastic Block Store): 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브

특정 가용 영역에서만 가능(us-east-1a에서 생성한 경우 us-east-1b에서는 생성 불가)

네트워크 USB stick

EBS Volume

네트워크 드라이브, 특정한 AZ에 위치해서 us-east-1a 볼륨이 us-east-1b로 연결 불가(스냅샷을 이용하면 가능)

EBS - Delete on Termination attribute

Delete on Termination 기능이 root 볼륨에는 설정되어 있으며, 새로운 EBS 볼륨에는 체크되어 있지 않다.
- root에서는 인스턴스 종료와 함께 EBS 볼륨이 삭제된다.

이 옵션으로 EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있다.

Use case: 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우(데이터를 저장할 경우), 루트 볼륨 삭제 속성을 비활성화 한다.

hands-on

+ search > format EBS volume attach EC2

EBS 볼륨의 가용 영역을 인스턴스와 맞춰줘야 한다.

EBS Snapshots Features

최대 75%까지 저렴한 archive tier, 스냅샷을 옮길 수 있는 기능
아카이브를 복원하는 데 24시간에서 최대 72시간이 걸린다.

EBS 휴지통: 스냅샷 삭제 시 recycle bin으로 이동(보관 기간: 1일 ~ 1년)
FSR(빠른 스냅샷 복원): 지연시간 없애는 기능

AMI Overview

아마존 머신 이미지, EC2 인스턴스를 통해 만든 이미지를 통칭

EC2 Instance Store

EC2 인스턴스는 가상 머신이지만 실제로는 하드웨어 서버에 연결되어 있다.
장기적으로 데이터를 저장할 스토리지는 될 수 없다.(장기 스토리지: EBS)

EBS Volume Types

gp2/gp3 (SSD): 범용 SSD 그룹, 절충안

io1/io2 (SSD): 최고 성능, 지연 시간이 낮음

st1 (HDD): 저비용

sc1 (HDD): 가장 비용이 적게 드는 볼륨

EBS Volume Types Use cases General Purpose SSD

범용 gp2, IOPS 프로비저닝

gp2: 짧은 지연 시간, 효율적인 비용의 스토리지

시스템 부팅 볼륨에서 크기는 1GiB - 16TiB

gp2/gp3가 비용 효과적인 스토리지

gp3에서는 IOPS 처리량을 독자적으로 설정할 수 있음

EBS Volume Types Use cases

데이터베이스 워크로드에 적합(스토리지를 이용하는 경우)

EBS Multi-Attach - io1/io2 family

하나의 EBS 볼륨을 같은 가용 영역에 있는 여러 EC2 인스턴스에 연결할 수 있도록 한다. 

각 인스턴스는 고성능 볼륨에 대한 high-performance volume을 갖는다.

해당 가용 영역 내에서만 EBS 볼륨 연결 가능

한 번에 16개의 EC2 인스턴스만 같은 볼륨에 연결할 수 있다.

EBS Encryption

저장 데이터가 볼륨 내부에 암호화된다
암호화가 동시다발적으로 일어난다.

암호화는 지연 시간에는 거의 영향이 없다.

KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 갖는다.

스냅샷을 복사해 암호화를 푼걸 다시 암호화 활성화한다.

Encryption: encrypt an unencrypted EBS volume

EBS 볼륨 암호화 및 암호화 풀기

볼륨의 EBS 스냅샷을 생성하고, 복사 기능을 통해 EBS 스냅샷을 암호화한다.
-> 스냅샷을 이용해 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화된다.
-> 암호화된 볼륨을 인스턴스 원본에 연결한다.

Amazon EFS - Elastic File System

EFS: 관리형 NFS, 네트워크 파일 시스템

네트워크 파일 시스템이므로 많은 EC2 인스턴스에 마운트될 수 있다.

EC2 인스턴스는 서로 다른 가용성 영역에 있을 수 있다.

가용성이 높고 확장성이 뛰어나며 가격이 비싸다.

Amazon EFS - Elastic File System

사용 사례: 콘텐츠 관리, 웹 서빙, 데이터 공유, wordpress

내부적으로 NFS 프로토콜을 사용한다.

윈도우가 아닌 Linux 기반 AMI와만 호환된다.

EFS - Storage Classes

언제 EFS를 사용해야 하는지, 네트워크 파일 시스템에 어떤 옵션을 설정해야 하는지 - 요구사항을 준수하고 검증

EBS vs EFS - Elastic Block Storage

EBS 볼륨과 EFS 파일 시스템의 차이

EBS 볼륨

1)한 번에 하나의 인스턴스에 첨부된다. (io1, io2 유형 볼륨의 다중 첨부 기능을 사용하는 경우 제외)

2) AZ 수준에서 잠긴다.

...

EFS는 EBS보다 가격대가 높다.

[Quiz#04]

1) us-east-1a에서의 EC2 인스턴스를 종료하여, 이 인스턴스에 연결된 EBS 볼륨을 사용할 수 있게 되었다. 팀원이 us-east-1b의 EC2 인스턴스에 이 볼륨을 연결하려 했으나, 연결이 불가능한 상태이다. 이 경우, EBS 볼륨은 가용 영역으로 제한되어 있으므로(특정 AZ에 맞춰 생성되므로) 스냅샷을 활용하여 다른 AZ 간의 이전을 가능하게 한다.

2) AMI는 특정 AWS 리전에 국한되고, 각 AWS 리전에는 고유한 AMI가 있다.

3) EC2 인스턴스를 생성할 때 부팅 볼륨으로는 gp2, gp3, io1, io2, Magnetic(표준) EBS 볼륨 유형만을 사용할 수 있다.

4) EBS 다중 연결이란? 동일한 EBS 볼륨을 동일한 AZ에 있는 다수의 EC2 인스턴스에 연결할 수 있다.

5) EFS는 네트워크 파일 시스템(NFS)으로 여러 AZ 상에 있는 EC2 인스턴스에 동일한 파일 시스템을 마운트할 수 있게 해준다.

6) EC2 인스턴스 스토어는 최적의 디스크 I/O 성능을 제공한다.(EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황)

7) 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행할 경우, 이는 IOPS 기준이므로 EC2 인스턴스 스토어를 선택해야 한다.

- EC2 인스턴스에서 데이터베이스를 인스턴스 스토어를 사용하여 실행 가능하지만, EC2 인스턴스가 중지 시 데이터가 손실이라는 문제가 있다 (문제 없이 다시 시작할 수 있음). 한 가지 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가질 수 있다는 것다. 또 다른 솔루션은 데이터에 대한 백업 메커니즘을 설정하는 것입니다. 요구 사항을 검증하기 위해 아키텍처를 설정하는 방법은 모두 사용자에게 달려 있다.

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 7

Placements Groups

Cluster, Spread(분산, 각 EC2 인스턴스가 여러 AZ에 걸쳐 서로 다른 물리적 하드웨어(랙)에 배치), Partition(분할)

hands-on

EC2- Network & security > Placement Groups

Launch an instance > Advanced details - Placement group에서 설정

Elastic Network Interfaces (ENI)

VPC의 논리적 구성 요소, 가상 네트워크 카드
EC2 인스턴스가 네트워크에 액세스할 수 있게 해준다.

https://aws.amazon.com/blogs/aws/new-elastic-network-interfaces-in-the-virtual-private-cloud/

EC2 Hibernate

절전 모드, 인스턴스 부팅이 빨라진다.

백그라운드에서 RAM에 기록되었던 인 메모리 상태는 루트 경로의 EBS 볼륨에 기록된다.

인스턴스를 종료하면 RAM은 삭제되지만, EBS 볼륨에는 여전히 RAM이 덤프된 게 있으니 인스턴스를 다시 실행하면 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져간다.

hands--on

Launch an instance > Advanced details - Stop-Hibernate behavior: Enable

루트 볼륨에 RAM을 저장할 수 있는 공간, 즉 EC2 인스턴스를 저장할 공간이 충분한지 확인 루트 EBS 볼륨이 암호화되었는지 확인

-> Configure storage - Advanced 설정

EC2 Instance connect 시 최근 재시작부터 가동된 시간

uptime

[Quiz#03]

탄력적 네트워크 인터페이스(ENI)는 다른 AZ에 있는 EC2 인스턴스와 연결될 수 없다.(특정 AZ로 국한된다.)

EC2 인스턴스 RAM은 150GB 미만이어야 함, 절전 모드를 활성화하기 위해서는 EC2 인스턴스 루트 볼륨 유형은 EBS 볼륨이어야 함
EC2 절전 모드는 온디맨드 및 예약 인스턴스를 지원함

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

Amazon EC2

EC2: Elastic compute cloud, AWS에서 제공하는 서비스형 infrastructure

EC2 sizing & configuration options

AWS에서 임대하는 가상 서버인 EC2에서 어떤 것을 선택? EC2 인스턴스 운영체제로 어떤 것을 선택?

OS: Linux, Windows, Mac OS

CPU(compute power & cores), RAM(random-access memory), 부트스트랩 스크립트 등

EC2 User Data

bootstrapping: 머신이 작동될 때 명령을 시작하는 것, 스크립트는 처음 실행할 때 시작

사용자 데이터 스크립트에 작업을 추가할수록 부팅 시 인스턴스가 할 일이 늘어난다.

모든 명령문은 sudo로 실행된다.

EC2 instance types: example

네트워크 성능은 낮음에서 중간 사이

t2 제품군에서 large로 변환하면, 네트워크 성능은 중간, c5d.4xlarge는 CPU, memory, storage 등 달라진다.

t2.micro가 AWS 프리티어

Hands-On: Launching an EC2 Instance running Linux

EC2 인스턴스에서 웹 서버 생성

User data

#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

인스턴스 수명 주기 중 단 한번만 실행, 몇 가지를 업데이트하고 HTTP 코드

EC2 Instance Types - Overview

https://aws.amazon.com/ec2/instance-types

AWS naming convention: example - m5.2xlarge

m: instance class
5: generation
2xlarge: 더 많은 메모리와 사이즈

EC2 Instance Types

compute-intensive tasks
ec2instances.info

Introduction to Security Groups

보안 그룹, 허용 규칙만 포함된다. 보안 그룹끼리 참조할 수도 있다.

EC2 인스턴스에 액세스하려고 할 경우 인스턴스 주변 보안 그룹을 생성해야 한다.(방화벽 생성) -> 보안 그룹은 규칙을 가지게 된다. 그 규칙은 인바운드 트래픽의 여부인데, 외부에서 EC2 인스턴스로 들어오는 것이 허용되면 아웃바운드 트래픽도 수행할 수 있다. 현재 위치에서 인터넷으로 들어오는 것.

Security Groups Deeper Dive

보안 그룹은 EC2 인스턴스의 방화벽이다. 포트로의 액세스를 통제하며 인증된 IP 주소의 범위를 확인해 IPv4인지 IPv6인지 확인한다.

인바운드 네트워크/아웃바운드 네트워크를 통제한다.

Security Groups Good to know

여러 인스턴스에 연결할 수 있다.
보안 그룹과 인스턴스 간의 일대일 관계는 없다.

여러 보안 그룹을 연결할 수 있다.

지역을 전환하면 새 보안 그룹을 생성하거나 다른 VPC를 생성해야 한다.

보안 그룹은 EC2 외부에 있다. -> 트래픽이 차단되면 EC2 인스턴스로는 확인할 수 없다. (EC2 외부의 방화벽이므로)

SSH 액세스를 위해 하나의 별도 보안 그룹을 유지하는 것이 좋다.

time out으로 애플리케이션에 접근할 수 없으면, 보안 그룹의 문제이다.

연결 거부 오류(connection refused)이면 트래픽은 통과했지만, 애플리케이션 문제이거나 실행되지 않는 등 문제이다.

기본적으로 인바운드 트래픽은 blocked, 아웃바운드 트래픽은 authorised

Referencing other security groups Diagram

인바운드 큐칙은 보안 그룹 1의 인바운드를 보안 그룹 2에 허용하는 것
로드 밸런서에서도 나온다.

Classic Ports to know

22: SSH(리눅스 인스턴스 로그인 시)

21: FTP / 22: SFTP / 80: HTTP / 443: HTTPS

3389: RDP(Remote Desktop Protocol, 윈도우 인스턴스에 로그인 시 사용)

HTTP, SSH 등 어떤 것을 시도할 때 time out이 되면, 100% EC2 보안 그룹 때문이다.(EC2 > Security Groups)

How to SSH into your EC2 Instance

ssh ec2-user@(public ipv4 address)
ssh -i EC2Tutorial.pem ec2-user@(public ipv4 address)
chmod 0400 EC2Tutorial.pem (소유자의 읽기 권한)

aws iam list-users 안되는 경우, 자격증명을 찾을 수 없어 aws configure 실행

개인 정보를 입력해두면 이 계정 상의 누구라도 다시 EC2 인스턴스 커넥트 등을 통해 EC2 인스턴스에 접근해서 자격 증명 정보를 실행할 수 있음 -> IAM API key 입력하지 말 것

그 대신 IAM role 이용: 역할을 EC2 인스턴스에 연결해서 자격 증명을 제공

Instances > Actions > Security - Modify IAM role

EC2 Spot Instances

Not suitable for critical jobs or databases

EC2 Dedicated Instances

전용 인스턴스란 자신만의 인스턴스를 자신만의 하드웨어에 갖는다는 것인 반면,

전용 호스트는 물리적 서버 자체에 대한 접근권을 갖고 낮은 수준의 하드웨어에 대한 가시성을 제공해준다.

Which purchasing option is right for me?

On demand - Reserved - Saving Plans - Spot instances - Dedicated Hosts - Capacity Reservations

How to terminate Spot Instances?

원하는 인스턴스 수, 최대 가격, 시작 사양 등 정의 (AMI 등), 언제부터 언제까지 유효한지 등
일회성 요청 or 영구 인스턴스 요청
일회성 요청: 스팟 요청 시 인스턴스 생성 및 스팟 요청은 사라짐
영구 요청: 스팟 요청이 유효한 기간 동안 인스턴스 수도 유효함, 인스턴스가 중지되거나 스팟 가격 기준으로 종료되는 경우

스팟 요청을 취소하고 -> 스팟 인스턴스를 종료

Spot Fleets

스팟 플릿에 스팟 인스턴스를 할당하는 전략을 정의해야 한다.

1) lowestPrice(최저 가격): 스팟 플릿은 가장 낮은 가격인 풀에서 인스턴스를 시작하기 때문에 비용이 최적화된다. 워크로드가 매우 짧은 경우 좋은 옵션

2) diversified: 스팟 인스턴스는 내가 정의한 모든 풀에 분산된다. 가용성과 긴 워크로드에 적합하다.(한 풀이 사라져도 다른 풀은 여전히 활성화되어 있기 때문)

3) capacityOptimized(용량 최적화): 원하는 인스턴스 수에 맞는 최적의 용량을 가진 풀을 갖게 된다.

4) priceCapacityOptimized(recommended)(가격 용량 최적화): 사용 가능한 용량이 가장 큰 풀을 선택하고 그 중 가격이 가장 낮은 풀을 선택, 대부분의 워크로드에 가장 적합한 선택

Spot Fleets: 사용하면 여러 개의 런치 풀과 여러 인스턴스 유형을 정의할 수 있다. 원시 전력만 신경쓰면 된다. 자동으로 가장 낮은 가격으로 스팟 인스턴스 풀을 선택해 추가 비용 절감 가능

- 간단한 스팟 인스턴스 요청을 하는 경우: 원하는 인스턴스 유형과 AZ(Availability Zone)를 정확히 알고 있는 경우
- 스팟 플릿을 요청하는 경우: 조건을 만족하는 모든 인스턴스 유형과 모든 AZ를 선택하라는 것(조건 예: 낮은 가격)

[Quiz#02]

1. 스팟 인스턴스는 단기적인 워크로드에 적합하고, 가장 저렴한 EC2 구매 옵션, EC2 인스턴스를 손실할 우려가 있기 때문에 신뢰도가 떨어진다.(데이터베이스 혹은 중요 업무에는 적합하지 않다.)

2. EC2 인스턴스 내/외의 트래픽을 제어하기 위해 보안 그룹을 사용한다.

3. EC2 예약 인스턴스는 1년 혹은 3년의 기간으로만 예약이 가능하다.

4. 컴퓨팅 최적화 EC2 인스턴스는 고성능 프로세서(배치 처리, 미디어 트랜스코딩, 고성능 컴퓨팅, 과학적 모델링 및 머신 러닝, 전용 게이밍 서버 등)가 필요한 집중 컴퓨팅 워크로드에 적합하다. (고성능 컴퓨팅: HPC)

5. 온디맨드 인스턴스는 가격 예측이 가능한 짧은 경우에 적합, 예약 인스턴스는 장기적인 워크로드에 적합하다.(1년 혹은 3년의 기간)

6. 메모리 최적화 EC2 인스턴스는 메모리에 대규모 데이터 세트가 필요한 워크로드에 적합하다.

7. 스토리지 최적화 EC2 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대해 높은 수준의, 그리고 순차적인 읽기/쓰기 액세스 권한이 필요한 워크로드에 적합하다.

8. 전용 호스트는 높은 수준의 규정 준수가 필요한 기업, 혹은 복잡한 라이선스 모델을 가진 소프트웨어에 적합하다. 가장 비싼 EC2 구매 옵션, 물리적 코어 및 기반 네트워크 소켓 가시성을 기반으로 비용을 책정할 때, 가시성을 확보하기 좋은 구매 옵션

9. 스팟 플릿은 스팟 인스턴스의 집합이고, 선택적으로 온디맨드 인스턴스이다. 스팟 플릿은 가장 낮은 가격으로 스팟 인스턴스를 자동으로 요청할 수 있게 해준다.

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

How can users access AWS?

three options: AWS Management Console, Command Line Interface(CLI), Software Developer Kit(SDK)

don't share your access keys

What's the AWS CLI?

AWS 서비스들과 상호작용할 수 있도록 도와주는 도구 (e.g., aws s3 cp)

What's the AWS SDK?

프로그래밍을 위한 액세스가 가능하도록 하는 것, 코딩을 통해 애플리케이션 내 자체적으로 지원, 프로그래밍 언어

search > aws cli install macos

aws --version

aws-cli/2.16.10 Python/3.11.8 Darwin/23.5.0 exe/x86_64

IAM > Users > (account) > Create access key

region: ap-northeast-2

aws iam list-users

AWS에 액세스하기 위해서는 관리 콘솔을 사용하거나 액세스 키와 비밀 액세스 키를 구성하여 CLI을 구성할 수 있다.

AWS CloudShell는 다음의 AWS 리전에서 사용할 수 있다.

• US East (Ohio)
• US East (N. Virginia)
• US West (N. California)
• US West (Oregon)
• Asia Pacific (Mumbai)
• Asia Pacific (Osaka)
• Asia Pacific (Seoul)
• Asia Pacific (Sydney)
• Asia Pacific (Singapore)
• Asia Pacific (Tokyo)
• Canada (Central)
• Europe (Frankfurt)
• Europe (Ireland)
• Europe (London)
• Europe (Paris)
• Europe (Stockholm)
• South America (São Paulo)

CloudShell: AWS 클라우드에서 무료로 사용 가능한 터미널

IAM Roles for Services

EC2 인스턴스: 가상 서버, AWS에서 어떤 작업을 수행하려고 할 때 권한을 부여하기 위해 IAM Role을 만들어 이들을 하나의 개체로 만든다. EC2 인스턴스가 AWS에 있는 어떤 정보에 접근(액세스)하려고 할 때 IAM Role을 사용한다.

Common roles: EC2 instance roles, Lambda function roles, roles for CloudFormation

IAM Security Tools

IAM Credentials Reports (account-level)
IAM Accesss Advisor (user-level)

IAM Guidelines &  Best Practices

one physical user = one AWS user

never share IAM users & access keys

IAM Section - Summary

Users, Group, Policies, Roles, Security, AWS CLI, AWS SDK, Access Keys, Audit

-

[Quiz#01]

IAM 사용자 그룹은 다른 사용자 그룹에 속할 수 없다. IAM 사용자만을 포함할 수 있다.

IAM 정책의 문장은 시드, 효과, 원칙, 조치, 리소스, 조건으로 구성된다. (버전은 IAM 정책 자체의 일부이며, 문장의 일부가 아니다.)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

Route 53

리전이 필요하지 않음: Global

ref: aws global infrastructure > AWS regional services 제공 서비스 및 가용성 확인

IAM: Users & Groups

Identity and Access Management, Global service
사용자 생성, 그룹에 배치하기 때문에 글로벌 서비스에 해당
Root account created by default + Users
- Groups은 사용자만 배치할 수 있음
- 그룹에 포함되지 않은 사용자가 있을 수 있음(비추천)

- 한 사용자가 다수의 그룹에 속할 수 있음

사용자와 그룹을 구성하는 이유

IAM: Permissions

사용자, 그룹에게 JSON 문서를 지정할 수 있음

최소 권한의 원칙(least privilege principle) 부여

IAM은 글로벌 서비스라 선택할 리전이 없음, 즉 IAM에서 사용자를 생성하면 어디에서나 사용할 수 있음

root를 사용하는 것은 바람직하지 않음, 사용자 생성 필요

IAM Policies Structure

Consists of

1) Version: 2012-10-17 - 정책 언어 버전

2) Id: 정책 식별(optional)

3) Statement

Ststement consists of

(1) Sid: 문장 ID, 문장 식별자(optional)

(2) Effect: 문장이 특정 API에 접근하는걸 허용할 지 거부할 지(Allow/Deny)

(3) Principal: 특정 정책이 적용될 사용자, 계정, 역할

(4) Action: API 호출 목록

(5) Resource: 적용될 action의 리소스 목록

-

[Troubleshooting#01]

Access denied

You don't have permission to iam:ListUsers. To request access, copy the following text and send it to your AWS administrator. Learn more about troubleshooting access denied errors. 

root 계정 IAM > Users > 계정 Permissions policies (0) > Add permissions > Attach policies directly - IAMReadOnlyAccess

User group was not created.
User: arn:aws:iam::058264561455:user/saraheee is not authorized to perform: iam:CreateGroup on resource: arn:aws:iam::058264561455:group/dev because no identity-based policy allows the iam:CreateGroup action

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

AWS is a Cloud Provider
use on demand and scale easily

Services

AWS Regions

all around the world, names can be us-east-1, eu-west-3

a region is a cluster of data centers

How to choose an AWS Region?

1) Compliance(법률 준수): with data governance and legal requirements

2) Proximity(접근성) to customers: reduced latency

3) Available services within a Region

4) Pricing(요금): pricing varies region to region and is transparent in the service pricing page

AWS Availability Zones

Each region has many availability zones

(usually 3, min is 3, max is 6)

example: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c

- they're separate from each other

- they're connected with high bandwidth, ultra-low latency networking

Tour of the AWS Console

Identity and Access Management (IAM)
Route 53 (DNS service)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

SGD (Stochastic Gradient Descent)

Laplace Mechanism
Gaussian Mechanism
Exponential Mechanism
Local Sensitivity Sampling (LSS)
Multiplicative Weights Exponential Mechanism (MWEM)
High-Dimensional Matrix Mechanism (HDMM)
Multiplicative Weights Update (MWU)
Projected Gradient Descent (PGD)
PrivBayes
DualQuery

1. 경사 하강법(Stochastic Gradient Descent, SGD)

장점
연속적인 최적화: SGD는 연속적인 최적화를 통해 합성 데이터를 생성할 수 있어, 쿼리 결과에 대한 차이가 최소화된다.
확장성: 대규모 데이터셋에서도 효과적으로 작동한다.

유연성: 다양한 데이터셋과 쿼리 유형에 적용할 수 있다.
단점
수렴 문제: 학습률(lr)과 같은 하이퍼파라미터에 민감하며, 잘못 설정된 경우 수렴하지 않을 수 있다.
비선형 관계: 데이터의 비선형 관계를 다루는 데 한계가 있을 수 있다.

2. Multiplicative Weights Update (MWU) Mechanism

MWU 메커니즘은 적응적으로 쿼리를 선택하고, 각 쿼리의 응답을 업데이트하는 방법이다. 이 방법은 데이터의 각 레코드에 가중치를 할당하고, 각 쿼리 응답에 따라 가중치를 업데이트한다.
장점
적응적 쿼리 선택: 가장 정보가 많은 쿼리를 선택하여 효율성을 높인다.
프라이버시 보호: 프라이버시 예산을 효율적으로 사용한다.
단점
복잡성: 구현이 복잡하고, 계산 비용이 높을 수 있다.
적용 범위 제한: 일부 특정 쿼리 유형에만 효과적일 수 있다.

3. High-Dimensional Matrix Mechanism (HDMM)

HDMM은 고차원 데이터에 대해 최적화된 방식으로 쿼리를 처리하는 메커니즘이다. 쿼리 집합에 대한 응답을 선형 결합으로 표현하고, 이를 통해 최적의 노이즈 추가 방법을 찾아낸다.
장점
고차원 데이터 처리: 고차원 데이터셋에 대해 효과적으로 작동한다.
최적화된 노이즈 추가: 노이즈 추가를 최적화하여 정확도를 높인다.
단점
계산 복잡성: 계산 비용이 높아 대규모 데이터셋에 적용하기 어려울 수 있다.
제한된 쿼리 유형: 일부 쿼리 유형에 제한적일 수 있다.

4. Projected Gradient Descent (PGD)

PGD는 경사 하강법을 사용하는 투영 메커니즘 중 하나로, 최적화 과정에서 정규화 제약 조건을 적용한다. 이는 주어진 제약 조건 내에서 최적의 해를 찾는 데 효과적이다.
장점
정확도: 제약 조건 내에서 최적화하므로, 정확한 결과를 얻을 수 있다.
제약 조건 적용: 다양한 제약 조건을 쉽게 적용할 수 있다.
단점
수렴 문제: 학습률과 같은 하이퍼파라미터에 민감하며, 잘못 설정된 경우 수렴하지 않을 수 있다.
복잡성: 구현이 복잡할 수 있다.

5. Local Sensitivity Sampling (LSS)

주요 개념

국소 민감도 (Local Sensitivity): 특정 데이터셋에서 특정 쿼리에 대한 민감도를 계산한다. 이는 데이터셋의 특정 부분에서 쿼리 결과의 변동성을 측정한다.
노이즈 추가: 민감도에 따라 적절한 노이즈를 추가하여 프라이버시를 보호한다.
장점
효율적 노이즈 추가: 국소 민감도를 사용하여 보다 효율적으로 노이즈를 추가할 수 있다.
높은 정확도: 민감도에 맞춰 노이즈를 추가함으로써 데이터의 유용성을 유지한다.
단점
복잡성: 민감도를 계산하는 과정이 복잡할 수 있다.
특정 쿼리에 맞춤: 특정 쿼리에 대해 민감도를 계산하므로, 모든 유형의 쿼리에 적용하기 어려울 수 있다.

6. Private Gaussian Mechanism (PGM)

PGM은 Gaussian 노이즈를 추가하여 차등 프라이버시를 보장하는 메커니즘이다. Gaussian 노이즈는 데이터의 평균을 중심으로 정규 분포를 따르는 노이즈를 추가한다.
주요 개념
글로벌 민감도 (Global Sensitivity): 데이터셋 전체에서 특정 쿼리에 대한 민감도를 계산한다. 이는 데이터셋에서 최악의 경우에 쿼리 결과가 얼마나 변할 수 있는지를 측정한다.
Gaussian 노이즈: 정규 분포를 따르는 노이즈를 추가하여 프라이버시를 보호한다.
장점
프라이버시 강화: Gaussian 노이즈를 사용하여 데이터의 민감한 정보를 효과적으로 보호할 수 있다.
적용 범위: 다양한 유형의 데이터셋과 쿼리에 적용할 수 있다.
단점
노이즈 크기: 글로벌 민감도를 기준으로 노이즈를 추가하므로, 데이터셋의 크기와 민감도에 따라 노이즈가 커질 수 있다.
데이터 유용성: 노이즈가 커질수록 데이터의 유용성이 떨어질 수 있다.

7. PrivBayes

PrivBayes는 차등 프라이버시를 보장하는 베이지안 네트워크 기반의 합성 데이터 생성 기법이다. 원본 데이터의 분포를 학습하고, 그 분포를 기반으로 합성 데이터를 생성한다.
장점
정확한 데이터 생성: 원본 데이터의 통계적 특성을 잘 반영한 합성 데이터를 생성할 수 있다.
유용성: 다양한 데이터 분석 및 머신러닝 모델 학습에 사용할 수 있다.
단점
복잡성: 베이지안 네트워크 학습과 파라미터 추정 과정이 복잡하고 계산 비용이 높을 수 있다.
스케일링 문제: 매우 큰 데이터셋에 적용하기 어려울 수 있다.

8. DualQuery

DualQuery는 차등 프라이버시를 보장하는 데이터 쿼리 응답 기법이다. 이 방법은 데이터의 중요한 통계적 쿼리에 대한 정확한 응답을 제공하기 위해 노이즈를 적응적으로 조절한다.

장점
높은 정확도: 적응적 노이즈 조절을 통해 정확한 쿼리 응답을 제공할 수 있다.
적응성: 중요도가 높은 쿼리에 더 적합한 노이즈 수준을 선택할 수 있다.
단점
복잡성: 적응적 노이즈 조절 및 쿼리 선택 과정이 복잡하고 계산 비용이 높을 수 있다.
제한된 쿼리 응답: 특정 유형의 쿼리에 대해서만 적용할 수 있다.

9. MWEM (Multiplicative Weights Exponential Mechanism)

MWEM은 차등 프라이버시를 보장하면서 데이터의 분포를 추정하기 위한 기법이다. 이 방법은 데이터의 가중치를 반복적으로 업데이트하여 실제 데이터 분포에 가까운 분포를 생성한다.

주요 개념
Multiplicative Weights: 데이터의 각 레코드에 가중치를 할당하고, 반복적으로 업데이트한다.
Exponential Mechanism: 쿼리 응답에 노이즈를 추가하여 차등 프라이버시를 보장한다.
장점
정확한 분포 추정: 반복적인 업데이트를 통해 실제 데이터 분포에 가까운 분포를 생성할 수 있다.
적응성: 다양한 쿼리 유형에 대해 적용할 수 있다.
단점
계산 비용: 반복적인 가중치 업데이트 과정이 복잡하고 계산 비용이 높을 수 있다.
수렴 문제: 반복 과정에서 수렴하지 않을 위험이 있다.

상황별추천

대규모 데이터셋:

SGD: 확장성이 좋고, 대규모 데이터셋에서 효과적으로 작동한다.
PGD: 제약 조건이 있는 최적화 문제에 효과적이다.

고차원 데이터셋:

HDMM: 고차원 데이터에 최적화된 방식으로 쿼리를 처리한다.

적응적 쿼리 응답:

MWU: 적응적 노이즈 조절로 높은 정확도를 유지할 수 있다.
DualQuery: 중요한 쿼리에 대한 높은 정확도를 유지할 수 있다.

프라이버시 보호와 데이터 유용성:

MWEM: 반복적인 업데이트를 통한 정확한 분포 추정이 가능한다.
PrivBayes: 원본 데이터의 통계적 특성을 잘 반영한 합성 데이터를 생성할 수 있다.

복잡한 조건부 의존성 처리:

PrivBayes: 베이지안 네트워크를 사용하여 복잡한 조건부 의존성을 처리할 수 있다.

PrivBayes: 원본 데이터의 통계적 특성을 잘 반영한 합성 데이터를 생성할 수 있지만, 계산 비용이 높다.
DualQuery: 적응적 노이즈 조절을 통해 높은 정확도의 쿼리 응답을 제공하지만, 구현이 복잡할 수 있다.
MWEM: 다양한 쿼리 유형에 적용할 수 있으며, 반복적인 업데이트를 통해 정확한 분포를 추정할 수 있지만, 계산 비용이 높을 수 있다.

상위호환 관계

1. SGD < PGD

제약 조건을 추가하여 최적화 문제를 해결할 수 있다.

- PGD: 제약 조건을 적용한 경사 하강법, 데이터의 특정 조건을 만족해야 하는 최적화 문제에 적합하다.

2. Laplace < Gaussian Mechanism

고차원 데이터에 적합, 델타 파라미터 사용하여 노이즈를 추가한다.

3. MWU < MWEM

쿼리 응답과 데이터 분포 추정에 대해 더 복잡하고 정밀한 업데이트를 수행한다.

4. LSS < PGM

국소 민감도를 사용하여 노이즈 추가하는 방식에서, 글로벌 민감도를 기반으로 Gaussian 노이즈를 추가한다.

High-Dimensional Matrix Mechanism (HDMM)
PrivBayes
DualQuery

1. 원핫 인코딩 (One-Hot Encoding)

설명: 각 범주를 이진 벡터로 변환한다. 각 벡터는 하나의 1과 나머지 0으로 구성된다.
장점: 단순하고 직관적, 범주 간 순서나 크기를 가정하지 않음
단점: 차원이 높아질 수 있음, 범주가 많을 경우 메모리 사용량이 증가함
적합성: 많은 노이즈를 추가해야 하는 경우가 많아질 수 있으며, 고차원 데이터는 계산 복잡도를 증가시킬 수 있다.

2. 레이블 인코딩 (Label Encoding)

설명: 각 범주를 고유한 정수로 매핑한다.
장점: 단순하고 메모리 효율적, 차원이 증가하지 않음
단점: 범주 간 순서나 크기를 가정하게 되어 모델이 이를 잘못 해석할 수 있음
적합성: 범주 간의 순서나 크기 정보가 노출될 수 있어 적합하지 않을 수 있다.

3. 순서 인코딩 (Ordinal Encoding)

설명: 범주형 데이터를 순서가 있는 정수로 변환한다.
장점: 순서가 있는 데이터를 잘 표현할 수 있음, 메모리 효율적
단점: 범주 간의 거리를 동일하게 가정, 범주 간 순서가 중요하지 않은 경우 부적절할 수 있음
적합성: 순서가 중요한 경우 유용하지만, 범주 간 순서 정보가 노출될 수 있어 적합하지 않을 수 있다.

4. 바이너리 인코딩 (Binary Encoding)

설명: 각 범주를 고유한 숫자로 매핑하고, 이 숫자를 이진수로 변환한다.
장점: 차원이 원핫 인코딩보다 낮음, 원핫 인코딩과 레이블 인코딩의 중간 정도의 복잡도와 메모리 사용량을 가짐
단점: 복잡도가 증가할 수 있음, 일부 정보가 손실될 수 있음
적합성: 차원이 적당히 낮고, 범주 간의 순서 정보가 직접적으로 노출되지 않아 적합하다.

바이너리 인코딩은, 
차원 감소: 원핫 인코딩보다 낮은 차원을 가지므로 계산 복잡도가 줄어든다.
정보 노출 최소화: 범주 간의 순서나 크기 정보가 직접적으로 노출되지 않는다.
프라이버시 보호: 적당한 수준의 노이즈를 추가하여 프라이버시를 보호할 수 있다.

virtual private network는 공용 인터넷을 통해 가상의 사설 네트워크를 구성해서 프라이빗 통신을 제공함

AWS에서 제공하는 관리형 VPN 서비스: site-to-site VPN, 클라이언트 VPN

Site-to-Site VPN

Site-to-Site VPN은 서로 다른 지리적 위치에 있는 두 네트워크 간에 안전한 연결을 생성한다. 이는 주로 기업 환경에서 사용되며, 두 사이트의 네트워크가 마치 같은 로컬 네트워크 내에 있는 것처럼 통신할 수 있게 해준다.

예를 들어, 본사의 네트워크와 지사의 네트워크를 연결하여 자원을 공유할 수 있다. Site-to-Site VPN은 일반적으로 라우터나 게이트웨이 장치에 구성되며, 모든 트래픽은 이 장치들을 통해 자동으로 암호화되어 전송된다.

클라이언트 VPN (Remote Access VPN)

클라이언트 VPN, 또는 Remote Access VPN은 개별 사용자가 원격 위치에서 기업 네트워크에 안전하게 접속할 수 있게 해주는 기술이다. 사용자는 VPN 클라이언트 소프트웨어를 사용하여 인터넷을 통해 기업의 VPN 서버에 연결하고, 인증 후 네트워크 리소스에 접근할 수 있다. (e.g., 재택 근무나 출장 중인 직원들이 회사의 시스템이나 데이터베이스에 안전하게 접속해야 할 때)

차이점

• 적용 범위: Site-to-Site VPN - 전체 네트워크 간의 연결, 클라이언트 VPN - 개별 사용자가 네트워크에 원격 접속 시 사용
• 구성: Site-to-Site VPN은 네트워크 경계에 위치한 장비에 구성되는 반면, 클라이언트 VPN은 사용자의 장치에 VPN 클라이언트 소프트웨어를 설치하여 사용한다.
• 사용 사례: Site-to-Site VPN은 기업의 다른 위치에 있는 사무실들을 연결하는 데 주로 사용되고, 클라이언트 VPN은 개별 사용자가 어디에서든 안전하게 회사 네트워크에 접속해야 할 때 사용된다.

두 VPN 유형 모두 데이터의 보안과 프라이버시를 보장하는 중요한 도구이며, 사용 사례에 따라 적절한 유형을 선택하여 사용할 수 있다.

VPN, Virtual Private Cloud: 독립된 가상의 클라우드 네트워크 AWS 클라우드 내 논리적으로 독립된 섹션을 제공하여, 사용자가 정의한 가상 네트워크상에서 다양한 AWS 리소스를 실행할 수 있게 지원 인스턴스와 서브넷 레벨에서 인바운드/아웃바운드 필터링을 수행할 수 있도록 보안 그룹과 네트워크 ACL을 제공해서 보안을 강화할 수 있음

사용자 생성 VPC에서 AWS 퍼블릭 서비스나 다른 VPC로 통신이 필요할 경우 일반적으로 외부 인터넷 구간인 퍼블릭 네트워크를 통해 통신이 이루어짐 → 격리된 프라이빗 서브넷에 자원이 생성되어야 함 (금융 서비스처럼 강력한 보안 요건을 만족하기 위해)

VPC 엔드포인트: AWS 퍼블릭 서비스나 직접적으로 생성한 AWS 서비스에 대해 외부 인터넷 구간을 통한 접근이 아닌 직접적으로 접근할 수 있는 프라이빗 액세스 기능

엔드포인트: AWS 퍼블릭 서비스 대상에 대한 프라이빗 연결

• 게이트웨이 엔드포인트: AWS 퍼블릭 서비스 중 S3와 DynamoDB에 대한 연결
• 인터페이스 엔드포인트: 위 대상 외에 나머지 AWS 퍼블릭 서비스에 대한 연결 엔드포인트 서비스: 사용자가 지정한 서비스 대상에 대한 프라이빗 연결

Stateful vs Stateless

Stateful: 이전 상태 정보를 기억하고 있다가 다음 단계에서 그 상태 정보를 활용할 수 있다.

Stateless: 이전 상태 정보를 기억하지 않아 다음 단계에 관여하지 않는다.

보안 그룹

Stateful 접근 제어 동작에서, 인바운드(대상→인스턴스)로 들어오는 트래픽에 대해 인바운드 규칙에 따라 대상이 허용된다면, 그 상태 정보를 기억하고 있어서 아웃바운드로 되돌아갈 때(리턴 트래픽) 아웃바운드 규칙 상관없이 허용된다.

- 허용 규칙만 존재(유형, 프로토콜, 포트 범위, 소스, 설명-선택사항), 지정된 대상이 아닌 것은 자동으로 거부됨

네트워크 ACL

Stateless 접근 제어 동작에서, 인바운드(대상→서브넷)로 들어오는 트래픽에 대해 인바운드 규칙에 따라 대상이 허용한다 해도 그 상태 정보는 상관없다. 아웃바운드로 되돌아갈 때(리턴 트래픽) 아웃바운드 규칙에 따라 허용할지 거부할지 결정한다.

- 허용 규칙과 거부 규칙이 둘 다 존재함(규칙(100-400번), 유형, 프로토콜, 포트 범위, 소스, 허용/거부

- 마지막 규칙은 모든 트래픽에 대해 거부하는 규칙(자동 설정)

References

김원일, 서종호, 따라하며 배우는 AWS 네트워크 입문, enBergen, BOOKK, 07. 네트워크 보안 | 보안 그룹과 네트워크 ACL

[TCP/IP Protocol #14] Part 3 | Chapter 14. UDP

[TCP/IP Protocol #15] Part 3 | Chapter 15. TCP

UDP

비연결형, 신뢰성 없는 전송 프로토콜

호스트 대 호스트 통신 대신에 프로세스 대 프로세스 통신을 제공하는 것 이외에는 IP 서비스에 추가하는 기능이 아무것도 없다.

Q. UDP가 아무런 기능이 없다면 왜 프로세스는 이것을 사용하는가?

A. 단점이 때론 장점이 되기도 한다. UDP는 최소한의 오버헤드만 사용하는 매우 간단한 프로토콜이다. 작은 메시지를 보내고자 하고 또한 신뢰성에 대해서 걱정하지 않는 프로세스는 UDP를 사용할 수 있다.

비연결형 서비스

UDP에 의해 전송되는 각각의 사용자 데이터그램은 서로 독립적이라는 것을 의미한다.

* 데이터그램: 패킷 교환 네트워크와 관련된 기본 전송 단위

흐름 제어 기능 없음 → 수신 측에서는 들어오는 메시지로 인해 오버플로우가 발생할 수 있다

오류 제어 메커니즘이 없음 → 메시지가 손실되거나 중복되었는지 송신자가 알 수 없다는 것이다

혼잡 제어 제공하지 않음 → UDP에서 패킷은 작고 산발적으로 전송된다

검사합

UDP 검사합의 계산은 IP의 경우와도 다르다

의사 헤더(pseudoheader), UDP 헤더, 응용 계층으로부터 온 데이터의 세 부분을 포함한다.

패킷이 TCP에 속하지 않고 UDP에 속한다는 것을 확인하기 위해 프로토콜 필드가 추가되었다.(프로토콜 필드 값은 17)

만약 이 값이 전송 도중 변하면 수신 측에서의 검사합 계산은 이것을 발견할 것이고 UDP는 이 패킷을 폐기할 것이다.

캡슐화

UDP를 통해 보낼 메시지가 있는 프로세스는 UDP로 메시지와 한 쌍의 소켓 주소 그리고 데이터의 길이를 보낸다.

그 이후 UDP 헤더를 추가하여, 소켓 주소들과 함께 사용자 데이터그램을 IP로 보낸다.

큐잉

큐가 없다면 UDP는 사용자 데이터그램을 폐기하고 ICMP 프로토콜에게 'port unreachable' 메시지를 서버로 보낼 것을 요청한다.

다중화와 역다중화

TCP/IP 프로토콜을 수행하고 있는 호스트에서는 UDP는 하나지만 UDP 서비스를 사용하기를 원하는 프로세스는 여러 개 있을 수 있기에 다중화/역다중화를 사용한다.

송신자 측에서는 사용자 데이터그램을 보내고자 하는 프로세스가 여러 개 있을 수 있다. 그러나 UDP는 하나이므로 이것은 다-대-일 관계이고 다중화를 요구한다.

다중화: UDP는 프로세스마다 할당된 포트 번호에 의해서 구분되는 서로 다른 프로세스로부터 메시지를 수신한다. UDP는 헤더를 추가한 후 IP로 사용자 데이터그램을 보낸다.

역다중화: UDP는 사용자 데이터그램을 IP로부터 받는다. 오류를 점검하고 헤더를 없앤 후 UDP는 포트 번호에 의거하여 각 메시지를 적절한 프로세스로 보낸다.

대표적인 응용(TCP와의 차이)

UDP는 단순한 요청-응답 통신을 필요로 하고 흐름 제어와 오류 제어에는 큰 관심이 없는 프로세스에 적절하다.

FTP와 같이 대량의 데이터를 보내야 하는 프로세스에서는 보통 사용되지 않는다.

TFTP(Trivial File Transfer Protocol) 프로세스는 흐름 제어와 오류 제어 메커니즘을 내부에 가지고 있으므로 쉽게 UDP를 사용할 수 있다.

- TFTP: 사용자 인증 없이 기본 파일 전송 기능을 제공하는 단순 프로토콜

UDP는 멀티캐스팅에 적합한 전송 프로토콜이다.(멀티캐스팅 기능은 UDP 소프트웨어에 내장되어 있지만 TCP 소프트웨어는 그렇지 못하다.)

UDP는 SNMP와 같은 관리 프로세스에 사용된다.

- SNMP에 UDP 쓰는 이유: SNMP 메시지는 실시간으로 빠르게 처리되어야 하며, UDP는 세션 설정 지연 없이 즉시 데이터를 전송할 수 있다.

UDP는 수신된 메시지의 조각들 간의 지연이 동일하지 않으면 안되는 실-시간 응용들에 의해서 일반적으로 사용된다.

TCP

다중화와 역다중화 수행

연결 지향 서비스

A 노드에 있는 프로세스가 B 노드에 있는 프로세스와 데이터를 주고받고자 하는 경우에는 다음 세 단계가 발생한다.

두 TCP 간에 가상 연결이 설정된다 → 양방향으로 데이터가 교환된다 → 연결이 종료된다

TCP 세그먼트는 IP 데이터그램으로 캡슐화되어 순서에 어긋나게 전송되거나 손실되거나 훼손되고 재전송 될 수 있다.(물리적인 연결이 아니므로)

그렇지만, TCP는 스트림 기반의 환경을 제공하여 상대방에게 순서에 맞게 바이트를 전달할 책임이 있다.

신뢰성 서비스

TCP는 신뢰성 있는 전송 프로토콜이다. 데이터가 안전하고 오류 없이 잘 도착했는지를 확인하기 위하여 확인응답 메커니즘을 이용한다.

연결 설정

TCP는 전 이중(full-duplex) 방식으로 데이터를 전송한다. 두 기기에 있는 두 개의 TCP가 연결되면, 그들은 동시에 세그먼트를 주고받을 수 있다.

- 세그먼트: TCP에서의 패킷

즉, 데이터의 교환이 이루어지기 전에 한 편에서는 통신을 개시하고 다른 편에서는 통신 개시의 요구에 대한 승인이 먼저 이루어져야 한다.

3단계 핸드셰이크

클라이언트라고 하는 응용 프로그램은 서버라고 하는 또 다른 응용 프로그램과 전송 계층 프로토콜인 TCP를 이용해 연결을 설정하고자 한다. 3단계 핸드셰이크 절차는 서버에서부터 시작한다.

서버: 자신의 TCP에게 연결을 수락할 준비가 되어 있다는 것을 알린다.(이러한 요청: 수동 개방(passive open))

클라이언트: 능동 개방(active open)을 위한 요청을 실행한다. 자신의 TCP에게 특정한 서버와 연결을 설정할 것이라는 것을 알린다.

1) 클라이언트는 첫 번째 세그먼트로서 SYN 플래그가 1로 설정된 SYN 세그먼트를 전송한다. 이 세그먼트는 순서 번호의 동기화가 목적이다. 클라이언트는 임의의 값을 첫 번째 순서 번호로 선택한 후 이 번호를 서버로 전송하는데, 이 순서 번호를 초기 순서 번호(ISN: initial sequence number)라고 한다. (이 세그먼트에는 확인응답 번호나 윈도우 크기가 포함되지 않는다.)

SYN 세그먼트는 단지 하나의 제어 세그먼트이며 어떠한 데이터도 전달하지 않지만, 하나의 순서 번호를 소비한다.

데이터 전송이 시작되면 순서 번호는 1만큼 증가한다. 즉, SYN 세그먼트는 실제의 데이터를 전달하지 않지만 하나의 가상 바이트를 포함하고 있기에 하나의 순서 번호를 소비하는 것이다.

2) 서버는 두 번째 세그먼트로서 SYN과 ACK 플래그 비트가 각각 1로 설정된 SYN+ACK 세그먼트를 전송한다.

이 세그먼트는 두 가지 목적을 가지고 있다.

첫 번째, 반대 방향으로의 통신을 위한 SYN 세그먼트이다. - 서버는 서버로부터 클라이언트로 전송되는 바이트의 순서화를 위한 순서 번호를 초기화하기 위해 이 세그먼트를 사용한다.

두 번째, 서버는 ACK 플래그를 1로 설정하고 클라이언트로부터 수신하기를 기대하는 다음 순서 번호를 표시함으로써 클라이언트로부터의 SYN 세그먼트 수신을 확인 응답한다. - 이 세그먼트는 확인 응답 번호를 포함하고 있다.

3) 클라이언트가 단순히 ACK 세그먼트를 전송한다.

ACK 플래그와 확인응답 번호 필드를 이용해서 두 번째 세그먼트의 수신을 확인한다.

이 세그먼트에 있는 순서 번호는 SYN 세그먼트에 있는 것과 동일한 값으로 설정된다. (∵ ACK 세그먼트는 어떤 순서 번호도 소비하지 않기 때문)

데이터의 첫 번째 바이트의 바이트 번호를 나타내는 새로운 순서 번호를 가지고 있어야 한다.

데이터를 전달하지 않고 어떠한 순서 번호도 소비하지 않는다.

동시 개방

두 프로세스가 동시에 서로에게 능동 개방을 요구하는 상황이 발생한다면, 양쪽 TCP는 서로에게 SYN + ACK 세그먼트를 전송하게 되고 하나의 단일 연결이 두 TCP 사이에 설정된다.

SYN 플러딩 공격

TCP의 연결 설정 과정은 SYN 플러딩 공격이라는 중요한 보안 문제에 노출되어 있다.

악의에 찬 공격자가 데이터그램의 발신지 IP 주소를 위조함으로써 서로 다른 클라이언트로 가장한 후에 많은 수의 SYN 세그먼트를 하나의 서버에 전송하는 경우에 발생한다.

TCP 서버가 핸드셰이크의 세 번째 단계를 기다리는 동안에 자원들은 사용되지 않는 상태로 할당되어 있을 것이다.

이 짧은 시간 동안 전송되는 SYN 세그먼트의 수가 많으면, 서버는 궁극적으로 자원을 다 소비하게 되어 유효한 클라이언트로부터 들어오는 연결 요청을 받아들이지 못하게 될 것 - 서비스 거부 공격(denial of service attack)

TCP에서는 SYN 공격의 영향을 경감하기 위해 몇 가지 방법을 사용한다.

1) 미리 정해진 시간동안 들어오는 연결 요구의 수를 제한하는 방법

2) 원하지 않는 발신지 주소로부터 들어오는 데이터그램을 여과해서 제거하는 방법

- 쿠키(cookie)라고 하는 것을 이용해서 전체 연결이 설정되기 전까지 자원의 할당을 연기하는 것이다. - SCTP가 사용하는 전략

- SCTP: 스트림 제어 전송 프로토콜, 멀티호밍(하나의 연결이 여러 IP 주소를 사용할 수 있어, 네트워크 경로 문제 발생 시 연결의 안정성 높임

연결 종료

일반적으로 클라이언트에서 종료를 시작한다.

3단계 핸드셰이크와 반-닫기(half-close) 옵션을 가진 4단계 핸드셰이크 등 2가지 옵션이 사용된다.

3단계 핸드셰이크

1) 클라이언트 프로세스로부터 close 명령을 수신한 클라이언트 TCP는 첫 번째 세그먼트로서 FIN 플래그를 1로 설정한 FIN 세그먼트를 전송한다. 이 FIN 세그먼트는 클라이언트로부터 전송되는 데이터를 포함할 수도 있으며, 단지 제어 세그먼트일 수도 있다.(제어로 동작하는 경우는 하나의 순서 번호를 소비한다.)

2) FIN 세그먼트를 수신한 서버 TCP는 서버 프로세스에게 연결 종료 상황을 알려준다. 그리고 서버 TCP는 클라이언트 TCP로부터의 수신을 확인하고 동시에 다른 방향으로의 연결 종료를 알려주기 위해 두 번째 세그먼트 FIN + ACK를 전송한다. 이 세그먼트가 서버로부터 수신한 데이터를 포함하지 않는 경우는 하나의 순서 번호를 소비한다.

3) 클라이언트 TCP는 서버 TCP로부터의 FIN 세그먼트 수신을 확인하기 위해 마지막 세그먼트인 ACK 세그먼트를 전송한다. 이 세그먼트는 서버로부터 수신한 FIN 세그먼트에 있는 순서 번호에 1을 더한 값으로 설정되는 확인응답 번호가 포함된다. 이 세그먼트는 데이터를 전달하지 않으며 순서 번호를 소비하지도 않는다.

반-닫기(4-way handshake)

TCP에서는 한 쪽에서 데이터를 수신하면서 데이터 전송을 종료할 수 있다. 이것을 반-닫기라고 한다.

서버나 클라이언트 어느 쪽에서도 반-닫기(half-close) 요청을 시작할 수 있다.(서버에서 모든 데이터를 수신한 후 처리가 시작되는 경우에 발생)

1) 클라이언트는 FIN 세그먼트를 전송함으로써 연결을 반-닫기 한다.

2) 서버는 ACK 세그먼트를 전송함으로써 반-닫기를 수락한다. 그렇지만, 서버는 여전히 데이터를 전송할 수 있다.

3) 서버가 처리된 모든 데이터를 전송한 후에는 FIN 세그먼트를 전송한다.

4) 클라이언트로부터 ACK를 전송하여 확인응답한다.

반-닫기 이후 데이터는 서버로부터 클라이언트로 전달, 확인응답은 클라이언트로부터 서버로 전달된다.

두 번째 세그먼트(ACK)는 어떠한 순서 번호도 소비하지 않는다.

연결이 최종적으로 종료되는 경우에 마지막 ACK 세그먼트의 순서 번호도 증가하지 않는다.(∵ 클라이언트로부터 서버 방향으로 순서 번호가 하나도 소비되지 않았기 때문)

연결 리셋

RST 비트를 1로 설정함으로써 연결 요청을 거절하거나 중단하거나, 휴지 상태에 있는 연결을 종료한다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

[TCP/IP Protocol #11] Part 2 | Chapter 11. 유니캐스트 라우팅 프로토콜(RIP, OSPF and BGP)

유니캐스트 라우팅 프로토콜1(거리 벡터 RIP, 링크 상태 OSPF)

RIP(Routing Information Protocol): 거리 벡터 프로토콜

OSPF(Open Shortest Path First): 링크 상태 프로토콜

BGP(Border Gateway Protocol): 경로 벡터 프로토콜

3. 경로 벡터 라우팅

거리 벡터와 링크 상태 라우팅은 모두 도메인 내부 라우팅 프로토콜이다. 하지만 이 두 프로토콜은 확장성으로 인해 도메인 간 라우팅에는 대부분 적합하지 않다.

- 거리 벡터 라우팅은 동작하는 도메인에 수 홉 이상이 존재하게 되면 불안정해질 수 있다.

- 링크 상태 라우팅은 라우팅 테이블을 계산하기 위해 아주 많은 양의 자원을 필요로 한다. + 플러딩으로 인해 많은 트래픽을 유발할 수도 있다.

* 플러딩: 모든 다른 라우터로 효과적이며 안전한 방법으로 LSP들을 발송하는 것

→ 제 3의 라우팅 프로토콜이 필요, 이것이 경로 벡터 라우팅(path vector routing)

경로 벡터 라우팅의 원리는 거리 벡터 라우팅과 유사하다.(각 자율 시스템에 하나의 스피커 노드만이 다른 것들과 통신할 수 있다는 것을 제외하고는)

자율 시스템 내에 있는 하나의 노드를 스피커 노드(speaker node)라고 부른다.

(다른 AS들에 정보를 제공하기 위해 각 AS는 그 AS에 있는 각 망의 도달 가능성 정보를 모으는 적어도 하나의 경로 벡터 라우팅을 가져야만 한다.)

BGP

경계 게이트웨이 프로토콜(BGP: Border Gateway Protocol), 자율 시스템 간의 라우팅 프로토콜

자율 시스템의 유형

인터넷은 자율 시스템이라고 불리는 계층적 도메인으로 나뉜다.

3개의 범주로 나눌 수 있음: 스터브, 멀티홈, 경유(transit) 시스템

스터브 AS

Stub AS, 다른 자율 시스템과 단 하나의 연결만을 가진다.

스터브 AS 내의 도메인 간 데이터 트래픽은 AS 내에서 생성되거나 사라질 수 있다. 그러나 데이터 트래픽은 스터브 AS를 통해 지나갈 수는 없다. 스터브 AS는 송신자 이거나 수신자 일 수 있다.

멀티홈 AS

Multihomed AS, 다른 자율 시스템과 하나 이상의 연결을 가진다.

하나의 자율 시스템에서 다른 시스템으로 지나가는 트래픽은 허용되지 않고, 데이터 트래픽의 송신자나 수신자만 될 수 있다.

e.g., 지나가는 트래픽을 허용하지 않는 하나 이상의 지역혹은 국가 AS에 연결된 큰 조직이 될 수 있다.

경유 AS

지나가는 트래픽을 허용하는 멀티홈 AS

e.g., 국가 혹은 국제 ISP(인터넷 백본)

CIDR

BGP는 클래스 없는 도메인 간 라우팅 어드레스(CIDR)을 사용한다.

경로 속성

경로는 자율 시스템의 목록으로 표현되었지만 사실은 속성(attributes)들의 목록이라고 할 수 있다.

각 속성은 경로에 대한 정보를 제공한다.

속성들은 두 개의 큰 영역으로 나뉜다. 하나는 잘 알려진 것이고 하나는 옵션이다.

1) 잘 알려진 속성들: 모든 BGP 라우터가 반드시 인식해야만 하는 것들

- 필수 속성: 경로를 기술하는 데 반드시 있어야 한다.

(e.g., ORIGIN: 경로 정보(RIP, OSPF 등)를 제공하는 발신지를 나타낸다.

AS_PATH: 목적지에 도달하기 위해 거쳐야 하는 자율 시스템의 목록

NEXT-HOP: 데이터 패킷이 보내져야 할 다음 라우터

- 임의(discretionary) 속성: 각 라우터가 반드시 인식할 수 있어야 하나 모든 갱신 메시지에 포함되지 않아도 되는 것

2) 선택적인 속성들(옵션): 모든 라우터에서 인식될 필요는 없는 것들

- 천이(transitive): 이 라우터가 이 속성을 지원하지 않더라도 다음 라우터로 전달되어야만 하는 것

- 비천이(nontransitive): 수신한 라우터가 이 속성을 지원하지 않으면 버려지는 것

BGP 세션

BGP를 사용해서 두 라우터 간 라우팅 정보를 교환하는 것은 세션에서 일어난다.

세션은 라우팅 정보를 교환하기 위해서만 두 BGP 라우터들 간에 설정되는 연결이다.

신뢰성 있는 환경을 만들기 위해 BGP는 TCP 서비스를 사용한다. 그러나 BGP를 위해 만들어진 TCP 연결은 다른 응용 프로그램에서와는 다른 약간의 차이가 있다. BGP를 위해 TCP 연결이 만들어지면 무언가 일반적이지 않은 일이 발생하기 전까지 오랜 시간 동안 유지된다.

→ BGP 세션은 반영구적 연결이라고도 불린다.

외부 및  내부 BGP

BGP에는 두 가지 종류의 세션이 있다.

1) 외부(external) BGP(E-BGP) 세션: 서로 다른 자율 시스템에 속하는 두 스피커 노드들 간에 정보 교환을 위해 사용된다.

- 두 스피커 라우터들은 인터넷에 있는 네트워크에 관해 자신이 아는 정보를 교환한다.

e.g., AS1과 AS2 사이에 설정된 세션

2) 내부(internal) BGP(I-BGP) 세션: 자율 시스템 내의 두 라우터 간에 정보 교환을 위해 사용된다.

- 스피커 라우터들이 자율 시스템 내의 다른 라우터로부터 정보를 수집하기 위해 필요하다.

패킷 형식

4가지 패킷 종류: open, update, keepalive, notification

개방(Open) 메시지

BGP가 동작중인 라우터가 이웃 관계를 생성하기 위해서는 그 이웃과 TCP 연결을 열고 개방 메시지를 전송한다.

이웃 관계를 받아들이면 두 라우터 간 이웃 관계가 성립되었다는 뜻으로 킵얼라이브(keepalive) 메시지를 보내게 된다.

- 필드: BGP 버전(현재는 4), 자율 시스템 번호, 유지 시간, BGP 식별자(개방 메시지를 전송한 라우터), 선택 매개 변수들 및 길이

갱신(Update) 메시지

BGP 프로토콜의 중심, 라우터로 하여금 전에 광고된 목적지를 취소하거나 새로운 목적지로의 경로를 알리는 데 사용된다.

- 필드: 불가능 경로 길이(다음 필드의 길이), 취소된 경로(광고된 목록 중에서 삭제되어야 하는 모든 경로를 나열), 경로 속성 및 길이(도달 가능한 네트워크까지의 경로에 대한 속성), 네트워크 계층 도달 가능 정보

킵얼라이브(Keepalive) 메시지

BGP가 동작되는 라우터들은 상대방에게 자신들이 살아있음을 알리기 위해 유지 시간이 만료되기 전에 정기적으로 킵얼라이브 메시지를 교환한다.

- 필드: 공통 헤더만으로 구성됨

통지(Notification) 메시지

오류 상황이 감지되거나 연결을 닫기 원할 때 라우터에 의해 전송된다.

- 필드; 오류 코드, 오류 서브 코드(유형), 오류 데이터

캡슐화

BGP 메시지는 잘 알려진 포트 179를 사용하여 TCP 세그먼트에 캡슐화된다. 이는 오류 제어나 흐름 제어가 필요하지 않음을 의미한다.

TCP 연결이 개설되면 종료(cease) 유형의 통지(notification) 메시지가 전송될 때까지 갱신, 킵얼라이브, 통지 메시지의 교환이 게속된다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

[TCP/IP Protocol #11] Part 2 | Chapter 11. 유니캐스트 라우팅 프로토콜(RIP, OSPF and BGP)

유니캐스트 통신: 하나의 송신자와 하나의 수신자 간의 통신을 의미, one-to-one 통신

유니캐스트 통신을 지원하기 위해 라우터에 생성되는 라우팅 테이블에 관해 논의할 것

자율 시스템(AS: Autonomous System)

비용 또는 메트릭

라우터가 패킷을 수신했을 때, 어느 네트워크로 패킷을 보내야 하는가? 이 결정은 최적화 과정에 기반을 둔다.
그렇다면 최적의 경로란 무엇인가? 최적이라는 용어의 정의는 무엇인가?

망을 통해 전달되는 비용(cost)를 할당하는 것, 이 비용을 메트릭(metric))이라 부른다.

망에서 성능을 최대한 혹은 지연 시간을 최소로 하고 싶다면 성능이 높은 것/낮은 지연 시간이 낮은 비용을 의미한다.

도메인 내 및 도메인 간 라우팅

근래 들어 인터넷은 한 가지 라우팅 프로토콜로 모든 라우터의 라우팅 테이블을 갱신하는 작업을 수행하기에는 부족할 정도로 너무 많이 확장되었다. 이런 이유로 인터넷은 자율 시스템(AS: Autonomous System)으로 나눠진다.

- 자율 시스템: 하나의 단일 관리 기관 하에 있는 라우터와 네트워크의 그룹

- 도메인 내(intradomain) 라우팅: 자율 시스템 내에서의 라우팅 (e.g., 거리 벡터(RIP), 링크 상태(OSPF))

- 도메인 간(interdomain) 라우팅: 자율 시스템 간의 라우팅 (e.g., 경로 벡터(BGP))

RIP(Routing Information Protocol): 거리 벡터 프로토콜

OSPF(Open Shortest Path First): 링크 상태 프로토콜

BGP(Border Gateway Protocol): 경로 벡터 프로토콜

1. 거리 벡터 라우팅

distance vector routing

모든 라우터와 망들로 구성된 AS를 노드의 집합과 이 노드들을 연결하는 선(에지)들로 구성된 그래프로 간주한다.

그래프 이론은 노드들 간의 거리가 주어진 망에서 노드들 간의 최단 거리를 찾기 위해 Bellman-Ford(또는 Ford-Fulkerson)라고 불리는 알고리즘을 사용한다.

Bellman-Ford 알고리즘

임의의 두 노드 쌍 간의 비용을 안다면 두 노드 간의 최소 비용(최단 거리)을 찾을 수 있다.

1) 각 노드와 자신 간의 최단 거리 및 비용을 0으로 초기화함

2) 각 노드와 다른 노드와의 최단 거리를 무한대로 설정함. 그 후 노드와 다른 노드 간의 비용을 주어진 값으로 설정하되 연결이 없으면 무한대로 유지함

3) 최단 거리 벡터에 변경 사항이 더 없을 때까지 알고리즘을 반복함

거리 벡터 라우팅 알고리즘

Bellman-Ford 알고리즘은 도시 간의 도로 지도에 매우 잘 적용된다. (∵ 동일한 지역에 있는 각 노드 간의 초기 정보가 모두 주어지기 때문)

비용: 홉 수 (즉, 목적지에 도달하기 위해 얼마나 많은 망을 거쳐 가야 하는 가, 두 노드 간의 비용은 1로 설정)

각 라우터 필수 보유 정보: 목적지 망, 비용, 다음 홉(next-hop) 정보

무한대로의 카운트

라우팅 프로토콜이 잘 동작하기 위해서는 링크가 고장 나서 비용이 무한대로 바뀌었을 때 모든 다른 라우터들이 이를 즉시 인식할 수 있어야 하는데, 거리 벡터 라우팅에서는 이에 시간이 소요된다.

이 문제: 무한대로의 카운트

두 노드 루프

노드 A와 B는 노드 X에 도달하는 방법을 알고 있다. 그러나 갑자기 A와 X 사이의 링크가 실패했다고 하며 노드 A는 자신의 테이블을 변경한다.

만약 노드 A가 즉각적으로 B에게 테이블을 전송하면 문제가 없다. 그러나 만약 B가 라우팅 테이블을 A로부터 받기 전에 자신의 라우팅 테이블을 보내게 되면 시스템이 불안정해진다.

무한대의 정의

첫 번째 해결책, 무한대를 16과 같은 작은 수로 재정의 (거리 벡터 라우팅의 대부부 구현에서 16을 무한대로 정의)

→ 각 방향으로의 망의 크기가 15 홉을 넘을 수 없음
→ 거리 벡터 라우팅이 큰 시스템에서 사용될 수 없음을 의미

수평 분할

각 인터페이스를 통해 테이블을 플러딩(flooding)하는 대신에 각 인터페이스를 통해 자신 테이블의 일부만을 전송

노드 B가 X에 도달하는 최적의 경로가 A를 거치는 것이라는 것을 안다면 다시 알릴 필요 없음 (이미 A는 알고 있기 때문)

수평 분할과 poison reverse

보통 거리 벡터 프로토콜은 타이머를 사용하고, 경로 상에 새로운 소식이 없으면 테이블에서 이 경로를 제거함

혹은 수평 분할 시나리오에서 노드 B가 A로 보내는 광고에 X로의 경로를 제거해 버림

→ (수평 분할 정책의 단점) 노드 A: 수평 분할 정책 때문에 그런 것인지, B가 최근에 X에 관한 소식을 받지 못해서인지 예측할 수 없음

→ (poison reverse) 동일하게 광고하되, 거리 값을 무한대로 설정해서 "이 값을 사용하지 말라"고 경고함

세 노드 불안정성

X가 도달 가능하지 않음을 발견한 후 노드 A가 이 상황을 노드 B와 C에 패킷을 전송해 알림

노드 B는 즉각적으로 테이블을 갱신했으나 노드 C로 가는 패킷은 유실

RIP

경로 정보 프로토콜
RIP에서 사용되는 메트릭으로, 거리는 목적지에 도달하기 위해 사용되어야만 하는 링크(네트워크)의 수로 정의된다. 이런 이유로 RIP에서의 메트릭은 홉 수라고 불린다.

2. 링크 상태 라우팅

도메인 내의 각 라우터가 도메인의 전체 토폴로지 -노드들과 링크들의 리스트, 그 유형, 비용(메트릭) 및 링크가 살아 있는지 죽어 있는지와 같은 상태를 포함해서 어떻게 연결되어 있는지- 를 알고 있다면 노드는 딕스트라(Dijkstra) 알고리즘을 사용하여 라우팅 테이블을 만들 수 있다.

라우팅 테이블 만들기

1) 각 노드에 의해 링크 상태를 생성하는 것: 이는 링크 상태 패킷(LSP: link state packet)이라고 함

2) 모든 다른 라우터로 효과적이며 안전한 방법으로 LSP들을 발송하는 것: 플러딩(flooding)이라고 부름

3) 각 노드에서 최단 경로 트리의 생성

4) 최단 경로 트리에 기반을 둔 라우팅 테이블의 계산

OSPF

Open Shortest Path First 프로토콜, 라우팅을 적절하게 수행하기 위해 OSPF는 자율 시스템을 여러 지역으로 나눈다.

지역(areas)이란 자율 시스템 내에 포함되는 호스트, 라우터 및 네트워크의 모음이다.

하나의 자율 시스템은 여러 개의 다른 지역들로 나뉠 수 있다. 지역 내의 모든 네트워크들은 연결되어야만 한다.

링크의 유형

네트워크는 링크(link)라고 불린다. 4가지 유형의 링크가 정의 되는데 각각 점-대-점(point-to-point), 경유(transient), 스터브(stub), 가상(virtual) 링크이다.

점-대-점 링크

라우터 간을 그 사이에 어떤 다른 호스트나 라우터 없이 직접 연결하는 것, 링크(네트워크)의 목적은 단지 라우터 간을 연결하는 것

경유 링크

몇 개의 라우터가 연결되어 있는 네트워크, 데이터는 어떤 라우터로도 들어갈 수 있고 어떤 라우터로부터도 떠날 수 있다.

각 라우터가 하나의 단일 네트워크를 통해 다른 라우터들과 연결되어 있다는 것을 보여주기 위해 네트워크 자체는 단일 노드로 표현되어야 한다. 그러나 여기서 문제가 되는 것은 네트워크가 장치가 아니므로 라우터로 동작할 수 없다는 것이다.

따라서 네트워크에 있는 라우터 중 하나가 이런 책임을 맡아야 한다. 이 라우터에게는 두 가지 목적이 주어지는데 하나는 실제 라우터로서 이고, 다른 하나는 지정(designated) 라우터로서 이다.

스터브 링크

단지 하나의 라우터에만 연결된 네트워크이다. 데이터 패킷은 이 단일 라우터를 통해서만 네트워크에 들어가거나 나갈 수 있다.

이런 상황을 나타내기 위해서는 라우터를 노드로, 네트워크를 지정 라우터로 표시해야 한다.

가상 링크

두 라우터간의 연결이 끊어지면 관리자는 여러 라우터를 거쳐 돌아가는 더 긴 경로를 사용하더라도 그 둘 사이에 가상 링크를 연결해야 한다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

ELB (Elastic Load Balancing)

0. 로드밸런서의 탄생

VPC 내 단일 서버를 통한 서비스를 구성해서 사용자가 접근하는 환경에서는, 단일 서버가 장애가 발생되면 서비스를 받을 수 없다.

지속적인 서비스 제공을 위해 서버를  다중화 구성해서 서비스의 연속성을 보장하는 고가용성 구성이 필요하다.

다수의 서버를 구성해서 서비스를 제공하면, 인스턴스 하나의 장애가 발생하더라도 다른 인스턴스로 서비스를 받을 수 있다.

하지만 서비스 타깃을 사용자 입장에서 일일이 지정해줘야 하는데,
사용자 입장에서 장애를 인지하여 타깃을 변경하기 전까지는 서비스를 받을 수 없을 것이고 이러한 환경은 서비스 연속성을 보장하는 고가용성 구성이라고 할 수 없을 것이다.

이러한 문제를 해결하기 위해 부하 분산 기술인 로드 밸런서(Load Balancer)가 존재한다.

1. 웹 트래픽 증가에 대한 처리 방식

1) Scale-up

CPU, 메모리, 디스크 등의 기능을 업그레이드 하는 방식

기존보다 높은 성능을 보유한 서버로 시스템을 업그레이드함으로써 문제를 해결하는 방식으로,

필요로 하는 성능이 높아질수록 비용이 기하급수적으로 늘어나는 단점이 있다.

또한 하나의 서버에서 웹 서비스를 제공하여 서버 중지 및 장애로 인해 웹 서비스 가용성에 문제가 발생할 수 있다.

2) Scale-out

저렴한 노드 여러 개를 하나의 Cluster로 구성하는 방식

Cluster 내 하나의 노드에 문제가 발생해도 웹 서비스가 중단되지 않으므로 가용성이 높은 웹 서비스를 구성할 수 있다.

로드 밸런싱은 Scale-out 방식의 웹 서비스 구성에 주로 사용되고, 트래픽을 분산 처리함으로써 높은 가용성과 부하 분산을 통한 고효율 웹 서비스를 제공한다.

2. ELB 정의

EC2(Elastic Compute Cloud) 인스턴스의 상태를 확인하고 데이터를 분산해서 전달하는 단일 접점 역할을 수행한다.

* EC2: 컴퓨팅 리소스를 제공하는 서비스

로드 밸런서는 크게 자신이 서비스하는 대상을 정의하는 리스너(Listener)와 부하 분산 대상을 정의하는 대상 그룹(Target Group)으로 이루어져 있다.

- 리스너: 부하 분산 처리를 위한 서비스 정의

프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스, 로드 밸런서에서 서비스하고자 하는 프로토콜과 포트를 지정하는 규칙을 생성(TCP, TLS, UDP, HTTP(S) 등)

- 대상 그룹: 부하 분산 대상 그룹 정의

 하나 이상의 대상을 라우팅하여 부하 분산을 하는 데 사용됨. 대상 그룹(target group)에 속한 대상에 대해 주기적으로 확인하는 프로세스(keepalive)를 통해 상태 확인(health check)을 수행한다.

3. 로드 밸런싱 방식

Round Robin

Real 서버의 Session 연결을 순차적으로 맺어주는 방식

연결되어 있는 Session 수에 상관 없이 순차적으로 연결시키는 방식으로 Session에 대한 보장을 제공하지 않는다.

Hash

hash 알고리즘을 이용한 로드 밸런싱 방식

Client와 Server 간에 연결된 Session을 계속 유지해 주는 방식으로 Client가 특정 Server로 연결된 이후 동일 서버로만 연결되는 구조로 Session에 대한 보장을 제공한다.

Least Connection

Session 수를 고려하여 가장 작은 Session을 보유한 서버로 Session을 맺어주는 연결 방식

Sesison에 대한 보장을 제공하지 않는다.

4. ELB 종류

Application Load Balancer, Network Load Balancer, Classic Load Balancer 3가지 유형

ALB

HTTP나 HTTPS와 같이 웹 애플리케이션에 대한 분산 처리를 제공(7계층)

URL 경로 기반 라우팅, 호스트 기반 라우팅, HTTP 헤더 기반 라우팅 등과 같이 다양한 규칙을 생성하여

포워드, 리다이렉션, 지정 HTTP 응답 등의 작업 수행 가능

NLB

TCP나 UDP, TLS 프로토콜에 대한 포트 정보를 정의하여 네트워크 기반의 분산 처리를 제공(4계층)

가장 빠른 처리 속도가 가능하고 고정 IP나 탄력적 IP를 보유할 수 있다.
* 탄력적 IP: 동적 클라우드 컴퓨팅을 위해 고안된 정적 IP주소, AWS 계정에 할당되고 릴리스할 때까지 할당된 상태로 유지된다.

CLB

VPC의 예전 버전인 EC2-Classic에 대해서도 분산 처리를 제공, 이전 세대의 로드 밸런서

3-4계층에서 작동, EC2-Classic 네트워크 내에 구축된 애플리케이션을 대상으로 제공

5. ELB 통신 방식

인터넷 연결 (Internet Facing Load Balancer)

퍼블릭 주소를 보유해서, 인터넷을 통해 요청을 로드 밸런서에 등록된 EC2 인스턴스로 라우팅한다.

내부 (Internal Load Balancer)

프라이빗주소를 보유해서, 로드 밸런서를 위한 VPC 내부에 액세스하여 등록된 EC2 인스턴스 등 컴퓨팅 자원으로 라우팅한다.

6. ELB 특징

1) 상태 확인 서비스(Health Check)

대상 그룹에 대한 Keepalive를 통해 주기적으로 상태를 확인한다.

ELB와 연결된 인스턴스의 연결 상태를 수시로 체크해서, 연결 장애나 서비스 가능 여부에 대한 Health Check를 지속적으로 수행한다.

Health Check가 실패하는 경우 해당 인스턴스로 트래픽을 전달하지 않는다.

(이를 위해 HTTP, HTTPS 상태 확인 빈도, 실패 임계치, 성공 시 응답 코드로 임의 설정)

HTTP나 HTTPS 방식은 특정 웹 페이지의 접속 시도에 따른 응답 코드(200)가 정상 반환 여부를 확인해서 Health Check 성공/실패 여부를 판단한다.

2) Sticky Session

처음 연결된 Client에 별도의 HTTP 기반의 쿠키 값을 생성해서 다음 번 연결 요청에 대해 처음 접속했던 서버로 계속 연결하도록 트래픽을 처리한다.

∵ ELB로 트래픽을 부하 분산하는 경우 기본적으로는 Round Robin 방식으로 트래픽을 분산하면 한 번 연결된 Session이 다음 연결 시 그대로 연결되지 않고 다른 인스턴스로 연결될 수 있어 애플리케이션의 Session을 유지할 수 없게 된다.(웹 사이트의 로그인/인증 정보 유지X)

3) 고가용성 구성

ELB로 인입되는 트래픽을 다수의 대상으로 분산하여 고가용성(High Availability)을 유지한다.

고가용성 구성을 위해 Route 53와 같은 AWS의 다른 서비스와의 연계를 통해 가용성 서비스를 제공할 수 있다.

4) 보안 기능

보안 옵션을 부여할 수 있다. (NLB는 보안 그룹이 적용되지 않는다.)

ELB의 SSL Termination 기능을 사용하면 개별 인스턴스에 SSL 인증서를 직접 설치할 필요가 없다.

- 웹 사이트에 SSL 인증서를 적용하여 HTTPS와 같은 방식으로 암호화 통신을 하기 위해서는 개별 웹 서버에 별도의 공인인증서를 구매 후 적용해야 한다.

5) 4계층/7계층 로드밸런싱: 각 계층의 로드 밸런싱을 사용할 수 있음(HTTP/HTTPS: 7계층, TCP/UDP: 4계층)

6) 운영 모니터링: ELB 애플리케이션 성능을 실시간으로 모니터링한다.

References

김원일, 서종호, 따라하며 배우는 AWS 네트워크 입문, enBergen, BOOKK

권영환, 아마존 웹 서비스(AWS Discovery Book), 정보문화사

사전 지식: 웹 브라우저, PC 운영 체제, 인터넷 서비스 제공업체, 웹 사이트 호스팅하는 서버, 해당 서버에서 실행되는 서비스

[수행 단계]

웹 사이트를 호스팅하는 웹 서버의 위치 조회

웹 서버에 연결

특정 페이지를 가져오기 위한 요청 전송

웹 서버의 응답을 처리

사용자가 웹 사이트와 상호 작용할 수 있도록 페이지 렌더링

웹 브라우저에서 sarahee.tistory.com과 같은 URL을 가리키면

브라우저는 인터넷에서 사이트를 호스팅하는 서버를 파악해야 한다.

인터넷의 각 디바이스에는 모두 IP 주소라는 고유한 주소가 존재하지만 이러한 숫자는 기억하기 어렵다.

인터넷도 마찬가지, 도메인 네임 시스템(DNS)은 휴대폰의 연락처 앱과 같다.

DNS는 브라우저가 인터넷에서 서버를 찾는 데 도움이 된다.

DNS를 조회하여 도메인 이름(sarahee.tistory.com)을 기반으로 서버의 IP 주소를 찾을 수 있다.

1. 웹 브라우저에 URL을 입력하고 Enter 키 입력

도메인 (Domain)

Lightsail DNS 영역을 보면 Lightsail 인스턴스의 고정 IP 주소를 나타내는 DNS A 레코드

경로 (Path)

URL에 리소스에 대한 추가 경로

리소스 (Resource)

이 URL을 브라우저에 입력하면 

브라우저에 URL을 입력하고 enter 키를 누른 후 브라우저는 인터넷에서 연결할 서버를 파악함

1. 응용 계층(Application Layer)

HTTP 프로토콜을 사용해서 웹 서버에게 'amazon.com' 웹 페이지 요청을 준비한다.

이는 DNS 조회를 포함해서 'amazon.com'의 IP 주소를 찾는 과정이 포함된다.

2) www.amazon.com에 대한 요청은 일반적으로 케이블 인터넷 공급 업체, DSL 광대역 공급업체 또는 기업 네트워크와 같은 인터넷 서비스 제공 업체(ISP)가 관리하는 DNS 해석기로 전달된다.

* DSL: 도메인 특화 언어(Domain Specific Language), 특정 도메인에 특화된 비교적 작고 간단한 프로그래밍 언어

3) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 DNS 루트 이름 서버에 전달된다.

4) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달한다. .com 도메인의 이름 서버는 amazon.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답한다.

5) ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.amazon.com에 대한 요청을 해당 이름 서버에 전달한다.

6) Amazon Route 53 이름 서버는 amazon.com 호스팅 영역에서 www.amazon.com  레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환한다.

7) ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 된다. 해석기는 이 값을 웹 브라우저로 반환한다. 또한 DNS 해석기는 다음에 누군가가 amazon.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 동안 amazon.com의 IP 주소를 캐싱(저장)한다.(TTL(Time to Live) 참조)

8) 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.amazon.com에 대한 요청을 전송한다. 여기가 콘텐츠(Contents)가 있는 곳으로, 웹 사이트 엔드 포인트(End-point)로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버이다.

2. 표현 계층(Presentation Layer)

데이터를 네트워크에서 전송할 형식으로 변환한다. 예를 들어, 암호화된 데이터를 HTTP 요청으로 사용할 경우 이 계층에서 암호화 및 압축이 이루어진다.

통신 규약(protocol)

HTTPS: Hypertext Transfer Protocol Secure

브라우저에 전송 계층 보안(TLS)을 사용하여 서버에 연결하도록 지시, 브라우저와 서버 간 교환되는 데이터 암호화(e.g., 암호, 신용 카드 정보)

TLS: 인터넷을 통한 통신을 보호하는 암호화 프로토콜

- HTTP와 같은 응용 계층 클라이언트/서버 프로그램은 SSL 패킷에 자신들의 데이터를 캡슐화할 수 있는 TCP 서비스를 사용한다. 만약 서버와 클라이언트가 SSL(또는 TLS) 프로그램을 실행할 수 있다면, 클라이언트는 HTTP 메시지가 SSL/TLS 패킷에 캡슐화할 수 있도록 허용하기 위해 URL http:// 대신 https:// 를 사용할 수 있다.

- 서비스: 단편, 압축, 메시지 무결성, 기밀성(대칭 암호화), 프레임 만들기(헤더는 암호화된 페이로드에 더해짐)

3. 세션 계층(Session Layer)

클라이언트와 서버 간의 세션을 관리한다. 데이터 교란을 시작하고 종료하는 역할을 한다.

4. 전송 계층(Transport Layer)

TCP를 사용해서 'amazon.com'의 서버와의 연결을 설정한다. 포트 번호를 통해 HTTP 요청이 올바른 애플리케이션으로 전달되도록 한다.(예: 웹 서버의 80번 포트 또는 443번 포트)

5. 네트워크 계층(Network Layer)

IP 주소를 기반으로 데이터 패킷을 'amazon.com'의 서버로 라우팅한다. 데이터 패킷이 여러 네트워크 장비를 거치게 된다.

6. 데이터 링크 계층(Data Link Layer)

물리적 네트워크 경계 내에서 패킷을 전송한다. MAC 주소를 사용해서 패킷을 네트워크의 다음 장치로 전달한다.

7. 물리 계층(Physical Layer)

실제 전기 신호로 변환하여 네트워크 케이블이나 무선 매체를 통해 데이터를 전송한다.

2. 웹 브라우저가 도메인명의 IP 주소 조회

브라우저에 URL을 입력하고 Enter 키를 누른 후 브라우저는 인터넷에서 연결할 서버를 파악함

입력한 도메인을 사용해 웹 사이트를 호스팅하는 서버의 IP 주소를 조회 (DNS 조회를 사용해 이 작업을 수행함)

DNS 데이터는 웹 브라우저 사이의 서로 다른 계층과 인터넷의 다양한 위치에 임시로 저장됨 - 캐시(Cache)

DNS 레코드 조회(고정 IP 주소를 레코드에 추가)

로드밸런서에 지정하여 동적으로 IP 주소를 할당함

웹 브라우저가 캐시 계층에서 IP 주소를 찾을 수 없는 경우 

회사 네트워크 또는 ISP의 DNS 서버가 재귀적 DNS 조회를 수행함

인터넷에 있는 여러 DNS 서버를 요청, 검색될 때까지 DNS 레코드에 대해 더 많은 DNS 서버에 요청함

웹 브라우저가 IP 주소로 DNS 레코드를 가져오면 인터넷에서 서버를 찾아 연결을 설정함

DNS Prefetch: 특정 웹 브라우저에서 미리 도메인 네임을 확인

- 사용자가 해당 도메인으로 이동할 때 DNS 확인 시간으로 인한 지연 발생하지 않음

3. 웹 브라우저가 서버와의 TCP 연결 시작

웹 브라우저 요청 패킷은 일반적으로 TCP/IP(Transmission Control Protocol/Internet Protocol)라고 하는 전송 제어 프로토콜을 사용하여 이동, 통신 회사간 경로인 라우팅 테이블을 따라 연결할 IP 주소가 있는 웹 서버 찾음

but, 요즘은 직접 서버에 연결하기 보다 콘텐츠 전송 네트워크(CDN)를 사용하여 정적/동적 콘텐츠를 웹 브라우저 가까이에 위치시킴

(e.g., 동영상, 음악 파일 - ISP의 데이터 센터에 있는 콘텐츠 배포 서버에 위치하여 버퍼링 없이 서비스 감상이 가능함)

내 컴퓨터에서 sarahee.tistory.com으로 이동하는 홉을 추적하기 위해 traceroute를 사용함(윈도우: tracert)

첫번째 hop은 내 라우터에 관한 것

각 요청은 가장 성능이 좋은 위치를 통해 지능적으로 라우팅되어 브라우저에 콘텐츠를 전송함

로드밸런싱 기능 이용

- 로드밸런서: 여러 웹 서버의 부하 분산을 해줌

웹 브라우저가 인터넷에서 서버를 찾으면, 웹 서버와 TCP 연결을 설정하고 HTTP를 통해 평문 통신을 시작함

HTTPS를 사용하는 경우 데이터 암호화를 위한 TLS(Transport Layer Security) handshake 추가 과정을 수행

4. 웹 브라우저가 HTTP 요청을 서버로 전송

페이지 콘텐츠를 요청하기 위해 서버에 HTTP 요청을 전송

HTTP 요청에는 요청 method가 포함됨

- GET, POST, PUT, PATCH, DELETE 등

- 요청된 리소스를 가리키는 경로, 통신할 HTTP 버전

5. 웹 서버가 요청을 처리하고 응답을 다시 전송

GET /~/~ HTTP/1.1 요청에 대해 서버는 이 경로의 콘텐츠를 가져오고 응답을 생성하여 클라이언트로 다시 전송함

6. 웹 브라우저가 콘텐츠 렌더링

서버로부터 응답을 받으면 응답 헤더를 검사해서 리소스를 렌더링하는 방법에 대한 정보를 확인한다.

GET 요청은 HTML을 반환해서 페이지의 구조를 알 수 있다. 하지만 웹 브라우저의 개발 도구를 사용해서 페이지 HTML을 검사하면 다른 Javascript, CSS, 이미지 리소스를 참고하고 웹 페이지를 설계된 대로 렌더링하기 위해 추가 데이터를 요청한다.

HTML 내에서 CSS나 JS 파일 리소스를 참조하는데, CSS 리소스 요청에 대한 Content-Type 헤더로 브라우저에 CSS를 렌더링하도록 지시한다.

Reference

https://aws.amazon.com/ko/blogs/korea/what-happens-when-you-type-a-url-into-your-browser/

IPv6 데이터그램 형식 기술

인터넷 프로토콜 버전 6(IPv6: Internet Protocol version 6)이 필요한 이유

1) IPv4에서 직면한 주소 고갈 문제

2) 불필요한 처리로 인한 속도 저하, 새로운 옵션의 필요성, 멀티미디어 지원, 강력한 보안의 필요성 등

[변경된 부분]

1) 확장된 주소공간: IPv6 주소는 128비트 길이임, IPv4 주소의 32비트와 비교할 때, 주소 공간길이가 매우 크게(2^96배) 증가함

2) 개선된 헤더 형식: IPv6는 옵션들이 기본 헤더로부터 분리됨, 필요 시 기본 헤더와 상위 계층 데이터 사이에 삽입되는 새로운 헤더 형식을 사용함

→ 대부분의 옵션이 라우터에 의해 검사될 필요가 없음 → 라우터 과정을 단순화하고 빠르게 함

3) 새로운 옵션: IPv6는 부가적 기능을 허용하는 새로운 옵션을 가짐

4) 확장 허용: IPv6는 새로운 기술이나 응용 분야에 의해 요구되는 프로토콜의 확장을 허용하도록 설계됨

5) 자원 할당에 대한 지원: 서비스 유형(type-of-service) 필드가 삭제되고 흐름 레이블이라는 메커니즘이 추가됨

7) 향상된 보안성 제공: IPv6에서 암호화와 인증 옵션들은 패킷의 신뢰성과 무결성을 제공함

IPv4와 IPv6 헤더의 비교

- IPv6에서 헤더의 길이는 고정되어 있기 때문에 헤더 길이 필드가 제거됨

- IPv6에서 서비스 유형 필드는 제거됨, 트래픽 클래스와 흐름 레이블 필드는 서비스 유형 필드의 기능을 대신함

- 총 길이 필드는 IPv6에서 제거되고 페이로드 길이 필드로 대체됨

- 식별(identification), 플래그(flag) 및 옵셋(offset) 필드들은 IPv6 기본헤더에서 제거됨, 단편화 확장 헤더에 포함됨

- TTL 필드는 IPv6에서 홉 제한(hop limit)으로 불림

- 프로토콜 필드는 다음 헤더 필드로 대치됨

- 헤더 검사합(checksum)은 상위 계층 프로토콜에 의해 제공되므로 제거됨, 따라서 네트워크 계층에서는 필요하지 않음

- IPv4에서 옵션 필드(option field)는 IPv6에서는 확장 헤더로 구현됨

채택이 지연된 원인

IPv4 주소 고갈 문제가 3가지 문제로 필요성이 감소됨: 클래스 없는 주소 지정, 동적인 주소 할당을 위한 DHCP, NAT

패킷 형식

구성: 기본 헤더, 페이로드

- 버전(version): 4비트 필드, IP의 버전을 정의함

- 트래픽 클래스(traffic class): 8비트 필드, 서로 다른 전달 요구사항을 갖는 페이로드를 구분

- 흐름 레이블(flow label)

IPv4에서 IPv6로의 천이

Transition strategies: Dual stack, Tunneling, Header translation

이중 스택

버전 6으로 완전하게 이전하기 전에 모든 호스트가 이중 스택(dual stack) 프로토콜을 갖는다.

다른 말로, 인터넷의 모든 시스템이 iPv6를 사용할 때까지 IPv4와 IPv6를 동시에 운용해야 한다.

패킷을 목적지로 보낼 때 어느 버전을 사용해야 할지를 결정하기 위해 발신지 호스트는 DNS에 질의를 한다.

DNS가 IPv4/6 주소를 응답한다면 발신지 호스트는 IPv4/6 패킷을 보낸다.

터널링

tunneling, IPv6를 사용하는 두 컴퓨터가 서로 통신하는데 IPv4를 사용하는 영역을 통과해야만 할 때 사용되는 전략

IPv6 패킷 영역에 들어갈 때 IPv4 패킷 내 캡슐화되고, 영역을 나올 때 역캡슐화된다.

헤더 변환은 IPv6 주소를 IPv4 주소로 변환하기 위해 맵 주소를 이용한다.

IPv6 패킷 헤더에서 IPv4 패킷 헤더로 변환하는 과정에서 사용되는 규칙

- IPv6 맵 주소는 오른쪽 32비트를 취함으로써 IPv4 주소로 변환된다.

- IPv6 우선권 필드의 값은 버려진다.

- IPv4에서 서비스 필드의 형태는 0으로 설정된다.

- IPv4의 검사합이 계산되어 해당 필드에 삽입된다.

- IPv4 흐름 레이블은 무시된다.

- 호환 확장 헤더는 옵션들로 전환되어 IPv4 헤더에 삽입된다.

- IPv4 헤더의 길이는 계산되어서 해당 필드에 삽입된다.

- IPv4 패킷의 전체 길이는 계산되어서 해당 필드는 삽입된다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

RFC 2460, 2461, 2462