FJcloud実践
マネージドDBと自前構築のDB、どちらを選ぶべき？ 導入パターン別のメリット・使い分けを解説
はじめに
データベースを導入する際、最初に直面するのが「自前でデータベースを構築するか、クラウド事業者が提供するマネージドDBサービスを利用するか」というインフラレベルの選択です。どちらにもメリット・デメリットがあり、システムの要件や運用体制によって最適な選択肢は変わるため、一概にこちらがいいと言うことはできません。
この記事ではFJcloud-VのマネージドDBサービス「RDB」を例に、マネージドDBと自前構築DBそれぞれの特徴を解説します。データベースの導入を検討している方は、適切な選択のための判断材料としてぜひ参考にしてください。
マネージドDBと自前構築DBの基本的な違い
マネージドDBと自前構築DBの大きな違いは、その運用面にあります。それぞれの特徴を詳しく見ていきましょう。
管理負荷
自前構築DBでは、データベースの運用管理をすべて、ユーザー側で実施しなければなりません。OSのパッチ適用、データベースエンジンのアップデート、バックアップ戦略の設計・実行など、全ての作業を自社で行わなければなりません。データベース運用に対する知見が不足していると、こうした作業を正しく計画・実施することは困難でしょう。特にバックアップの失敗によるデータ喪失といったトラブルは、非常にありがちな障害です。データベースはサービスの根幹を支えるコンポーネントですから、このような障害が発生すると、事業の継続性にも影響が出てしまいます。
対してマネージドDBでは、セキュリティアップデートやパッチ適用など、基盤レベルの管理作業をクラウド事業者に任せられます。自動バックアップや、データベースを任意の時点の状態へ復元する「ポイントインタイムリカバリー」機能も標準で提供されることが多く、データ保護に関する運用負荷が大幅に軽減されます。
可用性
自前構築DBで高可用性を実現するためには、レプリケーション設定やフェイルオーバーの仕組みを手動で設計・構築する必要があります。当然ですが、適切な設計と運用には高度な専門知識が求められます。
マネージドDBでは、冗長化構成や障害時の自動フェイルオーバー機能が標準で用意されています。クラウド事業者が構築した、信頼できる高可用性アーキテクチャを活用できます。
障害対応
自前構築DBでは、障害の検知から対応まで、すべてユーザー側で行う必要があります。夜間や休日の障害対応体制も自社で構築しなければならず、運用担当者の負担は相当大きなものとなります。
マネージドDBでは、障害の自動検知・復旧機能に加え、24時間365日の監視体制がクラウド事業者によって提供されます。軽微な障害であれば、ユーザーが気づく前に問題が解決しているというケースも珍しくありません。
アップグレード
自前構築DBでは、アップグレード計画の策定から実行まで、全て手動で行う必要があります。万が一にもアップグレードに失敗しないよう、事前検証や切り戻し手順の準備など、綿密な計画が必要となるでしょう。
マネージドDBでは、データベースエンジンのアップグレードや基盤レベルのアップグレードが、管理画面から簡単に実行できます。またクラウド事業者によって自動的に行われるケースもありますが、こうしたケースでは、任意のメンテナンスウィンドウを設定できるのが一般的です。メンテナンスウィンドウとは、システムの定期的な保守作業を行うため、あらかじめ設定された時間枠の呼び名です。例えば利用者数が極端に少ない深夜など、都合のよい時間帯をメンテナンスウィンドウに指定すれば、業務への影響を最小限に抑えながらアップグレードを行えます。
監視
自前構築DBでは、監視システムの構築から運用も、当然自社で行う必要があります。監視項目の選定、アラート設定、通知先の管理なども含まれます。監視システムをきちんと構築できていないと、障害が発生しているのに誰も気づいていなかった、といった事態も起こりがちです。監視の不備はサービスの品質に直結するため、企業の信頼を毀損するといった事態に発展することも考えられます。
マネージドDBでは、CPU使用率、メモリ使用率、ディスク使用量などの基本的な監視機能が標準で提供されます。閾値を超えた場合のアラート通知機能も利用できます。
FJcloud-VのマネージドDBサービス（RDB）の機能
FJcloud-VのマネージドDBサービスが「RDB」です。RDBは一般的なクラウドサービスのマネージドDBの例に漏れず、データベース運用を大幅に簡素化するための様々な機能を提供しています。ここではRDBの主要な機能を見ていきましょう。
冗長化
異なるホストに2台のデータベースサーバーを分散配置することで、高可用性を実現する機能です。アクティブ・スタンバイ構成を取ることができ、プライマリサーバーに障害が発生すると、自動的にセカンダリサーバーにフェイルオーバーされます。これによりサービスの継続性が保たれます。
なお、自動フェイルオーバーは、同名の機能が仮想サーバー（コンピューティング）にも用意されています。ですがコンピューティングの自動フェイルオーバーが、あくまでハードウェア障害にのみ対応するのに対し、RDBの自動フェイルオーバーはハードウェア障害だけでなく、データベースアプリケーション層もカバーしています。例えばサーバータイプの変更や、サーバーの再起動自にも自動的にフェイルオーバーが発生し、待機系に切り替えることで、ダウンタイムを最小にできます。単一障害点を排除した多重保護により、ミッションクリティカルなデータベース運用に必要な高可用性を提供しています。
リードレプリカ
DBサーバーのリードレプリカを追加することで、読み取り性能を向上させる機能です。読み取りアクセスをリードレプリカにオフロードできるため、プライマリサーバーへの負荷を軽減できます。例えば、ショッピングサイトなどでは、実行されるクエリのほとんどが商品の検索クエリというケースもあります。このように読み取りの負荷が高いアプリケーションにおいては、リードレプリカの追加はパフォーマンス向上に大きな効果があります。
外部レプリケーション
特に日本においては、地震や台風といった災害への対策は非常に重要です。こうした災害では、データセンター全体に障害が発生し、サービスの継続が困難となる可能性も無視できません。ディザスタリカバリの観点からすると、FJcloud-Vの別リージョンや、FJcloud-Vの外部へデータを逃がすことも求められてきます。RDBは、ゾーンやリージョンをまたいだレプリケーションが可能です。またFJcloud-V外部のDBサーバーとのレプリケーションにも対応しており、既存システムとの連携も柔軟に行えます。
自動バックアップ機能
FJcloud-VRDBでは、定期バックアップが自動で実行されます。バックアップの期間やバックアップを実行する時間帯も柔軟に設定できるため、業務への影響を最小限に抑えながらデータを保護できます。手動でのバックアップ作業が不要となるため、運用担当者の負荷や、ヒューマンエラーのリスクも軽減できます。
ポイントインタイムリカバリー
ポイントインタイムリカバリーとは、データベースの状態をある特定の時点に復元する機能です。この機能により、障害が発生してしまった場合でも、障害発生の直前の状態まで、確実にデータを復旧させることが可能となっています。ポイントインタイムリカバリーを活用すれば、データロスを最小限に抑えることができます。
ディスク割り当て
ビジネスの規模が拡大し、サービスの利用者が増加するのはよいことですが、データの肥大化によるDBのストレージ枯渇は大きな問題です。RDBではDBサーバーに追加でディスクを割り当てたり、後からの増設が可能となっています。オンデマンドに拡張が可能なため、スモールスタートとスケーリングを両立させられ、これはコスト最適化にも繋がります。
ネットワーク・セキュリティ
RDBには様々なネットワーク機能やセキュリティオプションが用意されています。DBファイアウォールによるアクセス制御に加えて、プライベートLANやSSLによるセキュアな通信にも対応しています。
マネージドDBと自前構築のDBの使い分け
ここまで解説したように、マネージドDBには多くのメリットがあり、運用負荷の軽減と品質の向上に大きく貢献します。一般的にはマネージドDBを活用できないかをまず検討すべきですが、とはいえすべてのケースでマネージドDBを使うことが正解とは限りません。システムの要件や運用体制に応じて、最適な選択肢は変わります。ここではマネージドDBと自前構築DBのどちらを選択するとよいのか、具体的なユースケースの一例を紹介します。
マネージドDB（RDB）を推奨するケース
ケース1 運用負荷を軽減したい場合
マネージドDB最大のメリットは、運用面の多くをクラウド事業者に任せられる点です。IT部門のリソースが限られており、データベース運用にかけられる工数を削減したい場合は、マネージドDBが最適でしょう。運用工数を削減することで、余剰リソースをアプリケーション開発により多く投入できます。
ケース2 高可用性が求められるシステム
どのようなシステムであれ、データを扱う以上、データを格納するデータベースが屋台骨となります。特に停止すると業務に大きな影響が出るシステムの場合、データベースの可用性の確保は非常に重要となるでしょう。マネージドDBであれば、専門的な知識がなくとも、エンタープライズレベルの可用性を実現できます。マネージドDBを採用すれば、冗長化機構や自動復旧機能により、サービスの継続性を確保できます。
ケース3 迅速な開発・デプロイが必要な場合
クラウドのメリットは、必要な時に必要なリソースを、迅速に確保できる点です。その中でもマネージドDBであれば、ミドルウェアの構築・設定作業すら不要で、ただちにサービスを開始できます。スタートアップや新規プロジェクトなどで、迅速な市場投入が求められる場合でも、マネージドDBを採用すればインフラの準備時間を大幅に削減できるでしょう。
自前構築DBを検討するケース
ケース1 特殊な設定やカスタマイズが必要な場合
マネージドDBは構築や運用をクラウド事業者に任せられる反面、自分たちでは自由にコントロールできない部分も存在します。特定のデータベースパラメータの細かな調整や、マネージドDBでは提供されない特殊な機能が必要な場合は、自前構築が適しているでしょう。
ケース2 既存システムとの互換性を重視する場合
長年データベースを運用した経験があり、確立された運用プロセスを持っている組織では、クラウド事業者任せにすると逆にやりにくいというケースもあるでしょう。こうした組織では自前構築することで、そのノウハウを活かした効率的な運用が可能です。またオンプレミスから段階的にクラウド移行を行う場合や、既存システムとの連携を重視する場合、既存の構成を維持できる自前構築が有効な選択肢となる場合もあります。
ケース3 開発・テスト環境での一時的な利用
マネージドDBは性能や可用性に優れますが、その特性上本番環境を見据えたサービスであり、開発やテスト目的ではオーバースペックとなってしまうことがあります。当然コストもかかりますから、短期間の開発プロジェクトやテスト環境では、既存のサーバーにDBを自前でインストールして同居させる、オールインワン構成を選択するのもよい考えです。データベースが動けばよい、可用性もいらない、といったケースであれば、自前構築によるコスト削減効果が期待できます。
まとめ
本番運用を見据えるのであれば、運用負荷軽減や可用性の確保から、多くの企業にとってマネージドDBが非常に有効な選択肢であると言えるでしょう。どのような組織であれ、割けるITリソースは限られています。余計な運用負荷を削減し、ビジネスの成長により多くのリソースを割くためにも、FJcloud-VRDBのようなマネージドサービスの活用を検討してみてください。
ただ、マネージドDBではコストがかかりすぎてしまったり、自由なカスタマイズができず、かゆい所に手が届かないといった問題もあるでしょう。そのため、自前構築を行った方がよいケースも決して少なくはありません。一方、自前構築でマネージドDBを越えるパフォーマンスや可用性を確保するためには、データベースエンジンへの深い理解が必要となる点には注意してください。また、技術的な要件だけでなく、組織の運用体制や事業戦略も重要な要素となります。
組織にデータベース運用の専門知識を持つ人材がいるか？ システム停止がビジネスに与える影響の大きさはどうか？ 初期コストと運用コストの長期的な視点での比較、求められるセキュリティレベルと運用リスクなどを総合的に検討し、自社の状況に最適な選択を行ってください。
