ブログ@nnaka2992

データベースってなんだよ

AIを使うのは当たり前になったけど、AIを使いたくないときがある

zatu

ChatGPTが最初に発表されたときに比べ、生成AIはいわゆるハルシネーションも減ればコーディングも得意になり、情報の調査から整理まであらゆる用途で実用的になりました。

普段のくだらない疑問をSNSに垂れ流していたのが、雑にChatGPTに聞くようになりました。 少し真剣に考えたい仕事のトピックや会社の情報を入れる時には、取り敢えずGeminiに意見を求めることも少なくありません。 コーディングにいたっては速さも質も私ではClaudeに勝てなくなりました。

そんな便利な生成AIですが、自身のキャリアや目標、解釈ではなく理解したい技術を学ぶときは安易に生成AIを利用したくないと思っています。 生成AIを利用することでインスタントにそれらしい出力を得ることができますが、よく語られるようにその質は現時点のインプットに従属します。

キャリアや目標のような自分の中にしか答えがなく、向き合い磨くことでしか良くならいものがあります。 こういったトピックに生成AIを利用すると短期的にそれらしい出力を得られますが、頭の片隅にしかない小さなアイデアの種は簡単に押しのけられてしまいます。

うわべではなく、真に理解したい論文や技術を生成AIに頼ると、理解ではなく解釈に逃げてしまい、要約の周りにある削ぎ落とされた情報を自分のものにすることができません。

生成AIが幅を利かせるようになるまでは、アウトプットこそ至高でアウトプットこそ正義と考えていました。 最近は生成AIを使って言葉することで消えてしまう考えや、言葉にすることでこぼれ落ちてしまうアイデアの輪郭にこそ価値があるのではないかと思うようになりました。

言葉にすれば消えちゃう関係なら言葉を消せばいいやって思ってた 恐れてただけど あれ? なんかちがうかも

曲名 恋愛サーキュレーション

作詞 meg rock

作曲・編曲 神前 暁 (MONACA)

歌 千石撫子(CV:花澤香菜)

一昔前のオタクが大好きな恋愛サーキュレーションの真逆だなと思った冬の日です。

2025年の振り返りをする

みんな振り返りしてる。振り返りしてないのはお前だけ。

なので振り返りします。

アウトプットログ

2025-1-24 3-shake SRE Tech Talk #11 オンサイト 新春OSSスペシャル 登壇

2025年の外部発信はじめは所属会社である株式会社スリーシェイクの主催するイベントでした。

CloudNativePGがCNCF Sandboxプロジェクトになったぞ！ 〜CloudNativePGの仕組みの紹介〜

https://speakerdeck.com/nnaka2992/cloudnativepggacncf-sandboxpuroziekutoninatutazo-cloudnativepgnoshi-zu-minoshao-jie

OSSスペシャルということでPostgreSQL関連のツールとして初めてCNCFプロジェクトに認定されたCloudNativePGがどのように動作しているかを掘り下げました。 今年もですがここ数年は毎年、年末のセールにProxmox VM用ミニPCを購入してお家Kubernetesのセットアップをすることがルーティーンになりつつあります。 そのため毎年12月から翌年4月ごろまで、DB on Kubernetesのモチベーションが高くなります。この登壇もその影響のひとつで3月ごろの登壇まではCloud Native PGに関するブログが続きました。

2025-02-19 Jagu'e'r Cloud Native #17 ハイブリッド Meetup 登壇

続くアウトプットも年末から続く個人的CloudNativePGブームに影響されたものです。 Google Cloud関連のコミュニティであるJagu'e'rのCloud Native分科会が主催のというイベントでの登壇です。

CloudNativePGを布教したい~敵「なぜCloud SQLがあるのにKubernetesでPostgreSQLをホストするのか？」~

https://speakerdeck.com/nnaka2992/cloudnativepgwobu-jiao-sitai

テーマは「推しの CNCF プロジェクトを紹介するぜ LT」と言うことで当然のごとく、CloudNativePGの話をしました。 CloudNativePGの特徴とデプロイ方法をともに、マネージドデータベースではなくなぜセルフホストするデータベースを選ぶのかを言及しました。

