データベース自動化を開始する方法

データベースの自動化は、複雑で時間のかかるタスクをシンプルかつ高速にするのに役立ちます。自動化のために最も一般的かつ簡単に特定されるタスクは、時間がかかるが反復的なタスクです。これらはしばしば生産性を消費し、これらのタスクに取り組む人々に支払う必要があるため、会社の財務に影響を与える可能性があります。ただし、時間と労力が不必要に消費されるプロセスを仮想自動化に変換できるため、退屈で疲れ果てた作業を回避できます。

データベースの自動化は、データベース管理者とサーバー管理者の一般的な慣習であり、これらを合わせて現在DevOpsとして知られています。 DevOpsは、DBAとサーバー管理タスクの組み合わせも指します。昔ながらの方法では、従来の一般的な自動化タスクは一連のSQLステートメントまたは.sqlファイルとして記述され、スクリプトを介してサーバーを展開およびプロビジョニングし、暗号化/復号化を設定し、自動化が想定される環境のセキュリティを活用します。走る。ここで、自動化は人をスクリプトに置き換える会社の例ではありません。物事をスピードアップし、より少ないエラーでより速くタスクを完了するためのアシスタントとして存在します。自動化は、DBAがタスクを実行する方法や、会社全体または組織全体に提供できる価値に取って代わることはできません。

Puppet、Chef、Ansible、SaltStack、TerraformなどのInfrastructure as Code（IaC）向けの高度なツールは、バックアップと復元、フェイルオーバー、展開など、簡単に複製できるタスクをDBAが完了するのに役立ちます。新しいクラスター、セキュリティ設定の調整、OSカーネルとデータベースのパフォーマンスの調整など。自動化の助けを借りて、多くのDBAは、従来のアプローチを使用するよりも簡単にするこれらのIaCツールを利用するために、データドメイン固有のタスクに焦点を当てることから、コーディング方法もカバーするようにスキルを向上またはシフトしました。現在、会社のユーザーアカウント、ログの管理、インスタンスのデプロイ、サーバーの管理など、クラウド内のアセットの管理を容易にするツールもあります。ビッグ3のクラウドプロバイダーのクラウド向けツールには、AWS CloudFormation、Azure Resource Manager、Google Cloud Deployment Managerが含まれ、DBAまたはDevOpsが自動化の力を活用して処理を高速化できるようにします。これは、組織や会社の幹部だけでなく、あなたのサービスに依存している顧客にも感銘を与えます。

何を自動化する必要がありますか？

前述のように、データベースの自動化はDBA、サーバー管理者、さらにはDevOpsにとって目新しいものではありません。自動化するかどうかを躊躇したり疑問視したりする理由はありません。先に述べたように、自動化のために簡単に特定できる一般的なケースは、本質的に反復的なタスクです。

以下では、DBAの観点から公理的なものを列挙します。

• サーバーのプロビジョニング（例：vagrantの使用、dockerの開始、Kubernetesの開始などのVMインスタンスの開始プラットフォーム）およびSSHアクセスのセットアップまたはVPNアクセスのセットアップ

• 新しいデータベースクラスターの導入

  • データベースプロバイダーの種類、セットアップの種類（プライマリ/スタンバイ、マスターマスターレプリケーション、同期）を特定しますレプリケーション）

• 既存のデータベースクラスターをインポートする

• 既存のデータベースを現在のデータベースクラスターにデプロイ/インポートする

• 自動フェイルオーバーまたはスイッチオーバー

• ノードまたはクラスターの自動回復

• レプリカ/スレーブの昇格またはマスターの降格

• ロードバランサー（ProxySQL、HaProxy、pgpool、pgbouncer、MaxScale、Keepalivedなど）の導入

• バックアップと復元

• データベース監視環境をセットアップします（たとえば、Prometheusなどのエージェントベースの監視を展開します）

• セキュリティ調整を有効にする

• 環境のタイプに応じて自動最適化と調整を実行します

• 他のサードパーティ統合へのアラートシステムを有効にする

• アラートまたはアラームと通知を生成する

