読者です 読者をやめる 読者になる 読者になる

Tsuyoshin blog

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

勉強会:GCPUG Shonan vol.13 続・移行話 にたまたま参加させて貰った

はじめに

  • いつも藤沢で利用しているコワーキングスペースで今日も作業しようかなと思ったら本当に偶然にGCPUGが行われていた
  • なんか良さげな話をしていて、主催者のお気遣いを頂き参加させて貰った😃

勉強会概要

gcpug-shonan.connpass.com

発表

Parse.comからGCPへ移行した話 ~完結編~ @tache_jp さん

speakerdeck.com

GKEの話 @sinmetal さん

  • kubernetes,GCP,Firebaseを使ったアプリケーションの構成の話
  • Remoteでちょっと聞きにくく…資料をもとに見直したいなぁ🙏🏼

最後感想とか

  • うちはフルAWSでやってるけど、だいたい同じような機能や仕組みが当然GCPにもあってそこでの現場感のある話は面白かった
  • 意外に湘南地区に住んでいるエンジニアが多くて話せて良かった
  • 予定していた作業はあまりこなせなかったけど、まぁたまにはいいかと思ってる😆
  • 皆様お疲れ様でした

社内勉強会でHTML Cacheの構成の話をした

その時の資料

speakerdeck.com

備考

  • 最近であればRoute53からドメインのAレコードをAWS Cloudfrontに向けて、originサーバにLB経由でアプリケーションサーバみたいな構成がありうる
    • けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
      • globalにあるエッジロケーションのキャッシュデータをクリアするのに20minぐらいはかかるとのことらしい

参考

勉強会:pixiv Night #02 - 画像処理技術 に参加した時のメモ

勉強会概要

pixiv.connpass.com

発表

Blenderを使ってCUIベースで3D画像処理する by haya (15min)

pixivFACTORYの画像処理周りについて何か話す by redcap97 (10min)

小説の画像から空白を取り除く画像処理 by 496 (10min)

JPEGのブロックノイズとはなにか? by harukasan (10min)

speakerdeck.com

  • cgo内での処理が多いらしい
  • ImageFluxの中身がだいたい知れて良かった
  • ストリーム処理でバッファ分をメモリ確保するだけなので効率的

go-thumber に ImageMagick をつなげた話 by yoya (5min)

  • go-thumberをスマニューでそのまま活用しようとしたけどforkしてカスタマイズしたのがyoya-thumber
  • ImageMagickは処理の前に一度メモリに載せる(=遅いし、マシーンスペックは必要)
  • proxyを通してhttp経由で画像変換を提供
    • nginxのproxy_cache経由で返却
    • 1パツ目のアクセスはキャッシュが無いので負荷がデカイ
    • オンデマンドでサムネイル画像を返却する仕組みのツラさも良く分かる…
  • ImageMagickの中身をすごく詳しくてびっくりした

  • 参考 GoImagickThumbnail // Speaker Deck

halide-langについて by saturday06 (5min)

これから使っていきたいライブラリ

  • C++の画像処理ライブラリだけど言語と言っている by 公式

    • Halide

      a language for image processing and computational photography

  • LLVMを内部でもってコンパイルしてる?

  • ffmpeg(libswscale)からhalideへ乗り変えを検討

まとめ

  • 画像処理深い…😅
  • 少し軽いノリで参加させてもらったけど、話がdeep過ぎてあまりついて行けなかった😨
  • 画像変換は今自分たちも課題があるけど、自前のコア技術として持つまでのフェーズではないから、OSSやこのあたりのSaaSをうまく活用していきたいなと思った
  • ImageMagickってすごく昔からあるけど、取って代わるプロダクトってまだ出てきてないんだなぁーと感じた
  • 画像処理系をメインに仕事をしている人はもちろんだけど、傍らでやってるエンジニアにとっても少しでも中身を知るキッカケになって良かった。
    • 色々理解出来なかった部分をググって少しでも知ることができて良かった😄
  • Streamingで画像処理をする話とか、へーそうやって軽くして多くの処理をしようとしているのかーと思った

勉強会:データ分析基盤Night #1に参加してきた

概要

data-platform.connpass.com

発表

「リブセンスのデータ分析基盤の全貌」yusaku omasa(taise)

speakerdeck.com

  • ビーコンの活用か
  • 無いとビジネス上困るからスタートしているので(あきらかなニーズがあるので)当然使われるシステムなったと言うのは良いな
  • Cookieを最大限活用しているのがポイント
  • 実装側がJavaScriptのコードを一行読み込めば良いと言う気軽さは良いな

「Rettyのデータ分析基盤について(仮)jp_taku2

  • AthenaとBigQueryを主に活用して構築している
  • 機械学習の基盤まで整っているので感じでより奥深いなーと思った

Gunosyのデータ分析/ログ基盤の全容」atsushi morimoto

speakerdeck.com

  • 攻めの為のデータ基盤、守りの為のデータ基盤と言うような分類があった
  • 守りの為のデータ基盤、タスクはなるべく自動化を図って人の手を介さないようにしている
    • いかに多くの時間を攻めの為に使えるように回すかがポイント!!
  • 完璧なログ設計は難しくて、どこかで差異が出てしまってそれをどこで(APIコンバーター?で)カバーするか?みたいな話はよく分かる…
    • カバーすればするほど複雑性が出てしまい、後からjoinしたエンジニアに申し訳なくなるパターン
  • デロリアンというオフラインテストはへーそこまでやるんだーと思った
    • 過去ログからアルゴリズムを変更してAパターンだったらどのようなデータ抽出なるか、Bパターンだったらどのようなデータ抽出になるか等々
    • これをもっと気軽にできるとproductの精度増しそう🤔

まとめ的なもの

  • やっぱりみな頑張ってBigQueryに移行している感じだった
  • 発表を聞かせてもらってもUIの為のデータ分析と言うのはABテストというものでひと括りになってしまってて、どちらかと言うとみなCVを上げるためのデータ分析基盤と言う印象が残った
    • UIやUX改善に焦点を当てたデータ分析基盤、分析方法というのに興味を持ったし、色々考えていきたいなと思った💪🏽
  • 事業インパクトがそれなりに大きいので、それぞれ専属チームで担当していた
    • 1人とか2人とかでやれる業務範囲ではないなーと思った
  • 逆に1人 or 2人でも出来るデータ分析基盤構築と分析といった感じのライトにできる事始め的な内容なら紹介出来るかもと思った😅
    • 中身はGAのデータとGoogle App Script,SpreadSheet,DataStudio,SQLといった感じなんですが😭
  • お疲れ様でした👏🏽

Googleデータスタジオを使って見てBIツールについて考えた

はじめに

下記の記事でちょっと触れてて現状の業務に少し導入してみた。

tsuyoshi-nakamura.hatenablog.com

数日後、下記のニュースが出てヨッシャー無料で使いまくれるじゃないかと思ってもっと業務に取り入れてやってみた analytics-ja.googleblog.com

ほとんど数値は隠してますが、下記のような感じで使ってました

example

1

f:id:tsuyoshi_nakamura:20170226180023p:plain

2

f:id:tsuyoshi_nakamura:20170226180037p:plain

3

f:id:tsuyoshi_nakamura:20170226180047p:plain

このあたりの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
  • 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の設定等々を見ておけば良いんじゃなかろうか…