本記事はGlobal Solutions ArchitectのMaksim Malyginが2019年11月11日に投稿した記事の翻訳版です。
原文はこちら。
皆様が日々利用されている会社のCRMから電話で遊んでいるゲーム、そして雑貨店のセルフサービスのPOSに至るまでの殆どのアプリケーションは、それがクラウドベースであれ、オンプレミスであれ、もしくはサービスとして提供されているにしても、データベースによって支えられています。こうしたアプリケーションによって利用されるデータベースはデータを操作、処理し、直接的にアプリケーションの拡張性やパフォーマンスに影響を及ぼしており、データベースのプラットフォームはビジネスの成功にとって重要な要となります。アプリケーションの数の急速な増加とともに、データベースの市場も同様に成長し、2026年までには$155.50Bに達すると予測されています(リンク)。
それと同時に、DBaaS(データベース・アズ・ア・サービス)が複雑なデータベースの管理の必要性とデータベース管理者やインフラストラクチャチームとのやり取りをせずに済むようにして、その代わりにアプリケーションの開発にフォーカスできるようにすることで開発者がどのようにデータベースを利用するのかを変革しつつあります。さぁ、どうやってそれが可能になるのか、そのやり方を詳しくみていきましょう。
もしもエンタープライズITの世界に少しでも身をおいたことがあるのであれば、「Everything-as-a-service(あらゆるものをサービス化)」(XaaS)するというアプローチについて聞いたことがあるかもしれません。そして、殆どの場合、従来からのアプローチでもうまく行っているのに、どうしてIT組織は何かをエンタープライズに向けてアズ・ア・サービスとして提供するべきなのかということを自問自答したのではないでしょうか？結論から言うと、ITをどのように利用・アクセスするのかということがお客様の目線から見るとこの10年で変化してしまっているということです。すでに世の中にはUber、Airbnb、そしてパブリッククラウドがあり、すぐに利用できて、利用しただけ支払うという利用モデルが新しいスタンダードになってしまっているのです。これがエンタープライズのITにも当てはまります ー 社内の顧客は迅速で簡単に、想定通りの、成果報酬ベースの、ビジネスのニーズに最適化されたサービスにアクセスできることを望み、先行投資や構築をまったりサポートの心配はする必要がないと考えているのです。
このアズ・ア・サービスのアプローチはITとビジネスユーザーの関係性をエンタープライズの効率化を推し進め、やり取りのコストややり取りのための時間を減らす手助けをするという意味で一つの方向性へまとめてくれます。もはやIT組織にとって、XaaSは「ITを運用する人」という意味ではなく、サービスを提供し、それとともに明瞭なコスト配布モデルを提示してくれるビジネスパートナーとして扱われるという意味を持つのです。
DBaaS 産みの苦しみとどうそれを癒やすのか
ITの殆どの部分は「サービス」モデルへととてもスムーズに移行してきましたが、データベースチームはその移動の中で通り抜けがたいいくつかの問題に直面してきました。しかしながら、これはDBaaSをプライベートのEnterprise Cloudで構築するということが不可能であるということではありません。これらの問題に分け入り、どのようにそれを解決し、エンタープライズで利用できるサービスレベルのDBaaSをどうやって確実に構築するのか見ていきましょう。
課題 #1: 分断されたコンピュート、ストレージ、そしてデータベース
データベースの展開の手順の中にそれを支えるコンピュートとストレージリソース(それがサービスとして提供されていたとしても)の展開を統合することは簡単ではありません。従来から、データベース管理者はストレージ領域の割り当て、コンピュートの展開、そしてOSのインストールを要請しなければなりませんでした。殆どの場合、これは3つの別々のチームによって行われてきました。この一部はAnsibleのようなツールで解決しますが、これはまだエンドツーエンドの自動化であるとは言えません。
この問題を完全にそして永遠に解決するためには、コンピュート、ストレージ、そして仮想化が融合された単一のプラットフォームを利用するのがベストです。ハイパーコンバージドプラットフォームを利用することで簡単にそして一元化され、一貫性をもったインフラストラクチャサービスの展開がプログラマティック(Nutanix APIに感謝です！)に実現可能です。Nutanix Eraがハイパーコンバージドプラットフォームと自動化の両方の力を融合させ、新しいデータベースサーバのための仮想マシンの展開のすべてのステップを受け持ちます。
課題 #2: データベースサーバの構成とセキュリティ
新しいデータベースサーバ(OS/データベース)を立ち上げ、エンタープライズ向けの標準構成(パフォーマンスの観点からセキュリティとバックアップに至るまで)を適用するという部分は展開のSLAに影響を及ぼすもう一つのボトルネックです。
安定した基盤があれば標準構成(仮想マシンとデータベースの双方について)を自動的に適用することができ、一貫したパフォーマンス(繰り返しになりますが、これはデータベース管理者がプラットフォームをコントロールできない場合 ー 標準化の検証を可能な限りのストレージ/コンピュートの組み合わせ全てで実施しなくてはなりません)をえることができます。こうした最適化されたデータベースの構成はEraによって提供され、Nutanixクラスタ上で最大のパフォーマンスを提供できることが保証されます。セキュリティ(インフラストラクチャの観点から)はNutanix AOSにビルトインされている自動化されたSTIG実装でとても簡単になります。データベースについての標準セキュリティがその上にEraによって適用されます。
課題 #3: どうやってSLAを満たすのか?
データベース管理者チームにとってパフォーマンス、可用性、そしてバックアップ/リカバリのSLAを保証するということは課題であり続けてきました。これは彼らがほとんどのサービスをコントロールできないということに原因がありました。
下を支えるプラットフォームとの密な統合が重要です:
- DBaaSが必要とされるレベルの可用性(更に可用性を高めるためにデータベースサーバをクラスタ化して展開できる)を提供できることを保証するために、同じ(もしくはより厳格な)SLAを満たすことができるプラットフォーム。Nutanixのハイパーコンバージドプラットフォームは可用性のSLAを担保するための構成を用意に実現できる上に、Eraはクラスタ化されたデータベースを展開することができます。
- データベースのパフォーマンスはコンピュートおよびストレージの安定性(ノイジーネイバー - やかましいお隣さん が居ないこと)と適切なサイジングに大きく依存しています。最初の問題はNutanixクラスタ上では仮想的に不可能ですので、残された問題は仮想マシンのインスタンスを適切にサイジングするということになります。
- データベースのバックアップとリカバリはストレージスナップショットと統合されることでとても簡単になります。しかしながら、3階層の環境の場合、それだけで複雑な「スナップショットマネージャー」を利用しなければなりませんので、構成と運用は複雑で時間がかかるものになります。一方でNutanix Eraを利用する場合、その統合はほとんどインビジブル(意識する必要がない)で ー インストールや構成、維持する必要はありません - データベースを「タイムマシン」機能とともに一貫してバックアップしただ動作するのです。
課題 #4: どうやって最新に保つのか
多くのホスト/インスタンスがある動的なデータベース環境がある場合にはデータベースとOSのパッチ作業は殆ど日々の(そして夜間の!)通例タスクになり、セキュリティと可用性のSLAへ影響を及ぼします。
この問題を解決するために、Eraは自動化された1-クリックでのデータベースサーバへのパッチメカニズムを提供します。データベースのパッチを本稼働環境のインスタンスに影響を可能な限り最小に抑えながらテストするということも可能です。
課題 #5: 低速なCDM(コピーデータ管理)手順でストレージ利用を食いつぶす
本稼働環境から開発/受け入れテスト(UAT)環境向けにデータベースをクローンするには多くのデータをコピーした上にマスクを実施しなければならず、データベース管理者は週末に休むことなく働き続け、更にはストレージベンダーを大喜びさせています。
以前に述べたように、ストレージスナップショットとの統合でバックアップは簡単になり、大規模なストレージの節約に繋がります。自動化された仮想マシンとデータベースの展開の統合に加え、データマスクソリューションを提供することで高速でリソース効率の良いCDMを実行する能力を提供することができます。
課題 #6: 大規模でバラバラのデータベースポートフォリオ
平均的な企業では4-6つのデータベースタイプが利用されています ー 従来型のOracleやMSSQLからNoSQLデータベースに至るまで、データベース管理者にとってこれはこれまで上で述べてきた課題をそれぞれのデータベースのタイプ全てにおいて解決しなければならないということを意味します。
本日の時点でNutanix EraはOracle、Postgres、MySQL、そしてMariaDBの5つのデータベースエンジンに対応しており、将来のリリースでは更に多くに対応する計画です。
さぁ、今度はDBaaSを実現するためのいくつかの概念とツールについてみていきましょう。
サービスを走らせるため必要なもの
ITIL (少し読むには退屈ですが、とても有用です!)によると、サービスの定義は多くの要素から構成されていますが、今回我々は最も重要な部分にフォーカスします、すなわち：
- サービスとアセットの重要性
- このITサービスを利用するビジネスサービスがどれほど重要なのか
- サービスレベル要件/目標
- 展開時間 / 可用性 / 信頼性 / パフォーマンス / キャパシティ 等
- サービスのインターフェイス
- このサービスはどのように利用されるのか
- 価格モデル
- このサービスについてのコスト配布モデル
上のすべてのメトリクスは容易に測定可能で、強固なDBaaSの基盤となります(もしも測定ができないのなら、管理することなど到底できないのです!):
重要性はもしもそのサービスが特定のビジネス要件をサポートするものであり、それによってサービスレベル要件(ビジネスのSLAを反映している)を定義するものであればまずはじめに検証、理解すべきものです。重要性は一般的に以下のうちの一つのカテゴリで定義されます:
一度重要性が確定すれば、サービスレベル要件も定義することができます:
Nutanix Eraではサービス定義にマッチするSLAプロファイルを作成することができ、一度すべての重要度のレベルと関連するSLAが確定すれば、それをEraの構成へと読み替えることができます:
データベースの展開の最中に、データベースインスタンスに対して特定のSLAを適用することができます:
そして、最後にいい忘れていましたが大事なこととして、コンピュートとデータベースのサイズもサービス定義内で定義しておきます:
…そして、Era内で公開します
すべてを一つにする
新たなDBaaS製品を作り上げることは非常に大変なことで、課題を伴う道筋です。更にそれを健全に保ちながら維持することはもっと難しい問題です。Nutanix EraはDBaaSの「産みの苦しみ」を癒やすために特化して作られた製品です ー 多くのデータベース管理者を苦痛から開放するだけでなく、DBaaSを完全にサービス設計のプロセスと足並みを合わせた形で機能提供しています。
2019 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).