Tsuyoshin blog

所属団体とは関係なく、個人的なblog

xhprofとphp-quick-profilerを使って改善した話

対象のシステム

  • PHP
  • Fulephp使ってる
  • PHP-fpm使ってる
  • Nginx使ってる

はじめに

  • PHPを使っててPHP重いなーとかサーバのメモリ使いすぎだよなーとかいろんな不満を抱えていました
  • PHP自体はそこまで古くないのになーとかFWのversionも上げてるしなーとかざっくり思って見たり
  • でもPHPが本当に原因なのかなーっと疑問を感じながらずっと過ごしてた
  • チームの他のエンジニアがpmapを使ってプロセス (群) のメモリマッピングを表示してくれて、anonという匿名メモリー?へのメモリ割り当てが多く存在する事が分かった。
    • これPHP-fpmの再起動直後と数日間運用してからもう一度計測したりして見比べるとやっぱりPHP側で色々とメモリ使ってるんだろうなーっという感じ
    • Newrelicとかでの指摘は合ってたのかと思ったり

んーこれは少々ばかりDeep Driveして向き合わねばならん

まずは調査

Newrelicを使ってるんですが、契約のplanとNewrelic側の対応FWでfulephpが非対応になってて、詳細が分からずという状態だったので別の解析ツールが必要だったので色々ググった

ただ、一つのツールだけではちょっと分かりづらく、結局下記の2つのツールを活用することがよさげと思って試した

その他

調査結果~考案

自分のローカルマシンで調査しました

一応色々数値自体は隠しておきます。🙇🏽

php-quick-profiler

f:id:tsuyoshi_nakamura:20170214111003p:plain

  • どの画面でprofilingしてもMemory Usedが高い😨
  • アクセスをさばく時に毎度通るロジックの部分が怪しいと分かった

xhprofのグラフから

  • 一番ボトルネックになってる箇所を見つけた。下記グラフの赤くなってる箇所 f:id:tsuyoshi_nakamura:20170214111014p:plain

    • でもここFWのcore部分で手つけづらい…😨
    • その手前の赤マルで記した部分がアクセスの度に必ず通過するメソッドで黄色くなって指摘されてた
      • ここに改善の余地があるのではないかと考えた🤔

xhprofの表から

f:id:tsuyoshi_nakamura:20170214111023p:plain

EWall%でソートして表示しています

項目

  • Calls… 呼びされて回数
  • Incl Wall Time … その関数全体の処理時間
  • IWall% … 全体の実行時間に対する割合
  • Excl Wall Time … その関数から呼ばれた関数の実行時間を除外した、関数の純粋な処理時間
  • EWall% … 全体の実行時間に対する割合(関数の純粋な処理時間 version)

赤で囲った部分はExcl Wallの%で、わりと高いと指摘されてる。且つ手の入れやすい部分。アクセスがある度に動くロジックの部分でもある。

xhprofのグラフの赤マルで囲ったfunctionだった🙄

こいつを改善できれば良いんじゃないかと思った🤔

それより上位はPHPのネイティブ関数の部分だったり、そのPHPのネイティブ関数をFWのcoreクラスで使ってたりでちょっと深い部分。

ここを改修となると影響範囲が大きいのでちょっと一旦パス。

以上を踏まえて主な対策方針

  • アクセスされる度に動く共通のロジックの部分を見直した方が効果が高いのでやろう
  • いきなりFWのCore部分に手をいれるとそれなりのリスクがあるので、Coreから切り離せる部分がまずは良いだろう

