オープンソースデータベースを管理するための新しい方法

少し前まで、データベース業界は少数のベンダーで構成されていました。データベースは主にリレーショナルであり、単一のマシンで実行されていました。高可用性は、アクティブスタンバイの「クラスター」を介して実装されました。垂直方向の「スケールアップ」モデルでは、主に共有ストレージ（SANまたはDRBD）またはログの非同期レプリケーションで状態をスタンバイノードに同期していました。 2001年に私がNDBクラスター（後にMySQLクラスターになる）を使い始めたとき、データベース全体をメインメモリに保持するという概念は奇妙でした。「サーバーの電源を切ったらどうなるでしょうか？」データベースを複数のサーバーに分散することは心配でした。「あちこちにデータがあります」。そして、ミッションクリティカルなワークロード用のオープンソースデータベースのアイデア全体は笑いました。

15年早送りすると、現在、市場には数十のデータベースベンダーがあります。ほとんどがオープンソースで、さまざまなモデル（キー値、ドキュメント、グラフなど）であり、デフォルトで配布されています。メモリ常駐データは、高性能と低遅延を実現するためのほぼ標準です。 （db-enginesランキングによる）上位5つの最も人気のあるデータベースのうちの3つは、オープンソース（MySQL、PostgreSQL、およびMongoDB）です。最近では、さまざまなデータセンターに分散されたデータベースサーバーのフリートを管理する可能性が高くなっています。一部のデータベースをサードパーティのクラウドベンダーが管理している場合もあります。

では、2018年にデータベースを管理するのはどうですか？

自動化

管理するタスクが非常に多く、1日の時間も非常に長いため、手動で物事を行うのは気が狂います。

自動化は物事を成し遂げるための素晴らしい方法です。管理するデータベースがほとんどない場合、データベースの操作は非常に実践的であり、一部のタスクはbashやperlなどでスクリプト化されます。たとえば、データベースをバックアップするスクリプトや、バックアップファイルを特定の場所に移動するスクリプトなどです。フェイルオーバーは手動で行われ、自動化する必要があるかどうかについても議論します。

今日では、自動化は簡単です。活用できるIT自動化または構成管理システムは多数あります。Puppet、Chef、Ansible、Saltはすべて、さまざまなデータベーストポロジの自動化を構築するために使用できる汎用フレームワークを提供します。データベース設定を管理するために特別に作成されたクラスター管理ソフトウェアには、MongoDBOpsManagerとClusterControlが含まれます。これらにより、運用チームは、すぐに利用できるものを使用してクラスターを管理できます。構成管理システムを使用してクラスター管理システムをゼロから構築することは、簡単なことではありません。自動化ツールに関する重要な専門知識に加えて、バックアップのスケジューリングと検証、システムのその後の再構成を伴う自動フェイルオーバー、構成変更の展開、パッチ適用、バージョンのアップグレードまたはダウングレードなどの管理操作の理解が必要です。

そしてもちろん、展開、正常性、フェイルオーバー、バックアップなどがすべてソフトウェアによって制御されるDBaaSサービスプラットフォームの台頭があります。クラウドプロバイダーは確かに自動化に非常に優れています。 Amazon RDSは、大規模なデータベース自動化の優れた例です。デプロイ、パッチアップグレード、バックアップ、ポイントインタイムリストア、レプリカのスケーリング、高可用性/フェイルオーバーを自動化します。

ペットvs牛

90年代、ドットコムブームとバストが発生するまで、SunMicrosystemsとOracleは大規模なSMTPハードウェアでスケールアップデータベースを販売して大金を稼ぎました。そこにいくつかのSANストレージとVeritasフェールオーバーソフトウェアを投入すると、高可用性を実現する最先端のアクティブスタンバイフェールオーバークラスターを手に入れることができます。データベースサーバーの数は比較的少なかったが、垂直方向に成長するため強力である。彼らには名前が付けられ（あなたがペットに名前を付けるのと同じように！）、DBAによって世話をされました。

