xhprofとphp-quick-profilerを使って改善した話
対象のシステム
はじめに
- PHPを使っててPHP重いなーとかサーバのメモリ使いすぎだよなーとかいろんな不満を抱えていました
- PHP自体はそこまで古くないのになーとかFWのversionも上げてるしなーとかざっくり思って見たり
- でもPHPが本当に原因なのかなーっと疑問を感じながらずっと過ごしてた
- チームの他のエンジニアが
pmapを使ってプロセス (群) のメモリマッピングを表示してくれて、anonという匿名メモリー?へのメモリ割り当てが多く存在する事が分かった。
んーこれは少々ばかりDeep Driveして向き合わねばならん
まずは調査
Newrelicを使ってるんですが、契約のplanとNewrelic側の対応FWでfulephpが非対応になってて、詳細が分からずという状態だったので別の解析ツールが必要だったので色々ググった
ただ、一つのツールだけではちょっと分かりづらく、結局下記の2つのツールを活用することがよさげと思って試した
- xhprof
- fuelphpのprofiling
- fuelphp特有のものではなく、
php-quick-profilerなんですが - Particletree » PHP Quick Profiler
- fuelphp特有のものではなく、
その他
xhgui使うとxhprofの結果を見やすい用に表示してくれるGUIツールなんですが、ストレージにMongoDB使ってて自分の環境ではうまく動かず一旦断念…
調査結果~考案
自分のローカルマシンで調査しました
一応色々数値自体は隠しておきます。🙇🏽
php-quick-profiler
- どの画面でprofilingしてもMemory Usedが高い😨
- アクセスをさばく時に毎度通るロジックの部分が怪しいと分かった
xhprofのグラフから
一番ボトルネックになってる箇所を見つけた。下記グラフの赤くなってる箇所
- でもここFWのcore部分で手つけづらい…😨
- その手前の赤マルで記した部分がアクセスの度に必ず通過するメソッドで黄色くなって指摘されてた
- ここに改善の余地があるのではないかと考えた🤔
xhprofの表から
EWall%でソートして表示しています
項目
Calls… 呼びされて回数Incl Wall Time… その関数全体の処理時間IWall%… 全体の実行時間に対する割合Excl Wall Time… その関数から呼ばれた関数の実行時間を除外した、関数の純粋な処理時間EWall%… 全体の実行時間に対する割合(関数の純粋な処理時間 version)
赤で囲った部分はExcl Wallの%で、わりと高いと指摘されてる。且つ手の入れやすい部分。アクセスがある度に動くロジックの部分でもある。
xhprofのグラフの赤マルで囲ったfunctionだった🙄
こいつを改善できれば良いんじゃないかと思った🤔
それより上位はPHPのネイティブ関数の部分だったり、そのPHPのネイティブ関数をFWのcoreクラスで使ってたりでちょっと深い部分。
ここを改修となると影響範囲が大きいのでちょっと一旦パス。
以上を踏まえて主な対策方針
- アクセスされる度に動く共通のロジックの部分を見直した方が効果が高いのでやろう
- いきなりFWのCore部分に手をいれるとそれなりのリスクがあるので、Coreから切り離せる部分がまずは良いだろう
対策した内容
- アクセスがある度に毎回動くクラスAがfuelphpの
Autoloaderに設定されていて、クラスAはCoreクラスをextendしていたが、extendを止めた- xhprofの表の赤で囲ったfunctionです
- なぜかと言うと
- 親クラスのメソッドを全く使っていなかったので必要無いだろうと
- fuelphpの仕様で
Autoloaderで設定されてるクラスを辿り、_initメソッドが存在した場合はそれを動作させるみたい。つまり、クラスAの親クラスの_initメソッドが毎回動いていた- 無駄な処理で且つ、中身を見ると結構重そうな処理だった…😰
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.
- 下記の公式に書いてるように
cookieを活用して
preg_matchの判定する場面を減らした- どうしても
preg_matchを使わなければ行けない部分はあって、cookieを活用することで効率的に処理するようにした
- どうしても
対策してみた結果
Newrelic
😀
Latency
😀
CPUの数値
😀
LoadAverage
😀
もちろん
xhprof,php-quick-profilerの数値も改善が見られました😀
まとめ
- 施策を3つほどやりましたが、結局は
アクセスがある度に毎回動くクラスAのチューニングが一番効果が高かった🙌 - xhprofで指摘された処理の中で一番遅く時間が掛かってるものをチューニングしたのが良かった(FWのcoreを除外して) 😀
- あえてcore部分を一度除外したことで影響範囲も限定されるし、リードタイム短くリリースまでいける❗❗何気にここ良かったと思ってる😀
- やっぱり時間を取って絶対改善するという心意気重要💪🏽
- 思ったよりもいろんな数値の改善が見られたのでインスタンスのタイプ一つ下げれるなぁーと思った
- このシステムが動いているサーバは4台あるので削減できる金額も結構でかく見えると思われる💰
- やった事はそんなに難しい事ではないので早くやればよかったという結果論😅
- どんどん改善していきましょー🚀
memcached1.4系、redis2系、redis3系でHTTPレスポンスのベンチマークまとめ
はじめに
そもそもVarnishも検討した方は良いよという話はあるんですが、AWSでELBとか使ってたりすると中々構成がムズいなぁーと考えていて、まぁ別エントリーで詳しく書く事にして…今回はmemcached1.4系、redis2系、redis3系でHTTPレスポンスの性能比較をしたのでまとめておく
検証した構成
利用module
Nginx to Memcached
Module ngx_http_memcached_module
Nginx to Redis
Nginx version
nginx version: nginx/1.10.1
負荷内容
GitHub - wg/wrk: Modern HTTP benchmarking tool
を使って、2スレッドから50接続でアクセス,2スレッドから100接続でアクセス,3スレッドから100接続でアクセスと3パターンの負荷をかけて計測した
ベンチマーク結果
Requests/sec
- Memcached1.4系とRedis2系ではMemcached1.4系のがより多くアクセスを捌ける
- だけどMemcached1.4系とRedis3系ではRedis3系の方がより多くのアクセスを捌ける
- 負荷が高い時により顕著に現れる
Latency
- そんなに大差は無いけどRedis3系のがLatencyが小さい
その他
- EC2の上に自分でRedisやMemcachedを構築する事は考えていなくてAmazon ElastiCache(https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/WhatIs.html)を使う予定!!
- ElastiCacheではMemcachedとRedisを選べてVPC内に作れてクラスタ設定も楽で良いと感じてるが、Multi-AZ機能を提供しているのはRedisなのでRedisのが可用性により長けるなぁーと感じてる
- redis2というものがあってこっち使った方がよりパフォーマンス良いんじゃないと思ったけどDescriptionに下記のように書いてあったので
HTTP Redisを使ったIf you only want to use the get redis command, you can try out the HttpRedisModule. It returns the parsed content part of the Redis response because only get is needed to implement.
HttpRedisModuleはHTTP Redis | NGINXにリンクが貼ってあったGitHub - openresty/redis2-nginx-module: Nginx upstream module for the Redis 2.0 protocol
まとめ
- 結果から言うとRedis3系を使った方が良さそう😁
- パフォーマンス結果も😀
- 可用性も😀
- 後はAWSのメンテナンスウィンドウ時の対応や監視のCloudWatchの設定等々を見ておけば良いんじゃなかろうか…
キャッシュ戦略を考えた
はじめ
もっともっとキャッシュをうまく活用することでよりスケーラブルに、よりレスポンシブにしたいなーと考えていて幾つかのパターンを考えたのでまとめておこうと思う
キャッシュといえども広義になってしまうけどここではhtml全体をキャッシュさせてレスポンスさせるキャッシュを指して書きます
設計する上のでポイント
- ユーザ毎の情報をいかにキャッシュから返すか
- staticなデータはまぁ良いとしてユーザ毎のデータのキャッシュはしくると情報漏えいとなってしまい大事故になるので慎重に!!
- キャッシュをさせたくないデータ(ex:ECサイトだったら在庫数とか)をどう扱うか
考えたパターン
varnishを活用した場合
説明
- varnishはpostやget、urlによってキャッシュするしないという設定が柔軟で😃
- varnishの設定によりキャッシュさせるページ＝データを設定する
- 図の流れのように順番に上からアクセスをさばくが、varnishの部分でキャッシュが存在していればそこからレスポンスされる
- なのでキャッシュがあればELB→Nginx→Varnishだけでレスポンスをする
- ESI(Edge Side Includes)とvcl-hashingの機能を使えばユーザ毎のデータも部分的にキャッシュ可能で効率的にキャッシュできる😃
- キャッシュのクリアは特定のIPからのcurlでrefreshする仕組みを作り、必要に応じてcurlする
Memcachedを活用した場合
説明
- まぁ手軽😃
- ngx_http_memcached_moduleを活用してキャッシュが存在すればレスポンスするようになる
- なのでELB→Nginx→Memcached→Nginxでレスポンスをする
- Module ngx_http_memcached_module
- ngx_http_memcached_module自体にはキャッシュさせる仕組みは無く、どのページ、どのデータをキャッシュさせるかはバックエンド=PHP側で行い、ngx_http_memcached_moduleはキャッシュがあればそのデータをレスポンスをする
- ただVarnishのようにユーザ毎のデータのキャッシュを作ってそれぞれにレスポンスする仕組みは整っておらず、ちょっと厳しい😂
- キャッシュのクリアはバックエンドからkeyを特定してmemcachedのデータをdeleteする
AWS CloudFrontを活用した場合
説明
- 前の２つとはちょっと毛色がかわる
- AWS CloudFrontを活用する
- Nginxで特定のURLの場合にリバースプロキシ設定でCloudFrontへ飛ばす
- CloudFrontのoriginにはバックエンドのサーバを指定してhtmlのキャッシュを作り、CDN配信する
- ユーザ毎に必要なデータはすべてAPI経由で配信する
- キャッシュのクリアはそもそもAPIから都度配信しているので考慮不要
最後
- 3パターン考えて見たけどCloudFrontにのせるとCDN配信されるのでインフラのグローバル対応にも役立つし（当然これだけではダメだんだけど）、手間いらずにスケーラブルだなーと感じた😃
- サービスを流行らせて、AWSを使い倒せばボリュームディスカウントhttps://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-discounts.htmlが期待できるので良いかも
varnishを活用した場合とMemcachedを活用した場合のbenchmarkは下記の記事が参考になります😃 tsuyoshi-nakamura.hatenablog.com- 他にもよい方法あるのかなぁ...誰かあれば教えてください🙇🏽🙏
Nginx with Goのパフォーマンスを検証した
はじめに
そろそろAPIをちゃんと切り出して運用したほうが良いよなーとか、ネイティブアプリやる時に必ず必須だしなぁーとか思ってた。 でせっかくならGolangでやった場合どんな感じになるかなと思いながらかる～く調べていた。
Golang自体の書き方云々はまぁ良いとして、実際のAPIを公開して運用するときにさてどんな構成が一番良いんだろうとかちょっと疑問に思った。
んで何通りかあって、どれが一番ベストパフォーマンスが出るんだろうなーと疑問に思ったのでそのあたりのbenchmarkとったのでまとめる
検証環境
- 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
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)
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
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)
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
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で作ってしまってパフォーマンスを優先するパターンが結構あるんだなーと色々と調べて感じた😁
- そのときに https://github.com/gin-gonic/ginのうなFWは使わずに内包されてる
- 今回の検証結果的には
net/http、Go(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オプティマイズ360とGoogleデータスタジオ360がある - その
Googleオプティマイズ360とGoogleデータスタジオ360を無償版としてGoogleオプティマイズとGoogleデータスタジオを発表された - MicrosofltのPowerBIという同様のツールの対抗として発表された模様
主な特徴
データソースは下記が選択できる
実際の画面の使い方は下記のサイトが詳しい
Googleデータスタジオの使い方 #GoogleDataStudio
速報！Google Data Studio（グーグル・データ・スタジオ）使用感レポート | 株式会社プリンシプル
実際に使ってみた
データソースはGoogle Analyticを活用
所感。良いところ
- サクッとできた😃
- グラフがキレイ😃
- 印刷ボタンがないところが良い😄
- 印刷した瞬間からどんどんゴミになっていきますからね...
- 常にこのレポートで最新を見る。過去を見たければカレンダーを操作する💪🏽
- データソースが豊富😃
- 広告のデータも一緒に出せるので費用対効果が一発で見れる😃
- 今回は使ってないけど
- フィルターが使えるので色々な視点で絞って分析が可能😃
- 前年比とかできて良い😃
イマイチなところ
- データスタジオ上で数式計算とかはできない😢
- CV系のデータはBigQueryに入れてそこから引いたほうが良さげ😢
- Google AnalyticsにもCVデータ保存できるけど、正しい数値とはちょっとズレが生じるので別口でBigQueryにデータを入れて引いたほうがデータが正確になる
まとめ
この手軽さからしてまず良い！！GCPにあるデータとかと繋げられたらまた広がるなぁーと感じた
社内勉強会でキャッシュサーバの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
自分で勝ってに学べよは基本としてあるけどそれだけではダメでチームとして行うこと自分にもメリットは返ってくる。例えば下記
- 他の職種の人との共有言語ができる
- 組織として学びの文化形成（環境変化への対応）
- チャレンジングな部署移動を積極的にできる
組織、社会、自身が変わっても十分に力を発揮するようにするために少しづつ着実に自分のできることを増やす事が大切!!
この方の歩んできた経歴がとても面白くて一度フランクに話聞きたいなーと思った!!