対策した内容

  1. アクセスがある度に毎回動くクラスAがfuelphpAutoloaderに設定されていて、クラスAはCoreクラスをextendしていたが、extendを止めた
    • xhprofの表の赤で囲ったfunctionです
    • なぜかと言うと
    • 親クラスのメソッドを全く使っていなかったので必要無いだろうと
    • fuelphpの仕様でAutoloaderで設定されてるクラスを辿り、_initメソッドが存在した場合はそれを動作させるみたい。つまり、クラスAの親クラスの_initメソッドが毎回動いていた
      • 無駄な処理で且つ、中身を見ると結構重そうな処理だった…😰
  2. preg_match関数じゃなくても良い部分はstrposに置き換えた

    • 下記の公式に書いてるようにstrposで置き換え可能な場合は置き換えた方が早くなるよって
    • PHP: preg_match - Manual

      Tip Do not use preg_match() if you only want to check if one string is contained in another string. Use strpos() instead as it will be faster.

  3. cookieを活用してpreg_matchの判定する場面を減らした

    • どうしてもpreg_matchを使わなければ行けない部分はあって、cookieを活用することで効率的に処理するようにした

対策してみた結果

Newrelic

f:id:tsuyoshi_nakamura:20170214113344p:plain

😀

Latency

f:id:tsuyoshi_nakamura:20170214113356p:plain

😀

CPUの数値

f:id:tsuyoshi_nakamura:20170214113432p:plain

😀

LoadAverage

f:id:tsuyoshi_nakamura:20170214113425p:plain

😀

もちろん

xhprof,php-quick-profilerの数値も改善が見られました😀

まとめ

  • 施策を3つほどやりましたが、結局はアクセスがある度に毎回動くクラスAのチューニングが一番効果が高かった🙌
  • xhprofで指摘された処理の中で一番遅く時間が掛かってるものをチューニングしたのが良かった(FWのcoreを除外して) 😀
    • あえてcore部分を一度除外したことで影響範囲も限定されるし、リードタイム短くリリースまでいける❗❗何気にここ良かったと思ってる😀
  • やっぱり時間を取って絶対改善するという心意気重要💪🏽
  • 思ったよりもいろんな数値の改善が見られたのでインスタンスのタイプ一つ下げれるなぁーと思った
    • このシステムが動いているサーバは4台あるので削減できる金額も結構でかく見えると思われる💰
  • やった事はそんなに難しい事ではないので早くやればよかったという結果論😅
  • どんどん改善していきましょー🚀

memcached1.4系、redis2系、redis3系でHTTPレスポンスのベンチマークまとめ

はじめに

そもそもVarnishも検討した方は良いよという話はあるんですが、AWSでELBとか使ってたりすると中々構成がムズいなぁーと考えていて、まぁ別エントリーで詳しく書く事にして…今回はmemcached1.4系、redis2系、redis3系でHTTPレスポンスの性能比較をしたのでまとめておく

検証した構成

f:id:tsuyoshi_nakamura:20170206190503j:plain

利用module

Nginx to Memcached

Module ngx_http_memcached_module

Nginx to Redis

HTTP Redis | NGINX

Nginx version

nginx version: nginx/1.10.1

負荷内容

GitHub - wg/wrk: Modern HTTP benchmarking tool

を使って、2スレッドから50接続でアクセス,2スレッドから100接続でアクセス,3スレッドから100接続でアクセスと3パターンの負荷をかけて計測した

ベンチマーク結果

Requests/sec

f:id:tsuyoshi_nakamura:20170206191234p:plain

  • Memcached1.4系とRedis2系ではMemcached1.4系のがより多くアクセスを捌ける
  • だけどMemcached1.4系とRedis3系ではRedis3系の方がより多くのアクセスを捌ける
  • 負荷が高い時により顕著に現れる

Latency

f:id:tsuyoshi_nakamura:20170206191236p:plain

  • そんなに大差は無いけどRedis3系のがLatencyが小さい

その他

まとめ

  • 結果から言うとRedis3系を使った方が良さそう😁
    • パフォーマンス結果も😀
    • 可用性も😀
  • 後はAWSのメンテナンスウィンドウ時の対応や監視のCloudWatchの設定等々を見ておけば良いんじゃなかろうか…

キャッシュ戦略を考えた

はじめ

もっともっとキャッシュをうまく活用することでよりスケーラブルに、よりレスポンシブにしたいなーと考えていて幾つかのパターンを考えたのでまとめておこうと思う

