🐆 LabGuide - AWS Global Accelerator

작성자 : ongja.cloudnet@

AWS Global Accelerator 참고 링크

Global Accelerator 개요
Global Accelertor 소개 (AWS 한국 블로그)
Global Accelerator Developer Guide (설명서)
Traffic management with AWS Global Accelerator
Global Accelerator 요금

💡 AWS 서비스 관련해서는 항상 최우선으로 ‘AWS 설명서’를 읽어보는 것을 추천한다.
한글 번역이 매끄럽지 못하면 English 로 변경 후 읽어보길 바란다.

1. AWS Global Accelerator Theory

1.1 AWS Global Accelerator 란?

AWS Global Accelerator는 로컬 또는 글로벌 사용자를 대상으로 어플리케이션의 가용성과 성능을 개선하는 서비스이다.
AWS Global Accelerator는 AWS 글로벌 네트워크를 통해 사용자에서 어플리케이션으로 이어진 경로를 최적화하여 트래픽의 성능을 개선한다.

1.2 AWS Global Accelerator Key Words

고정 Anycast IP – AWS Global Accelerator는 하나 이상의 AWS 리전에서 호스팅되는 애플리케이션에 대한 고정 진입점 역할을 하는 정적 IP 주소를 사용한다. 이 IP 주소는 AWS 엣지 로케이션에서 할당되는 Anycast입니다. 즉, 이 IP 주소가 여러 AWS 엣지 로케이션에서 발표되므로 트래픽이 사용자에게 최대한 가까운 위치에서 AWS 글로벌 네트워크에 진입할 수 있다.
AWS의 글로벌 네트워크 – AWS Global Accelerator를 통해 라우팅되는 트래픽은 공용 인터넷이 아니라 AWS 글로벌 네트워크를 따라 이동한다. 클라이언트는 클라이언트 위치, 상태 검사 결과 및 구성된 가중치에 따라 최적의 리전으로 라우팅된다.
클라이언트 상태 – AWS Global Accelerator를 활용하면 필수 요건으로 상태를 저장하는 애플리케이션을 만들 수 있다. 상태 저장 애플리케이션은 초기 연결 후에 동일한 EndPoint로 사용자를 라우팅한다. AWS Global Accelerator는 이를 위해 포트와 프로토콜에 관계없이 클라이언트 요청자의 Source IP 상태 유지를 위한 식별자로 설정한다.
AWS Global Accelerator 구성
- Listener – 프로토콜과 포트를 기반하에, AWS Global Accelerator로 인바운드 연결을 처리하는 Listener를 구성
- EndPoint Group – 어플리케이션이 배포되는 AWS 리전을 정의
- Traffic Dial – EndPoint Group이 수신 할 수있는 트래픽의 비율을 의미
- EndPoint – EndPoint Group에 연결된 EC2-Instance, Elastic IP, Network Load Balancer 또는 Application Load Balancer이다.
- EndPoint Weight – 다수의 EndPoint가 있는 EndPoint Group에서 가중치를 부여하여 분배

1.3 AWS Global Accelerator 작동 방식

그림 1-1 AWS Global Accelerator Diagram

Edge Location에서 알리는 2개의 고정 Anycast IP 주소를 통해, 사용자에게 가장 가까운 Edge Location으로 트래픽이 전송된다.
AWS 글로벌 네트워크를 통해 AWS Global Accelerator로 요청이 라우팅되면, 가장 가까운 정상 상태의 EndPoint Group을 선택하여 서비스 한다.

💡 AWS Global Accelerator의 핵심은 고정 Anycast IP을 제공하여 사용자 입장에서 고정 IP 주소로 접근이 가능하며, AWS 글로벌 네트워크를 경유하여 안정적이고 빠른 서비스가 가능하는 점이다.

2. AWS Global Accelerator Lab Preview

2.1 Lab Topology

그림 2-1 AWS Global Accelerator Lab Topology

시드니, 상파울루 Region에 Web 서버용 EC2-Instance 2대씩 배치
Global Accelerator에서 HTTP 서비스의 인바운드 처리를 위한 Listener를 구성하고, 2개의 Anycast IP를 할당
Global Accelerator에서 시드니, 상파울루 Region에 대한 EndPoint Group을 구분
EndPoint Group의 EndPoint 지정 (시드니 : ALB, 상파울루 : EC2-Instance 2대)
서울, 버지니아 Region에 Client를 통해 생성된 Anycast IP로 Web 접근하여 동작 확인

