Flava DBaaS Deep Dive：アーキテクチャからマイグレーション、そして未来まで
LINE ヤフーは旧両社のクラウドを統合する次世代プラットフォーム「Flava」において、Kubernetes のオペレーターパターンとインフラ抽象化レイヤーを採用した DBaaS の設計思想と移行戦略を公開した。
キーポイント
オペレーターパターンの採用
DBaaS を Kubernetes 上で動作するオペレーター・パターンで構築し、ドメイン知識をコントローラーとしてコード化することで、宣言的 API を介した自動運用と複雑な問題の特定を可能にしている。
IaaS の抽象化（インフラ・オペレーター）
DB 層が直接 IaaS API に依存するのを防ぐため、VM やストレージなどのインフラリソースを Kubernetes リソースとして扱う「インフラ・オペレーター」層を設け、宣言的な定義でインフラを制御する。
旧クラウドの統合と移行
旧 LINE の「Verda」と旧ヤフーの「YNW」を次世代クラウド「Flava」に統合する過程において、本アーキテクチャが中核を担い、大規模環境でも負荷をかけずに動作する設計となっている。
オペレーター・パターンによる自動化と運用効率化
ドメイン知識をコントローラーにコード化し、ユーザーの宣言に基づいて自動的に状態を達成する設計により、大規模環境でも負荷をかけずに安定した運用を実現します。
インフラ・オペレーターによるレイヤ分離
IaaS リソース管理層を抽象化することで、DBaaS のビジネスロジックとインフラ制御が分離され、開発者が DBMS に集中できる環境を提供します。
カスタムリソースと 3 コンポーネントによる状態管理
API サーバ、マネージャ（コントローラー）、エージェントの連携により、YAML で定義された望ましい状態を継続的に監視・調整して実現します。
柔軟なストレージと統一されたUX
ブロックストレージの最大容量を5TiBに拡大し、DBMSごとの操作やUIを統一することでユーザーの学習コストを削減しています。
重要な引用
オペレーター・パターンは、オペレーターがドメイン知識に基づいて行っていた操作をコントローラーとしてコード化し、Kubernetes の宣言的 API モデルを用いて自動的に動作させる設計手法です
DBaaS レイヤーで IaaS の API を直接扱うと、DB の運用・管理のためのビジネスロジックとインフラ制御ロジックが混在してしまいます
このようにインフラ・オペレーターを用いることで、宣言的に VM を作成できます。DBaaS 側は IaaS 側の API や呼び出し手順を知る必要がなく
ユーザーは「こういう状態の DB が欲しい」と意図を宣言するだけで、オペレーターのドメイン知識を反映したコントローラーが、その宣言された状態に到達する手順を継続的に実行します
インフラ・オペレーターを使用することで各レイヤの責任範囲が明確に分離されます。これにより IaaS が提供するリソースを複数の DBMS で同じ方法で扱えるようになり、各 DBaaS 商品開発者は DBMS に依存したビジネスロジックに集中できます
Flava DBaaSはワークロードの特性に応じてサーバーレスDBaaSと専用クラスター基盤サービスを併せて提供し、多様な要求を受け入れる計画です。
影響分析・編集コメントを表示
影響分析
この記事は、大規模テック企業における DBaaS のベストプラクティスを具体化しており、Kubernetes を活用したインフラ抽象化の重要性を再認識させる内容です。特に、ビジネスロジックとインフラ制御を分離する設計思想は、複雑化するクラウド環境での運用負荷軽減に直結する示唆に富むものです。
編集コメント
AI/LLM の話題ではないが、クラウドインフラの成熟度を示す重要な技術記事です。Kubernetes のオペレーターパターンを DB 管理に適用し、IaaS を抽象化するアプローチは、大規模システム運用における標準的なプラクティスとして参考になります。
はじめに
こんにちは。LINEヤフー株式会社のDBaaS DevOpsチームで働いている朴政武（パク・ジョンム）です。
LINEヤフー株式会社は大規模なプライベートクラウドを自社で開発・運用しており、プライベートクラウド環境ではデータベースをDBaaS（Database as a Service）として提供しています。現在、我々は旧LINE株式会社で使われていた「Verda」と旧ヤフー株式会社で使われていた「YNW」という二つの大規模クラウドを次世代クラウドであるFlavaに統合していく過程にあります。本稿ではFlava DBaaSの設計と仕様を紹介し、マイグレーション戦略と今後Flava DBaaSが進化すべき方向について説明します。
オペレーター・パターン
Flavaが提供するDBaaSはKubernetes上で動作するオペレーター・パターンを基盤としています。
出典: https://github.com/cncf/tag-app-delivery/blob/main/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md, Licensed under the Apache License, Version 2.0.
オペレーター・パターンは、オペレーターがドメイン知識に基づいて行っていた操作をコントローラーとしてコード化し、Kubernetesの宣言的APIモデルを用いて自動的に動作させる設計手法です。ユーザーは「こういう状態のDBが欲しい」と意図を宣言するだけで、オペレーターのドメイン知識を反映したコントローラーが、その宣言された状態に到達する手順を継続的に実行します。
宣言的に動作するオペレーター・パターンで構成したDBaaSは、実装難易度は高くなりますが、手続き指向で構成したアーキテクチャに比べて運用・管理が容易です。運用中に問題が発生した際には、宣言されたカスタムリソースの仕様と状態を比較し、コントローラーのログを確認するだけで原因を特定しやすくなります。またイベント駆動で動作するコントローラーは大規模なデータベースインフラ環境でも大きな負荷をかけずに動作します。CI/CDの構築や権限管理など、Kubernetesエコシステムが提供する多くの機能を利用できる点も利点です。
IaaS管理とインフラ・オペレーター
DBaaSのようなPaaS（Platform as a Service）はIaaS（Infra as a Service）上で動作するため、IaaSを効率的に制御できる設計が必要です。IaaSでデータベースクラスターを1つ構成するには、複数のVM、ストレージ、ドメインなどIaaS側が提供するリソースを生成・管理する必要があります。そのため、DBaaSレイヤーでIaaSのAPIを直接扱うと、DBの運用・管理のためのビジネスロジックとインフラ制御ロジックが混在してしまいます。
この点を改善するため、Flava DBaaSではIaaSリソースを扱う層を別のインフラ・オペレーター（infra operator）として抽象化しています。インフラ・オペレーターはIaaSリソースをKubernetesリソースの形で扱えるようにするプラットフォームで、IaaSのAPI呼び出しを直接実行するのではなく、Kubernetesの宣言的APIモデルをそのままインフラリソースに適用できるようにします。例えば、データベースをインストールするVMを作成するには、以下のように宣言的にserver.yamlを定義します。
name: testserver
namespace: testnamespace
spec:
availabilityZone: az3
image: Rocky Linux 8.10
serverType: 4vCPU-8GiB
その後、次のようにserver.yamlを使ってカスタムリソースを作成します。
kubectl create -f server.yaml
このようにインフラ・オペレーターを用いることで、宣言的にVMを作成できます。DBaaS側はIaaS側のAPIや呼び出し手順を知る必要がなく、server.yamlに必要事項を宣言するだけでKubernetesリソースだけでIaaSを扱えます。
インフラ・オペレーターを導入したFlava DBaaSのレイヤ構成は次の通りです。
+-----------------+
| DBaaS | ← Focus on database business logic
+-----------------+
| Infra operator | ← Abstracting IaaS as Kubernetes resources
+-----------------+
| IaaS | ← Provide compute, network, storage
+-----------------+
インフラ・オペレーターを使用することで各レイヤの責任範囲が明確に分離されます。これによりIaaSが提供するリソースを複数のDBMSで同じ方法で扱えるようになり、各DBaaS商品開発者はDBMSに依存したビジネスロジックに集中できます。
カスタムリソースとAPIサーバ、マネージャ、エージェント
インフラ・オペレーターがIaaSリソースをカスタムリソースとして表現するように、各DBMSではデータベースクラスターを次のような1つのカスタムリソースで表現します。
name: testmysql
namespace: testnamespace
spec:
version: mysql-8.0.45
serverType: Cx.4vCPU_16GiB_100GiB
storage:
type: nvme_dev
size: 200GiB
replication:
member: 1
このカスタムリソースは、ユーザーが望む状態のデータベースを表現しています。プライマリをレプリケートするメンバーを 1 つ構成し、VM のスペックは 4 vCPU、16GiB メモリ、100GiB ディスクを使用し、別途 200GiB のブロックストレージを使用するという形で記述されています。カスタムリソースは YAML の形で Kubernetes の etcd に保存され、Kubernetes が提供する API を使って参照・作成・修正・削除できます。
DBaaS はこのようなカスタムリソースを参照する三つのコンポーネントで構成されています。
- API サーバ: ユーザーに提供する操作方法を提供する REST API です。宣言的に定義されたカスタムリソースの作成・変更・削除を担います。Flava の UI や IaC ツールからこの API が呼ばれます。
- マネージャ: カスタムリソースの変更に応じて仕様と状態を一致させるために継続的に調整（reconcile）するコントローラープロセスです。データベースクラスターの現在状態を確認し、必要なコマンドを実行するなどの作業を総括します。
- エージェント: データベースプロセスが動作する VM 上で共に動作し、カスタムリソースの変更に応じて OS やデータベース上で実行すべきコマンドを実行するプロセスです。ローカルでしか動作しない操作やプロビジョニングのロジックに深く関与します。
カスタムリソースと API サーバ、マネージャ、エージェントがどのように動作するかを、MySQL クラスターを作成するシナリオを例にして見てみます。
ユーザーが構成したいデータベースクラスターの情報を API に送ると、API サーバがユーザーの要求に合わせた MySQL カスタムリソースを作成します。これにより、レプリケーション構成や MySQL を構成するサーバスペックなど、MySQL クラスターを構築するために必要な情報がカスタムリソースの仕様に記録され、Kubernetes の etcd に保存されます。
API Server -> kubectl create mysqlservice -f mysqlservice.yaml
- mysqlservice.yaml
name: testmysql
namespace: testnamespace
spec:
version: mysql-8.0.45
serverType: Cx.4vCPU_16GiB_100GiB
storage:
type: nvme_dev
size: 200GiB
replication:
member: 1
マネージャは作成されたカスタムリソースの生成や変更を検知し、カスタムリソース仕様に定義された状態と一致させるための手順を実行し始めます。仕様に定義された VM を作成するために、インフラ・オペレーターで提供される server というカスタムリソースを作成し、VM 作成が完了した後にエージェントがレプリケーションを設定するための命令を実行する、という流れです。
エージェントは VM 作成時に VM 内部にインストールされて動作し、カスタムリソースの仕様を確認してその状態に到達するために OS コマンドやデータベースコマンドを実行します。
このように各 DBMS は API サーバ、マネージャ、エージェントの三つのコンポーネントで分離して構成され、それぞれのプロセスの役割を明確に分けています。
Flava DBaaS で改善した点
DBaaS ではプラットフォームレベルでプロビジョニング、高可用性（high availability）、バックアップとリカバリ、スケーラビリティ（scalability）、モニタリングなどの基本機能を提供する必要があります。既存の Verda や YNW といったクラウドサービスでもこれらの機能は提供されており、Flava も同様に提供しています。さらに、これまで多くの開発者が要望していた点を改善して提供するために取り組んでいます。どの点を改善したかを順に見ていきます。
対応する DBMS の拡充
Flava では旧 Verda や YNW で提供していた DBMS を統合し、さらに多くの DBMS を提供しています。
追加したサポート機能
既存クラウドサービスで行ったユーザー満足度調査の結果に基づき、Flava DBaaS に新機能を追加しました。
より柔軟なスケーラビリティ
ユーザーは必要に応じて 100GiB 単位で柔軟にストレージを構成できます。またブロックストレージを使用する DBMS では使用可能なストレージ容量を最大 5TiB まで増やしました。
従来のクラウドでは VM のローカルディスクを使用していたため、DBMS が使用できるストレージ容量はハイパーバイザが提供する VM のスペックに依存していました。しかし Flava では VM 作成時にカスタムインスタンスタイプをサポートし、DBMS がブロックストレージを使用することでストレージ構成が柔軟になり、ストレージ最大容量も 5TiB に拡大しました。ブロックストレージ自体は 5TiB 以上でも利用可能でしたが、既存クラウドの利用実績を分析した結果、5TiB でほとんどの要件をカバーでき、ブロックストレージ側のサーバ断片化を防ぐために最大サイズを 5TiB に設定しました。
従来のクラウドでは単一 VM のストレージ容量の制限によりシャーディングなどの代替を検討する必要があるケースがありました。Flava DBaaS では最大ストレージ容量が増えたため、そのような検討が不要になる場合があります。
統一されたユーザー体験の提供
Flava が提供する DBaaS はすべて統一されたアーキテクチャと UI に基づき、統一されたユーザー体験を提供します。ユーザーは DBMS ごとに操作方法を変える必要がありません。例えば MySQL でサーバスペックを変更した経験があれば、その操作経験をもとに Redis のサーバスペックを変更できます。また Apache Cassandra のモニタリングアラームを設定した経験をもとに MySQL のモニタリングアラームも設定できます。同一の UI/UX を提供するため、ユーザーは DBMS ごとに別々に使い方を習得する必要がありません。
セキュリティ機能の強化
Flava が提供する DBaaS は、TDE（透明性データ暗号化）や TLS（トランスポート層セキュリティ）のようなセキュリティ機能を DBaaS レベルで標準提供しています。
利便性機能の追加
Flava DBaaS ではユーザー体験を改善するためにいくつかの利便性機能を提供しています。
- 「カスタム DB ロール」機能：ユーザーは必要な権限レベルを持ったデータベースユーザーを柔軟に作成・管理でき、再利用も可能です。
- 「データベースパラメータグループ」機能：任意のデータベースパラメータを制御でき、これを再利用できます。
- 「バックアップからの復元」機能：特定のバックアップを基に新しいデータベースクラスターを作成できます。この機能を使えば障害発生時にバックアップから復旧したり、パフォーマンステストのために本番と同じデータが入ったデータベースを UI 上で素早く作成できます。
まだ上記機能を提供していない DBaaS についても、これらの機能を提供するために準備中です。
既存クラウドサービスの運用過程で得たユーザーの声を基に、Flava ではより良い DBaaS を提供するために多くの機能改善を行い、その結果社内のユーザー満足度調査で高い評価を得ました。
マイグレーションにおける DBaaS の役割
新しい DBaaS を開発してユーザーに提供するだけでマイグレーションの役割が完了するわけではありません。既存プラットフォームから容易かつ簡便にマイグレーションできる手段を提供することまでが新しい DBaaS プラットフォームの責務です。既存プラットフォームから Flava DBaaS へ移行するために我々がどのような取り組みをしているかを説明します。
同一 DBMS 間のマイグレーション方法
Flava DBaaS が提供する方法を説明する前に、同一 DBMS 間でのマイグレーション方法を見てみます。異機種ではない同種の DBMS 間でのマイグレーションは大きく三つに分けられます。
ダンプ＆リストア（dump & restore）
ソースデータベースでバックアップを取り、ターゲットのデータベースにリストアする方式です。最も単純なマイグレーション方式ですが、データ整合性を保証するためにはアプリケーションを停止する必要があります。
レプリケーション（replication）
DBMS が提供するレプリケーション機能を利用する方式です。まずソース DB からターゲット DB へのリアルタイムレプリケーションを構成し、レプリケーションが追いついたらフェイルオーバーを行ってプライマリをターゲット側に切り替え、ソース DB を削除する流れです。
この方式ではデータ整合性は DBMS 自身が提供するレプリケーション機構に依存します。またプライマリのフェイルオーバー時に最小限のアプリケーション停止が発生する可能性があり、フェイルオーバー前にアプリケーションで使っているデータベースのエンドポイント等を変更する作業が必要になるため、ダンプ＆リストア方式に比べて手順が複雑で時間がかかる場合があります。無停止でのマイグレーションを目指す際には一般的に選択される方法です。
変更データキャプチャ（change data capture）
Apache Kafka などの別のシステムを構築してデータベース間のデータを論理的にコピーする方式です。論理的マイグレーションであるため、同種の DBMS 間であってもトポロジーの制約を超えた移行が可能です。例えば 6 シャードで構成された Redis クラスターを 3 シャード構成の Redis に移行することもできます。別途システムを構築して運用・管理する必要があるため複雑さは増しますが、ほぼ無停止でのマイグレーションが可能です。
Flava DBaaS が提供するマイグレーションツール
マイグレーションはデータベースを運用する運用者とそれを利用する開発者が緊密に協力して進める作業です。大規模データベースの運用担当者が単独ですべてを移行するのはほぼ不可能です。最善の方法は、データベースを使用する開発者が特別な知識なしに簡単に使えるよう、使い勝手の良いツールとマニュアルを提供することです。
現在は MySQL 向けに DMB（data migration bridge）という名前で、開発者が直接使えるマイグレーションツールを提供しています。2026 年第 2 四半期までに Flava が提供するすべての DBMS を対象に、開発者が直接使える形のマイグレーションツールを提供することを目標としています。DBMS ごとにワークロードや特性が異なるため、マイグレーションツールが提供する方式は DBMS ごとに異なる可能性がありますが、ユーザーが移行のための専門知識を持たずとも UI の指示に従うだけで簡単に移行できることを共通目標としています。
Flava DBaaS の将来
ここまでで現在の Flava DBaaS の姿を紹介しました。次に一歩先の未来、明日の Flava DBaaS がどのようになっているかを見てみます。
既存クラウドで提供していた DBMS のサポート
既存の YNW で提供していた FractalDB や、DBA 支援で利用していた HBase などのデータベースも DBaaS の形で提供できるよう準備しています。
セキュリティ環境のサポート
LINE ヤフー株式会社は社会インフラとしてサービスを提供しているため、厳格なセキュリティレベルの維持が求められます。Flava DBaaS もこれらの要求に応える機能を提供する必要があります。
Flava は、社内の厳格なデータガバナンスおよびセキュリティ基準に基づき、データをセキュリティレベルごとに隔離して保存・処理するアーキテクチャとして設計されています。Flava DBaaS も同様に、取り扱うデータの重要度や性質に応じた高度な分離管理環境を段階的に拡充し、適用しています。セキュリティが厳格に整備された後、重要なのは使いやすさです。 Flava DBaaS では、データのセキュリティレベルによって使い勝手が変わることはなく、すべてのセキュリティレベルにおいて迅速かつ便利にデータベース環境を構築できるよう準備を進めています。
サーバーレス DBaaS
独立したデータベースクラスターの形で提供される DBaaS は安定したデータベース運用環境を提供できますが、プラットフォーム全体の観点では独立した冗長化などの理由で自然とリソース利用率が低くなります。Flava DBaaS はこの問題を解決するためにサーバーレス DBaaS を準備しています。
サーバーレス DBaaS は、複数のユーザーがマルチテナント形式で共通インフラを効率的に利用できるように設計されています。DBaaS の運用者は全体的な観点からリソース利用率を高め、バージョンアップやバックアップなどの運用作業を標準化して運用コストを下げることができます。ユーザーはクラスター構成やサーバー仕様を気にする必要はなく、必要なリソースを即座に自由に利用でき、その費用は使用した分だけ請求されます。サーバーレス DBaaS ではよく知られた ノイジーネイバー (noisy neighbor) のような問題が発生する可能性があります。これを解決するためにテナント間のリソース隔離なども導入して検証しています。
サーバーレス DBaaS がすべてのワークロードに適しているわけではありません。高いレベルの性能や専用インフラ構成が必要なワークロードの場合は、独立したクラスター基盤の DBaaS の方が適しています。Flava DBaaS はワークロードの特性に応じてサーバーレス DBaaS と専用クラスター基盤サービスを併せて提供し、多様な要求を受け入れる計画です。
現在はまず MySQL 互換の TiDB サーバーレスデータベースとサーバーレス検索（Serverless OpenSearch）を準備しています。これにより増加するデータベース需要を積極的に受け入れ、インフラリソースを効率的に利用する方法を検討しています。
インテリジェント DBaaS
Flava DBaaS が AI 時代に向けて進むべき方向の中で最も挑戦的なのはインテリジェントクラウド（intelligent cloud）です。
DBA as a Service
DBA は長年にわたり DB 運用の要を担ってきました。アラート発生時に原因を調査して対応し、遅いクエリを分析してチューニングし、利用者に適切な運用ガイドを提供するなど、安定して動作するデータベースの裏側には常に DBA が存在してきました。DBA as a Service はこれらの DBA の役割を AI エージェントの形で提供するものです。
ユーザーは DBA とやり取りしていた相談等を Slack ボットを通じてサービスの形で受け取ることができます。
- アラート分析：アラート発生時に指標とログを分析して現在発生しているアラートの原因を特定し、検証結果に基づいて対処の提案を行います。
- 課題対応：「13:05 から db-prod-01 のクエリ遅延が増加しているのはなぜですか？」と質問すると、Slack ボットが指標とログを照会して回答します。回答後の追加質問にも適切に答えるため、まるで DBA とやり取りしているかのように問題の原因を分析できます。
- 問い合わせ対応：データベース仕様の算定、クラスター構成の選定、バックアップポリシーの設定などに関するアドバイスを提供します。想定 QPS やデータ量などの情報、データの性質、サービス概要を提供すると、適切な構成を提案します。
Slack ボットだけでなく、Flava コンソール（Web UI）でもレポートタブを提供します。レポートタブでは DBaaS をより良く利用するための改善提案をレポート形式で受け取ることができます。
- 日単位または特定時間単位の DB 使用パターンを確認し、バックアップ時間がバッチ実行と重なる場合はバックアップ時間の変更を推奨したり、リソース使用率を確認してリソース削減の可能性を判断して提案します。
- 遅いクエリのパターンを分析してクエリチューニングの方法を提案したり、適切なインデックス（索引）を推奨します。
- 保管されているデータの中に個人情報と判断されるものがあれば報告の上で暗号化を提案します。
オートスケーリング
DBMS リソースをいかに効率的に使うかは、すべての運用者が常に悩む点です。リソースを過剰に割り当てればコストが無駄になり、不足すれば性能低下や障害を引き起こす可能性があるためです。
Flava DBaaS はこの問題を解決するためにオートスケーリング機能を提供します。ユーザーは CPU、メモリ、ストレージ、コネクションなどの指標に基づいてポリシーを設定でき、ポリシーに基づいて必要なリソースを自動的に拡張または縮小します。例えば深夜に大規模なバッチ処理が予定されている場合、DBaaS は事前にリードレプリカを作成して読み取り負荷を分散し、処理終了後にレプリカを返却してコストを最適化します。別の例として、データ増加によりディスク使用率が閾値に達した場合、ストレージを 20％増やしたノードに VM（仮想マシン）仕様を変更することができます。
このようなオートスケーリング機能を DBA as a Service と連携させれば、より知的で安定したオートスケーリングを提供できるでしょう。AI エージェントはデータベースの使用パターンやリソース使用履歴を分析し、現在設定されているオートスケーリングポリシーが適切かを検討して改善案を提案できます。例えば特定の時間帯に繰り返し発生するトラフィック増加のパターンを分析してオートスケーリングの閾値調整を推奨したり、データ増加の傾向に基づいて事前増強ポリシーを提案することができます。これによりユーザーは複雑なポリシー設計を悩む必要なく、リソースが効率的に使われる体験を得られます。
おわりに
ここまでで Flava DBaaS のアーキテクチャと仕様、既存プラットフォームからのマイグレーションのために提供するツール、そして今後 Flava DBaaS がどのように進化していくかを確認しました。Flava DBaaS は既存プラットフォームの運用経験に基づき、より改善された形で安定的で使いやすい DBaaS を提供するために努めており、AI 時代に合わせて DBaaS をどのように提供すべきかの答えを模索しています。
今後 Flava DBaaS がもたらす変化にぜひご注目ください。お読みいただきありがとうございました。
Tech-Verse 2026 を開催します（6 月 29 日）
この記事は、イベントの公式記事として公開されました。
Tech-Verse 2026 は、LINE ヤフーが開催する技術カンファレンスです。
最先端の挑戦や積み重ねてきた知識を共有します。
YouTube LIVE での配信をぜひご覧ください。
原文を表示
はじめに
こんにちは。LINEヤフー株式会社のDBaaS DevOpsチームで働いている朴政武（パク・ジョンム）です。
LINEヤフー株式会社は大規模なプライベートクラウドを自社で開発・運用しており、プライベートクラウド環境ではデータベースをDBaaS（Database as a Service）として提供しています。現在、我々は旧LINE株式会社で使われていた「Verda」と旧ヤフー株式会社で使われていた「YNW」という二つの大規模クラウドを次世代クラウドであるFlavaに統合していく過程にあります。本稿ではFlava DBaaSの設計と仕様を紹介し、マイグレーション戦略と今後Flava DBaaSが進化すべき方向について説明します。
オペレーター・パターン
Flavaが提供するDBaaSはKubernetes上で動作するオペレーター・パターンを基盤としています。
出典: [https://github.com/cncf/tag-app-delivery/blob/main/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md, Licensed under the Apache License, Version 2.0.](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/e101c557641a47b88d96b4873a125e79.png?updatedAt=1780381177000)
オペレーター・パターンは、オペレーターがドメイン知識に基づいて行っていた操作をコントローラーとしてコード化し、Kubernetesの宣言的APIモデルを用いて自動的に動作させる設計手法です。ユーザーは「こういう状態のDBが欲しい」と意図を宣言するだけで、オペレーターのドメイン知識を反映したコントローラーが、その宣言された状態に到達する手順を継続的に実行します。
宣言的に動作するオペレーター・パターンで構成したDBaaSは、実装難易度は高くなりますが、手続き指向で構成したアーキテクチャに比べて運用・管理が容易です。運用中に問題が発生した際には、宣言されたカスタムリソースの仕様と状態を比較し、コントローラーのログを確認するだけで原因を特定しやすくなります。またイベント駆動で動作するコントローラーは大規模なデータベースインフラ環境でも大きな負荷をかけずに動作します。CI/CDの構築や権限管理など、Kubernetesエコシステムが提供する多くの機能を利用できる点も利点です。
IaaS管理とインフラ・オペレーター
DBaaSのようなPaaS（Platform as a Service）はIaaS（Infra as a Service）上で動作するため、IaaSを効率的に制御できる設計が必要です。IaaSでデータベースクラスターを1つ構成するには、複数のVM、ストレージ、ドメインなどIaaS側が提供するリソースを生成・管理する必要があります。そのため、DBaaSレイヤーでIaaSのAPIを直接扱うと、DBの運用・管理のためのビジネスロジックとインフラ制御ロジックが混在してしまいます。
この点を改善するため、Flava DBaaSではIaaSリソースを扱う層を別のインフラ・オペレーター（infra operator）として抽象化しています。インフラ・オペレーターはIaaSリソースをKubernetesリソースの形で扱えるようにするプラットフォームで、IaaSのAPI呼び出しを直接実行するのではなく、Kubernetesの宣言的APIモデルをそのままインフラリソースに適用できるようにします。例えば、データベースをインストールするVMを作成するには、以下のように宣言的にserver.yamlを定義します。
name: testserver
namespace: testnamespace
spec:
availabilityZone: az3
image: Rocky Linux 8.10
serverType: 4vCPU-8GiB
その後、次のようにserver.yamlを使ってカスタムリソースを作成します。
kubectl create -f server.yaml
このようにインフラ・オペレーターを用いることで、宣言的にVMを作成できます。DBaaS側はIaaS側のAPIや呼び出し手順を知る必要がなく、server.yamlに必要事項を宣言するだけでKubernetesリソースだけでIaaSを扱えます。
インフラ・オペレーターを導入したFlava DBaaSのレイヤ構成は次の通りです。
+-----------------+
| DBaaS | ← Focus on database business logic
+-----------------+
| Infra operator | ← Abstracting IaaS as Kubernetes resources
+-----------------+
| IaaS | ← Provide compute, network, storage
+-----------------+
インフラ・オペレーターを使用することで各レイヤの責任範囲が明確に分離されます。これによりIaaSが提供するリソースを複数のDBMSで同じ方法で扱えるようになり、各DBaaS商品開発者はDBMSに依存したビジネスロジックに集中できます。
カスタムリソースとAPIサーバ、マネージャ、エージェント
インフラ・オペレーターがIaaSリソースをカスタムリソースとして表現するように、各DBMSではデータベースクラスターを次のような1つのカスタムリソースで表現します。
name: testmysql
namespace: testnamespace
spec:
version: mysql-8.0.45
serverType: Cx.4vCPU_16GiB_100GiB
storage:
type: nvme_dev
size: 200GiB
replication:
member: 1
このカスタムリソースはユーザーが望む状態のデータベースを表現しています。プライマリをレプリケートするメンバーを1つ構成し、VMのスペックは4 vCPU、16GiBメモリ、100GiBディスクを使用し、別途200GiBのブロックストレージを使用する、という形で記述されています。カスタムリソースはYAMLの形でKubernetesのetcdに保存され、Kubernetesが提供するAPIを使って参照・作成・修正・削除できます。
DBaaSはこのようなカスタムリソースを参照する三つのコンポーネントで構成されています。
- APIサーバ: ユーザーに提供する操作方法を提供するREST APIです。宣言的に定義されたカスタムリソースの作成・変更・削除を担います。FlavaのUIやIaCツールからこのAPIが呼ばれます。
- マネージャ: カスタムリソースの変更に応じて仕様と状態を一致させるために継続的に調整（reconcile）するコントローラープロセスです。データベースクラスターの現在状態を確認し、必要なコマンドを実行するなどの作業を総括します。
- エージェント: データベースプロセスが動作するVM上で共に動作し、カスタムリソースの変更に応じてOSやデータベース上で実行すべきコマンドを実行するプロセスです。ローカルでしか動作しない操作やプロビジョニングのロジックに深く関与します。
カスタムリソースとAPIサーバ、マネージャ、エージェントがどのように動作するかを、MySQLクラスターを作成するシナリオを例にして見てみます。
ユーザーが構成したいデータベースクラスターの情報をAPIに送ると、APIサーバがユーザーの要求に合わせたMySQLカスタムリソースを作成します。これにより、レプリケーション構成やMySQLを構成するサーバスペックなど、MySQLクラスターを構築するために必要な情報がカスタムリソースの仕様に記録され、Kubernetesのetcdに保存されます。
API Server -> kubectl create mysqlservice -f mysqlservice.yaml
- mysqlservice.yaml
name: testmysql
namespace: testnamespace
spec:
version: mysql-8.0.45
serverType: Cx.4vCPU_16GiB_100GiB
storage:
type: nvme_dev
size: 200GiB
replication:
member: 1
マネージャは作成されたカスタムリソースの生成や変更を検知し、カスタムリソース仕様に定義された状態と一致させるための手順を実行し始めます。仕様に定義されたVMを作成するために、インフラ・オペレーターで提供されるserverというカスタムリソースを作成し、VM作成が完了した後にエージェントがレプリケーションを設定するための命令を実行する、という流れです。
エージェントはVM作成時にVM内部にインストールされて動作し、カスタムリソースの仕様を確認してその状態に到達するためにOSコマンドやデータベースコマンドを実行します。
このように各DBMSはAPIサーバ、マネージャ、エージェントの三つのコンポーネントで分離して構成され、それぞれのプロセスの役割を明確に分けています。
Flava DBaaSで改善した点
DBaaSではプラットフォームレベルでプロビジョニング、高可用性（high availability）、バックアップとリカバリ、スケーラビリティ（scalability）、モニタリングなどの基本機能を提供する必要があります。既存のVerdaやYNWといったクラウドサービスでもこれらの機能は提供されており、Flavaも同様に提供しています。さらに、これまで多くの開発者が要望していた点を改善して提供するために取り組んでいます。どの点を改善したかを順に見ていきます。
対応するDBMSの拡充
Flavaでは旧VerdaやYNWで提供していたDBMSを統合し、さらに多くのDBMSを提供しています。
追加したサポート機能
既存クラウドサービスで行ったユーザー満足度調査の結果に基づき、Flava DBaaSに新機能を追加しました。
より柔軟なスケーラビリティ
ユーザーは必要に応じて100GiB単位で柔軟にストレージを構成できます。またブロックストレージを使用するDBMSでは使用可能なストレージ容量を最大5TiBまで増やしました。
従来のクラウドではVMのローカルディスクを使用していたため、DBMSが使用できるストレージ容量はハイパーバイザが提供するVMのスペックに依存していました。しかしFlavaではVM作成時にカスタムインスタンスタイプをサポートし、DBMSがブロックストレージを使用することでストレージ構成が柔軟になり、ストレージ最大容量も5TiBに拡大しました。ブロックストレージ自体は5TiB以上でも利用可能でしたが、既存クラウドの利用実績を分析した結果、5TiBでほとんどの要件をカバーでき、ブロックストレージ側のサーバ断片化を防ぐために最大サイズを5TiBに設定しました。
従来のクラウドでは単一VMのストレージ容量の制限によりシャーディングなどの代替を検討する必要があるケースがありました。Flava DBaaSでは最大ストレージ容量が増えたため、そのような検討が不要になる場合があります。
統一されたユーザー体験の提供
Flavaが提供するDBaaSはすべて統一されたアーキテクチャとUIに基づき、統一されたユーザー体験を提供します。ユーザーはDBMSごとに操作方法を変える必要がありません。例えばMySQLでサーバスペックを変更した経験があれば、その操作経験をもとにRedisのサーバスペックを変更できます。またApache Cassandraのモニタリングアラームを設定した経験をもとにMySQLのモニタリングアラームも設定できます。同一のUI/UXを提供するため、ユーザーはDBMSごとに別々に使い方を習得する必要がありません。
セキュリティ機能の強化
Flavaが提供するDBaaSは、TDE（transparent data encryption）やTLS（transport layer security）のようなセキュリティ機能をDBaaSレベルで標準提供しています。
利便性機能の追加
Flava DBaaSではユーザー体験を改善するためにいくつかの利便性機能を提供しています。
- 「Custom DB Role」機能: ユーザーは必要な権限レベルを持ったデータベースユーザーを柔軟に作成・管理でき、再利用も可能です。
- 「Database Parameter Group」機能: 任意のデータベースパラメータを制御でき、これを再利用できます。
- 「Restore backup」機能: 特定のバックアップを基に新しいデータベースクラスターを作成できます。この機能を使えば障害発生時にバックアップから復旧したり、パフォーマンステストのために本番と同じデータが入ったデータベースをUI上で素早く作成できます。
まだ上記機能を提供していないDBaaSについても、これらの機能を提供するために準備中です。
既存クラウドサービスの運用過程で得たユーザーの声を基に、Flavaではより良いDBaaSを提供するために多くの機能改善を行い、その結果社内のユーザー満足度調査で高い評価を得ました。
マイグレーションにおけるDBaaSの役割
新しいDBaaSを開発してユーザーに提供するだけでマイグレーションの役割が完了するわけではありません。既存プラットフォームから容易かつ簡便にマイグレーションできる手段を提供することまでが新しいDBaaSプラットフォームの責務です。既存プラットフォームからFlava DBaaSへ移行するために我々がどのような取り組みをしているかを説明します。
同一DBMS間のマイグレーション方法
Flava DBaaSが提供する方法を説明する前に、同一DBMS間でのマイグレーション方法を見てみます。異機種ではない同種のDBMS間でのマイグレーションは大きく三つに分けられます。
ダンプ＆リストア（dump & restore）
ソースデータベースでバックアップを取り、ターゲットのデータベースにリストアする方式です。最も単純なマイグレーション方式ですが、データ整合性を保証するためにはアプリケーションを停止する必要があります。
レプリケーション（replication）
DBMSが提供するレプリケーション機能を利用する方式です。まずソースDBからターゲットDBへのリアルタイムレプリケーションを構成し、レプリケーションが追いついたらフェイルオーバーを行ってプライマリをターゲット側に切り替え、ソースDBを削除する流れです。
この方式ではデータ整合性はDBMS自身が提供するレプリケーション機構に依存します。またプライマリのフェイルオーバー時に最小限のアプリケーション停止が発生する可能性があり、フェイルオーバー前にアプリケーションで使っているデータベースのエンドポイント等を変更する作業が必要になるため、ダンプ＆リストア方式に比べて手順が複雑で時間がかかる場合があります。無停止でのマイグレーションを目指す際には一般的に選択される方法です。
変更データキャプチャ（change data capture）
Apache Kafkaのような別のシステムを構築してデータベース間のデータを論理的にコピーする方式です。論理的マイグレーションであるため、同種のDBMS間であってもトポロジーの制約を超えた移行が可能です。例えば6シャードで構成されたRedisクラスターを3シャード構成のRedisに移行することもできます。別途システムを構築して運用・管理する必要があるため複雑さは増しますが、ほぼ無停止でのマイグレーションが可能です。
Flava DBaaSが提供するマイグレーションツール
マイグレーションはデータベースを運用する運用者とそれを利用する開発者が緊密に協力して進める作業です。大規模データベースの運用担当者が単独ですべてを移行するのはほぼ不可能です。最善の方法は、データベースを使用する開発者が特別な知識なしに簡単に使えるよう、使い勝手の良いツールとマニュアルを提供することです。
現在はMySQL向けにDMB（data migration bridge）という名前で、開発者が直接使えるマイグレーションツールを提供しています。2026年第2四半期までにFlavaが提供するすべてのDBMSを対象に、開発者が直接使える形のマイグレーションツールを提供することを目標としています。DBMSごとにワークロードや特性が異なるため、マイグレーションツールが提供する方式はDBMSごとに異なる可能性がありますが、ユーザーが移行のための専門知識を持たずともUIの指示に従うだけで簡単に移行できることを共通目標としています。
Flava DBaaSの将来
ここまでで現在のFlava DBaaSの姿を紹介しました。次に一歩先の未来、明日のFlava DBaaSがどのようになっているかを見てみます。
既存クラウドで提供していたDBMSのサポート
既存のYNWで提供していたFractalDBや、DBA支援で利用していたHBaseなどのデータベースもDBaaSの形で提供できるよう準備しています。
セキュリティ環境のサポート
LINEヤフー株式会社は社会インフラとしてサービスを提供しているため、厳格なセキュリティレベルの維持が求められます。Flava DBaaSもこれらの要求に応える機能を提供する必要があります。
Flavaは、社内の厳格なデータガバナンスおよびセキュリティ基準に基づき、データをセキュリティレベルごとに隔離して保存・処理するアーキテクチャとして設計されています。Flava DBaaSも同様に、取り扱うデータの重要度や性質に応じた高度な分離管理環境を段階的に拡充し、適用しています。セキュリティが厳格に整備された後、重要なのは使いやすさです。 Flava DBaaSでは、データのセキュリティレベルによって使い勝手が変わることはなく、すべてのセキュリティレベルにおいて迅速かつ便利にデータベース環境を構築できるよう準備を進めています。
サーバーレスDBaaS
独立したデータベースクラスターの形で提供されるDBaaSは安定したデータベース運用環境を提供できますが、プラットフォーム全体の観点では独立した冗長化などの理由で自然とリソース利用率が低くなります。Flava DBaaSはこの問題を解決するためにサーバーレスDBaaSを準備しています。
サーバーレスDBaaSは、複数のユーザーがマルチテナント形式で共通インフラを効率的に利用できるように設計されています。DBaaSの運用者は全体的な観点からリソース利用率を高め、バージョンアップやバックアップなどの運用作業を標準化して運用コストを下げることができます。ユーザーはクラスター構成やサーバー仕様を気にする必要はなく、必要なリソースを即座に自由に利用でき、その費用は使用した分だけ請求されます。サーバーレスDBaaSではよく知られたノイジーネイバー(noisy neighbor)のような問題が発生する可能性があります。これを解決するためにテナント間のリソース隔離なども導入して検証しています。
サーバーレスDBaaSがすべてのワークロードに適しているわけではありません。高いレベルの性能や専用インフラ構成が必要なワークロードの場合は、独立したクラスター基盤のDBaaSの方が適しています。Flava DBaaSはワークロードの特性に応じてサーバーレスDBaaSと専用クラスター基盤サービスを併せて提供し、多様な要求を受け入れる計画です。
現在はまずMySQL互換のTiDBサーバーレスデータベースとサーバーレス検索（Serverless OpenSearch）を準備しています。これにより増加するデータベース需要を積極的に受け入れ、インフラリソースを効率的に利用する方法を検討しています。
インテリジェントDBaaS
Flava DBaaSがAI時代に向けて進むべき方向の中で最も挑戦的なのはインテリジェントクラウド（intelligent cloud）です。
DBA as a Service
DBAは長年にわたりDB運用の要を担ってきました。アラート発生時に原因を調査して対応し、遅いクエリを分析してチューニングし、利用者に適切な運用ガイドを提供するなど、安定して動作するデータベースの裏側には常にDBAが存在してきました。DBA as a ServiceはこれらのDBAの役割をAIエージェントの形で提供するものです。
ユーザーはDBAとやり取りしていた相談等をSlackボットを通じてサービスの形で受け取ることができます。
- アラート分析: アラート発生時に指標とログを分析して現在発生しているアラートの原因を特定し、検証結果に基づいて対処の提案を行います。
- 課題対応: 「13:05からdb-prod-01のクエリ遅延が増加しているのはなぜですか？」と質問すると、Slackボットが指標とログを照会して回答します。回答後の追加質問にも適切に答えるため、まるでDBAとやり取りしているかのように問題の原因を分析できます。
- 問い合わせ対応: データベース仕様の算定、クラスター構成の選定、バックアップポリシーの設定などに関するアドバイスを提供します。想定QPSやデータ量などの情報、データの性質、サービス概要を提供すると、適切な構成を提案します。
Slackボットだけでなく、Flavaコンソール（Web UI）でもレポートタブを提供します。レポートタブではDBaaSをより良く利用するための改善提案をレポート形式で受け取ることができます。
- 日単位または特定時間単位のDB使用パターンを確認し、バックアップ時間がバッチ実行と重なる場合はバックアップ時間の変更を推奨したり、リソース使用率を確認してリソース削減の可能性を判断して提案します。
- 遅いクエリのパターンを分析してクエリチューニングの方法を提案したり、適切なインデックスを推奨します。
- 保管されているデータの中に個人情報と判断されるものがあれば報告の上で暗号化を提案します。
オートスケーリング
DBMSリソースをいかに効率的に使うかは、すべての運用者が常に悩む点です。リソースを過剰に割り当てればコストが無駄になり、不足すれば性能低下や障害を引き起こす可能性があるためです。
Flava DBaaSはこの問題を解決するためにオートスケーリング機能を提供します。ユーザーはCPU、メモリ、ストレージ、コネクションなどの指標に基づいてポリシーを設定でき、ポリシーに基づいて必要なリソースを自動的に拡張または縮小します。例えば深夜に大規模なバッチ処理が予定されている場合、DBaaSは事前にリードレプリカを作成して読み取り負荷を分散し、処理終了後にレプリカを返却してコストを最適化します。別の例として、データ増加によりディスク使用率が閾値に達した場合、ストレージを20％増やしたノードにVM仕様を変更することができます。
このようなオートスケーリング機能をDBA as a Serviceと連携させれば、より知的で安定したオートスケーリングを提供できるでしょう。AIエージェントはデータベースの使用パターンやリソース使用履歴を分析し、現在設定されているオートスケーリングポリシーが適切かを検討して改善案を提案できます。例えば特定の時間帯に繰り返し発生するトラフィック増加のパターンを分析してオートスケーリングの閾値調整を推奨したり、データ増加の傾向に基づいて事前増強ポリシーを提案することができます。これによりユーザーは複雑なポリシー設計を悩む必要なく、リソースが効率的に使われる体験を得られます。
おわりに
ここまででFlava DBaaSのアーキテクチャと仕様、既存プラットフォームからのマイグレーションのために提供するツール、そして今後Flava DBaaSがどのように進化していくかを確認しました。Flava DBaaSは既存プラットフォームの運用経験に基づき、より改善された形で安定的で使いやすいDBaaSを提供するために努めており、AI時代に合わせてDBaaSをどのように提供すべきかの答えを模索しています。
今後Flava DBaaSがもたらす変化にぜひご注目ください。お読みいただきありがとうございました。
Tech-Verse 2026 を開催します（6月29日）
この記事は、イベントの公式記事として公開されました。
Tech-Verse 2026は、LINEヤフーが開催する技術カンファレンスです。
最先端の挑戦や積み重ねてきた知識を共有します。
YouTube LIVEでの配信をぜひご覧ください。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み