NAKADATE Naoki

お仕事をしているとチームや自分の周りで合意を取ったことを、相手にお願いしに行くことが多々あります。例えばピープルマネジメントのマネージャー層でxxというやり方を試していきたいと合意をとったものを、相手にお願いしに行くこと。例えば自分たちの担当範囲の決め事で、相手に協力をお願いしに行くこと。例えば自分たちのシステムと他システム間の決め事で、こちらの方針を相談しに行くこと。自分たちの決め事を相手に協力してもらうことはよくあります。方針を固めるまでにディスカッションを重ね、自分たちにどのようなメリットがあるかは詳細に話すでしょう。自分たちの考えやメリットも詳細に説明できるでしょう。では相手のメリットはどうでしょう？ 自分の考えやメリットの説明で終わってはいないでしょうか？相手のアクションが必要なとき、ポジションティブに動いてもらうには相手の動機が重要です。相手にメリット考えて貰うより、発案者から提案したほうが心象も良くなります。要は相手の立場を考えましょうの一側面です。相手と話すときは相手の立場を考えましょう。

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

Google CloudがApplication Design Centerという、構成図を書けばTerraformを書いて、デプロイまで行う機能をリリースしました。[1]https://cloud.google.com/application-design-center/docs/overviewどうやらGoogle CloudはTerraform職人を失職に追い込みたいようです。 Application Design Centerの概要アプリケーション デザイン センターは、Google Cloud アプリケーション インフラストラクチャの設計、共有、デプロイに役立ちます...

Google CloudのTerraform職人が失職する機能が出てしまった……

仕事をしていて数年ほどたつと自分はこんなに頑張ってるのに評価が低いと思うタイミングが来る。これは後々そんなことはなかったと気がつくものの、そのタイミングにいる間は不適当な評価を受けていると思いがちで、自尊心が肥大しがちである。自分ばっかり頑張っていると感じたときは、自分の仕事が本当に価値を生んでいるのかという観点に立ち返ったほうがいい。やらなくてもいい仕事に忙殺されていないか？ 楽してると思ってる人は本質的な仕事に集中しているのではないか？これはイシューからはじめよでいうところの犬の道に陥っている状態である。自分だけ大変と思っているときは、実際には価値を生み出していないにも限らず、仕事量によ達成感を成果と勘違いしていることが多い。自分ばっかり大変だ、となっているときは価値の低いことに時間を投入していないか見つめ直そうという自戒。

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

みんな振り返りしてる。振り返りしてないのはお前だけ。なので振り返りします。登壇関係2024-03-29 3-shake SRE Tech Talk #9 - connpass2024年の登壇はじめは所属会社である株式会社スリーシェイクの主催するイベントでした。データベーススペシャルということでDB関連がメインの回で、メインセッションとして30分枠で登壇しました。内容はo11yとデータベースを主軸とした話です。個人的には今後データベースのスロークエリ検知は従来のスロークエリログを利用する方法からo11yのトレースを通して発見していく方法が主流になるのではと思っています。データベースにオブザーバビリティを注入する - Speaker DeckSRETTというイベントがインフラ・SRE・アプリケーション側の試聴者が多いだろうと考えて、少しアプリ・SREよりの内容にしようとo11yをメインに据えた記憶があります。2024-04-26 YugabyteDB Japan Meetup #3登壇はじめからはなかなかのハイペースで、1ヶ月経たないうちにGoogle CloudのコミュニティであるJagu'e'rでの登壇です。やはりここもDBREの文脈でデータベースでブルーグリーンをできるようにしようという内容です。Jagu'e'r Observability-SRE分科会 Meetup#7 ハイブリッド - connpassGoogle 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 DeckYugabyteDBはメジャーなNewSQLでは唯一RLSをサポートしており、スケールアウトとセキュリティを両立したデータベースなので大規模マルチテナントの最適解では？　という内容です。この考えはAurora DSQLの登場でも意見は変わりませんが、Limitlessでいいのでは？　という気持ちはあります。2024-08-30 Jagu'e'r Cloud Native #15 ハイブリッド Meetup - connpass2024年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 - connpassJagu'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 - connpass2024年の登壇納はDatabase Engineering Meetupでした。ちょうど11月下旬ごろにKubeCon NA 2024があり、そこでDB関連のセッションが半年前のKubeConから3倍近くに増えておりそれをまとめた内容です。KubeCon NA 2024の全DB関連セッションを紹介 - Speaker Deck2024年のはじめごろはGoogle Cloudを中心としたパブリッククラウドを主軸としたCloud Nativeから、Oracle x GKEを通してKubernetesという流れでした。データベースエンジニアを自称する限り、Kubernetesからは逃げられないと思っています。来年もKubernetesを頑張ります。2024年は全部で7本の登壇をしたようです。ブログ関連はてなブログでは主に読んだ論文やドキュメント、セッションレポートなどをまとめ、zennでは何かを調べてまとめたものや検証した結果をまとめるように使い分け運用しました。12月のアドベントカレンダーシーズンにKubeCon NAのセッションレポートを書いていたところ、最後の投稿が2023年の振り返りをするで焦ったのは秘密です。nnaka2992.hatenablog.comzennの方は2023年と同様に社内向けに話すもののうち社外に出しても問題ないようなものを垂れ流していましす。2025年も引き続き技術検証方面に力をいれたいのでzennを活発に出来たらなと思います。全部で11本のブログを書いたようです。まとめ2024年はがむしゃらに本数を意識した1年でした。来年も数にはこだわっていきたいですが、内容はKubernetesとPostgreSQLとGoogle Cloudあたりに注力していけたらいいなと思っています。

2024年の振り返りをする

この記事は以下アドベントカレンダー15日目の記事です。3-shake Advent Calendar 2024 シリーズ2Kubernetes Advent Calendar 2024 シリーズ2Goodbye etcd! Running Kubernetes on Distributed PostgreSQL セッションレポートセッション概要 https://kccncna2024.sched.com/event/1i7rt/goodbye-etcd-running-kubernetes-on-distributed-postgresql-denis-magda-yugabyteセッション動画 www.youtube.comこのセッションは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 etcdetcdは多くのKubernetesクラスタで標準的に利用されていますが、大規模環境（100～1000ノード）ではスケーラビリティに課題があることが指摘されました。このようなケースでは、etcdから分散データベースへの移行が必要となります。さらに、etcdプロジェクトへのコントリビュータ不足も懸念材料として挙げられており、Kubernetesが必要とする機能追加への対応が遅れる可能性が示唆されました。このセクションは、etcdの潜在的な問題点を浮き彫りにし、代替手段を検討する必要性を示唆しています。特に大規模運用を想定している場合、etcdのスケーラビリティの限界は深刻な問題になり得ます。KineKineは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 PostgreSQLyoutu.beこのデモでは、PostgreSQLが動作するサーバ上でk3sを実行し、Kineが必要とするオブジェクトがPostgreSQLに作成される様子、そしてk3s自体の動作確認が示されました。既存のPostgreSQL環境へのKubernetesの導入を検討する際に、このデモは具体的な手順と動作イメージを提供してくれます。データベース管理者にとって、Kineによるデータベースへの影響を視覚的に確認できる点は非常に重要です。Kubernetes on YugabyteDBYugabyteDBとは？YugabyteDBは、PostgreSQL互換の分散SQLデータベースです。クエリレイヤはPostgreSQLからフォークされ、ストレージレイヤはLSMツリーベースの実装1を採用しています。複数サーバ・複数リージョンでの運用が可能で、クエリ分散やノード障害時の継続動作を実現します。etcdと同様にRaftプロトコルを利用することで、データの一貫性を確保し、ネットワーク分断時のスプリットブレインにも対応します。このセクションはYugabyteDBの特徴を説明し、高可用性と分散性を備えたデータベースとしての利点を明確に示しています。etcdの代替としてYugabyteDBを検討する際に、この情報は非常に重要です。デモyoutu.beYugabyteDBクラスタ上で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: Goodbye etcd! Running Kubernetes on Distributed PostgreSQLのセッションレポート

この記事は以下アドベントカレンダー14日目の記事です。3-shake Advent Calendar 2024 シリーズ2Kubernetes Advent Calendar 2024 シリーズ1Database DevOps: CD for Stateful Applications セッションレポートセッション概要:https://kccncna2024.sched.com/event/1i7na/database-devops-cd-for-stateful-applications-stephen-atwell-harnessio-christopher-crow-pure-storage?linkback=grid-fullセッションスライドhttps://static.sched.com/hosted_files/kccncna2024/86/Harness-Portworx%20Kubecon%202024.pdfこの記事内の画像は全てこのスライドより引用しています。セッション動画  www.youtube.comこのレポートでは、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以外の部分にも注目していきたいです。

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

この記事は以下アドベントカレンダー13日目の記事です。3-shake Advent Calendar 2024 シリーズ2Kubernetes Advent Calendar 2024 シリーズ2Building Resilience: Effective Backup and Disaster Recovery for Vector Databases on Kubernetes セッションレポートセッション概要:https://kccncna2024.sched.com/event/1i7kn/when-life-gives-you-containers-make-an-open-source-rds-a-kubernetes-love-story-sergey-pronin-perconawww.youtube.comKubeCon + CloudNativeCon North America 2024 のセッション "Building Resilience: Effective Backup and Disaster Recovery for Vector Databases on Kubernetes" は、AI アプリケーションにおけるベクトルデータベースの重要性と、Kubernetes 上での堅牢なデータ保護戦略の必要性を強調した示唆に富む内容でした。マーケティング的な観点や、聴衆の興味を引くためといった理由からかタイトルでベクトルデータベースとなっていますが、バックアップの部分ではあらゆるデータベースやステートフルワークロードに応用ができる内容でした。AI and Kubernetesセッションは、AI がアプリケーションにもたらす変革的な影響についての概説から始まりました。リソース需要予測による動的スケーリング、異常検知によるセキュリティ向上、UX の改善、そして事前の障害予測による可用性向上など、AI はアプリケーションのあらゆる側面を最適化する可能性を秘めています。そして、これらのメリットを実現する上で、Kubernetes が最適なプラットフォームとして位置づけられています。迅速なデプロイ、高可用性とスケーラビリティ、可搬性と柔軟性、分散ワークロード管理の効率化、そして効率的なバックアップとリカバリといった Kubernetes の特徴は、AI ワークロードの運用に不可欠な要素です。特に、データベースを Kubernetes 上で運用する組織が増加しているという Data on Kubernetes のレポートの言及は、AI/ML ワークロードとデータベース運用の密接な関係性を示唆しており、データベースエンジニアとして注目すべき点でした。Kubernetes がステートフルなアプリケーションの運用基盤として成熟しつつあることを改めて認識させられました。Kubernetes上でAIアプリケーションをデプロイする理由セッションでは、Kubernetes上でAIアプリケーションをデプロイする理由として、迅速なデプロイ、高可用性とスケーラビリティ、可搬性と柔軟性、分散ワークロードの管理の効率化、効率的なバックアップとリカバリ、そしてエコシステムとコミュニティの発展が挙げられていました。これらの利点は、クラウドネイティブな開発と運用を目指す上で非常に重要です。特に、マイクロサービスアーキテクチャを採用する際に、Kubernetes はサービスのデプロイと管理を簡素化し、スケーラビリティと可用性を向上させる上で強力なツールとなります。さらに、ベクトルデータベースのようなステートフルなサービスを Kubernetes 上で運用することで、データの永続性と可用性を確保し、AI アプリケーションの信頼性を向上させることができます。Vector Databases and RAGセッションの中核を成すのが、ベクトルデータベースと RAG (Retrieval Augmented Generation) の解説です。非構造化データの増加に伴い、従来のデータベースでは対応が難しくなってきた画像、テキスト、音声といったデータの効率的な処理が求められています。ベクトルデータベースは、これらの非構造化データをベクトル表現に変換し、類似度検索によって関連性の高い情報を高速に取得することを可能にします。Embedding Model を用いたベクトル化によって、意味的な検索が可能になり、AI アプリケーションの精度と効率性が向上する点が強調されていました。特に、生成 AI アプリケーションにおけるハルシネーション軽減とコンテキスト付与におけるベクトルデータベースの役割は重要です。RAG は、ベクトルデータベースを用いて関連情報を取得し、生成 AI の出力に信頼性を与える手法として紹介されており、今後の AI アプリケーション開発において不可欠な要素となるでしょう。ベクトルデータベースのユースケースセッションでは、ベクトルデータベースのユースケースとして、検索エンジン、画像検索、推薦アルゴリズム、異常検知、そしてチャットボットなどの生成 AI アプリケーションが挙げられていました。これらのユースケースは、現代のアプリケーション開発において非常に重要であり、ベクトルデータベースの適用範囲の広さを示しています。特に、マイクロサービスアーキテクチャにおいて、ベクトルデータベースを独立したサービスとして提供することで、様々なサービスから容易にアクセスできるようになり、システム全体の柔軟性と拡張性を向上させることができます。また、DevOps/SRE の実践においては、ベクトルデータベースの監視と運用を自動化することで、システムの信頼性と可用性を向上させることができます。Data Protectionデータ保護は、Kubernetes 上で運用されるベクトルデータベースにとって不可欠な要素です。データの整合性とセキュリティ、災害復旧、コストと時間の効率化、バージョンコントロール、そしてコンプライアンス規制への準拠など、データ保護は多岐にわたるメリットを提供します。セッションでは、Kubernetes 上でのベクトルデータベースのデータ保護方法として、ストレージスナップショット、データサービスを利用したストレージスナップショット、データサービスレベルのスナップショット、そしてこれらの組み合わせが紹介されました。PVC を利用した永続化データの保護は、Kubernetes ネイティブなデータ保護戦略を構築する上で重要なポイントです。Kanister のようなデータ保護ワークフロー管理ツールは、バックアップとリストアの手順を抽象化し、自動化することで、運用効率を大幅に向上させることができます。Kanister の Blueprint、Profile、ActionSet といった CRD を活用することで、柔軟なデータ保護ワークフローを定義し、Kubernetes の宣言的な運用を実現できます。Kanisterの動作Kanister の動作は、ActionSet が Controller に動作を開始するようにトリガーし、Controller が Blueprint を参照して定義されたオペレーションに従ってベクトルデータベースからバックアップを取得し、オブジェクトストレージに保存するという流れで実行されます。動作完了後、Controller は ActionSet に完了を伝え、ActionSet がユーザーに完了を通知します。この自動化されたワークフローは、データベースエンジニアの運用負荷を軽減し、ヒューマンエラーのリスクを最小限に抑える上で非常に有効です。また、バックアップとリストアのプロセスをコード化することで、再現性と信頼性を向上させることができます。Demoデモでは、書籍推薦チャットボット BookNest を例に、PostgreSQL と PGVector を利用したベクトルデータベースのバックアップとリストアのワークフローが紹介されました。提供された図とデモ動画は、Kanister を用いたデータ保護の実践的な方法を理解する上で非常に役立ちました。具体的な構成例を示すことで、視聴者は自身の環境に合わせたデータ保護戦略を検討する際の参考にすることができます。また、デモを通じて Kanister の操作方法やワークフローの定義方法を視覚的に理解することができ、実践的な知識を深めることができます。Kanister の Blueprint は Kubernetes の manifest 内で ShellScript を書くようなイメージでかけるため、すでに Kubernetesを利用している組織であれば利用に大きなハードルは少なそうだと感じました。Operator 化されたデータベースでは大きなメリットはないかもしれないですが、そうでないデータベースのバックアップや、Operator を使っていても複数の種類がある場合オペレーションの使用ツールの共通化という面で十分メリットがあるでしょう。Call to Actionセッションの締めくくりとして、AI アプリケーションとベクトルデータベースの重要性、そしてデータ保護の必要性が改めて強調されました。データ保護を Day 0 Operation と位置づけるというメッセージは、システム設計の初期段階からデータ保護を考慮することの重要性を示唆しています。システムの保守性、スケーラビリティ、セキュリティを確保する上で、データ保護は不可欠な要素であり、アプリケーション開発ライフサイクル全体を通じて考慮する必要があります。まとめこのセッションは、AI アプリケーションにおけるベクトルデータベースの重要性と、Kubernetes 上での堅牢なデータ保護戦略の構築方法について、具体的な例を交えながら分かりやすく解説していました。特に、Kanister のようなデータ保護ツールを活用することで、複雑なバックアップとリカバリのワークフローを簡素化し、自動化できる点が印象的でした。データベースを Kubernetes 上で運用する際には、データ保護を Day 0 Operation として捉え、Kanister のようなツールを活用することで、システムの信頼性と可用性を向上させることができます. セッションで提示された情報は、今後のデータベース運用戦略を検討する上で非常に貴重な示唆を与えてくれました。このセッションで扱われなかった点として、ベクトルデータベースの選択基準やパフォーマンスチューニング、そして異なるベクトルデータベースにおけるデータ保護戦略の差異などが挙げられます。今後のセッションでは、これらの点についても掘り下げて議論されることを期待します。

