Amazon Web Services ブログ

Amazon Aurora を使用して WordPress データベースバックエンドの容量をシームレスに増やす

今回は、Pagely の Arman Zakaryan (ホスティングオペレーション部門ディレクター) と Michael Martin (ソフトウェアエンジニア) によるゲスト投稿です。Pagely は、同社自身の言葉では、「WordPress のための非常にスケーラブルなマネージド型ホスティングソリューションを提供しています。世界で最大かつ最も革新的なブランドと協力して、オーダーメイドの WordPress ホスティングソリューションを作成しています。クライアントは、何よりもクライアントの幸せを最優先する、ベテランの DevOps エンジニアのオールスターチームによるサービスとサポートを享受できます。Pagely は、最高の状態で Enterprise WordPress をホスティングしています」。

WordPress は全ウェブサイトの 30 パーセントを駆動しています。これは、Pagely でビジネスを構築してきたコンテンツ管理システムです。当社のマネージド型 WordPress ホスティングは完全にアマゾン ウェブ サービス上で稼働します。Amazon が物理的なハードウェアやデータセンターの管理の心配からお客様を解放したのと同じように、Pagely は WordPress の管理を心配することなく自らの職務に集中できるようにします。Pagely が WordPress を大規模に実行することに対する献身的なサポートと経験は、Amazon の技術的なサービスと相性が良好です。

WordPress を実行する上で最も重要な側面の 1 つは MySQL データベースです。Amazon は Pagely のような会社が他のソリューションよりもはるかに優雅にそして効率的に業務上の職務を管理することを支援します。これは Amazon Relational Database Service (Amazon RDS) 、特に Amazon Aurora にある革新によるものです。

この記事では、Amazon Aurora で本番ワークロードの容量を増やすのがいかに簡単であるかを説明します。Aurora に組み込まれている機能により、このプロセスがより効率的かつ信頼できるものにする方法について説明します。十分な時間と適切な社内の才能をもって、あるいは商業的に利用できる他のソリューションにより、自己管理アプローチを使用して同様の結果を確かに達成できますが、Aurora を使用すると、このプロセスにかかる労力がはるかに少なくなり、統合性が向上し、よりアプローチしやすくなります。

Aurora はどの点が MySQL を超えるのでしょうか?

一言で言うと、実用性です。

パフォーマンス上の利点の他に、難なく維持することができます。MySQL や MariaDB エンジンを使用した Amazon RDS インスタンスよりも、新しいレプリカを作成してフェイルオーバーを実行するなどの操作がより速く、より強力に制御されます。RDS を使用しない「普通の」MySQL 環境と比較して、さらに一歩進んで、Aurora はより柔軟で使いやすい環境を提供します。

以前、Aurora の WordPress でのパフォーマンス向上についてブログを書きました。けれども、投げかけられる可能性があるさまざまなワークロードを処理するのに柔軟性がなければ、違いはありません。これらと同じ機能を社内で構築するには時間がかかる場合があります。あるいは、MySQL Cluster や Galera Cluster などの代替の商用ソリューションを本番環境に初めて導入するのに数週間かかる場合もあります。まだ AWS を使用していない場合は、AWS Database Migration Service (AWS DMS) と AWS Direct Connect がオンサイト MySQL および PostgreSQL システムを Aurora に移行するのに役立つツールです。

Amazon Aurora は何をするのでしょうか?

Amazon Aurora は、ハイエンドな商用データベースの速さと信頼性と、オープンソースデータベースのシンプルさと高い費用対効果を組み合わせたリレーショナルデータベースエンジンです。詳しくは、「Aurora のユーザーガイド」を参照してください。

Aurora リレーショナルデータベースサービスの標準設定は、プライマリ (ライター) インスタンスと単一のセカンダリ (リードレプリカ) インスタンスを持つマルチ AZ クラスターです。読み取りと書き込みのクエリの分割を行うことは可能であり、場合によっては必要でさえありますが、WordPress はそれをネイティブにサポートしていません。そのため、レプリカは通常の操作では実際には使用されません。したがって、レプリカの目的は、容量を拡大する必要がある場合に、サイズ変更可能なフェイルオーバーターゲットとして機能することにあります。これは、新しいインスタンスを作成するよりも既存のインスタンスのサイズを変更する方が一般的に速いことがわかったためです。

