ProxySQL と Percona Monitoring and Management で、Amazon RDS for MySQL のデプロイを強化する
ProxySQL と Percona Monitoring and Management で、Amazon RDS for MySQL のデプロイを強化する:
本日は、Percona 社の Michael Benshoof 氏によるゲストブログ投稿です。Benshoof 氏によると、「Percona 社は、3 千人以上の顧客をグローバルに持ち、バイアスのない最善の企業規模サポート、コンサルティング、管理サービスおよびトレーニングを提供し、リスクと運用コストを減らす対策を提供しています。さらにオンプレミスとオープンソース環境でのオープンソースデータベースのためのソフトウェアを使って、ロックインを排除し、機敏性を高め、ビジネスの成長を可能にしています。」
」
クラウドにアプリケーションをデプロイする予定で、データ層には Amazon RDS for MySQL を利用しようと考えている? それはいい選択ですね! それでは、アーキテクチャを最大限に活用するためのベストプラクティスをいくつか見てみましょう。
PMM Query Analytics を使用すると、MySQL と MongoDB のクエリが可能な限り短時間で実行され、データベースのパフォーマンスを最適化することができます。問題が発生した場合は、原因となるクエリを確認し、その詳細なメトリックを取得できます。Metrics Monitor ツールでは、データベースサーバーにとって重要なメトリックの履歴ビューを閲覧できます。時間ベースのグラフは、ダッシュボード上でテーマごと、例えば MySQL や MongoDB に関するものや一般のシステムメトリックなどを見ることができます。
特定のメトリックを拡大して、詳細を表示することができます。
PMM Query Analytics では、インバウンドおよびアウトバウンドのネットワークトラフィック、CPU 使用率、長期間使用可能なメモリなど、モニター中のデータに関する詳細情報を各グラフ上で表示できます。
パフォーマンスの低下は、たいていパフォーマンスの低いクエリが主な原因です。PMM を使えば、これらのクエリはリストの一番上にすばやく表示され、問題となる前でもすぐに識別できます。
詳細は、PMM のドキュメントを参照してください。
また、プライマリインスタンスに対して ProxySQL を使用することもできます。RDS は自動的にパッシブマスターをアクティブにしますが、DNS の伝達には時間がかかることがあり、アプリケーションに障害が発生する可能性があります。自動再試行では、RDS のフェールオーバーが完了するまで再試行し、アプリケーションからプロモーションを完全に隠すよう ProxySQL を設定できます。
最後に、ProxySQL を使用して、読み取りトラフィックのクラスターエンドポイントを定義します。アプリケーションですでに読み取り/書き込みを分割できる場合は、アプリケーションでレプリカエンドポイントを管理する必要はなく、レプリカをクラスタに追加し、すべての読み取りを ProxySQL 経由で送信するだけです。
詳細については、ProxySQL のウェブサイトを参照してください。
複数の ProxySQL インスタンスを設定し、それらを ELB 経由で置くと、最終レベルで冗長性が追加されます。ProxySQL インスタンスに障害が発生した場合、ELB はすべてのトラフィックを正常なインスタンスに自動的にルーティングします。 新しいノードを追加することによって、必要に応じて ProxySQL レイヤーを拡張することもできます。
Michael Benshoof 氏は Percona 社のテクニカルアカウントマネージャーです。Percona 社に入社する前は、ソーシャルネットワーキングに特化した SaaS アプリケーションの開発とメンテナンスを行う会社で、DevOps 開発者として数年勤めていました。アプリケーションの開発とスケーリング、システム管理の他、データベース管理と設計の経験が豊富です。拡張性と柔軟性を持ったソリューションを設計でき、HA システムの知識と経験は誰にも負けません。
本日は、Percona 社の Michael Benshoof 氏によるゲストブログ投稿です。Benshoof 氏によると、「Percona 社は、3 千人以上の顧客をグローバルに持ち、バイアスのない最善の企業規模サポート、コンサルティング、管理サービスおよびトレーニングを提供し、リスクと運用コストを減らす対策を提供しています。さらにオンプレミスとオープンソース環境でのオープンソースデータベースのためのソフトウェアを使って、ロックインを排除し、機敏性を高め、ビジネスの成長を可能にしています。」
」
クラウドにアプリケーションをデプロイする予定で、データ層には Amazon RDS for MySQL を利用しようと考えている? それはいい選択ですね! それでは、アーキテクチャを最大限に活用するためのベストプラクティスをいくつか見てみましょう。
Amazon RDS for MySQL とは
RDS for MySQL は、アマゾン ウェブ サービス (AWS) スタック内でサービスを行う管理データベース (DBaaS) です。RDS for MySQL では、次のような細かな操作作業の多くを処理します。- バックアップ
- ポイントインタイムリカバリ
- マイナーバージョンの自動アップグレード
- 新しいレプリカの追加
- 自動フェイルオーバー (Multi-AZ を実行している場合)
標準的なベストプラクティス
任意のアーキテクチャ (クラウドまたは物理データセンター内にある) を一から設計する場合、不具合への対応を準備しておくことは大変重要です。障害に対する準備が整ったインフラストラクチャの設定は、耐障害性のある環境を設計する上でかなめとなります。そのため、本番でのデプロイ (または高可用性が必要なデプロイ) の場合は、少なくとも以下を実行する必要があります。プライマリインスタンスに、Multi-AZ を指定する
- 次に、DNS を使用して、アプリケーション接続をアクティブなインスタンスにルーティングします。
- パッシブインスタンスは、同期ストレージブロックレベルのレプリケーションを使って同期され、プライマリ障害が発生した場合には昇格されます。
- パッシブインスタンスにトラフィックを送信することはできません。
レプリカが複数のアベイラビリティゾーンに分散していることを確認する
- この方法で、AWS リージョン内で複数の障害が発生した場合の可用性を向上させます。
- リージョン全体を失った場合の冗長性を高めるために、リージョン間のレプリカを追加できます。
- この方法では、地理的負荷分散のオプションも備えることになります。
自動バックアップを有効にする
- レプリカを使用するには、バックアップを有効にする必要があります。
- バックアップは、Multi-AZ モードのパッシブインスタンスから取得されます。
- 復元を実行して定期的にバックアップをテストし、実行可能性を確認してください。
- バックアップの保持期間を長くすることをお勧めします (現在、35 日が最大です)。
アプリケーションリトライロジックを使用する
- アプリケーションは、必要に応じて障害を処理し、ステートメントとトランザクションを再試行できる必要があります。
Percona Monitoring and Management を使ってモニタリングする
- インスタンスのメトリックとクエリトラフィックを把握することは、トラブルシューティングやプランニングにとって重要です。
- PMM は自由に利用できる Amazon Machine Image (AMI) を使って、実行中の RDS インスタンスに簡単に接続できます。
Percona Monitoring and Management
RDS デプロイ強化のための最後のステップは、Percona Monitoring and Management (PMM) インスタンスの設定です。Amazon CloudWatch は、インスタンスからいくつかの未加工メトリックを提供しますが、PMM はさらなる MySQL メトリックを提供できます。PMM は、MySQL および MongoDB サーバーの徹底した時間ベースの分析を実現し、データができる限り効率的に機能するようにします。PMM Query Analytics を使用すると、MySQL と MongoDB のクエリが可能な限り短時間で実行され、データベースのパフォーマンスを最適化することができます。問題が発生した場合は、原因となるクエリを確認し、その詳細なメトリックを取得できます。Metrics Monitor ツールでは、データベースサーバーにとって重要なメトリックの履歴ビューを閲覧できます。時間ベースのグラフは、ダッシュボード上でテーマごと、例えば MySQL や MongoDB に関するものや一般のシステムメトリックなどを見ることができます。
特定のメトリックを拡大して、詳細を表示することができます。
PMM Query Analytics では、インバウンドおよびアウトバウンドのネットワークトラフィック、CPU 使用率、長期間使用可能なメモリなど、モニター中のデータに関する詳細情報を各グラフ上で表示できます。
パフォーマンスの低下は、たいていパフォーマンスの低いクエリが主な原因です。PMM を使えば、これらのクエリはリストの一番上にすばやく表示され、問題となる前でもすぐに識別できます。
詳細は、PMM のドキュメントを参照してください。
拡張アーキテクチャ
前述のベストプラクティスに基づいて、より透明性の高い可用性と可視性を増強しつつ、リソースをより効果的に使用するための機能を追加することができます。追加のコンポーネントには、次のものがあります。- ProxySQL
- Elastic Load Balancing (ELB)
ProxySQL
ProxySQL は、SQL 接続エンドポイント、およびその背後にある RDS インスタンスへのプロキシとして機能する、Layer 7 ロードバランサーです。このツールを使用すると、よりよい利用率での透過的な読み取りと書き込みの分割ができるだけでなく、可用性のためのサーバープールも定義することができます。ビルトインヘルスチェックは、レプリカがいつ停止したかを判断し、他のノードで失敗したクエリを透過的に再試行します (自動コミットまたは読み取りクエリ)。また、プライマリインスタンスに対して ProxySQL を使用することもできます。RDS は自動的にパッシブマスターをアクティブにしますが、DNS の伝達には時間がかかることがあり、アプリケーションに障害が発生する可能性があります。自動再試行では、RDS のフェールオーバーが完了するまで再試行し、アプリケーションからプロモーションを完全に隠すよう ProxySQL を設定できます。
最後に、ProxySQL を使用して、読み取りトラフィックのクラスターエンドポイントを定義します。アプリケーションですでに読み取り/書き込みを分割できる場合は、アプリケーションでレプリカエンドポイントを管理する必要はなく、レプリカをクラスタに追加し、すべての読み取りを ProxySQL 経由で送信するだけです。
詳細については、ProxySQL のウェブサイトを参照してください。
Elastic Load Balancing
前述のように、コンポーネントの障害を考慮して、すべてのアーキテクチャを設計する必要があります。その際に、Elastic Load Balancing (ELB) をスタックに追加することが重要となります。 ProxySQL はバックエンドレベルで負荷分散とノード障害を処理できますが、ELB は ProxySQL に冗長性を提供します。複数の ProxySQL インスタンスを設定し、それらを ELB 経由で置くと、最終レベルで冗長性が追加されます。ProxySQL インスタンスに障害が発生した場合、ELB はすべてのトラフィックを正常なインスタンスに自動的にルーティングします。 新しいノードを追加することによって、必要に応じて ProxySQL レイヤーを拡張することもできます。
まとめ
以上のように、Amazon RDS for MySQL は AWS のデータ層に最適なオプションです。基本的なベストプラクティスに従えば、アプリケーションの可用性を高めることができます。さらにいくつかのレイヤーを追加することで、追加の可用性と可視性が備わり、現行の MySQL デプロイをドロップインで置き換えて、本番対応のソリューションを実現できます。今回のブログ投稿者について
Michael Benshoof 氏は Percona 社のテクニカルアカウントマネージャーです。Percona 社に入社する前は、ソーシャルネットワーキングに特化した SaaS アプリケーションの開発とメンテナンスを行う会社で、DevOps 開発者として数年勤めていました。アプリケーションの開発とスケーリング、システム管理の他、データベース管理と設計の経験が豊富です。拡張性と柔軟性を持ったソリューションを設計でき、HA システムの知識と経験は誰にも負けません。
コメント
コメントを投稿