KubeCon NA 2024: Building Resilience: Effective Backup and Disaster Recovery for Vector Databases on Kubernetes のセッションレポート

この記事は以下アドベントカレンダー8日目の記事です。3-shake Advent Calendar 2024 シリーズ2Kubernetes Advent Calendar 2024 シリーズ2The Future of DBaaS on Kubernetesのセッションレポートセッション概要:https://kccncna2024.sched.com/event/1i7kL/the-future-of-dbaas-on-kubernetes-melissa-logan-constantia-sergey-pronin-percona-deepthi-sigireddi-planetscale-gabriele-bartolini-edbセッション動画:https://www.youtube.com/watch?v=Z35SlsYd1ds「The Future of DBaaS on Kubernetes」は、Data on Kubernetes Communityのメンバーによるパネルディスカッション形式で、Kubernetes上で動作するDBaaSの将来について議論されました。ここ数年でデータベースをKubernetes上で動かすにあたりどう便利になったか？セッションでは、Kubernetesにおけるストレージとネットワーキングの進化が、データベース運用を大きく改善した点が強調されました。Volume Snapshotなどのストレージ関連機能の向上は、バックアップとリカバリといったDay 2 Operationを効率化し、Local Persistent Volumeの導入と改善は、データベースの高可用性とディザスタリカバリ構成をシンプルに実現可能にしました。また、Cilium Network PolicyやIngress/Egressといったネットワーキング機能は、マルチテナントサービスにおけるアクセス制御を容易にし、セキュリティ強化に貢献しています。これらの改善により、増加するデータベースと、優秀なデータベースエンジニア不足という課題に対し、Kubernetesは少ない人員でデータベースをスケールさせる有効な手段となっています。数年前に比べ、Kubernetes上でのデータベース運用はより現実的になり、エンタープライズグレードの運用にも耐えうるレベルに達しています。これは、Kubernetesがステートレスなアプリケーションだけでなく、ステートフルなデータベースにも適したプラットフォームへと進化したことを示しています。私がKubernetesを触り始めた時点ではここで紹介されているほとんどの機能はサポートされており、なぜKubernetesでデータベースを運用することが難しいのかを理解しきれない面がありました。このセクションによる直近のデータベース観点でのKubernetesのアップデートの紹介により、何が障壁でそれがどのように解決されたのかの理解が深まりました。Kubernetes上でデータベースを動かしている顧客についてシェアできる事例はあるか？セッションでは、Nokia、Broadcom、HubSpot、Shopify、IBMなど、様々な企業がKubernetes上でデータベースを運用している事例が紹介されました。これらの事例は、マイクロサービスアーキテクチャの普及と密接に関連しています。マイクロサービス化されたアプリケーションでは、単一のモノリシックなデータベースではなく、サービスごとにデータベースを持つ傾向があり、Kubernetesはそのような分散データベース環境の構築と管理を容易にします。特に、開発者がデータベースを所有し、インフラ管理者がDBaaSをインターフェイスとしてデータベースを払い出すという新しい運用モデルは、今後の主流となる可能性を示唆しています。これは、DevOpsの原則をデータベース運用に取り入れることで、開発速度と運用効率を向上させるアプローチと言えるでしょう。セクション内で紹介されている開発者がデータベースを所有し、インフラ管理者がデータベースを払い出すという体制はパブリッククラウドで運用されるマイクロサービスアーキテクチャでは当たり前のように実践されており、Kubernetesでも今後の主流となると考えることは不思議ではないでしょう。そしてそれは従来のVMやベアメタルベースのDBAがデータベース管理を行うには多すぎるデータベースが運用され、限界を迎えることは想像に難くなく、KubernetesとOperatorによる運用の簡略化は必須と言えるかもしれません。Kubernetes上でデータベースを動かすにあたりベストプラクティスはなにか？ベストプラクティスとして、クラウド中立性、クラウドレディネス、セルフサービス、セキュリティ、アーキテクチャ設計などが挙げられました。Operatorの活用は、クラウドベンダーに依存しない運用を実現する上で重要であり、UI/APIの整備やArgoCDなどのツールとの連携により、データベースのプロビジョニングと管理を自動化できます。また、開発者が容易にスケーリングやテスト環境構築を行えるセルフサービス環境も重要です。セキュリティについては、業界標準やコンプライアンス要件に合わせたポリシー設定が不可欠です。アーキテクチャ設計では、PostgreSQLを例に、Kubernetesの機能を活用した高可用性構成や、複数のアベイラビリティゾーンを考慮した設計が重要となります。さらに、Kubernetesの標準APIを活用することで、オブザーバビリティやセキュリティ、証明書の管理を簡素化し、他のコンポーネントとの統合を容易にすることが推奨されています。VMからの移行時には、ストレージを分離することでリソース管理の予測精度を高めることが重要です。ここではベストプラクティスとしてユーザーがセルフサービスでデータベースを立ち上げる方法としてGUIとAPIとツール連携による自動化二つの観点が出ていました。個人的にはパブリッククラウドとIaCの流れを見るにGUIベースよりAPIによる自動化が主流になっていくのではないかと考えます。またデータベースではないですがオンプレミスのVMベースシステムからKubernetesのコンテナベースに移行するプロジェクトに関わった時は独自のプロトコルによる通信をVMで実装しており、その方法をコンテナの世界に持ち込もうとした結果非常に複雑になっていた事例を見たことがあります。そのため、ここで紹介されているKubernetesとそのエコシステムに合わせることは不可欠ではないかと感じます。データベースをKubenetesで動かす場合の課題や落とし穴はあるか？セッションでは、VM環境での運用とKubernetes環境での運用を混同してしまうこと、マイグレーション計画の不足、リソースの過剰確保、そして人材育成の課題が議論されました。既存のVM向けスクリプトをそのままKubernetesに適用しようとするのではなく、クラウドネイティブな考え方を取り入れ、スケーラビリティと信頼性の向上に焦点を当てるべきです。マイグレーションにおいては、全てのワークロードの移行と、ダウンタイム最小化を両立するための綿密な計画が必要です。リソース管理においては、Kubernetesの柔軟性を活かし、適切なリソース割り当てを行うための実験と調整が重要です。さらに、DBAがKubernetesの基礎知識を習得し、データベース運用における新たなパラダイムシフトに対応できるよう、人材育成に力を入れる必要があります。このセッションを通して一番に感じたのはオンプレからパブリッククラウドへの移行と気にするところは同じだということと、DBAとKubernetesの距離を近づけることはやはり大事だということでした。特にDBAとKubernetesについてはより簡単なソリューションとして存在してしまっているマネージドデータベースが、Kubernetesを利用することから目を背けさせてしまう要因になっていると感じます。しかしDBAがより求められるのはデータベースをセルフホストする場合で、今後DBAとして活躍していくにはLinuxに適応してきたようにKubernetesに適応していく日強うがあると考えています。DBaaSの将来はどのように変わっていくと考えるか？将来のDBaaSは、Kubernetesとの統合がさらに深まり、データベースとKubernetesの境界が曖昧になっていくと予測されています。PostgreSQLの例では、Kubernetesとの親和性を高めるためのパッチ適用や、拡張機能のコンテナ化などが進んでいます。また、プライベートDBaaSだけでなく、商用DBaaSのKubernetes上での提供も増加し、データベースサービスの利用がさらに容易になると考えられます。Google Cloudなどのクラウドプロバイダーも、将来的にKubernetes上でマネージドデータベースサービスを提供する可能性があり、これにより、数千規模のデータベース管理が容易になるでしょう。Kubernetesの普及と成熟に伴い、Helm ChartやYAML以外の、より洗練されたUXも期待されます。セッション内ではGoogle CloudではCloud SQLがKubenetes1で運用される未来があるかもしれないと言及していましたが、すでにSpannerはKubernetesで動いています。商用DBaaSがKubernetesで動くことについてはよくある構成ですが、プライベートDBaaSがKubernetes上で動き、さまざまなエコシステムと組み合わせてAPIベースなど自動化に適したUXが提供されていくことには非常に注目しています。まとめ「The Future of DBaaS on Kubernetes」セッションは、Kubernetes上でのデータベース運用が成熟期を迎えていることを示しました。ストレージとネットワーキングの進化、Operatorの普及、そして様々な企業での成功事例は、Kubernetesがデータベース運用のための堅牢でスケーラブルなプラットフォームであることを証明しています。クラウドネイティブなアプローチ、セルフサービス化、セキュリティ強化、そして適切なアーキテクチャ設計は、Kubernetes上でのデータベース運用を成功させるための鍵となります。同時に、VM環境からの移行、リソース管理、人材育成といった課題にも適切に対処する必要があります。今後のDBaaSは、Kubernetesとの統合がさらに進み、データベースサービスの利用がより容易になると期待されます。このセッションで得られた知見は、今後のデータベース運用戦略策定に役立つ貴重な情報源となるでしょう。特に、オンプレミスでマイクロサービスアーキテクチャを採用する組織にとって、Kubernetesはデータベース運用における重要な選択肢となるでしょう。↩

 KubeCon NA 2024: The Future of DBaaS on Kubernetesのセッションレポート