データベースインスタンスが過負荷になり始めたかどうかをすぐに知ることが重要です。その問題の原因を特定のクエリまたは顧客データベーススキーマに遡って追跡し、必要に応じて容量を増やし、変更中のダウンタイムを最小限に抑える必要があります。

Aurora クラスターの正常性を監視するには、Amazon CloudWatch を使用します。アラームは、高い CPU 使用率や特定のスループットの急激な上昇・低下など、運用上の問題について当社のチームに通知します。RDS イベント通知を使用して、予期しないフェイルオーバーイベントなどの通知を受け取ることもできます。これらは大規模な WordPress デプロイメントを管理するときに重宝する洞察です。

Aurora とどのように連携するのでしょうか?

当社のクライアントは、フォーチュン 500 企業から公共部門の一流大学、そしてその間の幅広い B2B ユーザーまで多岐にわたっています。急上昇は、最新情報、トラフィック、プロモーション、その他の情報源から発生する可能性があります。それが発生する前に、クライアントのサイトの準備が必要です。Aurora がスケーリング中および高負荷イベントからの回復のための取り組みをサポートする方法は次のとおりです。

突然の急上昇を管理する

Aurora DB クラスターが、顧客サイトのデータベースのセグメントを駆動していて、CPU 使用率が突然急増し、予約した予備の容量のほとんどを消費しているとしましょう。

この状況はさまざまな理由で発生する可能性があります。たとえば、データベースの大規模なグループが、共通のツールからバグのある更新を受け取った場合などです。負荷の問題を最初に評価する際に、リードレプリカのサイズを変更して容量を増やし、フェイルオーバーを実行する必要があるかどうかを判断します。

次に、フェイルオーバー後の CPU 使用率が許容範囲内であり、実際のアプリケーションパフォーマンスが通常の状態に戻ったことを確認します。

容量の問題を緊急に対処する際、当社はリソースの使用量が高くなっている原因を特定します、それは以下のようなものになるでしょう。

  • WordPress の悪いプラグインのアップデート
  • 悪いクエリ
  • 悪いサイト
  • ウェブキャッシュがないサイトなど

Aurora を使用すると、スケールアップして予想外のワークロードの増加を吸収し、急上昇を引き起こした問題に対処し、改善を監視できます。システムが安定したら、元のライターに戻ってもう一度リーダーを縮小します。

中断のない成長を促進

では、人気が高まっているプライベート Aurora RDS クラスターを持つエンタープライズクライアントを考えてみましょう。当社がアプリケーションの評価をしたところ、データベースエンドポイントはより多くの容量を必要とすることが示されました。その原因は CPU、メモリ、さらにはネットワークのスループットである可能性があり、それらはすべてより大きなインスタンスで多くのものが得られます。

クライアントは、もちろん、長時間のダウンタイムを経験したくないので、サイトを稼働させ続けるためのソリューションが必要です。これを処理する方法は、同等のサイズの一時読み取りレプリカを Aurora クラスターに追加することです。リーダーエンドポイントとして機能しながら、フェイルオーバーを実行し、元のインスタンスのサイズを変更します。

サイズの変更が完了したら、元のライターにもう一度フェイルオーバーし、一時的なレプリカを削除する前に新しい容量が十分であることを確認します。Aurora との特定の統合で、自動化が正しく機能するためにインスタンス名を同じに保つ必要がある場合は、次のプロセスも役に立つでしょう。新しいインスタンス名をより流動的に反映させることができる場合は、単により大きなレプリカを作成し、フェイルオーバーして他のインスタンスを削除します。

これについての最も良い部分は、プロセスがより控えめなワークロードに対して行う場合と同じ様に、何十万ものテーブルのデータベース使用量に対して確実に機能することです。当社がホストしている WordPress アプリケーションの中には (WordPress の基準と比較して) 膨大な量のデータがあるものがあり、それらのアプリケーションには Aurora が明らかに向いていると考えます。

Aurora を使用するためのコツは何かあるでしょうか?

以下が、当社が学んだ、Aurora を使用する上で時間の節約になるかもしれない方法です。

今後のメンテナンスについてクライアントに通知する