現在、データベースは安価であり、コモディティハードウェア上で適切に動作します。それらはたくさんあり、牛のように番号を付けます。壊れた場合は、新しいものを入手できます。

また、新しい種類の牛、つまりオープンソースの牛でもあります。 db-enginesによると、上位5つのデータベースのうち3つはすべてオープンソースであり、2つのプロプライエタリベンダーの市場シェアをゆっくりと、しかし確実に食いつぶしています。オープンソースは、オペレーティングシステムだけでなく、データベースにとっても新しいデータセンター標準です。

それで、これはあなたにとって何を意味しますか？まあ、将来的には、オープンソースデータベースを管理する可能性が高くなります。あるいは、異種データコレクションを使用するアプリケーションの場合は複数のデータベースを管理する可能性が高くなります。ポリグロットの永続性とマイクロサービスの世界では、基盤となるデータストアはデータの性質によって決定されるようになりました。アーキテクチャの観点から、ディスクベースのHAを備えたシングルインスタンスデータベースは、複数のデータセンターに分散している可能性のあるクラスターに取って代わられています。

DBAが必要ですか？

DBAの役割は特殊なものであり、1つになるには何年もの経験が必要です。以前は、選択できる独自のデータベースベンダーが数社しかなかった場合、特定のスキルと経験を備えた専門のDBAが必要でした。また、これも必要でした。OracleやSQL Serverのようなデータベースには、何十年にもわたって構築された膨大な機能セットがあります。それらは管理が容易ではありません。これらは通常、アプリケーションの唯一のデータベースとして展開され、監視、データのバックアップが必要であり、発生した問題には対処する必要がありました。これらのタスクは、まさにDBAがここで焦点を当てていたものでした。

しかし、過去10年間で、まったく新しいデータベース業界が出現しました。数十から数十のオープンソースデータベースとクラウドデータベースサービスがあります。前に見たように、アプリケーションがいくつかの異なるデータストアを使用することは珍しいことではありません。しかし、企業が使用するこれらのデータストアのDBAを持っていることはめったにありません。 MongoDB、Cassandra、または5年以上の本番経験を持つ<新しいお気に入りのデータベースを挿入> DBAはどこにありますか？新世代のNoSQLデータベースは、以前のクローズドソースデータベースよりもはるかに単純であるため、同じ学習曲線を必要としないと主張することができます。

それらの管理は、SysAdmin、DevOps、またはサイト信頼性エンジニアリング（SRE）チームのToDoリストに追加されるもう1つのタスクです。そして今日、多くの企業がフルタイムのDBAを持っていないことがわかります。代わりに、責任はチーム全体に分散され、自動化ツールが日常のタスクを処理するためにますます使用されています。クラウドに移行したデータベースの場合、データの保存方法の運用面は完全にクラウドプロバイダーにアウトソーシングされます。そのため、データの保存方法に取り組む代わりに、運用チームはデータの使用に集中できるようになりました。

データベースのライフサイクル

データベースの平均ライフサイクルは、現在よりもはるかに長くなりました。データベースプラットフォームを選択したら、それだけです。決定は、通常はDBAまたは組織の上位の誰かによって、2つまたは3つのリレーショナルデータベース間で行われます。会社は永久ライセンスを購入するためのお金を見つけるでしょう。決定が下されたら、あなたは今、次の10年以上それと一緒に暮らす必要がありました。データベースはモノリシックであり、アプリケーションは通常、単一の共有データベースを使用します。

今日、コンテナ、クラウド、マイクロサービス、CI / CDパイプラインの世界では、開発者がテクノロジーを選択することは珍しくありません。特に、簡単にダウンロードしたり、サービスとして提供したりできるオープンソースデータベースの場合は、営業担当者と話をしたり、経営陣に予算を求めたりする必要はありません。組織はより迅速に価値を創造するという課題に直面しているため、インフラストラクチャ/アプリケーションの変更率は劇的に上昇しています。モノリシックデータベースは現在、複数の小さなデータベースに分割されており、各データベースは個々のマイクロサービスのドメインデータを管理しています。オープンソースエコシステムで現在利用可能なさまざまなデータベース製品により、チームはより優れたデータストアに移行するための選択肢と自由を手に入れることができます。サービスが試運転および廃止されると、データベースもそれに続きます。ただし、データ自体はアーカイブされるか、データレイクに移動される可能性があります。今日、はるかに動的なインフラストラクチャの状況では、データベースの寿命が短くなっていることがわかります。