2025-02-20 Kubernetes Novice Tokyo #36 登壇

Jagu'e'r Cloud Native #17 ハイブリッド Meetupから開けて翌日の登壇でした。 同僚の@bells17_さんが運営に参加するイベントです。

データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る

https://speakerdeck.com/nnaka2992/detabesunooperetadearucloudnativepggastatefulsetwoshi-wanaili-you-nipo-ru

2025年前半は1か月1.5回という異常な登壇モチベーションがあったため、脊髄反射で登壇申し込みをした結果、連日の登壇になり自分の首を締めた記憶がつよいです。 発表内容としてはStatefulSetという便利なKubernetesリソースがあるにも関わらず、なぜCRDでPodとPVCを管理するのかについて解説しました。

2025-03-09 Jagu'e'r オブザーバビリティ分科会 Meetup#1 登壇

Google Cloud関連のコミュニティであるJagu'e'rのオブザーバビリティ分科会が主催のというイベントでの登壇です。

Google Cloudとo11yで実現するアプリケーション開発者主体のDB改善

https://speakerdeck.com/nnaka2992/google-cloudtoo11ydeshi-xian-suruapurikesiyonkai-fa-zhe-zhu-ti-nodbgai-shan

Cloud SQL x Cloud Trace x OpenTelemetryという軸でアプリケーションのパフォーマンスをデータベースと透過的に見ましょうというはなしをしました。 始めてでDBREについて登壇してから一環してデータベースエンジニアの手からデータベースを話し、アプリケーションエンジニアがデータベースエンジニアと同じ程度にデータベースへのモチベーションをもってほしいという気持ちがあらわれた登壇した。

2025-03-11 Google CloudのTerraform職人が失職する機能が出てしまった…… ブログ

2025年の数少ないブログ投稿の一つです。

Google CloudでIaCをGUIで手軽に管理するためのツールの紹介をしたブログです。 現時点ではまだまだ自分の方が上手くIaCでGoogle Cloudを管理できると自身を持っていえるものの、昨今発展の目覚ましい生成AIがこの機能に本格的に統合されたら飯の食い扶持が一つ減ってしまうと危機感を覚えます。

2025-03-27 第52回 PostgreSQLアンカンファレンス@オンライン 登壇

JPUGが主催するアンカンファレンスでの登壇です。

データベースエンジニアの仕事を楽にする。PgAssistantの紹介

https://speakerdeck.com/nnaka2992/tetahesuensinianoshi-shi-wole-nisuru-pgassistantnoshao-jie

生成AIというものが本格的に使えるかも？ という世間の雰囲気にあてられて調査したツールでした。 PgAssitsantというWebベースのツールを通して、PostgreSQLの調査に必要なデータを収集し、必要に応じて生成AIで分析を行うというツールです。 はてブか何かに「楽にするではなく、奪うでは？ 」というコメントがあり、この程度で奪われたらもっと楽に仕事できているわと思った記憶があります。

2025-04-17 Google Cloud Next 2025 データベースRecap ~データベース関連の全41リリースを紹介~ ブログ

自社ブログでのアウトプットです。

2025年のGoogle Cloud Partner Top Engineerとして2025年4月にラスベガスで開催されたGoogle Cloud Next 2025で発表されたデータベース関連のリリースをまとめて紹介したブログです。 個人としても始めての海外カンファレンスの参加で、非常にモチベートされた記憶があります。

2025-04-24 Next × Jagu'e'r アフターイベント「Next 2025 Big Thing」 登壇

上記と同様にGoogle Cloud Next 2025のアウトプットの一つで、Jagu'e'rが主催するイベントのアフターイベントです。

Google Cloud Next 2025 DM Recap ～DM領域PTEが贈る注目リリース～

https://speakerdeck.com/nnaka2992/google-cloud-next-2025-dm-recap-dmling-yu-ptegazeng-ruzhu-mu-ririsu

データベース領域のGoogle Cloud Partner Top Engineerからの注目リリースを紹介しました。

2025-05-14 【技術選定を突き詰める】Online Conferenc​​e 2025 登壇

Findyが開催する技術選定を突き詰めるというテーマのカンファレンスの公募LT枠での登壇です。

