社内勉強会でキャッシュサーバのVarnishのベンチマークをレポートした
久しぶりに毎週金曜日にやっている社内の勉強会で話す機会を得たので発表した内容を残しておく
発表資料
ざっくり感想
- memcachedとvarnishの単純なキャッシュ性能を計測した。恐らくvarnishのが良いんだろうなーと思ってたけどその通りの結果になった😅
- Benchmarkの数値を集計して評価するのに色々と設定が面倒で今回はレイテンシーのみを Vegeta(https://github.com/tsenart/vegeta)見てた😃
- けどmackerelのagentとか入れとけば自前でzabbixやmuninのようなものを用意しなくても基本的なLA,CPU,Memory等の数値はみれるし、pluginもあってこれ使えばokなのに気づいた😂
- これからも定期的に発表していこうと思います💪🏽
弁護士ドットコム×みんなのウェディング ライフイベントメディアの成長を支える技術勉強会に参加してきた
久しぶりに勉強会に参加させてもらったのでまとめておく
勉強会概要
Time Table
みんなのウェディング 「爆速開発のために独自フレームワークからRails に移行した話」 @松久 浩伸
- 今まではMobaSifを利用
- perl5.8 / mysql5 / FastCGI という割と昔のものという印象
- 文字コードにShiftJISやEUCとか出てくるあたりはガラケー時代を思い出す
- Prototype.jsも時代を感じる
- リリースまでは4ヶ月ほど要している
- リバースプロキシを導入して新しいFW、古いFWでレスポンスを返す等完全切り替えでなく、移行期間を設けている
感想とか
- Rails、ActiveRecordの命名ルールとか既存のDBのschema設定に依存してしまい、どう対応していったのかと気になってた
- 結果的にはこのあたりは別扱いというかまずはRailsに乗り換える事を優先していったという感じ
- ActiveRecordをもっとフル活用できるとより爆速開発につながるんだろなーと勝手に思った
- リバースプロキシで移行期間を設けてというのは良いと思うが、この移行期間はダブル運用になるので運用コストも見逃せないと思う。最短で切り替えていく計画が必要だろうと感じた。（おそらくやられているかと思いますが）
- 場合によってはアクセスがスパイクした時とか、裏側で２つのシステムをみて対応していかないといけないし...
弁護士ドットコム 「CloudSignでのGo言語でのサービス開発」@和田 浩一
- サーバ側の実装はGo,Revel
- もともとはPHPで実装されていた
- なぜ、Goを採用したのか
- 開発するサービスが独立している分自由度があったので新しい言語、FWを採用しやすかった
- サービスの特性上、堅牢性が重要でその観点からも静的型付言語でコンパイル時に初歩的なエラーを発見できるのは良かったと
みんなのウェディングのデータ分析基盤の作り方 @小室 直
www.slideshare.net
解決は
- 巨人の肩にのる!!
10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)
- 作者: 青木峰郎
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/30
- メディア: 単行本
- この商品を含むブログ (6件) を見る
- redshift,bricolage,kuroko2
- fluent ,embulk,kinesis
分析には
- re:dashも使ってる
- dmemo(DBのドキュメント化ツール)
感想とか
- 布教活動は重要だなと同じく感じた
- 全てエンジニアのバックボーンがあるならそこまで要らないかもしれないけど
- 技術のわからない人向けにデータ分析関連(SQLとか)を覚えて活用すると自分の目標にどう活かしていくことができるかをセットで教えられるとより身につくだろうなと思った
弁護士ドットコム 「Yahoo砲にも耐えるインフラ設計」@薄井 敏臣
おこなった対策
- htmlをキャッシュしてCloudfrontでレスポンス
- けどダメだった
- AWSのauto scaling
- けどダメだった(ELBのスケールアップやオートスケールは間に合わない)
最終的には
- varnishを前方に配置
- Cloudfrontから切り替え
感想とか
- うちも今同じようにキャッシュでhtmlをレスポンスしている仕組みがある。Varnishの性能とベンチマークしてみたいなーと思った
- 自分も取り急ぎの基準値としてGoogle Analyticsのリアルタイムセッション数は参考にするけど、正しくは秒間のリクエスト数になるのでそのあたりをスパイクしている時に瞬時に把握できる仕組みが必要だなと思った
- AWS側のスケール対応が間に合わないって話はちょこちょこ聞くなぁ〜
みんなのウェディング 「サービスを支える監視運用の工夫」@坪井 昭憲
www.slideshare.net
以前は
- Munin,Zabbix,Nagios
現在は
- zabbix,cloudwatch,twillo
感想とか
- AWSのEC2インスタンス追加時に自動でzabbixの開始対象へする設定は確かに良い(zabbixの監視テンプレートも自動で割り当て)
- 最近は監視内容、項目のバージョン管理していく流れ(code化される)があると思っていてそのあたりの考えとかザックばらんに話聞ければが良かったけど時間が無くて残念
- AWS Configとか検証してたりしないかなーと思ったけど
弁護士ドットコム 「スケールする会社を支える開発組織のマネジメント」@市橋 立
- カウボーイスタイル開発
- スタイルなし
- テストサーバ１台でみんで開発。かなりの初期感がある
結局スケール対応するマネージメントとは
- ライフサイクル
- ステージ別に考えて重点をどこにおいて対応していくかを考える
重要なのは下記
- 問題の見極め
- アンテナを張る
- ノイズなのかシグナルなのか
- 3回ルール（3回同じ事が起きたらノイズではなくシグナル）
- 引き出しを増やす
- 他の事例を参考にインプット
みんなのウェディング 「職種を超えたスキル育成でキャリアをつくる」@中村 修治
www.slideshare.net
自分で勝ってに学べよは基本としてあるけどそれだけではダメでチームとして行うこと自分にもメリットは返ってくる。例えば下記
- 他の職種の人との共有言語ができる
- 組織として学びの文化形成（環境変化への対応）
- チャレンジングな部署移動を積極的にできる
組織、社会、自身が変わっても十分に力を発揮するようにするために少しづつ着実に自分のできることを増やす事が大切!!
この方の歩んできた経歴がとても面白くて一度フランクに話聞きたいなーと思った!!
頻繁にdeployしながらCDN(CloudFront)化のキャッシュclear,lifecycleの付き合い方
静的コンテンツ(CSS,Image,JS)をCDNから配信するとサイトの表示スピードが格段にあがるよってゆう話はかなり今更感ですが、それは前提として1日何回もデプロイを繰り返すサービスを考慮するとCDNのキャッシュとライフサイクルにどううまく付き合うかが結構課題になってきたりします。
そんな課題にどうやって対処したかをまとめておこうと思います
全体説明
- 静的コンテンツ(CSS,Image,JS)はすべてS3に格納
- S3を通常のバケットとして設定
- 以前は直接S3のURLを参照してコンテンツを配信していたが、パフォーマンス的にNGなので今はCloudFrontから配信している
- 静的コンテンツ以外はELBにアプリケーションサーバ群が存在、その先にDB等がある。storage系は今回省略
抱えていた・想定された課題
- CDN(CloudFront)からコンテンツを配信した場合、キャッシュの更新が全世界のエッジロケーションに行き渡るまで最大20分程度かかってしまう
- 即時反映させないとサービス運用上厳しい時があって困った 😩
- 静的ファイルのrevision管理(ハッシュプレフィックス)を行ってもリリースのたびに過去のゴミファイルが増えて続けてしまう
- S3のアクセスログからアクセスが無くなったタイミングでdeleteする運用すれば良いかもしれんが面倒すぎる 😰
- 通常のリリース中に表示の不具合等が起こってた
- リリースは①〜③で順にELBからサービスアウト、ソースの更新、サービスイン。④で静的コンテンツ(S3)に世代管理もしていなく、アクセスを受けているディレクトリにゴリっとデータをSync
- リリース時間中は新旧のソースが入り混じる状態でアクセスを受けてレスポンスしている為に表示の不具合が発生....なんどもデプロイすると問題が表面化してくる😱
- 詳細
- ソースがまだ古い旧アプリサーバがレスポンスを返す時は旧versionのhtmlを
- ソースが更新された新アプリサーバがレスポンスを返す時は新versionのhtmlを
- 静的コンテンツはあるタイミングでゴリっと変わる
- 2のhtmlでSync前の静的コンテンツを呼び出してレンダリングした場合、表示が壊れる... 😰
- BlueGreenDeployment的な思考が必要...だ
取り組んだ内容
- S3に配置するファイルをリリースをする度に世代管理した。リリースをする度に
yyyyより下層ディレクトリが増えていく- 時間軸を世代管理に利用したのはCDNのキャッシュを考慮した為
- 毎度新しいstatic fileのpathにする事で一回目のアクセスで必ずoriginサーバからキャッシュにのり、最新のデータが配信できる
- AWS S3のライフサイクル設定(ルールターゲット)で引っ掛けて不要ファイルがdeleteしやすい
- 何度もデプロイを繰り返す上で数日前のversionのstatic fileとかはもはやゴミ
- 時間軸を世代管理に利用したのはCDNのキャッシュを考慮した為
└── bucket_name
└── revision
└── yyyy
└── mm
└── dd
└── His
├── css
├── image
└── js
* yyyyはリリースをした年
* mmはリリースをした月
* ddはリリースをした日
* Hisはリリースをした時間(secまで)
- リリーススクリプトからリリース時にアプリケージョンサーバが参照する静的コンテンツを指定できるようにした。課題3のクリア😀
- Shell職人気味だけど
- アプリケーションは必ず上記で指定された静的コンテンツを参照するようにした
- リリース時間中でもアプリケーションと静的コンテンツのversionがずれる事なく参照できるようなったので表示不具合は無くなった😬
- これで1日なんども安心してデプロイできるようになった😆
- リリースの度に新しく世代管理された静的コンテンツを参照する為、必ず新しいURL参照になるのでCDNのキャッシュクリアを気にする事なく即時反映を実現できた。課題1のクリア🙂
- ライフサイクル設定でリリース日から前月のコンテンツをdeleteした
docs.aws.amazon.com
- 無駄なゴミファイルを削除が実現できた。一ヶ月前のリリースのバージョンの静的ファイルは確実に要らないと断言できたので。課題2のクリア😀
ついでに改善した点
- キャッシュの有効時間設定をheaderオプションを使って設定した
docs.aws.amazon.com
- CloudFrontの管理画面でも設定できるけどユーザのブラウザキャッシュも有効に活用したいのでheaderオプションを活用
最後
- AWSのライフサイクル設定はもっと早いサイクルでも全く問題ないと思った
- S3自体でもバージョニング機能が存在するけど結論、オペミスによるファイルの復活させるレベルの使い方になると理解した docs.aws.amazon.com
- これで安心して何度もデプロイしてリリースするまでの改善スピードをあげていける
- 今回はgitにcommitしてあるCSS,Image,JSが対象とした話
- Imageだとユーザがアップロードするものもある。更新されるタイミングが異なるので今回とはまた別の話
- 各static fileの名前をハッシュプレフィックスをつけておくとS3上のI/Oが良くなってリリース時間が短縮できるっぽい docs.aws.amazon.com
PM Meetup #2 に参加させてもらった時のメモ
自分はPMではないけど、PMとはという事を色々と考える機会があり且つ運良く抽選にあたったので今回参加させてもらいました。
その時のメモ的なものです。
勉強会概要
Time Table
PM Talk by takoratta
IncrementsのPMの役割を私から説明（終わった）。 #incrementsmeetup pic.twitter.com/l5KO3xLcIj
— 及川卓也 / Takuya Oikawa (@takoratta) 2016年10月4日
- IncrementsにおけるPMのお話
- 理想的に言うと多種多様(QAやPR、legalなどの)な職種が必要だけど現実はPM,ENG,デザイナーしかいない
- PM,ENG,デザイナーはすべて対等な立場である
- 最終決定はチーム内の合意を取りながらPMが進めていく
- What,When,WhyをつくるのがPMの仕事であり、そこでPRDを用いる
- ENGはHowの部分を担う。Githubでコンテキストに残しながら議論をして技術選定をしていく
- デザイナーはフロントエンドエンジニア部分も担う。またPMと一緒にWhatの部分も担っていく
- 自明の事でも文字にして残すことで自分には当たり前のことが他者は違う解釈がわかる時がある
- あえて文字起こしすることの重要性。自分の考えもクリアになる
- PMはMTGで合意を取ることがメインの仕事となるのでリモートワークにおいては一番工夫をする必要がある
- 非同期コミニュケーションでいいのか？同期コミュニケーションがよいのか？
- QAの役割をどの役職が担うかが議論中
PM Talk by yaotti
- 絵文字リアクション機能を例にPRDの話
- Qiita:Team のPM
- プロダクトのコンセプト、主要ストーリの設定やブラッシュアップ
- issueの立ち上げ、進行サポート
- ユーザーヒアリングやアンケート
- プロダクトチームマネジメント
- 1on1
- マイクロマネジメントはせずに自律的に動きやすい環境をつくりをする
- よりやり方を求めて改善し続ける
- 使っているtool
- qiita:team
- zenhub
- slack
- google spreadsheet,Re:dash
- trello,mural
- リモートワークで一番工夫する必要があるのはPM
- ビデオ・テキスト
- 同期的・非同期
- 人の集中時間を無駄に奪ってはいけないのでうまく使い分ける
質疑応答 + フリーディスカッション
メンバーのモチベーション維持にはどうしているか？
- 毎日スタンドアップMTGしている
- 昼会、夕会で課題洗い出しで解決していく
- 1on1で吸い上げる
- 物怖じしないでどんどん発言するエンジニア文化が良い気がする
Trello,Zenhub使い分けは？
- 採用系、バックオフィス系でTrelloを使ってる
- 開発系はZenhubで完結
プロジェクトマネジメント・プロジェクトマネージメントの違いや捉え方にかんして
- あまり区別なく、取り組んでいる
- 小さいチームにはスクラムとか教科書どおりにいかない
- ユーザに愛されるサービス開発からブラさないのでいつまでに出すといったスケジュールのプレッシャーは少ない
PMソースコードはどの程度把握しているか？
- 小さい修正はcommitしている by yaotti
- ほぼわからない。というかrubyあまりわからないw by takoratta
PRDに経営判断がどの程度入れているのか？
- qiitaはもともとマネタイズしてなかったので最初は考えていなかったが、健全な成長を促す為に広告を貼りやすいといった要件はある
- ユーザの使い勝手とセットでなければ、経営的な判断は入れない。あくまでユーザに愛されることから軸足ををずらさない
感想等
- エンジニアの為の情報共有のプロダクトなので、作るのもエンジニア、使うのもエンジニアという形なので方向性が割とまとまりやすい気がした
- 完全リモートワークの中でのPMの立ち回りはより重要だと思った
- 自明の事でもしっかりテキストに残して共有する事の重要性を改めて感じました
- ついつい忙しいとスキップしてしまいがちな自分を反省しました
- あとで振り返った時にチームのノウハウ？学習を積み上げていく作業である
- チーム全員がよりよりプロダクト作りに集中していて楽しそうに見えた
- PMって偉い？立場の人ってなりそうだけど、全員が対等な立場であって正しい発言・行動をした人が正しい（偉い）文化
- お二方の話っぷりや姿勢を見ていると納得できた
- マイクロマネジメントはしない。賛成!! 信頼で成り立たせる
- お疲れ様でした
過去の参考記事
社内勉強会で"HTTP/2"をざっくり理解した
毎週金曜の30分の勉強会がある。クオリティは自由でまぁテックトークをする場である。今回は自分が立候補して発表してテックトークしてきた。 その時に使った資料をupする
発表資料
関連情報
QUIC, a multiplexed stream transport over UDP - The Chromium Projects
http://www.rfc-editor.org/rfc/rfc7540.txt
HTTP/2 and SPDY indicator - Chrome ウェブストア
感想とか
結局のところアプリケーション開発者はスクリプトのコーディングレベルでは何も気にすることはない。ブラウザは半自動的にupdateされるし、wwwサーバも運用とともにversionを上げていくのでゆるやかーにHTTP/2が普及していくのだろうなと思った。
次世代的な立ち位置のquicはすでにchromeでgoogleのサービスを使う際には既に使われてた。当たり前か
通信環境の弱いユーザに一番メリットをもたらすんではないかと思われる
HTTP/2 でNginxとH2Oのベンチマークとったらどうなんだろうかと思っている
Github Universe 2016 で感じた事とか
Github Universe 2016ってなに？
Githubが主催するユーザーデベロッパーカンファレンスイベント
keynote
Chris Wanstrath (CEO)
- Electron をPRしてた
- Activate Power Modeにうけた
- 学生に対して無料で開放して教育への取り組みに関しての話
- 政府もOpen Sourceを取り入れているよってゆうような話
- The White House · GitHub
- このリポジトリ群初めて知った
- Projects機能の話
- Reviews機能の話
- 個人のプロフィール画面がリニューアルされてる話
Nicole Sanchez (VP)
- Free and Open to the public
- Nicole Sanchez自身の経験から、何かを学ぼうとした時に限られた人や限られた条件の中でしか情報を取得できないことはありえない事的な話
- 今後２０年でコンピューターサイエンス関連の新規雇用は1500万が見込まれる。コンピューターサイエンス系の学生の今後卒業する人数からしてすでに人材不足が見込まれる
- コンピューターサイエンス系を大学で勉強していない人にも大いにチャンスがあるし、むしろ必要とされている。その為にこのキーワード(Free and Open to the public)がピッタリだなと
- 個人的にはアカデミックな学習より実践的に力が付くので良いと思ってる。独学
- 何と言っても自身が成長できる機会、学ぶ機会は人種問わずみな平等であるべきで、あとはそれを活かすかどうかはその人自身という感じはとても同意
- 退役軍人に向けたソフトウエア開発トレーニングの話もよかった
- 若い世代だけではなく学ぶ機会均等が行われてる感じが良かった
まとめ的な
自分もコンピューターサイエンスなんかやった事ないし、オープンソースの世界のおかげで今の仕事をしているし、今のプロダクトを作れているので感謝感謝と共に少しでも自分もできる寄与をしなければと思った
インターネットサービス企業の中でオープンソースの活用なしに事業をしている所はもはや存在してないんじゃないかと思う。企業として各種イベントのスポンサー、ソースの公開以外にも寄与できる事って無いかなーと思う。そのくらいお世話になってるよ。きっと。
壮大な夢と共にGithubはあるなーとkeynote見ながら思った。相変わらず英語のスピーチは苦手だけど
参考
Canary ReleaseでNginxのupgradeをした話
いち早くユーザに価値を届ける。もしくは今ユーザが抱えている課題をいち早く解決することはとても重要でこのあたりをコアバリューにしているチームも多くあると思います。
そんな流れで継続的デリバリー、デプロイあたりが注目されていて（今更感）今回はCanary Releaseでshipした話をまとめておこうと思います。
ちなみにサーバサイドアプリケーション(rubyやpythonで作られたアプリケーション)またはミドルウェア系のリリースでは話がちょっと変わってくるので注意です。
今回はタイトルの通りミドルウェアを対象にしたCanary Releaseのお話です
サーバサイドアプリケーションではシンボリックリンクを使ったデプロイやBlue-Green Deploymentあたりの考えも似ていて一緒に考慮すべきなのかなぁと思ってみたり。
さて本題。前提として下記のようなシステム構成で話をします
構成
構成の説明
- 基本的にAWS上にすべてを構築している
- ユーザはELBのラウンドロビンで横にスケールしたアプリケーションサーバ、その先のデータベースへアクセスしてレスポンスを取得する
- 今回はCanary Releaseについて書きたいのでシンプルな構成にしてる
- CloundwatchでELBのモニタリング
- Zabbix,mackerelでアプリケーション群の各サービス等をモニタリング
- fluent,elasticsearch,kibanaで主にアプリケーションサーバのログ系をモニタリング
実施したCanary Release
内容
- アプリケーションサーバ群のNginxのversionを上げた
主な手順
- 基本的な監視アラートを一時的にOFF。メンテ作業するのでね。
- アプリケーションサーバ群の1台のサーバをピックアップする（どれでもよい）今回は上記図の④を対象にした
- ELBからサービスアウトさせてユーザからは参照できないようにする。サービスアウトさせる方法はコンソール画面でも、APIでもどちらでも
- 上記図の④のサーバに対してnginx_buildを活用してnginxのupgradeを実施 (Chef経由で実施した)
- nginx_build便利でした! github.com
- リリース手順的なものを最初に作っていて、その手順に基づいた確認のコマンドとか打って確認する
- 良さげであれば④のサーバをELBにサービスインさせる
- ELBはランドロビンなので1/4の確率で④のサーバがアクセスを受け付けるようになる
- CloudwatchやZabbix,macherel,fluent経由のアプリケーションlogをkibanaからしばらく見てる
- このモニタリングで何か通常とは違う数値が集計されると今回の作業が何かしらの影響を与えたことになるので注意深くみる
- 問題があるようなら④のサーバにrollbackしてあげればよい
- 逆にこのモニタリングで通常どおりであると問題ないと判断ができるるので他のサーバ①~③のサーバに適用しても問題ない
注意
- 構成管理にChefを使っているのでnginx ver1とnginx ver2のレシピを流すだけ
- 冪等性は注意しとかなきゃいけない
まとめ的な感想
- 今回は既存で動いているミドルウェアのupgradeで期待値が何も変化が無い事だったので比較的楽だった
- 「テスト環境でのテストはどうしても限界あるから、とりあえず本番リリースしちゃえば」という言葉がちょっと理解できてしまった....伝わるかな....
- 障害とか不具合ってどうしたって出るもんだから出すなら意図的？最小限に抑えて出してrollbackしてデバッグした方が全体的なスピードと品質に貢献するよねってゆう話かな
staging vs test-in-productionという言葉を思い出した- ④だけを参照するELBを新たに作りELBのセキュリティポートでアクセス元を制御できればダークカナリアリリースも可能だなと思った。下記イメージ図
- 今回はDBは一つだったが別けてやってる事例も多く見かけた
- 新機能のアプリケーションのCanary Releaseとなるとまた考慮すべき点が多くありそうだな
- ELBのルーティンの課題
- 評価計測の課題
- アプリケーションでN%のユーザに利用できる機能といった感じでルーティンをする場合もあるっぽいね
- 何はともあれ実践を通して少しでも理解が深まって良かった。今後も活かしていきたいと思う
