[Laravel × Aurora MySQL]DB接続先を分離してアプリの耐久性を上げる

はじめに

イノベーション開発チームの大野です！
弊社ではnoteの方でもエンジニアブログをやってます。私についてのnoteはこちらからどうぞ！

本記事では、LaravelでDBの読み込み/書き込みの参照先を分離するために行なったことと、その注意点をご紹介します。

前提

バックエンド：Laravel
DB：Amazon Aurora MySQL

目的

DB起因のアプリケーション遅延を避けるために実施しました。

[背景]
社内メンバーが、管理画面で受注データのCSVをダウンロードして集計に使う業務があります。
この際、長期間指定してダウンロードをするとユーザー向け画面に遅延が発生してしまっていました。
社内業務が原因でユーザーの体験を損なうことになってしまうので、解消する必要がありました。

[原因]
アプリケーションがDBのライターしか参照していなかったことが原因でした。
リーダーはオートスケールで負荷に耐えられますが、ライターにはその機能がありません。
そのため一定以上負荷が高まるとパフォーマンスが大きく下がります。

Aurora レプリカでの Amazon Aurora Auto Scaling

注記
Aurora Auto Scaling は、ライター DB インスタンスのワークロードには適用されません。>Aurora Auto Scaling は、リーダーインスタンス上のワークロードにのみ役立ちます。

やること

設定ファイルの変更

読み／書き接続

read, write にエンドポイントを設定する

config/database.php

    'read' => [
        'host' => [
            env('DB_HOST_READ'),
        ],
    ],
    'write' => [
        'host' => [
            env('DB_HOST_WRITE'),
        ],
    ],

動作確認

参照が分かれてることを確認するために、STG環境で重いクエリを実行します。

リーダーは負荷が増えるが...

ライターは無事！

注意点

DB接続というシステムの根幹に手を加える変更なので、失敗時の切り戻し手順（DB_HOST環境変数の再設定、デプロイ前の検証環境へのロールバックなど）を準備しておくと良いと思います。

結果

管理画面の操作起因での遅延がなくなりました🎉

感想

やることは意外と少なかったです！
これまでDBのチューニングというと真っ先にクエリチューニングをしていました。しかしDBの接続先を分けるという選択ができたことで、機能単位ではなくアプリ全体で効果を得られました。

アプリだけではなく、設定レイヤーでチューニングができることはないかを確認する、という学びを得られました！