Web系OLTPにおけるデータストア技術選定の私感的史観

7.4K Views

February 26, 26

スライド概要

profile-image
スライド一覧

GitHubber, OSS作家。Tech SaaSのPdM、スタートアップ取締役CTOや外資スタートアップのIC等を経験後現職。好きな言語はGoとPerlと中国語で雑なOSSを200以上量産している。3 times ISUCON winner. 著書「みんなのGo言語」共著他。Podcast https://oss4.fun

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

slide-thumbnail

Goの野暮ったさとどう付き合うか
user-img Masayuki Matsuki 610.7K
slide-thumbnail

k1LoW/deck の紹介とチュートリアル
user-img Masayuki Matsuki 138.8K
slide-thumbnail

おこがましくオーナーシップを持つ
user-img Masayuki Matsuki 87.6K
slide-thumbnail

自己評価力を武器とする
user-img Masayuki Matsuki 77.9K
slide-thumbnail

GoでマルチプラットフォームなOSSを開発する時の注意点
user-img Masayuki Matsuki 53.2K
slide-thumbnail

自己評価力を武器とする 増補改訂版
user-img Masayuki Matsuki 33.9K
各ページのテキスト
1.

Web系OLTPにおけるデータ ストア技術選定の私感的史観 技術選定を突き詰めるOnline Conference - 逆境を乗り越える意思決定プロセス @ 2026-02-26

2.

Profile ● ● ● id: Songmu (ソンムー) (GitHubber) Masayuki Matsuki / 松木雅幸 Blog: おそらくはそれさえも平凡な日々 ○ ● ● ● http://www.songmu.jp/riji/ 好きな言語はPerlとGoと中国語 3 Times ISUCON Winner OSS作家 ○ ○ ○ 200+ OSS Developer 入門監視 付録C 執筆・「みんなのGo言語」共著者 Podcast ■ 趣味でOSSをやっている者だ #oss4fun

3.

(宣伝)このスライドは k1LoW/deckで作られました ● k1LoW/deck ○ ○ ○ MarkdownからGoogle Slideを生成するツール 私もメンテナとしてアクティブに開発に関わっています 是非ご利用下さい！

4.

前段

5.

OLTPとOLAP ● OLTP (Online Transaction Processing) ○ ○ ○ ● リアルタイム性が求めれる処理 Webサービスの裏側のデータベース 👈 今回の主題は主にこっち！ OLAP (Online Analytical Processing) ○ ○ 分析処理 いわゆるデータウェアハウス

6.

個人の現在のスタンスと技術選定 ● RDBMSをちゃんと使えば大抵のことはできる ○ ○ ● RDBMSで足りない部分をRedisで補うのは好き ○ ● list, set, sorted set, pubsubなどは便利 分析系はBigQuery使っておく ○ ● かなりのアクセスを捌ける 徒に分散したり複数のミドルウェアを併用すると逆に複雑になる この辺りは色々新しい選択肢も出てきて興味はある 参考: 最近話題のChatGPTのPostgreSQLスケーリングの話 ○ ○ この規模でも書き込みのPostgreSQLは1台 読み込み分散や、CosmosDBへの垂直(機能別)分割はしている

7.

人類はSQLから逃れられない 人類のSQLに対する愛憎 ● データアナリストやリサーチャーにとっても重要な汎用スキル ○ ● 結局多くのデータストアがSQL的なインターフェースを提供する ○ ○ ● 「英語」のような「飯の種」 後付けであったとしても NewSQLもある意味その流れとも言える 人類には置き換えが望まれるが現実的には困難な技術が存在する ○ POSIXシェル・C言語・Perl互換正規表現・SQL ■ 最近ではYAMLなど

8.

本トークの概要と構成 私が経験してきたいくつかの時代の変遷の中で、データストア選定がどのよう に変わってきたか、いくつかの切り口でお話します。 ● ● ● 分散メモリキャッシュが必須だった時代 アドテクやソシャゲにおけるKVS戦国時代 OSSのRDBMS活用の進化

9.

Web 2.0 時代 2005年頃-

10.

時代背景 ● Web 2.0とCGM ○ ○ ○ ● 業務システムのWebアプリ化 ○ ● それまでと桁が違うアクセスを捌く必要性に直面 サーバー複数台構成 可能なら安価に SIer方面 キーワード ○ ○ C10K問題 LAMP

11.

アーキテクチャーの変化 ● 3層アーキテクチャーの定着 ○ ○ ● 複数台構成が当たり前に Proxy (Web server) <-> Web App <-> DB OSSのRDBMS採用の広がり ○ ○ MySQL PostgreSQL