データベースの技術選定を突き詰める ～複数事例から考える最適なデータベースの選び方～

https://speakerdeck.com/nnaka2992/detabesunoji-shu-xuan-ding-wotu-kijie-meru-fu-shu-shi-li-karakao-eruzui-shi-nadetabesunoxuan-bifang

データベースをどう選ぶか？ さまざまな要求があるときに、本当にその要求は必要なのか？ を問いかけ、難易度があがりやすい制約を外すことで、よりシンプルで現実的な選択肢を選ぼうという内容です。

2025-05-22 JPOUG Tech Talk Night #13 登壇

JPOUGが主催するテックトークイベントでの登壇です。

ついに国内でも使えるようになる！～Oracle Database@Google Cloudの紹介～

https://speakerdeck.com/nnaka2992/tuiniguo-nei-demoshi-eruyouninaru-oracle-database-at-google-cloudnoshao-jie

Google Cloud Next 2025で日本のリージョンでOracle Database@Google Cloudが利用できるようになるというアナウンスにモチベートされた内容でした。 Oracle Cloud InfrastructureやAWSではなく、なぜGoogle CloudでOracle Databaseがつかえることが魅力的なのかというテーマを主題でした。

2025-06-06 Oracle Database＠Google Cloudの紹介～ついに日本のリージョンも使えるようになったぞ！～ ブログ

自社ブログでのアウトプットです。

Oracle Database@Google Cloudとはどのようなサービスなのか？ から始め、実際にどのようにデプロイできるのかを手順書チックに紹介したブログです。

2025-06-30 Gemini Code Assist for GitHubでPrisma ORMのデータモデリングをレビューする ブログ

自社ブログでのアウトプットです。

Gemini Code Assist for GitHubを利用することでPrisma ORMのデータモデリングをレビューする知見についてまとめたブログです。 いまではGoogleはGemini CLIにのりかえてしまったようで残念ですが、このブログで紹介した内容はほとんどの生成AIツールに応用可能です。

2025-08-06 Google Cloud Next Tokyo 2025のパートナーブースで登壇

資料としては公開していませんが、Google Cloud Next Tokyo 2025の自社ブースにて、Gemini Code Assistを利用したデータベーススキーマのPRレビューについて紹介しました。

上記ブログのPrismaという軸から一般的なデータベーススキーマに焦点をひろげて紹介しました。

2025-10-31 月末 Tech Lunch Online#6 - Google Cloud を語る！- 登壇

2025年の登壇収めは非常にはやく、10月でした。 こちらもJaguerが主催するイベントでの登壇で、Spannerとコストという軸を深掘りしました。

Spannerのコストが高いの真意に迫る~ Spannerのコストの何が高いのか？ ~ ※ 無精のため資料非公開。そのうち公開します。

よく高いといわれるSpannerですが、コストベースでみればそこまで高くありません。 そんな中でイメージで語られるSpannerのコストを正確に判断するための観点を紹介しました。

2025-12-16 PostgreSQLのインデックス作成におけるパラメータの影響の調査 ブログ

自社とPostgreSQLのアドベントカレンダーでクロスポストしたブログ記事です。

仕事でPostgreSQLのインデックス作成パフォーマンスを説明するために、適切な資料がなく困ったため、今後困らないために記述したブログといっても差し支えないです。

2025-12-31 SREとPlatform Engineeringの交差点としてのデータベースエンジニア ブログ

自社のアドベントカレンダーにポストしたブログです。 31日にポストしていますが、アドベントカレンダーです。

DBREとして仕事している中でDBRE/SREのプラクティスだけでは不足するデータベースエンジニアが本来行うべき仕事をカバーできないという課題から、常々考えておりまた業務の中でとりくもうと試行錯誤している内容をブログとしてアウトプットしたものです。

その他、おしごとのことなど

今年はマネージャーだったりカンリショクだったり、ピープルマネジメントだったりと呼ばれるロールにチャレンジしました。 いまだにどうすればいいか別らないことは多いものの、マネージャーはこういうことを考えて発言していたのか？ など様々な学びはありました。

また昨年に引き続き、Google Cloud Partner Top Engineer 2026に選出されました。昨年は数人いたデータベース領域の選出者も今年は私だけになってしまい、非常に残念です。

