[社内共有会]AWS NAT-GW導入と構成変化 2年運用して同時接続数秒間100->10万へ成長

AWS NAT-GW導入と構成変化
2年運用して
同時接続数秒間100->10万へ成長

自己紹介
CyberZ F.O.X エンジニア
茂木高宏(もてきたかひろ)
得意技術:
ビッグデータ, AWS, ops系, サーバHW, kernel...
twitter: @tkmoteki / facebook: takahiro.moteki.31
[登壇]FaaSで簡単に実現する数十万RPS
負荷試験 https://goo.gl/ffYVbt
[登壇]Infrastructure as Codeを活用した
F.O.Xのクラウドビッグデータ環境の変化
https://goo.gl/5HTPzY

(2016年) 経緯
● 広域ユースケースをカバー出来る良い制限/認証方法がない
● 連携先からのIP制限希望
連携先
成果通信データ送付
連携先提供のアクセス
連携先セキュ
リティポリシに
依存
● ユースーケース
...IP制限かけることに...
理想な認証: 連携先に追加実装なく認証できること

(2016年) 経緯
Amazon
EC2
Amazon
EC2
バッチ軍団
同一ユースケー
スでスケールア
ウトが可能
連携先連携先
制限必須で
す
制限必須で
はありません
EC2の場合,EC2のElastic IP or (Public IP)でイ
ンターネット外へ
● -> EC2のElastic IP or (Public IP)を連携先
許可が必要
IPIP
IP IP
大量の
連携先

(2016年) 経緯
Amazon
EC2
Amazon
EC2
連携先連携先
制限必須で
す
制限必須で
はありません
IPIP
IP IP
Amazon
EC2
増設したい
バッチサーバ
IP
連携先
に解除申請
連携先連携先
IP
IP
IP
IP
連携先で制限解除出来ないとバッチ増設出来ない
アプリ設計連携先多さ運用的に

(2016年) 経緯
● 制限解除増設可能へ
● バッチサーバ増設が自社起因で不可能な状態に

(2016年) 経緯 NATすることに
連携先連携先
IPIP
NAT NAT
IP IP
IP
IP 連携先
IP
IP 連携先
IP
IP
IP

(2016年) NATの選択肢
Amazon
EC2
IPフォワード
VPC NAT
gateway
パターン
のフォワードを用いて上へクラスタ構築
パターン
上のマネージドサービスを利用
詳細比較 https://goo.gl/ZuiBcy

(2016年) 選択要件
ぶっちゃけラクしたい

(2016年) NATの選択肢
Amazon
EC2
IPフォワード
VPC NAT
gateway
パターン
のフォワードを用いて上へクラスタ構築
パターン
上のマネージドサービスを利用
採用

(2016年~2018年)NAT-GW仕様(1)
項目説明
可用性内部的に冗長化(単一AZレベル)
障害時の動き数秒~数＋秒で内部ノードリプレイス
種類(タイプ/サイズ) 選択出来ない
課金 NAT-GW料金(0.062/時間) + 通信量課金
サポートプロトコル TCP, UDP, ICMP
性能: 帯域 10Gbpsまでバースト
性能: スループット NATトラフィックに最適化
性能制限: 同時接続数同時接続約65000(利用ポートレンジ1024 ~ 65535)
性能制限: タイムアウトアイドル5分以上で自動タイムアウト
セキュリティセキュリティグループ未対応/NACLで制御
メンテンナス AWSによって管理
機能制限 VPN越し接続, VPCピアリング越し接続, ダイレクトコネクト越し接続不可(横断不可)
カスタマイズパラメータ設定不可
その他機能制限ポート転送, 踏み台機能不可
IPv6 未対応(Egress-only internet gatewayを利用) 参考 https://goo.gl/nBVRC5

(2016年~2018年)NAT-GW仕様(2)
● NAT-GWの使い方
● NAT-GWを経由するサブネットにENIを付与し配置するだけ
● ENIを付与し配置
○ 例: EC2, Lambda(VPC内実行)など
○ 意味ないけど、ElasticSearchService,RDS, ELBもENIを持つのでNAT-GWを
経由可
● NAT-GWを経由するサブネットはprivate subnet
○ インターネット上からのpublicアクセス不可(IN)
メリット: 使い方ちょうカンタン
デメリット: 余計な通信でNAT-GWの負荷をかけやすい
重要

(2016年) NAT-GW利用構成
Availability Zone 1a Availability Zone 1c
VPC NAT
gateway
VPC NAT
gateway
route table route table
public
subnet
public
subnet
private
subnet
private
subnet
route table
VPC NAT
gateway
subnet
多多 1
~AWS仕様~
route table
VPC NAT
gateway
subnet
1 1 1
~利用構成~
NAT間通信のsubentのみ1:1:1へ
(シンプル性/route tableの切替え考慮)

(2016年) 事前設計:負荷分散
NAT-GW側でやれること
VPC NAT
gateway
VPC NAT
gateway
public
subnet
public
subnet
private
subnet
private
subnet
Availability Zone 1x
VPC NAT
gateway
route table
public
subnet
private
subnet
このセット
追加
ケース) 高負荷で性能オーバな場合

(2016年) 事前設計:負荷分散
アプリ側でやれること
ケース) 同時接続数を減らす
VPC NAT
gateway
VPC NAT
gateway
public
subnet
public
subnet
private
subnet
private
subnet
バッチ停止可能
な範囲から一部
停止縮退
する必要が
ない通信は別
バッチへ分割

