Developers Summit（通称デブサミ）とは
Developers Summit（デベロッパーズサミット：デブサミ）は、2003年から毎年開催する、日本最大級のソフトウェア開発者のためのカンファレンスです。社外のデベロッパーと連携を取りながら企画を行い、ソフトウェア開発者が今知っておきたいトピックや、ロールモデルとなるデベロッパーとのさまざまな出会いを創出します。 引用元：Developers Summit（デベロッパーズサミット）
Developer Summit 2022に聴講者として参加してきました！聞いたセッションの中で、いくつかピックアップして感想をまとめていきます。
感想
デジタル庁CTOになってみた -今よりもよい10年後のために必要そうなこと [17-A-1]
グリーCTO&デジタル庁CTOの藤本さんの講演。民間と行政の開発の違いが面白かったです。
特に行政の場合は、開発PJTの期限が法律で定められていて、民間じゃ想像できないなと思いました。また、行政は税金を利用しての開発なので、その先に売上がたつわけではなく、KGI•KPI指標設計がとても重要とも。
デジタル庁では戦略を以下のページにまとめており、シンプルでわかりやすく、コンセプトとして掲げている「人に優しいデジタル化」を非常に重要視していると感じました。この構成はわかりやすいので、一度写経したいくらいです。 www.digital.go.jp
最後に藤本さんからの「いつだってなんだって目の前のソースコードの1行から」という言葉が印象的でした。
KARTE リアルタイムユーザー解析基盤のDB（450TB）をゼロダウンタイムで新DBに移行したノウハウ [17-B-5]
株式会社プレイドが提供する顧客体験プラットフォーム「KARTE」の移行ノウハウ紹介です。大量データのリアルタイム解析基盤は、ユーザーのアクションからの即時ポップアップの提示が行われているプロダクトが増えてきているので、興味がありました。またイベントストリームが今後のETLのベースになっていくのではないかという気持ちもあります。
スケールした際に現状の10倍捌けるかという観点が、ビジネススケールを意識したシステムの成長ができていて素敵だなと感じました。また移行のデータのずれの算出も、全体比較とクライアント別で割合を算出していたのは、ユーザー目線にすごく立っていると感じました。
思ったこととして、リアルタイム解析基盤を作れると、サービスに訪れた離反予測を行い、誘導リンクを変える以下の取り組みもセットでできるので、今後チャレンジしてみたいですね。 blog.tensorflow.org
マイクロサービスとデータとData Mesh - アプリは分けた。データはどうだ。[17-B-6]
Apache Kafkaの開発元のConfluent社の方の発表です。データメッシュ、イベントストリームは現在勤めているサービスの性質上、今後必要と感じているのと、まだまだ事例が少ないため基本理解の目的で聞きました。Confluent社は日本法人が昨年できたみたいで、今後のサポートも期待が持てます。
セッションの前提知識
マイクロサービス化をアプリケーション層で取り入れることで、APIベースのでの疎結合な状態にでき、ドメインごとの変更がしやすくなることや、1機能で障害が起きた場合もモノシリックな場合に比べ、サイトの可用性が高くできるというメリットもあります。 ※ 前提として、なんでもマイクロサービス化かというのは違うと思っています。
ただデータの同期は厄介で、仮にRDBのレプリケーションなどによるテーブルの同期などで、サービス間の連携を行おうとすると、疎結合というメリットが一気に崩れます。
そこでメッセージキューにデータの作成、更新、削除をイベントとして送り、利用サービス先が自分たちのタイミングで取得、利用するというのがデータの同期で求められます。中でもkafkaは、イベント保持が揮発性ではなく永続性かつ、イベントがpushではなくpullモデルのため、取得側を送信側で管理する必要がなく、スケーラビリティのメリットの恩恵を受けます。
これからの10年はData Mesh
データの中央集権管理では、各ドメインの結合を行うと、結局はデータの密結合な状態になり、依存関係が強く出てしまったり、基盤を利用するのに知識が必要になるなどの課題があるそうです。そのような課題を解決するために、Data Meshという概念が提唱されています。
参考記事 Data Meshとは何か？ – Attsun Blog
メッセージキューのデータ同期により、各ドメインのデータをデータプロダクトというサービスとして整備し、提供することで、利用側のドメインが取得を行い、前述の課題を解決することを目指したものです。メッセージキューによりスケーラビリティを担保し、データプロダクトとして扱うことでガバナンスを担保するという意図のようです。
個人的には、Data Meshを採用するには①APIで疎結合な状態、②メッセージキューでの非同期なデータ共有、③データプロダクト化、というステップがかなりハードルが高いと感じるのと、アプリケーションサイドにデータエンジニアが分散して必要になると考え、既存で事業を進めている企業で採用できるのはかなり先かつ少数と感じました。
新規のサービスかつ、ビジネススケールを期待できそうであれば、最初の設計案として入れても良いかと思います。
さいごに
デブサミに参加して良かったのは、改めてエンジニアコミュニティの素晴らしさを体感できたことです。普通の勉強会と異なるのは、事例紹介ではなく前向きであったり、今回のテーマ上未来を考える発表が多く、以下のようなセッションはとても気持ちを前向きにさせてくれました。
- あの人の自分戦略を聞きたい！2022 18-A-9
- イキイキと働くaround50／over50のシニアエンジニアが語るキャリアストーリー [17-E-9]
自分も来年か再来年は登壇枠で出てみたいです！ おしまい
