DevOpsでは、開発と運用、継続的なパイプラインとアジャイルアップデート、ビルドのロールアウトなどが話題になります。しかし、非常に重要なもの、つまりデータベースが見落とされがちです。
開発環境でも本番環境でも、データベースはインフラの重要な構成要素です。そして、組織内の誰もがデータベースを利用したいと考えています。
IT 部門には通常、データベース管理者 (DBA) が開発者がスキーマやストアド プロシージャに対して要求した変更を確認できるデータベース リリース管理システムがあります。
データベースリリースの自動化ツールを販売するDaticalのCTO、ロバート・リーブス氏によると、組織がリリースサイクルを加速させ、データベースチームの同期が取れなくなると問題が発生します。これは、アジャイルで継続的なビルドを特徴とするDevOpsを導入した場合に起こり得ることです。
「Pivotal CloudFoundryを導入した米国に拠点を置くある自動車メーカーと協業したことがあります」と彼は振り返る。理論上、このツールは迅速な導入を可能にする。cf pushアプリケーション名を入力するだけで、開発チームがインフラについて心配することなく、ソフトウェアが本番環境にリリースされる。
「データベースが更新されるまでは、そうすることができませんでした。なぜなら、これらの作業は密接に関係しているからです」とリーブス氏は言う。「DBAが対応するまで、7～12営業日も待たなければなりませんでした。」
他にも潜在的な問題があります。一つはデータベースドリフトです。データベースの変更をすべて自動化システムで強制していない場合、短気な開発者がQAスキーマ、あるいは（神に祈って）本番環境スキーマを変更してコードをリリースしてしまう可能性があります。
DevOps ワークフローに合わないデータベースでは、パフォーマンスの問題が発生したときに DBA が頭を悩ませることになる、と Redgate データベース DevOps 製品マネージャーの Stephanie Herr 氏は警告しています。
旧来型のDBAは、DevOpsの中でも運用寄りの立場にあります。データに手違いが生じた場合の影響が甚大であるため、彼らは極めてリスク回避的でセキュリティ意識が高いです。彼らは新しいものを信頼するためには十分な理由が必要です。そして、開発者がデータベースを破壊した実績があるため、開発者を信用しない傾向があります。
「本番環境でパフォーマンスの問題が発生すると、DBAに呼び出しがかかるケースが依然として見られます」と彼女は言います。誰がどのような変更を行ったかを明確に把握できなければ、原因分析は困難です。「本番環境のDBAは、たとえ前回のデプロイメントで変更を加えたコードを書いていなかったり、変更に気づいていなかったりする場合でも、その問題に対処する必要があります。」プライバシーとセキュリティも軽視すべきではありません。開発やテストのために本番環境のコピーを取得したいという誘惑に駆られます。
DevOpsコンサルティング会社DLM Consultantsのディレクター、アレックス・イェーツ氏は、ハッカーが現在、開発者と開発システムを積極的に狙っていることを懸念している。
「ハッカーは何年も前から本番サーバーへの攻撃をやめました。開発者への攻撃がはるかに容易になったからです」と彼は言う。「ハッカーがアクセスできるものなら何でも、今やハッカーもアクセスできるのです」。適切な開発者にフィッシングメールを送ったり、デフォルトのパスワードを使って開発システムにアクセスしたりすれば、本番環境のデータはもう終わりだ。
データベースが頻繁に見落とされる理由は何でしょうか? 技術的な問題と文化的な問題です。
文化的な面では、データベースは DBA の管轄であり、ご存知のとおり、開発者は火星から来ており、DBA は金星から来ています。
イェーツ氏は次のように述べています。「旧来のDBAは、DevOpsの中でも運用寄りの立場にあります。データに手違いが生じた場合の影響が甚大であるため、彼らは極めてリスク回避的でセキュリティ意識が高いのです。こうした人々が新しいものを信頼するには、十分な理由が必要です。そして、開発者がデータベースを破壊した実績があるため、彼らは開発者を信用しない傾向があります。」
技術面では、データベースは従来、サーバーを家畜のように扱い、必要に応じてサーバーを死なせて交換するという典型的な DevOps シナリオにはあまり適合していませんでした。
「永続的なデータストアの話になるまでは、すべて非常に良いことです」とイェーツ氏は指摘する。「データを失ってしまうので、既存のシステムを停止して別のシステムを導入することはできません。結果として、システムの健全性をペットのように気遣う人が必要になるか、トランザクションデータを家畜のように確実に扱うための新しい賢い方法を考え出す必要があるのです。」
これらは両方とも同時に取り組むことができます。
開発者は常に技術的負債を返済する。ああ、すべての金額を返済するが、それ以上は決して返済しない。
続きを読む
ヘア氏は、開発の意思決定に早い段階でDBAを関与させることを勧めています。「開発者がデータ操作を必要とする大きな機能変更を行う場合、DBAに連絡して支援を求められると非常に助かります」と彼女は言います。DBAはこれに抵抗するかもしれません。彼らは非常に多忙な人々であり、ますます複雑化する環境で増大するデータ量を管理しなければならないという重責を担っています。このような重責を担っているDBAは、余計な仕事を求めてはいません。
リーブス氏は、開発部門との連携をDBAの職務内容の一部にすることを提案しています。「製品チームにDBAを配置する必要があります。少なくとも、複数の製品チームをサポートできる人材が必要です」と彼は言います。
Herr氏によると、自動化はDevOpsの車輪に油を差すようなものであり、DBAの負担を軽減するのにも役立つとのことです。スキーマ、関数、ストアドプロシージャ、セキュリティへの重要な影響を強調するDBA向けのスクリプトやフラグが役立つかもしれません。
重要な変更をフラグ付けすることで、潜在的なギャップを埋めることができます。ハー氏自身も実世界でそのような状況に遭遇したことがあります。「数千行に及ぶスクリプトを作成していたのですが、本番環境のDBAがそれを目にするのは、デプロイメント作業に取り掛かる時だけでした」と彼女は言います。「彼らはざっと目を通す程度でしたが、私を信頼してくれていました。」
スクリプトの使用は、DevOps チームがデータベースを環境に導入するときに行う必要があるもう 1 つの決定を浮き彫りにします。DevOps チームは、データベースの変更を処理するために移行スクリプトを使用する必要があるでしょうか?
データベースをDevOpsプロセスに組み込むプロセスは、ソフトウェアのソースコードに使用するのと同じような管理メカニズムを導入することから始まります。「目標は、ソースコード全体を徹底的に管理することです」とYates氏は言います。「システムを再デプロイするときは、ソースコード管理からシステム全体を再デプロイする必要があります。システムにデータベースが含まれている場合は、デプロイメントにデータベースを含める必要があります。そうでなければ、うまく動作しません。」
データベースのソース管理における従来のアプローチは、データベースに変更を加える移行スクリプトを作成することです。コミットされた移行スクリプトを一つずつ最初から実行すると、データベーススキーマの最新バージョンが再現されてしまいます。
しかし、複数の開発者がアプリケーションのコードに取り組み、データベースに変更を加え、それぞれがスクリプトを作成すると、問題が発生します。これにより、バージョン管理システムでマージ競合が発生する可能性があります。どの移行スクリプトが適切でしょうか？どれを最初に実行すべきでしょうか？
Yates氏によると、各スクリプトの個々の行を調べて何が起こっているかを確認し、フランケンスクリプトを手作業でつなぎ合わせる必要があるかもしれないとのことです。チームの規模が大きく、コードのチェックインが統制されていないほど、この問題はより厄介になります。代替案として、モデル（状態とも呼ばれます）ベースのアプローチがあります。これは、データ構造のスナップショットを保存し、データベーススキーマのあるべき姿を記述します。データベースをそのように見せるためのアップグレードスクリプトを生成する必要はありますが、これを処理するための自動化ツールがあります。
生産性の低下：Slack は 99 個あるが、仕事はまだ終わっていない
続きを読む
「90%の確率で、作業がかなり楽になります」と彼は言う。「ソース管理の世界では、システムをどのように見せたいかを宣言的に表現できます。問題は、簡単には解決できない変更があった場合です。」
ソフトウェアが十分な情報を持っていないために、スクリプトを適切に生成できない場合があります。リレーショナルテーブル内の氏名列を姓と名の2つの列に分割した場合、ソフトウェアは氏名列を削除し、後続の2つの列を作成する可能性があり、その過程でデータが失われます。データを失うことなく変更をスクリプト化するには、人間による処理が必要です。
データベースをソース管理された継続的インテグレーションの世界に統合するためにどのようなアプローチを選択するかは、チームとテクノロジーによって異なります。多数のストアドプロシージャと大規模な開発チームを抱える大規模で複雑なデータベース環境では、状態ベースのデータベース配信が適しています。逆に、ブランチマージの競合を回避できる、規律の整った開発チームを抱えるシンプルなデータベース環境では、移行が容易です。
2つのアプローチの長所を組み合わせることができるツールやテクニックも存在します。例えば、Visual Studio SSDTでは、配置前と配置後のスクリプトを実行できます。
DevOpsと継続的なライフサイクルを成功させるには、データベースと組織のDBAを考慮する必要があります。つまり、DevOpsサイクルの他のメンバーと同様にDBAとも話し合い、データベースの変更プロセスがバージョン管理ワークフローにどのように適合するかを理解する必要があります。
これを行わなかったり、遅すぎたりすると、このデータベースが壮大なアジャイル計画の障害となる可能性があります。®
Continuous Lifecycle London 2018イベントでDevOpsについて取り上げます。詳細はこちらをご覧ください。
