Skeemaを使用したスキーマ管理

公開: 2019-04-26

注：この投稿は、SendGridのエンジニアリングチームからのものです。 このような技術エンジニアリングの投稿については、技術ブログロールをご覧ください。

データベーススキーマの管理は、本番プロセスで誰でも「ライブで実行」できるワイルドウェストから、油を塗った1人の個人だけが本番データベースにアクセスできるウォーターフォール風のマルチステップ、マルチチームレビュープロセスにまで及びます。

リレーショナルデータベースに含まれるデータが企業にとってより価値のあるものになり、データベースの可用性がビジネスにとってより重要になるにつれて、潜在的な破壊的なスキーマ変更に対する障壁が現れます。

早い段階で、データベース管理者（DBA）は、データベースを悪いことが起こらないように保護するために、データベースのゲートキーパーになりました。しかし、開発者とそのアプリケーションのデータベースの間に古いDBAを配置すると、アプリケーションの開発ライフサイクルが大幅に遅くなり、開発と運用のサイロが作成され、チーム間に摩擦が生じる可能性があります。

今日のマイクロサービス開発運用指向の世界では、開発者はデータベーススキーマの変更を自分で管理できる必要があります。これは、開発者がデータであり、アプリケーションのパフォーマンスと稼働時間に最終的な責任があるためです。 DBAと運用チームは、開発チームがデータベースの所有者になるのに役立つ適切なツールとアドバイスを提供する必要があります。

スキーマの管理方法

現在のスキーマ管理プロセスでは、単一のGitリポジトリを使用して、すべてのデータベースクラスターの初期スキーマを保存し、個々のテーブルの変更/作成および削除が適用されると、そのスキーマに対する後続のすべての変更が含まれます。

開発者はスキーマをローカルで変更し、alter / create / dropステートメントを生成して、それをプルリクエストとして統合ブランチに追加します。
データ運用チームのJiraチケットのセットは、スキーマの変更を確認して、テスト/ステージングおよび本番環境に適用するために作成されます。
データ運用チームのメンバーは、要求された変更を確認し、その変更をテスト/ステージング環境に適用して、PRを統合ブランチにマージします。
要求している開発者は、テスト/ステージング環境で変更をテストし、変更を本番環境にプッシュすることを承認します。
最後に、Data Operationsは統合ブランチをマスターにマージし、スキーマの変更を本番環境に適用します。

私たちのデータベースに保存されているデータの価値と、それらのデータベースを常に正常に稼働させたいという願望を考慮して、私たちは自分自身を自分自身から守るために、このビザンチンの一連のイベントに落ち着きました。

データベースを保護することは1つのことですが、このプロセスでは、信頼性が高く効率的な方法でスキーマを変更するためのいくつかのハードルが発生します。

スキーマ変更のレビューと変更は週に2回行われ、複数のチームがすべて同じGitリポジトリ内の異なるデータベースで作業し、全員がデータ運用チームの誰かに依存してさまざまな環境をレビューおよび変更するため、簡単に脱線する可能性があります。
すべてのリレーショナルデータベーススキーマに対して1つのリポジトリがあると、リリースプロセスが困難になる可能性があります。本番環境にプッシュする準備ができていないが、追加のテストを待機しているステージングにある他のスキーマ変更がある場合、本番環境の準備ができている1つのスキーマへの変更は本番環境に移行できません。
小さなチームであるデータ運用チームは、どの変更をいつ本番環境に移行できるか、いつ移行できないかを管理しようとするボトルネックになります。スケジュールの競合と人員の空き状況により、現在のアプリケーションに対する新機能や修正のリリースが大幅に遅くなる可能性があります。
プルリクエストとJiraチケットのコメントを使用して、これらの変更を本番システムに手動で適用しています。コピーペーストがひどくうまくいかないことがあります。

Skeema（および数人のヘルパー）を入力してください

これらのプロセスのハードルを取り除き、スキーマの変更で人為的エラーが発生しにくくし、開発者が独自のアプリケーションのスキーマを管理できるようにし、開発速度を上げる可能性があるため、データ運用チームは、データベーススキーマ。

既存のツールであるGit、Buildkite CI、およびpt-online-schema-changeを使用して、ローカル開発から本番環境へのスキーマ変更の適用を自動化し、さらに1つSkeemaを追加しました。

アイデアは、モノリシックDBスキーマリポジトリをデータベースクラスタごとに1つずつ、個々のスキーマリポジトリに分割し、開発者が使い慣れた環境で独自のスキーマ変更を行えるようにすることです。また、開発者が大規模で複雑な、または破壊的な可能性のあるスキーマ変更を行うための追加の支援を探すのに役立つ、適切なガードレールを設置する必要があります。

Skeemaは、SQLを使用して宣言型の方法でMySQLスキーマを管理するCLIツールです。

データベース内の各テーブルのデータ定義言語（DDL）を生成し、Gitを介して追跡リポジトリと統合するためにDDLをローカルファイルシステムにエクスポートできます。 Skeemaは、Gitリポジトリ内のSQLファイルをライブのMySQLデータベースと比較し、それらの違いをDDLステートメントとして出力できます。