DBA ROLE

DBAは、従来はデータベースの保護者とゲートキーパーの両方であり、組織内のさまざまなアプリケーション/インフラストラクチャチームのデータベースニーズに対応していました。データベースへのアクセスまたは変更を必要とする変更には、DBAのサービスが必要になります。ただし、優先順位の競合とDBAの可用性の欠如は、プロジェクトがブロック/遅延され、避けられない摩擦が続くことを意味する可能性があります。

コラボレーションのコストが高く、イノベーションが速く、市場投入までの時間が短いというのは、うまくいきません。前に見たように、マイクロサービスは、インフラストラクチャとアプリケーションサービスが、可能な限り分離するように設計されている方法の例です。データベースはますます自動化されており、データベースの制御は開発者またはプロジェクトチームに移っています。スキーマの変更のようなものでさえ、以前ほど重くはありません。モノリシックアプリケーションの中央データベースのコンテキストでは、これらははるかに困難でした。異なるコンポーネント間でデータが共有されているため、スキーマの変更を調整し、慎重に計画する必要があります。通常は数か月前です。 DBAは、変更を理解して実行する上で重要な役割を果たしました。変化の速度がはるかに速い今日では、ダイナミクスは異なります。開発チームが本番環境でコードの変更を毎週または毎日、あるいは1日に数回プッシュすることも珍しくありません。データベースは、アプリケーションの変更に対応するために絶えず更新する必要があり、これらは開発者によって実行されます。 MongoDBのような新しいデータベースの中には、スキーマレスモデルを使用することで非常にシンプルなものもあります。これが効果的に意味するのは、データベーススキーマがアプリケーションコードに移行しているということです。

では、すべての一般的なコアタスクが自動化されている場合、将来的にDBAの役割はどうなるでしょうか。 DBAは、管理タスクに集中する代わりに、組織内の他のチームのメンターとして機能します。組織は、所有しているデータと、そのデータをどのように使用できるかを理解する必要があります。結局のところ、データは、保存されているだけでなく、他のリソースと共有および結合されたときに最も価値があります。スキーマレスは素晴らしいように聞こえますが、データベースまたはコードのいずれかでデータを追跡する必要があります。セキュリティは課題であり、データ侵害は悪化の一途をたどっています。したがって、データを再び素晴らしいものにするためには、DBAはチームにまたがる水平的なアドバイザー/イネーブラーの役割に移行する必要があります。コンピテンシーの観点から、最新のDBAは、分散型の高可用性システムを設計する方法を理解し、日常的なタスクを処理するための効率的な自動化システムを導入する必要があります。企業がクラウドまたはコンテナ環境全体にインフラストラクチャを展開する場合、これらのプラットフォームで高可用性でスケーラブルなデータベースを構築する方法を理解することで、DBAの存続が保証されます。

概要

私たちは、過去20年間で大規模な変革を遂げてきたデータベース業界の歴史の中で、魅力的な接点に座っています。以下の表はそれを要約しようとしています。

オープンソースのデータベース管理についてのあなたの考えと、同じ傾向が見られたかどうかを聞いてみたいと思いますか？ここ数年のOSDBでの苦労や成功はどのようなものでしたか？そして、来年は何が起こると思いますか？

私たちSevereninesはもちろん、来年以降もオープンソースデータベースの管理と自動化を促進するために兵士として働き続けます。ですから、来年1月からの最新情報にご期待ください。

それまでの間、私にあなたの考えを知らせてください、そして2019年にあなたに会いましょう！

SoRad（Shutterstock）＆TheSimpsonsによる写真;他の写真はそれぞれの所有者によるものです。