ダウンタイムがほとんどまたはまったく発生しないと予想される場合でも、常に定期メンテナンスについてクライアントとやり取りします。クライアントは状況を知らせてくれていることに感謝するでしょう。それはまたクライアントに、自らのクライアントに通知する機会も与えます。少しばかりのダウンタイムが発生したとしても、期待されることが正しく伝わっているので問題ありません。顧客がメンテナンスのお知らせを受け取るために購読できるステータスページを立ち上げると、これを効率的かつ日常的なステップにするのに役立ちます。

ユースケースに合わせてカスタムツールを開発する

Amazon RDS コンソールを使用して、必要なすべてのタスクを実行できます。しかし、基盤となる API とソフトウェア開発キットにより、特定のユースケースによりよく適合するワークフローとの統合を可能にします。API と連携するカスタムツールを開発することを強くお勧めします。これにより、RDS に直接アクセスすることなく、より単純化されたミッション指向の形式で、複雑な操作を直接顧客に、または内部的により幅広いスタッフメンバーに委任することができます。

うまくいく可能性があるものは何でしょうか? Rundeck、Red Hat Ansible や Jenkins などのオーケストレーションおよびパイプラインツールを使用すると、AWS API を活用して任意のシナリオを実行する独自の方法を作成できます。

使用状況やその他の傾向を監視する

CloudWatch アラームを事前に設定することが重要です。チームが E メールまたはポケベルシステムを通して目視できることを確認してください。

少なくとも、Aurora クラスターの CPU 使用率を監視する必要があります。これを SNS や PagerDuty と統合することで、自身の SRE (Site Reliability Engineering) チームに不満足な傾向を知らせることができます。そして適切な修復プロトコルをすばやく開始できます。特に負荷の問題に続いて、利用可能なすべてのメトリックを調べて、あなたのユースケースの問題を早期に警告するためにどのような追加のアラームが役立つかをよりよく理解しましょう。

ワークロードの急上昇を計画する

本番ワークロードを処理する Aurora クラスターでは、常に予備の CPU およびメモリ容量を維持してください。

一般的に、ベースラインの CPU 使用率を 50 パーセント以下に維持することが、使用率の急上昇を経験するワークロードの目標です。予備的な余裕があることで、ほとんどの急上昇を吸収し、可能な限りフェイルオーバーの必要性を回避できます。

このテーマに取り組む間、自動スケーリング機能を備えた Aurora Serverless が進行中で、それは本当のゲームチェンジャーになるかもしれません。これまでに説明したことはすべて、ピーク時にプロビジョニングし、必要に応じてより大きなインスタンスにフェイルオーバーするという戦略の下で行われています。これは効果的な戦略ですが、それでもやはりこれらの決定やイベントを推進するには、人の手や自ら自動化することが必要です。サーバーレスでは、これを懸念事項からほとんど排除することを約束します。それでも急上昇が発生しますが、十分な余裕を維持することにやきもきすることなく、その問題の原因を突き止めることに集中できます。この新製品が完成するのを見るのが楽しみです。

レプリカを維持する

フェイルオーバーターゲットとしてリードレプリカをオンラインにしておくことは、迅速なスケールアップパスを必要とする複数の顧客またはハイエンドのエンタープライズクライアントのワークロードを処理するインスタンスにとって非常に重要です。Aurora を使用して複数のレプリカを作成することは、AWS リージョン全体にわたる包括的な災害復旧 (DR) 計画の一部として使用できるオプションです。

コストを削減するために単一のライター Aurora クラスターを使用しても、Aurora レプリカの追加には通常、Aurora 以外の RDS MySQL よりも短時間で済みます。レプリカは必要に応じてオンラインにしてフェイルオーバー/スケールアップに使用し、後で削除することができます。

Aurora 以外の RDS クラスターを使用しても、これらのプロセスは実行可能ですが、Aurora はそれらを合理化するのに役立ちます。自己管理型の RDS MySQL 以外のサーバーでは、もう少し知識が必要で、注意深く扱う必要があります。

結論

Amazon Aurora は、パッケージとして、すぐに利用できる組み込みツールを備えています。これらのツールを用意することで、自分で何かを構築するために費やす時間を節約できます。また当社のような業界ではかけがえのないものであり、信頼し構築することができるソリューションも提供します。

著者について

Arman Zakaryan は Pagely のホスティングオペレーション部門のディレクターです。

 

 

 

Michael Martin は Pagely のソフトウェアエンジニアです。