Kayac. Inc Redshiftを 中心としたAWSでのデータ基盤 みんなの考えた最強のデータアーキテクチャ〜2025もやって きましょうSP！ 2025/01/30 20:10 - 20:25 面白法人カヤック 池田将士 (@mashiike)

Kayac. Inc @mashiike 面白法人カヤック 管理本部 グループ情報部 所属 自己紹介 Roles: ● データエンジニア ● バックエンドエンジニア ● データアナリスト ● SRE その他: ● 2016年12月にカヤックに 新卒入 ● ゲーム好き 最近はPoE2をやってます ● 利き茶・利き酒もやります （なお正答率は低い） Redshift/BigQuery/Snowflake、全部使える3刀流 業務・趣味含めて主要なDWHはある程度使います

Kayac. Inc 主にWeb技術を得意とする ゲームやサービスなど 多種多様な事業を展開する おもちゃ箱のような会社。 経営理念『つくる人を増やす』 会社紹介

Kayac. Inc ● 僕の考える『最強』とは。 ● AWSにおけるデータ基盤の話 ● で、具体的には？　（図のみ） アジェンダ： ※割と個別最適化されてます

Kayac. Inc 僕の考える『最強』とは。 はじめに、 について語ります ※割と個別最適化されてます

Kayac. Inc 僕の考える『最強』とは。 https://www.kayac.com/company は 背景1： ですが・・・ 多分、『データエンジニア』を 名乗ってる人は実は少ない（2~3人くらい？）

Kayac. Inc 僕の考える『最強』とは。 背景１：『専任』が居ない。開発チームもデータエンジニアリングする。 補足: カヤックでは、Enabling DRE(Data Reliability Engineering) 的な感じで関わろうとしています。 各プロダクトの開発チームにデータ（信頼性）エンジニアリングを浸透させて、 開発チーム自体で、データ基盤の開発・保守・運用ができるようにという感じ。 そういう意味でも「専任」というのが薄い。 データエンジニアと名乗ってなくてもデータエンジニアリングはする。 https://www.kayac.com/service/closed_and_soldout また、カヤックは事業売却・撤退が非常に多い。 やってるサービスも幅広い。 なので、統一データ基盤を作るより、 各プロダクト毎にデータ基盤を用意するほうが理にかなってる。 そういう意味でも、Enablingで関わるのがいい

Kayac. Inc 僕の考える『最強』とは。 最近のデータ基盤のパターンってこうですよね？ ここより右は実は、安定したら保守がそんなに大変じゃない データ基盤の開発が安定してきて 運用・保守フェーズになると 一番、めんどくさいのは 『Data Ingestion』の周り Airbyteの保守だったり、 SaaSとのやり取りだったり、 ネットワーク障害対応だったり、 etc…

Kayac. Inc 僕の考える『最強』とは。 背景１：『専任』が居ない。開発チームもデータエンジニアリングする。 背景２：安定すると『めんどくさい』＝『人の欲』が集まるのは Data Ingestion周り。

Kayac. Inc 僕の考える『最強』とは。 安定してくると生まれてくる『人の欲』 『このレポート（ダッシュボード）の更新 もっと早くならない？』 『リリースしてすぐの初速が見たい！』 『これが止まると困るから、もっと安定化して』 だいたい、一番最初に整備したやつが一番重要で そのうち、『ニアリアルタイム』『安定』という 言葉が出てくる。