2.2 AWS 기본 설정

본 실습에서 활용할 AWS Region은 서울, 버지니아북부, 시드니, 상파울루 이다. 해당 Region에 대한 EC2-Key Pair를 생성
서울, 버지니아북부 Region은 클라이언트 영역으로, 실습용 EC2-Instance를 1대씩 구축 (Default VPC 내 EC2-Instance 생성)
시드니, 상파울루 Region은 서비스 영역으로, CloudFormation에 의해 인프라를 자동 구축 (2.3항에서 진행)

2.3 CloudFormation (Infrastructure as Code)

⤵ Download GlobalAccelerator_Lab_CF.yaml

GlobalAccelerator_Lab_CF.yaml Template Code View

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
Parameters:
  KeyName:
    Description: Name of an existing EC2 KeyPair to enable SSH access to the instances. Linked to AWS Parameter
    Type: AWS::EC2::KeyPair::KeyName
    ConstraintDescription: must be the name of an existing EC2 KeyPair.

Mappings:
  AWSRegionArch2AMI:
    ap-southeast-2:
      HVM64: ami-dc361ebf
    sa-east-1:
      HVM64: ami-6dd04501

Conditions:
  CreateSydneyResources: !Equals [ !Ref 'AWS::Region', ap-southeast-2 ]

Resources:
  VPC01:
    Type: AWS::EC2::VPC
    Properties:
     CidrBlock: 10.0.0.0/16
  InternetGateway0101:
    Type: AWS::EC2::InternetGateway
    Properties: {}
  InternetGatewayAttachment0101:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref InternetGateway0101
      VpcId: !Ref VPC01
  PublicRouteTable0101:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC01
  DefaultPublicRoute0101:
    Type: AWS::EC2::Route
    DependsOn: InternetGatewayAttachment0101
    Properties:
      RouteTableId: !Ref PublicRouteTable0101
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway0101
  Subnet0101:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC01
      AvailabilityZone: !Select [ 0, !GetAZs '' ]
      CidrBlock: 10.0.0.0/24
  Subnet0102:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC01
      AvailabilityZone: !Select [ 2, !GetAZs '' ]
      CidrBlock: 10.0.1.0/24
  Subnet0101RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable0101
      SubnetId: !Ref Subnet0101
  Subnet0102RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable0101
      SubnetId: !Ref Subnet0102

  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Enable HTTP access via port 80 and SSH access via port 22
      VpcId: !Ref VPC01
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: '80'
        ToPort: '80'
        CidrIp: 0.0.0.0/0
      - IpProtocol: tcp
        FromPort: '22'
        ToPort: '22'
        CidrIp: 0.0.0.0/0

  EC2Instance1:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: !FindInMap [AWSRegionArch2AMI, !Ref 'AWS::Region', HVM64]
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref Subnet0101
          GroupSet:
          - !Ref WebSecurityGroup
          AssociatePublicIpAddress: true
      UserData:
        Fn::Base64:
          !Sub |
            #!/bin/bash
            yum install httpd -y
            service httpd start
            chkconfig httpd on
            echo "<h1>CloudNeta Web Server_1 [Region= ${AWS::Region}] </h1>" > /var/www/html/index.html
  EC2Instance2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: !FindInMap [AWSRegionArch2AMI, !Ref 'AWS::Region', HVM64]
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref Subnet0102
          GroupSet:
          - !Ref WebSecurityGroup
          AssociatePublicIpAddress: true
      UserData:
        Fn::Base64:
          !Sub |
            #!/bin/bash
            yum install httpd -y
            service httpd start
            chkconfig httpd on
            echo "<h1>CloudNeta Web Server_2 [Region= ${AWS::Region}] </h1>" > /var/www/html/index.html

  ALBTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Condition: CreateSydneyResources
    Properties:
      Name: CloudNetaTG
      Port: 80
      Protocol: HTTP
      VpcId: !Ref VPC01
      Targets:
        - Id: !Ref EC2Instance1
          Port: 80
        - Id: !Ref EC2Instance2
          Port: 80
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Condition: CreateSydneyResources
    Properties:
      Scheme: internet-facing
      SecurityGroups:
        - !Ref WebSecurityGroup
      Subnets:
        - !Ref Subnet0101
        - !Ref Subnet0102
  ALBListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Condition: CreateSydneyResources
    Properties:
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref ALBTargetGroup
      LoadBalancerArn: !Ref ApplicationLoadBalancer
      Port: 80
      Protocol: HTTP

