はじめに
こんにちは、価格.com開発本部のしがない新卒2年目エンジニアです。
昨年夏に引き続き、国内最大級のソフトウェア開発者向けカンファレンスである、Developer Summit 2025（通称:デブサミ）の参加レポートをお届けします。今年はホテル雅叙園東京を会場として、2月13日から14日の2日間にかけて開催されました（私は1日目のみ参加しました）。 今回も新人エンジニアなりの視点で、デブサミ2025の内容を共有させていただきます。
まず最初に、私が特に注目した話題であるNewSQLについて重点的に紹介し、次にサブトピックとして、新しいデータベースアーキテクチャであるHTAP、バックエンドエンジニアの視点で解説されたフロントエンド入門についても少しだけ触れさせていただきます。
『NewSQL ― 統合と分散の螺旋』
デブサミでの講演タイトルは『データベースの新潮流 ～NewSQLとHTAPを中心に～』(02/13 10:00 ～ 10:40) です。詳しい発表資料はコチラをご覧ください。
NewSQL以前のデータベース
大きな枠組みとして、データベースには二つのモデルが存在していました。一つには、スキーマ定義・ACID保証・SQLサポート等を備えたリレーショナルデータベース（RDB）です。50年余の歴史を持つDB界の大御所ですが、近年のビッグデータ需要などから、その拡張性（スケーラビリティ）の限界が課題とされているようです。
そんなRDBとは対照的に、スキーマレス・ACID保証なし・SQLサポート無しではあるが、水平方向にスケーラブルなデータベースが、2010年代から登場したNoSQLです。NoSQLのスケーラビリティは大きな魅力ですが、RDBのトランザクション管理のような機能を持ち合わせていないため、あくまでRDBの補完的な存在に落ち着いているとのことです。
NewSQLの特徴
さて、今回のテーマであるNewSQLは2020年前後から頭角を現し始めましたが、実はその名前とは裏腹に、特に新しい要素があるわけではないようです。端的に言えば、RDBとNoSQLの良いとこどり。つまり、RDBを土台としたデータの整合性を保つ仕組みと、水平方向にスケーラブルな仕組みを両立した分散データベースシステムということだそうです。
※Developers Summit 2025の資料 | Mick's Page（ミック）1を基に作成
リーダー選挙
RDBをベースにしつつ、スケーラビリティを実現する方法とはどのようなものなのでしょうか？実際の講演ではNewSQLの複雑なアーキテクチャについて説明されていましたが、このレポートではNewSQLにおいて肝となるリーダー選挙のアルゴリズムをピックアップして紹介します。
リーダー選挙では、複数のデータベースがリーダー役とフォロワー役に分かれます。クライアントからリクエストを直接受けるのはリーダーのみで、リーダーはデータの書き込み処理を全てのフォロワーに指示します。
障害のボトルネックとなるのがこのリーダーなのですが、フォロワーたちは常にリーダーを死活監視しているため、リーダーが一時的にダウンした場合には、フォロワー同士で即座にリーダー選挙が開始され、最新のログを持つフォロワーがリーダーに置き換わるという仕組みが備わっています。
リーダー選挙により、更新処理の負荷分散が可能になり、NewSQLの分散データベースシステム実現に繋がっているとのことです。比較的簡素なアルゴリズムであるということから、NewSQLの普及に一役買ったとのことです。アルゴリズムの詳細については、原論文2をご参照ください。
※『センスの良いSQLを書く技術』(ミック/KADOKAWA)3を基に作成
国内のユースケース
講演では、実際にNewSQLを採用している国内企業のユースケースについて紹介されていました。
Spanner
SpannerはGoogle Cloud Platform上で提供されるNewSQLです。東京と大阪の両現用構成で展開するという国内マルチリージョンが大きな特徴だそうです。国内初のデジタルバンクとされる、「みんなの銀行」が採用しています。
TiDB
MySQL互換のため、日本で特に人気のあるNewSQLがTiDBです。PayPayが2019年から取引履歴処理に採用しており、 翌年には決済フローにも導入を進めました。更新系トランザクションのスループットが大きく向上したようです。
また、DMM.comは異種混合DBの統合としてTiDBを採用しています。 従来はRDBとNoSQLが混在していたような運用携帯でしたが、その双方をTiDBで置き換えることにより、運用効率が劇的に向上したとのことです。NewSQLが、RDBとNoSQL双方の特徴を持ち合わせているからこそ実現できる統合ということで、大変興味深いユースケースでした。
課題
ここまでNewSQLの利点ばかりを並べてきましたが、当然デメリットも存在します。
一つ目は、NewSQLは分散データベースシステムであるため、レスポンスタイムが悪化しやすいということです。二つ目は、新技術であるため、そもそも製品自体の価格が高かったり、既存製品と比較して情報が乏しいことから導入・運用コストが嵩みやすいという点が危惧されているようです。
NewSQLに限らず、最新技術に関してはついついメリットばかりに着目しがちだと思います。 導入の決定権あるなしに関わらず、「もし当社で採用するとしたら、どのようにこれらの課題を解決できるだろうか？」と、戦略をイメージしていくことが、一人のエンジニアとして重要な姿勢なのではないかと感じました。
『HTAP ― スーパーデータベースの夢』
先ほどの講演『データベースの新潮流 ～NewSQLとHTAPを中心に～』(02/13 10:00 ～ 10:40) でNewSQLの次に紹介されたトピックです。詳しい発表資料はコチラのp27以降をご覧ください。
企業のデータベースには大きく分けて二種類が存在します。一つは、業務の中心を担う基幹系、もう一つがデータの分析や社内ツールなどに利用される情報系です。基幹系と情報系は障害が発生した際のリスクが大きく異なるため、これら二つのデータベースは、アーキテクチャとしては分離することが長らく原則とされてきたそうです。
ところがHTAP（Hybrid Transactional and Analytical Processing）がこの常識を覆しました。基幹系と情報系を統合し、基幹系が持つ確報性と、情報系が持つ速報性を両立した運用を可能としているようです。（実現に至る具体的な技術については、上記資料をご参照ください。）
具体的なユースケースとしてはリアルタイム分析が顕著で、製造業における製品の在庫数に基づいた需要予測、金融取引における犯罪行為の検知などが挙げられていました。
現在の自分にとってはそれほど身近なトピックではありませんでしたが、価格.comにおいても、基幹系と情報系のデータベースはそれぞれ存在するという話を聞いたので、今後の業務で現状の運用形態について理解を深めていきたいと思います。
※Developers Summit 2025の資料 | Mick's Page（ミック）4を基に作成
『バックエンドエンジニアのためのフロントエンド入門』
『バックエンドエンジニアの為のフロントエンド入門』(02/13 17:00 ～ 17:40) では、オブジェクト指向と比較しながら、フロントエンドにおけるコンポーネント指向の考え方が解説されていました。詳しい発表資料はコチラをご覧ください。
実はこの講演、単にコンポーネント指向を説明するだけの時間ではありませんでした。既に自分が持っている知識や考え方を活用して、新しい知識を上手く吸収していくこと。そして、そのため学習に費やすコストは資産と考えるべき（学習資産）だということが強調されていました。
私はコンポーネント指向はおろか、オブジェクト指向すらまだまだ理解できていませんが、講演を通して、一見全く異なる枠組みの知識についても、共通点や相違点を見出すことの面白さに気が付くことができました。 また、「学習資産」の概念は一生を通じて大事にするべきマインドであると思いました。
おわりに
今回のレポートでは、NewSQLの話題を中心にデブサミ2025の講演をいくつか紹介してまいりました。
昨年夏のイベント参加時と比較すると、自分が理解していること・してないことの区別がハッキリしてきたため、インプットできる情報が多かったです。
当社のサービスに関連する技術であるか？現実的に採用可能な技術であるかどうか？などはさておき、現在のトレンドや他社の動向などを少しでも把握しておくことによって、ITニュース等の情報に対するアンテナの張り方が大きく変わることを実感しました。
今後の業務における自分の宿題を発見するキッカケとなる、非常に貴重な体験となりました！
カカクコムでは、ともにサービスをつくる仲間を募集しています！
カカクコムのエンジニアリングにご興味のある方は、ぜひこちらをご覧ください！
