Suche senden
Hochladen
マスタデータの管理と運用について
•
0 gefällt mir
•
1,142 views
Kentarou Takeda
Folgen
PHPerKaigi 2020 2020/02/11
Weniger lesen
Mehr lesen
Ingenieurwesen
Melden
Teilen
Melden
Teilen
1 von 53
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
infinite_loop
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
NTT DATA Technology & Innovation
Cognitive Complexity でコードの複雑さを定量的に計測しよう
Cognitive Complexity でコードの複雑さを定量的に計測しよう
Shuto Suzuki
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
sairoutine
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
Weitere ähnliche Inhalte
Was ist angesagt?
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
例外設計における大罪
例外設計における大罪
Takuto Wada
MQTTとAMQPと.NET
MQTTとAMQPと.NET
terurou
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
目grep入門 +解説
目grep入門 +解説
murachue
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
増田 亨
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Masahito Zembutsu
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
Was ist angesagt?
(20)
Redisの特徴と活用方法について
Redisの特徴と活用方法について
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
TLS, HTTP/2演習
TLS, HTTP/2演習
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
例外設計における大罪
例外設計における大罪
MQTTとAMQPと.NET
MQTTとAMQPと.NET
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
目grep入門 +解説
目grep入門 +解説
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Twitterのsnowflakeについて
Twitterのsnowflakeについて
Tackling Complexity
Tackling Complexity
マスタデータの管理と運用について
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) • 変換層を設けることで堅牢性と利便性を両立 • 運用シーンを考えながらツールの選定や要否を考える
Jetzt herunterladen