Kayac. Inc 僕の考える『最強』とは。 背景１：『専任』が居ない。開発チームもデータエンジニアリングする。 背景２：安定すると『めんどくさい』＝『人の欲』が集まるのは Data Ingestion周り。 一番最初に整備したやつが、大体一番重要で 『ニアリアルタイム』に『安定』=(高可用性）にデータを取得したくなる。 ニアリアルタイムのデータ転送で、高可用性とか めちゃめんどくさい！！！！

Kayac. Inc 僕の考える『最強』とは。 一番楽に、（重要なデータが） 可能な限り早く、 転送されてくる方法 =マネージド転送に対応してるやつ どの箱(DWH/Query Engine)がいいとか、 自分は全部大体使えるし、開発チームは０から学習するからどれでもいい。 背景１：『専任』が居ない。開発チームもデータエンジニアリングする。 背景２：安定すると『めんどくさい』＝『人の欲』が集まるのは Data Ingestion周り。

Kayac. Inc 僕の考える『最強』とは。 いちばん重要なデータが何なのか？で僕の最強の構成は変わる なら 例えば： が中心 なら 特殊な が中心 一番重要なデータを一番簡単に鮮度良く運べる箱を選ぶのが 僕の考える『最強』

Kayac. Inc AWSにおけるデータ基盤の話 次に、 をします。 重要なデータがAWSにあるなら、データ基盤も僕はAWSで作るのが楽=最強だと思う

Kayac. Inc AWSにおけるデータ基盤の話 https://aws.amazon.com/jp/events/summits/online/japan/sessions/ AWS Summit 2021 AWS-06: 『貯めるだけじゃもったいない！AWS 分析サービスを使ったデータレイクの有効活用』資料より参照 基本的には Amazon S3が中心 AWSのほとんどのサービスはS3と の連携を重視する事が多いので、 S3を中心にするのが無難ではある これが、2023年までの話。

Kayac. Inc AWSにおけるデータ基盤の話 https://aws.amazon.com/jp/blogs/news/amazon-redshift-announce ments-at-aws-reinvent-2023-to-enable-analytics-on-all-your-data/ AWS re:Invent 2023から『zero-ETL』 というキーワードが出現するようになりました。 『zero-ETL』を一言でいうと、(ニアリアルタイム)転送をマネージドでAWSがやってくれるという仕組み 2023: https://aws.amazon.com/jp/blogs/news/top-announcements-of-aws -reinvent-2024/ 2024: https://aws.amazon.com/jp/what-is/zero-etl/

Kayac. Inc AWSにおけるデータ基盤の話 2023年までは、S3を中心にしてデータ転送が強かった。 S3を中継して、自前でETL/ELTを実装する感じ 2023年からは、外側の各サービス間のデータ転送を強くしてるようだ。 S3の外側にいる各サービス間でマネージドな転送を活用 2023年まで 2025年１月時点で、 zero-ETLがよく進んでいるのは『Redshift』 2023年から

Kayac. Inc AWSにおけるデータ基盤の話 2025年１月時点で、以下のデータソースが重要な場合、 『Redshift』に送るのが楽なのです。 ● WebApplication Log Data (FireLens, CloudWatch Logs: Amazon Data Firehose) ● DynamoDB (zero ETL) ● Amazon Aurora (zero ETL) ECS FireLens CloudWatch Logs

Kayac. Inc 具体的にはこうなる。 というわけで、

Kayac. Inc

Kayac. Inc Q: なんで、dbt Core を ECSで動かしてるん？ 謎のカヤック文脈: OSS > SaaS の技術選択になりがち。 「いざというときに、ソースコードを読めるので安心！」（ｴｯ A: アプリケーションエンジニアの管理主体に乗っかってるので、　 dbt Cloud という SaaSを使うより、dbt CoreというOSSのほうが何 故か、親和性が高かったから。

Kayac. Inc Q: これの何が嬉しい？ 専任データエンジニアが居ないという前提で、 管理主体として、Product Appのアプリケーションエンジニアチームに乗っかる関係で、 こうするのが一番理にかなってた。 A: Redshiftへのデータ取り込みが全部マネージド。

Kayac. Inc Q: Redshiftって取り扱い難しくない？ よくパフォーマンスの話とか聞くんですが、 今のRedshiftは結構、雑に使っても強い。 A: 管理主体がアプリケーションのエンジニアなので実は、 PostgreSQL互換とかそういうのも踏まえて、案外そうでもない。