• グラフなどのレポートを生成する

• クエリ分析のためにクエリログ（遅いログ）を処理する

• クエリ分析を生成

• データベースのアーカイブまたはクリーンアップ

もちろん、自動化できるケースはたくさんありますが、これには最も一般的なタスクがリストされており、それらを自動化することは間違いありません。これらは本質的に反復的なタイプのタスクであり、特に時間の制約のために迅速に実行する必要がある場合、大部分はエラーが発生しやすくなります。

自動化してはいけないことは何ですか？

これらの領域は、DBAまたはSysAdminsがほとんどの作業を行う場所です。自動化できないものに関しては、自動化はDBAのスキルセットとインテリジェンスに取って代わることはできません。

DBAは、次のことを深く理解している必要があることを理解しています。使用しているデータベースと展開されるデータベース。処理および保存されているデータ。そして、それらが処理されている方法が安全であるかどうか、またはそれが会社のセキュリティ基準に準拠しているかどうか。 DBAもレビューし、ほとんどの場合、自動化アーキテクトと同様にDevOpsと見なされます。彼らは何をしなければならないか、何をしないかを指示します。自動化してはならない一般的なものは次のとおりです。

• スケジュールされたバックアップの設定。スケジュールされたバックアップはもちろん自動化されており、それに応じて実行する必要がありますが、必要なスケジュールされた日付または期間は、サーバーが実行する低ピーク時間に基づいている必要があります。たとえば、クラスターが日中にビジー状態の場合、バックアップを取ることはできません。提供しているアプリケーションの種類や地理的な場所によっては、サーバーが夜間にまだビジー状態である場合もよくあります。

• 自動フェイルオーバーは、新しいマスターの昇格に失敗しました。これは最も重要なケースの1つであり、よく理解する必要があります。フェイルオーバー用に設計された自動スクリプトがある場合は、フェイルオーバーが失敗した場合に強制的にフェイルオーバーを実行するように設計しないでください。主な問題が何であるかわからない場合があります。障害が発生した場合は、次のようなトランザクションが発生する可能性があります。何よりも先に回復する必要があります。たとえば、失敗したマスターに保存された金融トランザクションであり、強制的にスレーブを昇格させたいが、候補スレーブが最新のトランザクションを複製できなかった可能性があります。その場合、データが破損する可能性があります。

• データリカバリ。もちろん、データの破損が発生した場合、またはクラスターがノード/サーバーの自動回復から回復できない場合は、主な原因を調査する必要があります。将来それを回避するために、RCA（根本原因分析）のためにこれを文書化する必要があります。ただし、障害が使用しているデータベースソフトウェアのバグである場合や、VMが破損している可能性がある場合があります。

• データのドリフトまたはデータの不整合。これは、自動化にとって理想的な状況ではありません。オートマトンがデータを一般化またはステレオタイプ化して、「データが破損している場合は自動的に修正しましょう」という概念を適用する方法にしたくない場合。それは間違いなく良い習慣ではありません。決定する前に、最初に理解して調査しなければならないケースがたくさんあります。たとえば、MySQLには、pt-table-checksumと呼ばれるPerconaツールがあり、次にpt-table-syncがあります。これらのツールは、データの不整合を修正する際に相互に相関関係があります。データをよく知っているか、データが広範でないか、データを再生成できない限り、これを自動化することは絶対に避けたいでしょう。

• カーネルチューニングとデータベースチューニング。もちろん、これは私たちが上で述べたことと矛盾していると見ることができます。ただし、メモリ、バッファプール、HugePages、仮想メモリパラメータなど、特定の種類の環境で知られている自動調整可能な変数があります。ただし、変更を適用するかどうかを決定する前に、理解、調査、テスト、ベンチマークが必要なパラメータは間違いなくたくさんあります。

確かに、自動化してはいけないことがたくさんありますが、ここでは触れませんでした。データベースの世界では、提供しているデータとアプリケーションのタイプに応じて、さまざまな状況が発生します。そのことを念頭に置き、自動化できることに注意してください。そうしないと、自動化によって破壊が発生する可能性があります。