まとめと来年の抱負

今年は竜頭蛇尾としかいいようのない一年でした。通年では16件と月一回以上のペースでアウトプットできたものの、そのほとんどは上期にかたよっており、下期は6件程度でした。 来年は上期で息切れしないように継続的なアウトプットを目標としたいです。 また今年はアウトプットに偏ってしまったという印象もあるため、来年はもうすこしインプットを増やしたいものです。

外向けに話すときは相手のメリットを話そう

zatu

お仕事をしているとチームや自分の周りで合意を取ったことを、相手にお願いしに行くことが多々あります。

例えばピープルマネジメントのマネージャー層でxxというやり方を試していきたいと合意をとったものを、相手にお願いしに行くこと。 例えば自分たちの担当範囲の決め事で、相手に協力をお願いしに行くこと。 例えば自分たちのシステムと他システム間の決め事で、こちらの方針を相談しに行くこと。

自分たちの決め事を相手に協力してもらうことはよくあります。 方針を固めるまでにディスカッションを重ね、自分たちにどのようなメリットがあるかは詳細に話すでしょう。 自分たちの考えやメリットも詳細に説明できるでしょう。

では相手のメリットはどうでしょう？ 自分の考えやメリットの説明で終わってはいないでしょうか？ 相手のアクションが必要なとき、ポジションティブに動いてもらうには相手の動機が重要です。 相手にメリット考えて貰うより、発案者から提案したほうが心象も良くなります。

要は相手の立場を考えましょうの一側面です。 相手と話すときは相手の立場を考えましょう。

自分ばっかり大変と思ってるときは気をつけたほうがいい

zatu

仕事をしていて数年ほどたつと自分はこんなに頑張ってるのに評価が低いと思うタイミングが来る。 これは後々そんなことはなかったと気がつくものの、そのタイミングにいる間は不適当な評価を受けていると思いがちで、自尊心が肥大しがちである。

自分ばっかり頑張っていると感じたときは、自分の仕事が本当に価値を生んでいるのかという観点に立ち返ったほうがいい。 やらなくてもいい仕事に忙殺されていないか？ 楽してると思ってる人は本質的な仕事に集中しているのではないか？

これはイシューからはじめよでいうところの犬の道に陥っている状態である。 自分だけ大変と思っているときは、実際には価値を生み出していないにも限らず、仕事量によ達成感を成果と勘違いしていることが多い。

自分ばっかり大変だ、となっているときは価値の低いことに時間を投入していないか見つめ直そうという自戒。

2024年の振り返りをする

zatu

みんな振り返りしてる。振り返りしてないのはお前だけ。

なので振り返りします。

登壇関係

2024-03-29 3-shake SRE Tech Talk #9 - connpass

2024年の登壇はじめは所属会社である株式会社スリーシェイクの主催するイベントでした。 データベーススペシャルということでDB関連がメインの回で、メインセッションとして30分枠で登壇しました。 内容はo11yとデータベースを主軸とした話です。個人的には今後データベースのスロークエリ検知は従来のスロークエリログを利用する方法からo11yのトレースを通して発見していく方法が主流になるのではと思っています。

データベースにオブザーバビリティを注入する - Speaker Deck

SRETTというイベントがインフラ・SRE・アプリケーション側の試聴者が多いだろうと考えて、少しアプリ・SREよりの内容にしようとo11yをメインに据えた記憶があります。

2024-04-26 YugabyteDB Japan Meetup #3

登壇はじめからはなかなかのハイペースで、1ヶ月経たないうちにGoogle CloudのコミュニティであるJagu'e'rでの登壇です。 やはりここもDBREの文脈でデータベースでブルーグリーンをできるようにしようという内容です。

Jagu'e'r Observability-SRE分科会 Meetup#7 ハイブリッド - connpass

Google CloudのDBにもAWS RDSのブルーグリーン相当の機能が欲しいです。

2024-06-05 Google Cloud非公開イベント

Google Cloudがパートナー向けに開催している非公開イベントでの登壇でした。 2024年4月のGoogle Cloud Nextで発表された「全てのDBにベクトル検索を搭載します」という内容に衝撃を受けて、話した内容だった気がします。 確かにすごいですが、全部のDBに必要なのかと問われると疑問です。

