PHPerKaigi 2020 2020/02/11

1. マスタデータの
管理と運用について
PHPerKaigi 2020
@KentarouTakeda / 武田 憲太郎

6. 何らかのキー（ID）で管理

8. キーと値の対応表を用意

9. 各画面で同じ対応表を使う
フォームも対応表から生成

10. マスタデータの
管理と運用について
↑これを管理する話

11. 例えばこんなデータ
•都道府県マスタ / 47件
1:北海道 / 2:青森県 / 3:岩手県/ 4:宮城県 / 5:秋田県 / 6:山形県 …
•金融機関コード / 約4000件
1:みずほ銀行 / 5:三菱UFJ銀行/ 9:三井住友銀行 / 10:りそな銀行 …
•ポケモン一覧 / 1000件弱
1:フシギダネ / 2:フシギソウ / 3:フシギバナ / 4:ヒトカゲ …
•カテゴリ一覧 / 10件
general:一般 / social:世の中 / economics:政治と経済 …

12. データベース管理＋管理画面

13. 管理画面にかかる工数
•機能追加する度にそれに対応する管理画面を作成
（開発の工数）
•データ構造が変わる度に管理画面を修正
（保守の工数）
•運用担当者に管理画面の操作方法を教える工数
（運用の工数）

14. データベースとテスタビリティ
•「13」という入力に対し「東京」と表示するテスト
でDB接続？
•「2」という入力に対し「女性」と表示するための
モック？

15. 環境間のデータ同期（リリース作業）
•ステージングと本番、双方に同じデータを入力？
（人為ミスの温床…）
•リリース用に本番環境からステージングDBへ接続？
（何のための複数環境？）
•入力してはいけないデータも
（エッジケース確認用データ、など）

16. データベースとフロントエンド
（SPA/PWAやネイティブアプリの設計やビルドを考える）
• 「13」を「東京」と表示するためにHTTP通信？
• ビルド時にbundleすれば問題ない。
• 「25」を「ピカチュウ」と表示するためにHTTP通信？
• ビルド時にbundle、すれば問題ない？（たまに増える）
• 「176-0001」を「練馬区練馬」に変換する場合は？
• ビルド時にbundle、して良いのか？（全12万件のデータ）
• そもそもビルドにDB接続が必要なのはどうなのか？

17. こんなデータ管理が求められている
•データ構造の変化に容易に対応できる
•管理画面を作る必要がない
•エンジニアでなくても更新できる
•集約管理できる
•オフラインでも利用できる

18. https:// ja.wikipedia.org/wiki/ポケモンの一覧_(1-51)#ピカチュウ

19. 運用できる？

20. こんなデータ管理が求められている
•データ構造の変化に容易に対応できる
•管理画面を作る必要がない
•エンジニアでなくても更新できる
•集約管理できる
•オフラインでも利用できる
•外部データの参照ができる

21. https://products.office.com/ja-jp/excel

22. https://packagist.org/packages/phpoffice/phpspreadsheet

23. https://www.npmjs.com/package/xlsx

24. これをプログラムに取り込みたい

25. オブジェクトのプロパティ名を定義

26. jsonでの型を定義

27. 人間向けに名前を表示
join相当
この列はプログラムからは不要
ここにIDを入力
プログラム向けにはIDを出力
DBで出来ることはExcelでも大体できる

28. 入力できてはならないデータ

29. 異常なデータの混入をテストで弾く

30. こんなデータ管理
•データ本体をgit経由で管理・配布
•変換ツールやテストをdocker等で配布
•データの環境差異はブランチで管理
•テストをパスしないcommitはmerge拒否
•テストをパスしたcommitは自動deploy
表計算 + VCS + テスト deploy ＝ CI/CD
↓
管理画面と同等の機能

31. PHPからの利用

32. PHPからの利用
•Webアプリがxlsxをパースして読み込み
• 論外
•Webアプリがjsonをパースして読み込み
• 悪くはないがそれでも遅い
•Webアプリ自体にマスタデータを組み込んでしまう
• ここが目標

33. PHPからの利用
PHPコードの雛形となるコードに、
データを流し込んでクラスとして書き出し

34. PHPからの利用
オートローディング設定をしておけば
使いたい時にいつでも使える

35. PHPでのパフォーマンス

36. PHPでのパフォーマンス
•都道府県データ 47件
•市区町村データ 約1700件
•郵便番号データ 約12万件
何件までコード化可能か？

37. PHPでのパフォーマンス
郵便番号データ 約12万件
•配布状態 12.3MB
•json変換 33.5MB
•php変換 43.1MB
https://www.post.japanpost.jp/zipcode/download.html

38. PHPでのパフォーマンス
ファイルサイズの約8倍のメモリ消費
43.1MB

39. PHPでのパフォーマンス
！？

40. PHPでのパフォーマンス
https://www.php.net/manual/ja/intro.opcache.php
その日の最初のアクセスだけ遅い…
パースの有無でメモリ使用量が変わる

41. PHPでのパフォーマンス
https://www.php.net/manual/ja/opcache.configuration.php#ini.opcache.preload
PHP7.4 preload
サーバ起動と同時に全てキャッシュに乗せる
アプリケーションデータ全部入りWebサーバ