12.

当時のハードウェア制約 ● 32bit OSが主流 ○ ● 4GBのメモリサイズ制約 HDDが主流 ○ とても遅い 一台のサーバーのメモリにサービス全体の主要データを乗せられない。 → それぞれ2010年台中盤まではその状況が続く

13.

DBとキャッシュサーバーの併用構成 DBにコアデータを持ちつつ、キャッシュサーバーに分散 ● ● 「DBにアクセスが行ったら負け」 「swap使ったら負け」

14.

分散メモリキャッシュのアイデア ● サービス主要データを複数台のキャッシュサーバーに分散 ○ ○ ○ 永続化はおこなわない ミスヒットは許容 溢れたら使用頻度の低いアイテムを削除 (LRU) https://gihyo.jp/dev/feature/01/memcached/0001

15.

memcached (2003-) ● ● ● 高速なインメモリKVS 時限削除 (expire) 機能 シンプルで優れたmemcachedプロトコル ○ ● ● ● テキストプロトコル及びバイナリプロトコル 複数台並べてキャッシュサーバー群を構築するのがメインのユースケース サーバー側は単純でクライアント側に分散アルゴリズムを持たせる キャッシュサーバーを動的に増減でき、スケールアウトが簡単 「memcachedを使っていると大規模サービス」という雰囲気

16.

コード例 (Go) ● https://github.com/bradfitz/gomemcache のサンプルそのまま ○ コンストラクタに複数台のサーバーを指定

17.

memcachedはソフトウェア設計の宝庫 ● Slabアロケータ ○ ● Consistent Hashing ○ ● 分散アルゴリズム プロトコル設計 ○ ● メモリ内に効率良くアイテムを格納するアルゴリズム シンプルなテキストプロトコル・バイナリプロトコル LRU (Least Recently Used) アルゴリズム ○ キャッシュが溢れたときに使用頻度の低いアイテムを削除するアルゴリズム

18.

動的なキャッシュサーバー増減の実現 ● ● ● Consistent Hashing キーのハッシュ値に基づき、配置memcachedサーバーを決定するアルゴリズム サーバーの増減に伴うキャッシュの再配置を最小限に抑えられる ○ 第4回 キャッシュサーバー群をスケールさせやすい memcachedの分散アルゴリズム | gihyo.jp

19.

利用局面の変化 (2015年頃- ) 分散キャッシュとしてのmemcachedの利用局面の低下 ● ハードウェア性能向上 ○ ● ● コミュニティでのRDBMS設計ノウハウの成熟 RDBMSを適切にチューニングすれば十分な性能が出るように ○ ● ● ● 64bit OSやSSDの普及 OSのファイルキャッシュやDBのメモリバッファで十分なケースが増えた Redisの台頭 (後述) Google CloudのMemcachedの非推奨化 マルチコアが使え、シンプルで高速である利点は健在 ○ Netflixはヘビーに使っているしスポンサーしている

20.

学びと小まとめ ● ● 技術の進歩により複雑なアーキテクチャを取らなくて良くなった話 後で少し触れるが、DBのシャーディングなども同様の現象があった

21.

(余談) Brad Fitzpatrick 氏 (bradfitz) / memcached作者 とてもかっこいい ● ● ● 10代でLiveJournal起業 -> Six Apartに吸収 Googleで主にGoのhttpパッケージ周りの開発 2019年に Tailscale を起業 Coders at Workに若かりし頃のインタビュー → みんな読もう

22.

アドテクやソシャゲにおけるKVS 戦国時代 2010年前後-

23.

時代背景 アドテクのハイスループット (2010年前後-) ● ● memcachedは優れていたがメモリキャッシュのみ memcachedに近い使い勝手で永続化機能を持つKVSも求められた ○ ● 特にアドテクでは高速に堅牢にデータを読み書きする需要があった ○ ● レプリケーション機能も システムのメインのデータストレージとしての利用 ソシャゲでも同様の需要

24.

memcached互換にする意味 ● ● ● memcachedプロトコルはとてもシンプルでサーバー実装しやすい クライアント側も既存のライブラリを流用できる memcached互換のKVSが数多く登場した

25.

様々なKVS ● Kyoto Tycoon / Kyoto Cabinet (2009-) ○ ● Couchbase (2012-) ○ ○ ● ● 後述 memcachedプロトコルでも通信可能なドキュメントストア 余り聞かれなくなったが世界的には今でもそこそこポピュラーなはず cybozu/yrmcds (2013-) gree/flare (2008-)