この記事は以下アドベントカレンダー11日目の記事です。3-shake Advent Calendar 2024 シリーズ2Kubernetes Advent Calendar 2024 シリーズ1When Life Gives You Containers, Make an Open Source RDS: A Kubernetes Love Story セッションレポートセッション概要:https://kccncna2024.sched.com/event/1i7kn/when-life-gives-you-containers-make-an-open-source-rds-a-kubernetes-love-story-sergey-pronin-perconaセッション動画:https://www.youtube.com/watch?v=0gSSmdNB-Zoこのセッションは、オープンソースRDS、あるいはオープンソースDBaaSをKubernetes上で構築・運用する道のりを、物語風に語っています。セッションを通して、Kubernetes上でデータベースを運用することへの不安や課題を解消し、そのメリットと可能性を提示することを目指していると感じました。なぜKubernetesでデータベースを動かすのか？セッション冒頭では、スピーカーが4年前はKubernetesでデータベースを動かすことに懐疑的だったものの、現在は大きく考えが変わっていることが語られています。その理由として、クラウドニュートラル戦略、コスト削減、そして自動化の3点が挙げられています。特に自動化は、高可用性構成、Blue/Greenデプロイ、フェイルオーバーなどを容易にする点で重要です。これらのメリットは、マイクロサービスアーキテクチャやクラウドネイティブ開発において、データベース運用を効率化し、DevOps実践を促進する上で大きな力となります。従来の運用では、データベースのデプロイや管理に多くの手作業が必要でしたが、Kubernetesと自動化ツールを組み合わせることで、これらの作業を大幅に簡素化し、開発スピードの向上に貢献できます。一方、Kubernetes上でのデータベース運用に対する懸念として、パフォーマンスの劣化、Kubernetes自体の成熟度、そして複雑さが挙げられています。これらの懸念は、データベースエンジニアとして当然抱くものであり、セッション全体を通してこれらの懸念への回答が提示されています。このセクションでは、Kubernetes上でデータベースを運用する上でのメリットと課題が明確に示されており、導入を検討する上で重要なポイントが提示されています。特に、クラウドネイティブな環境におけるデータベース運用の重要性が強調されていました。また単純なメリット・デメリット以上にユーザーの感情面にフォーカスしているところが印象的でした。Chapter 1: Enthusiasm and Kubernetes 101: Kubernetesの基本と進化この章では、Kubernetes上でデータベースを動かすための基本的なステップが段階的に示されています。Pod、Persistent Volume Claim (PVC)、Service、Secret、ConfigMap、StatefulSet、そしてHA構成のためのエージェントとProxyの導入といった流れは、Kubernetesにおけるデータベース運用の進化を理解する上で非常に有用です。特に、StatefulSetの導入は、データベースのようなステートフルアプリケーションの運用において大きな進歩です。Podの順序付けられたデプロイ、安定したネットワークID、永続ストレージへのアクセスなど、StatefulSetが提供する機能は、データベースの高可用性と安定運用に不可欠です。しかし、これらの構成要素を手作業で管理することは複雑でエラーを起こしやすいため、IaCの導入が推奨されています。IaCを用いることで、インフラストラクチャのコード化、自動化、バージョン管理が可能となり、再現性と信頼性の高いデプロイを実現できます。TerraformやAnsible、ArgoCD、HelmなどのIaCツールは、Kubernetesの構成管理を簡素化し、複数環境へのデプロイを容易にします。これは、DevOpsの原則である「Infrastructure as Code」を実践する上で非常に重要なステップです。この章では、Kubernetes上でデータベースを動かすための基本的な構成要素と、IaCの重要性が説明されています。IaCを用いることで、複雑なKubernetes環境を効率的に管理し、再現性と信頼性を向上させることができる点が強調されていました。またIaCのパラメータを変更することで複数環境をデプロイできるところからDBaaSの最初の一歩を踏み出したととらえることができました。Chapter 2: Disillusionment and Operators 101: OperatorによるDay 2 Operationの簡素化IaCによってデプロイは容易になりますが、運用、つまりDay 2 Operationは依然として複雑です。アップグレード、スケーリング、フェイルオーバー、バックアップ、モニタリング、メンテナンス、リカバリといったタスクは、手作業で行うと大きな負担となります。ここでOperatorが登場します。Operatorは、Kubernetesの拡張機能であり、特定のアプリケーションのデプロイと管理を自動化します。データベースOperatorは、データベースのライフサイクル全体を管理し、Day 2 Operationを大幅に簡素化します。Operatorの導入により、データベース管理者はKubernetesの内部構造を深く理解する必要がなくなり、データベース運用に集中できます。これは、運用コストの削減と効率性の向上に大きく貢献します。また、Operatorは宣言的な設定をサポートしており、運用作業の自動化と標準化を促進します。しかし、Operatorだけでは真のDBaaSとは言えません。セルフサービスポータル、マルチクラスタ対応、詳細なモニタリング、課金機能など、DBaaSに必要な機能は多岐に渡ります。この章では、OperatorがDay 2 Operationを簡素化する上で重要な役割を果たすことが説明されています。Operatorは、データベース管理者の負担を軽減し、運用効率を向上させる強力なツールです。これはデータベースエンジニアといわれるロールが採用市場に少ない日本では特に重要な点です。大規模なデータベース運用に合わせてデータベースエンジニアの採用を増やすことは難しいため、様々なツールを利用して負荷を下げ、省力化し、より本質的な業務を行う必要があるためです。一方でOperatorだけではDBaaSの全てをカバーできない点にも注意が必要です。Chapter 3: Hope and DBaaS: Percona Everestの紹介Percona Everestは、オープンソースのDBaaSソリューションであり、Kubernetes上でデータベースサービスを提供します。ReactとMaterial UIで構築された直感的なUI、Golangで実装されたバックエンド、そしてAPIによるアクセスを提供することで、ユーザーフレンドリーな操作性を実現しています。Everestのアーキテクチャは、複数のOperatorをOperator Managerで管理する構造を採用しています。これにより、Operatorのバージョン管理、依存関係の解決、相互運用性の確保が容易になります。ユーザーは、GUIまたはAPIを介してデータベースサービスを操作し、そのリクエストはEverest Operatorによって各データベースOperatorに変換されます。Everestは、オープンソースDBaaSとして、ベンダーロックインを回避し、柔軟なデータベース運用を可能にします。また、コミュニティベースの開発により、迅速な機能追加とバグ修正が期待できます。この章では、Percona EverestがオープンソースDBaaSとして、Kubernetes上でデータベースサービスを提供する仕組みが説明されています。Everestは、ユーザーフレンドリーなUI、Operator ManagerによるOperator管理、そしてオープンソースとしてのメリットを提供することで、柔軟で効率的なデータベース運用を支援します。セッション中ではGUIやAPIは利用しない導入例もあると話されており、個人的にはKubernetesリソースの管理に余計なUIを追加する方法は大規模化したときにデメリットが増えるのではないかと感じました。またこのセッションのスピーカーはPerconaのエンジニアであるためある程度ポジショントークが含まれているであろうことも注意が必要です。Epilogue: Kubernetesとデータベースの未来セッションの締めくくりとして、Kubernetes上でのデータベース運用は困難な側面もあるものの、OperatorやDBaaSソリューションの活用により、効率的でスケーラブルな運用が可能になることが強調されています。Kubernetes上でデータベースを運用することは、もはや一部の先進的な企業だけの選択肢ではなく、一般的な選択肢になりつつあります。クラウドネイティブな環境でデータベースを運用することは、ビジネスの俊敏性と競争力を高める上で重要な要素となります。Kubernetes上でのデータベース運用に対する不安や懸念を解消し、その可能性を示す上で非常に有益な内容でした。Percona EverestのようなオープンソースDBaaSソリューションの登場は、Kubernetesにおけるデータベース運用の楽にする選択肢の一つと言えるでしょう。まとめこのセッションを通して、Kubernetes上でのデータベース運用は、進化を続け、成熟しつつあることが理解できました。初期の懸念は解消されつつあり、OperatorやDBaaSソリューションの登場により、運用効率とスケーラビリティが大幅に向上しています。特に定型的なデプロイと運用を自動化できることでデータベースエンジニアはアプリケーション特性に応じた最適化やリリースマネジメントといったユーザーに価値を提供することを最大化することに注力することができます。今後、Kubernetes上でのデータベース運用はさらに普及し、クラウドネイティブなアプリケーション開発の中核を担うことになるでしょう。一定以上の規模の組織ではオンプレ回帰やクラウドコストの最小化といった観点からKubernetes上にデータベースをホストするソリューションが求められ生ます。そのためデータベースエンジニアは、Kubernetesの基礎知識を習得し、OperatorやDBaaSソリューションの活用方法を学ぶことで、より効率的で本質的な業務を遂行できるようになるはずです。

KubeCon NA 2024: When Life Gives You Containers, Make an Open Source RDS: A Kubernetes Love Story のセッションレポート

アプリケーションを開発しているとアプリケーションログの分析や、JSONデータに対する分析など全文検索機能を求められることがたびたびあります。そういった場合はElasticsearchのように全文検索に特化したデータベースを導入することが多いです。しかし単純な文章の検索[^特にトランザクション用途]や小規模に利用される場合ばわざわざ専用のデータベースを管理作りたくないというケースが多いです。今回はPostgreSQLで利用可能な全文検索インデックスの拡張機能であるpg_bigmを紹介します。 検証環境の作成 CloudSQL 構成Cloud SQL EditionsE...

PostgreSQLので全文検索拡張機能、pg_bigmを試す

2024年6月5日にGoogle Cloudがパートナー向けに開催したデータ関連の非公開イベントで「Google Cloud で利用できるRDBのベクトル検索を徹底解剖！」というLTを話しました。https://speakerdeck.com/nnaka2992/google-cloud-deli-yong-dekirurdbnobekutorujian-suo-woche-di-jie-pou非公開イベントのため録画がなかったり、LT枠だった関係で省略してしまった部分があったりしたためブログでより詳細な説明資料のようなものを書きました。 背景Google Cloudが提供する...

Google Cloud主催パートナー向けイベントで「Google Cloud で利用できるRDBのベクトル検索を徹底解剖！」を話しました。

Google Cloud Next '24でGoogle Cloudが提供するすべてのマネージドデータベースにベクトル検索の機能が追加されました。[1]今回はそのなかのCloud SQL for PostgreSQLにフォーカスしてベクトル検索機能を試します。 Cloud SQL for PostgreSQL インスタンススペックエディションEnterprisevCPU2RAM8GBストレージタイプSSDZoneasia-northeast1接続パブリックIPを有効化 必要な設定を行うデータベースを作成す...

Cloud SQL for PostgreSQLのベクトル検索を試す

概要300年ぶりぐらいに、ローカル環境(非Cloud環境)でホストしたOracle Databaseが欲くなったので、自宅にあるProxmoxへインストールします。 前提Proxmoxにダウンロード済みのOracle Linux 9のイメージを利用する。利用するOracle Databaseは19cとする。検証環境のため本番用途に適した設定ではない。 Proxmox VMを建ち上げる Oracle Database 19cのサーバ要件今回関係あるもののみ抜粋しています。OSOracle Linux 9およびRed Hat互換カーネル: 5.14.0-...

Oracle Dataabse 19cの検証環境が欲しいからProxmoxに環境構築する

概要Google Cloudが提供するPostgreSQL互換データベースであるAlloyDBのパフォーマンスをトランザクション用途・分析用途の双方から検証する。今回の検証ではAlloyDBの上限を見定めるのではなく、CloudSQLと比べてどのようなパフォーマンスになるを目的とする。 TL;DR絞り込み条件がインデックスに限定されない場合、AlloyDBのパフォーマンスメリットが特に大きくなる。絞り込み条件がインデックスに限定され、かつデータサイズが小さい場合、CloudSQL for PostgreSQLのコストパフォーマンスが大きくなる。現将・将来のワークロード...

CloudSQL for PostgreSQLのベンチマークと比較して理解するAlloyDBの特徴

