MySQLはインストールと使用が簡単で、開発者やシステム管理者に常に人気があります。一方、ビジネスクリティカルなエンタープライズワークロードに本番環境に対応したMySQL環境をデプロイすることは、別の話です。これは少し難しい場合があり、データベースに関する深い知識が必要です。このブログ投稿では、MySQLのデプロイメントが本番環境に対応していると見なす前に実行する必要のあるいくつかの手順について説明します。
高可用性
何時間ものダウンタイムを受け入れることができる幸運な人に属している場合は、ここで読むのをやめて次の段落にスキップできます。ビジネスクリティカルなシステムの99.999％の場合、それは受け入れられません。したがって、本番環境に対応した展開には、高可用性対策を含める必要があります。データベースインスタンスの自動フェイルオーバー、およびMySQLのトポロジと状態の変更を検出し、それに応じてトラフィックをルーティングするプロキシレイヤーが主な要件になります。 MHA、MRM、ClusterControlなど、このような環境を構築するために使用できるツールは多数あります。
プロキシレイヤー
マスター障害の検出、自動フェイルオーバーおよびリカバリ-これらは、本番環境に対応したインフラストラクチャを構築する際に重要です。しかし、それだけでは十分ではありません。フェイルオーバーによってトリガーされるトポロジー変更に適応する必要があるアプリケーションがまだあります。もちろん、インスタンスの障害を認識するようにアプリケーションをコーディングすることは可能です。ただし、これはトポロジの変更を処理するための面倒で柔軟性のない方法です。これがデータベースプロキシです。これは、アプリケーションとデータベースの中間層です。プロキシは、データベース層の複雑さをアプリケーションから隠すことができます。アプリケーションが行うのはプロキシに接続することだけで、残りはプロキシが処理します。プロキシはクエリをデータベースインスタンスにルーティングし、トポロジの変更を処理し、必要に応じて再ルーティングします。プロキシを使用して読み取りと書き込みの分割を実装することもでき、アプリケーションをもう1つの複雑なケースから解放します。これは別の課題を生み出します-どのプロキシを使用しますか？それを構成する方法は？それを監視する方法は？ SPOFにならないように高可用性を実現するにはどうすればよいですか？
ClusterControlはここで支援できます。さまざまなプロキシをデプロイしてプロキシレイヤーを形成するために使用できます：ProxySQL、HAProxy、MaxScale。プロキシを事前設定して、トラフィックを正しく処理できるようにします。また、アプリケーションのプロキシ設定をカスタマイズする必要がある場合は、構成の変更を簡単に実装できます。読み取り/書き込み分割は、ClusterControlがサポートする任意のプロキシを使用して構成できます。 ClusterControlはプロキシも監視し、障害が発生した場合にプロキシを回復します。自動リカバリでは不十分な場合があるため、プロキシレイヤーが単一障害点になる可能性があります。これに対処するために、ClusterControlはKeepalivedをデプロイし、フェイルオーバーを自動化するように仮想IPを構成できます。
バックアップ
高可用性を実装する必要がない場合でも、おそらくデータに注意を払う必要があります。バックアップは、ほぼすべての本番データベースに必須です。バックアップ以外の何物も、偶発的なDROPTABLEまたはDROPSCHEMAからあなたを救うことはできません（まあ、おそらく遅延レプリケーションスレーブですが、一定期間だけです）。 MySQLは、バックアップを取る複数の方法を提供します-mysqldump、xtrabackup、さまざまなタイプのスナップショット（特定のハードウェアまたはクラウドプロバイダーでのみ利用可能なものもあります）。正しいバックアップ戦略を設計し、使用するツールを決定してから、プロセス全体をスクリプト化して正しく実行することは簡単ではありません。ロケット科学でもないので、慎重な計画とテストが必要です。バックアップが作成されると、完了しません。バックアップを復元でき、データがゴミではないことを確認しますか？バックアップの検証には時間がかかり、おそらくToDoリストで最もエキサイティングなことではありません。しかし、それでも重要であり、定期的に行う必要があります。
ClusterControlには、広範なバックアップおよび復元機能があります。論理バックアップにはmysqldumpを、物理バックアップにはPercona Xtrabackupをサポートしています。これらのツールは、クラウドまたはオンプレミスのほぼすべての環境で使用できます。オンライン方式で、増分バックアップまたは完全バックアップの論理バックアップと物理バックアップを組み合わせたバックアップ戦略を構築することができます。
リカバリとは別に、バックアップを検証するオプションもあります。たとえば、バックアッププロセスが正常に機能するかどうかを検証するために、別のホストにバックアップを復元します。
バックアップを定期的に監視したい場合（そしておそらくこれを実行したい場合）、ClusterControlには運用レポートを生成する機能があります。バックアップレポートは、実行されたバックアップを追跡するのに役立ち、バックアップの作成中に問題が発生したかどうかを通知します。
データベース管理に関するSevereninesDevOpsガイドオープンソースデータベースを自動化および管理するために知っておくべきことを学ぶ無料でダウンロード監視と傾向分析
サービスを適切に監視しない限り、本番環境に対応できるデプロイメントはありません。一部のサービスが利用できなくなった場合にアラートが送信されるようにして、アクションを実行したり、調査したり、リカバリ手順を開始したりできるようにする必要があります。もちろん、トレンドソリューションも必要です。インフラストラクチャの状態を評価するため、またはサービスの状態を事後またはリアルタイムで監視するための調査のために監視データを用意することがどれほど重要であるかを十分に強調することはできません。指標の重要性は同じではありません。特定のデータベース製品に精通していない場合、収集して監視する最も重要な指標がどれであるかわからない可能性があります。もちろん、すべてを収集できる可能性はありますが、データの確認に関しては、ホストごとに数百の指標を調べることはほとんど不可能です。どの指標に焦点を当てるべきかを知る必要があります。
オープンソースの世界には、さまざまなデータベースからメトリックを監視および収集するように設計されたツールがたくさんあります。それらのほとんどは、全体的な監視インフラストラクチャ、chatopsプラットフォーム、またはオンコールサポートツール（PagerDutyなど）と統合する必要があります。また、ストレージ（ある種の時系列データベース）、プレゼンテーション層、データ収集ツールなど、複数のコンポーネントをインストールして統合する必要がある場合もあります。
ClusterControlは、最も重要な詳細を表示するリアルタイムの監視、傾向分析、およびダッシュボードを備えた単一の製品であるため、少し異なるアプローチです。データベースアドバイザーは、単純な構成のアドバイス、しきい値に関する警告、または予測のためのより複雑なルールなど、一般的に包括的な推奨事項を作成します。
スケールアップ機能
データベースはサイズが大きくなる傾向があり、トランザクション量やユーザー数の点で大きくなる可能性はほとんどありません。スケールアウトまたはスケールアップする機能は、本番環境にとって重要な場合があります。製品ライフサイクルの開始時にハードウェア要件を見積もるのに優れた仕事をしていても、製品が成功している限り、おそらく成長フェーズを処理する必要があります（しかし、それは私たち全員が計画していることです） ？）。入ってくる負荷に対処するために、インフラストラクチャを簡単にスケールアップする手段が必要です。ウェブサーバーのようなステートレスサービスの場合、これはかなり簡単です。バージョン管理ツールの最新の本番イメージまたはコードを使用して、より多くのインスタンスをプロビジョニングする必要があります。データベースのようなステートフルなサービスの場合、それはよりトリッキーです。現在の本番データを使用して新しいインスタンスをプロビジョニングするか、現在のインスタンスと新しいインスタンスの間にレプリケーションまたは何らかの形式のクラスタリングを設定する必要があります。これは複雑なプロセスになる可能性があり、それを正しく行うには、選択したクラスタリングまたはレプリケーションモデルについてより深い知識を持っている必要があります。
ClusterControlは、その名前が示すように、クラスター化または複製されたデータベース設定を構築するための広範なサポートを提供します。使用される方法は、何千もの展開を通じてバトルテストされています。コマンドラインインターフェイス（CLI）が付属しているため、構成管理システムと簡単に統合できます。ただし、データベースのプールを頻繁に変更したくない場合があることに注意してください。新しいインスタンスのプロビジョニングには時間がかかり、既存のデータベースにオーバーヘッドが追加されます。したがって、クラスターが過負荷になる前に新しいインスタンスを起動する時間ができるように、「オーバープロビジョニング」側に少しとどまることができます。
全体として、環境を本番環境で使用できるようにするために、最初の展開後に実行する必要のあるいくつかの手順があります。適切なツールがあれば、そこにたどり着くのははるかに簡単です。