概要
パブリック公開された動画はこちらです!!
登壇の裏側
はーいここからはKomawoと尾﨑でお届けしまーす
登壇中に細部まで語られなかったアーキテクチャの良し悪しを二人で会話形式でお届けします
アーキテクチャーの変遷を中心に報告
私ってこんなに更新されてたんですね！見る影もないですね
いろんな壁にぶち当たってようやく落ち着きました。後ほどそれぞれのアーキテクチャの良し悪しは解説します
プロジェクト体制
尾﨑ってPMだったんですね！一人じゃないじゃないですか
全体の絵を書きつつKoamwoの全てを管掌してきました。この図は終盤の体制ですね。
チームのリビルドから始まったのと、データエンジニアとしての知見は実際に一人でキャッチアップから進めました
プラン変更
そうか！R&Dからスタートだったからスモールスタートだったんですね
いいところに気が付きましたね。troccoとRedshiftそれぞれパフォーマンスや要件に合わせてプラン変更を行いました
アーキテクチャ変遷
既存
これが噂の初代分析基盤のCUEBiC Analytics先輩ですか
ですです。Ruby on Railsで実装された独自の分析基盤を使用していました
なんでリプレイスが必要になったんです?
いろいろ理由はあるんですが、端的にいうと老朽化に伴い、事業成長に耐えられなくなってきたからです
検討
ここで初めてtroccoが登場するんですね
そうなんです。troccoは広告のコネクタが豊富でAWSのRDBやDWHにも対応していたので選定しました
最初はAWS GLUEでデータ整形の責務を持たせてたんですね
ですです。AWS GLUEでスクリプティングもできるのは魅力的だったのですが、一時的にS3に置いたデータの階層をバケットのパスで仮想的に分岐したり、 データカタログのjobを紐づけたりが割とブラックボックス化しやすい点があり、GLUE以外の経路でtroccoからデータ連携があった際に認識できないので、データ疎通がTableauまでできた時点でアーキテクチャを見直しました
導入
かなりシンプルな構成になりましたね！
troccoのデータマート機能を使用してRedshiftのストアドプロシージャーで整形や集計を行うことでシンプルな構成にできました
もうこれで良いんじゃないんですか？
troccoはRedshiftに関してはデータカタログ機能が未実装だったので、集計に必要な情報を登録しておくインターフェースが必要になりました。 この時点ではCBAをリニューアルして集計と収集処理を分離して継続利用する計画もありましたが、スクラッチで必要機能を作り直した方が早いという見解になりました
開発
Oasisが新たに作られて集計情報も流れてくるようになりましたね。でもなんでAWS GLUEがまた登場したんですか？
実際にOasisが完成したのは2023年の3月だったので、それまではCBAのRDSから集計に必要なデータを同期していました
あれ？でもOasisとCBAは別物ですよね？
良い質問です！ビジネスサイドからCBAの機能を7月のリプレイス直前まで使用したいという要望が多く、Oasisからは新機能を先行リリースしつつ、 CBAの機能を使うための導線を用意しておいて平行稼働できるようにしました
なるほど。つまりRDSにDB違いでOaisisのデータが相乗りしたってことですね
Komawo君が鋭すぎて怖い・・・おっしゃる通りです
恐るべき巧妙な同期設定。しかもコスパも良い。私じゃないと見逃しちゃうね
改善
RDSからAuroraに変更されたんですね
よりコストメリットを受けられるように今後の運用を考えてSREチームと連携して変更を行いました。
Ruby on RailsのACTIVE RECORDからRedshiftに接続するのは速度劣化が見られたので、このタイミングで集計設定データはAuroraに分離してRedshiftからFederated Queryで参照する形にしました
なるほどなるほど。他はTableauからAPI連携が追加されてますね。これってTableauだけじゃダメなんですか？
CBAではエキスポート機能を提供していたんですが、
リプレイスに伴い実現不可であることが運用課題としてわかったので、
Tableauで事前にViewを作成しておき、Tableau APIでGoogle Spread Sheetに連携することで補完しました
普段、よく見るところに情報が連携されるようになったってことですね
他にもまだ変更点はあるんですが分かりますか？ヒントはプラン変更です
あっRedshift ServerlessからRedshiftに変えましたよね！
正解です！そうなんです。実は6月にRedshiftのRA3に変更しました
Redshift Serverlessの方が早いんじゃないんですか？
状況によると思います。大規模なデータの転送を行う際や常時高負荷が維持される場合はRedshift Servelessの方に軍配が上がりますね
ますますRedshiftのRA3にした理由がわからない・・・
端的にいうと損益分岐点で事前に設定していた金額をRedshift Serverlessの転送時間あたりの課金額が上回ったからですね。
あとは朝のバッチ処理以外はRPUが高負荷になることも想定されなかったので
この話はプラン変更で別で詳しく解説してほしいです><
もちろんです！話がそれましたが4回目にしてようやくアーキテクチャがパフォーマンス/コストともにFIXしました
伝えたかったこと
いろいろ解説しましたが、一番苦労したのってどこか分かりますか？
データ活用を推進するのって難しいよねというお話ですか？
さすがですね！HOWの技術はエンジニアリングでどうにかなっても何を解決するかは、実際にビジネスサイドの現場まで入り込んで課題解決に当たらないと顕在化させることが難しいなと
Fit&GAPが大事ってことですね。でも導入/検討時ってそれ以前の問題も多いですよね・・・・
そうなんです！今回の裏テーマは、「良きメンターを見つけよ」というのを自分の中でメッセージとして発表させていただきました
確かに過去の登壇でも類似の内容を触れてきましたね！データ活用を推進する上で最初にやることは良きメンターを見つけることですね
ですです。フォロワーって伴走者だけじゃなくて依代だと思っていて書籍でも学問でもベンチマークでも自分の中に軸ができればそれはフォロワーと言えるのではと
分からない・・・・誰かに相談したいって時に誰かに相談したり、この情報！まさに今求めてたやつだ！って時ってかなり大きいですよね
ですです！まさにそれです！誰かに相談したい！って時にprimeNumberさんとAWSさんには本当に助けられました
確かに一緒に進めましょう！って一人でも良いから同じモチベーションで協力者が居るのって居ない時と雲泥の差がありますよね
うまく連携をとるにはどうすればよいんですか？
それは是非登壇資料の最後のページを見てもらえればと(笑)
えっここで終わるんです？！めっちゃ気になるやん！！！実際に登壇した際の資料を特別公開します。私も読み返さないと！！
その他宣伝など
なんとなんと！8月に登壇のお話をまたまたいただきました。次回のレポートをお楽しみに