PGUnconf #46 でPostgreSQL の開発するときにまず何からすればいいかを聞いてきた概要2024年3月23日に第46回 PostgreSQLアンカンファレンス@東京が開催されました。PostgreSQLアンカンファレンスは日本PostgreSQLユーザー会が主催するイベントでPostgreSQLユーザーはもちろん、PostgreSQLのコントリンビューターやコミッターも参加しているイベントです。その中でPostgreSQL メジャーコントリビューターであり、コミッターでもある@masahiko_sawadaさんが、PGConn 2024でMAKING POSTGRESQL HACKING MORE INCLUSIVEというセッションでPostgreSQLコミュニティーがどうすればより初心者にオープンになれるか？ という内容でディスカッションするそうです。そこに向けてアイデアはあるか？ 困ってることはないか？ という相談？ をされていました。経験豊富な方々は実践的な案を出していましたが、私はPostgreSQLにコードコントリビュートしたいけど何からすればいいのか分らないという状態だったのでこの機会に相談してみました。自分のレベル感Cはすこし読める。すこし書けるPostgreSQLのソースコードはsimple_query_execの関数をひととおり読んで、なんとなくどこで何しているか分かるPostgreSQLのメーリングリストはとりあえず入った何が分からなかったのか？そもそもPostgreSQLはメーリングリストとパッチの文化なのでGitHub/Labなどになれた身からするとよく分からないです。またGitHubで管理されているOSSでは良くあるgood first issueのようなものも存在しないため、新規参入者には難しいと感じていました。なにからすればいいのか？PGUnconfでは以下のようなアドバイスを受けました。チュートリアルをなぞってドキュメント通りに動かないものを修正する初心者向けコンテンツへの追記は初心者にしか出来ないので、是非おねがいしたいとのことでした既存のパッチで放置されているもの(Headでビルドできないようなもの)をアップデートするメーリングリストのディスカッションを眺めてネタを探す新規機能を試してバグをさがし、修正するCommitFestに参加するまとめ1のネタを探してみつつ、PostgreSQL17のリリースが近いので4に取りくんでみようと思います。

PGUnconf #46 でPostgreSQL の開発するときにまず何からすればいいかを聞いてきた

YugabyteDB Managedにフリートライアルがあるのは知っていたのですが、期間が限られたものしか無いと思っていました。YugabyteDBについて調べごとをしていたら機能制限はあるもののSandboxクラスターというクレジットカード登録すら不要でAlways Freeな利用枠があることを知りました。いままでローカルでYugabyteDBを建てたりminikube上で遊んでいたのですが、簡単な検証であればSandboxクラスターで十分です。この記事ではそんなYugabyteDB ManagedのSandboxクラスターを紹介します。 Sandbox Clusterの制限...

YugabyteDB ManagedのAlways Free枠を試そう

みんな振り返りしてる。振り返りしてないのはお前だけ。なので振り返りします。登壇関係2023-06-22 3-shake SRE Tech Talk #6これまで対外向けの登壇は行なったことが無かったのでこれが登壇デビューでした。DBREノススメ所属会社である株式会社スリーシェイクの主催するイベントでしたが、一度登壇すると登壇のハードルが低くなるのでとてもいい機会でした。今の会社にDBREerポジションで入社して6か月目の登壇なので今見ると当時と違う意見の部分もあったりしますが、今もDBREもSREも何なのか分かりません。2023-09-26 YugabyteDB Japan Meetup #3別件でYugabyte Japanの方と話していたところ、登壇してみないか？ と誘われたためホイホイ話しに行った登壇でした。紹介 データベース信頼性エンジニアリングSRETTの方ではSREの存在を認知している方が多いだろうと想定して何故DBREが必要なのか？ という話しをしたのに対して、こちらではDB関係者が多いと想いDBAとDBREという切り口で発表しました。YugabyteDBはドキュメントを始めから読む活動をしていたり(2023年後半はあまり出来ていませんが)、ローカル環境で動かして遊んだりはしていたもののYugabyteDBについて話せるほどの理解は(今も)なく次にYugabyteDB Japan Meetupで話す機会があればYugabyteDBについてを主題に話したいと思いました。2023-10-12 3-shake SRE Tech Talk #76月の登壇と同様に所属会社主催のイベントでした。KubernetesでDBを動かしたい2021年ごろにDBをKubernetesで動かす記事見て以来DB on Kubernetesには興味があったのですが、Kubernetes自体やデータベースのお勉強をしていたらなかなかDB on k8sまでたどりつけていませんでした。それをイベント駆動で無理やり勉強したのがこのイベントでした。内容としてはありきたりですが、Zalando Postgres Operatorを動かしましたというだけのものですが、ここでDB on k8sをさわってからはいろいろな機会でDB on k8sを触るようになりました。2023-12-26 第44回 PostgreSQLアンカンファレンス@オンライン年内最後の登壇はPostgreSQLアンカンファレンスでした。pgrollで実現するスキーマブルーグリーンデプロイメントちょうど登壇しやすいネタを抱えてたのとアドベントカレンダーでそーだいさんが運用・開発よりの話しが足りないと書いていたのを見て、DBREを名乗っているし話さなきゃいけないだろと思ったので登壇しました。もっと運用よりだったりサービス開発だったり設計よりの話も募集中です。 大体そういうの喋る担当が自分だけなのでめちゃめちゃ需要があるので気軽にどうぞ。登壇自体はpodman-composeとdocker composeの差分で悲しいライブデモになりました。検証環境と登壇環境はそろえなきゃいけないなと思いました。ブログ関連はてなブログでは主に読んだ論文やドキュメントについてまとめ、zennでは何かを調べてまとめたものや検証した結果をまとめるように使い分け運用しました。はてなブログでやっているYugabyteDBのドキュメントを全部読む取り組みは途中で止ってしまっているので動かします。zennの方は社内向けに話すもののうち社外に出しても問題ないようなものを垂れ流していましす。2024年は技術検証方面に力をいれたいのでzennを活発に出来たらなと思います。アドベントカレンダーは大風呂敷で畳みきれなかったデータベースエンジニアのためのDB on Kubernetes入門ガイドに始まり、誰得なのかわからないAlloyDB omni on Kubernetesを眺めると続いて、sqldefとpgrollを利用したPostgreSQLでのスキーマブルーグリーンデプロイメントを書きました。ターゲットは誰だったんですかね？まとめ2023年は今までインプット重視だったところからアウトプットを考えだした年でした。これはそろそろアウトプットをしなきゃいけないという思いもあったものの、2023年1月に現職に転職し社外へのアウトプットをする人が多くいたからという面も多大にあります。人は周りの5人の平均になるという言葉があるらしいですが、まさしくその例で環境が変り周りの人が変ったため個人の方向性も変ったのではないかと思います。外部にアウトプットすることが偉いわけではありませんが、外部に発信すると新しい機会も産まれましたし1来年以降も継続していきたいです。↩

2023年の振り返りをする

この記事はこのエントリー以下のアドベントカレンダーの11日目の記事です。3-shake Advent Calendar 2023昨日はtoyb0xによるTODOコメントをチケット管理するためのESLint Custom Ruleでした。PostgreSQL Advent Calendar 2023昨日は@ozozatyによるPostgreSQLのjsonb型でJSONパス式(JSONPath)を使うでした。 はじめにPostgreSQLではDDLはその性質からテーブルレベルでロックを取得してしまいます。SREやPlatform EngineeringなどDev...

sqldefとpgrollを利用したPostgreSQLでのスキーマブルーグリーンデプロイメント

このエントリーは以下のアドベントカレンダーの6日目の記事です。3-shake Advent Calendar 2023 シリーズ1昨日は@bells17さんによるChainguard imagesについて調べてみたでした。PostgreSQL Advent Calendar 2023 シリーズ2Kubernetes Advent Calendar 2023昨日は@yassan168さんによるRKE2ノードのCiliumを使ったeBPFな帯域制限をする話でした。 背景を眺める2023年10月12日にAlloyDB OmniのGAに併せてAlloyDB Omni o...

AlloyDB omni on Kubernetesを眺める

このエントリーは3-shake Advent Calendar 2023 1日目の記事です。株式会社スリーシェイクのメンバーが各々自由に技術・非技術ネタを投稿するカレンダーとなります。 はじめに1959年にW. C. McGeeがデータベースという概念を提唱してから約65年、様々なアーキテクチャのデータベースが提案され様々なプラットフォームで利用されてきました。古くはメインフレームを中心に動作していたデータベースは、マイコンブームとともにそのアーキテクチャを変えながらにオープン系システムへと主戦場を移して行きました。オープン系が主流になってからもその進化は止まることなく、ベア...

データベースエンジニアのためのDB on Kubernetes入門ガイド

前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Read I/O pathを読みました。今回はArchitecture > Core functions > High Availabilityを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。High availabilityYugabyteDBは一貫性と分断耐性を兼ね備えたデータベースであると同時にリーダーの障害時に新しいリーダーとしてフェイルオーバー出来るアクティブレプリカを持つことで高可用性(HA)を達成している。もしノードに障害が発生した場合、そのノード上で動作するYB-TServerとYB-Masterの停止を引き起こす。YB-TServer failureYB-TServerはYSQLレイヤとアクティブなIOを提供するピアーリーダータブレットを含むタブレットをホストする。YSQレイヤとタブレットピアーフォロワーとタブレットピアーリーダーで発生した障害はそれぞれ特別な方法であつかわれる。YQL failureアプリケーションの視点からみればYQLはステートレスである。そのためクライアントが発行したリクエストは単純に他ノードのYQLにリクエストが送信される。スマートクライアントを利用している場合、スマートクライアントは理想的なYB-TServerの場所をタブレットが所有するキーから検索し、リクエストを直接そのノードに転送する。Tablet peer follower failureタブレットピアーフォロワーはクリティカルパスではない。この障害はユーザーリクエストへの可用性に影響しない。Tablet peer leader failureタブレットピアーリーダーの障害は数秒以内にRaftレベルのリーダー選出を自動的にトリガーし、他のYB-TServerに配置されているタブレットピアーが新しいリーダーとして選出される。タブレットピアリーダーに障害が発生した場合、可用性が損なわている時間は約3秒(ハードビートの感覚がデフォルトの500msの場合)である。YB-Master failureYB-Masterは通常のIOオペレーションではクリティカルパスでは無いため、ユニバースを動作させるのに影響は無い。しかしYB-Masterは異るノードで動作するピアーのRaftグループの一部であるため。このピアーのうちの一つがアクティブなマスターで残りがアクティブスタンバイである。YB-Masterのリーダーであるアクティブマスターに障害が発生した場合、ピアーはリーダーの障害を検知し、新なアクティブマスターであるYB-Masterのリーダーを障害時に数秒以内で再選出する。

YugabyteDBのドキュメントを全部読む Day9

前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Write I/O pathを読みました。今回はArchitecture > Core functions > Read I/O pathを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Read I/O pathI/O Pathはタブレットリーダーが特定されリード処理を実行する単一キーの例で説明することが出来る。Tablet leader identificationユーザーが発行したYQLクエリレイヤに作用するリードリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。このユーザリクエストはYQLレイヤで内部キーに変換され、YQLレイヤがタブレットとそれをホストするYB-TServerを発見するのに利用される。YQLレイヤはこれをYB-MasterにたしてRPC呼び出しを実行するために行なう。またそのレスポンスは将来の利用のためにキャッシュされる。その後YQLレイヤはリーダータブレットピアーをホストするYB-TServerに対してリード処理を行なう。このリード処理は内部キーを保持するタブレットのRaftグループのリーダーによって処理される。このリードリクエストを処理するRaftグループのリーダーはDocDBから読み込みを実行し、その結果をユーザーに戻す。Write I/O Pathで説明した通り、YugabyteDBのスマートクライアントではアプリケーションのリクエストを直接適切なYB-TServerに送信することが出来るため、余計なネットワークホップやマスターへのアクセスを省略することが出来る。Read operation performed by tablet leaderkという値をKというプライマリキー行に持つテーブルT1からデータを取得するケースについて考える。またテーブルT1はキー行Kと値行Vを持つものとする。1下記の画像はリード処理について説明している。YugabyteDBはデフォルトでは強整合性の読み取りを採用している。リードクエリはさらに複雑になることもある。YQLクエリレイヤーは式やビルトイン関数、算術演算を含むクエリを処理するfully-optimized2されたクエリエンジンを持っている。SELECT K,V from T1 where K = 'k'ということ↩↩

YugabyteDBのドキュメントを全部読む Day8

