Fluentdで
本番環境を再現
するFluentd Meetup 2015 夏
 
 
https://iprostm.doorkeeper.jp
/events/25664
参加者募集中!
Speakerになってもいい人いたら是非連絡ください!
@toyama0919
 
アジェンダ
Shadow Proxy
fluent-plugin-http_shadow
ユースケース
まとめ
Shadow Proxy
Shadow Proxy
productionのhttp requestを複製してバックエンドに送
信するproxy
限りなく本番に近い環境をを再現できる
主な用途は負荷試験や結合試験
本番環境を開発環境で再現するアプローチ
 
Shadow Proxy何故?
WEBのtestが年々複雑化してきている
本番に入れてみたら変なデータが入ってきて落ちた
り。。
本番運用したら負荷が大きすぎて落ちたり。。
導入
するしかない!
方式を考えた
公開されているOSSを使う
cookpad/kage
lestrrat/p5-Geest
kentaro/delta
mod_mrubyやngx_mruby
nginx層やapache層の処理をmrubyでscriptingできる
 
 
懸念点があった
ユーザーに密接するフロントエンドにミドルウェアをあ
まり入れたくない
proxyが挟まることによるユーザーへの影響が不安
もう少し安全にやりたい
要はフロントエンドに手を入れずShadow Proxyやりたい
Fluentdで
出来そうな予感
fluent-plugin-http_shadow
fluent-plugin-http_shadow
Fluentdからhttp requestを復元
フロントエンドに手を入れずにShadow Proxyを実現
ApacheやNginxのログを想定しているが、専用のログで
post等も実現可能
 
パラメータ
rateによる希釈
timeout
並列数
http headerとcookieを指定可能
virtual host
rateによる希釈
本番と同じスペックを揃えられない
同じrequestを送信したらstaging環境が破裂した
最初は1%で運用、徐々に上げてくのが安全
timeout
timeoutが長すぎるとbufferが詰まる
fluent-plugin-elasticsearchと同じ
短いtimeoutであればclient側でtimeoutするのでbuffer
が詰まりにくい
並列数
Apache Benchの用にhttp requestを並列で投げる
Aggregatorが複数あればrequest元を分散できる
あまり一斉にrequestを投げるとサーバー側が破裂する
サーバー数でscaleさせたい場合は各サーバーの並列数を
低めに
注意点config_paramsにhashが使えないversionはダメ
<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>
ユースケース
主なユースケース
バグ発見器
パフォーマンスの比較
バグ発見器
開発環境でとりあえず流しとけば結構バグが見つかるw
通常テスト時には邪魔になるので、rateを下げる
昨今のミドルウェア更新頻度
開発が活発なミドルウェアは毎週のようにアップデート
が実施される
ライブラリのアップデートの更新頻度も年々上がってい
る
特にOSSだとその傾向が強い
アップデートしないという選択肢もある
ミドルウェアアップデート時
同じWEBサーバを2つ用意し、片方だけアップデートす
る
fluentdのcopyでhttp_shadowのmatch directiveを作る
全く同じrequestが送信されることが保証される
newrelicでパフォーマンスを比較
copyで複製<match http_shadow.**>
type copy
<store>
type http_shadow
...
</store>
<store>
type http_shadow
...
</store>
...
</match>
 
productionと比較は?
productionと同じ構成には費用がかかる
Fluentdのcopyで同一のhttp requestが保証できる
環境間の差分を見る
まとめと感想
完全なShadow環境は難しい
メールアドレスはMASKされており本番と違う
Postのパラメータはログに出せない
Kageでもgetだけ送信するようなサンプルが提示されて
たりする
ブラウザによるアクセスではない
完全なるShadow環境は危険
意図しないデータの更新
Get(参照系)だけでも9割は再現出来る
管理画面とかとは相性が悪い
まとめ
shadow環境はバグを沢山見つけてくれる
ミドルウェアの更新頻度が多い現代に合っている
Fluentd上ならこういったことがCasualにできる
ありがとう
ございました

Fluentdで本番環境を再現