• 
• 
• 

本コンテンツは、当社が執筆している　実践DX、データベースのクラウド移行　「加速するデータベースのクラウド移行、基盤と運用に5つのコスト削減策」の内容を一部要約しつつ独自コンテンツを加えたものです。日経クロステック記事の全文はこちらをご覧ください。

データベースのコスト削減効果が大きい「５つの方法」

当社は、これまでにさまざまな企業のデータベースのコスト削減に取り組み、さまざまな方法で実現してきました。これらのなかで、 “実際により効果が大きかった” 「５つのコスト削減方法」をご紹介します。

これらは、組み合わせて実施できるものもあれば、単独で実施するものもあり、それぞれの有効性を評価して、組み合わせや順序等を検討・選択のうえ、実施します。

データベースのコスト削減効果が大きい５つの方法

コスト削減の方法	コストの増減
	ハードウェア	ソフトウェア	インテグレーション
① 低コストなDBMSの利用	ー	大幅に削減可能	変換コストが一時的に発生する 保守コストが増加する可能性がある
② 有利な調達条件	削減可能	削減可能	ー
③ データベースの統合	削減可能	削減可能	削減可能
④ チューニング	削減可能	削減可能	チューニングのためのコストが一時的に発生する
⑤ 運用の自動化	ー	ー	削減可能

① 低コストなDBMSの利用　〜オープンソースのDBMSへの移行〜

1つ目は、「低コストなDBMSの利用」で、ライセンス料金が発生する商用データベースの場合、オープンソースソフトウェア（OSS）のDBMSに移行することで、ライセンスコストを削減できます。OSS DBの代表例はPostgreSQL、MySQLです。実際にTCO（Total Cost of Ownership：総保有コスト）が下がるかは商用DBMSへの依存度で決まります。

商用DBMSの機能を使って、すでに開発・運用業務を効率化している場合や、データベースの可用性・性能・セキュリティ等を向上できている場合は、OSS DBに移行すると却って高コストになる場合があります。このようなケースでは、DBMSを変えずに単純に「クラウド」に移行することが最適解になりやすいです。Oracle DatabaseをOCI（Oracle Cloud Infrastructure：オラクル社のパブリッククラウド環境）に移行するのが代表例です。

コスト削減のインパクトと注意点

OSS DBへの移行コストは、難度の高い変換がどのくらい必要になるかによります。必ずしもSQLの方言を修正するための移行ギャップの数ではない点に注意してください。それよりも設計レベルの変更や、性能劣化するリスクの高いSQLの本数が重要な要素です。アプリケーションソースコードからこの該当箇所を抽出して、難度やリスク度合いを評価することが難しい点です。

OSS DBがフィットするデータベースを正しく移行できれば、大きなコスト削減効果を得られることが多くあります。クラウドにはOSS DBへの移行をサポートするサービスがあり、実現性を高められることもメリットです。代表例としては、AWS SCT（Schema Conversion Tool）、Google CloudのDMS（Database Migration Service）などです。

最適な移行先を正しく判断するには？

商用DB、OSS DBどちらにするかはよく議論になるテーマです。それぞれフィットする場面や状況が異なるので、「最適な使い分け」をするというのが現実的な答えとなります。

当社では、データベースの最適な移行先を的確にご判断いただくために、DBMS移行の仕様ギャップや性能劣化するリスクの高いSQL、および、必要となるエンジニアリングリソースを調査・レポートする「データベース移行アセスメントサービス」を提供しています。

また、移行時の変換コストを、オフショア利用などの従来手法以上に削減できるよう、AIを活用したソースコード自動変換サービスを独自開発しました。詳しくは、「Geminiを活用してD.Forceが独自開発！ソースコード変換AIサービス」をご参照ください。

② 有利な調達条件　〜運用スタイルに適した調達条件でコストを改善〜

ライセンスなどの調達方法を変えるだけでコスト削減できれば、移行工数やコストがかからず、大きなメリットになります。クラウドでは、複数の調達方法から運用スタイルに合ったものを選び直すことで削減につながることがあります。

CPU、メモリの利用量が大きく変動しない、常時利用されるデータベースでは、1年間以上の利用をコミットする契約で割引が受けられます。年数や前払いなどの条件で、割引率が30～60%ほどになります。

利用されない時間が長いデータベース（夜間、休日は利用されないなど）では、利用される時間帯だけ起動してその他の時間帯は停止すると、時間による従量課金となるため料金が下がります。停止する時間の割合に比例してコスト削減できるので、平日日中のみ起動する場合は、さらにコスト削減率が高くなります。

クラウド上でのデータベース運用では、「料金の最適化」も運用作業に組み込みます。この作業を、費用面の最適化運用という意味合いで「FinOps（フィンオプス、Financial Operationsの略）」といいます。

③ データベースの統合　〜性能強化されたインフラで分割DBを統合〜

インフラの性能は常に強化され、向上し続けています。リソースの上限や性能面の制約により、過去に分けざるを得なかったデータベースも、統合できるようになっている可能性があります。

データベースでは、統合する際のネームスペースの衝突やサービス時間・メンテナンス時間の調整などいくつかの課題を乗り越える必要はあるものの、データベーススキーマやデータの統合作業自体は難度が上がりやすいものではありません。

複数システムのデータベースを統合する際、リスク分散するために段階移行になりやすく、移行計画や安全な移行をするための作業品質を保つ作業にコストがかかります。技術的難度よりも移行計画や実行の煩雑さ、複数システムプロジェクト間の調整作業が多くなることにペインポイントがあります。

④ チューニング　〜SQLのチューニングによるリソース縮減〜

クラウドでは、CPUとメモリのサイズにほぼ比例するような形で料金が上がります。データベースで実行されるSQLをチューニングすることで、必要となるCPUを少なくすることができればコスト削減につながります。

当社では、データベースの性能診断サービスやチューニングサービスを提供しており、多くのケースで30%以上のCPU時間削減を実現しています。SQLがデータベースのCPUを無駄に消費しているケースは実際に非常に多く、他のコスト削減策と併行して実施することでさらなる削減効果を得ることができます。

クラウドでは、CPUサイズの大きなモデルに移行しなくて済むよう、アプリケーション設計の段階から消費リソースの最適なDBアクセス方式やSQLにするための品質管理に適度なコストをかけた方が、無駄なインフラコストや後ろ向きなトラブル対応工数の発生を抑制することができます。

⑤運用の自動化／標準化　〜主体的な運用体制でコスト最適化と品質向上〜

データベースの運用業務も無駄の温床です。クラウドでは多くの運用業務が自動化されており、運用工数を削減することが可能です。前述の継続的なコスト最適化のためのFinOpsや品質管理に加えて、さらに自動化に工数を充てるとより良い成果を得られます。

いずれも、「オペレーショナルな作業」ではなく「考える業務」です。「考える業務」が苦手な受け身の運用体制では実現が難しく、マインドセットを変える必要があります。「主体的、能動的な運用体制」はまだまだ実現できていない組織がとても多いと感じています。

運用スタイルを変革し、コスト最適化と品質・アジリティを圧倒的に高めるサポートができればと考え、当社では「データベース信頼性エンジニアリング（DBRE：データベース運用サービス）」を提供しています。

本記事に関するより詳しい説明は、日経クロステック記事に掲載されています。ご興味のある方はご覧いただければと思います。

次回は「データベースのクラウド移行を進める体制」について説明します。

• 
• 
•