スタフェスからは
データドリブンにするためにどういったことをしているいのか、QuickSight等を交えたお話と、
データはどのようにモデリングしていくべきなのか、アプリケーションの視点なども取り入れたデータ設計の話
をお届け予定です— yuuki takezawa@ytake (@ex_takezawa) April 3, 2023
1ヶ月以上ぶりのブログとなります。皆さんお元気でしょうか！？私は直近だとフレンチブルドッグを飼いまして、毎日リモートワークしながら厳しく躾をしております。(ここらへんは後でブログで紹介します)
心配したぞ！！！！小さなおじさんめ！ pic.twitter.com/EqIMEeIheO
— adachin👾SRE (@adachin0817) March 22, 2023
仕事では直近だと3ヶ月にも渡る、Fluentdで運用しているログサーバーをAmazon Kinesisに移行することができました。ログ基盤の移行はしんどいのでもうやりたくないですが、ログのことであればいつでも相談お待ちしております。
遥か昔、メンバーに「ログといえばあだちんに聞いてくれ！」とよく言われたが、今はmajiでログのあだちんになったような気がする。(なにそれ)
— adachin👾SRE (@adachin0817) April 4, 2023
さて、今回はスターフェスティバル x ネットプロテクションズさんの、「突撃！隣のデータ設計・活用勉強会 vol.1」に参加してきました。ちなみにスタフェスのエンジニアメンバーとは@ex_takezawaさん含めて、PHPカンファレンス仙台で飲んだのと、自分の経験として前職でData Lake(Digdag,Embulk,Redash,BigQuery,Athena)の運用・改善をしておりました。非常に濃い内容で勉強になりましたので、イベントレポートさせていただきます。
イベント概要
https://stafes.connpass.com/event/273805/
オープニング
- 竹澤さん(@ex_takezawa)さん
- スターフェスティバル
- インフラ・データ処理系、PdM、アプリケーション全般
- ネットプロテクションズの技術顧問
- データ系好きな人は次回喋っちゃって〜
データドリブンなお弁当開発の実現に向けた取り組み
- 山崎さん(@koonagi3)
- スターフェスティバル
- インフラ/データエンジニア
- 猫二匹いるんだわ
- Lambda/Fargateが好き
- 進め方を共有していきたい
- 注文情報などのレポートを提供している
- システム構成を共有
- データドリブンとは
- 売上データやWEB解析データなどのデータに基づいて、アクションや意思決定を行うこと
- お弁当ニーズへの対応力向上
- 競争力の強化
- 競合も増えていってる
- 季節による売れ筋
- 特定のエリアでのジャンル
- 春限定のお弁当
- お子様向けお弁当
- これまでの飲食事業者向けデータ活用
- 注文情報やアンケート結果を、営業チームが必要に応じてメールで連携
- いつでも閲覧ができない
- レポートまでの道のり
- 1年半かかった
- 飲食事業者全体の集計データや個別の集計データをAmazonQuicksightで可視化
- QuickSightをKitchen Managerに埋め込んでいる
- データ基盤構想
- ターゲットやアプローチを考える
- データ基盤構築
- データソース S3、Kintone、Salesforce、GA、RDS
- ETL Embulk、Go
- ストレージ Aurora、S3
- 営業チームと合同でヒアリングして、データ活用の可能性を模索してきた
- コスト的に安価なQuickSightを採用
- ハマりどころをブログ書いてるよー(以下より)
- 他の飲食事業者様の情報を表示しないように制御しているのでQuickSightのセキュリティポリシーで制御している
- モック作成から営業チームにレビュー
- β版レポート提供開始
- 本番開始！
- 必要なときに必要な情報を取りにいくことができる
- 今後のデータ活用について
- データ分析の結果をお客様へもフィードバック
- QuickSightコストと連携で便利！
- 質問
- QuickSightのつらいこと
- 行レベルのセキュリティはコピーできないので開発環境で事前に準備するしかない
- なぜデータドリブンに舵を切ったのか
- お客さんに対してデータなしだと感を頼りにしていたので必要性を感じた
- QuickSightのつらいこと
Amazon Quicksightを利用する上でのTips集🎇
https://zenn.dev/stafes_blog/articles/d0bd3970a43541
DBリファクタリングする時のデータリモデリングの勘所
- 一騎さん(@ikkitang)
- スターフェスティバル
- TechPdM、Backendエンジニア
- 岡山でフルリモート
- ECS/Fargateが好き！
- DBリファクタリングの目的
- システムリプレースをするのか
- 技術的負債の解消をしたい
- 新技術で素早く価値提供をしたい
- 利便性の悪さを一気に解消したい
- フレームワークのバージョンをあげよう
- TSで書いていこう
- SPAしてReactで書くぞー
- きれいな旧システムが多い
- 開発の利便性向上だけではない
- 運用を見直してやらなくていいことを見出して昨日を見直し
- 要らないものを見直すことを検討すること
- きれいなコードに見えるけど
- 実態は契約ステータスは廃止されていることがある
- これがきれいな旧システムの罠
- 注文ステータスが様々な運用ルールで定義されている
- 普通の注文ステータスではなくて複雑になっている
- 認知負荷が高い状態になる
- 現時点の運用を見直す
- ドメインの負債も解消することを目的にシステムリプレースをしよう
- どうやって実践するのか
- リプレースはびっくりさせないこと
- 新しいものに置き換える時は不安感を与えがち
- 抑えるところを抑えながら最速で実践していく仕組み作りが大事
- 現状把握と文字起こし
- 聞いた人に対してこれであってますか？
- フィードバックをもらう
- 認識合わせ
- 図解して、ビフォーアフターの認識合わせをしておくと良い
- 仕様変更後をのシステムを俯瞰的に見て、正しいモデルを再考できる
- リレーション図を書く
- 抽出したエンティティをリレーションズに起こす
- ER図を完成
- イミュータブルデータモデリング
- 1テーブル1イベントにすれば失敗しない
- ドメインとして使用する単語を統一する
- 意思決定
- 既存システムとの並行稼動の壁(以下リンク貼っておきました)
- まとめ
- リプレースはリファクタリングではない
- 課題を把握すること
- モデリングはチームで進めていく
- 質問
- 共感しかないｗ
- キレイなシステムにしたらパフォーマンスが悪くなることも
- 切れ目はどこらへんから？
- 旧システムのEC2を落とすのが切れ目
- 共感しかないｗ
Debeziumを活用したRDBMSイベントソーシングの仕組み
- 春田さん (@harumisa31)
- ネットプロテクションズ
- ソリューションアーキテクトグループ
- マイクロサービスアーキテクチャのネタを持ってきたよ
- アーキテクチャの種類
- モノリス
- モジュラモノリス
- マイクロサービス
- モジュラモノリスを採用
- Apache Kafkaを利用
- キューイングでメッセージのログを溜める
- RDBMSで管理
- Sageパターン
- 結果生合成を担保するために分散トランザクションを避けたパターンを採用
- 二種類ある
- オーケストレーション(指揮型)
- コレオグラフィ(自律型)
- イベントソーシング/CQRS
- ドメインイベントとしての業務データの書き込み先と業務データの参照先が別れる構成
- 分散トランザクション
- Transactional Outboxを採用
- DBに追加したOutboxテーブルにイベントの内容を書き込むパターン
- Debeziumを利用
- より簡易的に可能
- Outboxパターンを利用することでSageを組むことが可能
- タイムラインスキーマにイベント依頼・消費履歴テーブルを作成しイベント情報を統合管理
- イベント依頼履歴テーブル
- kafkaに連携
- イベント消費履歴テーブル
- 冪等チェック用テーブルとしても利用
- 誰がいつ何をどこに依頼
- だれがいつどこから何を消費したのかが終える設計になる
- AWSアーキテクチャ
- MSKを利用
- ECS/FargateでKafka Consumerを稼働
- 障害発生時の対応
- 障害を起こしたConsumerGroupの失敗したメッセージまでOffSetを戻し処理を再実行
- まとめ
- Sageオーケストレーションパターン
- イベントソーシング/CQRSパターン
- Transactional Outboxパターン
- 質問
- オーケストレーションは担保されるのか
- タイムライントピックのパーティションを時系列に処理できる
- 処理がシーケンシャルにできるよう工夫している
- 質問が追いつけませんでした！
- オーケストレーションは担保されるのか
ちなみにいっきさんがDebeziumについて書いております。
- DebeziumでCDCを構築してみた
https://zenn.dev/stafes_blog/articles/ikkitang-691e9913644952
Auroraクローン作成を活用したRDBMSのDatalake連携
- 佐久間さん(@jyori112)
- ネットプロテクションズ
- 自然言語処理大学でやってた
- 機械学習の自動適用
- MLOpsも
- 今はデータ分析基盤を作ってる
- data分析環境
- 非開発者が気楽にデータを分析するができない
- 本番DB data分析環境 分析者
- 間に環境作ろう
- IT経験の少ない人でも気楽に分析できる環境を作る
- 一般的なRDBからDataLake連携
- バッチで定期実行
- 本番DBに大きな負荷がかかる
- Aurora Cluster Cloneを用いたDataLake連携
- 本番DBの負荷がほぼ0になる
- Read Replica、DB Restoreとの比較
- Cluster CloneはRead Replica、DB Restoreに近い機能
- Read Replicaではだめなのか？
- SELECT文実行中に同期が走ると整合性が保てない
- Writerをlockすることがある
- Copy-on-write protocol
- Clone clusterを作成するとPageを共有する新たなDBが作成
- データのコピーが必要なく、高速・低コスト
- Clone DBがSELECT文を実行中でもLockなく書き込める
- 不整合は発生しない
- メリット・デメリット
- DBサイズの依存せず高速に立ち上がる
- Storageの削除
- 完全に個別のDB Instanceなので、本番DBの負荷がほぼ0
- 本番DBへの更新はClone DBに反映されない
- 副次的効果
- DataLake連携システムを誰が作るのか
- 事業システムとデータ分析環境をつなぐシステム
- 事業システム開発チームが作る場合
- ドメイン外の領域で事業ごとの車輪の再開発が発生
- Cluster Cloneによりコミュニケーションをへらす
- Data Scienceチームが自立して開発可能に
- まとめ
- Aurora Cluster Clone
- 本番DBへの影響をほぼ0
- Copy-on-write Protocol
- DataLake連携システムを誰が作るのか
- 質問
- Cluster CloneとRead Replicaの使い分けは？
- Cluster Cloneは立ち上げに時間かかるのでリアルタイム性は厳しい
- Read Replicaが良い
- Cluster CloneとRead Replicaの使い分けは？
— adachin👾SRE (@adachin0817) April 6, 2023
まとめ
イッヌのご飯あげたらイベントレポート書く！
すごく勉強になりました〜🙌#stafesstudy— adachin👾SRE (@adachin0817) April 6, 2023
普段SREの業務ですが、個人的にData Lake周りは触ってて面白かったのと、各社の取り組みついてむちゃくちゃ勉強になりました！振り返るとデータベース周り弱いなと感じましたし、特に春田さんのLTはついていくので精一杯でした..内容が非常に濃い…！
いい勉強会だったのでまたやるときは参加させていただきます！では！！
- 告知！
https://stafes.connpass.com/event/279671/
スタフェス Meetup #3が来月にあるそうです！
0件のコメント