前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Table Creationを読みました。今回はArchitecture > Core functions > Write I/O pathを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Write I/O pathWrite I/O pathはYQLレイヤーで処理され、タブレットリーダーによってレプリケーションの準備が行なわれるシングルキーでの書き込みとして例示することが出来る。アトミックなアップデートを共なう複数キーでの分散トランザクションなど複雑なケースについては分散トランザクションに記載する。Write operation processing by YQL layerユーザーが発行したYQLクエリレイヤに作用するライトリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。このユーザーリクエストはYQLレイヤで内部キーに変換される。シャーディングで説明するように、それぞれのキーは一つのタブレットが所有する。どのタブレットがキーを所有するか特定するために、YQLレイヤはYB-MasterにRPC1呼び出しを実行する。そのレスポンスは将来の利用のためにキャッシュされる。YugabyteDBはタブレットの場所をキャッシュし直接参照することでネットワークホップを減らすことで、YQLレイヤが直接適切なYB-TServerにホストされるタブレットリーダーにリクエストを送信することが出来るスマートクライアントを持つ。YQLレイヤがローカルノードにタブレットリーダーを見つけた場合、RPCはローカルファンクションコールになりリクエストをシリアライズとデシリアライズしてネットワーク越しに送信する時間を節約することが出来る。その後YQLレイヤはタブレットリーダーをホストするYB-TServerへの書き込みを発行する。この書き込みはキーを所有するRaftグループのタブレットリーダーによって処理される。Preparation of the operation for replication by tablet leader下記の図はタブレットリーダーがレプリケーションを実行する処理を説明している。タブレットのRaft Groupリーダーは以下の処理を実行する。現在実行されている処理が現在のスキーマに対応しているかを判別するキーに対してローカルin-memoryロックマネージャーを利用してロックを取得する。このロック機構はフォロワーには存在しない必要であればデータを読み込む(read-modify-writeや条件付きアップデート命令など)DocDBに書き込まれる変更のバッチを準備する。この書き込みバッチは殆ど最終的にRocksDBに書き込まれるKey-Valueペアに近く、それぞれのキーの末尾に最終的なhybrid timestampが添えられていないだけであるRaft replication of the write operation書き込みのRaftレプリケーション処理の流れは以下のように説明することが出来る。リーダーがバッチをRaft logにアペンドし、書き込みのためのhybrid timestampを選択するRaftを利用しデータをピアーに複製する成功したRaft replicationのデータをローカルのDocDBに反映するユーザーに成功を返すフォロワータブレットはRaftを利用したデータの複製を受けつけ、コミットされた事が分ったタイミングでその複製をローカルのDocDBに反映する。リーダーは以下のようにコミットポイントに於ける後続のRPCリクエストの進行を進める。書き込みバッチを含むRaftエントリーは過半数以上のタブレットRaft Groupピアーに複製されるRaftのサブシステムから"Replication Successful"のコールバックを取得したあと、リーダーはローカルのDocDBにバッチの書き込みを適用するリーダーからの次の更新でエントリーがコミットされたことがフォロワーに通知され、フォロワーはそれぞれのRocksDBインスタンスにバッチの書き込みを適用する。Response to the clientInformation Pending2Exampleskとvという値をKという行とVという行をもつテーブルT1に挿入する例について考える3。この例ではユーザーアプリケーションがランダムなYugabyteDBサーバにWriteクエリを送信し、そのサーバがリクエストを適切にルーティングすると仮定して簡略化している。特にYCQLではYugabyteDB Smart Clientを使うことで、余分なネットワークホップを避けることが出来る。↩原文ママ。過去のバージョンでも記載無し↩INSERT INTO T1 (K,V) VALUES('k','v')ということ↩

YugabyteDBのドキュメントを全部読む Day7

前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Universe creationを読みました。今回はArchitecture > Core functions > Table Creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Table CrationYugabyteDBではユーザーにより実行されるテーブルの作成はYB-Masterのリーダーが実行する非同期APIによって管理される。YB-MasterはそのAPIでテーブルのスキーマと障害耐性を高めるために形成するRaftグループに所属するYB-Masterでのテーブル作成に必要な他の情報のレプリケーションが完了した段階でAPIの成功を返す。YB-Masterのリーダーがテーブル作成を実行するときは複数のステップが存在する。ValidationYB-Masterリーダーはテーブルスキーマの検証を行ない、指定された数のタブレットを作成する。これらのタブレットはこの段階ではYB-TServerには割り振られていない。ReplicationYB-MasterリーダーはYB-MasterのRaftグループにテーブルスキーマと新しく作成されたタブレット(この時点ではYB-TServerへの割り当て行なわれていない)の複製を行なう。この処理はYB-Masterリーダに障害が発生してもテーブル作成が成功することを保証する。Acknowledgementテーブル作成処理はYB-Masterリーダーに障害が発生しても処理を継続することが出来るため、この段階で非同期テーブル作成APIは成功を返す。ExecutionYB-Masterリーダーはそれぞれのタブレットをレプリケーションファクターとして指定された数だけYB-TServerに割り当てを行なう。このタブレットピアーの配置は指定された障害耐性を実現でき、またタブレットの割り当てがYB-TServerに均等に行なわれるように実行される。タブレットのYB-TServerへの割り当てはタブレットのレプリカが複数クラウド、リージョン、アヴェイラビリティゾーンをまたいで分散するといった追加の制約を満す必要がある。Continuous monitoringYB-Masterリーダーは全てのタブレットの割り当て処理を監視し、その実行状態と完了をユーザーが実行したAPIコールに対して応答する必要がある。Examplesテーブルが4ノードからなるYugabyteDBUniverseに作成される処理について考える。このときテーブルは16のタブレットと3つのレプリケーションファクターを持つとする。YB-Masterリーダーはスキーマを検証する。また16タブレット(合計48のタブレットピアー)を作成し、Raftを利用して過半数のYB-TServerにテーブルの作成に必要なデータを複製する。作成したタブレットをRaftグループを成すYB-TServerの中の指定された数のYB-TServer割り当て、リーダーの選出を行なう。このタブレットに属するキーに対する全てのリードとライトは、タブレットピアーのリーダーとRaftグループが責任を持つ。タブレットが割り当てられると長期に渡る障害か将来のロードバランシングが発生しYB-Masterにオーナーシップを変更されるまで、割り当て先のYB-TServerが所有する。タブレットリーダーをホストするYB-TServerの内の1台に障害が発生した場合、タブレットのRaftグループはI/Oを処理するために即座にリーダーエレクションを実行する。そのためYB-MasterはI/Oにおけるクリティカルパスになることはない。レプリケーション先となる候補を探す。この複製処理は段階的かつGracefulに実行される。

YugabyteDBのドキュメントを全部読む Day6

前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > YB-Master serviceを読みました。今回はArchitecture > Core functions > Universe creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Universe creationYugabyteDBのユニバース作成は複数のステップを含む。Start YB-MastersYBユニバース作成の最初のステップはレプリケーションファクターで指定された数だけYB-Masterを作成することである。作成されたYB-Masterはそれぞれを認識している。YB-Masterはユニバース内でユニークなID(UUID)をそれぞれに割り当て、それぞれを認識しあったあとにリーダーエレクションを実行する。このステップの終りにYB-Masterの中のひとつがリーダーとして確立される。Start YB-TServersノードの数だけYB-TServerを起動し、それぞれにマスターのアドレスを渡す。それぞれのYB-TServerはマスターにハートビートを送信し、正常に動作していることを確認する。ハートビートはYB-TServerが現在ホストしているタブレットとその負荷情報についても通信するが、この時点ではタブレットにデータは登録されていない。Examples4ノードからなるYBユニバースにテーブルを作成する場合について考える。テーブルのレプリケーションファクターは3とする。3つのマスターがcreateモードで起動される。これはマスターがすでに起動しているために発生するエラーを防ぐために明示的に実行される。リーダーエレクションを実行し、リーダーを選出する。YB-TServerが起動し、全てのYB-TServerがマスターにハートビートを送信する。

YugabyteDBのドキュメントを全部読む Day5

前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > YB-TServer serviceを読みました。今回はArchitecture > Key Concepts > YB-Master serviceを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。YB-Master serviceYB-Masterサービスはテーブルやそのタブレットの場所、ユーザー・ロールの権限といったシステムのメタデータとレコードの管理を行っている。それに加えYB-Masterはロードバランシングやレプリケーションの開始といったバックグラウンドオペレーションの管理や、テーブルのCREATEやALTER、DROPといった様々な管理オペレーションの責任を持つ。YB-MasterはRaft Groupを組むことで高可用性を実現し、またテーブルに対するI/Oの単一障害点にならない。Functions of YB-MasterYB-Masterはシステムの重要な機能を複数持っている。Coordination of universe-wide administrative operationsCREATE TABLEやALTER TABLE、DROP TABLEといったユーザーからのリクエスト処理やバックアップの実行などUniverseをまたぐオペレーション実行の調整を担当している。YB-Masterではこれらのオペレーションがテーブルを保持するYB-TServerの状態に関わらず、全てのテーブルに伝搬されることを保証する。YugabyteDBは分散システムのため、Universeをまたぐ処理中にYB-TServerに障害が発生し一部のタブレットへの適用に失敗してもオペレーションの結果に問題が発生しないことが重要だからである。Storage of system metadataそれぞれのYB-Masterではネームスペースやテーブル、ロール、パーミッション、YB-TServerへ割り当てたテーブル情報を含むシステムメタデータを保存している。これらのシステムレコードはYB-Masterを対象にRaftグループを組みレプリケーションすることで冗長性を実現している。またシステムレコードはYB-Masterが管理するDocDBに保存される。Authoritative source of tablet assignments to YB-TServersYB-Masterは全てのテーブルとそれらをホストするYB-TServerの情報を保存している。一般のクライアントではそれらの情報はクライアントからクエリレイヤなどを通して取得された上で、クライアントにメタデータを返しデータアクセスが行なわれる。一方でスマートクライアントではYB-Masterに保存されたメタデータを利用して特定のYB-TServerが保持するタブレットやキャッシュを利用することが出来るため、データアクセス時のネットワークをまたぐ通信を減らすことができパフォーマンスを高めることができる。Background operationsいくつかのオペレーションはUniverseのライフタイムを通してバックグラウンドで行なうことで、フォアグラウンドのRead/Writeに影響を与えずに実行することが出来る。Data placement and load balancingYB-MasterのリーダーはCREATE TABLE時にタブレットの初期配置をYB-TServerをまたいで行なう。そのときにユーザー定義のデータ配置制約を強制し均一な読み込みを保証する。Universeのライフタイム中のノード追加や障害が発生しても、負荷分散を継続しデータ配置の制約を自動的に適用する。Leader balancing複数のYB-TServerに配置されたタブレットへのアクセスがUniverseをまたいで分散されることを保証している一方で、YB-Masterは対象となるノード1間でそれぞれのノードが同じ数のtablet-peer leader2をもつことを保証する。Rereplication of data on extended YB-TServer failureYB-Masterは全てのYB-TServerからハードビートシグナルを受け取ることでYB-TServerの死活監視を行なっている。そしてYB-MasterはYB-TServerの異常を検知したときに、どれぐらいのあいだYB-TServerが異常であったかを追跡する。閾値を超えると、YB-Masterは障害中のYB-TServerに配置されていたタブレットを再配置するYB-TServerを探し、レプリケーションを実行する。レプリケーションはYB-Masterリーダーに抑制された状態で実行されるため、Universeのフォアグラウンドオペレーションには影響をおよぼさない。Raft Groupのリーダーになれるノード↩↩

YugabyteDBのドキュメントを全部読む Day4

