Flava DBaaS Deep Dive：アーキテクチャからマイグレーション、そして未来まで

はじめに

こんにちは。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 での配信をぜひご覧ください。

https://tech-verse.lycorp.co.jp/2026/ja/