キャッシュといえども広義になってしまうけどここではhtml全体をキャッシュさせてレスポンスさせるキャッシュを指して書きます

設計する上のでポイント

  • ユーザ毎の情報をいかにキャッシュから返すか
    • staticなデータはまぁ良いとしてユーザ毎のデータのキャッシュはしくると情報漏えいとなってしまい大事故になるので慎重に!!
  • キャッシュをさせたくないデータ(ex:ECサイトだったら在庫数とか)をどう扱うか

考えたパターン

varnishを活用した場合

f:id:tsuyoshi_nakamura:20170117142512j:plain

説明

  • varnishはpostやget、urlによってキャッシュするしないという設定が柔軟で😃
  • varnishの設定によりキャッシュさせるページ=データを設定する
  • 図の流れのように順番に上からアクセスをさばくが、varnishの部分でキャッシュが存在していればそこからレスポンスされる
  • なのでキャッシュがあればELB→Nginx→Varnishだけでレスポンスをする
  • ESI(Edge Side Includes)とvcl-hashingの機能を使えばユーザ毎のデータも部分的にキャッシュ可能で効率的にキャッシュできる😃
  • キャッシュのクリアは特定のIPからのcurlでrefreshする仕組みを作り、必要に応じてcurlする

Memcachedを活用した場合

f:id:tsuyoshi_nakamura:20170117143659j:plain

説明

  • まぁ手軽😃
  • ngx_http_memcached_moduleを活用してキャッシュが存在すればレスポンスするようになる
  • ngx_http_memcached_module自体にはキャッシュさせる仕組みは無く、どのページ、どのデータをキャッシュさせるかはバックエンド=PHP側で行い、ngx_http_memcached_moduleはキャッシュがあればそのデータをレスポンスをする
  • ただVarnishのようにユーザ毎のデータのキャッシュを作ってそれぞれにレスポンスする仕組みは整っておらず、ちょっと厳しい😂
  • キャッシュのクリアはバックエンドからkeyを特定してmemcachedのデータをdeleteする

AWS CloudFrontを活用した場合

f:id:tsuyoshi_nakamura:20170117153331j:plain

説明

  • 前の2つとはちょっと毛色がかわる
  • AWS CloudFrontを活用する
  • Nginxで特定のURLの場合にリバースプロキシ設定でCloudFrontへ飛ばす
  • CloudFrontのoriginにはバックエンドのサーバを指定してhtmlのキャッシュを作り、CDN配信する
  • ユーザ毎に必要なデータはすべてAPI経由で配信する
    • Cookieからユーザを特定してjsonで返却するイメージ
    • APIのコール元は自社で提供しているアプリ(ブラウザ)なのでCookieからユーザ特定は問題ないのでは無いかと思っている(セキュリティ的に)
    • Authorization: Bearer ヘッダあたりを使えば良いんじゃないかなぁー
      • このへんもっと調べる必要あり...
  • キャッシュのクリアはそもそもAPIから都度配信しているので考慮不要

最後

Nginx with Goのパフォーマンスを検証した

はじめに

そろそろAPIをちゃんと切り出して運用したほうが良いよなーとか、ネイティブアプリやる時に必ず必須だしなぁーとか思ってた。 でせっかくならGolangでやった場合どんな感じになるかなと思いながらかる~く調べていた。

Golang自体の書き方云々はまぁ良いとして、実際のAPIを公開して運用するときにさてどんな構成が一番良いんだろうとかちょっと疑問に思った。

んで何通りかあって、どれが一番ベストパフォーマンスが出るんだろうなーと疑問に思ったのでそのあたりのbenchmarkとったのでまとめる

検証環境