Google Cloud で利用できるRDBのベクトル検索を徹底解剖！ - Speaker Deck

結論としては特別な理由がなければCloud SQLを使え、です。

2024-07-17 YugabyteDB Japan Meetup #5 - connpass

約1年ぶりのYugabyteDB Japan Meetupのリベンジ登壇です。 初回がなぜかDBREの話をしてYugabyteDBの話はフレーバー程度になってしまったので、本腰を入れてYugabyteDBならではの話をしました。

大規模マルチテナントを解決するYugabyteDBという選択肢 - Speaker Deck

YugabyteDBはメジャーなNewSQLでは唯一RLSをサポートしており、スケールアウトとセキュリティを両立したデータベースなので大規模マルチテナントの最適解では？　という内容です。 この考えはAurora DSQLの登場でも意見は変わりませんが、Limitlessでいいのでは？　という気持ちはあります。

2024-08-30 Jagu'e'r Cloud Native #15 ハイブリッド Meetup - connpass

2024年2回目のJagu'e'rでの登壇でした。 Google Cloudと不仲と噂されていたOracleの関係改善に驚いた結果話した内容です。 やっていることはシンプルでOracle DBをKubernetesでうごかすOperatorを紹介しています。

GoogleとOracle：この二人は友達になれました～GKEでOraOperatorを動かそう～ - Speaker Deck

この9月末まではGoogle Cloudのパートナーエンジニア表彰プログラムである、Google Cloud Partner Top Engineerの評価期間であったためGoogle Cloudに偏重した登壇を行っていました。

2024-10-01 Kubernetes Novice Tokyo #34 - connpass

Jagu'e'r Cloud Native #15で登壇した内容を一部保管しつつ、されつつといった内容の登壇でした。 @bells17_が運営のひとりなのでOracle DB on Kubernetesの話をするので早く開催してくださいとプレッシャーをかけた覚えがあります。その節はお世話になりました。 登壇した直後にOracle DBの話しすぎて、Kubernetesユーザーからするとちょっと違うなという話をしてしまったと反省した記憶があります。

Kubernetes上でOracle_Databaseの運用を楽にするOraOperatorの紹介 - Speaker Deck

この時期はOracle DB x Kubernetesの熱が上がりましたが、今はそこまででもありません。 今はやっぱりPostgreSQLだとCloud NativePGに熱を上げてます。

2024-12-17 Database Engineering Meetup #5 - connpass

2024年の登壇納はDatabase Engineering Meetupでした。 ちょうど11月下旬ごろにKubeCon NA 2024があり、そこでDB関連のセッションが半年前のKubeConから3倍近くに増えておりそれをまとめた内容です。

KubeCon NA 2024の全DB関連セッションを紹介 - Speaker Deck

2024年のはじめごろはGoogle Cloudを中心としたパブリッククラウドを主軸としたCloud Nativeから、Oracle x GKEを通してKubernetesという流れでした。 データベースエンジニアを自称する限り、Kubernetesからは逃げられないと思っています。来年もKubernetesを頑張ります。

2024年は全部で7本の登壇をしたようです。

ブログ関連

はてなブログでは主に読んだ論文やドキュメント、セッションレポートなどをまとめ、zennでは何かを調べてまとめたものや 検証した結果をまとめるように使い分け運用しました。

12月のアドベントカレンダーシーズンにKubeCon NAのセッションレポートを書いていたところ、最後の投稿が2023年の振り返りをするで焦ったのは秘密です。

nnaka2992.hatenablog.com

zennの方は2023年と同様に社内向けに話すもののうち社外に出しても問題ないようなものを垂れ流していましす。2025年も引き続き技術検証方面に力をいれたいので zennを活発に出来たらなと思います。

全部で11本のブログを書いたようです。

まとめ

2024年はがむしゃらに本数を意識した1年でした。

来年も数にはこだわっていきたいですが、内容はKubernetesとPostgreSQLとGoogle Cloudあたりに注力していけたらいいなと思っています。

KubeCon NA 2024: Goodbye etcd! Running Kubernetes on Distributed PostgreSQLのセッションレポート