また、Perconaのpt-online-schema-changeツールを使用し、必要なpt-online-schema-changeコマンドをフォーマットして、実行中のMySQLデータベースのスキーマをGitリポジトリで定義されたスキーマと一致させるように構成することもできます。

Skeemaは、ローカル、テスト、本番環境など、それぞれ異なる構成でスキーマを管理することもできます。そして最後に、プルリクエストベースのワークフローに簡単に適合させることができます。

個々のMySQLデータベーススキーマリポジトリを作成すると、現在のモノリシックdb-schema Gitリポジトリが分解され、別々のチームの開発者が共有リポジトリ（db-schema）ではなく独自のリポジトリでアプリケーションのMySQLスキーマを管理できるようになります。

データベーススキーマごとに個別のリポジトリを用意することで、アプリケーション開発チームの自律性を高めることができます。これにより、すべてのスキーマ変更を厳密なスケジュールに調整する必要がなくなり、アプリケーションチームが望むように変更を本番環境に移動できます。

このプロセスを自動化するための重要なコンポーネントは、BuildkiteのCIパイプラインです。次のようなパイプラインを作成しました。

SQL構文エラーをチェックします
データベースのスキーマの現在のマスターブランチを使用してテストMySQLサーバーを作成し、プルリクエスト（PR）の変更の適用をテストします
違いを確認し、PRの変更をテスト中のMySQL環境に適用します
違いを確認し、PRの変更をステージング環境に適用し、本番環境からいくつかのテーブル統計を出力します

本番出力の統計は、ディスク上のテーブルサイズと推定行数です。これらの統計は、スキーマの変更によって何らかのレベルのサービスの中断が発生し、特別な処理が必要になる可能性があるかどうかを判断するのに役立ちます。 PRがマスターにマージされると、buildkiteパイプラインはマスターブランチと本番環境で実行されているものとの違いをチェックします。

違いがPRから予想される変更である場合、開発者はこの最後のステップのブロックを解除でき、Skeemaは変更を本番MySQLデータベースクラスターに適用します。これらの各ステップはブロックステップであり、次のステップに進む前に、要求された変更を担当するエンジニアリングチームによる承認が必要です。

ガードレールに関する限り、デフォルトで本番環境で破壊的なスキーマ変更を許可しないようにSkeemaを構成しました。

テスト環境とステージング環境では、破壊的な変更が許可されています。

また、pt-online-schema-changeを使用してスキーマを変更するようにSkeemaを構成しました。これは、DataOpsチームが精通しており、SendGridで長年使用されているのと同じスキーマ変更ツールです。 pt-online-schema-changeの合理的なオプションのセットを開発して、レプリケーションが遅れたり、データベース内のアクティブなスレッドが過剰になった場合に変更をロールバックします。

Skeemaをこのように構成すると、DataOpsチームメンバーによるアプリケーションの手動手順とpt-online-schema-changeコマンドの手動コーディングによる潜在的なエラーが排除されます。

プログラムによるガードレールを追加することで、個々のチームは、MySQLデータベーススキーマの管理と、それらの変更を比較的安全に実稼働前および実稼働環境に適用する責任を負うことができます。ガードレールにぶつかると、スキーマの変更は失敗し、ロールバックされます。スキーマ変更の失敗の理由は、追加のレビューのためにビルドログに出力されます。

開発者がラップトップでのローカルテストから本番環境への変更を管理できるようにすることで、開発者の自律性と、アプリケーションをサポートしているデータベースの所有権が大幅に強化されます。 Skeemaの自動化とMySQLデータベース管理プロセスへの統合は、一般的なスキーマ変更管理タスクの約90％を簡単にカバーします。

ほとんどのスキーマの変更は、列の追加、列挙型フィールドの変更、デフォルトの変更、およびインデックスの追加のためのものです。スキーマ変更の残りの10％は、大きなテーブル、非常にアクティブなデータベース、またはパーティション化されたテーブルの特殊なケースを扱います。この投稿の時点では、Skeemaはパーティション化されたテーブルへのスキーマ変更をまだ処理していませんが、頻繁に追加が要求されると聞いており、Skeemaの開発者はその機能の実装について積極的に支援を求めています。

Git、pt-online-schema-change、Skeema、およびBuildkite CIパイプラインを組み合わせると、MySQLデータベーススキーマの変更に信頼性が高く、反復可能なプログラムプロセスがもたらされます。これにより、開発者はデータベースのスキーマを安全に管理し、機能と修正を本番環境に展開する速度を制御できます。

Skeemaおよびpt-online-schema変更の構成ファイルに適切なガードレールを含めることで、スキーマ変更を実装する開発者に信頼性の尺度を提供し、それらのガードレールがヒットした場合にスキーマ変更を進めるための可能な方法に関する貴重なフィードバックを提供します。

データ運用チームは、このプロセスを適用できない残りの10％のケースを支援するために引き続き利用可能であり、将来このプロセスを強化するための追加のツールに取り組んでいます。