f:id:tsuyoshi_nakamura:20161222222201j:plain

  • NginxでまずはHTTP通信を受ける
    • GoのフロントにNginxを置くのはキャッシュ、Logging等々、インターネットからのアクセスを受け付ける役割としてはNginxを使ったほうが最終的に良いだとうと最終的になりそうだったので入れた
  • その後、Golangに投げて、Golangではmysqlからサンプルデータをselectしてレスポンスするという環境にしている
    • Hellow Worldでは無くて少しでも実際のパターンに近づけた😀
  • nginx version: nginx/1.10.2
    • worker_processes 1;
    • worker_connections 1024;
    • keepalive_timeout 65;
  • go version go1.7.4 darwin/amd64
  • gomaxprocs=4 いつからのバージョンからはわからないけど動かしているマシンのCPUの数がセットされる様子
  • 自身のローカルマシーンのmacで完結させている

検証ツール

GitHub - wg/wrk: Modern HTTP benchmarking tool

GitHub - tsenart/vegeta: HTTP load testing tool and library. It's over 9000!

検証パターン

NginxとGoをつなぐ方法として下記のパターンを試した

Go(http.ListenAndServe) + Nginx(proxy)

一番サンプルででてくるパターンかな

vegetaでの検証結果

echo "GET http://localhost:8081" | vegeta attack -rate=100 -duration=30s | tee results_8081.bin | vegeta report

Requests      [total, rate]            3000, 100.03
Duration      [total, attack, wait]    29.996695502s, 29.98999987s, 6.695632ms
Latencies     [mean, 50, 95, 99, max]  8.262946ms, 6.36174ms, 16.602405ms, 20.103509ms, 249.542167ms
Bytes In      [total, mean]            486000, 162.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:3000
Error Set:

cat results_8081.bin | vegeta report -reporter='hist[0,2ms,4ms,6ms]'

Bucket         #     %       Histogram
[0,     2ms]   0     0.00%
[2ms,   4ms]   18    0.60%
[4ms,   6ms]   1108  36.93%  ###########################
[6ms,   +Inf]  1874  62.47%  ##############################################

cat results_8081.bin | vegeta report -reporter=plot > results_8081.html f:id:tsuyoshi_nakamura:20161225170707p:plain

wrkでの検証結果

wrk -t1 -c100 -d30s http://localhost:8081/

Running 30s test @ http://localhost:8081/
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   205.13ms  207.27ms   1.96s    95.27%
    Req/Sec   524.92    143.15     0.90k    72.44%
  8261 requests in 30.02s, 2.50MB read
  Socket errors: connect 0, read 0, write 0, timeout 14
Requests/sec:    275.16
Transfer/sec:     85.18KB

Go(net.tcp) + Nginx(fastcgi_pass)

fastcgiTCP通信

vegetaでの検証結果

echo "GET http://localhost:8071" | vegeta attack -rate=100 -duration=30s | tee results_8071.bin | vegeta report

Requests      [total, rate]            3000, 100.03
Duration      [total, attack, wait]    34.148993246s, 29.989999849s, 4.158993397s
Latencies     [mean, 50, 95, 99, max]  786.786891ms, 6.547174ms, 6.418549209s, 7.619790263s, 7.978296865s
Bytes In      [total, mean]            486000, 162.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:3000
Error Set:

cat results_8071.bin | vegeta report -reporter='hist[0,2ms,4ms,6ms]'

Bucket         #     %       Histogram
[0,     2ms]   0     0.00%
[2ms,   4ms]   31    1.03%
[4ms,   6ms]   1116  37.20%  ###########################
[6ms,   +Inf]  1853  61.77%  ##############################################

cat results_8071.bin | vegeta report -reporter=plot > results_8071.html f:id:tsuyoshi_nakamura:20161225170704p:plain

wrkでの検証結果

wrk -t1 -c100 -d30s http://localhost:8071/

Running 30s test @ http://localhost:8071/
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   312.64ms  258.32ms   1.97s    83.26%
    Req/Sec   330.31    225.29     0.92k    68.49%
  9786 requests in 30.08s, 3.11MB read
  Socket errors: connect 40, read 0, write 0, timeout 21
  Non-2xx or 3xx responses: 1607
