이 문서는 DMM.com #2 Advent Calendar 2017 - Qiita의 9 일째입니다.

캘린더는 이쪽
DMM.com #1 Advent Calendar 2017 - Qiita
DMM.com #2 Advent Calendar 2017 - Qiita

소개

안녕하세요, @funa1g 이라고 합니다.
사내에서 공통으로 이용되는 API등의 개발을 하고 있습니다.
기술 선정을 위해 AWS에 대해서도 여러가지 시도하고 있습니다.
이번에는 그 안에서 AWS Lambda와 VPC를 연결한 안티패턴에 대해서입니다.

전체 구성

API Gateway + Lambda에서 API를 만들 때 RDS에 액세스하고 싶을 수 있습니다.
게다가 RDS가 되면 역시 VPC내에 두고 싶습니다.
이 조합이 안티 패턴인 것은, 이미 여러 가지 검증 기사가 나와 있습니다만,
다소 늦어도 움직이면 용서할 수 있을까라고 생각해, 검증해 보았습니다.

전체 구성입니다.

동작 테스트

혼잡하게 움직이면 좋기 때문에 이런 엔드 포인트로 만들었습니다.
응답은 DB의 데이터

METHOD: GET
URL:/LambdaTest
Response

[
  {
    "id": 1,
    "name": "test1"
  },
  {
    "id": 2,
    "name": "test2"
  }
]

Lambda 측 코드도 DB에 액세스하고 JSON을 반환합니다.

const { Client } = require('pg');

exports.handler = (event, context, callback) => {
    // 接続先のPostgresサーバ情報
    const client = new Client()

    client.connect()
    client.query("SELECT * FROM test", (err, res) => {
        if (err) throw err
        client.end()
        callback(null, res.rows)
    })
};

부하 테스트에는 Gatling을 사용했습니다.
사용한 코드는 다음과 같습니다.

constantTest.scala

  setUp(
    scn.inject(
      // 50人のアクセスを40秒間継続
      constantUsersPerSec(50) during(40 seconds)
    )
  ).protocols(httpConfig)

이제 테스트 준비가 완료되었습니다.
그리고는 실행 결과를 기다리는 것뿐입니다.

테스트 결과

위 설정에서 테스트한 결과는 다음과 같습니다.

---- Global Information --------------------------------------------------------
> request count                                       2000 (OK=1839   KO=161   )
> min response time                                      0 (OK=144    KO=0     )
> max response time                                  57613 (OK=57613  KO=0     )
> mean response time                                   471 (OK=512    KO=0     )
> std deviation                                       2902 (OK=3023   KO=0     )
> response time 50th percentile                        259 (OK=262    KO=0     )
> response time 75th percentile                        279 (OK=281    KO=0     )
> response time 95th percentile                        454 (OK=479    KO=0     )
> response time 99th percentile                       1304 (OK=1410   KO=0     )
> mean requests/sec                                     20 (OK=18.39  KO=1.61  )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms                                          1802 ( 90%)
> 800 ms < t < 1200 ms                                   1 (  0%)
> t > 1200 ms                                           36 (  2%)
> failed                                               161 (  8%)
---- Errors --------------------------------------------------------------------
> j.u.c.TimeoutException: Request timeout to not-connected after    161 (100.0%)
 60000 ms
================================================================================

몇 가지 문제가 있습니다.

상당히 느린 응답이 부분적으로 발생했습니다

시간 초과 발생

여러 번 시도했지만 1700 전후의 시나리오를 실행한 결과 처리가 불가능했습니다.
실행측의 문제인지, AWS측의 문제인지까지 확인할 수 없다.
거기의 검증을 계속하고 있었습니다만, 모르는 채, 날짜가 바뀔 것 같기 때문에(12/9 22:00), 일단의 결과를 방류입니다.
외로운 결과가 되었습니다만, 검증이라고 이런 일도 있네요.
계속 조사는 계속하고, 알고 있으면 추기하고 싶습니다.

2개월 정도 전에 시도했을 때는 300명의 사용자 액세스를 60초 정도 하는 것으로 API Gateway와 VPC간의 ENI를 한계(300)까지 도달시킬 수 있었습니다만, 거기까지 도달하지 못했습니다. 했다.
htp // // cs. 아 ws. 아마존. 이 m/그럼 _jp/ぁmb다/ㅁ해서 st/dg/vpc. HTML
실제로 그렇게 되면 이 기사의 맨 아래와 같은 현상이 발생합니다.
ENI를 더 이상 만들 수 없기 때문에 Lambda를 시작할 수 없으며 그만큼 실패합니다.
게다가 CloudWatch에 로그가 나오지 않기 때문에 상당히 엄격합니다.
역시 안티 패턴은 안티 패턴이군요.

마지막으로

그런데, AWS측으로부터 안티패턴이라고 하는 것이 되어, 그 나름의 이유가 있는 것을 알았습니다.
앞으로도 이 방법은 취할 수 없는가 하면, 아직 모르겠는가라고 생각하고 있습니다.

요 전날 re:Invent에서 API Gateway VPC integration이 발표되었습니다.
이것은 API Gateway에서 VPC 리소스에 액세스하는 수단을 제공합니다.
아키텍처 문제로 인해 Lambda에는 명시적인 엔드포인트가 없으므로 현재 액세스할 수 없습니다.
그러나, VPC에의 액세스 수단이 준비되었다고 하는 것으로, 전개에 희망이 없을까라고 생각하고 있습니다.
앞으로의 발표가 기대되는 곳입니다.