템플릿 파일을 다운받은 후 시드니, 상파울루 Region에서 CloudFormation 스택을 생성한다.
CloudFormation 스택 생성 시 KeyName 파라미터 값을 입력한다. (EC2-Key Pair 생성을 하지 않았다면 생성)
CloudFormation에 의해 생성되는 리소스는 아래와 같으며, 각 Region 별 정상적으로 생성되었는지 확인한다.

시드니 CF 생성 인프라

- Web 서버용 EC2-Instance 2개

- VPC 1개, Subnet 2개, Public Route Table 1개, IGW 1개

- Security Group 1개

- Application Load Balancer, Listener, Target Group 1개씩

상파울루 CF 생성 인프라

- Web 서버용 EC2-Instance 2개

- VPC 1개, Subnet 2개, Public Route Table 1개, IGW 1개

- Security Group 1개

2.4 검증

사용자 PC에서 시드니 ALB DNS 주소로 Web 접근한다. (새로고침을 하여 정상적인 로드밸런싱 확인)
사용자 PC에서 상파울루 EC2-Instance IP 주소로 Web 접근한다. (2대 모두 확인)
참고로 CF에 의해 리소스가 정상적으로 올라오기 까지 약간의 시간이 필요하니 일정 시간 대기가 필요하다.

💡 본격적인 실습에 앞서, Global Accelerator 리소스는 소량의 과금이 불가피 하다. (최초 리소스 생성 시 시간당 약 0.025$)
자세한 사항은 Global Accelerator 요금 링크를 참고 바란다.

3. Create AWS Global Accelerator

3.1 AWS Global Accelerator 생성

[STEP 1] Enter Name

1) Global Accelerator 리소스 접근

Global Accelerator는 오레곤 Region(us-west-2)에서 관리

2) Create Accelerator

3) Enter Name

Accelerator Name: CloudNeta-GA

[STEP 2] Add Listeners

Port Info: 80
Protocol Info: TCP
Client affinity Info: None

[STEP 3] Add EndPoint Groups

Region Info: ap-southeast-2, Traffic Dial Info: 100
- Configure Health Checks
  - Health Check Protocol: HTTP, 나머지 Default
Add EndPoint Group
Region Info: sa-east-1, Traffic Dial Info: 100
- Configure Health Checks
  - Health Check Protocol: HTTP, 나머지 Default

[STEP 4] Add EndPoints

Endpoint group: ap-southeast-2
- Add endpoint
- Endpoint type Info: Application Load Balancer
- Endpoint Info: ALB 대상 지정
- Weight Info: 128

View Screenshot

LabGuide%20AWS%20Global%20Accelerator%2086f3714d71d24b4c940958dfd90b2d52/Untitled%202.png
그림 3-1 시드니 EndPoint Group의 EndPoint 설정 화면 (ALB)

Endpoint group: sa-east-1
- Add endpoint
- Endpoint type Info: EC2 instance
- Endpoint Info: EC2-Instance-1 대상 지정
- Weight Info: 128
- Add endpoint
- Endpoint type Info: EC2 instance
- Endpoint Info: EC2-Instance-2 대상 지정
- Weight Info: 128

View Screenshot

LabGuide%20AWS%20Global%20Accelerator%2086f3714d71d24b4c940958dfd90b2d52/Untitled%203.png
그림 3-2 상파울루 EndPoint Group의 EndPoint 설정 화면 (EC2-Instance)

Create Accelerator

3.2 AWS Global Accelerator 정보 확인

[STEP 1] Accelerator & Listener 정보

그림 3-3 Accelerator 정보와 이에 속한 Listener 정보

Accelerator Provisioning Status는 Deployed 상태로 전환되었다.
Accelerator에 Static한 Anycast IP 2개를 할당 받는다.
TCP 80에 대한 Listener가 생성되었고 All Healthy 한 상태이다.

[STEP 2] EndPoint Group 확인

