38
Fluentd Fluentd Meetup 2015

Fluentdで本番環境を再現

Embed Size (px)

Citation preview

Page 1: Fluentdで本番環境を再現

Fluentdで本番環境を再現

するFluentd Meetup 2015 夏

Page 2: Fluentdで本番環境を再現

 

Page 3: Fluentdで本番環境を再現

 

Page 4: Fluentdで本番環境を再現

https://iprostm.doorkeeper.jp/events/25664

参加者募集中!Speakerになってもいい人いたら是非連絡ください!@toyama0919

Page 5: Fluentdで本番環境を再現

 

Page 6: Fluentdで本番環境を再現

アジェンダ

Shadow Proxy

fluent-plugin-http_shadow

ユースケース

まとめ

Page 7: Fluentdで本番環境を再現

Shadow Proxy

Page 8: Fluentdで本番環境を再現

Shadow Proxyproductionのhttp requestを複製してバックエンドに送信するproxy

限りなく本番に近い環境をを再現できる

主な用途は負荷試験や結合試験

本番環境を開発環境で再現するアプローチ

Page 9: Fluentdで本番環境を再現

 

Page 10: Fluentdで本番環境を再現

Shadow Proxy何故?WEBのtestが年々複雑化してきている

本番に入れてみたら変なデータが入ってきて落ちたり。。

本番運用したら負荷が大きすぎて落ちたり。。

Page 11: Fluentdで本番環境を再現

導入

するしかない!

Page 12: Fluentdで本番環境を再現

方式を考えた

公開されているOSSを使う

cookpad/kagelestrrat/p5-Geestkentaro/delta

mod_mrubyやngx_mruby

nginx層やapache層の処理をmrubyでscriptingできる

Page 13: Fluentdで本番環境を再現

 

Page 14: Fluentdで本番環境を再現

 

Page 15: Fluentdで本番環境を再現

懸念点があった

ユーザーに密接するフロントエンドにミドルウェアをあまり入れたくない

proxyが挟まることによるユーザーへの影響が不安

もう少し安全にやりたい

要はフロントエンドに手を入れずShadow Proxyやりたい

Page 16: Fluentdで本番環境を再現

Fluentdで出来そうな予感

Page 17: Fluentdで本番環境を再現

fluent-plugin-http_shadow

Page 18: Fluentdで本番環境を再現

fluent-plugin-http_shadowFluentdからhttp requestを復元

フロントエンドに手を入れずにShadow Proxyを実現

ApacheやNginxのログを想定しているが、専用のログでpost等も実現可能

Page 19: Fluentdで本番環境を再現

 

Page 20: Fluentdで本番環境を再現

パラメータrateによる希釈

timeout

並列数

http headerとcookieを指定可能

virtual host

Page 21: Fluentdで本番環境を再現

rateによる希釈本番と同じスペックを揃えられない

同じrequestを送信したらstaging環境が破裂した

最初は1%で運用、徐々に上げてくのが安全

Page 22: Fluentdで本番環境を再現

timeouttimeoutが長すぎるとbufferが詰まる

fluent-plugin-elasticsearchと同じ

短いtimeoutであればclient側でtimeoutするのでbufferが詰まりにくい

Page 23: Fluentdで本番環境を再現

並列数

Apache Benchの用にhttp requestを並列で投げる

Aggregatorが複数あればrequest元を分散できる

あまり一斉にrequestを投げるとサーバー側が破裂する

サーバー数でscaleさせたい場合は各サーバーの並列数を低めに

Page 24: Fluentdで本番環境を再現

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

Page 25: Fluentdで本番環境を再現

<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>

Page 26: Fluentdで本番環境を再現

ユースケース

Page 27: Fluentdで本番環境を再現

主なユースケースバグ発見器

パフォーマンスの比較

Page 28: Fluentdで本番環境を再現

バグ発見器

開発環境でとりあえず流しとけば結構バグが見つかるw

通常テスト時には邪魔になるので、rateを下げる

Page 29: Fluentdで本番環境を再現

昨今のミドルウェア更新頻度

開発が活発なミドルウェアは毎週のようにアップデートが実施される

ライブラリのアップデートの更新頻度も年々上がっている

特にOSSだとその傾向が強い

アップデートしないという選択肢もある

Page 30: Fluentdで本番環境を再現

ミドルウェアアップデート時同じWEBサーバを2つ用意し、片方だけアップデートする

fluentdのcopyでhttp_shadowのmatch directiveを作る

全く同じrequestが送信されることが保証される

newrelicでパフォーマンスを比較

Page 31: Fluentdで本番環境を再現

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

Page 32: Fluentdで本番環境を再現

 

Page 33: Fluentdで本番環境を再現

productionと比較は?productionと同じ構成には費用がかかる

Fluentdのcopyで同一のhttp requestが保証できる

環境間の差分を見る

Page 34: Fluentdで本番環境を再現

まとめと感想

Page 35: Fluentdで本番環境を再現

完全なShadow環境は難しいメールアドレスはMASKされており本番と違う

Postのパラメータはログに出せない

Kageでもgetだけ送信するようなサンプルが提示されてたりする

ブラウザによるアクセスではない

Page 36: Fluentdで本番環境を再現

完全なるShadow環境は危険意図しないデータの更新

Get(参照系)だけでも9割は再現出来る

管理画面とかとは相性が悪い

Page 37: Fluentdで本番環境を再現

まとめ

shadow環境はバグを沢山見つけてくれる

ミドルウェアの更新頻度が多い現代に合っている

Fluentd上ならこういったことがCasualにできる

Page 38: Fluentdで本番環境を再現

ありがとう

ございました