Requests/sec:    325.37
Transfer/sec:    105.89KB

Go(net.unix) + Nginx(fastcgi_pass)

fastcgiUNIXドメインソケット通信

vegetaでの検証結果

echo "GET http://localhost:8061" | vegeta attack -rate=100 -duration=30s | tee results_8061.bin | vegeta report

Requests      [total, rate]            3000, 100.03
Duration      [total, attack, wait]    29.99792736s, 29.989999868s, 7.927492ms
Latencies     [mean, 50, 95, 99, max]  7.824538ms, 5.861618ms, 16.640207ms, 29.212751ms, 231.643738ms
Bytes In      [total, mean]            486000, 162.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:3000
Error Set:

cat results_8061.bin | vegeta report -reporter='hist[0,2ms,4ms,6ms]'

Bucket         #     %       Histogram
[0,     2ms]   0     0.00%
[2ms,   4ms]   121   4.03%   ###
[4ms,   6ms]   1484  49.47%  #####################################
[6ms,   +Inf]  1395  46.50%  ##################################

cat results_8061.bin | vegeta report -reporter=plot > results_8061.html f:id:tsuyoshi_nakamura:20161225170701p:plain

wrkでの検証結果

wrk -t1 -c100 -d30s http://localhost:8061/

Running 30s test @ http://localhost:8061/
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   221.23ms  300.71ms   1.99s    89.90%
    Req/Sec   552.81    243.08     1.09k    72.54%
  16298 requests in 30.01s, 5.20MB read
  Socket errors: connect 1, read 0, write 0, timeout 52
Requests/sec:    543.11
Transfer/sec:    177.28KB

vegetaでの検証結果のまとめ

  • レイテンシーのグラフではぱっと見ちょっと良くわからなかった。ちゃんと追うと少し差異があるのがわかるんだけど...
  • Go(http.ListenAndServe) + Nginx(proxy)Go(net.tcp) + Nginx(fastcgi_pass)の比較はだいたい同じかんじ
  • Go(net.unix) + Nginx(fastcgi_pass)との比較ではちょっと差異がでた

少し差異がでた部分のLatency比較

4ms, 6ms 6ms, +Inf
Go(net.tcp) + Nginx(fastcgi_pass) 37.20% 61.77%
Go(net.unix) + Nginx(fastcgi_pass) 49.47% 46.50%

Go(net.unix) + Nginx(fastcgi_pass)ではレイテンシーが少々いいのかな😀

wrkでの検証結果のまとめ

Req/Sec
Go(http.ListenAndServe) + Nginx(proxy) Requests/sec: 275.16
Go(net.tcp) + Nginx(fastcgi_pass) Requests/sec: 325.37
Go(net.unix) + Nginx(fastcgi_pass) Requests/sec: 543.11

秒間でさばけるリクエストはGo(net.unix) + Nginx(fastcgi_pass)は一番良かった😀

まとめ的な

  • Golangをメイン言語にしてフルスタックなFWを使うパターンよりはバッチやAPIに使う場合が結構あると思う
    • そのときに https://github.com/gin-gonic/ginのうなFWは使わずに内包されてるnet/httpで作ってしまってパフォーマンスを優先するパターンが結構あるんだなーと色々と調べて感じた😁
  • 今回の検証結果的にはnet/httpGo(net.unix) + Nginx(fastcgi_pass)でやると一番良いんじゃないかという結果になった
  • 今回は対象外にしたけど grpc / grpc.ioあたりも触ってみたいなーと余談💪🏽
  • AWS gatewayを利用するけどヘッダー認証系やスロットリングAPIキー認証、レスポンスキャッシュなどが低コストでさくっと実装できたりできるので組み合わせるとなお良いかなーっと思ったけど内部のAPIサーバには使えなかったり...うーんおしい😅
    • 使い勝手良く改善されることを願う
  • golangでgraceful-restartも運用を考えると必要だなぁと感じたけどAPIの上位にロードバランサがいればいらないかもって感じてる。どうなんだろう🤔