YugabyteDBのドキュメントを全部読む Day3前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > Universeを読みました。今回はArchitecture > Key Concepts > YB-TServer serviceを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。それはそれとして技術系の単語をカタカナ表記で誤魔化していて、体系的に学んでいないことがバレてしまう。特にストレージまわりが分からない……YB-TServer serviceYB-TServer(YugabyteDB Tablet Servcer)はユーザからの受けつけたYugabyteDBクラスタへのリクエストのI/Oの処理をする。テーブルのデータは一つ以上のTablet peerに分割(シャーディング)される。peerの数はレプリケーションファクターによって決定される。YB-TServerは一つ以上のTablet peerをホストする。Tablet peerはRaftグループを形成してグループ間でデータの複製を行ない、タブレットはYB-TServer上で最大の効率になるように管理される。Server-global block cacheブロックキャッシュは一つTB-TServer上の異なるタブレット間で共有される。YB-TServerのメモリ効率は一つのテーブルからの読み込みが多いほど最適化される。Space AmplificationYugabyteDBではSize-tired Compactionというライトアンプリフィケーション1が小さい圧縮方式を利用している。Size-tired Compactionはスペースアンプリフィケーション2が大きいという問題があるが、YugabyteDBではテーブルは複数のタブレットに分割され、タブレット間でのConcurrent Compactionは特定の最大値まで絞られるため問題になりにくい。YugabyteDBでは凡そ10-20%のスペースアンプリフィケーションにおさまる。つまりSize-tired Compaction一単位が扱うデータ量を小さく(タブレット化)して、同時に実行される圧縮処理数を絞ることで特定のタイミングで圧縮に使用されるストレージ容量を抑えているということ？Throttled compactionsYB-TServerではタブレット間で実行される圧縮処理の同時実行数を制限することで、圧縮処理が多量のリソースを占有することを防いでいる。この機能は圧縮されるファイル同士のサイズを比べ、実行される圧縮処理が妥当であることを確認することで実現されている。Small and large compaction queuesYB-TServerでは圧縮処理を大きい圧縮処理と小さい圧縮処理に分けて優先度を決めることで、I/Oが大きな場合でもシステムの機能を保っている。YugabyteDBでは圧縮処理数を制限することに加え、様々な最適化を実行することで圧縮処理の影響を最小化している。Manual compactionYugabyteDBではyb-admin utilityのcompact_tableコマンドにより、任意のタイミングでテーブルに対して圧縮を実行することが出来る。この方法はデータが新しく書き込まれない場合や、DDLやTTLの超過によるデータ削除時によりデータが断片化したときに有効である。Statistics-based full compactions to improve read performanceYugabyteDBでは読み込まれたkey-valueペアをDocDBレベルで監視している。監視対象となる時間軸はauto-compact-stat-window-secondsで管理されている。YugabyteDBがデータ読み込み時に多量の廃棄されたデータのスキップを検知した場合、full compactionがトリガーされ不要なキーの削除が行なわれる。Full compactionがトリガーされる詳細な条件は対象の時間軸で以下が満された時である。廃棄されたキーとアクティブなキーが読まれる割り合いがauto-compact-percent-obsoleteで定義された閾値を超たとき。廃棄されたキーの読み込みauto-compact-min-obsolete-keys-foundで定義された閾値を超たとき。この機能はTTLを設定したテーブルと互換性があり、TTL file expirationが有効なテーブルではスケジュールされた圧縮を実行しない。Scheduled full compactionsYugabyteDBでは全てのデータに対するデータ圧縮をスケジュール実行することが出来る。スケジュール実行はscheduled-full-compaction-frequency-hoursとscheduled-full-compaction-jitter-factor-percentageのフラグで管理される。この機能は大量のDELETEとUPDATEを定常的に実行するワークロードでのパフォーマンスとディスクスペースの再割り当てに有効である。スケジュール化したデータ圧縮はTTLと互換しているが、TTL file expirationとは互換していない。つまりスケジュールされた圧縮は実行されない。Server-global memstore limitServer-global memstore limitは一つのYB-TServer上のタブレット間でシェアされるメモリサイズを追跡し、強制する。この機能はタブレット間の書き込みに偏りがある場合に有効である。一つのテーブルに書き込みが集中しているばあい、メモリ制限以上のメモリを割り当てることでパフォーマンスを向上させることが出来る。Auto-sizing of block cache and memstoreBlock Cacheとmemstoreは何れも多量のメモリを使用している。これらはtablet-peer間で共有されるリソースのため、メモリ管理とこれらのコンポーネントの様々な環境に合せたサイジングを容易にしている。YB-TServerでは自動で特定の割合のメモリをBlock CacheとMemstoreに割り当てる。Distributing tablet load uniformly across data disks複数のSSDを利用するハードウェアでは、テーブルのデータ(SSTable)とWALはテーブル毎に利用可能なディスクに均等に分散される。このストライピングと呼ばれる負荷分散は、それぞれのディスクがそれぞれのテーブルの負荷を均等に処理することを保証する。SSDで実際に書き込んだデータより書き込み量が増幅する現象。もちろんライトアンプリフィケーションが小さいほうが望ましい。↩↩

YugabyteDBのドキュメントを全部読む Day3

YugabyteDBのドキュメントを全部読む Day2前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Design goalsを読みました。今回はArchitecture > Key Concepts > Universeを読みます。また画像は同ドキュメントより引用しています。UniverseYugabyteDBは耐久性とスケーラビリティを兼ねそなえた分散データベースを達成するために、Universe1と呼ばれるノードのグループを持っている。Universeはビジネス要件やレイテンシの兼ね合いでシングルゾーン、単一リージョンマルチゾーン、マルチリージョン、同期・非同期レプリケーションなどを選択することが出来る。UnivereはClusterと表現されることもある。データの構成Universeは一つ以上のネームスペースを持つことができ、またネームスペースは一つ以上のテーブルを持つことができる。YugabyteDBではUniverse上に存在するノードにまたがって保持されるテーブルを設定に従って、シャーディングし、レプリケーション、ロードバランシングを行なう。YugabyteDBはノードやディスク、ゾーンなどに発生した障害に自動で対応し、必要であればデータを新規に分散、レプリケーションを行なう。ネームスペースはYSQLではデータベースに対応し、ほかのDBにおけるネームスペースに対応する2。YCQLではキースペースに対応し、Cassandraのキースペースに対応している。サービスコンポーネントUniverseはYugabyteDB Tablet Server(YB-TServer)とYugabyteDB Master Server(YB-Master)の二つで構成されている。YB-MasterとYB-TServerはRaftにより分散されており、高可用性を達成している。YB-Tserverはテーブルを始めとしたユーザーデータの保存、提供を担当する。YB-Masterはシステムのメタデータを管理し、システム全体のテーブルに対するDDLやメンテナンスの実行、ロードバランシングといったオペレーションを管理する。UniverseとClusterUniverseは一つのプライマリクラスタとゼロ個以上のレプリカクラスタによって構成されている。プライマリクラスタプライマリクラスタはRead/Write両方の実行と、プライマリクラスタ内のノード間の同期的なレプリケーションを担当する。リードレプリカクラスタリードレプリカクラスタはRead処理のみを実行する。Write処理は自動的にプライマリクラスタにルーティングされる。リードレプリカクラスタを利用することで、地理的に分散したデータに対する読み取りの遅延を小さくすることができる。データはプライマリクラスタから非同期的にとりこまれる。これはRaftの書き込みには関与しないRaftオブザーバとして機能する。GoogleのCloud Spannerでも同様にUniverseと呼ばれている↩PostgreSQLではSchemaの裏側に存在するデータ構造↩

YugabyteDBのドキュメントを全部読む Day2

Day1最近Twitter改めXで「俺はDBのドキュメント端から端まで読んで強くなった」というX's1を複数みかけました。周りのエンジニアに一歩差をつける方法として、フレームワークやミドルウェアやライブラリのドキュメントを最初から最後までちゃんと読む、というのがあって、これはマジでコスパ抜群です。— 徳永広夢 (@tokuhirom) July 21, 2023 確かに私のRedisはこれ。 https://t.co/2y1E01aLGw— maru (@maruloop) July 22, 2023 私のMySQLもこれ。 https://t.co/BxiOjeQVPk— yoku0825 (@yoku0825) July 22, 2023 俺のpostgresqlもこれ。 https://t.co/URRjyXCpGI— そーだい@初代ALF (@soudai1025) July 22, 2023 PostgreSQL系NewSQLで最強になりたいのでYugabyteDBのドキュメントを順番に読んで行きます。ドキュメントはv2.19に対応したものです。手始めにArchitectureの一番先頭にあるDesign goalsから読みはじめます。また画像は同ドキュメントより引用しています。Design goalsYugabyteDBは以下を達成することを目標としている。1. 分散トランザクションを提供しながら強い一貫性を保証する。2. Query APIを再発明せず、既存のクエリ言語への互換を達成する。3. 高いパフォーマンスを保証する。4. 地理的に分散したデプロイを可能にする。5. Cloud Native Databaseとしてデザインする。一貫性分断耐性YugabyteDBはCAPの定理で言えばCPを中心に高い可用性を供えたデータベースネットワーク分断などを起因とするSplit BrainはRaft Group内であたらしいリーダーを選出することで対応している。YugabyteDBではLeader Leaseという障害が発生しても常に一つのリーダが存在することを保証する仕組みを実装している。直列化可能性single-row Linearizable writeをサポートしている。ACIDトランザクションYugabyteDBではSeriarizable、Repetable Read、Read Committed Isolationの三つの分離レベルをサポートしている。YSQL APIではこれら3つの分離レベルをサポートしているが、YCQLではRepeatable Readのみに対応している。Query APIYugabyteDBではYSQLとYCQLという2種類のQuery APIをサポートしている。YSQLYSQLはPostgreSQLに互換したAPIでPostgreSQLのクエリレイヤを再利用している。新しい変更は互換性を崩さない。YSQLは新しいPostgreSQLに互換しつづけることを目標としている。YCQLYCQLはCassandraのクエイ言語から派生した半リレーショナルなクエリ言語で、Webスケールな膨大なwriteに対応してスケールし素早いデータ取得を目標としている。パフォーマンスC++で実装されているため高いパフォーマンスと巨大なHeap(RAM)をCacheとして利用できる。SSDとNVMeに最適化している。高いWriteスループットとクライアントの同時実行性、高いデータ密度、増加し続けるデータへの対応を目標としている。地理的分散Zone、Multi Region、Multi Cloudいずれにも対応している。これに対応するために、ノード障害やトラヒックのルーティングなどに対応できる必要がある。クラウドネイティブアーキテクチャパブリッククラウドやオンプレミスで利用される一般てきなハードウェアで利用可能にする。原子時計のような特別なものに依存しない。Kubernatesに対応している。OSSで提供している。https://twitter.com/SawyerMerritt/status/1683365478582951936↩

YugabyteDBのドキュメントを全部読む Day1

Google CloudではPublic IPを利用した際に割り振られる可能性のあるCIDRの一覧がcloud.jsonでJSON形式で公開されています。この記事は雑な検証用のTerraformで承認済みネットワークにasia-notheast1のCIDRを全部登録してやろうとしたとき、上記のJSONファイルからscopeがasia-northeast1のprefixes.ipv4Prefixを抜きだそうとしたときにハマったのでその対応方法のメモです 結論以下のような感じで書いたら対応できました。contains(keys(hoge), "fuga") # hogeのkeyにh...

Terraformでmapにkeyが含まれないときにスキップしたい

クラウドを利用する一番のメリットの一つとしてオンデマンドでリソースを調達し、アクセス負荷に応じてスケールイン・アウト出来ることが上げられます。そのため大体のアプリケーションではシングルリージョンまたは隣接するリージョン2~3程度で運用を始めることが多いと思います。(日本の場合asia-northeast-1とasia-northeast-2など)アプリケーションがグローバルに拡大すると、それだけ物理的な距離が広がりユーザ・サーバ間のアクセスにかかる時間が拡大します。例えばユーザ・サーバ共に日本にある場合(沖縄・北海道間約3,000km)、ネットワークによる遅延は片道約15ms以下...

光に負けルナ~Google Cloudでのマルチリージョンデータベースについて~

GitHub Copilot便利ですね。2021年にTechnical Previewとして発表された時から便利だ便利だと言われていたGitHub Copilotに、2023年の4月末ごろからデビューしました。デビューしたは良いものの最近は仕事ではコーディングよりアーキテクト的な方面でのお仕事が多かったり、個人の時間でもコーディングするよりOSSのコードを読むことのほうが多くコーディングのアシスタントツールとしては使いこなせていません。そのため最近はPostgreSQLのコードを読むときのアシスタントとして利用することが多いです。なのでこの記事ではCopilotでコードリーディン...

Copilotでらくらくコードリーディング

今年に入ってからCarnegie Mellon UniversityのAdvanced Database SystemsでReading Assignmentとして出ている論文リストで必須とされているものや講義資料を読みました。https://nnaka2992.hatenablog.com/archive/category/論文この記事では紹介されていた論文やAdvanced Database Systemsの講義資料・動画を振り替えることで、BigQueryやRedShift、Snowflakeといった最新の分析用データベースがどのように優れたパフォーマンスを実現しているかを考え...

OLAPデータベースを支える技術

この記事の趣旨2020年に発表されたBigQueryの元となったGoogle内で利用されている分析向けデータベースであるDremelの実装を解説した論文を読みました。Dremel: A Decade of Interactive SQL Analysis at Web Scale著者についてSergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shivakumar, Matt Tolton,Theo Vassilakisら2010年のDremel発表論文の著者らと、Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, Jeff ShuteらGoogleで分析ワークロードと分散処理に関わる著者らによる論文。概要BigQueryの元となったGoogleのDremelの10年間を振り替えってアーキテクチャについて説明した論文。Dremelは現代のクラウドネイティブ分析ツールで一般的になっている、計算リソースとストレージの分解、カラムナストレージ、in situデータ分析などを統合した最初のツールである。手法SQLの採用Googleでは殆どのデータはBigTableなどNoSQLデータベースで管理されていたため、SQLを用いないデータアクセスが主流であった。しかしトランザクション型ビッグデータシステムにおける、SQLの採用に共ないDremelでもSQLを採用した。ストレージの分離メモリの分離MapReduceのシャッフルのボトルネックを回避するためにDisaggregated Memory Shuffle Systemを採用した。In situデータ分析への対応DBMSへのデータロードを必要としないデータ分析のことで、DremelではGFSに移行するときにGoogle内で共有のストレージフォーマットを使用することでGoogle内のデータに対応した。加えてGoogle Cloud StorageやGoogle Drive、MySQL、BigTableなどからのデータ取得もフェデレーションとして対応した。サーバレスアーキテクチャフォールトトレラントリスタート、仮想スケジューリングユニットによりマルチテナントかつオンデマンドなリソースを提供可能とし、低価格な利用を可能とした。現在ではサーバレスアーキテクチャを進化させ、集中型スケジューリングやShuffle Persistent Layer、柔軟なDAG実行、動的クエリ実行などを実装することでより優れたサーバレスアーキテクチャを実現した。ネストデータにおけるカラムナストレージ[[32])]Figure 5Figure 6Figure 7クエリレイテンシの最小化インタラクティブな実行のレイテンシは大きくなる。それを解決するためにDremelではスタンバイサーバプール、マルチレベル実行ツリー、列指向スキーマ表現、CPUとIO負荷のバランス調整、ファイルオペレーションの再利用、保証されたキャパシティ、適合的なクエリスケーリングにより実現している。作業時間read27:5027:50author32:024:12summary68:5026:48