DB KubeCon NA 2024 Kubernetes YugabyteDB

この記事は以下アドベントカレンダー15日目の記事です。

Goodbye etcd! Running Kubernetes on Distributed PostgreSQL セッションレポート

このセッションはKubernetesクラスタのメタデータストアとして利用されるetcdをDistributed PostgreSQLであるYugabyteDBに置き換えた方法を紹介し、デモを行っています。

What's etcd?

セッションはetcdの解説から始まりました。etcdは分散可能で可用性の高いキーバリューストアであり、シンプルながらも強力なデータベースとして機能します。Raftプロトコルを用いることで、複数のマシンやVMで構成されたクラスタ全体にわたって変更を複製し、ノード障害発生時にも一貫したデータと継続的な動作を保証します。Kubernetesはこのetcdをメタデータストアとして活用し、サービスのポート数やデプロイメントのPod数といったクラスタの状態を管理しています。このセクションはetcdの役割を明確に示し、Kubernetesにおける重要性を理解する上で有用でした。etcdがKubernetesの心臓部と言える重要な役割を担っていることを再認識させられました。

Why some are not happy with etcd

etcdは多くのKubernetesクラスタで標準的に利用されていますが、大規模環境（100～1000ノード）ではスケーラビリティに課題があることが指摘されました。このようなケースでは、etcdから分散データベースへの移行が必要となります。さらに、etcdプロジェクトへのコントリビュータ不足も懸念材料として挙げられており、Kubernetesが必要とする機能追加への対応が遅れる可能性が示唆されました。このセクションは、etcdの潜在的な問題点を浮き彫りにし、代替手段を検討する必要性を示唆しています。特に大規模運用を想定している場合、etcdのスケーラビリティの限界は深刻な問題になり得ます。

Kine

KineはKubernetesクラスタとリレーショナルデータベース間の仲介役として機能するシミュレータレイヤです。etcd APIをSQLに変換することで、PostgreSQLやMySQLのようなリレーショナルデータベースをKubernetesのメタデータストアとして利用可能にします。Kubernetes APIサーバーが発行したetcd APIをKineがSQLに変換し、データベースに実行することで、etcdの代替を実現します。このセクションはKineの動作原理を簡潔に説明し、リレーショナルデータベースをKubernetesと統合する仕組みを理解する上で重要です。Kineの存在によって、既存のデータベース基盤を活用したKubernetes運用が可能になります。

Hands-on

デモ環境はGoogle Cloud上の3つのCompute Engine（us-westリージョンの異なるゾーン）に構築されたk3sクラスタで、純粋なPostgreSQLと分散型PostgreSQLであるYugabyteDBの2つのシナリオが示されました。純粋なPostgreSQLは単一VMで、YugabyteDBは3台のVMで実行され、マルチゾーン、マルチリージョン、マルチクラウド/オンプレミス環境への拡張可能性が示唆されました。このセクションはデモ環境の概要を説明し、異なるデータベース構成でのKubernetes運用の可能性を示しています。実環境に近い構成でのデモは、KineとYugabyteDBの有効性を理解する上で非常に役立ちます。

Kubernetes on Pure PostgreSQL

youtu.be

このデモでは、PostgreSQLが動作するサーバ上でk3sを実行し、Kineが必要とするオブジェクトがPostgreSQLに作成される様子、そしてk3s自体の動作確認が示されました。既存のPostgreSQL環境へのKubernetesの導入を検討する際に、このデモは具体的な手順と動作イメージを提供してくれます。データベース管理者にとって、Kineによるデータベースへの影響を視覚的に確認できる点は非常に重要です。

Kubernetes on YugabyteDB

YugabyteDBとは？

YugabyteDBは、PostgreSQL互換の分散SQLデータベースです。クエリレイヤはPostgreSQLからフォークされ、ストレージレイヤはLSMツリーベースの実装1を採用しています。複数サーバ・複数リージョンでの運用が可能で、クエリ分散やノード障害時の継続動作を実現します。etcdと同様にRaftプロトコルを利用することで、データの一貫性を確保し、ネットワーク分断時のスプリットブレインにも対応します。このセクションはYugabyteDBの特徴を説明し、高可用性と分散性を備えたデータベースとしての利点を明確に示しています。etcdの代替としてYugabyteDBを検討する際に、この情報は非常に重要です。

