karahiyoの日記この広告は、90日以上更新していないブログに表示しています。replayを自動化するためのツールです。replayとは、log(httpのトラフィック)をreplay(再生)することで、よりリアルなデータ(プロダクションのトラフィック)をうまいこと使い、より効果時なテスト・確認をしようという考えからなるものです。プロダクションのトラフィックをステージング環境に転送することでステージング環境にデプロイした実装のテストをしたり、転送するトラフィックの割合を制限しつつ負荷テストをしたり、あるいはtcpdumpのようにトラフィックをファイルに書き出し、tcpreplayのようにそれを再生したりと。テストがないコードで、テストの回数が制限されているようなiscon5予選のときに使えたのではとgorが気になってたので試してみたメモです。replayのための機能です。指定したポートでのtcpトラフィックを取得し、そのトラフィックを指定した環境に転送することができます。その転送については、転送するトラフィックの割合を制限したり、フィルタをかけたり、rewriteしたり。転送先にファイルを指定することでtcpdumpのようにトラフィックをファイルに書き出し、入力にトラフィックを書き出したファイルを指定することで、tcpreplayのようにトラフィックを再生することもできます。replayのツールと比較しかなり細かいところまで手が届くものになっているように見えます。現状、Linuxのみ対応。MacOSには対応してませんhttps://github.com/buger/gor#faq自分はgceのcentos7で試してみましたgom使って落としてこようとしたらはまった。あとソースからビルドしてもはまった(きっと自分のびるどの仕方がワルいhttps://github.com/buger/gor/issues/218リリースされているバイナリを使うことで解決https://github.com/buger/gor/releasesrunサンプルのアプリケーションのコードはgistにあげてあります。🐵🙈🙉!他にも、fluetndのout_execみたいな機能がmiddlewareという形であるようです。github.com!感想ローカルでのテストやステージング環境で確認できることと、本番系で確認できることではたしかに得られるものに大きな差があると思います。その差を少しでも小さくするためにgorがつくられたようです。実際にはサービスでは予期していない様々なことが起きます。どれだけ事前にテストをしたとしてもカバーするのは難しく、事は起こるときには起こるものです。できそうなことは例えば、起き得る事を考え、その影響範囲を確認し、必要ならその影響範囲をより少なくするための方法を考え、対応し、そしてリカバリ手順を確認したうえで、えいやと本番系で確認するという方法があります。1リリース1機能の方針など。scalingな構成のサービスでならリリース先のサーバを数台に限定してデプロイするなどの手段もあるかと思います。サービスに直接利益があるわけではないけど安定したサービスのために無視できないそれら心配事が、gorなどを使った仕組みによって意識しなければいけないことが減るのならそれはいい話だなと思いました。»プロフィールid:karahiyo渋谷ではたらくエンジニア見習い。karahiyoはてなブログをはじめよう!karahiyoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。