🐈

データベース マイグレーションを検討するための事前タスクを20個つくろう - 前半戦

2024/07/07に公開

はじめに

みなさん、こんにちわ。
仕事で DB Migration を検討しようと思ったのですが、メンバーに「やっといて〜」と丸投げするのは、これは流石に駄目だろうと思いまして(プロダクトの重要施策ですよね)。ざっとプロダクトバックログにして渡そうと思って書き始めたら、結構サクサクできました。
折角なら公開してフィードバックが欲しい。少しでも良いのでフィードバックが。
フィードバックください。お願いします。

前提

最初はプロダクトの特性やサービスの提供範囲、規模などをどうするか考えたのですが、その情報を集めることからやらねばな! と思いまして、現状把握タスクに含めて汎用化しました。
なので、準備無しで始めることを想定しています。

概要

いきなり人を集めて議論から始ると、どのDBが良いかの好き嫌い議論になりかねません。次の順番でタスクを進める事で、空中戦を避けましょう。

  • 現状の定量的評価
  • NoSQL DBのハードリミット分析
  • 要件の明確化 / ユースケース
  • 代替ソリューションの評価
  • データモデリングの再考
  • マイグレーション戦略の立案
  • パフォーマンスとスケーラビリティの検証
  • アプリケーション層への影響分析
  • 運用面の考慮
  • コスト / ベネフィット分析
  • リスク評価
  • PoC(プルーフオブコンセプト)の実施

現状の定量的評価

このタスクを整理しないと、最初の議論が出来ないはずです。現状の把握をしっかりして、課題やマイグレーションの目的を関係者と合意していきましょう。タスクに着手する際は、優先度 / 重要度 もスプリントバックログで整理しましょう。

大分類 中分類 小分類
パフォーマンス指標 a. スループット測定 - ピーク時のQPS, - 平均QPS(時間帯別、日別、週別)
b. レイテンシ測定 - 平均応答時間, - 95パーセンタイル、99パーセンタイルの応答時間
c. IOPS測定 - 読み取り/書き込みIOPS
d. リソース使用率測定 - CPU使用率, - メモリ使用率, - ディスクI/O使用率
クエリパフォーマンス a. スロークエリ分析 - スロークエリログの収集と分析
b. 頻出クエリ分析 - 頻繁に実行されるクエリのリスト化と実行時間測定
c. クエリプラン分析 - 可能な場合のクエリプラン確認
d. インデックス使用状況 - 現在のインデックス使用状況確認
データボリューム a. 総データ量測定 - 現在の総データ量
b. データ増加率計算 - 日次、月次、年次の増加率
c. コレクション別分析 - コレクション/テーブルごとのデータ量と増加率
d. インデックスサイズ - 各インデックスのサイズ測定
スケーラビリティ a. 負荷テスト - 段階的負荷増加テスト
b. 水平スケーリング評価 - スケールアウト時のパフォーマンス変化測定
c. レプリケーション遅延 - レプリケーション遅延の測定(該当する場合)
整合性と可用性 a. 読み取り整合性 - 読み取り整合性レベルの確認と測定
b. 書き込み整合性 - 書き込み整合性レベルの確認と測定
c. 分散環境での遅延 - 分散環境での整合性遅延測定
d. システム可用性 - アップタイムの測定
バックアップとリカバリ a. バックアップ時間 - バックアップ所要時間の測定
b. リストア時間 - リストア所要時間の測定
c. ポイントインタイムリカバリ - 可能性と所要時間の評価
リソース使用状況 a. ストレージ使用量 - 現在の使用量と増加率測定
b. メモリ使用量 - メモリ使用量のプロファイリング
c. コネクション数 - 最大・平均コネクション数の測定
クエリの複雑さと柔軟性 a. 複雑クエリ評価 - 最も複雑なクエリの特定と実行時間測定
b. 未対応クエリ - 実行できないが必要なクエリタイプのリスト化
c. 全文検索評価 - 全文検索機能の有無と性能評価
トランザクション処理 a. トランザクションスループット - トランザクションのスループット測定
b. トランザクション整合性 - トランザクションの整合性レベル確認
c. 分散トランザクション - 分散トランザクションの可能性と性能評価
運用面 a. 管理タスク - 日常的な管理タスクの所要時間測定
b. 監視システム - 監視と警告システムの有効性評価
c. 障害対応 - 障害発生頻度と平均復旧時間(MTTR)測定
コスト分析 a. インフラコスト - 現在のインフラストラクチャコスト算出
b. ライセンスコスト - ライセンスコストの確認(該当する場合)
c. 運用コスト - 運用コスト(人件費含む)の算出

