Successfully reported this slideshow.
Your SlideShare is downloading. ×

Fluentdで本番環境を再現

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 38 Ad
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Fluentdで本番環境を再現 (20)

Recently uploaded (20)

Advertisement

Fluentdで本番環境を再現

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

×