約のLAMPアプリケーション。 500 人のユーザーが、Web またはモバイル デバイス経由でアカウントに接続する際に、低速/接続およびスパイクの問題に直面していました。根本原因分析によると、既存の MySQL データベースは、Web サーバーと同じ EC2 でホストされており、CPU/RAM/IOPS リソースを共有する他の多くのサービスも含まれています。
現在のサーバーは、同時ユーザー ベースのサポート終了の制限に達しました。
MySQL を共有 EC2 ホスト サーバーから Aurora (mysql) に移動します。 Aurora はスケーラブルな RDBS であり、MySQL と互換性があり、いくつかの小さな変更で簡単に移植できます。
Aurora は、2 つの主な目的を持つリードレプリカを使用します。それらにクエリを発行して、アプリケーションの読み取り操作をスケーリングできます。これは通常、クラスターのリーダー エンドポイントに接続することによって行います。こうすることで、Aurora は、クラスター内にあると同じ数の Aurora レプリカに読み取り専用接続の負荷を分散できます。 Aurora レプリカは、可用性の向上にも役立ちます。クラスター内のライター インスタンスが使用できなくなった場合、Aurora は自動的にリーダー インスタンスの 1 つを新しいライターとして昇格させます。 Aurora には、リードレプリカと、DB スキーマに基づいて 100 万ユーザー以上の負荷を処理できる水平/垂直スケーラブルなアーキテクチャがあります。
Elastic Load Balancing は、実行中のすべての EC2 インスタンスに着信アプリケーション トラフィックを自動的に分散します。 Elastic Load Balancing は、1 つのインスタンスが過負荷にならないようにトラフィックを最適にルーティングすることで、着信要求を管理するのに役立ちます。
ロードバランサーを Auto Scaling グループにアタッチした後、Auto Scaling グループを構成して、Elastic Load Balancing メトリクス (ターゲットごとの Application Load Balancer リクエスト数など) を使用して、需要の変動に応じてグループ内のインスタンス数をスケーリングできます。
必要に応じて PHP/MySQL アプリケーションをスケーリングするのに役立ちます。 ASG はアプリケーションを監視し、容量を自動的に調整して安定した予測可能なパフォーマンスを維持します。スケーリングは需要に基づいているため、需要が低下するとサーバーは終了し、サーバーは縮小されます。 Auto Scaling は、PHP/MySQL アプリケーションの耐障害性と高可用性にもつながります。
github でホストされている PHP/MySQL コードは、新しいスケーリング グループがデプロイされるたびにプルされます。ロード バランサーが EC2 を起動してトラフィックを新しいサーバーにルーティングするたびに、サーバーが起動し、指定されたリポジトリのマスター ブランチからコードをプルします。 AMI を使用するプライマリ サーバーと追加サーバーでコードが変更された場合、コード ドリフトが発生する可能性があるため、AMI を使用することはできません。
CDN は、ユーザーの場所に基づいて低レイテンシーですべてのリクエストに対して静的な CSS/画像ファイルを提供します。ファイルは S3 バケットにあります。これにより、これらの静的コンテンツのダウンロード速度が向上します。
Web リクエストの任意の要素を検査するルールを提供します。 AWS WAF は、作成されたルールに従ってトラフィックをフィルタリングすることにより、Web アプリケーションを脅威から保護します。 CSS、SQL インジェクション、DDOS の WAF ルールは、PHP/MySQL アプリケーションへの攻撃を防ぎます。