#.LOG 第２回アドテクノロジーを支える技術 勉強会発表資料(2019.2.21)

1. 【.LOG（ドットログ）】第2回アドテクノロジーを支える技術 #2019.2.21

2. アジェンダ
 自己紹介
 nendインフラの紹介
 トラブル事例の紹介
 まとめ

3.  名前：黄 光川（こう こうせん）@guangchuan_h
 中国の美大卒～水墨画専攻
 2002年、留学をきっかけに来日し
 足を踏み外してIT業界に入り。。。13年！
自己紹介

4.  株式会社ファンコミュニケーションズ
サービス開発部 インフラ1課
 nendというサービスのインフラの面倒を見ています。
自己紹介

5. nendのインフラ
 AWS ＆ オンプレの冗長化 ＋ 2つのCDN
 AWS:
EC2に約1500インスタンス
（ELB, S3, CloudFront, Route53, SQS, ECS, …）
 オンプレミス:
10数ラック, 約1800VM, BIG-IP, Cisco, Juniper, …
 Tools:
・Apache, Nginx, Redis, Memcached, MySQL, Couchbase, Cassandra,
Aerospike, Fluentd, …
・Kubernetes, Docker, KVM, …
・Ansible, Zabbix, Grafana, …

6. 本題
 nendのRTB基盤で
 ある日の深夜3時頃から5xxエラー
 毎時、0分,15分,30分,45分と15分間隔で繰り返す
不思議な現象に遭遇

7. 本題
 nendのRTBで
 ある日の深夜3時頃から5xxエラーが
 0,15,30,45分と15分間隔で繰り返す
不思議現象に遭遇

8. ・nendのRTB
nend
nendの
RTB基盤
DSP a
DSP
nex8
DSP b
AWS Cloud

9. VPC
Availability zone 1 Availability zone 2
MySQLMySQL
Redis
Redis
Aerospike
Cluster
Aerospike
DSP a
DSP b
DSP nex8
DSP a
DSP b
DSP nex8
・nendのRTB
Nginx/AppNginx/App

10. VPC
Availability zone 1 Availability zone 2
MySQLMySQL
Redis
Redis
Aerospike
Cluster
Aerospike
DSP a
DSP b
DSP nex8
DSP a
DSP b
DSP nex8
・nendのRTB
Nginx/AppNginx/App
504

11. ・調査開始
 深夜3時なのでリリースなど変更は行っていない。
→ 外部要因
 取り敢えず、AWSのサポートに問い合わせ
→「HTTPCode_Backend_5XX」なので、
ELB配下のサーバー側を確認してください。

12.  ELBのログから確認すると、特定のwebサーバーではなく、
複数のwebサーバーで万遍なく504になっている。
 Nginxのログを見るとupstream_response_time: 0.200でhttp504を
返している。
・http 504(Gateway timeout)

13. DSP a
DSP b
DSP nex8
504
・http 504(Gateway timeout)
Nginx/App
Log Server
 Nginxがプロキシになっていて、proxy_read_timeout: 200ms
なので200msを超えると504を返す設定。(Open RTBの仕様)
 つまり、アプリ側の処理のどこかで200msを超えている。
Redis, Aerospike, MySQL, 何処かのDSP

14.  各DSPのレスポンスは特に変な感じはしない。
 Redis, Aerospike, MySQLの負荷などは特に問題なし
 NW経路遅延（綺麗に15分毎に変動する障害は考えにくい）
 アプリが15分毎に変な動きをするとも考えにくい
 うむ～～～～～～。詰んだ！
・http 504(Gateway timeout)

15. ・詰んだ時の必殺技 = 様子見
 取り敢えず様子見にしよう。
 一時的なものかも、自然に治るでしょう。
 数値的にも0.000666%ぐらいだし。。。
（100万リクエスト/分、1万5XX/15分毎）
 で、数日様子見しましたが、まったく改善しない。。。

16. ・TCP dumpしてみる

17. ・TCP dumpしてみる
Nginx appELB
http POST
http POST
ACK
200ms経過
FIN, ACK
ACK
http 204
http 504
14:30:10.848832000
14:30:10.885514000
14:30:10.848891000
14:30:11.049256000
14:30:11.085513000
14:30:11.322856000
480ms経過

18. ・TCP dumpしてみる
Nginx appELB
http POST
http POST
ACK
200ms
FIN, ACK
ACK
http 204
http 504
14:30:10.885514000
14:30:10.848891000
14:30:11.049256000
14:30:11.085513000
14:30:11.322856000
POSTから480ms
MySQL
Query(select 1)
14:30:10.849713000
Response
14:30:10.964732000
120ms
Query(SET autocommit=1)
14:30:10.964847000
Response14:30:11.155864000
Query(select xxx)
14:30:11.155988000
190ms
Response
14:30:11.317132000
160ms

19. VPC
Availability zone 1 Availability zone 2
MySQLMySQL
Redis
Redis
Aerospike
Cluster
Aerospike
DSP a
DSP b
DSP n
DSP a
DSP b
DSP n
・nendのRTB
Nginx/AppNginx/App

20. ・ELBとクロスゾーン負荷分散
Nginx/App
Availability zone 1
Nginx/App
Availability zone 2
Client
 一つの名前のELBで複数Azのipを返す。（DNSラウンドロビン）
 クロスゾーン負荷分散設定が有効な場合、複数のAzのインスタンス
にラウンドロビンルーティングする。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

21. ・nendのRTBの場合

22. Nginx/App
Availability zone 1
Nginx/App
Availability zone 2
・nendのRTBの場合 Client
MySQLMySQL

23. ・ELBのクロスゾーン負荷分散設定を無効に

24. ・ELBのクロスゾーン負荷分散設定は便利だが
RTB等の高いレスポンスを求めるシステム
には向いていない。
・AWSのAz間は物理的に距離が離れていて、
Az超えにコストがかかる場合がある。
・ブラックボックスのトラブル調査は難しい。
（謎：15分毎の変化は何だったのか？）
・まとめ

25. ・トラブルはまだまだ多くあります。
→助けてください。
・楽しめる環境があります。
→サーバー数千台、数十億imp/dayが待っています。
・働きやすい環境があります。
→裁量労働、リモート勤務、電動昇降机、集中作業スペース、
27インチDisplay x 2 などなど。
・最後に少しだけRTB(広告)させてください。

26. Infra Engineer
Web Application
Engineer
Data Scientist
@fantechPR

27. ご清聴ありがとうございました。