世界で最も人気のあるオープンソースデータベースを使い始めようとしていて、MySQLホスティングをどのように設定すべきか疑問に思っていますか？ MySQLがAzureCloudで非常に優れたパフォーマンスを発揮する場合、多くの場合、デフォルトでAmazonRDSが使用されます。 MicrosoftAzureはマネージドソリューションであるAzureDatabaseを提供しますが、このソリューションには、MySQLデプロイメントを移行する前に知っておく必要のあるいくつかの主要な制限があります。この投稿では、クラウドデータベースのパフォーマンスを最適化するために使用するマネージドソリューション、インスタンスタイプ、高可用性レプリケーション、バックアップ、ディスクタイプなど、AzureでMySQLをホストするための最良の方法の概要を説明します。
MySQLDBaaSと自己管理型MySQL
自己管理とMySQL Database-as-a-Service（DBaaS）ソリューションを比較検討する際に最初に考慮すべきことは、利用可能な内部リソースです。これを読んでいると、本番環境の展開の維持に関連する運用タスクの規模をすでに知っている可能性がありますが、簡単に要約すると、プロビジョニング、プロビジョニング解除、マスタースレーブ構成、バックアップ、スケーリング、アップグレード、ログローテーション、OSパッチがあります。 、およびいくつか例を挙げると監視します。
内部のMySQLエキスパート、またはアプリケーションのサイズに応じてDBAのチームは、組織でこれらを確実に処理できますが、問題は、チームの取り組みをどこに集中させるかということになります。 。多くの人がMySQLDBaaSに移行して、これらの時間のかかるタスクを自動化し、アプリケーションデータベースの開発と最適化により集中できるようにすることを決定します。良い例は、遅いクエリ分析です。ほとんどすべてのDBaaSは、問題のあるクエリを特定するのに役立つMySQL Slow Query Analyzerツールを提供していますが、このタスクには、アプリケーションのパフォーマンスに影響を与えるクエリを最適化する方法を決定するための人間のスキルと直感が必要です。
あなたが新興企業であろうとフォーチュン500企業であろうと、多くの組織がDBaaSを活用してDBAの時間を最適化することを選択し、同じ業種と規模であることに気付くでしょう。また、内部の自己管理に固執することを選択します。多くの企業にとって、決定は主にカスタマイズと制御に帰着します。これが、Azure Database、またはAWSのライバルであるAmazon RDSをデフォルトにしないように注意する理由です。これは、MySQLスーパーユーザーアクセスやSSHアクセスをマシンに保持できないためです。さらに、使用できるインスタンスタイプ、RAM、ディスクサイズ、IOPSなど、展開設定をカスタマイズする機能は非常に制限されています。以下で使用するのに最適なインスタンスタイプとディスクについて詳しく学びます。このMySQLプロバイダーの比較をチェックして、上位4つのマネージドMySQLソリューション、ScaleGrid、Compose、Azure Database、およびAmazonRDSの利点と制限を確認できます。
高可用性の導入
本番環境にデプロイする場合は、常にMySQLをマスタースレーブデプロイメントとしてセットアップする必要があります。スタンドアロン展開はレプリケーションのない単一ノードであり、実際には開発環境またはテスト環境でのみ使用する必要があります。マスタースレーブ展開では、高可用性を構成できるため、ノードの1つがダウンした場合でも、ダウンタイムなしでスレーブにフェイルオーバーできます。これは通常、3ノードのマスタースレーブスレーブまたは2+1ノードのマスタースレーブクォーラムとして設定されます。クォーラムを使用する利点は、低コストの代替手段であるということですが、欠点は、データを保持するノードが2つしかないことです。これは、他のノードがクォーラムノードとして機能し、最適なフェイルオーバーコースを決定するためです。アプリケーションがスレーブから読み取ることができる場合は、読み取りスケーリングを実行して、遅延を最小限に抑えてクラスターボリュームから同じデータを返すようにする必要があります。
AzureCloudでMySQLをホストするための最良の方法クリックしてツイート
MySQLマスタースレーブ構成を使用する場合は、半同期レプリケーションを設定して、データの冗長性を備えたデータの整合性を向上させることをお勧めします。これにより、コミットが正常に返されると、データはマスターとスレーブの両方に存在するため、データセンターがダウンした場合でも、MySQLマスターはデータを失うことなくスレーブにフェイルオーバーできます。これは、非同期レプリケーションまたは準同期レプリケーションのいずれかで実行できます。詳細については、MySQL高可用性の説明–パートIIブログ投稿を参照してください。
では、AzureでMySQLの高可用性を構成するにはどうすればよいでしょうか。スレーブインスタンスをさまざまなAzureアベイラビリティーゾーン（AZ）に分散する必要があります。そのため、少なくとも3つのAZを持つAzureリージョンを選択し、各インスタンスを異なるAZに配置するようにします。これは、可用性の保証がAZ全体に及ぶためです。したがって、1つのゾーンがダウンしても、アプリケーションデータベースは他の2つのAZを介してオンラインを維持できます。アベイラビリティーゾーンはAzureにとってかなり新しいため、AZを提供していないリージョンで作業している場合は、アベイラビリティーセットを使用するオプションがあります。これらはAZよりもわずかに弱いですが、潜在的な停止から保護するために、さまざまなドメインやラックに展開されていることを確認してください。リージョン間で展開するオプションもありますが、これはより複雑な設定であるため、実装する前に話し合うことをお勧めします。
Azure仮想ネットワーク
データベースをインターネットから保護する最善の方法は、データベースをプライベートサブネットに展開して、データベースが公開されないようにすることです。 Azureでは、MySQLサーバー用に構成できる仮想ネットワーク（VNET）を使用して、これを簡単にセットアップできます。 Azure VNET for MySQLを使用すると、サーバー、インターネット、さらにはオンプレミスのプライベートクラウドネットワーク間で安全な通信をセットアップできます。これらは通常、単一のネットワークを介して通信するように構成されていますが、複数のリージョンを接続する必要がある場合は、仮想ネットワークピアリングを介して通信するために複数のVNETを作成できます。
さらに、IPホワイトリストを処理しなくても、ネットワークセキュリティグループ（NSG）ルールを介してMySQLアクセス制御を管理できます。これは、Azure Database for MySQLでは利用できませんが、VNETとNSGの両方を、AzureでMySQL Bring Your Own Cloud（BYOC）プランを使用して構成できます。このプランでは、独自のクラウドアカウントを介してクラスターをホストできます。
Azureインスタンスタイプ
考慮すべきもう1つの重要な側面は、パブリッククラウドでのMySQLインスタンスのパフォーマンスです。 Azureクラウドは、Es2 v3、Ds2、v2、Ls4など、MySQLホスティングに使用できる複数のインスタンスタイプを提供します。
データベースは大量のRAMを必要とし、最高のパフォーマンスを得るために可能な限り最速のディスク速度を求めているため、メモリに最適化されたインスタンスタイプから始めることをお勧めします。 Es2シリーズは通常、ほとんどのアプリケーションのMySQLワークロードの出発点として適しています。そこから、パフォーマンステストを実行して、より多くのCPUが必要かどうかを確認できます。その場合、バランスの取れたインスタンスタイプまたはCPUを集中的に使用するインスタンスタイプが、Dv3インスタンスタイプなどのMySQLのニーズにより適している可能性があります。パフォーマンステストでは、より多くのI / O（入力/出力）が必要であることが示される場合もあります。ディスクを大量に消費するインスタンスタイプに移行できます。
今後1〜3年間、AzureをMySQLクラウドプロバイダーとして活用し、かなり一貫した展開構成を維持する予定の場合は、リザーブドインスタンスを検討することもできます。これらは基本的にプリペイドインスタンスであり、MySQLホスティングの大幅なコスト削減を実現できます。平均すると、1年間の予約済みインスタンスで約20％から30％節約でき、3年間の予約済みインスタンスで40％から50％節約できます。
Azureディスクタイプ
MySQLの展開にAzureディスクの種類を選択する際に最初に決定する必要があるのは、マネージドディスクとアンマネージドディスクのどちらを使用するかです。アンマネージドディスクは、Azureが提供するレガシーディスクであり、ストレージアカウントをセットアップし、ディスクをストレージアカウントにマップし、そのストレージアカウントのIOPSの使用と制限を監視する必要があります。管理対象ディスクを使用することを強くお勧めします。まだ管理対象外のディスクを使用して展開している場合は、管理対象ディスクへの移行を検討する必要があります。
MySQL Dev / Test環境：標準ディスク
Azureから利用できる管理対象ディスクの種類は複数あり、デフォルトは標準ディスクです。標準ディスクは最大500IOPS（1秒あたりの入出力操作）をサポートでき、動的にサイズ変更できるため、開発およびテスト操作に適していますが、MySQLの実稼働環境には使用しないでください。
MySQL Production Deployment：プレミアムディスク
MySQL実稼働サーバーには、Azureプレミアムディスクを利用することを強くお勧めします。さまざまなプレミアムディスクから選択できます。プレミアムディスクごとに最適なサイズを選択できます。各サイズには異なるプロビジョンドIOPSが付属しているため、アプリケーションのニーズに最適なものを選択できます。
MySQL実稼働展開：ローカルSSD
AzureローカルSSDは、プレミアムディスクの高性能な代替手段であり、通常、大規模なクラスターに最適です。ローカルSSDは、はるかに高いI / Oパフォーマンスと、Azureで最高のスループットを提供します。ただし、永続的なストアではなく一時的なディスクであるという欠点があります。そのため、インスタンスを停止すると、データが失われます。非常に高速なLsv2シリーズをお勧めしますが、CPUが非常に弱いため、マシンのボトルネックが発生する可能性があることに注意してください。
Azure上のMySQLバックアップ
AzureでMySQLデータをバックアップする最良の方法は、マネージドディスクスナップショットを使用することです。スナップショットは、ディスクの読み取り専用のポイントインタイムバージョンです。これらのバックアップは、読み取り、コピー、または削除できますが、変更できないことに注意してください。 MySQLデータベースをリカバリする必要が生じた場合に備えて、すべてのデータベース、ユーザー、および設定がインスタンスにバックアップされるように、完全バックアップを実行することをお勧めします。また、バックアップスナップショットを暗号化して、バックアップが作成されたマシンにのみバックアップを復元できるようにすることもお勧めします。
ScaleGridの専用ホスティングプランのような包括的なMySQLonAzureソリューションを利用していない限り、MySQLバックアップには追加のAzureデータストレージ料金が発生します。コストを管理するために、バックアップの頻度、保持するバックアップの最大数、およびバックアップターゲットを構成できるカスタマイズ可能なスケジュールを通じて、バックアップを自動化することをお勧めします。もちろん、これは、実稼働環境でデータが失われた場合にMySQLデータが定期的にバックアップされるようにするのにも役立ち、最近のバックアップですばやく回復できます。
AzureでMySQLをホストする最良の方法について質問がある場合は、以下にコメントを残すか、support@scalegridまでご連絡ください。 io。また、30日間の無料トライアルを開始して、フルマネージドMySQLサービスを活用してデプロイメントのパフォーマンスを向上させることの利点を調べることもできます。
