PHPカンファレンス福岡 2018に参加して
去年からコミュニティ活動を再開して少しでもコミュニティに還元して行くぞ!! と決めて今年は福岡にもきました。 そこで聞いたセッションを中心にメモ、感想、レポートをまとめておこうと思います
参加したカンファレンス
各セッション
ログの設計してますか？PSR3とログ設計の話初級
そうですよね。そうですよね。って聞いていました。自分としては下記が気になった。
ログローテーションの話が少し出ていました。purgeに関してもセットで考えた方がより良いなと感じました。 purgeを考える事は単純あデータのライフサイクルだけでなくて、このログはどのくらい保存が必要なのかまでを深く考える必要があり、より良い設計に繋がると思っています。
どんな情報が含まれているログなのか、個人情報等が含まれるログなのか、どのくらい過去ログを持つ必要があるのか。トータルを考えられるきっかになるかなと思いました。
Event Sourcing,CQRS For PHP Application
本格的な分散システムですね。すごいなーという印象。 大規模が予測される時にチャンレンジするものだと思われるけど、AWS、GCPだけでの実現する方法とかって無いかなーと個人的に思っています。 それぞれのプロダクトの専門性があるし、エンジニアを採用もうまく行くとは限らないし、クラウドのマネージドでってゆう方が実現可能性が高いかも？と感じました。
AWSでこうやって設計して稼働させて見た的な事例をちょっと探している...
ロリポップ！マネージドクラウドを支えるコンテナ技術 / lolipop-mc-containers
コンテナ周辺情報はあまり詳しく無いけど CRIU はちょっと興味深かったです。
PHPerのためのよくわかるCPU脆弱性解説 / What's Spectra for PHPers
今年の年始に騒がせていた事件をとてもわかりやすく解説してくれたセッションでした。この脆弱性って例えばロリポップのような お客さんのコードを預かる事業者になるとより笑い事出なくて、大変だったんじゃ無いかと思った。 当然詳しい事は言えないと思うのだが、懇親会とかでペパボ（ロリポップ）の人にしれっと聞いて見たらよかったな☺️
DDoS攻撃との終わりなき戦い/endless_battle_with_ddos_attack
ワンコインDDOS攻撃と言っているぐらい、いろんな人が少しの悪意があればできてしまう時代。ブラックホールルーティングとか初めて知りました。 データセンター側でどんな対応しているかを知れて為になりました。
全体的な感想等
やはり技術カンファレンスはいいですね。もっと勉強しなきゃとか色々良い刺激をもらえる場であり、現地に行っていろんな人と交流できるのは楽しいです!! なぜか遠くの地へ行けば行くほど、経費かかってるし、目一杯吸収して帰らなきゃって思うのが良い作用になっているのかなと思いました。
最後に
自分もLTで少し参加させてもらいました
GitHubSatelliteTokyo 2018に参加してみて
参加させてもらったイベント
2日間にわたって開催したイベントでしたが、下記のリンクから全てのセッションが見れます。 感じた事などをピックアップして書いておこうと思います。
day1のライブ配信
感想やら
githubの機能に関する部分
- githubの機能を改めて追ってみると知らない機能がちょこちょこあったなと感じました。
- 特にchecks apiは気になった。circleci対応は現在開発中とのこと
- github上のタスクボード(projects機能)の所も前からちょっと気になってたけど個人的な課題は下記
LT関連
時間の関係上、会場で聞けず動画で見直しました
- wantedlyさんのエンジニア以外のメンバーもgithubに入れてしまい、全社的に活用しているのはすごいなと感じた。
- 一方で時たま数時間レベルで不安定になることがあるgithubの問題を全社的に影響を受けてしまうのはどうなんだろう？そのあたり何か対応されているのだろうか？聞いて見たい
- 柴山さんまたLTされていた。イベントでよく会うw
- Start OSS Contribution With What You Know / できることから始める OSS Contributi…
- OSSへの貢献が素晴らしいし、良い刺激を頂いた
day2のライブ配信
感想やら
- 青山学院大学の古橋さんのgithubの活用例は現代ならではで、自分が学生だった頃を思い出すとすごい世の中だなと思った。
- セゾン情報システムさんのお話は、SIerさんでも活用が広がっているのは良いですね (OSS精神的な良い部分の布教が少しでも広がる事は良い事だと思います)
最後
Ask the githubにもっと粘って行けばよかった。セッションは後日動画参照できるんだからと割り切りすればよかった...
PHPerKaigi 2018に参加メモ
はじめに
参加させてもらったカンファレンスは
まず最初に感動した事は運営スタッフのおもてなしでした。とても感動しました。 おかけで楽しい且つ有益な時間を過ごせたと思っております🙇🏻
聞かせてもらったセッションの中でいくつかメモをこのしておきます
トーク
PHP と SAPI と ZendEngine3 と
www.slideshare.net
PHP5~7系において内部でどのように動いているかをわかりやすく聞けて良かってです。普段気にすることが少ないのでこういった機会はありがたかったです。 自分でも内部を見てみようと思わせてもらったトークでした🙇🏻
SOLIDの原則ってどんなふうに使うの？ by hidenorigoto
ベストトーク賞にも輝いたもので何と言ってもとってもわかりやすいなーという感想があります。自分も新人の時にこんな感じで教えて欲しかったなーと思いました
その他
あとはtrack Bで行われていた各種の相談会で色々なエンジニアと話をさせてもらったのがとても良かったです。Kaigi=コミュニケーション です!というのがまさにtrack Bだったと思います。
ほとんどこちらにいた気もします😅
最後に自分のLT
みなさまお疲れ様でした。良い刺激を頂いたカンファレンスでした。自分も精進します💪🏽
PHP勉強会でLTしてきた
勉強会
LTの資料
今回文字にして資料に残すと捉えられ方によっては誤解が生まれてしまうなぁーと思ってたのであえて文字にはせずにLT時に口頭発表した
なので資料だけだとあまり、内容がわからないかも
このLTで一番何を伝えたかったで言うと...
ダメな実装の生みの親は自分なので、必要以上に言い訳せずに先頭にたって修正していきます!!
その時の背景や事情が必要だったりすれば正確に伝えるけど、必要以上に自分から話さないようにしている。老害っぽくなっちゃうし。
デブサミ2018を参加しての振り返り
2日間にわたって行われていたデブサミ2018に参加させてもらったのでその時のメモだったり、考えた事などを残しておこうと思います
参加したカンファレンス
その中で参加させてもらったセッションは下記
リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく
http://event.shoeisha.jp/devsumi/20180215/session/1631/
思ったところ
体調不良だから自宅勤務はやめた方がいい
これは確かにそうだなと思った。体調悪いけど自宅なら小一時間であれば仕事できるのでやろうというのは自分も経験がある。
だけど、体調悪い中でやった仕事を振り返ると、真っ当な判断をしていない事が多々あった。
出社できないぐらい体調不良なら休んでしっかり直してから仕事をやるべきだなと。
体調不良とリモートワークは別問題という事をしっかり理解しないといけないですね。
リモートワークで使う道具にはお金かける
リモートでMTGするたびに画質や音質のストレスを感じながらやるのはシンドイので同意
対面 > テレビ通話 > 音声通話 > テキスト
上記のように情報量減って行く事は確かだけど、テキストにする事で一度頭の中で考えた事などが整理されたり
改めて考えて直してみたら間違いに気付けたりという効果もあるのでこの辺も考慮した使い分けが大切だなと思った
GitHubの開発フローにおけるサポートエンジニアの役割
http://event.shoeisha.jp/devsumi/20180215/session/1640/
思ったところ
Githubの内情とかあまり聞いた事なかったので聞けて良かった
サポートエンジニアの主業務は当然顧客のサポート業務だけど、issueの3割はサポートエンジニア起票のものだったり
PRの4割近くがサポートエンジニアからのだったりと結構驚いた。
もはやサポートエンジニアの業務内容を定義し直すか、サポートエンジニア起票のissueをこなす開発エンジニアを置いても良いんじゃないかと思った。
夢は正夢〜「野球エンジニア」になるまでの歩み
http://event.shoeisha.jp/devsumi/20180215/session/1625/
思ったところ
このセッションでは、なんか人生の変え方というような話で違った視点で楽しかった。 こういう方の話を聞くと、自身のキャリアの見直すきっかけになったり、自分の今やっている事の小ささを身にしみたり、刺激になった。
The Amazon Way～Amazonのソフトウェア開発～
http://event.shoeisha.jp/devsumi/20180215/session/1672/
思ったところ
先にプレスリリースから書く話、Two Pizza Teamの話等々はよくある話だったけど、
オンコールも含めほぼ全てTwo Pizza Teamで行うのでOps専用のチームは存在しない。と
Two Pizza Teamにできる限りの権限が与えられているが採用というところだけは、他のチームのメンバーがインタビューアに入ってもらったり
入る人材の高水準は保つように工夫している様子。
こういうのは定期的に更新されて外の人を含め誰もが見れるのは良い文化だなーと感じた
Empty chairとか5whysとかEveryday is still day oneとかイイっすね
さいご
そんなかんだで良いお話を聞けて良かったです。＆自分もこれからもっと精進していかなければと感じれた日でした。💪🏽
PHP Way #1 勉強会に参加して自らのプロダクトでPHPを選んだ経緯を振り返る
参加した勉強会
はじめに
ようやく自分自身にエンジニアとしての精神的な余裕ができてきたのでコミュニティ活動を再開するんだ！と思ったけど
PHPでカジュアルに参加できる勉強会とか少ないなーと感じてた。
そんな中、いつものように会社でtwitterを眺めてたらこの勉強会を発見し、近いし参加させてもらいました。
本題
一応自分もスタートアップからサービスを開発をしてきました。当然最初の技術選定やらはしていて、そこでメイン言語をPHPにした経緯や当時の狙いみたいなところを振り返ってみようと思います
序章
2013年5月1日に今の所属している会社は設立され、その年の5月下旬か6月ぐらいにjoinした。
そこの会社で立ち上げるサービスに関して決められていたのは
- その年の6月中にサービスのティザーサイトをオープンさせる。
- その2ヵ月後ぐらいにサービスオープンさせるぞ!!😱...いけるのかぁ😰
その時いたエンジニアは私ともう一人でトータル2人。あとは業務委託として数名きてもらって一気に作るという感じだった
サービス自体は当時全く認知度が無かったクラウドファンディング。 まぁ技術的な視点でみると仕組みはEC+アルファのような感じでした
提供デバイスはとりあえずPCのブラウザ版をターゲット。のちにすぐにスマホのブラウザ版もターゲット
まぁよくあるwebですね
↑このサービスの立ち上げでした
大枠を決めた
まずはインフラはその頃からAWSが出始めてきてグループ社内でも使われ始めたのもあってAWSで良いんじゃないかという感じになりました。最初からインフラエンジニアというポジションで誰か来てもらう余裕なんて無いし
AWSはこれはこれで中々大変でしたが、今回はちょっと本題からずれるので置いておく
サーバサイドアプリケーション側のメイン言語はLL言語ってだけ決めた。webですし、何よりも改善スピードを重視したいという事もあった
会社には新規事業をどんどん立ち上げる文化がありますが、同時に決められた期間内に黒字にならないとクローズというルールがあります。 自分も実際にクローズを経験しました😨
LLの中でどれにしようか悩んだ
一応言語のその当時の印象やら評価をざっくりした
振り返り、まとめる下記のような感じだったと思います
| 言語 | 振り返りコメント |
|---|---|
| perl | 今更perlで作るのもなぁー。そもそもperlで人が集まるのかなぁ。コードの書き方が色々ありすぎて統一感なくなりそう |
| python | たぶんDjangoになるだろうなぁー。個人的にはこの組み合わせは好きだし良いけど、人材確保無理じゃない？めっちゃ苦労しそう。今でさえデータ分析系が流行っているのでpython周辺のコードをいじるエンジニアは増えているようだけど |
| ruby | 当時2.0系に上がったぐらいでまだそこまでのスピードがない印象。でもrailsが盛り上がりつつあるのか？！ |
| PHP | 5.4 or 5.3あたりで、当時ソーシャルゲームが流行り始めて、PHPで作っていく組織が多くあった。PHPerいっぱいの印象 |
最終的に
結局は多くのクローズする事業を目の当たりにしてきて（当事者になるとツライです）、期限内に黒字化達成をする為に爆速で開発ができる事を最優先に考えた
そこから逆算すると自分たちのスキルセットと外部でお願いするエンジニアの確保のしやすさが重要。
自分含め２人いた創業エンジニアの今までのLL言語の経験でいうとperl,python,PHPだった。自分は直近python。もうひとりのエンジニアはPHPだった。
そうするとpython or PHP
それに外部からのエンジニアの確保のしやすさを考えると（当時だと） -> PHPですね🎉🎉🎉
フレームワーク選び
これは個人的な思考もありますが、軽量なフレームワークがいい！というのがありました。
その観点でいうと当時だとCodeIgniter
だけど、ちょうどその頃ライセンス問題が話題になっていて（のちに解決されていたのですが）、そのあたりからFuelPHPがこれから来るのではないかと信じて思い切って選択しました
その後、来たかどうかは...
まとめ1
- 実はこの検討する時間が2、3日に考えて決めたんだよなー...
- まぁちょっとあまりにも時間がなさすぎるというか、無理があるすぎると言うか...これがスタートアップなんでしょうかね...
- PHPを選択した背景を4年前を思い出しながら書いたけど、4年前ってまだ20代じゃないか。色々知識が足らず未熟な選択も多分にあったと思う
- ただ、時間は流れ、適材適所で言語を複数使いながらサービスを作り上げるのは今の主流なので今ではPHPだけではない
- コードは常に書き換わるものなのでそういった循環のサイクルを回す事のが重要な気がしている
- もちろんこれからもPHPも書くし、用途に合わせて別の言語も書くし、継続してアウトプットして少しでも良い情報を還元できればと思いっている
まとめ2
自分で言うのもなんですが、サービス立ち上げから無事に4年すぎ、そこそこまで立ち上がったと思うので当時の技術選択を用いてサービスの立ち上げは成功したんじゃなかろうかと思っています。🎉🎉🎉
以上、php wayを機に得た振り返り機会でした
おまけ
- 勉強会の最後のパネルディスカッションでどういったエンジニアを採用したいかという話があった。
- 自分も同意ですが、サービスに対してコミットしてくれて、サービスの成長・改善を第一に考えてくれるエンジニアを採用したい（もちろんプラスで技術力高い人）と。
- でも現実問題としてサービスの成長やアクセルを踏み込むべきタイミングは待ってくれなくて、いつまでにどのくらいのエンジニアを増やして開発を加速させなきゃいけないというような時はある。理想ばかり言ってられなくなる
- 妥協ではないけど、どこかで区切りというかラインを下げつつ事を先に進めなきゃいけないんだよなぁー。という現実とのギャップの苦しみはないですか？的な質問を懇親会でしたかったけど、ちょっと本業で急遽予定が入ってしまい、渋々先に上がってしまった
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が改善したりしたので確実に積み上がる仕事だったのではないかと思っています
来年に向けて
- 今年の後半ぐらいからは自分はよりコードにコミットできる体制になってきて良く感じている
- 我ながら立ち上げからコーディングとは関係ない仕事を良くやってきたなと感じている😓
- 来年はよりコードでプロダクトに良い影響を与えて行きたい
- より技術的にコミットしていき、今まで控えていたコミュニティ活動も増やして還元して行きたいです💪🏽