Listener 를 선택 후 View Details에 접근 한다.

그림 3-4 생성된 Listener 정보와 이에 속한 Endpoint Group 정보

TCP 80에 대한 Listener 정보이다. (Client Affinity는 비활성화 상태)
해당 Listener에 속한 EndPoint Group을 확인한다. (ap-soutcheast-2의 EndPoint Group, sa-east-1의 EndPoint Group)
현재 각 EndPoint Group에 대한 Traffic Dial은 모두 100%이다. (트래픽 수용력 100%)

[STEP 3] EndPoint 확인

그림 3-5 시드니 Endpoint Group 정보와 이에 속한 Endpoint 정보

ap-southeast-2의 EndPoint Group에 대한 EndPoint 정보를 확인한다. (EndPoint Type: ALB)

그림 3-6 상파울루 Endpoint Group 정보와 이에 속한 Endpoint 정보

sa-east-1의 EndPoint Group에 대한 EndPoint 2대의 정보를 확인한다. (EndPoint Type: EC2)

4. Verify AWS Global Accelerator

4.1 Web 접속 부하 Test

Web 접속 테스트는 서울, 버지니아 Region에 생성한 EC2-Instance를 활용한다.

Web 접속 테스트는 리눅스의 curl 명령어를 통해 반복 작업과 지연 시간 체크를 한다.

Traffic management with AWS Global Accelerator | Amazon Web Services

참고링크: Global Accelerator Traffic Management

4.1.1) 서울 EC2-Instance에서 테스트

4.1.1-1) Web 접근 100회 반복 테스트 (Target GA Anycast IP)

View Configuration

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     50 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
     50 <h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
[root@ip-172-31-36-23 ec2-user]#

100회 시험 결과 100% 모두 시드니 (ap-southeast-2)에 위치한 Web 서버로 접근

4.1.1-2) Web 지연 시간 10회 반복 테스트 (Target GA Anycast IP)

View Configuration

for ((i=0;i<10;i++)); do curl -w "%{time_total}\n" 75.2.44.82 ; done ;
<h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
0.298549
<h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
0.300328
<h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
0.299850
<h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
0.298484
<h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
0.299389
<h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
0.299195
<h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
0.299922
<h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
0.300531
<h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
0.299018
<h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
0.300288
[root@ip-172-31-36-23 ec2-user]#

Web 서버 접근 지연 시간을 10회 반복 시 평균 0.3초 가량 소요 (10회 모두 시드니로 향함)

4.1.1-3) Traceroute 경로 확인 (Target 시드니 Region EC2-Instance)

View Configuration

traceroute -I 13.239.18.205
traceroute to 13.239.18.205 (13.239.18.205), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  100.65.11.1 (100.65.11.1)  2.153 ms  9.538 ms  4.807 ms
 7  54.239.122.39 (54.239.122.39)  1.893 ms  1.922 ms  1.848 ms
 8  54.239.122.244 (54.239.122.244)  2.705 ms  2.776 ms  2.790 ms
 9  54.239.122.235 (54.239.122.235)  1.989 ms  1.947 ms  1.949 ms
10  52.93.134.2 (52.93.134.2)  152.098 ms  148.786 ms  148.490 ms
11  54.239.43.246 (54.239.43.246)  148.300 ms  148.447 ms  148.310 ms
12  52.95.37.70 (52.95.37.70)  150.962 ms  149.034 ms  149.132 ms
13  150.222.112.215 (150.222.112.215)  149.895 ms  148.703 ms  148.656 ms
14  150.222.112.216 (150.222.112.216)  149.277 ms  149.290 ms  149.482 ms
15  52.95.37.91 (52.95.37.91)  149.298 ms  148.914 ms  149.624 ms
16  150.222.112.18 (150.222.112.18)  153.129 ms  149.476 ms  148.866 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@ip-172-31-36-23 ec2-user]#

4.1.1-4) Traceroute 경로 확인 (Target GA Anycast IP)

View Configuration

traceroute -I 75.2.44.82
traceroute to 75.2.44.82 (75.2.44.82), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  100.65.8.161 (100.65.8.161)  1.184 ms  0.275 ms  0.261 ms
 7  54.239.122.43 (54.239.122.43)  0.604 ms  0.651 ms  0.630 ms
 8  54.239.122.68 (54.239.122.68)  1.121 ms  1.590 ms  1.117 ms
 9  a848faec6df617b94.awsglobalaccelerator.com (75.2.44.82)  0.268 ms  0.256 ms  0.265 ms
