pixivisionを動かし続けるために

2023-09-29, PIXIV MEETUP 2023 (LT1-2)
https://conference.pixiv.co.jp/2023/meetup#lt

Transcript

1. pixiv.inc pixivisionを 動かし続けるために @fono 1
2. Profile fono バックエンドエンジニア 2019年度新卒入社。趣味は旅(鉄道, バイク)と自宅サーバー 入社時所信は「自分の”好き”でみんな の”好き”を支えたい」 2
3. 全体の流れ 1. 今日の内容 2. pixivisionとは？ 3. 機能のかいしゃく 4. アーキテクチャ改善 5. 未来へ届ける 3
4. 今日の内容 話すこと • 2021年8月着任時からpixivisionでやってきたこと • 全体を通した技術的な思考、志向、アーキテクチャ 話さないこと • 実装の細部 • 言語や環境に依存したトリッキーな部分 4
5. とは？ www.pixivision.net のこと(since 2014.6) 歴史的経緯でコードネームはspotlight ＼ ﾐﾃﾈ! ／ 5
6. 公式説明 (/ja/about)は下記の通り イラストやマンガ、ノベルをはじめとし た「創意工夫から生まれる"とっておきの 作品"」とオタクカルチャーを多言語で世 界に向けて発信する、毎日に退屈したく ない人のための創作系メディアです。 ＼ ﾐﾃﾈ! ／ 6 とは？
7. 機能のかいしゃく 7
8. 解釈🤔 8
9. 機能実装の経緯と意図を解釈する • 機能の経緯と動作と実運用 • 資料はUMLと文章で構成 • 古いという理由で邪険にしない(不要なバイアス) つぶさに調べて資料にまとめた上で、丁寧に解釈していく 9
10. つぶさに調べて まとめている様子 UMLでの表現 • ステートマシン図(状態遷移) • 相互作用とフロー(シーケンス図) • 自然言語よりは意味が固まっている • コード読解より大枠を理解しやすい • 必要な部分は文章で補足 10
11. つぶさに調べて まとめている様子 文章での表現 • 必要な分だけ • とはいえ少なくできない • 実装経緯 • 期待された・実は違う動作 • 今後の改修方針 11
12. わ　か　る 資料はめんどい…… 12
13. VCSはコードの履歴を残すが 経緯と意図は残してくれない しかしながら 13
14. だからこそ • 過度に1資料を肥大化させない ⇒カジュアルに新しいページを作る • 惰性で残すことだけに固執しない ⇒Archiveという状態で見えなくする • しっかり資料奉行をやる ⇒読める、書ける、整っているを維持する 14
15. 機能のかいしゃく 15
16. 介錯😇 16
17. 使われていない機能を片付ける 解釈を終えた機能を、精度高く判断して介錯する • 敬意を持って看取る • 安全に消す ◦ 管理画面以外、基本的にメンテナンスで停止しない • 次に活かす ◦ なぜ不要になってしまったのかは軽く考慮する ◦ やむを得ない場合もある(ほとんどかも) 17
18. 看取った機能たち 消したもの 使っていないから看取る • 独自ABテスト • 管理画面の一部ロール • 運用実態のない表示領域 • 記事末導線テンプレート管理 • 公開済み記事の膨大な編集履歴 吸収合併したもの まとめて片寄せする • 記事データ形式(2形式⇒1形式) • 記事サムネイル形式(2形式⇒1形式) 18
19. 確実に実装量は減って 明らかに身軽になった 結果として DB 52カラム廃止 仕様 10+機能廃止 ※チケットベース,統廃合含む 21万+滞留レコード削除 ※本番DB保持から必要なレコードのみデータ基盤退避に仕様変更 19
20. アーキテクチャ改善 20
21. アーキテクチャ改善 • 身軽になったので、解釈が十分にできた機能が多くなる • 全体の実装をどのように整理するかの議論ができるようになる • 資料と照らし合わせて差分で検討できる • しかし、複雑性起因で撤退する機能はまだある • 全体の構造を見直す時期では？ 21
22. 深まる検討と実装 分割 ベタ書きの脱却と疎結合化 • どこで分割するか • 分割して差し替えたらどうなるか • 疎結合にして差し替えるのに適切な 場所はどこか 抽象化 移譲と認知負荷の軽減 • 適度な抽象度か • 既存実装に抽象度のブレはないか • この抽象は何を表現しているのか 22
23. まずは実装を大きく整頓した 平置きだったコードを フォルダに整頓 ※1ファイル1クラス ←before(47 file) after(29 file)→ 単純に認知コストが下がる 23
24. 整頓前の何が辛かったか • 全て平置きであり、依存関係が見通せない • 記事に関する神クラスを片付ける目処が立たない • 2017年の段階で大半の処理が2種類に分けられるとわかったが 実装に反映されていなかった(次のスライドで説明) 24
25. 横2分割 2種類の分類 Admin(赤色) 管理画面/ビジネスユーザー側 • 記事の管理 • 諸々の業務システム的な部分 Public(青色) 公開画面/記事を表示する側 • www.pixivision.net • 表示やSNSのシェアといった 公開されるデータを扱う 25
26. 整頓方針 • 分類に名前がついていなかったのでPublic, Adminと名付けた • 処理の役割に合わせてPublic, Adminの分離を行い Spotlight Public Admin Responsive Segregation と名付けた 頭文字から「エスパーズ」と呼んだが呼ぶ機会はあまりない 26
27. 整頓方針 • CQRS(クエリコマンド責務分離)とセットで考え 3種類に整頓(4分類だが、1分類は該当処理なし) • 記事本体の読み書きに関して、下記のように整理できた CQRS\SPARS Public Admin Command N/A(該当処理なし) (表示側で書き込む) Admin/ArticleCommandRoutine (管理側で書き込む) Query ArticleQueryRoutine (表示側で読み込む) Admin/ArticleQueryRoutine (管理側で読み込む) 27
28. 横2分割 CQRSとの関係 表示と編集を行う処理 • Read/Write • Query, Commandがある 表示に限られた処理 • ReadOnly • Queryしかない Admin(赤色) Public(青色) 28
29. 整頓結果 • パッケージングを意識し始めることができた • 「こちらを触っても直接Publicは壊れない」という安心感が生まれた • 整頓できないクラスの特徴から今後のリファクタ方針が浮かび上がった ◦ OOP, DDDにおける各種原則の実践も視野に入るようになってきた ◦ 惰性で配置するのではなく、もっと意図した配置とアーキテクチャへ 29
30. アーキテクチャ改善の続き • 突き詰めると一番身構えるべき変更がわからなくなる • それを脱するにはこの問いが発生する ◦ pixivisionをどうしていくか ◦ 今の実装をどう変えて何を実現したいか • 限られたリソースで優先順位をつけなければならないので、 精度高く、意図を持って決めておく必要性が認識できた • 記事を編集しているチームとより密に連携する必要が出てきた 30
31. 保守だけの状態が終わり あるべき問いに帰結した 31
32. 未来へ届ける • 実は最初のQRコードのリンク先はID=1、最初の記事 • 一貫していたのは「過去の記事がそつなく表示できること」 • これまでpixivisionに携わったすべての人が意図してか意図せずか 記事で紹介した作品と作者を尊敬し、未来に届ける という営みが連綿と続いていた • その営みを、真摯に、されど楽しく受け継いでいきたい 32
33. pixivision先生の次回作に ご期待ください ご清聴ありがとうございました 33