SlideShare ist ein Scribd-Unternehmen logo
1 von 53
Downloaden Sie, um offline zu lesen
マスタデータの
管理と運用について
PHPerKaigi 2020
@KentarouTakeda / 武田 憲太郎
マスタデータの管理と運用について
マスタデータの管理と運用について
マスタデータの管理と運用について
マスタデータの管理と運用について
何らかのキー(ID)で管理
マスタデータの管理と運用について
キーと値の対応表を用意
各画面で同じ対応表を使う
フォームも対応表から生成
マスタデータの
管理と運用について
↑これを管理する話
例えばこんなデータ
•都道府県マスタ / 47件
1:北海道 / 2:青森県 / 3:岩手県/ 4:宮城県 / 5:秋田県 / 6:山形県 …
•金融機関コード / 約4000件
1:みずほ銀行 / 5:三菱UFJ銀行/ 9:三井住友銀行 / 10:りそな銀行 …
•ポケモン一覧 / 1000件弱
1:フシギダネ / 2:フシギソウ / 3:フシギバナ / 4:ヒトカゲ …
•カテゴリ一覧 / 10件
general:一般 / social:世の中 / economics:政治と経済 …
データベース管理+管理画面
管理画面にかかる工数
•機能追加する度にそれに対応する管理画面を作成
(開発の工数)
•データ構造が変わる度に管理画面を修正
(保守の工数)
•運用担当者に管理画面の操作方法を教える工数
(運用の工数)
データベースとテスタビリティ
•「13」という入力に対し「東京」と表示するテスト
でDB接続?
•「2」という入力に対し「女性」と表示するための
モック?
環境間のデータ同期(リリース作業)
•ステージングと本番、双方に同じデータを入力?
(人為ミスの温床…)
•リリース用に本番環境からステージングDBへ接続?
(何のための複数環境?)
•入力してはいけないデータも
(エッジケース確認用データ、など)
データベースとフロントエンド
(SPA/PWAやネイティブアプリの設計やビルドを考える)
• 「13」を「東京」と表示するためにHTTP通信?
• ビルド時にbundleすれば問題ない。
• 「25」を「ピカチュウ」と表示するためにHTTP通信?
• ビルド時にbundle、すれば問題ない?(たまに増える)
• 「176-0001」を「練馬区練馬」に変換する場合は?
• ビルド時にbundle、して良いのか?(全12万件のデータ)
• そもそもビルドにDB接続が必要なのはどうなのか?
こんなデータ管理が求められている
•データ構造の変化に容易に対応できる
•管理画面を作る必要がない
•エンジニアでなくても更新できる
•集約管理できる
•オフラインでも利用できる
https:// ja.wikipedia.org/wiki/ポケモンの一覧_(1-51)#ピカチュウ
運用できる?
こんなデータ管理が求められている
•データ構造の変化に容易に対応できる
•管理画面を作る必要がない
•エンジニアでなくても更新できる
•集約管理できる
•オフラインでも利用できる
•外部データの参照ができる
https://products.office.com/ja-jp/excel
https://packagist.org/packages/phpoffice/phpspreadsheet
https://www.npmjs.com/package/xlsx
これをプログラムに取り込みたい
オブジェクトのプロパティ名を定義
jsonでの型を定義
人間向けに名前を表示
join相当
この列はプログラムからは不要
ここにIDを入力
プログラム向けにはIDを出力
DBで出来ることはExcelでも大体できる
入力できてはならないデータ
異常なデータの混入をテストで弾く
こんなデータ管理
•データ本体をgit経由で管理・配布
•変換ツールやテストをdocker等で配布
•データの環境差異はブランチで管理
•テストをパスしないcommitはmerge拒否
•テストをパスしたcommitは自動deploy
表計算 + VCS + テスト deploy = CI/CD
↓
管理画面と同等の機能
PHPからの利用
PHPからの利用
•Webアプリがxlsxをパースして読み込み
• 論外
•Webアプリがjsonをパースして読み込み
• 悪くはないがそれでも遅い
•Webアプリ自体にマスタデータを組み込んでしまう
• ここが目標
PHPからの利用
PHPコードの雛形となるコードに、
データを流し込んでクラスとして書き出し
PHPからの利用
オートローディング設定をしておけば
使いたい時にいつでも使える
PHPでのパフォーマンス
PHPでのパフォーマンス
•都道府県データ 47件
•市区町村データ 約1700件
•郵便番号データ 約12万件
何件までコード化可能か?
PHPでのパフォーマンス
郵便番号データ 約12万件
•配布状態 12.3MB
•json変換 33.5MB
•php変換 43.1MB
https://www.post.japanpost.jp/zipcode/download.html
PHPでのパフォーマンス
ファイルサイズの約8倍のメモリ消費
43.1MB
PHPでのパフォーマンス
!?
PHPでのパフォーマンス
https://www.php.net/manual/ja/intro.opcache.php
その日の最初のアクセスだけ遅い…
パースの有無でメモリ使用量が変わる
PHPでのパフォーマンス
https://www.php.net/manual/ja/opcache.configuration.php#ini.opcache.preload
PHP7.4 preload
サーバ起動と同時に全てキャッシュに乗せる
アプリケーションデータ全部入りWebサーバ
PHPでのパフォーマンス
「Excelがクラッシュしない程度の件数」ならオンメモリで捌ける
•管理画面メンテ工数からの開放
•誰でもデータを触れる
•テストをパスしている限り壊れない
•本来の開発やデータ管理に集中できる
Excelならではの辛みも数多くあります。
それ以外の選択肢
•yaml / json + git
• ○ diffが見やすい / × 書ける人を選ぶ
•csv / tsv + git
• △ diff可だが見づらい / × Excel可だが関数は保存できない
•Google Spreadsheet + API
• ○ 同時編集できる / △ ビルド処理が外部サービスに依存
•xlsx + git
• ○ 豊富な関数・ユーザーが多い / × マージ不可
データの特性を見極める
誰が使うデータか?
「綺麗に正規化されたデータ」
≠
「誰もが扱えるデータ」
「プログラムにとって都合が良いデータ」
≠
「人間にとって都合が良いデータ」
「モデリング上のベストプラクティス」
≠
「運用上のベストプラクティス」
誰が使うデータか?
• 元データ上では「メタデータトリブル(※1)」
• 変換時に中間層を通し配列化
• 元データ上では「ジェイウォーク(※1)」
• 変換時に正規化(元データの正当性はテストで担保)
• 元データ上では「フラグの闇(※2)」
• 変換時にフィルタ(論理削除)や出力先変更(STI)
• アプリケーション上では「失われた事実(※2) 」
• 元データ上では全履歴を管理(変換時にフィルタ)
※1 オライリー・ジャパン「SQLアンチパターン」
Bill Karwin 著 / 和田 卓人、和田 省二 監訳 / 児島 修訳
※2 技術評論社「失敗から学ぶRDBの正しい歩き方」
曽根壮大 著
誰が使うデータか?
変換することが前提のオフラインデータ
大本のデータがアンチパターンを踏んでいても
アプリケーション本体は守られる
「開発しやすさ」「運用しやすさ」のみを考えれば良い
(クリック数回でデータ構造すら変更できるのが表計算ソフトの長所)
本当に必要なデータか?
(架空の事例:とあるソーシャルメディアの開発中)
「エントリはカテゴリ分けをお願いします! 」
「どんなカテゴリになるんですか? 」
「『政治・経済』『テクノロジー』とかなんだけど、
後からでも変えられるように… 」
「はい、じゃあデータは誰でも編集できるようにして
おきますね!」
※具体的なイメージが湧きやすいよう「はてなブックマーク」の画面や文言を引用していますが登壇者ははてな社とは何の関係
もありません。内容もあくまで「一般的な開発でありがちなこと」をまとめた架空の事例です。
本当に必要なデータか?
「管理画面でカテゴリはいつ
でも変えられます!」
最終的に作られたデータ
※具体的なイメージが湧きやすいよう「はてなブックマーク」の画面や文言を引用していますが登壇者ははてな社とは何の関係
もありません。内容もあくまで「一般的な開発でありがちなこと」をまとめた架空の事例です。
本当に必要なデータか?
「このツールを操作すればカテゴリはいつでも変えられます!」
↓
アンチパターン「触ってはならない管理画面」
文字数(横幅)変わると困る
下線や文字の色はどうやって制御? ここだけ別制御?
※具体的なイメージが湧きやすいよう「はてなブックマーク」の画面や文言を引用していますが登壇者ははてな社とは何の関係
もありません。取り上げる内容もあくまで「一般的な開発でよくあること」をまとめた架空の事例です。
本当に必要なデータか?
「政治・経済」「テクノロジー」とかなんだけど、後からでも変えられ
るように…
• 「後」とはいつか?
開発中 / 運用開始後 / 両方
• 何に対する要件なのか?
プログラム / データ / デザイン / サービス全体
• 誰が変更するのか?
エンジニアのみ / 非エンジニア含む / スキル問わず変更可
• いつ変更するのか?
いつでも / 他と足並みを揃える必要 / 変更時はメンテ必須
例えばこんなデータ
•都道府県マスタ / 47件
1:北海道 / 2:青森県 / 3:岩手県/ 4:宮城県 / 5:秋田県 / 6:山形県 …
•金融機関コード / 約4000件
1:みずほ銀行 / 5:三菱UFJ銀行/ 9:三井住友銀行 / 10:りそな銀行 …
•ポケモン一覧 / 1000件弱
1:フシギダネ / 2:フシギソウ / 3:フシギバナ / 4:ヒトカゲ …
•カテゴリ一覧 / 10件
general:一般 / social:世の中 / economics:政治と経済 …
まとめ
• 「データベース管理+管理画面」がベストとは限らない
• 既存のツールをうまく使うことで本来の開発に集中
• PHPでの実装例(OPCacheやPreloadで巨大データもOK)
• 変換層を設けることで堅牢性と利便性を両立
• 運用シーンを考えながらツールの選定や要否を考える

Weitere ähnliche Inhalte

Was ist angesagt?

Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門泰 増田
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)Koichiro Matsuoka
 
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかなぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかYusuke Suzuki
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021Hiroshi Tokumaru
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NETterurou
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介AdvancedTechNight
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)Yoshitaka Kawashima
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説murachue
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースHajime Yanagawa
 
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割Recruit Lifestyle Co., Ltd.
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)増田 亨
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計sairoutine
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Masahito Zembutsu
 
Twitterのsnowflakeについて
TwitterのsnowflakeについてTwitterのsnowflakeについて
Twitterのsnowflakeについてmoai kids
 

Was ist angesagt? (20)

Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかなぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NET
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
 
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
 
Twitterのsnowflakeについて
TwitterのsnowflakeについてTwitterのsnowflakeについて
Twitterのsnowflakeについて
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
 

マスタデータの管理と運用について