Google データスタジオを試してみた

はじめに

日々色々な情報が流れてきますが、たまたま目に止まったのがGoogle データスタジオ。Google Analyticsは日々使ってるし、アクセス分析に関連した分析データをサクッと簡単に且つなるべく横断的に見れるのは求めてたし、使ってみた。それなりに良かったので使用感レポートとして残し置く

Google データスタジオとは

www.youtube.com www.google.com

  • もともと有償版であるGoogleアナリティクス360スイートがあってそのうちのGoogleオプティマイズ360Googleデータスタジオ360がある
  • そのGoogleオプティマイズ360Googleデータスタジオ360を無償版としてGoogleオプティマイズGoogleデータスタジオを発表された
  • MicrosofltのPowerBIという同様のツールの対抗として発表された模様

主な特徴

データソースは下記が選択できる

実際の画面の使い方は下記のサイトが詳しい

Googleデータスタジオの使い方 #GoogleDataStudio

速報!Google Data Studio(グーグル・データ・スタジオ)使用感レポート | 株式会社プリンシプル

実際に使ってみた

データソースはGoogle Analyticを活用 f:id:tsuyoshi_nakamura:20161207161843p:plain

所感。良いところ

  • サクッとできた😃
  • グラフがキレイ😃
  • 印刷ボタンがないところが良い😄
    • 印刷した瞬間からどんどんゴミになっていきますからね...
    • 常にこのレポートで最新を見る。過去を見たければカレンダーを操作する💪🏽
  • データソースが豊富😃
  • 広告のデータも一緒に出せるので費用対効果が一発で見れる😃
    • 今回は使ってないけど
  • フィルターが使えるので色々な視点で絞って分析が可能😃
  • 前年比とかできて良い😃

イマイチなところ

  • データスタジオ上で数式計算とかはできない😢
  • CV系のデータはBigQueryに入れてそこから引いたほうが良さげ😢
    • Google AnalyticsにもCVデータ保存できるけど、正しい数値とはちょっとズレが生じるので別口でBigQueryにデータを入れて引いたほうがデータが正確になる

まとめ

この手軽さからしてまず良い!!GCPにあるデータとかと繋げられたらまた広がるなぁーと感じた

社内勉強会でキャッシュサーバのVarnishのベンチマークをレポートした

久しぶりに毎週金曜日にやっている社内の勉強会で話す機会を得たので発表した内容を残しておく

発表資料

speakerdeck.com