[root@ip-172-31-36-23 ec2-user]#

목적지 Target에 따른 Traceroute 비교 (1-3항 vs 1-4항)

a) Global Accelerator 미사용

b) Global Accelerator 사용

그림 출처: AWS Global Accelerator 개요

서비스를 위해 수많은 네트워크를 거쳐가며, 각 Hop은 성능에 영향을 주며 위험을 초래할 수 있다.

그림 출처: AWS Global Accelerator 개요

AWS Global Accelerator를 추가하면 AWS 글로벌 네트워크를 활용하므로 성능이 개선 및 효율적인 통신을 보장한다.

4.1.2) 버지니아 EC2-Instance에서 테스트

4.1.2-1) Web 접근 100회 반복 테스트 (Target GA Anycast IP)

View Configuration

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     51 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
     49 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-82-0 ec2-user]#

100회 시험 결과 100% 모두 상파울루 (sa-east-1)에 위치한 Web 서버로 접근

4.1.2-2) Web 지연 시간 10회 반복 테스트 (Target GA Anycast IP)

View Configuration

for ((i=0;i<10;i++)); do curl -w "%{time_total}\n" 75.2.44.82 ; done ;
<h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
0.227008
<h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
0.227156
<h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
0.225631
<h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
0.227213
<h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
0.224898
<h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
0.225725
<h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
0.225744
<h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
0.226330
<h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
0.227288
<h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
0.226509
[root@ip-172-31-82-0 ec2-user]#

Web 서버 접근 지연 시간을 10회 반복 시 평균 0.22초 가량 소요 (10회 모두 상파울루로 향함)

4.1.2-3) Traceroute 경로 확인 (Target GA Anycast IP)

View Configuration

traceroute -I 75.2.44.82
traceroute to 75.2.44.82 (75.2.44.82), 30 hops max, 60 byte packets
 1  216.182.238.211 (216.182.238.211)  1.183 ms  1.183 ms  1.181 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  100.65.12.65 (100.65.12.65)  0.323 ms  0.324 ms  0.299 ms
 8  52.93.28.239 (52.93.28.239)  0.530 ms  0.485 ms  0.431 ms
 9  100.100.10.28 (100.100.10.28)  0.595 ms  1.151 ms  1.033 ms
10  100.95.2.131 (100.95.2.131)  20.297 ms  83.331 ms  69.912 ms
11  a848faec6df617b94.awsglobalaccelerator.com (75.2.44.82)  0.432 ms  0.488 ms  0.446 ms
[root@ip-172-31-82-0 ec2-user]#

4.1.3) Web 접속 흐름

그림 4-1 리전 별 User에서 Web 서버로 접근 시 논리적인 흐름

User에서 가장 가까운 Edge Location으로 트래픽이 전송한다. (Target: Anycast IP 사용)
AWS 글로벌 네트워크를 통해 최적의 EndPoint Group으로 전송하여 서비스한다.
예를 들어 한국에서 접근하는 사용자는 인접한 Edge Location으로 Web 접근 요청을 보내고, Edge Location에서 가장 가깝고 Healthy한 EndPoint Group인 시드니 (ap-southeast-2)로 AWS 글로벌 네트워크를 통해 서비스한다.

4.2 Traffic Dial & Weight 조정 Test

Traffic Dial은 EndPoint Group에 대한 트래픽 수용력이며, Weight는 EndPoint 별 트래픽 전송 가중치이다.

4.2.1) Traffic Dial 조정

현재 EndPoint Group의 Traffic Dial은 100%로 설정되어 모든 트래픽을 수용하고 있다.

즉, 서울 —> 시드니 100%, 버지니아 —> 상파울루 100%

4.2.1-1) Traffic Dial: 시드니 50%, 상파울루 100% (서울 에서 테스트)

Accelerator 선택 —> Listener 선택 후 view detail —> endpoint group을 선택 후 edit

그림 4-2 시드니 EndPoint Group의 Traffic Dial을 50%로 조정

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     27 <h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
     27 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
     23 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
     23 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-36-23 ec2-user]#

