勉強会:GCPUG Shonan vol.13 続・移行話 にたまたま参加させて貰った
はじめに
- いつも藤沢で利用しているコワーキングスペースで今日も作業しようかなと思ったら本当に偶然にGCPUGが行われていた
- なんか良さげな話をしていて、主催者のお気遣いを頂き参加させて貰った😃
勉強会概要
発表
Parse.comからGCPへ移行した話 ~完結編~ @tache_jp さん
- 一年がかりの移行プロジェクトかぁ
- オープンソース化されたParseサーバを動かしながら移行していった話
- 多くのバグを踏みながら対応していった話
- GCPのauto scalerの話は良かったなぁー。CPU基準で主にscaleすると言っていたけどメモリバウンドのサーバ群の場合とかどうするんだろうってちょっと気になった
- ロックオン上等とか…3ヶ月以内に収益化しなきゃいけないとかツライっすね…
- 元ネタはこのへんかな
GKEの話 @sinmetal さん
- kubernetes,GCP,Firebaseを使ったアプリケーションの構成の話
- Remoteでちょっと聞きにくく…資料をもとに見直したいなぁ🙏🏼
最後感想とか
社内勉強会でHTML Cacheの構成の話をした
その時の資料
備考
- 最近であればRoute53からドメインのAレコードをAWS Cloudfrontに向けて、originサーバにLB経由でアプリケーションサーバみたいな構成がありうる
- けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
- globalにあるエッジロケーションのキャッシュデータをクリアするのに20minぐらいはかかるとのことらしい
- けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
参考
勉強会:pixiv Night #02 - 画像処理技術 に参加した時のメモ
勉強会概要
発表
Blenderを使ってCUIベースで3D画像処理する by haya (15min)
- 下記のピクシブfactoryで使われている画像処理にBlenderを使ってる話
実はブログに詳しく書いてあるとのこと。このあたりかな
平面的なもの（Tシャツ）にディスプレイスメントマッピングと質感、パースで全然違和感なかった
- 画像処理する前に一度元画像からリサイズしてから、変換や合成をしている
- 元画像は容量的に重すぎて処理に時間がかかりすぎてしまう為
pixivFACTORYの画像処理周りについて何か話す by redcap97 (10min)
ピクシブfactoryで使われている画像処理の話
画像を変換するのに各フォーマット毎に別の処理をしている
- png … ImageMagickを使ってる
- pdf … rubyのprawnを使ってpdfを生成
- svg … potraceを利用して変換
小説の画像から空白を取り除く画像処理 by 496 (10min)
- 下記のサービスで活用されている様子
小説から本文を抜き出したい…
主なポイントは
- 行間隔
- 段組み
- 文字間隔
どれも自己相関、周波数解析で抽出している様子
JPEGのブロックノイズとはなにか？ by harukasan (10min)
- cgo内での処理が多いらしい
- ImageFluxの中身がだいたい知れて良かった
- ストリーム処理でバッファ分をメモリ確保するだけなので効率的
go-thumber に ImageMagick をつなげた話 by yoya (5min)
- go-thumberをスマニューでそのまま活用しようとしたけどforkしてカスタマイズしたのがyoya-thumber
- ImageMagickは処理の前に一度メモリに載せる(=遅いし、マシーンスペックは必要)
- proxyを通してhttp経由で画像変換を提供
- nginxのproxy_cache経由で返却
- 1パツ目のアクセスはキャッシュが無いので負荷がデカイ
- オンデマンドでサムネイル画像を返却する仕組みのツラさも良く分かる…
ImageMagickの中身をすごく詳しくてびっくりした
halide-langについて by saturday06 (5min)
これから使っていきたいライブラリ
C++の画像処理ライブラリだけど言語と言っている by 公式
- Halide
a language for image processing and computational photography
- Halide
- ffmpeg(libswscale)からhalideへ乗り変えを検討
まとめ
- 画像処理深い…😅
- 少し軽いノリで参加させてもらったけど、話がdeep過ぎてあまりついて行けなかった😨
- 画像変換は今自分たちも課題があるけど、自前のコア技術として持つまでのフェーズではないから、OSSやこのあたりのSaaSをうまく活用していきたいなと思った
- ImageMagickってすごく昔からあるけど、取って代わるプロダクトってまだ出てきてないんだなぁーと感じた
- 画像処理系をメインに仕事をしている人はもちろんだけど、傍らでやってるエンジニアにとっても少しでも中身を知るキッカケになって良かった。
- 色々理解出来なかった部分をググって少しでも知ることができて良かった😄
- Streamingで画像処理をする話とか、へーそうやって軽くして多くの処理をしようとしているのかーと思った
勉強会:データ分析基盤Night #1に参加してきた
概要
発表
「リブセンスのデータ分析基盤の全貌」yusaku omasa(taise)
- ビーコンの活用か
- 無いとビジネス上困るからスタートしているので（あきらかなニーズがあるので）当然使われるシステムなったと言うのは良いな
- Cookieを最大限活用しているのがポイント
- 実装側がJavaScriptのコードを一行読み込めば良いと言う気軽さは良いな
「Rettyのデータ分析基盤について(仮)jp_taku2
- AthenaとBigQueryを主に活用して構築している
- 機械学習の基盤まで整っているので感じでより奥深いなーと思った
「Gunosyのデータ分析/ログ基盤の全容」atsushi morimoto
- 攻めの為のデータ基盤、守りの為のデータ基盤と言うような分類があった
- 守りの為のデータ基盤、タスクはなるべく自動化を図って人の手を介さないようにしている
- いかに多くの時間を攻めの為に使えるように回すかがポイント!!
- 完璧なログ設計は難しくて、どこかで差異が出てしまってそれをどこで(API？コンバーター？で)カバーするか？みたいな話はよく分かる…
- カバーすればするほど複雑性が出てしまい、後からjoinしたエンジニアに申し訳なくなるパターン
- デロリアンというオフラインテストはへーそこまでやるんだーと思った
- 過去ログからアルゴリズムを変更してAパターンだったらどのようなデータ抽出なるか、Bパターンだったらどのようなデータ抽出になるか等々
- これをもっと気軽にできるとproductの精度増しそう🤔
まとめ的なもの
- やっぱりみな頑張ってBigQueryに移行している感じだった
- 発表を聞かせてもらってもUIの為のデータ分析と言うのはABテストというものでひと括りになってしまってて、どちらかと言うとみなCVを上げるためのデータ分析基盤と言う印象が残った
- UIやUX改善に焦点を当てたデータ分析基盤、分析方法というのに興味を持ったし、色々考えていきたいなと思った💪🏽
- 事業インパクトがそれなりに大きいので、それぞれ専属チームで担当していた
- 1人とか2人とかでやれる業務範囲ではないなーと思った
- 逆に1人 or 2人でも出来るデータ分析基盤構築と分析といった感じのライトにできる事始め的な内容なら紹介出来るかもと思った😅
- お疲れ様でした👏🏽
Googleデータスタジオを使って見てBIツールについて考えた
はじめに
下記の記事でちょっと触れてて現状の業務に少し導入してみた。
tsuyoshi-nakamura.hatenablog.com
数日後、下記のニュースが出てヨッシャー無料で使いまくれるじゃないかと思ってもっと業務に取り入れてやってみた analytics-ja.googleblog.com
ほとんど数値は隠してますが、下記のような感じで使ってました
example
1
2
3
このあたりのBIツールに関して思うこと
世の中にはBIツール系はたくさんありますが、今の業務と照らし合わせて考えてみる。
現在PCとスマホのブラウザ版でのサービスを提供している状況で考えるとwebのアクセスログが一番重要だったりする。
UIを改善してみたり、Designを変えてみたり、メルマガのセグメントを変えて見たりという日々の改善の効果測定はGoogle Analyticsから取るデータが一番指標になる。
そのアクセスログ系のデータとDBなどにストアしているデータをかけ合わせて数値を追える事が一番重要だなと感じてる
そういった視点で考えると繋ぎこむ事ができるデータソースにGoogle Analyticsがある事が重要だなーと思っている。
以上を踏まえて最近のBIツールを見てみる
Re:dash
- 直接Google Analyticsには繋ぎこむ事は出来ない
- Google AnalyticsのデータAPIで取得して一度Spreadsheetに落としてから活用する感じになる
- OSSでの提供なので自身が管理するネットワーク内のサーバにインストールして内部のDBに対してSQL投げてデータが取れる
Amazon QuickSight
- 直接Google Analyticsには繋ぎこむ事は出来ない
- 主にAWS内にあるデータに対して簡単に分析が出来るのが特徴
- RDS,RedShift,S3,Kinesis,EMRとかこの辺に色々データが溜まってると非常に便利だと思う
Tableau
- 直接Google Analyticsに接続出来る様子
- もちろんMYSQLなどのデータにもつなげてSQLを投げれる
Google Data Studio
- 直接Google Analyticsに接続出来る
- ただDBへの接続が出来るけど、セキュリティ周りの設定項目があまり出てこなかったのでちょっと心配
まとめ
Tableauは周りでの評価も高いし、一番良いんだろうなと感じてる。セキュリティ周りも少し調べた感じだとしっかり考慮されてる感あったし、安心して使えそう- ただ当然有料
Google Data Studioは無料で使えてGoogle Analyticsのデータも自由に使えるので👍だと思ってる- いきなりお金のかかるツールの導入って決済者目線で言うとちょっとok出しづらいと思ってる
- 使ってみたいと思う人も本当に活用しきれるか不安でもあるし、失敗した時の事考えるとちょっと止めとこうっと思ったりする
- 無料のもので出来る事はたくさんあって、まづはそこで活用してみて、もっとこういう情報を分析する必要があって、その分析が進むとこういった施策が打てて….といった所まで使い込んで見るとよいと思う
- そうすると本当に自分たちのチームにとって必要なツールで必要な投資かどうか自信を持って言えると思う
- 有料の額にもよる部分もあるけど、こういった思考、実際にやってみた後の評価・判断が出来る事が自体が良い経験だったりするし😁
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の設定等々を見ておけば良いんじゃなかろうか…
