#始めに
こんにちは。CYBIRDエンジニア Advent Calendar 2015 6日目のMr_Kimです。
5日目はmegadreams14さんの「開発の見える化に取り組んでみた」でした。
開発進捗進行、プロジェクト管理を見える化に取り込んで開発の効率化を目指しています。革新的な進め方ですね。勉強になりました。megadreams14さんは弊社初Aurora Database導入にあたっての重要な存在です。
#本論に入る前に
筆者は社内データベースエンジニアとして、データベースに関する仕事をやっています。
突然、「オンプレミスDBとクラウドDBって、何が違いますか？」と言われたらどう回答しますか。
同じデータベースが動いて、コンソールでもウェブでも操作可能など変わりはないのですが、ちょっとデータベースの経験がある上級者はこう言うかもしれません。
「DBシステムのインフラが違うんだよ。」って、そうなんです。DBMSが動作するDBインフラ環境が違うんです。
それでは具体的にオンプレミスDBとクラウドDBは何が違い、どういうメリットとデメリットがあるのかを考えて行きたいと思います。
その他、データベース業務について理解していただき、データベース選択にお役に立てれば幸いです。
今回は特定のデータベースに関する「DBオタク話」は語りません。
#前提条件
- 筆者の知識や経験に基づいた内容
- クラウドDB：すでにデータベースが作成されているデータベース
- オンプレミスDB：自社で用意したサーバにDBエンジニアが構築・作成するデータベース
- DBエンジニア = データベース管理者（DBA:DataBase Administrator）
- ここではDBエンジニアをアプリ側DBエンジニア、インフラ側DBエンジニアに分けて考えている
#導入事例からオンプレミスDBとクラウドDBのメリットを知る
弊社の導入事例からオンプレミスDBとクラウドDBの相違点や、それぞれのメリットをいかに最大限生かしているかを紹介します。
オンプレミスDBとクラウドDBのメリットについては後述させていただきます。
##事例から分かるオンプレミスDBのメリット
筆者が12月2日に登壇して発表した「複数のRDBMSが混在するデータベースシステムにおける次世代仮想化基盤の導入について」内容になります。
データセンター移管に伴い、沢山のデータベースを移行することになった時に、オンプレミスDBがいいか、クラウドDBがいいかを悩んでいて、最終的にオンプレミスDBにした事例です。
- DB物理マシン全32台やストレージとネットワーク機器を含めて約70台が1台(4ノード)のハイパーコンバージドシステムに集約ができ、来年まで75%の保守費用削減を見込んでいる。
- 楽なクラウドDBを検討したが、必要とするスペックのDBサーバを、サーバ集約が可能で、低コストで安定して提供する事業者はなかった。もし、最高スペックのクラウドDBインスタンスと高速のディスクを選んだ場合は、毎月支払う費用は決して安くならなく、数年後は逆転する計算だった。
- 仮想化基盤のアプライアンスマシンなので、基本的にDB関連ハードウェア構成設計は不要で、仮想化基盤ソフトウェアはすでに搭載されていたので、必要なソフトウェアだけインストールしてすぐに使える。また、このオンプレミスサーバはストレージとネットワークが不要なハイパーコンバージドインフラ構成で、ハードウェアと仮想マシン両方クラスタ構成になっているため、信頼性の高い仮想DBサーバ運用が出来ている。
より詳しい内容はこちら「サイバード、24時間365日稼働しているDBシステムに Nutanixのハイパーコンバージドシステムを採用 ～約70台のハードウェアを1台に集約、3年間で75%の保守費用削減」
DBサーバの集約、ハードウェアの再利用により、運用保守コストが大幅に削減できることがわかりました。
##事例から分かるクラウドDBのメリット
弊社はオンプレミスDBだけではなく、クラウドDBも多く使っています。
代表的にAmazon RDS for MySQLを利用していますが、規模に合わせた使い分けを考え、新しく出たAmazon RDS for Auroraを検証し、結果が要件を満たした場合は、次の案件に導入することを計画しております。
Amazon RDS for Auroraについてはこちら
それでは、筆者が検証した「Amazon RDS for MySQL」と「Amazon RDS for Aurora」の検証結果を共有します。
※2015年12月時点の検証結果であり、すぐウェブ検索で確認できる内容は書いてありません。
・検証のRDS for MySQLのインスタンスクラス：db.r3.4xlarge-16vCPU,122 GB
・検証のRDS for Auroraのインスタンスクラス：db.r3.4xlarge-16vCPU,122 GB
| 項目 | RDS Aurora | RDS MySQL |
|---|---|---|
| MySQLデータの投入時間(55MB) | 40秒 | 50秒 |
| DEFAULT CHARACTER SET | latin1 | latin1 |
| MySQLソースバージョン | 5.6.10 | 5.6.23 |
| ロール（レプリケーション） | writerとreader | masterとreplica |
| データ復元 | 障害発生後、51秒前のデータまで | 障害発生後、1分10秒前のデータまで |
| 復元時の注意点 | 復元後、新規のDBインスタンスを使用する必要がある | 復元後、新規のDBインスタンスを使用する必要がある |
| 弊社DB監視ツール | MONyog、Zabbix、MyPMON(手作り) | MONyog、Zabbix、MyPMON(手作り) |
| 管理コンソールの監視項目数 | 多い(特にSQL性能関連) | 少ない |
| DBパラメータ数 | 232（新規とinnodb関連パラメータの多くが廃止） | 288 |
| SQL処理能力 | SQL処理能力が高く、CPUとメモリーを効率的に使うように見られる | Auroraに負ける |
| 書き込み(2台分) | 1750/s | 1000/s |
| 読み取り(2台分) | 0.015/s | 1.0/s |
| 書き込み遅延(2台分) | 3.5ms | 6ms |
| 読み取り遅延(2台分) | 2.5ms | 6ms |
| フィルオーバー(マルチAZあり) | レプリケーション復旧まで：44秒 | レプリケーション復旧まで：2分9秒 |
| フィルオーバー(マルチAZなし) | レプリケーション復旧まで：1分1秒 | レプリケーション復旧まで：1分26秒 |
| スケールアップ(マルチAZあり) | 7分3秒 | 15分21秒 |
| スケールダウン(マルチAZなし) | 9分39秒 | 20分33秒 |
| クラスタエンドポイント | あり | なし |
筆者はこの検証を苦労せずに数日で完了できたことに驚いています。(10回以上DBインスタンスを作り直しました)
オンプレミスDBなら考えられません。
#オンプレミスDBのリレーショナルデータベースの設計・構築・運用について
データベース工程（手順）には、大きく分けて設計・構築・運用があります。
データベース工程は通常のシステム開発工程と並行で行いますが、システム規模によってアプリ側とインフラ側の工程と共に行うこともあります。
-
設計：データを構造化し、データを記憶装置に永続格納するためのデータモデリング、データベース設計（概念、論理、物理）、データベースのキャパシティ・プランニング（＝DBキャパシティ見積）を作成します。場合によってはデータベース設計段階でDBMSを決めることもあります。
-
構築：設計結果(成果物)に基づいて、データベース構築要員を手配し、ハードウェアを調達し、ソフトウェアのライセンス購入・インストールメディアを用意します。ハードウェア構成から始め、OSやDBMSをインストールし、データベースを作成します。要件にデータベースクラスタ構成がある場合は、クラスタ構成と合わせてデータベースを作成・設定します。
-
運用：この工程で重要なのは安定したデータベースを稼働させることです。データベースの性能確保、拡張性、可用性、バックアップ、ACIDの維持、RTO(Recovery Time Objective：目標復旧時間)とRPO(Recovery Point Objective：目標復旧地点)を考慮したデータベース復旧、監視など、様々な要件を満たすための運用手法やツールを利用して維持するのが重要になります。
安定したDB運用を目指すにはデータベースの性能がとても重要ですが、意外にDB設計不具合で性能が落ちていることを気づかないことが多くあります。その一つが「SQL」です。
頻繁に実行されるSQLが一気に集中し、大容量テーブルをフルスキャンしてしまうと、DB全体性能劣化が起こります。対策としてテーブルの非正規化やSQLチューニングを行いますが、場合によってはサービス停止が必要なメンテナンスに入ることもあります。
Queryはリレーションテーブルの関係・構造から生まれ、実行されるものですから、悪いテーブルやインデックス設計は悪いQueryを生んでしまうことに繋がります。
スピード重視のソーシャルゲーム業界ではDB設計を軽視する傾向があり、サービスインしてから急激にDBサーバに高負荷が起こった事でゲームシステム全体の性能が落ちてしまうことをよく耳にし、体験したこともあります。
また、O/Rマッピングツール（Object-Relational mapping）によるSQL生成機能がとんでもないクエリを発行してしまったことで、性能障害を引き起こすことがあるため、O/Rマッピングツールとプログラム言語の選択も重要になります。
#DBエンジニアの位置づけ
プロジェクトの規模により、DBエンジニアの役割が決まります。
| 希望 | 役割・工程内容 |
|---|---|
| 超大規模PJ |
DB設計：DA(データ管理者)がデータ設計・データモデリング・概念設計まで担い、それ以外の論理・物理はDBエンジニアが担う DBシステム構成設計：ITアーキテクトや上級インフラエンジニアがDB基本設計や運用方針まで担い、DBMSに関する環境・物理設計はDBエンジニアが担う DB基盤構築・運用：ネットワーク・ストレージの構成と配置・ハードウェアやサーバの構築・OSとミドルウェアのインストールや設定といったDB基盤はインフラエンジニアが担い、DBMSのインストールと環境設定・DB運用は運用要員または、DBエンジニアが担う |
| 大規模PJ |
DB設計：DA(データ管理者)がデータ設計・データモデリング・概念設計まで担うことがあるが、工数や予算によってDBエンジニアがデータモデリング・概念・論理・物理設計を担うことがある DBシステム構成設計：ITアーキテクトや上級インフラエンジニアがDB基本設計や運用方針まで担い、DBMSに関する環境・物理設計はDBエンジニアが担う DB基盤構築・運用：ネットワーク、ストレージの構成と配置・ハードウェアやサーバの構築・OSとミドルウェアのインストールや設定といったDB基盤はインフラエンジニアが担い、DBMSのインストールと環境設定・DB運用は運用要員または、DBエンジニアが担う |
| 中規模PJ |
DB設計：DBエンジニアがデータモデリング・全体のDB設計を担うことが多いですが、開発者が行うこともある DBシステム構成設計：DBエンジニアが全体のDBシステム設計や運用方針を決め、DBMSに関する環境・物理設計を担う DB基盤構築・運用：ネットワーク、ストレージの構成・配置、ハードウェアやサーバの構築、OSとミドルウェアのインストール・設定といったDB基盤はインフラエンジニアが担い、DBMSインストールと環境設定、DB運用は運用要員または、DBエンジニアが担う |
| 小規模PJ |
DB設計：DBエンジニアまたは、開発者がデータモデリング・全体のDB設計を担う DBシステム構成設計：DBエンジニアまたは、インフラエンジニアが全体のDBシステム設計や運用方針を決め、DBMSに関する環境・物理設計を担う DB基盤構築・運用：ネットワーク、ストレージの構成・配置、ハードウェアやサーバの構築、OSとミドルウェアのインストール・設定といったDB基盤はインフラエンジニアが担い、DBMSインストールと環境設定、DB運用はDBエンジニアが担う。場合によってはOSからDBMSまでDBエンジニア、あるいはインフラエンジニアが全工程を担うこともある |
※Database Appliance製品を使う場合は、上記の設計・構築の工程が大幅減ります。
※クラウドDBを使う場合は、上記の設計・構築の工程が大幅減り、役割も大きく変わります。
#リレーショナルデータベース(RDB) の限界を超えた新タイプのデータベース登場
データベース容量がどんどん大きくなり、トランザクション量も増え、さらに巨大な書き込みが多発すると、データの整合性を保つために行われているロックメカニズムを導入しているRDBMSアーキテクチャでは性能が劣化してしまいます。
この問題を解決ためにDBサーバの数を増やして、マスターDB（書き込み・読み取り）とスレーブDB（読み取り専用）を使い分けてパフォーマンスを向上させるレプリケーションがありますが、マスターDBに障害が発生すると、マスターDBをソースDBとしたスレーブDBは、すべて影響を受けてしまいます。
すべてのDBサーバをマスターにして全ノードは書き込みが可能な商用データベースクラスタ製品もありますが、基本的に高価なハードウェアを導入し、ノード数を増やすと、さらに高くなり、負荷が集中する時は全体的なDBシステムにオーバヘッドが発生することがあります。
もちろん、全DBサーバは書き込みが可能で大規模トランザクション向けのデータベースマシンが出て、従来のRDBMSの限界を伸ばしているデータベースマシンのアプライアンス製品があります。しかし、価格が数千万円～数億円に至りますので、導入可能な企業は限られています。高機能としてはDBサーバ側でテーブルフルスキャンの実行計画を作成しても、SQLの絞り込み条件や列リストをストレージサーバが認識し、必要なデータのみをDBサーバに返します。さらにパラレルSQLを実行することでより性能を最大限引き出せるという。。。
最近はこういったRDBMSの抱える課題を解決できるアンチテーゼとして登場したのは「NoSQL」です。
NoSQLはRDBMSと違って結果整合性のみを保証するなどして一貫性の保証を弱く設計したもので、関係モデルを必要としないデータを扱う時や大量のデータを扱う時に有用です。
NoSQLはスケールアウト型であり、書き込み負荷の分散が可能で、容易に耐障害性も高めることができるという点です。
簡単にまとめると、RDBMSは「トランザクションの一貫性とデータの整合性」であり、NoSQLは「性能と拡張性」だと言えるでしょう。ま～、お金さえあればRDBMSとNoSQLの弱みを乗り越えるRDBMSのアプライアンスマシンの導入もいいでしょう。
しかし、NoSQLはRDBMSのリプレースデータベースとして扱われることはできませんでした。理由としては以下のことが挙げられます。
- トランザクションを保証してくれないものが多い。
- SQL言語はビジネスアプリケーションに使われており、SQLのように柔軟にデータを操作・加工することができない。
- ハードウェアも進化を続けており、あえてRDBMSの素晴らしさを断念してNoSQL向けのシステム開発必要はない。
- そもそもNoSQLはRDBMSのリープレスデータベースとして誕生したわけではないため、NoSQLとRDBMSの強みを生かして使うシステムは増えている。
※実際に弊社ではNoSQLとRDBMSそれぞれの特徴を生かした形のハイブリッドスタイルで導入しているゲームシステムがあります。
#オンプレミスとクラウドの比較
以下のクラウドサービスプロバイダウェブサイトにまとめられているのでご覧ください。
・自社サーバーと AWS クラウドの違いとは？
・オンプレミスvsクラウド移行のメリットや課題
・サーバ不要のクラウド型とオンプレミス型を徹底比較
#オンプレミスDBとクラウドDBのメリット・デメリット
| オンプレミス | クラウド | |
|---|---|---|
| 維持管理 | 資産管理と保守が必要 | 資産管理と保守が不要 |
| 初期導入費用 | ハードウェアとソフトウェア、ネットワーク、ストレージなどで高コスト | 初期費用無料が一般的 |
| 運用費用 | 保守費用以外は発生しない | 使った分だけ支払い |
| 商用DBライセンス | サーバスペックに合わせて購入・管理が必要 | 「ライセンス込み」と「ライセンスを自分で用意」がある |
| インフラ構築期間 | 機器調達からインフラ環境構築まで数か月 | アカウント登録後すぐに利用できる |
| DBMS高機能・クラスタ構成 | 自由に使用可能 | 使用不可な場合がある |
| スケールアップ・ダウン | サービス停止があり（数時間）、リスクもあるためほぼ不可 | ウェブ画面ですぐに変更可能（数分以内） |
| DBセキュリティ設定 | 制限なし | 制限されることがある |
| 他のサードパーティ製品との連携 | 自由に使用可能 | 使用不可能な場合がある |
| DBサーバ運用 | 退屈で面倒なデプロイ、メンテナンス、バックアップ | 退屈で面倒なデプロイ、メンテナンス、バックアップから解放 |
| ハードウェア交換 | 現地へのオンサイトおよび機器調達 | クラウド事業者が行う一切関与しない |
| OSへログイン | 常にログイン可能 | ログインできないことがある |
| DBパラメータ | 自由に変更可能 | 一部のパラメータは変更できないことがある |
| DBサーバ運用管理 | 制限なくやりたいことができる | 提供されるフルマネジメント機能を利用することが多い |
| DB性能 | 細かくOSやDBのチューニングが可能で最新の高性能のハードウェアが使用可能 | 用意されているインスタンスを利用 |
| DBキャパシティ設計 | しっかり設計しないと無駄が発生しやすい | 見積もりレベルでスモールスタートが可能 |
| DBのバックアップとリカバリ | バックアップ環境を構築 | 用意されているバックアップ機能を利用 |
| DBの可用性と信頼性 | クラウドより高い可用性と信頼性実現可能 | 低コストで利用可能 |
| DB障害対応 | 自社で復旧作業を行うが、DB全領域の障害の対応が可能 | クラウド事業者が復旧作業を行うが、インフラ障害以外は対応できない |
| 対応規模 | 広範囲で対応可能 | 小規模～大規模で可能だが、スケールアップに限界がある |
| 求められる技術 | ハードウェア・インフラ・DB構築・SQL・チューニング・DB構成(冗長性・可用性) | 利用しているクラウドDBについての知識・SQL・チューニング（許容範囲内） |
| 得られる技術 | 様々な新DB技術を取り込むことが可能 | 利用しているクラウド環境のDB技術に依存してしまう |
| DB理解度 | 自社で設計と構築したのですべて理解している | クラウド事業者からの情報が全て |
| DB物理設計 | 要件に合わせて設計 | 要件とクラウドDBの制限を考慮して設計 |
| 使用範囲 | 殆どのDBは使用可能だが、一部はクラウド環境しか使えない | クラウド業者が提供するDBしか使えない |
| NoSQL使用 | 殆どのNoSQLは使用可能だが、一部はクラウド環境しか使えない | クラウド業者が提供するDBしか使えない |
#クラウドDBの懸念点
##1. DB技術力の低下
プログラム開発者がDBサーバを構築できる時代になっている今、個人的に新卒DBエンジニアには最初からクラウドDBに触れないようにしたく、ハードウェア選定からDB設計、DB構築などのオンプレミスDBの様々な経験を積んで欲しいです。
筆者が実際にクラウドDBを作成し、使ってみたところ、使いこなせるまでは1日（クラウドDBの動作 、メリット、操作を理解）で済みました。
エンジニアの技術的な考え方・スキルは不要で、只のサービス利用者となり、クラウドDB依存の危険性を再認識しました。
但し、エンジニア観点からみたものですので、社内にインフラ環境がなく、DBエンジニアがいない（足りない）企業では、クラウドDBには色々な魅力があり、素晴らしいソリューションになると思います。
##2. インフラ系DBエンジニアの需要軽減
最近DBMSの機能やハードウェアの進化により、細かくDBを設計し、DB性能チューニングする案件数が減り、上級DBエンジニアが行く場所も減っているという現実を受け止めていますが、クラウドDB登場により、さらに自分たちの必要性まで心配しなければなりない時か来るかもしれません。
##3. 予測不可な請求金額
クラウドDBは使った分だけ支払いますが、導入後時間が経ってシステム規模が大きくなると、支払費用が高くなります。場合によってはオンプレミスDB運用費用よりもっと高くなることがあります。
##4. クラウド依存度
クラウドは便利な反面、DBシステムやデータ管理においてクラウドサービス提供会社に依存してしまうという側面があります。クラウドのシステム障害やサービス会社の倒産などが起こると、依存度に比例してリスクも大きくなってしまいます。
特にデータベースは簡単に移行できるものではなく、インフラ環境が変わると今までの性能を出すことが難しくなり、安定させるための手間やコストが必要になることが多いです。
データベース容量が数TB～数十TBで、データベースクラスタを組んでおり、拡張したデータベースサーバ数が多い場合は、DB移行とDB再稼働まで絶対に１日以内に終わらないでしょう。
#DBエンジニアの業務領域の変化
上記の「クラウドDBの懸念点のインフラ系DBエンジニアの需要軽減」を受けて、DBエンジニアの危機と思われる方がいらっしゃるかと思いますが、そんなに心配は要りません。理由は以下にあります。
- DBエンジニアの仕事はDB構築がすべてではない
- クラウドDBに関する新しいDB案件が増えている
- クラウドDBの進化により、NoSQLデータベース導入の案件が出てくる
- 大規模プロジェクトにはオンプレミスDBが多く、オンプレミスDBしか導入できない案件も沢山ある
ということで、クラウドDBの活躍により、我々のDB仕事の業務領域の変化があるだけで、DB仕事が無くなるわけではなく、ただDB構築仕事が減るだけで減った分を設計・運用・チューニングに工数を割り振ればそれで事足ります。勿論クラウドDB向けのDB仕事も沢山あるでしょう。
#社内のプライベートクラウドを作ってみたら？
オンプレミスマシンで社内プライベートクラウドを構築し、その環境からクラウドDBサービスを運用するって、如何でしょうか。外部のクラウド事業者のクラウドDBを利用するよりは、安価（あるいは無料）で柔軟性の高い社内クラウドDBを使おうということです。
実際に弊社ではオンプレミスマシンを利用して、可用性・高性能の仮想DBサーバを運用しています。必要になったら仮想DBサーバを作成し、不要となったら削除することで、マシンのリソースを最大限に有効活用しております。
#クラウドDBがインフラのDB領域と企業に貢献した点
- インフラの技術革新
- ウェブ画面でいくつかDB情報を入力し、数回クリックするだけで、高性能・可用性・冗長性のDBサーバができてしまいますので、革新的と言うしかないですよね。
- 構築・運用のコスト軽減
- オンプレミスDBはきちんと見積らないと無駄なコストが発生しがちですが、クラウドDBは初期費用なしでスモールスタートができます。またスケールのアウト、アップ、ダウンが柔軟に可能となり、高いスケーラビリティや信頼性の高いサーバ構築ができ、フルマネジメント機能などが使えます。
- 構築・運用の工数低減
- 最小限のインフラ設計で、冗長化構成やDB構築の工数が数時間で終わり、管理が簡単で、運用に必要なツールは用意されているため、利用するだけで手間のかかるタスクから解放されます。余った工数をテスト工程に使い回せばシステム品質向上にも役に立ちます。
#最後に
最近クラウドDBは導入事例がどんどん増えていて、エンタプライズ向けのクラウドDBも出ていますが、大規模向けのオンプレミスDBの性能までは至っておりません。
それでもDB性能を認識したDB設計やDBチューニングを行うことでそのギャップはある程度狭めることができるでしょう。
IT技術進化と時代の流れにつれてクラウドDB導入はどんどん増える一方ですので、新クラウド向けのDB設計・DB運用方式を採用する時代がやってきます。
但し、クラウドを利用する際は、そのリスクとリターンをよく考慮した上で自社管理とのバランスを考えていく必要があります。
CYBIRDエンジニア Advent Calendar 2015明日は、asuky さんの[ (このクラウド時代に)自作サーバで重複排除やストレージ階層化を試してみる話] ()です！
asuky さんは優秀な後輩インフラエンジニアで、インフラ側のDB仕事に色々お世話になっています。