Fluentd Meetup 2015 夏 で発表した資料です。

1. Fluentdで
本番環境を再現
するFluentd Meetup 2015 夏

4. https://iprostm.doorkeeper.jp
/events/25664
参加者募集中！
Speakerになってもいい人いたら是非連絡ください!
@toyama0919

6. アジェンダ
Shadow Proxy
fluent-plugin-http_shadow
ユースケース
まとめ

7. Shadow Proxy

8. Shadow Proxy
productionのhttp requestを複製してバックエンドに送
信するproxy
限りなく本番に近い環境をを再現できる
主な用途は負荷試験や結合試験
本番環境を開発環境で再現するアプローチ

10. Shadow Proxy何故？
WEBのtestが年々複雑化してきている
本番に入れてみたら変なデータが入ってきて落ちた
り。。
本番運用したら負荷が大きすぎて落ちたり。。

11. 導入
するしかない!

12. 方式を考えた
公開されているOSSを使う
cookpad/kage
lestrrat/p5-Geest
kentaro/delta
mod_mrubyやngx_mruby
nginx層やapache層の処理をmrubyでscriptingできる

15. 懸念点があった
ユーザーに密接するフロントエンドにミドルウェアをあ
まり入れたくない
proxyが挟まることによるユーザーへの影響が不安
もう少し安全にやりたい
要はフロントエンドに手を入れずShadow Proxyやりたい

16. Fluentdで
出来そうな予感

17. fluent-plugin-http_shadow

18. fluent-plugin-http_shadow
Fluentdからhttp requestを復元
フロントエンドに手を入れずにShadow Proxyを実現
ApacheやNginxのログを想定しているが、専用のログで
post等も実現可能

20. パラメータ
rateによる希釈
timeout
並列数
http headerとcookieを指定可能
virtual host

21. rateによる希釈
本番と同じスペックを揃えられない
同じrequestを送信したらstaging環境が破裂した
最初は1%で運用、徐々に上げてくのが安全

22. timeout
timeoutが長すぎるとbufferが詰まる
fluent-plugin-elasticsearchと同じ
短いtimeoutであればclient側でtimeoutするのでbuffer
が詰まりにくい

23. 並列数
Apache Benchの用にhttp requestを並列で投げる
Aggregatorが複数あればrequest元を分散できる
あまり一斉にrequestを投げるとサーバー側が破裂する
サーバー数でscaleさせたい場合は各サーバーの並列数を
低めに

24. 注意点config_paramsにhashが使えないversionはダメ

25. <match http_shadow.example>
type http_shadow
host_hash {
"www.example.com": "staging.example.com",
}
host_key host
path_format ${path}
method_key method
header_hash {
"Referer": "${referer}",
"User-Agent": "${user_agent}"
}
max_concurrency 10
flush_interval 10
timeout 10
rate 10
</match>

26. ユースケース

27. 主なユースケース
バグ発見器
パフォーマンスの比較

28. バグ発見器
開発環境でとりあえず流しとけば結構バグが見つかるｗ
通常テスト時には邪魔になるので、rateを下げる

29. 昨今のミドルウェア更新頻度
開発が活発なミドルウェアは毎週のようにアップデート
が実施される
ライブラリのアップデートの更新頻度も年々上がってい
る
特にOSSだとその傾向が強い
アップデートしないという選択肢もある

30. ミドルウェアアップデート時
同じWEBサーバを2つ用意し、片方だけアップデートす
る
fluentdのcopyでhttp_shadowのmatch directiveを作る
全く同じrequestが送信されることが保証される
newrelicでパフォーマンスを比較

31. copyで複製<match http_shadow.**>
type copy
<store>
type http_shadow
...
</store>
<store>
type http_shadow
...
</store>
...
</match>

33. productionと比較は？
productionと同じ構成には費用がかかる
Fluentdのcopyで同一のhttp requestが保証できる
環境間の差分を見る

34. まとめと感想

35. 完全なShadow環境は難しい
メールアドレスはMASKされており本番と違う
Postのパラメータはログに出せない
Kageでもgetだけ送信するようなサンプルが提示されて
たりする
ブラウザによるアクセスではない

36. 完全なるShadow環境は危険
意図しないデータの更新
Get(参照系)だけでも９割は再現出来る
管理画面とかとは相性が悪い

37. まとめ
shadow環境はバグを沢山見つけてくれる
ミドルウェアの更新頻度が多い現代に合っている
Fluentd上ならこういったことがCasualにできる

38. ありがとう
ございました