한국 사용자 기준으로 약 50%정도는 시드니(ap-southeast-2)에서 처리되고 나머지는 상파울루(sa-east-1)에서 처리된다.

4.2.1-2) Traffic Dial: 시드니 0%, 상파울루 100% (서울 에서 테스트)

그림 4-3 시드니 EndPoint Group의 Traffic Dial을 0%로 조정

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     50 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
     50 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-36-23 ec2-user]#

한국 사용자 기준으로 100% 모두 상파울루(sa-east-1)에서 처리된다. (비록 사용자 입장에서 시드니가 인접해 있지만 Traffic Dial이 0% 이기 때문에)
테스트 완료 후 Traffic Dial 값 원상 복구 (100%)

💡 Traffic Dial 0%는 언제 사용할까?
Traffic Dial 0% 설정은 Region 내에서 응용 프로그램을 업그레이드하거나 유지 관리가 필요할때, 먼저 Traffic Dial을 0%으로 설정하여 트래픽을 차단한다. 작업을 완료하고 다시 사용할 준비가 되면, Traffic Dial을 100으로 조정하여 트래픽을 다시 수용한다.

4.2.2) Weight 조정

현재 상파울루 EndPoint Group의 2개의 EndPoint의 Weight 값은 각각 128로 동일한 비중을 설정하고 있다.
Weight에 대한 트래픽 처리 공식은 아래와 같다. (자신의 Weight / 전체 Weight 합)

즉, EndPoint#1 계산값: 128 / (128+128) = 1/2, EndPoint#2 계산값: 128 / (128+128) = 1/2

4.2.2-1) 상파울루 EndPoint#1 Weight: 64, 상파울루 EndPoint#2 Weight: 128 (버지니아 에서 테스트)

그림 4-4 상파울루 EndPoint Group의 EndPoint#1의 Weight 값을 64로 조정

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     67 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
     33 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-95-200 ec2-user]#

계산을 해보면 EP#1 = 64 / (64+128) = 1/3 이고, EP#2 = 128 / (64+128) = 2/3 이다.

4.2.2-2) 상파울루 EndPoint#1 Weight: 0, 상파울루 EndPoint#2 Weight: 128 (버지니아 에서 테스트)

그림 4-5 상파울루 EndPoint Group의 EndPoint#1의 Weight 값을 0으로 조정

1
2
3

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
    100 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
[root@ip-172-31-95-200 ec2-user]#

EP#1의 Weight가 0이므로 트래픽이 전달되지 않고 EP#2로 모두 전달된다.
테스트 완료 후 Weight 값 원상 복구 (128)

💡 Traffic Dial 값을 조정하여 EndPoint Group의 트래픽 처리 비중을 조절할 수 있으며,
Weight 값을 조정하여 EndPoint의 트래픽 처리 비중을 조절할 수 있다.

4.3 Client Affinity Test

AWS Global Accelerator에서 특정 Source IP 주소의 사용자 요청을 동일한 EndPoint 자원으로 보내 접속 선호도를 유지하도록 선택할 수 있다.

Listeners in AWS Global Accelerator

그림 4-6 Listener에서 Client Affinity 설정을 Source IP로 변경

GA에서 생성한 Listener를 Edit하여 Client Affinity를 None에서 Source IP로 수정한다.

즉, Source IP 기준으로 특정 EndPoint 대상으로 지속적인 연결을 보장한다. (마치 Sticky Session)
Test Target은 2개의 EndPoint가 존재하는 상파울루로 향하도록 한다.

4.3.1) 버지니아에서 Web 접속

1
2
3

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
    100 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-95-200 ec2-user]#

상파울루에서 하나의 EndPoint로만 접속이 이루어 진다. (EP#1 - Web Server_1)

4.3.2) 서울에서 Web 접속

서울에서 접속 시 시드니 Web Server로만 접속되므로, Traffic Dial을 0으로 조정하여 상파울루로 향하게 설정한 후 테스트 한다.

그림 4-7 시드니 EndPoint Group의 Traffic Dial을 0%로 조정

1
2
3

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
    100 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
[root@ip-172-31-37-218 ec2-user]#