現在のDremelの実装を解説した論文を読みました 

はじめにこの記事ではNewSQLの特徴であるノード間の分散とトランザクションや分断耐性などがTiDBではどのような技術によって実現されているかを説明することを目的としています。Spannerの論文が2012年に発表されてから10年以上の年月が流れ、優れた論文や実装ドキュメント、個人による解説ブログなど技術的詳細について述べた資料は多くあります。加えてこの記事を入門的なものと位置づけているため各コンポーネントを網羅的に解説するというよりは、キーコンセプトをどのように実装しているのかを実験を混じえながら動作の実現方法の解説を中心に扱います。また今回はTiDBをベースに説明し...

TiDBで学ぶNewSQLのアーキテクチャ for Beginners

この記事の趣旨2015年に発表されたクエリオプティマイザにおけるカーディナリティ推定とコストモデル、列挙アルゴリズムの貢献度を評価した論文を読んでいきます。How Good Are Query Optimizers, Really?著者についてViktor Leis、Andrey Gubichev、Atanas Mirchev、Peter Boncz、Alfons Kemper、Thomas Neumannらのグループによる論文。ほとんどのメンバーはDBMSにおける最適化について研究しているが、Atanas Mirchevはより統計や探索といった最適化よりの研究をしている。問題意識良い結合順序を見つけることはクエリの性能に対して大きな影響を与えるため、熱心に研究されてきた。古典的なクエリ最適化のアプローチでは以下のステップで動的計画方に基づいた最適化を行なう。1. 有効な結合順序の列挙1. カーディナリティ推定値を入力としたコストモデルの選択理論的にはカーディナリティとコストモデルの推定値が正確であれば、最適なクエリプランを選択することができる。しかし現実にはカーディナリティ推定は一様性や独立性といった単純化された仮定に基づいており、しばしばそのような仮定は間違っているため悲惨な計画を作成する。手法この論文ではカーディナリティ推定器の評価と正確なコストモデルの重要性の評価、そして列挙された結合順序の空間がどの程度影響するのかを以下の方法で検証し、貢献を行なっている。1. IMDBデータを用いたJoin Order BenchmarkというJOINにフォーカスしたベンチマークによる評価を行なう1. 実世界のデータセットにおける現実的なクエリを用いたE2Eの検証を行なう。1. クエリ性能に対するカーディナリティ・コストモデル・列挙アルゴリズムの貢献度を定量化し、最適なクエリプラン生成のためのガイドラインを策定している。作業時間read29:3829:38author33:083:30summary48:4414:36感想時間が無くまとめ途中で切り上げてしまった。やらないよりマシではあるものの、ちゃんと纏めるときにくらべて理解度に影響が出そうなので時間に余裕を持っておきたい。内容自体はGW中にPostgreSQLの実装を読んでいたこともあり、わりと理解しやすかった。

クエリオプティマイザの精度を検証した論文を読みました

この記事の趣旨1998年に発表されたクエリオプティマイザの基礎としてとくに重要な手法をまとめた論文を読みました。An Overview of Query Optimization in Relational Systems著者についてSurajit Chaudhuriによる論文Microsoft所属の研究者でRDBMSの研究を行なっており、近年ではCloudにおけるDBMSの研究を行なっている。概要RDBMSが提案された1970年代からクエリ最適化は大規模で幅の広く研究が行なわれてきた。この論文では執筆当時(1998年)までの重要な研究の基礎を説明している。手法探索空間統計情報とコストの推定列挙アルゴリズムアルゴリズムについて説明している。論文内では拡張可能なオプティマイザとして、StarburstとVolcano/Cascadeの2種類のオプティマイザの詳細を論じている。最新(当時)の最適化リアライズドビューについて説明している。作業時間read31:4031:40author33:402:00summary52:5519:15感想ベクトル化やパラレルジョインで扱われていたVolcanoオプティマイザの端に触れることが出来ました。内容としては基礎的な内容が多いものの、知らない概念もいくつかあり引用している論文も読みたいです。クエリ最適化の基礎を学ぶのに非常にいい内容でした。

現代のクエリオプティマイザの基礎となる技術をまとめた論文を読みました

この記事の趣旨2017年に出版されたリモートDBMSとクライアント間の大量データ転送を最適化する手法を提案する論文を読みました。Don’t Hold My Data Hostage – A Case For Client Protocol Redesign著者についてMark Raasveldt、Hannes Muhleisenらのグループによる論文。いずれもCentrum Wiskunde & Informaticaの所属で、DuckDBのCxO。DBMSと分析システムにおけるパフォーマンス最適化を研究している。問題意識DBMSからクライアントプログラムに大量のデータを転送することは一般的なタスクである。例えばRやPythonなどを用いた分析システムはしばしばデータベース・インターフェースを利用してデータの取得を行なっている。一方でネットワーク越しにデータを転送することはレイテンシを増加させ、転送時間を長引かせる要因である。そのため分析用途で大量のデータ転送を避け、一部のデータをサンプルとして利用するに止まることが多い。このアプローチはパフォーマンスの低下を押さえられるものの、分析や機械学習の精度を下げることに繋がる。とくに既存のクライアントではネットワークによるレイテンシとスループットの制限に大きな影響を受けパフォーマンスを劣化させる。この問題はデータベースが別マシンやクラウドで動作するときにより大きな問題となる。手法本論文では既存のシリアライズ手法と圧縮手法によるパフォーマンスへの影響を計測し、新しいプロトコルとして以下の特性を持つ手法を提案している。1. チャンク毎のデータ転送と(デ)シリアライゼーション1. ヒューリスティックによる圧縮方法の決定1. text/binaryによるカスタムシリアライゼーションを使用する1. NULL終端によるテキストの取り扱い実験結果提案手法を実装したMonetDB(表内ではMonetDB++)とPostgreSQL(表内ではPostgreSQL++)を既存のDBMSやnetcatと比較することで評価を行なっている。TCP-Hのlineitem、American Community Survay、Airline On-Time Statisticsの3つのデータセットで評価を行なったところ、ローカル通信における非圧縮netcatを除き殆どのケースでMonetDB++系が最良のパフォーマンスを発揮し次点でPostgreSQL++系が優れた結果を残している。Table 10Table 11Table 12PostgreSQLに比べMonetDBが優れている理由はPostgreSQLの行指向データを列指向に変換するコストのためである。作業時間read31:2131:21author35:384:17summary70:1334:35感想論文出版時にはTPC/IPプロトコルが前提でQuic登場前のため、ネットワークプロトコル自体は考慮されていない。現在であればTPC/IPとQuicに適合した手法の比較が行なわれると思うので気になるところ。

DBMSとクライアント間におけるデータ転送を最適化する論文を読みました

この記事の趣旨2017年に発表されたSQL ServerでUDFを最適化しているFroidという手法についての論文を読みました。Froid: Optimization of Imperative Programs in a Relational Database著者についてKarthik Ramachandra、Kwanghyun Park、K. Venkatesh Emani、Alan Halverson、Cesar Galindo-Legaria、Conor Cunninghamのグループによる論文。ほとんどの著者はMicrosoftに所属しており、いずれもトランザクショナルワークロードでのRDBMSの最適化や分析ワークロードにおけるRDBMS最適化の研究をしている。問題意識RDBMSではSQLによるデータ処理アプローチと、UDFやストアドプロシージャなどによる命令型のデータ処理アプローチを提供している。SQLによるデータアクセスは高度に最適化されてきた一方で、命令型のデータ処理は非効率なため性能を阻害し利用を禁止している組織すらある。UDFによるデータアクセスは非効率であるものの、SQLに比べ下記のような利点を提供するため幅広く利用されているのも事実である。1. SQL間でコードの再利用方法を提供する1. 複雑なビジネスロジックやMLアルゴリズムなどSQLでは難しい表現を可能にする1. 単純なSQLの組み合わせのため、ユーザーの意図が明確に表現できるこれらのメリットを享受するためにRDBMSにおける命令型データアクセス手法のパフォーマンスを向上しする必要があった。手法提案手法であるFroidはMicrosoft SQL Serverにおける命令型コードのパフォーマンス向上の手法として、UDFを複雑なサブクエリとしてみなすアプローチを取っている。UDFを構成する命令はDECLARE、SELECT、IF/ELSE、RETURN、他のUDF、リレーショナルオペレーションの6つに分ることができる。提案手法ではこれらの命令を一般的なT-SQLに置き換え、Apply演算により一つの関係式に結合する方法で実現している。Table 1命令が一般SQLに置き換えられることでUDFに対して、SQLに用いられていた高度な最適化を導入することが出来る。また提案手法ではい以下の理由から、SQLとして命令を置換するときにクエリ最適化時に行なうのではなくバインド時に置換をしている。1. 実際のワークロードでの実験ではほぼ全てのケースでバインド時のほうが性能がよかった1. クエリオプティマイザの変更が不要1. バインディング時に特定の最適化を行なえるとくにクエリオプティマイザの変更はSQL Serverが商用データベースなため重要であった。作業時間read28:5028:50author32:103:20summary57:0024:50

SQL ServerにおけるUDF最適化の論文を読みました

この記事はDBMSの登場以前から現代のDBMSを取り巻く環境までを振り返ることで、なぜNewSQLが必要とされ登場したのかをまとめます。 おことわり筆者はあくまでDBMSユーザーであり、研究者ではないため内容は個人の見解です。また対象読者はある程度DBMSに関わりがあり、OLTPやOLAP、列指向や行指向といった基本的な単語を理解しているものとします。またNewSQLの技術的詳細はスコープ外とします。 DBMS以前データベースという言葉は1950年代に米軍が情報基地を集約したことに由来します。一方で学術的なデータベースの起源はW. C. McGeeが1959年に発表...

DBMSの歴史とNewSQL

この記事の趣旨2018年に発表された分析ワークロードなどで発生しがちな最終結果に比べ、非常に大きな中間結果を作成してしまうクエリを多方向結合で最適化する論文を読みました。Adopting Worst-Case Optimal Joins in Relational Database Systems著者についてMichael Freitag、Maximilian Bandle、Tobias Schmidt、Alfons Kemper、Thomas Neumannによるグループの論文いずれの著者もDBMSにおける最適化を中心に研究しており、それぞれ分析ワークロードにおける最適化や最新のハードウェアにおける最適化などを研究している。問題意識従来のRDBMSにおける結合処理のほとんどはバイナリ結合に依存して複数のリレーションにまたがるクエリを処理してきた。数十年に渡る研究によりバイナリ結合は幅広い柔軟性と優れた性能を発揮するようになった。その一方でバイナリ結合による実行計画は特定のワークロードでは最適ではないケースを示すことが知られている。主な原因として実際のクエリ結果に比べて非常に大きな中間結果を生成するためである。とくにPK以外のキーによる結合が多くなる分析ワークロードではそのような状態を避けることが難しく、またグラフ分析のようなクエリパターンでも多く見られる。近年の論理的な進歩により中間結果の列挙を避ける多方向結合のアルゴリズムが開発可能になった。この手法はバイナリ結合計画より優れた実行時間を保証できるため、RDBMSの堅牢性を大幅に向上させる可能性を持っている。しかし現状最悪ケース最適化結合アルゴリズムでは以下のような問題を抱えている。1. 膨大なストレージとメンテナンスを必要とする結合に参加出来るカラムを含むインデックスを必要とする。1. RDBMSは挿入と更新のサポートが必要なものの、既存のアルゴリズムは高価な事前計算を必要とする。そのため本論文は以下の制約を満たすアプローチを提案している1. 多方向結合が有益な場合のみ多方向結合を使用するオプティマイザを必要とする。1. 実行中に効率的に実行でき、ディスクのに永続化する必要のないパフォーマントインデックスを必要とする。手法提案手法では比較ベースではなくハッシュベースの結合のため、2の「実行中に効率的に実行でき、ディスクのに永続化する必要のないパフォーマントインデックスを必要とする。」という要素の考慮を除いている。またオプティマイザについては既存のコストベースのものを拡張し適応している。提案手法では潜在的に成長している結合のカスケードを最悪の場合の最適結合に置き換えることで、最適化されたバイナリ結合計画を洗練させるヒューリスティックなアプローチを提案している。通常の結合順序最適化で使用されるのと同じカーディナリティ推定値に基づいて、中間テーブルが膨大になる結合を特定する。作業時間read22:1322:13author25:483:35summary52:5826:50感想とても難しい内容に感じてしまい、殆ど頭を通りすぎてしまった気がする。今まで最適化は触れずに来たため、理解が浅い領域だった。よくよく考えるとDBMSの話しに最適化が登場するのはあたりまえなので、今後はその方面にも触れて行きたい。