42. PHPでのパフォーマンス
「Excelがクラッシュしない程度の件数」ならオンメモリで捌ける
•管理画面メンテ工数からの開放
•誰でもデータを触れる
•テストをパスしている限り壊れない
•本来の開発やデータ管理に集中できる
Excelならではの辛みも数多くあります。

43. それ以外の選択肢
•yaml / json + git
• ○ diffが見やすい / × 書ける人を選ぶ
•csv / tsv + git
• △ diff可だが見づらい / × Excel可だが関数は保存できない
•Google Spreadsheet + API
• ○ 同時編集できる / △ ビルド処理が外部サービスに依存
•xlsx + git
• ○ 豊富な関数・ユーザーが多い / × マージ不可

44. データの特性を見極める

45. 誰が使うデータか？
「綺麗に正規化されたデータ」
≠
「誰もが扱えるデータ」
「プログラムにとって都合が良いデータ」
≠
「人間にとって都合が良いデータ」
「モデリング上のベストプラクティス」
≠
「運用上のベストプラクティス」

46. 誰が使うデータか？
• 元データ上では「メタデータトリブル（※1）」
• 変換時に中間層を通し配列化
• 元データ上では「ジェイウォーク（※1）」
• 変換時に正規化（元データの正当性はテストで担保）
• 元データ上では「フラグの闇（※2）」
• 変換時にフィルタ（論理削除）や出力先変更（STI）
• アプリケーション上では「失われた事実（※2） 」
• 元データ上では全履歴を管理（変換時にフィルタ）
※1 オライリー・ジャパン「SQLアンチパターン」
Bill Karwin 著 / 和田 卓人、和田 省二 監訳 / 児島 修訳
※2 技術評論社「失敗から学ぶRDBの正しい歩き方」
曽根壮大 著

47. 誰が使うデータか？
変換することが前提のオフラインデータ
大本のデータがアンチパターンを踏んでいても
アプリケーション本体は守られる
「開発しやすさ」「運用しやすさ」のみを考えれば良い
（クリック数回でデータ構造すら変更できるのが表計算ソフトの長所）

48. 本当に必要なデータか？
（架空の事例：とあるソーシャルメディアの開発中）
「エントリはカテゴリ分けをお願いします！ 」
「どんなカテゴリになるんですか？ 」
「『政治・経済』『テクノロジー』とかなんだけど、
後からでも変えられるように… 」
「はい、じゃあデータは誰でも編集できるようにして
おきますね！」
※具体的なイメージが湧きやすいよう「はてなブックマーク」の画面や文言を引用していますが登壇者ははてな社とは何の関係
もありません。内容もあくまで「一般的な開発でありがちなこと」をまとめた架空の事例です。

49. 本当に必要なデータか？
「管理画面でカテゴリはいつ
でも変えられます！」
最終的に作られたデータ
※具体的なイメージが湧きやすいよう「はてなブックマーク」の画面や文言を引用していますが登壇者ははてな社とは何の関係
もありません。内容もあくまで「一般的な開発でありがちなこと」をまとめた架空の事例です。

50. 本当に必要なデータか？
「このツールを操作すればカテゴリはいつでも変えられます！」
↓
アンチパターン「触ってはならない管理画面」
文字数（横幅）変わると困る
下線や文字の色はどうやって制御？ ここだけ別制御？
※具体的なイメージが湧きやすいよう「はてなブックマーク」の画面や文言を引用していますが登壇者ははてな社とは何の関係
もありません。取り上げる内容もあくまで「一般的な開発でよくあること」をまとめた架空の事例です。

51. 本当に必要なデータか？
「政治・経済」「テクノロジー」とかなんだけど、後からでも変えられ
るように…
• 「後」とはいつか？
開発中 / 運用開始後 / 両方
• 何に対する要件なのか？
プログラム / データ / デザイン / サービス全体
• 誰が変更するのか？
エンジニアのみ / 非エンジニア含む / スキル問わず変更可
• いつ変更するのか？
いつでも / 他と足並みを揃える必要 / 変更時はメンテ必須

52. 例えばこんなデータ
•都道府県マスタ / 47件
1:北海道 / 2:青森県 / 3:岩手県/ 4:宮城県 / 5:秋田県 / 6:山形県 …
•金融機関コード / 約4000件
1:みずほ銀行 / 5:三菱UFJ銀行/ 9:三井住友銀行 / 10:りそな銀行 …
•ポケモン一覧 / 1000件弱
1:フシギダネ / 2:フシギソウ / 3:フシギバナ / 4:ヒトカゲ …
•カテゴリ一覧 / 10件
general:一般 / social:世の中 / economics:政治と経済 …

53. まとめ
• 「データベース管理＋管理画面」がベストとは限らない
• 既存のツールをうまく使うことで本来の開発に集中
• PHPでの実装例（OPCacheやPreloadで巨大データもOK）
• 変換層を設けることで堅牢性と利便性を両立
• 運用シーンを考えながらツールの選定や要否を考える