デモ

youtu.be

YugabyteDBクラスタ上でk3sを実行するデモでは、PostgreSQLの場合とほぼ同様の手順でKubernetesを起動できることが示されました。YugabyteDBのダッシュボードを用いて、データベースの情報やKineが作成した情報を確認できる点も強調されました。さらに、Kubernetesのサンプルアプリを起動することで、etcdベースのKubernetesと同等の動作が確認されました。1台のCompute Engineを停止させることでYugabyteDBノードの障害をシミュレートし、データベースとKubernetesが継続して動作することを実証しました。このデモは、YugabyteDBの耐障害性と高可用性を視覚的に示し、実運用環境での信頼性を裏付けています。

結論

このセッションは、KineとYugabyteDBを用いることで、etcdの代替としてリレーショナルデータベースをKubernetesのメタデータストアとして利用できることを示しました。特に、YugabyteDBの分散性と耐障害性は、大規模Kubernetesクラスタの運用においてetcdのスケーラビリティやコントリビュータ不足といった課題を解決する可能性を示唆しています。ただし、YugabyteDBの導入には運用コストや学習コストといった新たな課題も発生するため、etcdとの比較検討が必要です。 同様にセッションではKineをネイティブに利用しているk3sを利用していますが、k3sはあくまでKubernetesの軽量ディストリビューションであるため完全に同じものではないため、本当にk3sで良いのかという比較検討も必要になります。

またセッション内では100を超えるノードから構成されるKubernetesクラスタではetcdのスケーラビリティが足りず、他のメタデータストアが必要になると紹介していますが、なぜ必要になるかは説明が不足していると感じました。これはKubernetesクラスタが大規模化することでAPIサーバが発行するクエリがetcdの対応可能な10000 rpsを越え始めるためです。 より詳細な説明はGoogle Cloudの65000ノードを越えるGKEクラスタをSpannerでホストしていることを紹介しているブログが参考になるでしょう。

cloud.google.com

KubeCon NA 2024: Database DevOps: CD for Stateful Applicationsのセッションレポート

DB KubeCon NA 2024 Kubernetes

この記事は以下アドベントカレンダー14日目の記事です。

Database DevOps: CD for Stateful Applications セッションレポート

このレポートでは、KubeCon + CloudNativeCon North America 2024 のセッション「Database DevOps: CD for Stateful Applications」の内容をまとめたもので、DatabaseのDevOpsとステートフルアプリケーションの継続的デリバリについてです。

データベースCDの課題と解決策

セッションでは、データパイプラインのデータテストをデリバリパイプラインに統合することの重要性が強調されていました。従来、データベースのテストは、BIツールなどを用いたカスタマイズされた方法で行われることが多かったようですが、最も信頼性の高いテスト方法は、新旧バージョンで同じデータに対してテストを実行することだとスピーカーは主張していました。そして、Kubernetesはこのようなテストを大幅に簡略化できるとのことでした。この主張は、データベースの変更がアプリケーション全体に及ぼす影響を正確に把握し、本番環境へのデプロイ前に潜在的な問題を早期に発見するために非常に重要です。

Kubernetesによるデータベース運用の進化

セッションで紹介されたアーキテクチャの進化は、Kubernetesがデータベース運用にもたらす利点を明確に示していました。初期のアーキテクチャでは、アプリケーション、データベース、インフラストラクチャの変更が個別に管理されていましたが、発展したアーキテクチャでは、これらが統合されたCI/CDパイプラインで管理されています。この統合により、アプリケーション、データベース、インフラストラクチャの変更をE2Eでテストできるようになり、本番環境へのデプロイリスクを大幅に軽減できます。

このアーキテクチャの進化は、マイクロサービスアーキテクチャやクラウドネイティブ開発との親和性が高いと言えます。マイクロサービスでは、個々のサービスが独立してデプロイされるため、データベースの変更が他のサービスに及ぼす影響を正確に把握することが重要です。Kubernetesはこのような複雑な依存関係を管理し、安全なデプロイを実現するための強力なプラットフォームを提供します。

