시나리오 배경

연합 API(VPCA)와 API를 사용하는 서비스(VPCB)는 AWS와 다른 VPC에 존재한다.
두 시스템은 Peering으로 설정되어 있으며 통신이 가능합니다.
통합 API의 VPC는 다중 AZ로 구성* (2 AZ)
Peering: 두 VPC 간의 통신은 외부 네트워크가 아니라 L3 네트워크를 통해 VPC 간에 상호 통신할 수 있는 서비스입니다.
다중 AZ 구성: 클라우드 구축, 시스템 가용성 활용을 위한 모범 사례 중 하나

VPC 피어 포인트 기능에 대해서는 여기.를 참조하십시오.

시나리오 개요

서비스 운용 도중 갑자기 협업 API의 3분의 1이 Timout으로 바뀌었다.
VPCA 환경의 접속에는 문제가 없습니다.

원인 조사 준비

VPCB 환경에서 새로운 EC2 인스턴스를 만들고 테스트 환경을 준비합니다.

API 로드 테스트

vegeta ApacheBench를 사용하여 API 서버의 성능에 문제가 있는지 조사합니다.
부하 테스트를 했지만 성능에는 문제가 없었다.

테스트 방법

{API URL}에 10request/sec의 속도로 30초 부하를 지속할 때
vegeta 실행

$ echo "GET {API URL}" | vegeta attack -rate=10 -duration=30s | tee results.bin | vegeta report

vegeta 실행 결과

Requests      [total, rate, throughput]         300, 10.03, 10.03
Duration      [total, attack, wait]             29.908s, 29.9s, 8.468ms
Latencies     [min, mean, 50, 90, 95, 99, max]  2.424ms, 9.616ms, 8.06ms, 15.127ms, 23.502ms, 29.709ms, 88.864ms
Bytes In      [total, mean]                     60000, 200.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:300  
Error Set:

Vegeta 사용법에 대해서 참고해주세요.

ApacheBench 테스트 방법

10명의 사용자가 각각 10회 요청하는 경우
ab 실행

ab -n 100 -c 10 {API URL}

option

n: 生成するリクエスト数を指定します
c: 並列実行する数（コネクション数）を指定します

실행 결과(Sample)

This is ApacheBench, Version 2.3 <$Revision: 1874286 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking xxxxxxxxxx (be patient).....done


Server Software:        nginx/1.15.12
Server Hostname:        xxxxxxxxxxxxx
Server Port:            80

Document Path:          /api
Document Length:        25 bytes

Concurrency Level:      10
Time taken for tests:   0.148 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      15300 bytes
HTML transferred:       2500 bytes
Requests per second:    676.97 [#/sec] (mean)
Time per request:       14.772 [ms] (mean)
Time per request:       1.477 [ms] (mean, across all concurrent requests)
Transfer rate:          101.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   2.3      1      14
Processing:     2   11   7.2      9      31
Waiting:        2   11   7.2      9      30
Total:          3   13   8.4     10      35

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     16
  75%     20
  80%     21
  90%     26
  95%     30
  98%     34
  99%     35
 100%     35 (longest request)

AB 사용법에 대해서 참고해주세요.

통합 API 서버의 커뮤니케이션 테스트

curl을 사용하여 테스트 서버에서 API를 직접 실행하여 소통 확인을 한 후 Timeout이 재현됩니다.
Timeout의 원인을 조사하기 위해curl의 Trace 옵션을 추가하여 진행
curl_trace 실행

$curl -sS {API URL} --trace-ascii trace.log -o /dev/null

DNS 이름이 해결되지 않는 것이 Timeout의 원인이라는 것을 알았습니다.
trace(Trace 도메인 이름, IP 주소 편집)

== Info:   Trying xx.xxx.xx.xx...
== Info: TCP_NODELAY set
== Info: connect to xx.xxx.xx.xx port 80 failed: Connection timed out
== Info:   Trying xx.xxx.xx.x...
== Info: TCP_NODELAY set
== Info: Connected to {API URL} (xx.xxx.xx.x) port 80 (#0)
=> Send header, 169 bytes (0xa9)
0000: GET /api HTTP/1.1
0032: Host: {API URL}
0072: amazonaws.com
0081: User-Agent: curl/7.61.1
009a: Accept: */*
00a7:
<= Recv header, 15 bytes (0xf)
0000: HTTP/1.1 200
<= Recv header, 37 bytes (0x25)
0000: Date: Wed, 02 Sep 2020 06:59:42 GMT
<= Recv header, 32 bytes (0x20)
0000: Content-Type: application/json
<= Recv header, 28 bytes (0x1c)
0000: Transfer-Encoding: chunked
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 23 bytes (0x17)
0000: Server: nginx/1.15.12
<= Recv header, 2 bytes (0x2)
0000:
<= Recv data, 209 bytes (0xd1)
0000: c6
0004: {"result":{""}}]}}
00cc: 0
00cf:
== Info: Connection #0 to host {API URL} left intact
~                                                                                                                                                                                                           
~                                                                                                                                          

컬의 트레이스에 대한 자세한 내용은 여기 참고해주세요.
이후nslokup DSN이 3개로 증가하여 그 중 하나를 연결할 수 없어 Timeout이 된 것을 발견했다.

결론

공동 작업 API 서버의 다중 AZ가 2개로 구성되어 있음을 배경에서 설명하고 싶습니다.
API 서버(VAPCA)의 AZ 구성을 3개로 늘렸지만, 연합API를 사용하는 서버(VAPCB)의 Peering 설정은 여전히 2개의 AZ를 허용하고 새 AZ의 DNS에 연결할 수 없어 오류가 발생할 수 있다.
'VPCB'의 피링 설정에 새로 추가된 AZ 서브넷의 CIDR을 추가해 해결한다.
Amazon API Gateway 협업을 사용하면 위와 같은 설정 변경의 영향을 받지 않습니다.