26.

MySQLのKVS的活用 ● mycached (2009-) ○ ● Innodb memcached plugin (2013-) ○ ● MySQL に memcached プロトコルサポートを追加してみる - kazuhoのメモ置き場 MySQL :: MySQL 8.0 Reference Manual :: 17.20 InnoDB memcached Plugin HandlerSocket (2010-) ○ GitHub - DeNA/HandlerSocket-Plugin-for-MySQL: HandlerSocket is a NoSQL plugin for MySQL

27.

Kyoto Tycoon / Kyoto Cabinet (2009-) ● ● ● ● 平林幹雄氏によるKVS / KVSサーバー Tokyo Cabinet / Tokyo Tyrant (2006-) の後継 ディスク永続化とレプリケーション機能を備えたmemcached互換KVS 日本のアドテク界隈で広く使われた ○ ● DBM(ファイル)実装とサーバー実装が分離された設計 ○ ● 堅牢なセッションストレージとしても CabinetがそれぞれDBM実装で、Tyrant, Tycoonがサーバー実装 メンテナンス体制などもあり徐々に使われなくなった

28.

tkrzw (2020-) 平林幹雄氏の最新作 ● https://dbmx.net/tkrzw/ ○ ● ブログ記事がとてもおもしろい ○ ○ ● https://github.com/estraier/tkrzw DBMの設計と実装 その0 全体の計画 - 豪鬼メモ データベースライブラリTkrzwの初版リリース - 豪鬼メモ 多分商用サービスで使われてはいないと思う

29.
30.

Redis (2009-) ● ● ● 2010年代中旬以降に大きく台頭 memcached互換ではなかった 単なるKVSではなかったところに強み ○ ● 様々なデータ型の格納 ○ ○ ● 単なるKVSは最早それほど必要とされていなかった "in-memory data structure store" プログラミング言語内のデータ構造を近い形で格納できる Sidekiqなど有力な実用例

31.

(余談) RedisとISUCON ● ISUCON 2 (2012年) のfujiwara組優勝時に一躍注目を浴びる ○ ○ ● ● Redis布教活動報告 ISUCON 編 - unknownplace.org typester氏: "最近の趣味は？っていう問いにはだいたいRedisのソースを読むことです" 国内だとまだベンチマーク記事くらいしかなかった ちなみにISUCON 5でもfujiwara組で優勝 ○ そのときは予選ではRedis, 決勝ではmemcachedを使った

32.

(余談) Salvatore Sanfilippo氏 (antirez) / Redis作者 ● 思想的に共感出来る部分も多く、ブログが面白い ○ ○ Don't fall into the anti-AI hype - antirez English has been my pain for 15 years - antirez

33.

学びと小まとめ ● ● 筋の良い設計も時代の変化と共に拘る必要がなくなることも 優れた技術が生き残るわけではない ○ ● 普及の努力も大事 定番に乗る技術選定

34.

参考: オープンソース開発者がDeNAを選ぶ理由 kazuhoさん作の先行実装のmycachedが余り使われず、DeNAの樋口さんが開発した 後発のHandlerSocketの方が使われるようになった逸話

35.

OSSのRDBMS隆盛 堅牢なRDBMS開発の必要性の向上 (2010年頃-)

36.

時代背景 世の中の要求や機能下地の確立 ● ● ソーシャルゲームバブル キーバリューストアの延長的な使い方から設計を意識するように ○ ● 意識せざるを得ないように OSSのRDBMSの機能充実 ○ ○ MySQLへのトランザクション機能 PostgreSQLのレプリケーション機能

37.

MySQLとPostgreSQL ● Web系システムではMySQL人気 ○ ○ ○ ● 高速で分散しやすい 主にKVS的な用途 特にMySQL4.0 / MyISAM時代 SIerではPostgreSQL人気 ○ ○ SQL機能の充実 商用RDBMSからの乗り換え需要

38.

LAMP構成 200X年代にWebサービスを構築する際の定番OSS技術スタック ● Linux/Apache/MySQL/P言語 ○ ● Perl, PHP, Python, Ruby "LAPP" という言葉はたまにつかわれていたくらい ○ それくらいにはMySQLが世界的にも人気だった

39.

(余談) LAMPの起源 https://ja.wikipedia.org/wiki/LAMP_(%E3%82%BD%E3%83%95%E3%83 %88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%90%E3%83%B3%E 3%83%89%E3%83%AB) この起源は、1998年にドイツのコンピュータ雑誌 であるC'tにてミハエル・クンツェ (Michael Kunze) が提唱したのが始まりである。