デモのオーバービュー

セッションでは、具体的なスキーママイグレーションのシナリオを例に、ダウンタイムゼロでのデータベース変更を実現する方法が紹介されていました。WarehouseテーブルのLocationカラムの衝突問題を解決するために、CityとStateカラムを追加し、Locationカラムとの同期をトリガーで実現する方法は、実務で非常に役立つアプローチです。この手法は、データベースの変更によるアプリケーションへの影響を最小限に抑え、ユーザー体験を損なうことなくシステムを進化させることを可能にします。

デモで利用されるCDパイプライン
デモで適用されるデータベースへの変更

個人的にはこのようなユースケースのテストシナリオは複雑になることが多いと考えていたため、自動化を行うには相当のカスタマイズが必要になると思っていたので、この後のデモの手軽さには非常に驚かされました。

デモのハイライトとHarnessの活用

youtu.be

このセッションはデモが全体のほとんどを閉めています。デモ開始時点のリンクがブログ記事の中盤にあるので、デモ部分だけでもご覧になることを強く推奨します。

セッションのデモでは、Harnessというツールが使用され、変更プロセスとロールバック手順が分かりやすく可視化されていました。Harnessは、GitLab CI/CDやGitHub ActionsのようなUIを提供し、各ステップの成功/失敗を容易に確認できる点が優れていると感じました。特に、ArgoCDとの連携によるデータベースとアプリケーションの協調動作は、複雑なデプロイプロセスを簡素化する上で非常に効果的です。

デモで紹介された、望ましい状態になっていないことを確認し、変更を加えるプロセスは、実践的な知見を提供していました。また、データベースの変更セットの一部として事前にロールバック手順を定義しておくことは、本番環境での予期せぬ問題発生時に迅速な対応を可能にするベストプラクティスと言えるでしょう。LiquibaseやFlywayなどのツールはこのような機能を提供しており、データベースDevOpsの実践において不可欠です。 HarnessではデータベースのDevOpsをアプリケーション、インフラストラクチャー込みで実現しており、非常に理想的なツールのように見えました。一方でこのセッションのスピーカーのひとりはHarnes.ioのエンジニアであるため、ポジショントークや見せたい部分しか見せていないことが十分考えられるので全てを鵜呑みにするのは危険です。 それを差し引いても興味深いデモだったので、セッションで紹介された技術スタックを検証してみたいと思っています。

まとめ

このセッションは、Kubernetesとツールを活用することで、データベースの変更を安全かつ効率的に行う方法を示していました。E2Eテスト、ダウンタイムゼロのスキーママイグレーション、そしてロールバック手順の自動化は、データベースDevOpsを実現するための重要な要素です。これらの手法を適切に組み合わせることで、開発速度を向上させながら、システムの安定性と信頼性を維持することが可能になります。

しかし、ここで紹介された手法は全ての状況に適用できるわけではありません。例えば、大規模なデータベースや複雑なトランザクション処理を行うシステムでは、ダウンタイムゼロのマイグレーションが困難な場合があります。そのようなケースでは、段階的なロールアウトやカナリアリリースなどの手法を検討する必要があります. また、ツールの導入や運用にはコストがかかるため、組織の規模やリソースに合わせて適切なツールを選択することが重要です。

今後のデータベース運用においては、自動化と可観測性をさらに強化し、自己修復機能を備えた自律的なデータベース運用を目指していくことが重要だと考えます。Kubernetesやクラウドネイティブ技術は、この目標を実現するための基盤となるでしょう。

またこのセッションを見るまで、個人的にDatabase on KubernetesはKubernetesを利用している組織でマネージドデータベースのコストを安くしたい場合や、データを自分たちのコントロールできる場所におきたい時に利用する選択肢と思っていました。 しかしデータベースをKubenetesにデプロイすることでアプリケーションと密接に結合したテストを簡単に行えることがわかり、データベースの運用コストさえ許容できれば、他のメリットがなくてもデータベースをKubernetesで運用するのは十分ありなのではないかと意見が変わりました。 今後は単なるデータベースのホスティング環境としてのKubernetes以外の部分にも注目していきたいです。