中間結果が莫大になるときの結合を最適化する最悪ケース最適化結合をRDBMSに適応する論文を読みました

この記事の趣旨2013年に発表された"Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited"という論文を読みました。当時最新のアルゴリズムとハードウェアにおける、ソートとハッシュによる結合のパフォーマンスを比べた論文です。Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited著者についてCagri Balkesen、Gustavo Alonso、Jens Teubner、M. Tamer Ozsuらのグループによる論文いずれもDBMSにおけるクエリ最適化やビッグデータにおけるパフォーマンスを研究している。またGustavo Alonsoはハードウェアや分散システムもメインのフィールドとしている。問題意識DBMSにおいて常にソートマージとハッシュ結合の性能比較が行われており、最新の研究ではSIMDやNUMAへの適正に基づいてソートマージがより優れていると結論づけられていた。しかしこれらの分野は常に研究が重ねられ、過去の検証時には登場していなったハッシュ結合の最適化手法が生れた。この論文ではそれらを適用し再度ソートマージとハッシュ結合の性能比較を行なう。手法本論文では以下に分けて結合手法の評価を行なっている。1. ソートフェーズの評価SIMDソートアルゴリズムとC++のSTLソートアルゴリズムを比較している。マージフェーズの評価入力サイズの調整によるマージフェーズの最適化パーマンスを検証している。ソートマージジョインにおける影響要因の特定結果結合対象のデータサイズに拘わらずハッシュによる結合がソートベースの結合のパフォーマンスを上回っている。Figure 14ソートマージによる結合は入力サイズが著しく大きくなったときのみハッシュ結合のパフォーマンスに近づく。Figure 15ソートマージ、ハッシュ結合におけるデータの偏りはパフォーマンスに大きな影響を及ぼさなかった。Figure 16いずれのアルゴリズムも物理的なコア数では線形にスケールした。Figure 17作業時間read23:1123:11author27:093:58summary60:1232:57

マルチコアメインメモリにおけるソートジョインとハッシュジョインのパフォーマンスを検証した論文を読みました

この記事の趣旨2016年に発表された"An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory"という論文を読みました。様々な結合手法を包括的に比較した論文でどのような結合方法がどのような時に適しているかを示しています。An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory著者についてStefan Schuh、Xiao Chen、Jens Dittrichのグループによる論文。いずれもDBMSや分析システム、Hadoopなどにおける検索高速化・最適化の研究を行なっている。問題意識関係結合はほとんど全てのクエリプランにおいて中核をなす処理であり、定期的に研究・改良され再検討されてきた。新たな手法が提案され実験を行なわれるものの、それぞれ結果において比較を困難にする要素や幾らかの矛盾を孕んでいた。例えば同じハッシュベースの結合アルゴリズムの比較でも実装が異なったり、複数の論文でパフォーマンス比較で正反対の結果を示しているためである。そのため単純に論文執筆時点で最も高速な結合アルゴリズムを結論づけることが困難であった。手法本論文では結合方法を以下の3つに分類した1. パーティションベースハッシュジョインパーティションに分割し結合する手法。ハッシュテーブルの構築と結合されるデータの探索のキャッシュミスを最小にする事を目的としている。非パーティションベースハッシュジョインパーティションテーブルを構築しながら結合を行なう手法で、マルチスレッドと順番に依存しない実行によりキャッシュミスのパフォーマンス劣化を隠蔽している。ソートマージジョインSIMDによりベクトル化される。検証ではこれらの結合方法を以下の3つのテストで使用するために、全部で13のアルゴリズムを検証している。1. ブラックボックス比較ブラックボックス的に比較する。ホワイトボックス比較ブラックボックス比較で検証する結合方法に先行研究で示された最適化を施した上で比較を行なう。パラレルラディックスジョイン比較Table 2結果パーティション結合の一種であるリモート書込みを排除したCPR系アルゴリズムは小さな入力に対して有効ではないスケールの大きい結合ではとくに理由が無い場合、パーティションベースのジョインを利用する大きなサイズのページを利用するソフトウェアライトコンバインバッファ()を利用するパーティションジョインでは適切なパーティションビットを利用するできるかぎりシンプルなアルゴリズムを利用するNUMAを考慮したアルゴリズムを利用する実行時間とクエリ時間は同一ではない作業時間read31:3431:34author35:183:46summary77:5042:32

RDBでの結合手法を比較した論文を読みました

この記事の趣旨2018年に発表された"Everything You Always Wanted to Know AboutCompiled and Vectorized Queries But Were Afraid to Ask"という論文を読みました。最新のクエリエンジンの特性をまとめ、どのようなワークロードに向くのかという指針を示すないようです。Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to AskTimo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Boncz著者についてTimo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Bonczのグループによる論文。いずれも大規模データにおけるクエリパフォーマスや最適化に関する研究を行なっている。問題意識分析ワークロードに向いた最新のクエリエンジンはベクトル化またはデータ中心のコード生成に基づいている。どちらのモデルも従来のエンジンに比べオーバーヘッドが少く、非常に効率的なものの概念的には大きく異なっている。この2つのモデルの違いは、DBMSの実行エンジンのソースコードの構成とその性能特性を決定する基本的なもので、クエリ実行モデルを超える多くの設計で異なる。本論文はことなる2つのモデルを再実装し、環境差異のないマシンで実行することでそれぞれのモデルがどのように違うのか。どのような用途に最適なのかを検証している。手法検証手法は著者らがC++で再実装したデータ中心モデルの「Taper」とベクトル化中心の「Tectorwise」を同一のマシンでパフォーマンス検証を行っている。検証項目は以下から成る1. インメモリOLAPワークロードでのマイクロアーキテクチャ分析1. SIMDの利点の検証1. マルチコアCPUにおけるクエリ並列化1. 異なるハードウェアでのパフォーマンス結果インメモリOLAPワークロードでのマイクロアーキテクチャ分析Figure 3: Performance – TPC-H SF=1, 1 threadSIMDの利点の検証SIMDを評価するにはTectorwiseのみを用いた。SIMDではスカラーなデータをベクトルに変換するペナルティは少く、最大8.4倍の性能向上が確認された。Figure 6: Scalar vs. SIMD Selection in TectorwiseマルチコアCPUにおけるクエリ並列化異なるハードウェアでのパフォーマンスIntel Skylake、Intel Knights Landing、AMD Ryzenで対照実験を行なったものの、いずれのハードウェアでもTyper、Tectorwiseともに有効に動作した。作業時間read29:2629:26author33:233:57summary76:3742:44感想VoectorwiseとHyperのいずれを使うべきか。どちらが優れているかといった疑問に答えるないようだった。

コンパイルとベクトル化による最適化のパフォーマンスを比較した論文を読みました

この記事の趣旨2020年に提案された"Make the most out of your SIMD investments: counter control flowdivergence in compiled query pipelines"という論文を読みました。SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文です。Make the most out of your SIMD investments: counter control flow divergence in compiled query pipelinesHarald Lang, Linnea Passing, Andreas Kipf, Peter Boncz, Thomas Neumann, Alfons Kemper著者についてHarald Lang、 Linnea Passing、 Andreas Kipf、 Peter Boncz、 Thomas Neumann、 Alfons Kemperのグループによる研究いずれも最新のアーキテクチャでのクエリ最適化やデータ分析における検索手法などを研究している。問題意識CPUの発展にともないあたらしいCPUアーキテクチャが登場した。Single Instruction Multiple Data(SIMD)ではRDBはSIMDによるベクトル処理能力の向上により、クエリコンパイラの実行パイプライン全体をベクトル化して高度なデータ並列性の恩恵を受けることが出来るようになった。一方でクエリ全体をベクトル化して実行することで、SIMDによるクエリ評価が忙しくなる。SIMD評価で結果に寄与しない評価が単純にオーバーヘッドとなってしまう。手法本論文ではリフィルアルゴリズムとそのアルゴリズムをクエリパイプラインプランに統合する手法で上記の問題の解決を試みている。リフィルアルゴリズムは基本的に新しい要素を宛先レジスタの希望する位置にコピーするアルゴリズムで、メモリからレジスタとレジスタからレジスタへのコピーの2パターンが存在する。クエリパイプラインプランに統合するリフィル戦略ではConsume EverythingパターンとPartial Consumeパターンが存在する。Consum Everything戦略は、タプルをバッファリングするために使用される追加のベクターレジスタを割り当てる方法で利用率が低い場合、オペレータはこれらのタプルの処理を延期する。つまり、この反復ではボディは実行されず(条件が満たされない場合)、代わりにアクティブなタプルがこれらのバッファレジスタに移動することになる。Partial Consume戦略ではconsume()コードを入力の一部に適用する方法で、制御フローを前のオペレータに戻し、アクティブなデータ断片のみをベクトルレジスタに残すことで実行を延期している。作業時間read29:4029:40author33:404:00summary60:0426:36感想前回に引続き個人的には難しいと感じる論文だった。2000年前後の提案にくらべ、2015年前後の論文ではハードウェアアーキテクチャを中心とした手法がピックアップされている。単純に自分の知識不足、理解力不足なので勉強するしかない。

SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文を読みました

この記事の趣旨"Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework forthe Many-Core Age"という2014年に発表された、多コアサーバにおけるクエリ最適化手法をあつかった論文を読みました。[Morsel-Driven Parallelism: A NUMA-Aware QueryEvaluation Framework for the Many-Core Age](https://15721.courses.cs.cmu.edu/spring2023/papers/07-scheduling/p743-leis.pdf)Viktor Leis, Peter Boncz, Alfons Kemper, Thomas Neumann著者についてViktor Leis、 Peter Boncz、 Alfons Kemper、Thomas Neumannのグループによる研究いずれもデータベースと 高速化かを中心に研究している。問題意識コンピュータアーキテクチャの進化にともない、二つのあたらしい問題が生じた。多コアを利用するためにクエリを数百のスレッドに均等に分散させるそれをNUMA(Non-Uniform Memory Access)による順序通りではないメモリアクセスで実現する必要がある。これらの要因からplanベースの並列処理による不可分散とコンテキストスイッチとボトルネックが問題になりスケールが難しかった。NUMAによってデータとアクセススレッドがどのチップに配置されるかによって、データ項目のアクセスコストが異なるため、コンピュータ自体がネットワークになっており、多コア並列化では、RAMやキャッシュ階層を考慮する必要がある。この論文ではMoral-drivenクエリ実行フレームワークを提案している。手法提案手法は並列クエリ処理のため、morselドリブンクエリ評価フレームワークを提示した。これはメニーコア時代の分析クエリ性能の主要なボトルネックである負荷分散、スレッド同期、メモリアクセス局所性およびリソース弾力性を解決することを目的としている。ベースとなるアイデアは以下の2つに分けられる。メモリ上のデータをmorselと呼ばれる小さなバッチに分割し、バッチごとに処理を実行したあとにそれぞれの処理結果をグローバルハッシュテーブルとしてまとめる。Figure 3: NUMA-aware processing of the build-phaseディスパッチャと呼ばれる並行パイプライン制御を行ない、ワーカースレッドをタスクに割り当てるFigure 5: Dispatcher assigns pipeline-jobs on morsels to threads depending on the coreまとめとして著者はきめ細かいスケジューリング、完全演算子並列化、低オーバーヘッド同期、NUMA対応スケジューリングの原理を用いて、他のシステムでもメニーコアスケーリングを改善できると示唆している。作業時間read28:3628:36author32:453:09summary60:3727:52感想近現代のサーバアーキテクチャで主流になっているNUMAでのクエリパフォーマンス向上のための論文のため、古典的なものに比べ概念が難しいものが多い。もう少し理解を深めたい。

NUMAアーキテクチャでのクエリ最適化に関する論文を読みました

SQL*Loaderで複数の文字コードが混ざったデータをロードする 概要単一のテキストファイル内で特定のカラムのみ文字コードが違うファイルをSQL*Loaderでデータベースに取り込む方法 注意本記事で扱っている対処方法はおそらく紛れ込んだ文字コードが本来あるべき文字コードの一部として解釈できない場合使用できないと思います。(未検証)最低限文字化けしながらも読み込める状態を想定しています。 結論コントロールファイル内で文字コードの変換が必要なカラムに以下の関数を適用する。column "CONVERT(:column, 'target_charset', 's...

SQL*Loaderで複数の文字コードが混ざったデータをロードする

Oracleインストール中にでたSysctl系エラーであたったkernel parameterについてTable of ContentsOracleインストール中にでたSysctl系エラーであたったkernel parameterについてMotivationそもそもsysctlとは何なのか？Oracleセットアップ中に遭遇したkernel parameterssemopm変更方法セマフォ(semaphore)とは？SEMSMLSEMMNSSEMOPMSEMMNIfile-max変更方法rem_default/rem_max/...