頻繁に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%のユーザに利用できる機能といった感じでルーティンをする場合もあるっぽいね
- 何はともあれ実践を通して少しでも理解が深まって良かった。今後も活かしていきたいと思う
SOFT SKILLSで色々反省した
こんなツイートを見かけたので早速ポチって積読しといてやっと重い腰をあげて読んだ。 すぐに忘れてしまうので思いのままに自分なりにまとめてく
ブログ書いた。ここ5年でいちばんのおすすめ本。入社時給与交渉から引退までについて書かれてる"
— higepon (@HigeponJa) September 21, 2015
プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニアhttp://t.co/ByKMJs6FIU "
翻訳されたほんはこちら
- 作者: ジョン・ソンメズ,まつもとゆきひろ(解説),長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2016/05/20
- メディア: 単行本
- この商品を含むブログ (3件) を見る
英文はこちら
Soft Skills: The Software Developer's Life Manual
- 作者: John Z. Sonmez,Scott Hanselman,Robert C. Martin
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2014/12/29
- メディア: ペーパーバック
- この商品を含むブログを見る
全体的な感想
これもネットの書評を見たとおり、プログラマー向けのビジネス書だと思う。あとは年齢なんか結局は関係ないが、20代のうちに読んでおきたかったなーと感じた
特に刺さった部分をpick up
第4章 社交術:考えているもの以上のものが必要だ
人間は非常に感情的な生き物
正しい理論を訴えてもその人との関係値があまりイイものではなければ無駄に批判されたり、思いもよらない方向へ進んでしまうので日頃の些細な関係値づくりは必要という話。ただ世の中にはどんなにこちらが頑張っても批判ばかり口にする人がいる。もしそんな人に出会ってしまったらその人に気づかせてあげよう・うまく付き合っていこうなんて思わない事だと言っている。人の人間性を変える事はそんなに簡単な事ではない。自分の為にできるだけ逃げる事も重要だと。もし直属の上司だったら移動願い、無理だったら迷わず転職を勧めていた
第10章 プロであること
正しい事をする
ソフトウェア開発者で著作家のボブ・マーティンの説明で医者を例にして説明している
患者が医者の仕事の仕方に指示をする事がバカげているのはだれでも納得できるだろうと
患者が腕がひどく痛むので切り落としてしまってくれと医者に指示しても医者は絶対「No」というしそれが正しい判断だと
でもソフトウェア開発に話を戻すと、患者と同じ立場であるクライアントや上司に断片的な情報を元にまぁいいからこの仕様で作ってくれと言われてそのまま従ってしまう技術者が多いと。怒りをかってしまうのではないか、失注してしまうのでは無いかという恐怖がある。でもプロには超えてはいけない一線があってそこは守るべきだと。当然その場では何かしらの代償を払う可能性はあるが、長いプログラマー人生を考えたときはそちらのが良いと
第18章 テクノロジーに対して頑なな態度をとるな
選択肢を制限しない
自分が選択したテクノロジーが最高だと強調して、他のすべてのテクノロジーを過小評価してはならぬ。それは最終的に自分を傷つける事になる
自分があまり良いと思っていないテクノロジーを選んで、そのテクノロジーが良いと思ってる人を探して理由なり聴いて理解に努めよう
第26章 バカにされるのを恐れるな
小さなステップを踏もう（でなければ飛び込め）
批判される事はある程度覚悟しながらも恐れずにアウトプットし続ける。恐れて何もしていない事こそ自分にとっては最も恐ろしい事だと。小さな事でもいい最初は。でもそれすらできなければ...一気に飛び込んで必死にもがいたらイイ
このくらい刺激的な言葉だと覚えやすい!!
第28章 私の10のステッププロセス
「学習 - 実践 - 学習 - 教え」(LDLT, learn-do-learn-teach)
より理解が深まり、且つチームのレベルも押し上げる
第35章 知識の中の隙間を見つける
ただ何となくでしか理解していない事やあやふやな理解のままで事が進んでいくと弱点が長期的に増えてくる
そういった隙間が多くなると効率を最大限に引き上げて仕事をすることができなくなる
メモパットを身近において、隙間を定量的に貯めていく事から始める
第45章 習慣を作る:コードを磨こう
悪い習慣に気づいて変える
新しい習慣を生み出す
自分にxxをしなければ自分にとって重要なxxができない状況・決めを作って最初はしんどいけど頑張るしかない
第48章 どんなことでも、しないよりした方がまし
動かないでいる最大の理由は恐怖
行動を取らないでいるのは駐車している車のハンドルを切るのと同じで簡単にはきれない
逆に動いている車のハンドルは切りやすい
誰でも無駄な事は避けたいし、目的に向かって一直線で進みたいと思っているけど、実は動きながら考えて色々とハンドルを切って方向転換しながら進むことは走行距離は増えるけど最短の時間で到達できるという話
第65章 心は身体にどのようにして影響を与えるか
すべては心から始まる
信念が変われば、思考も変わる
思考が変われば、言葉も変わる
言葉が変われば、行動も変わる
行動が変われば、習慣が変わる
習慣が変われば、人格も変わる
人格が変われば、運命も変わる
宗教臭い感じもするけど納得している
第70章 失敗に正面からぶつかれ
失敗と敗北は同じではなく、失敗は一時的で敗北はずっと続く。敗北は自らの意思で選んだ結果
でもなるべく失敗してもダメージが少ない場面を選ぶとより良いと思ってる
最後に
- 多少できてる部分もあればまだまだと感じた部分もあった
- 元々エンジニアだった人が書いたビジネス書のようなものなので言っている内容がスッと入ってくる
- 元々エンジニアの人が言ってるから妙な説得力がある
- アメリカのソフトウェア開発を元に書いているので日本でもそのままとはいかないと思うけど本質的な部分はまぁそうですよねという感じ
- 老害にならないように低姿勢に真摯に自分を見つめ直す時間を持てて良かった
- 色々と突っ込みたい事はあったりするんだが、この本で出てくる第4章の内容を胸に読み込んだ
chefのCHEF-3694課題をちょっと追いかけたのでメモる
インフラ関連はChefで管理していて色々とレシピを書いていてCHEF-3694というwarningが出たのでその時に調べたことをまとめておこうと思う
CHEF-3694
下記がエラーの内容
[#CHEF-3694] Resource cloning should be removed - Opscode Open Source Ticket Tracking
今はgithubに移行していて下記あたりのissueで語られている
Chef側の対応
v12.1.0からは一応スキップできるように対応されたようです
ちなみにChef 13からは根本から対応するようす
対策
- まぁwarningなので無視する運用はあり
- 色々と工夫されてる方がいらっしゃる qiita.com
- とりあえずv12.1.0以降を使っていれば、気持ち悪いけどそのまま使えるので使ってv13が出た時にversionを上げてしまう