40.

(余談) シャーディング ● ● 書き込みヘビーなアプリケーションをスケールさせる要求 読み込みヘビーなだけならキャッシュで逃げられたが ○ ● ゲームは書き込みヘビー 当時はシャーディング前提でDB設計されることも ○ ハードウェアの進化と共に必要性が薄れていった

41.

MySQLが好まれた理由 ● ● ● ● ● スケールアウトの容易さ 高速なフェイルオーバーの実現 運用ノウハウやエコシステムの充実 メッセージングパイプラインとしての活用 比較的ちゃんとしたDB設計が可能 (MySQL 5.0 以降)

42.

MySQLが好まれた技術的要素 ● ● ● ● ● ● レプリケーション 高速なコネクション確立 MHAなど運用ツールの充実 パーティション ストレージエンジン差し替え InnoDBにより比較的堅牢な設計が可能に

43.

レプリケーション 冗長構成とリアルタイムな切り替え処理を実現するために必須。 ● MySQLのキラー機能 ○ ● 2000年（MySQL 3.23.15以降）から存在 PostgreSQLは 9.0 (2010年) 以降サポート開始 ○ 10年遅れ MySQLはDBダウン時にリアルタイム切り替えができたが、PostgreSQLはバッ クアップからレストアするしかなかった。

44.

割り切った非同期レプリケーション ● ● ノード間のデータ整合性を保つというより単なるデータリレー データ不整合を意図的にも作り出せる ○ ○ ○ ● レプリカではDDLやインデックスを変える ストレージエンジンを別の物を使う バージョンを変える ■ バージョンアップに利用 数珠繋ぎにも ○ 複雑なメッセージングパイプラインを構築可能

45.

高速なコネクション確立と都度接続 ● MySQLはDB接続が高速だった ○ ○ ● MySQLはスレッド PostgreSQLはプロセス WebAPP・DB間はユーザーリクエスト毎の都度接続でも問題ない ○ ○ コネクションプール不要 ■ ステートレス 特に「同一DC」内であれば

46.

都度接続のメリット ● コネクションプール管理不要 ○ ● CGI的なステートレスなアーキテクチャと相性が良い DBフェールオーバー時に高速な切り替えが可能 ○ DBコネクションが腐らない

47.

MHA (Master High Availability Manager and tools for MySQL) https://github.com/yoshinorim/mha4mysql-manager ● MySQLで冗長構成を組む際のフェイルオーバーを自動化 ○ ○ ● DeNA社などはダウンタイム削減をカリカリにチューニングしていた ○ ○ ● Primaryダウンの際、十数秒程度でSecondaryをPrimaryに昇格 世界中で使われるキラーソフトウェアだった これが逆にパブリッククラウド移行の足枷にもなったとも クラウドのRDBMSのフェイルオーバー機構がそれほど高速ではなかった 作者の松信嘉範氏はDeNA所属後Facebook社へ(2012-)

48.
49.

ストレージエンジン MySQLはSQLレイヤーとストレージエンジンが分離されており、ストレージ エンジンが柔軟に差し替えられる設計になっている。 ストレージエンジンはテーブルごとに変更可能。

50.

代表的なストレージエンジン ● InnoDB ○ ○ ○ ● 現在の標準ストレージエンジン MySQL 5以降で導入が進み 5.5で標準に (2010) トランザクションサポート MyISAM ○ ○ MySQL 4以前の標準ストレージエンジン テーブルロックのみでトランザクション非サポート

51.

その他ストレージエンジン ● Blackhole ○ ○ ● データを記録しないストレージエンジン レプリケーション用のbinlogは記録する ■ 複雑なレプリケーションを組む際に利用することも Spider ○ 複数ノードに分散してデータを配置するストレージエンジン

52.

「MySQLはKVSである」という言説 ● ● LAMP全盛期の200X年代の残滓 トランザクションが無いものの、高速で比較的堅牢なデータの入れ物とし て重宝された時代 ○ ● 今ではInnoDBを使うのが当たり前になりそれなりのRDBMSとして使える ようになった ○ ● 不十分な道具でやりくりしていた時代の複雑な感情の発露 PostgreSQLに比べると機能面で劣る部分も多いが この辺りはMySQL 5以降から入ったかどうかでスタンスの違いがありそ うに思う

53.

Q4M (2007-) ● ● ● ● Q4M - a Message Queue for MySQL MySQLでメッセージキューを実現するストレージエンジン 奥一穂氏作 当時日本のWeb系企業で広く使われた