상파울루에서 하나의 EndPoint로만 접속이 이루어 진다. (EP#2 - Web Server_2)
테스트 완료 후 Traffic Dial과 Client Affinity 값 복구

4.4 Preserve Client IP Test

AWS Global Accelerator의 추가된 기능으로 Client IP 주소를 유지하여 보존하는 기능이다.
EndPoint 별 Client IP 보존 기능
- EC2 : 항상 활성화
- ALB : 선택 가능 (활성화/비활성화)
- EIP, NLB : 항상 비활성화

Preserve Client IP Addresses in AWS Global Accelerator

참고링크 : 클라이언트 IP 보존 관련 문서

4.4.1) EC2 EndPoint 대상 Client IP 보존 (상파울루)

그림 4-8 EC2 EndPoint Type에서 Client IP 보존 상태 (활성화)

EndPoint 타입이 EC2 일 경우 Client IP 보존 기능은 항상 활성화 상태이다.

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     54 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
     46 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
[root@ip-172-31-95-200 ec2-user]#

curl ifconfig.me
54.163.161.100
[root@ip-172-31-95-200 ec2-user]#

버지니아에서 GA Anycast IP 타겟으로 Web 접근 시도 및 자신의 공인 IP 확인

tail -f /var/log/httpd/access_log
:
54.163.161.100 - - [05/May/2020:03:31:23 +0000] "GET / HTTP/1.1" 200 53 "-" "curl/7.61.1"
54.163.161.100 - - [05/May/2020:03:31:24 +0000] "GET / HTTP/1.1" 200 53 "-" "curl/7.61.1"
54.163.161.100 - - [05/May/2020:03:31:24 +0000] "GET / HTTP/1.1" 200 53 "-" "curl/7.61.1"
:
[root@ip-10-0-1-252 ec2-user]#

상파울루 Web 서버에서 HTTP 로그를 확인해 보면 Client IP (버지니아)가 보존되어 그대로 인입되는 것을 확인할 수 있다.

4.4.2) ALB EndPoint 대상 Client IP 보존 (시드니)

EndPoint 타입이 ALB 일 경우 Client IP 보존 기능은 선택할 수 있다. (활성화/비활성화)
ALB Backend에 존재하는 EC2에서 Client IP 주소를 확인하려면 X-Forwarded-For 헤더를 사용하여 캡쳐해야 한다.

ELB 액세스 로그에서 클라이언트 IP 주소 캡처

참고링크 : ELB 엑세스 로그에서 클라이언트 IP 주소 확인

4.4.2.1) Client IP 보존 활성화

그림 4-9 ALB EndPoint Type에서 Client IP 보존 상태 (활성화)

vi /etc/httpd/conf/httpd.conf
:
LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
:
[root@ip-10-0-0-211 ec2-user]# service httpd reload
Reloading httpd:
[root@ip-10-0-0-211 ec2-user]#

시드니 Web 서버에서 /etc/httpd/conf/httpd.conf 파일의 LogFormat 섹션에서 위 내용을 추가 한다. (http 데몬 reload)

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     50 <h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
     50 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
[ec2-user@ip-172-31-37-218 ~]$

curl ifconfig.me
15.164.93.22
[ec2-user@ip-172-31-37-218 ~]$

서울 에서 GA Anycast IP 타겟으로 Web 접근 시도 및 자신의 공인 IP 확인

tail -f /var/log/httpd/access_log
:
15.164.93.22 10.0.1.18 - - [05/May/2020:04:13:05 +0000] "GET / HTTP/1.1" 200 58 "-" "curl/7.61.1"
15.164.93.22 10.0.0.76 - - [05/May/2020:04:13:05 +0000] "GET / HTTP/1.1" 200 58 "-" "curl/7.61.1"
15.164.93.22 10.0.0.76 - - [05/May/2020:04:13:06 +0000] "GET / HTTP/1.1" 200 58 "-" "curl/7.61.1"
:
[root@ip-10-0-0-211 ec2-user]#

시드니 Web 서버에서 HTTP 로그를 확인해 보면 Client IP (서울)가 보존되어 그대로 인입되는 것을 확인할 수 있다.

4.4.2.2) Client IP 보존 비활성화

그림 4-10 ALB EndPoint Type에서 Client IP 보존 설정 변경 (비활성화)

시드니의 ALB EndPoint Type을 Edit하여 Preserve Client IP address 체크를 해제한다. (Client IP 보존 비활성화)
Global Accelerator 가 재시동 되어 약간의 대기가 필요하다.

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     50 <h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
     50 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
