2017年の振り返り
はじめに
やっぱ年末になったので今年一年どんな開発をしたのか振り返っておきたいと思います。もちろん自分一人だけでは何もできないのでチームの成果でもありますが、自分が主となって開発してきた部分を中心にまとめてみようと思います
ちなみに
うちはメインのレポジトリに関してはリリースノートなるものを作っております。簡単にリリースしたプルリクを日付ごとにmarkdown形式に並べている（リンクさせています）
これを元に振り返って見ようかと思います
例(抜粋)
こんか感じのリリースノート
1-2月
ガイアのテレビ砲に備え、キャッシュ部分を増やしたり、expireを伸ばしたりして備えていた
結局ここでの結果がシステム的にはあまり良くなくて根本的な見直しを...😱 年始早々ツライ
個人的にはだいぶショックがあり、数日は仕事していなかった記憶があります。今年はここに向き合うんだろなーと感じた1月でした。
ここでの改善項目は大きくは下記でした
- とにかくPHPのアプリケーションのパフォーマンスが悪すぎるので見直す
- サーバを増やしたり、スケールアップ、キャッシュの見直し等々のインフラ的な対策ももちろんあるけど
- DBの見直し
ビジネス的には割と地味な戦いが続くな〜という感じだけど、エンジニアの最も重要な保全活動に力を注ぐ感じになりました
3~5月
1. DBのAurora移行
詳細は上記の記事に書いてありますが、不要なレコードを削除したり、drop tableして軽量化を図りつつ、最小のダウンタイムで移行した!!
自分は主にサポート業務になりました
副次的によかったのは2つ
1-1. AuroraのReaderが気軽に作れるのでre:dashを導入出来た事
tsuyoshi-nakamura.hatenablog.com
BIツール系も試せたのでチームにとっても良かったのではないかと
Googleデータスタジオを使って見てBIツールについて考えた - Tsuyoshin blog
1-2. Fluent,Kibanaで500エラーログ、slowクエリの可視化
問題が見える化されると改善のスピードは格段にあがる
2. PHPパフォーマンスチューニング
そもそももっとパフォーマンス改善できるよねという感じでまずは調査からして、ボトルネック見つけて、排除して、改善した
tsuyoshi-nakamura.hatenablog.com
色々ありました
preg_matchからstrposへ移行したり- UserAgent判定をそもそもNginxへ移行したり
3. キャッシュ系の戦略
このへんで色々と考えたり、検証したりしたけど結局productionへの導入まではしませんでした
6~8月
Newrelicの活用がもっと進みAWS SDK経由のAWSのAPIアクセスが遅い事に気づいて対応を進めた。外部URLのAPIコールも結局は同様で外部依存になっているところのパフォーマンスが落ちていた。
またImageMagicをphp経由で利用している箇所が比較的パフォーマンスが悪かった (そりゃそう)
AWSへのAPIアクセスを必要最低限にする工夫と画像処理(サムネイル生成とか)の課題を取り組む事になった
1. 外部APIコールのアクセスを最小限へ
とにかくDBやキャッシュを大いに活用してS3へのアクセスは最小限にした。
仕方なく外部のAPIをコールするときはGuzzleで並列リクエスト等の工夫をした
GitHub - guzzle/guzzle: Guzzle, an extensible PHP HTTP client
2. 画像のサムネイル対応
当初、Lambda + node.jsのGraphicsMagickでsmall,middle,largeサイズでサムネイル生成をして、CloudFront経由で各画面で最適な画像を選択して使おうとしてた。
でも、また運用タスク増えるなぁー
と色々と画像サムネイルソリューション探ってました
社内のデザイナーに協力してもらって画質のベンチマークとってみたり
- 事情により公開できる情報がない...💦
結局最後は、CAグループ内に存在したas Service を活用する事で運用負荷下げながら解決していった
この課題の対象箇所は本当にいたるところにあってトータルで120箇所ぐらいあってとにかくプルリク作りまくった。ここだけで軽く90ちかくプルリクを作ったんじゃなかろうか😅
9-10月
新規でiosアプリを開発が動き始めた
自分としては新規メンバーが来てくれるまでGoでAPIの基礎の走りぐらいを作ったにすぎず、ネイティブチームが頑張っておられた!!
レビューアの役割も少しさせてもらった。関連するプログラムのところだけですけど
限られた時間の中でよくリリースできたなーと基本外から眺めてました。
初めてブラウザのチームとネイティブのチームが別れた開発部隊となった
11-12月
よりあゆみを進めようとphp7化に向けてphanを活用して互換性チェックや少しでも不具合のリスクを減らす為にリファクタを繰り返した
tsuyoshi-nakamura.hatenablog.com
ImageMagicの撲滅
少しでもサーバのプロビジョニングを楽にしたい
画像のサムネイル類は外部サービスで完結するようにした
という理由から不要になったImageMagicを使っている箇所をリファクタした。ここも中々のボリュームで15プルリクぐらいつくった😅
時系列には無い細かいところでいうと
この辺は新しく入ってもらったエンジニアに色々と提案いただいて導入出来た事です
1. 開発環境の改善は結構ある
- database migrationの整備
- factory、facker導入したり
- mockテスト導入したり
- unit テストの時間が短縮したり
- xmlのfixtureを撲滅してもらったり
- gulp+webpackをwebpackに統一したり
2. vendor配下に独自ライブラリ
もともとto Cに提供していたメインレポジトリとは別に運用側で使う画面のレポジトリは分けて開発してきた(DBは当然同じ)
当然、同じようなロジックを両方のレポジトリに書くざるおえない場面が増えてきて、中々ツラくなってきた。そこで両方で使えるライブラリのレポジトリを作り、composerでインストールして両方で同じロジックのメソッドを使えるようになってコードがドライになった
その他
- もはやずっとだけど、ほぼ毎日のリリースマネージメントしてるのでなんだかんだ1日1時間程度はこれに消費してたな
- 一応STGでの最終手動確認してのリリースボタンをポチ
- マイグレーションが必要なら実行したり
- プルリク同士のdependencyがある場合にはちゃんと考慮してリリースしたり
- システム自体は常に稼働していて、様々な施策が行われている。もちろん不具合も出れば、トラブルシューティングのタスクも存在する。
- こいつらを対応しながらの作業はなかなかハードだった😅
最後に
- つらつらと書きたものを眺めているとやはりパフォーマンス改善に多くの時間を使ったなーと感じました
- 今年のメインレポジトリに約704個のプルリクがmergeされ、shipされた。そのうち約231が自分が起票のプルリクだった。
- その231のうち半分はパフォーマンスチューニング系のプルリクとなる計算になる（ざっくり）
- 感覚値とあってる
- アプリケーションサーバのレスポンスを1年間でaverageでみて見ると下記のグラフになった
- こう見るとめっちゃ改善したなぁーと思う
- LBのレイテンシーの数値も改善していたので間違いなくユーザにも改善が届けられたと思われる
- 実は事業的にもCVRが改善したりしたので確実に積み上がる仕事だったのではないかと思っています
来年に向けて
- 今年の後半ぐらいからは自分はよりコードにコミットできる体制になってきて良く感じている
- 我ながら立ち上げからコーディングとは関係ない仕事を良くやってきたなと感じている😓
- 来年はよりコードでプロダクトに良い影響を与えて行きたい
- より技術的にコミットしていき、今まで控えていたコミュニティ活動も増やして還元して行きたいです💪🏽
