Upload
hiroshi-toyama
View
233
Download
2
Embed Size (px)
Citation preview
https://iprostm.doorkeeper.jp/events/25664
参加者募集中!Speakerになってもいい人いたら是非連絡ください!@toyama0919
アジェンダ
Shadow Proxy
fluent-plugin-http_shadow
ユースケース
まとめ
Shadow Proxy
Shadow Proxyproductionのhttp requestを複製してバックエンドに送信するproxy
限りなく本番に近い環境をを再現できる
主な用途は負荷試験や結合試験
本番環境を開発環境で再現するアプローチ
Shadow Proxy何故?WEBのtestが年々複雑化してきている
本番に入れてみたら変なデータが入ってきて落ちたり。。
本番運用したら負荷が大きすぎて落ちたり。。
導入
するしかない!
方式を考えた
公開されているOSSを使う
cookpad/kagelestrrat/p5-Geestkentaro/delta
mod_mrubyやngx_mruby
nginx層やapache層の処理をmrubyでscriptingできる
懸念点があった
ユーザーに密接するフロントエンドにミドルウェアをあまり入れたくない
proxyが挟まることによるユーザーへの影響が不安
もう少し安全にやりたい
要はフロントエンドに手を入れずShadow Proxyやりたい
Fluentdで出来そうな予感
fluent-plugin-http_shadow
fluent-plugin-http_shadowFluentdからhttp requestを復元
フロントエンドに手を入れずにShadow Proxyを実現
ApacheやNginxのログを想定しているが、専用のログでpost等も実現可能
パラメータrateによる希釈
timeout
並列数
http headerとcookieを指定可能
virtual host
rateによる希釈本番と同じスペックを揃えられない
同じrequestを送信したらstaging環境が破裂した
最初は1%で運用、徐々に上げてくのが安全
timeouttimeoutが長すぎると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にできる
ありがとう
ございました