[ec2-user@ip-172-31-37-218 ~]$

curl ifconfig.me
15.164.93.22
[ec2-user@ip-172-31-37-218 ~]$

서울 에서 GA Anycast IP 타겟으로 Web 접근 시도 및 자신의 공인 IP 확인

tail -f /var/log/httpd/access_log
:
99.82.168.137 10.0.0.76 - - [05/May/2020:04:24:21 +0000] "GET / HTTP/1.1" 200 58 "-" "curl/7.61.1"
99.82.168.139 10.0.1.18 - - [05/May/2020:04:24:22 +0000] "GET / HTTP/1.1" 200 58 "-" "curl/7.61.1"
99.82.168.137 10.0.0.76 - - [05/May/2020:04:24:23 +0000] "GET / HTTP/1.1" 200 58 "-" "curl/7.61.1"
[root@ip-10-0-0-211 ec2-user]#

시드니 Web 서버에서 HTTP 로그를 확인해 보면 Client IP (서울)가 보존되지 않고, GA에서 사용하는 내부 주소 대역이 Source IP로 들어 온다.

💡 Client IP 보존 기능을 사용하면?
IP 별 필터링을 수월하게 수행할 수 있고, 특정 IP마다 제공 컨텐츠 분류하거나 통계 정보 활용에 유용하다.

4.5 Failover Test

시드니(ap-southeast-2)에 위치하는 Web 서버를 한대 씩 Stop 후 동작을 확인한다.
Client는 서울을 기준으로 한다.

4.5.1) 시드니 Web 서버 1대 Stop

그림 4-11 시드니 Web Server 1대 중지

1
2
3

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
    100 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
[root@ip-172-31-37-218 ec2-user]#

ALB에 의하여 Load Balancing 되는 환경이라 다른 Web 서버가 모두 처리 해 준다.

4.5.2) 시드니 Web 서버 모두 Stop

그림 4-12 시드니 나머지 Web Server 1대 중지 (전체 중지)

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     50 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
     50 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-37-218 ec2-user]#

시드니(ap-southeast-2)의 Web 서버 모든 자원이 Stop 되자 상파울루(sa-east-1)로 경로를 변경하여 모두 처리한다.

4.5.3) Global Accelerator 상태 확인

그림 4-13 Lisener 상태 확인

리스너의 상태를 확인해보면 1 Unhealthy endpoints 상태이다.

그림 4-14 EndPoints Health Check 상태 확인

Unhealthy 상태의 Endpoint를 확인할 수 있다.

4.5.4) 시드니 Web 서버 모두 Start

그림 4-15 시드니 Web Server 모두 활성화

for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     46 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
     44 <h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
      5 <h1>CloudNeta Web Server_2 [Region= sa-east-1] </h1>
      5 <h1>CloudNeta Web Server_1 [Region= sa-east-1] </h1>
[root@ip-172-31-37-218 ec2-user]#
for i in {1..100}; do curl -s -q 75.2.44.82 ; done | sort | uniq -c | sort -nr
     51 <h1>CloudNeta Web Server_2 [Region= ap-southeast-2] </h1>
     49 <h1>CloudNeta Web Server_1 [Region= ap-southeast-2] </h1>
[root@ip-172-31-37-218 ec2-user]#

Health Check에 의하여 시드니 쪽 EndPoint Group이 Healthy 상태로 전환되기 까지 상파울루에서 처리하며, 이 후 시드니에서 모두 처리한다.

그림 4-16 Lisener 상태 확인

All Healthy 상태로 전환

5. Delete Infrastructure

1) AWS Global Accelerator Disable

2) AWS Global Accelerator Delete

AWS Global Accelerator에 대해 Delete 버튼을 누르고, Disable 후 Delete

3) 시드니 CloudFormation Stack Delete

4) 상파울루 CloudFormation Stack Delete

5) 한국 EC2-Instance Shutdown

6) 버지니아 EC2-Instance Shutdown

🔔 CloudFormation 스택을 삭제 시 일정 시간이 소요되는데, 너무 시간이 오래 걸린다면 수동으로 관련 인프라를 삭제해야 한다.
반드시, 실습을 위해 생성한 리소스는 삭제한다.