54.

ストレージエンジン機構の功罪 ● 柔軟なストレージエンジン機構はMySQLの大きな特徴であり強み ○ ○ ● ● AWSがAuroraをMySQL互換から開発したのもその機構故に実装しやす かった可能性 ただ逆に今は足枷になっている可能性も ○ ● データパイプラインフレームワーク的な活用もできた 今だったら、専用のメッセージブローカーを使えば良いよねという話もある 密結合になっていた方がデータ制約などは実現しやすい 今は実質InnoDBほぼ一択 ○ 各パブリッククラウドのMySQL互換エンジンは差し替え機構を提供していない

55.

パーティション ● DBテーブルを内部的に複数に分割する機能 ○ ○ ● 大容量テーブルに対するクエリの高速化を実現 ■ 高速な読み込みや消し込み 大規模サービスで重宝する機能 これもMySQLの方がサポートが速かった ○ ○ MySQL 5.1 (2008- ) PostgreSQL 10 (2017-)

56.

パーティションの現状 ● ● 今はPostgreSQLでも実績がある PostgreSQL 11 (2018-) 以降、パーティションテーブルへの外部キー制 約がサポート ○ 機能面でMySQLを上回る

57.
58.

PostgreSQL優位の流れ 何故MySQLの新規採用は減ってきているように見えるのか 以下のような理由があるのではないかと個人的に考えている。 ● ● ● クラウド化が進み運用優位性での差別化が少なくなった コミュニティエコシステムや開発体制 機能優位性

59.

クラウド化の影響 アーキテクチャ上のMySQLの優位性が余り活きなくなった ● 冗長性やフェイルオーバー機能 ○ ● ステートレスな都度接続アーキテクチャー ○ ● → パブリッククラウド上では機能差はなくなった → 「同一DC」という前提が崩れ、コネクションプール管理必須に 柔軟なストレージエンジン ○ → そもそもパブリッククラウドでは差し替えできない ■ 能力を制限されているとも

60.

コミュニティエコシステムや開発体制 ● 2010年頃以降から世界的にはPostgreSQLの方が好まれるように ○ ○ ● RailsがPostgreSQLを優遇するように ○ ○ ● 堅牢で複雑なシステム構築に適しているという風潮 (この辺りは日本と海外で風潮が違っていたかも) Heroku標準のDBがPostgreSQLだった kamipoさんが後追いでMySQLサポート頑張っている OracleによるMySQL買収やMariaDBへの分岐等の混乱 ○ ○ これは正直個人的には余り影響を感じていない OSS開発がコミュニティ主導、企業主導かどちらが良いかは一概には言えない

61.

PostgreSQLの機能優位性 本来のDB機能の優位性にMySQLが押し負けてきている。 ● ● ● ● ● ● ● Row Level Security DDLがトランザクションに含まれる UUID型 マテリアライズドビュー ベクトル演算周り パーティションなどもPostgreSQLが優位になってしまった … etc.

62.

今個人的には新規ではPostgreSQLを選ぶ ● ● MySQLにはお世話になったので残念にも思う クラウドベンダ固有のデータストアの採用はまだ積極的ではない ○ いくつか使ったことがあり、便利さはとてもよく分かるが

63.

まとめ データ重要

64.

時代の流れによっても「正解」は変わる ● 技術の正常進化故の淘汰もあるが、不可抗力的な偶然の変化も実は多い ○ ○ ● 誰が作ったか・誰がメンテナンスしたか・誰が使ったか・誰が普及に尽力したか この辺りの掛け違いで全く異なる未来になった可能性もある その場その場で手堅い選択をしつつ変化させていくことが大事 ○ 昔の「当たり前」に固執しないこと

65.

データ設計重要 ● データの読み書き速度はユーザー体験に直結する ○ ● いい感じに隠蔽してくれるNewSQL等のデータストアも増えたが ○ ● 裏側の工夫を想像することも大事 AIだって物理法則はねじ曲げられない ○ ○ ● どこにどのようにデータを置くか 光の速度やストレージ追記速度などは変えられない ハードウェアの進化はある 「プログラミングの中心はアルゴリズムではなくデータ構造」by Rob Pike ○ ○ アルゴリズムはAIが書いてくれる データ構造と計算量の理解が大事

66.
67.

取り上げなかった話 懇親会来る方は話しましょう！ ● ドキュメントストア ○ ● ● ● ● ● Mongo / DynamoDB オブジェクトストレージ / S3 列指向DB libevent / libev / libuv 仮想化・クラウド化の影響 Fusion-io