DB(NoSQL)のハードリミット分析

ここまで纏めることで、ようやく有識者と健全な議論が出来る想定です。

大分類 中分類 小分類
データモデル制限 a. ドキュメントサイズ制限 - 単一ドキュメントの最大サイズ確認,- 現在の最大ドキュメントサイズ測定
b. キーサイズ制限 - キー(フィールド名)の最大長確認, - 現在の最長キー長測定
c. コレクション/テーブル数制限 - データベース内の最大コレクション/テーブル数確認, - 現在のコレクション/テーブル数カウント
d. ネスト深度制限 - ドキュメント内の最大ネスト深度確認, - 現在の最大ネスト深度測定
インデックス制限 a. インデックス数制限 - コレクション/テーブルあたりの最大インデックス数確認, - 現在のインデックス数カウント
b. インデックスキー制限 - 複合インデックスの最大フィールド数確認, - 現在の最大複合インデックスフィールド数測定
c. インデックスサイズ制限 - 単一インデックスの最大サイズ確認, - 現在の最大インデックスサイズ測定
クエリ制限 a. クエリ複雑性制限 - 単一クエリの最大複雑度(条件数など)確認, - 現在の最も複雑なクエリ分析
b. 結合操作制限 - 結合操作の可否と制限確認, - 現在実行中の最も複雑な結合操作分析
c. ソート制限 - ソート操作の制限(メモリ使用量など)確認, - 現在の最大ソート操作分析
d. クエリタイムアウト - デフォルトおよび最大クエリタイムアウト設定確認, - 長時間実行クエリの特定
トランザクション制限 a. トランザクションサイズ制限 - 単一トランザクション内の最大操作数確認, - 現在の最大トランザクションサイズ測定
b. トランザクション時間制限 - トランザクションの最大実行時間確認, - 長時間トランザクションの特定
c. 分散トランザクション制限 - 分散トランザクションのサポート確認, - 制限事項の特定
スケーラビリティ制限 a. シャード数制限 - クラスタあたりの最大シャード数確認, - 現在のシャード数カウント
b. レプリカセット制限 - レプリカセットあたりの最大ノード数確認, - 現在のレプリカセット構成分析
c. クラスタサイズ制限 - 単一クラスタの最大ノード数確認, - 現在のクラスタ構成分析
ストレージ制限 a. データベースサイズ制限 - 単一データベースの最大サイズ確認, - 現在のデータベースサイズ測定
b. ファイルサイズ制限 - 単一データファイルの最大サイズ確認, - 現在の最大データファイルサイズ測定
c. 総ストレージ容量制限 - クラスタ全体の最大ストレージ容量確認, - 現在の総ストレージ使用量測定
接続制限 a. 最大接続数 - サーバーあたりの最大同時接続数確認, - ピーク時の接続数測定
b. 接続プール制限 - 接続プールのサイズ制限確認, - 現在の接続プール設定分析
バックアップ制限 a. バックアップサイズ制限 - 単一バックアップの最大サイズ確認, - 現在のバックアップサイズ測定
b. バックアップ時間制限 - バックアッププロセスの時間制限確認, - 現在のバックアップ所要時間測定
結果分析とレポート作成 a. 定量的評価の集計 - パフォーマンス指標、スケーラビリティ指標の集計
b. 定性的評価のまとめ - 開発者/運用者からの課題やフィードバックの集約, - 現状ユーザビリティ、保守性の評価
c. 初回レポートの作成 - 技術的フィージビリティの一次評価, - ビジネス目標達成の影響度合い

さいごに

タイトルに20個とか書きましたが、ここまでで80個以上になってしまいました。ごめんなさい。
ただ、これがMAXだと想定して頂いて、みなさんのケースで必要となる部分を選んで頂くことで20個になるかと思います。
(続きも頑張って書きます)

Discussion