(2016年) 事前設計:切返し
NAT-GW側でやれること
VPC NAT
gateway
VPC NAT
gateway
public
subnet
public
subnet
private
subnet
private
subnet
ケース) NAT-GW側が死んだ場合(内部的に冗長化されてるけど...)
VPC NAT
gateway
VPC NAT
gateway
route table
route table
public
subnet
public
subnet
private
subnet
private
subnet
切返し

(2018年) 2年後
VPC NAT
gateway
VPC NAT
gateway
VPC NAT
gateway
VPC NAT
gateway
同時接続数
100(秒間)
同時接続数
10万(秒間)
通信量約
100倍増加
~2016年~ ~2018年~
※ ある一定の条件あり

(2018年) Q&A 100倍通信量増加して
Q) 秒間10万同時接続数でNAT-GW性能オーバーし負荷分散しま
したか?
A) No (捌けたから特にしてない)
Q) 2年間運用してNAT-GW側に障害ありましたか?
A) No (たぶん、そのはず)
VPC NAT
gateway
← こいつ案外
すげーな...

(2018年) 2020年予測キャパ
2018年2016年
100
(同時接続数/秒)
2020年
10万
30万?
実際の
同時接続数
100倍
2倍と予測
(サービス的に予測可)
(年月
合計NATGW
同時接続数
制限
13万13万 13万

(2018年) 2020年予測キャパ
2018年2016年
100
(同時接続数/秒)
2020年
10万
20万?
実際の
同時接続数
100倍
(年月
合計NATGW
同時接続数
制限
13万13万
30万
性能アラート(自社): warn80%, crit90% -> 予測段階で50~60%理想
2倍と予測
(サービス的に予測可)

(2018年) NAT-GW事前対策1
NAT NAT
NAT NAT
リザーブ
NAT-GWをリザーブした
○ NAT-GW増設に自社起因で可能な状態へ
連携先
IP
IPIP
IP
IP
IP
IP
IP

(2018年)NAT-GW対策2
VPC NAT
gateway
private subnet
● VPCエンドポイントで負荷を逃がす
● NAT-GWを経由するサブネットは、インターネット上への通信がNAT-GWを経由(OUT)
○ SQS, Kinesis(Kinesis Streamエンドポイント付与してないから)
○ 例外: S3(S3エンドポイント付与したから),DynamoDBエンドポイントは進め中
endpoints
Amazon
Kinesis
Amazon
SQS
Amazon
S3
Amazon
DynamoDB

(2018年) NAT-GW対策3
コネクション持続特性でNAT-GW分けた
VPC NAT
gateway
VPC NAT
gateway
ワリとバッチっぽい用途リアルタイム用途
ケース
成果通信
ケース
データ送付外部データ

(2018年) NAT-GW現構成
Availability Zone
1a
Availability Zone
1c
VPC NAT
gateway
VPC NAT
gateway
route
table
route
table
public
subnet
public
subnet
private
subnet
private
subnet
Availability Zone
1a
Availability Zone
1c
VPC NAT
gateway
VPC NAT
gateway
route
table
route
table
public
subnet
public
subnet
private
subnet
private
subnet
NAT NAT
NAT NAT
リザーブ
ケースデータ送付外部データケース成果通信
endpointsendpoints endpoints endpoints

(2018年) NAT-GW運用
● モニタリング
● 障害対応
● ロギング
● 痛い課題

(2018年) NAT-GWモニタリング
CloudWatchメトリクス参考
● NAT-GW CloudWatchメトリクス
● NAT-GWへICMP echo
○ pingやtraceroute, mtrで応答を見る
● NAT-GWのaliveness
○ AWSマネコンから確認可
● VPC Flow logs
最も簡単で
確認しやすい

(2018年) NAT-GW監視
CloudWatchメトリクス参考
NAT-GW CloudWatch監視すべきメトリクス
項目説明対応など
ErrorPortAllocation 送信元ポートを割り当てられなかった件数。性能問題の発見。スライド13,14
ActiveConnectionCount 同時接続数。性能制限の発見(同時接続数) スライド13,14
IdleTimeCount アイドル時間が5分以上になり自動でタイムアウトした件数。
同時接続数内訳のデバックに役立つ。
-
PacketsDropCount NAT-GWでドロップしたパケット数。NAT-GWのdownの発見。スライド15, aws service healthダッ
シュボード確認(or 問合せ)
注意: 連携先(相手先)が死亡 -> IdleTimeCount増加 -> ActiveConnectionCount
増加(最大12万同時接続まで確認済)

(2018年) NAT-GW障害対応
2016年時とほぼ一緒

(2018年) 痛い課題
● 処理データ課金が高い
○ 同時接続数100倍 -> 課金も成長><

その他: stoneプロキシとの使い分け
● NAT-GW / エンドポイント設定したサブネットは強制的通過
○ stone利用: アプリケーション/プロトコルレベル等でNAT-GW / VPCエンドポイントを
経由させない(←構築背景)
○ IP固定化されるので、秘匿通信は不可
VPC NAT gateway
private subnet
(NAT経由する)
endpoints Amazon S3
public subnet
(NAT経由しない)
アプリ1
アプリ1
アプリ1
アプリ1
endpoints Amazon S3
stone

[社内共有会]AWS NAT-GW導入と構成変化 2年運用して同時接続数秒間100->10万へ成長

More Related Content

What's hot (20)

Similar to [社内共有会]AWS NAT-GW導入と構成変化 2年運用して同時接続数秒間100->10万へ成長 (20)

More from Takahiro Moteki (14)