ざっくり感想

  • memcachedとvarnishの単純なキャッシュ性能を計測した。恐らくvarnishのが良いんだろうなーと思ってたけどその通りの結果になった😅
  • Benchmarkの数値を集計して評価するのに色々と設定が面倒で今回はレイテンシーのみを Vegeta(https://github.com/tsenart/vegeta)見てた😃
  • これからも定期的に発表していこうと思います💪🏽

弁護士ドットコム×みんなのウェディング ライフイベントメディアの成長を支える技術勉強会に参加してきた

久しぶりに勉強会に参加させてもらったのでまとめておく

勉強会概要

mwed.connpass.com

Time Table

みんなのウェディング 「爆速開発のために独自フレームワークからRails に移行した話」 @松久 浩伸

speakerdeck.com

感想とか

  • RailsActiveRecordの命名ルールとか既存のDBのschema設定に依存してしまい、どう対応していったのかと気になってた
    • 結果的にはこのあたりは別扱いというかまずはRailsに乗り換える事を優先していったという感じ
    • ActiveRecordをもっとフル活用できるとより爆速開発につながるんだろなーと勝手に思った
  • リバースプロキシで移行期間を設けてというのは良いと思うが、この移行期間はダブル運用になるので運用コストも見逃せないと思う。最短で切り替えていく計画が必要だろうと感じた。(おそらくやられているかと思いますが)
    • 場合によってはアクセスがスパイクした時とか、裏側で2つのシステムをみて対応していかないといけないし...

弁護士ドットコム 「CloudSignでのGo言語でのサービス開発」@和田 浩一

speakerdeck.com

  • サーバ側の実装はGo,Revel
  • もともとはPHPで実装されていた
  • なぜ、Goを採用したのか
    • 開発するサービスが独立している分自由度があったので新しい言語、FWを採用しやすかった
    • サービスの特性上、堅牢性が重要でその観点からも静的型付言語でコンパイル時に初歩的なエラーを発見できるのは良かったと

みんなのウェディングのデータ分析基盤の作り方 @小室 直

www.slideshare.net

  • 月刊1000万行のログ。日々増え続ける 以前は

  • mysql,modgo,内製ログツールにcron,scp,perl,grepとかとか

  • 課題
    • データストアの分断
    • 横断分析が面倒

解決は

分析には

感想とか

  • 布教活動は重要だなと同じく感じた
    • 全てエンジニアのバックボーンがあるならそこまで要らないかもしれないけど
  • 技術のわからない人向けにデータ分析関連(SQLとか)を覚えて活用すると自分の目標にどう活かしていくことができるかをセットで教えられるとより身につくだろうなと思った

弁護士ドットコム 「Yahoo砲にも耐えるインフラ設計」@薄井 敏臣

speakerdeck.com

おこなった対策

  • htmlをキャッシュしてCloudfrontでレスポンス
    • けどダメだった
  • AWSのauto scaling
    • けどダメだった(ELBのスケールアップやオートスケールは間に合わない)

最終的には

  • varnishを前方に配置
    • Cloudfrontから切り替え

感想とか

  • うちも今同じようにキャッシュでhtmlをレスポンスしている仕組みがある。Varnishの性能とベンチマークしてみたいなーと思った
  • 自分も取り急ぎの基準値としてGoogle Analyticsのリアルタイムセッション数は参考にするけど、正しくは秒間のリクエスト数になるのでそのあたりをスパイクしている時に瞬時に把握できる仕組みが必要だなと思った
  • AWS側のスケール対応が間に合わないって話はちょこちょこ聞くなぁ〜

みんなのウェディング 「サービスを支える監視運用の工夫」@坪井 昭憲

www.slideshare.net

以前は

現在は

  • zabbix,cloudwatch,twillo

感想とか

  • AWSのEC2インスタンス追加時に自動でzabbixの開始対象へする設定は確かに良い(zabbixの監視テンプレートも自動で割り当て)
  • 最近は監視内容、項目のバージョン管理していく流れ(code化される)があると思っていてそのあたりの考えとかザックばらんに話聞ければが良かったけど時間が無くて残念
    • AWS Configとか検証してたりしないかなーと思ったけど

弁護士ドットコム 「スケールする会社を支える開発組織のマネジメント」@市橋 立

  • カウボーイスタイル開発
    • スタイルなし
  • テストサーバ1台でみんで開発。かなりの初期感がある

結局スケール対応するマネージメントとは

  • ライフサイクル
    • ステージ別に考えて重点をどこにおいて対応していくかを考える

重要なのは下記

  1. 問題の見極め
  2. アンテナを張る
    • ノイズなのかシグナルなのか
    • 3回ルール(3回同じ事が起きたらノイズではなくシグナル)
  3. 引き出しを増やす
    • 他の事例を参考にインプット

みんなのウェディング 「職種を超えたスキル育成でキャリアをつくる」@中村 修治

www.slideshare.net

自分で勝ってに学べよは基本としてあるけどそれだけではダメでチームとして行うこと自分にもメリットは返ってくる。例えば下記

  • 他の職種の人との共有言語ができる
  • 組織として学びの文化形成(環境変化への対応)
  • チャレンジングな部署移動を積極的にできる

組織、社会、自身が変わっても十分に力を発揮するようにするために少しづつ着実に自分のできることを増やす事が大切!!

この方の歩んできた経歴がとても面白くて一度フランクに話聞きたいなーと思った!!