データベース on ララジャパン

第２のデータベースにアクセス

Fri, 14 Nov 2025 12:04:49 +0900

たいていのプロジェクトで扱うデータベースは１つですが、これが２つあるいは３つのデータベースにアクセスするとなったら、どう対応するのでしょう？というのが今回のテーマです。

データベースのコネクション

まず、データベースのコネクションに関しての説明です。扱うデータベースが１つとすると、

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password
...

と設定します。これらの環境変数は、以下のconfig/database.phpにおいてのデータベース接続のための値となります。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DB_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'laravel'),
            'username' => env('DB_USERNAME', 'root'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => env('DB_CHARSET', 'utf8mb4'),
            'collation' => env('DB_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

扱うデータベースが２つのとき

デフォルトのデータベースへのコネクションが、mysqlとすると、もう１つ扱うデータベースを mysql2 として、先のconfig/database.phpに追加することができます。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [
      　 // デフォルトのデータベース
        'mysql' => [
        ...
        ],

　　　　// 第２のデータベース
        'mysql2' => [
            'driver' => 'mysql',
            'url' => env('DB2_URL'),
            'host' => env('DB2_HOST', '127.0.0.1'),
            'port' => env('DB2_PORT', '3306'),
            'database' => env('DB2_DATABASE', 'laravel'),
            'username' => env('DB2_USERNAME', 'root'),
            'password' => env('DB2_PASSWORD', ''),
            'unix_socket' => env('DB2_SOCKET', ''),
            'charset' => env('DB2_CHARSET', 'utf8mb4'),
            'collation' => env('DB2_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

mysql2では、環境関数名は皆DB2_のプレフィックスとなっていることに注意を。

.envでは、こんな感じに設定します。

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password

DB2_HOST=localhost
DB2_PORT=3307
DB2_DATABASE=db2
DB2_USERNAME=root2
DB2_PASSWORD=password2
...

第２のデータベースにアクセスするには

さて、第２のデータベースにアクセスしてみましょう。

クエリビルダーでは、以下のようにconnection()の引数に第２のデータベースのコネクション mysql2 を指定するだけです。

DB::connection('mysql2')->table('user')->get();

Eloquentではどうでしょう。

まず、第２のデータベースのモデルを作成します。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';

    protected $connection = 'mysql2'; // ここでコネクションを指定
}

ここでは、デフォルトのデータベースと同じように、第２のデータベースでも users というテーブルが存在すると仮定します。通常と違って、mysql2のコネクションが指定されていることも注意を。

この設定なら、クエリの実行はデフォルトのデータベースのEloquetとまったく変わりません。簡単ですね。

RemoteUser::all();

Eloquentで動的にコネクションを指定

先のEloquentはモデル内ですでに指定されている固定のコネクションでしたが、前もってわからないときはどうしましょう。つまりモデルの定義が以下のようなときのことです。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';
}

このようなときは、クエリ実行時において、以下のようにコネクションを指定します。

RemoteUser::on('mysql2')->get();

上では、RemoteUser::on(‘mysql2’)は、Illuminate\Database\Eloquent\Builderを返すので、RemoteUser::on(‘mysql2’)::all()とは出来ないことに注意を。

ユニットテストの超高速化

Wed, 17 Jul 2024 11:26:20 +0900

長年管理しているお客さんのプロジェクトのユニットテスの数が増えてきました。Featureテストも含めてテストケースの数は2,400以上あります。私の古めのWindowsのマシン（i7-9700CPU @ 3.00GHz）のWSL2環境では、7分51秒かかります。今回はこのテスト実行所有時間をほぼ1/10の50秒以下に縮めた話です。

mysqlをメモリー内で実行

DBを使用するテストが多いので最初に考えたのは、使用しているmysqlサーバーのエンジンをInnoDBからMemoryとすることです。しかしこれはすぐに不可能とわかりました。MemoryのエンジンではTEXTのデータタイプを対応していないからです。

どうしたらよいかといろいろ調査すると、mysqlのDBを保存しているボリュームをハードディスクのストレージからtmpfsに変えれば良いらしい。tmpfsは以下に説明されるようにメモリに存在するファイルシステムです。 tmpfsとは

しかし、ローカル環境（WSL2）で実行されているmysqlサーバーをtmpfsで走らせるとなると、mysqlサーバーがいろいろなプロジェクトで共有されているためにとても不都合であるし、マシンを落としたらそれでDB内のデータは消えてしまうとなるともっと困ります。

ということで、sailを使用してdocker内でmysqlサーバーをtmpfsで実行するのが理想となりました。

sailのセットアップに関してはここでは説明しませんが、セットアップの産物としてdocker-compose.ymlが作成されます。

このdocker-compose.ymlのmysqlサーバーの定義において、以下のようにvolumesのsail-mysqlをコメントアウトして、tmpfsを追加します。

...
    mysql:
        image: 'mysql/mysql-server:8.0'
        ports:
            - '${FORWARD_DB_PORT:-3306}:3306'
        environment:
            MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ROOT_HOST: '%'
            MYSQL_DATABASE: '${DB_DATABASE}'
            MYSQL_USER: '${DB_USERNAME}'
            MYSQL_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ALLOW_EMPTY_PASSWORD: 1
        volumes:
            # - 'sail-mysql:/var/lib/mysql' # コメントアウト！
            - './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
        tmpfs: # ここを追加！
            - /var/lib/mysql
        networks:
            - sail
        healthcheck:
            test:
                - CMD
                - mysqladmin
                - ping
                - '-p${DB_PASSWORD}'
            retries: 3
            timeout: 5s
...

以下を実行して、

$ sail up

dockerを立ち上げて、docker内のmysqlサーバーのファイルシステムを見ると、

sh-4.4# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         251G   26G  213G  11% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
shm              64M     0   64M   0% /dev/shm
/dev/sdd        251G   25G  214G  11% /docker-entrypoint-initdb.d/10-create-testing-database.sh
/dev/sde        251G   26G  213G  11% /etc/hosts
tmpfs           7.8G  199M  7.6G   3% /var/lib/mysql
tmpfs           7.8G     0  7.8G   0% /proc/acpi
tmpfs           7.8G     0  7.8G   0% /sys/firmware

/var/lib/mysqlがtmpfsとなっていますね。

テストを実行してみましょう。

$ sail artisan test

テスト実行の所有時間は、7分51秒から219秒から3分39秒と一気に半分以下となりました。

並行処理でテストを実行

今度は、パラレルテストを利用してもっと高速化してみましょう。

まず、必要なライブラリをインストールします。

$ sail composer require brianium/paratest --dev

その後、パラレルテストを実行します。

$ sail artisan test --parallel

tmpfsとパラレルを組み合わせたテスト実行となり、その結果、所有時間は驚異の49秒となりました。ほぼ1/10の時間です。

Docker内のmysqlサーバーでデータベースを閲覧すると、以下のように、testingのデータベース７個新たに作成ｓれて、計８個となっています。これは私のマシンが８コアのためです。パラレルテストは使用のマシンのコア数でデータベースの数が決まります。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| laravel            |
| mysql              |
| performance_schema |
| sys                |
| testing            |
| testing_test_1     |
| testing_test_2     |
| testing_test_3     |
| testing_test_4     |
| testing_test_5     |
| testing_test_6     |
| testing_test_7     |
+--------------------+

ちなみに、tmpfsなしのパラレルテストの所要時間は、5分28秒でした。tmpfs + parallelが最速のチームということですね。

artisan dbコマンド

Mon, 08 Jan 2024 02:33:53 +0900

Laravelの最新バージョンは10xでもうすぐに11xがリリースされます。しかし、Laravel 9xでartisan dbコマンドにオプションが増えていることについ最近気づいたので、忘れずにここで紹介します。

Laravel 9x以前から存在したdbコマンド

db:seed

まず、データベースにシードのレコードを作成するコマンドです。

$ php artisan db:seed

と実行すると、以下のDatabaseSeederがデフォルトで使用されます。

database/seeders/DatabaseSeeder.php

namespace Database\Seeders;

// use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     */
    public function run(): void
    {
        \App\Models\User::factory(10)->create();　// 10個のusersのレコードが作成されます

        // \App\Models\User::factory()->create([
        //     'name' => 'Test User',
        //     'email' => 'test@example.com',
        // ]);
    }
}

新規のプロジェクトでは、seedを実行する前には以下のようにmigrateを実行しましょう。

しかし、プロダクションではこんなに簡単に実行できると危ないと思いませんか？ちなみに、上の実行の環境では、.envでAPP_ENVはlocalで私の開発環境設定です。

.env

APP_NAME=Laravel
APP_ENV=local
...

この値が、productionのときには、上のコマンドを実行すると、

と警告してくれて実行してOKかどうか質問されます。しかし、それでも実行は可能です。注意しましょう。

db:wipe

db:seedは実行する環境によっては危険なコマンドでしたが、こちらはもっと危険です。以下は、APP_ENV=localでの実行ですが、有無も言わさずにDBのテーブルをすべて削除してしまいます。

もちろん、APP_ENV=productionのときには、db:seedと同様に警告と確認のステップがあります。

Laravel 9xで登場したdbコマンド

今度は、Laravel 9xで追加されたコマンドたちです。先のDB操作のコマンドとは違って今度はどれもDBの情報をすぐにチェックできる有用なコマンドです。

db:monitor

現在のDBの接続数を表示するコマンドです。

db:show

DBの情報を表示するコマンドですが、Doctrine DBAL (doctrine/dbal)のパッケージがインストールされていないと、インストールするかどうかが問われます。YESとすると、必要なパッケージがインストールされます。

インストール完了後、再度実行すると、

db:table

こちらは、DBテーブルの情報を表示するコマンドです。まず、どのテーブルの情報が必要か尋ねられます。

usersを選択してENTERすると、

DBテーブルの項目などテーブルの情報を表示してくれます。これはとても便利ですね。

クエリの累計時間にタイムアウトを設定する（２）

Thu, 27 Jul 2023 11:10:26 +0900

前回の記事にてタイムアウトとなった場合に２種類の例外がスローされる事を説明しました。クエリ実行中にタイムオーバーとなった場合は、QueryException。クエリ実行外でタイムオーバーとなり、その後クエリを実行してエラーとなる場合は、自作したTimeoutExceptionです。今回はこれらのエラーをどうキャッチしてハンドリングするのか解説します。

検証用のページ

説明の為にテスト用のコントローラを用意しました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            return 'error';
        }

        return 'success';
    }
}

ルーティングは以下の通りです。

routes/web.php

<?php

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\TimeoutTestController;

Route::get('/timeout_test', [TimeoutTestController::class, 'index']);

indexアクションでは重いクエリが２つ実行されます。それらが正常に処理できた場合はsuccess、何かしらのエラーが発生した場合はerrorを返します。尚、GETパラメタでtimeoutの指定がある場合は、DbQueryTimeoutを使用して制限時間が設定されます。ビルドインサーバーを起動して挙動を確認してみましょう。

php artisan serv

まず、パラメタ無しで /timeout_test へアクセスしてみてください。約8秒後にsuccessと表示されるはずです。次に、timeoutパラメタを指定して制限時間を設定してみましょう。/timeout_test?timeout=5 として制限時間を5秒にしてアクセスしてみて下さい。すると、約５秒後に処理が中断されerrorと表示されるはずです。

Tips: 重いクエリをシミュレートする方法

重いクエリ = 時間が掛かるクエリ、という事でDB側でsleep()を実行してシミュレートできます。mysqlではsleep()は正常にスリープできた場合は0、途中で中断された場合は1が返却されます。しかし、実際の環境ではmax_execution_timeで指定した時間をオーバーして処理が中断された場合は１ではなくエラーが発生します。sleep()においてもタイムオーバーした場合にエラーを返させるには、unionで追加の処理を実行すればOKです。追加の処理はなんでも良いので今回は適当にselect 1としました。実際にmysql clientにて以下を実行して試してみると理解しやすいと思います。

# 制限時間を5秒に設定
mysql> set max_execution_time = 5000;
Query OK, 0 rows affected (0.01 sec)

# 制限時間内に終わるsleepなら0が返却される
mysql> select sleep(4);
+----------+
| sleep(4) |
+----------+
|        0 |
+----------+
1 row in set (4.05 sec)

# 制限時間内に終わらずsleepが中断されたら1が返却される
mysql> select sleep(5);
+----------+
| sleep(5) |
+----------+
|        1 |
+----------+
1 row in set (5.06 sec)

# unionで追加の処理を含めるとエラーが返却される
mysql> select sleep(6) union select 1;
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded

エラーのハンドリング

冒頭で述べた通り制限時間をオーバーした場合は２種類のタイムアウトエラーが発生します。しかし、アプリにおいては当然それ以外のエラーも発生し得るので、タイムアウトエラーとそうでないエラーの場合で判別してエラーを出し分ける必要があります。それぞれどの様に判別すれば良いでしょうか。

TimeoutExceptionをキャッチ

先に簡単な方から、TimeoutExceptionを判別する場合です。こちらはシンプルにスローされたExceptionのインスタンスをチェックすれば判別できます。TimeoutTestController.php のindexアクションを以下の様に書き換えてみましょう。

app/Http/Controllers/TimeoutTestController.php

...
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            // TimeoutExceptionの場合のエラー文言
            if ($e instanceof TimeoutException) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }

TimeoutExceptionは、クエリ実行外でタイムオーバーし、次のクエリが実行されるタイミングでスローされます。そちらを再現する為に、クエリ１とクエリ２の間にPHP側のスリープを3秒挟みました。これにより制限時間が5秒の場合はTimeoutExceptionがスローされるはずです。再度、ビルドインサーバにて/timeout_test?timeout=5へアクセスしてみて下さい。今度はtimeout errorと表示されたはずです。

クエリ実行中にタイムアウトした場合のエラー

クエリ実行中にタイムアウトした場合はQueryExceptionがスローされます。QueryExceptionはタイムアウト以外でもスローされる例外ですので、前項のTimeoutExceptionの様にインスタンスだけではタイムアウトエラーを判別できません。判別には一歩踏み込んで、$e->errorInfoのチェックが必要です。errorInfoはQueryExceptionの親クラスであるPDOExceptionにセットされていた値で、PHPマニュアルによると、データベースハンドラにおける直近の操作に関連する拡張エラー情報が配列で格納されています。タイムアウトエラーとしてQueryExceptionがスローされた際の$e->errorInfoは以下の様になります。

[
  0 => "HY000"
  1 => 3024
  2 => "Query execution was interrupted, maximum statement execution time exceeded"
]

0はSQLSTATEエラーコード、1はドライバ固有のエラーコード、2はそのエラーメッセージです。判別には1のドライバ固有のエラーコードを使用します。こちらの記事によると、max_execution_timeの設定をオーバーした場合のエラーコードは MySQL 8.0.19 以前は3024か1028で、以降は3024に統一されたとの事です。私の環境はまだMySQL5.7なので、1028のエラーコードも補足する必要があります。これらを考慮して、TimeoutTestControllerの例外処理部分を次の様に修正しました。

app/Http/Controllers/TimeoutTestController.php

...
        } catch (\Exception $e) {
            $timeoutError = false;

            switch (get_class($e)) {
                case TimeoutException::class:
                    $timeoutError = true;
                    break;

                case QueryException::class:
                    if (in_array($e->errorInfo[1], [3024, 1028])) {
                        $timeoutError = true;
                    }
                    break;
            }

            if ($timeoutError) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

インスタンスのチェックはswitch文でget_class($e)でクラス名を取得して分岐する様に変更しました。QueryExceptionの場合はerrorInfoでエラーコードもチェックします。クエリ実行中にタイムオーバーとなるように/timeout_test?timeout=7へアクセスしてみて下さい。再度、timeout errorが表示されるはずです。

リファクタリング

これまで説明の為にコントローラ側にタイムアウトエラーのエラー処理のコードを記述してきましたが、DbQueryTimeoutと一緒に色々な箇所で使い回すのでまとめておいた方が良さそうです。という事で、DbQueryTimeout::isTimeoutError()にコードを移しました。

app/Services/DbQueryTimeout.php

...
    // タイムアウトエラー発生？
    public static function isTimeoutError(\Exception $e): bool
    {
        $timeoutError = false;

        switch (get_class($e)) {
            case TimeoutException::class:
                $timeoutError = true;
                break;

            case \Illuminate\Database\QueryException::class:
                if (in_array($e->errorInfo[1], [3024, 1028])) {
                    $timeoutError = true;
                }
                break;
        }

        return $timeoutError;
    }
...

isTimeoutError()はシンプルにタイムアウトエラーか否かを判別するメソッドです。このメソッドを使う事でTimeoutTestController側は次の様にシンプルになりました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            if (DbQueryTimeout::isTimeoutError($e)) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

クエリの累計時間にタイムアウトを設定する（１）

Thu, 27 Jul 2023 11:06:11 +0900

先日、管理サイトにてアラートが発生しました。調査すると、ある検索画面で利用者が重いクエリを連続で発行した事が原因でした。待ち時間が長かった為、不安になり検索ボタンを連打してしまったようです。サーバに負荷を掛ける操作については注意喚起するとして、待ち時間に制限が無いのはよくありません。そこで、検索処理に制限時間を設ける事にしました。今回はそちらの実装にあたって色々学んだことがあるので紹介します。

クエリの実行時間を制限する

今回実装した内容を簡単に説明すると、検索処理に対して実行可能時間を設定し、時間切れとなった場合にエラーを返すというものです、要はタイムアウトの設定です。検索処理においてボトルネックとなっていたのはDBへのクエリ部分で、それ以外の処理時間は無視して良いレベルでした。従って、クエリの実行時間に制限を設ける事にしました。

クエリにタイムアウトを設定する方法については過去の記事の「クエリーの実行所有時間の制限」の項目で紹介されており、今回もこちらを使います。簡単におさらいすると、DB::statement()を使用して、MySQLのmax_execution_timeを設定する方法です。例えば、以下は5秒に制限する場合のコードです。

DB::statement('SET SESSION MAX_EXECUTION_TIME = 5000');

こちらを実行すると、以降クエリで5秒以上掛かった場合にQueryExceptionがスローされます。

クエリの累計時間を制限する

ボトルネックとなるクエリが１つの場合は前項の方法で制限時間を設ければOKですが、今回の実装先には重いクエリが複数実行されており、それらの累計時間を制限する必要がありました。例えば、以下のように制限時間を５秒に設定した場合、クエリ１とクエリ２で合わせて５秒を超えたらタイムアウトエラーとします。

クエリの累計時間に制限を設けるには、クエリを実行する毎に都度残り時間を計算し、それを前項で紹介した方法で設定していけば良さそうです。つまり、以下の様に

クエリ１の時点では残り時間を５秒として制限時間を設定しますが、クエリ２の時点ではクエリ１で３秒掛かったので、残りの実行可能時間２秒を制限時間として再設定します。

DbQueryTimeout.php

ロジックについて理解が深まったところで、実際のコードを紹介します。クエリの制限時間を管理するクラスとして app/Services 配下に DbQueryTimeout.php を追加しました。

app/Services/DbQueryTimeout.php

<?php

namespace App\Services;

use App\Exceptions\TimeoutException;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Str;

class DbQueryTimeout
{
    const TIMEOUT_QUERY = 'SET SESSION MAX_EXECUTION_TIME';

    public static $maxExecutionTime;  // 最大実行可能時間（ミリ秒）

    public static $processStartTime;  // プロセス開始時刻（マイクロ秒）

    // タイムアウト設定初期化
    public static function set(int $seconds): void
    {
        self::$maxExecutionTime = $seconds * 1000;
        self::$processStartTime = microtime(true);

        DB::beforeExecuting(function ($query) {
            // タイムアウト設定のクエリなら何もしない
            if (Str::startsWith($query, self::TIMEOUT_QUERY)) {
                return;
            }

            // 残りの実行可能時間を計算
            $timeRemaining = self::timeRemaining();

            // 実行可能時間が残っていないなら例外スロー
            if ($timeRemaining <= 0) {
                throw new TimeoutException;
            }

            self::setTimeout($timeRemaining);
        });
    }

    // タイムアウト設定
    public static function setTimeout(int $time): void
    {
        DB::statement(self::TIMEOUT_QUERY.' = '.$time.';');
    }

    // 残りの実行可能時間をミリ秒で返す
    public static function timeRemaining(): int
    {
        return self::$maxExecutionTime - self::elapsedTime();
    }

    // 経過時間をミリ秒で返す
    public static function elapsedTime(): int
    {
        return (int) ((microtime(true) - self::$processStartTime) * 1000);
    }
}

後で説明しますが、このクラス内で使用されている TimeoutException は自作の例外クラスになります。app/Exceptions 配下に TimeoutException.php を追加してください。

app/Exceptions/TimeoutException.php

<?php

namespace App\Exceptions;

use Exception;

class TimeoutException extends Exception
{
}

DbQueryTimeout の使い方はとてもシンプルで、実行時間を制限したい箇所の最初にset()を実行するだけです。set()の引数には制限時間を秒で指定します。例えば、制限時間を５秒としたいなら以下の様に。

DbQueryTimeout::set(5);

すると、set()が実行された時点からカウントダウンが始まり、タイムオーバーとなった場合は以下の２パターンでエラーが発生します。

クエリ実行中
クエリ実行外で、それ以後にクエリを実行しようとした

前者の場合はQueryExceptionがスローされ、後者の場合はTimeoutExceptionがスローされます。

参考までに実装例を掲載します。以下は注文データを検索するページです。

app/Http/Controllers/InvoiceController.php

<?php

namespace App\Http\Controllers;

use App\Models\Invoice;
use App\Models\InvoiceShip;
use Illuminate\Http\Request;
use App\Services\DbQueryTimeout;
use Illuminate\Contracts\View\View;

class InvoiceSearchController extends Controller
{

    /**
     * 検索画面
     */
    public function index(Request $request): View
    {
        $input = $request->all();

        // 制限時間を5秒に設定
        DbQueryTimeout::set(5);

        // 注文データ
        $invoices = Invoice::query()
            ->whereBetween('invoice_date', [$input['date_start'], $input['date_end']])
            ->where('invoice_status', '=', $input['invoice_status'])
            ->orderBy('invoice_date', 'desc')
            ->paginate(config('local.items_per_page'))
            ->withQueryString();

        // 注文配送データ
        $invoice_ships = InvoiceShip::query()
            ->whereIn('invoice_id', $invoices->pluck('invoice_id'))
            ->where('invoice_ship_status', '=', $input['invoice_ship_status'])
            ->get();

        return view('admin.invoice_index')
            ->with(compact('input', 'invoices', 'invoice_ships'));
    }

}

上記のコントローラのindexアクションでは以下の３つのクエリが実行されています。

１ページに表示する注文データ
注文データの件数
注文データに紐づく注文配送データ

これら３つのクエリの累計実行時間が５秒を超える場合はエラーが発生します。エラーが発生した場合の処理については次の投稿で紹介します。

コードのポイント

コア部分であるset()で行われている処理について補足です。set()ではクエリ毎に実行されるbefore処理を登録しています。before処理では以下の処理が実行されます。

実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行
それ以外のクエリなら残りの実行可能時間を計算
残り時間なし（既にタイムオーバー）ならTimeoutExceptionをスロー
残り時間があるならそれを制限時間として設定

before処理の登録にDB::beforeExecuting()を使用している点がポイントです。こちらはドキュメントには載っていませんが、イベントリスナーの様にEloquentやクエリビルダにてクエリが実行される毎に直前に呼び出すコールバックを登録できます。余談ですが、after処理の登録にはDB::listen()というメソッドがあります。（こちらはドキュメントにも載っている。）

DB::beforeExecuting()のクロージャの引数$queryはSQLが文字列で渡されます。1. 実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行ではそちらが、SET SESSION MAX_EXECUTION_TIMEから始まるクエリかチェックして、そうならbefore処理を終了しそのままクエリの実行に移ります。そうしなければ、この制限時間を設定するクエリに対しても更にbefore処理をして、、、と無限ループとなってしまうからです。

長くなってしまったので、一旦ここで切ります。次回はエラー処理について解説します。

【Eloquent】has() vs joinSub()

Mon, 24 Oct 2022 12:54:19 +0900

過去の記事でも紹介されていますが、親子（or 1対多）関係にあるModelにおいて、「１つ以上子を持つ親」などの条件で絞り込む際にhas()は便利です。

しかし、has()を使わずともjoinSub()でサブクエリを指定して同じ条件で絞り込む事もできそうです。どちらを使うのがベターなのか？気になったので調べてみました。

has()とjoinSub()の違い

例えば、店(Shop)と商品(Product)というModelが有った場合、「１つ以上商品を持つ店」はそれぞれ以下で絞り込むことができます。

// has()で絞り込み
$shops = Shop::has('product')->get();

// joinSub()で絞り込み
$sub = Product::distinct()->select('shop_id');

$shops = Shop::joinSub($sub, 'sub', function ($join) {
        $join->on('sub.shop_id', '=', 'shop.shop_id');
    })->get();

見ての通り、joinSub()の方が冗長ですね。

発行されたsqlはそれぞれ以下になります。

# has()のsql
select * from `shop` where exists (select * from `product` where `shop`.`shop_id` = `product`.`shop_id`);

# joinSub()のsql
select * from `shop` inner join (select distinct `shop_id` from `product`) as `sub` on `sub`.`shop_id` = `shop`.`shop_id`;

has()ではEXISTS句で相関サブクエリを使用して絞り込んでいます。

相関サブクエリとは

mysqlの公式ドキュメントからの引用です。

相関サブクエリは、外部クエリにも現れるテーブルへの参照を含むサブクエリです。

前述のhas()のsqlでは、外部クエリのFROMに指定しているshopをサブクエリ内で参照している為、相関サブクエリと言えます。

相関サブクエリの注意点

レコード数が多いテーブルに紐づいたModelにてhas()使う際は注意が必要です。

相関サブクエリでは外部クエリの結果行数分、比較処理が行われる可能性があり、結果行数が多ければ遅くなる為です。

例えば前述のhas()のsqlでは、shopのレコード数 x productのレコード数分の比較処理が走ることになります。（EXISTS句では条件にヒットする行が見つかればその時点でtrueを返し、次のレコードの比較処理に移るため、あくまでも全件ヒットしなかった場合）

とはいえ、それをjoinSub()に置き換えた場合もGROUP BYやDISTINCTで重複を削除する処理のコストが有るため、一概にどちらが速いと言い切れません。

実際に実装する環境でテストしてみるのが良いでしょう。

今回の実装環境ではhas()でもjoinSub()でも速度に大きな違いはありませんでした。であればよりシンプルに記述できるhas()がベターと考えてそちらを採用することにしました。

DBテーブルをjoinして値を更新

Sun, 16 Oct 2022 11:57:03 +0900

これまた、データベースの話ですが、長期でアクティブに管理しているプロジェクトでは必ず登場してくる作業です。

どういうときに必要？

例えば、以下のようなデータの会員テーブル(users)があります。

id	name	rank
1	高橋美加子	A
2	浜田太一	B
3	中島充	A
4	渚あすか	B
5	渚和也	A

最後の項目は、会員ランクで過去２年間に会員が購入した商品の送金額により会員ランクが決まります。会員ランクには、ＡとＢの２つあり、会員ランクＡの会員は、購入の際に5%の割引があるなどの恩恵があります。Ｂランクの会員は残念ながら恩恵なしです。

さて、会員数も増えてきて、Ａランク会員が多すぎて購入額の総額も同じランクでばらつきがあることから、ランクを１つ増やすことにします。つまり、今度はＡ，Ｂ，Ｃと３つのランクとなります。

もちろん、Artisanコマンドを作成して新たなランク計算式を使い、usersのそれぞれのレコードを更新することも可能ですね。こんな感じで。

User::all()->each(function($user) {
    $user->rank = $user->calcNewRank();
    $user->save();
})

しかし、これではもとのランクの値がなんであったか残りません。更新前に、usersのテーブルをdumpしてファイルとして残してもよいですが、もしかしたら、移行後にも旧のランク値はクレームときのために必要かもしれません。

値の移行のためのテーブルを新規に作成

このようなときは、まず、一時的に使用するテーブルを作成して、そこでusersのそれぞれのレコードに対応する旧と新のランクをあらかじめレコードを作成します。テーブル名は、change_rankとして以下のようなデータとなります。

user_id	name	old_rank	new_rank
1	高橋美加子	A	A
2	浜田太一	B	C
3	中島充	A	B
4	渚あすか	B	C
5	渚和也	A	B

change_rankのテーブルとusersのテーブルは、両者のプライマリーキー(users.idとchange_rank.user_id)を介してまったく１対１の関係となり、後の一括更新に使用されます。さらに、この移行のテーブルを残しておけば、旧と新のランク値のスナップショットとなり、何かのときにとても有用なものとなります。

一括更新

通常更新は、１つのテーブルにおいて、例えば以下のように更新します。

UPDATE users SET rank = 'A';

しかし、今回のケースは２つのテーブルが関わる、つまり１つのテーブルの値をもとにもう１つのテーブルの値の更新となるので、joinが必要となります。SQL文では以下のようになります。

UPDATE users
INNER JOIN change_rank ON users.id = change_rank.user_id
SET user.rank = change_rank.new_rank;

さて、これをSQL文でなく、クエリビルダーで行うなら、以下のようなコードとなります。

DB::table('users')
    ->join('change_rank', 'users.id', '=', 'change_rank.user_id')
    ->update(['users.rank' => DB::raw('change_rank.new_rank')]);

ここ以下のように書いてしまいそうですが、DB::raw()がないとエラーとなるので注意を。

DB::table('users')
    ->join('change_rank', 'users.id', '=', 'change_rank.user_id')
    ->update(['users.rank' => change_rank.new_rank]);

from句のサブクエリ

Tue, 03 Aug 2021 23:53:37 +0900

集計用のコマンドを書いていてクエリビルダでfrom句にサブクエリを使いたいケースが発生しました。公式ドキュメントを見てもwhere句かjoin句でのサブクエリしか書かれていません。恐らくこうやるのでは？と、試してみたら期待通りに動いてしまい、結局、不安になってソースを確認したのでその共有です。

from句のサブクエリが必要なケースとは？

例えばECサイトにおける顧客分析で注文回数別にユーザ数を算出する場合を考えてみましょう。

以下のような注文テーブルがDBにあったとして、ユーザが商品を注文する度にこのテーブルにレコードが挿入されます。

そして、以下のようなデータを出力したいとします。

１回購入したユーザは60人、２回購入したユーザは50人、３回購入したユーザは10人、、、といった具合です。

これを出力する為のsql文は以下になります。

select
    invoice_count,
    count(user_id) as user_count
from (
    select
        user_id,
        count(invoice_id) as invoice_count
    from invoices
    group by user_id
) as invoices_by_user
group by invoice_count;

from句にユーザごとの購入回数を取得するサブクエリを指定する必要があり、これをどうやってクエリビルダで組み立てるか？が今回のゴールです。

※次項から解説になりますが、手を動かしながら確認したい方は記事の最後のおまけ、検証データ準備をご参照下さい。

DB::table($subQuery)

冒頭にて触れた通り、公式ドキュメントに載っているのはwhere句やjoin句にsubQueryを指定する方法です。いずれもClosureを指定して実現しています。ということは、table()に同様にClosureを渡せば良いのでは？、と思いやってみました。

まず、$subQueryという変数にClosureを格納します。Closureの引数にクエリビルダを指定し、サブクエリにて実行したいクエリを定義します。

$subQuery = function ($query) {
    $query->from('invoices')
        ->selectRaw('user_id, count(invoice_id) as invoice_count')
        ->groupBy('user_id');
};

次に、それをtable()の引数に指定してみます。

$query = DB::table($subQuery)
    ->selectRaw('invoice_count, count(user_id) as user_count')
    ->groupBy('invoice_count');

最後に、toSql()でクエリを確認してみましょう。（見辛いので改行しています）

>>> $query->toSql();
=> "select invoice_count, count(user_id) as user_count 
    from (
        select user_id, count(invoice_id) as invoice_count 
        from `invoices` 
        group by `user_id`
    ) as `` 
　　　　　　　　group by `invoice_count`"

予想通り(?)、from句のサブクエリを指定することが出来ました。しかし、よく見てみるとサブクエリのエイリアスが空文字(``)になってしまっています。ここで私はこれが正しい使い方なのか不安になり、table()を解析することにしました。

ソース確認

まず、DBファサードを見てみます。すると、Docコメントにてtableメソッドについて記述されています。

vendor/laravel/framework/src/Illuminate/Support/Facades/DB.php

namespace Illuminate\Support\Facades;

/**
 * @method static \Illuminate\Database\ConnectionInterface connection(string $name = null)
 * @method static \Illuminate\Database\Query\Builder table(string $table, string $as = null)   <- ココ
...

第二引数にstring $asを取っているので、エイリアスはそこに指定すれば良さそうですね。せっかくなので、メソッドを見てみます。メソッドは下記のどちらかに定義されているようです。

vendor/laravel/framework/src/Illuminate/Support/Facades/DB.php

...
 * @see \Illuminate\Database\DatabaseManager
 * @see \Illuminate\Database\Connection
...

確認したところ、\Illuminate\Database\Connectionにありました。

vendor/laravel/framework/src/Illuminate/Database/Connection.php

   /**
     * Begin a fluent query against a database table.
     *
     * @param  \Closure|\Illuminate\Database\Query\Builder|string  $table
     * @param  string|null  $as
     * @return \Illuminate\Database\Query\Builder
     */
    public function table($table, $as = null)
    {
        return $this->query()->from($table, $as);
    }

なるほど、第一引数の$tableにはstring以外に、Closureやクエリビルダも渡すことができるみたいです。そして、内部的にはfrom()を呼び出しています。from()はどうなっているのでしょうか？

vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php

    /**
     * Set the table which the query is targeting.
     *
     * @param  \Closure|\Illuminate\Database\Query\Builder|string  $table
     * @param  string|null  $as
     * @return $this
     */
    public function from($table, $as = null)
    {
        if ($this->isQueryable($table)) {
            return $this->fromSub($table, $as);
        }

        $this->from = $as ? "{$table} as {$as}" : $table;

        return $this;
    }

なるほどなるほど、$tableがClosureやクエリビルダであればisQueryable()がtrueとなりfromSub()を呼び出すようです。join句にサブクエリを指定するメソッドがjoinSub()なので、from句ならfromSubというわけですね。

まとめ

クエリビルダでサブクエリを指定するには以下のいずれかの方法で実現できます。

// tableメソッドで指定
DB::table($subQuery, $as)->...;

// fromメソッドで指定
DB::query()->from($subQuery, $as)->...;

// fromSubで指定
DB::query()->fromSub($subQuery, $as)->...;

上記の$subQueryは、ClosureでもクエリビルダでもOKです。以下はクエリビルダで指定してみた例です。

$subQuery = DB::table('invoices')
        ->selectRaw('user_id, count(invoice_id) as invoice_count')
        ->groupBy('user_id');

$query = DB::table($subQuery, 'sub')    // エイリアスをsubとしてみました。
    ->selectRaw('invoice_count, count(user_id) as user_count')
    ->groupBy('invoice_count');

$query->toSql();

=> "select invoice_count, count(user_id) as user_count 
    from (
        select user_id, count(invoice_id) as invoice_count 
        from `invoices` group by `user_id`
    ) as `sub`     // as sub になりました。
    group by `invoice_count`"

たまにドキュメントにて網羅されていないメソッドなどがありますが、そんな時は少しソースを覗いてみると良いかもしれませんね。

おまけ、検証データ

実際にデータを入れて手を動かしながら確認してみたい方は以下の手順でデータを用意できます。 Laravel 7.xのインストールにてDBのセットアップまで完了している状態からの手順となります。

Model、migrationファイル、Factoryクラス作成

php artisan make:model Invoice -m -f

invoicesのmigrationファイルを編集します。使用するのはinvoice_idとmember_idのみなので、そちらを追加。

database/migrations/2021_07_28_035716_create_invoices_table.php

/**
 * Run the migrations.
 *
 * @return void
 */
public function up()
{
    Schema::create('invoices', function (Blueprint $table) {
        $table->id('invoice_id');
        $table->integer('user_id')->default(0);
        $table->timestamps();
    });
}
...

DBに反映。

php artisan migrate

Seederで検証用データを作成。今回はinvoicesテーブルしか使わないので、わざわざ専用のSeederクラスを作成せず、DatabaseSeeder.phpのrun()に直接記述しました。

database/seeds/DatabaseSeeder.php

use App\Invoice;
use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     *
     * @return void
     */
    public function run()
    {
        $params = [];

        for ($i=0; $i<100; $i++) {

            // user_id毎に 0~10 のランダムな数の注文レコードを作成する
            for ($j=0; $j < rand(0, 10); $j++) { 
                $params[] = [
                    'user_id' => $i,
                ];
            }
        }

        Invoice::insert($params);
    }
}

ユーザ毎に購入回数をばらつかせたいのでrand()を使用して０から１０の注文レコードを、１００ユーザ分用意するようにしました。また、データの挿入が速く終わるように、以前bulk insertで大量のデータをDBに登録するで紹介した方法を採っています。

seederを実行して、DBにレコードを挿入。

php artisan db:seed

mysql上で登録されたデータを確認してみます。冒頭の、from句のサブクエリが必要なケースとは？で示したクエリを実行してみましょう。

+---------------+------------+
| invoice_count | user_count |
+---------------+------------+
|             1 |         21 |
|             2 |         14 |
|             3 |         21 |
|             4 |         13 |
|             5 |         14 |
|             6 |          4 |
|             7 |          5 |
+---------------+------------+
7 rows in set (0.01 sec)

いい感じにバラけていますね！検証用データの準備は以上です。

DB変更履歴の作成（４）パッケージ

Sun, 07 Jun 2020 04:55:17 +0900

DB変更の履歴の作成をトレイトで簡単にEloquentのモデルに装着できるとしたころまでが前回ですが、巷では似たような仕組みでより良いパッケージがすでにあります。今回はそれを紹介します。

Laravel Auditing

パッケージは、Laravel Auditingという名でララベル専用です。

独自のサイトもあります。

http://www.laravel-auditing.com/

まずはインストール、

$ composer require owen-it/laravel-auditing

次に設定ファイルのパブリッシュ。

$ php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider" --tag="config"

config/audit.phpが作成されます。

DBテーブルの作成が必要なので、以下を実行してmigrationファイルを作成します。

$ php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider" --tag="migrations"

作成されたファイルを見てみましょう。

database/migrations/2020_06_05_152546_create_audits_table.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audits', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('user_type')->nullable();
            $table->unsignedBigInteger('user_id')->nullable();
            $table->string('event');
            $table->morphs('auditable');
            $table->text('old_values')->nullable();
            $table->text('new_values')->nullable();
            $table->text('url')->nullable();
            $table->ipAddress('ip_address')->nullable();
            $table->string('user_agent', 1023)->nullable();
            $table->string('tags')->nullable();
            $table->timestamps();

            $table->index(['user_id', 'user_type']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('audits');
    }
}

これを見ると、作成するDBテーブルの名前はauditsで、 user_type, user_idは、アクセスしたユーザーの情報、 old_valuesとnew_valuesはモデルの古い値と新規の値が入る、 url、ip_address, user_agentはウェブのどこからアクセスされたかの情報、などと検討できますが、その他の項目はどう使われるが興味あるところです。特に、morphs(‘auditable’)の部分はなんでしょう？見たことないですね。

とりあえず、migrateしてテーブルを作成します。

$ php artisan migrate       
Migrating: 2020_06_05_152546_create_audits_table
Migrated:  2020_06_05_152546_create_audits_table (0.04 seconds)

作成されたテーブルの構造を見ると、

mysql> describe audits;
+----------------+---------------------+------+-----+---------+----------------+
| Field          | Type                | Null | Key | Default | Extra          |
+----------------+---------------------+------+-----+---------+----------------+
| id             | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| user_type      | varchar(255)        | YES  |     | NULL    |                |
| user_id        | bigint(20) unsigned | YES  | MUL | NULL    |                |
| event          | varchar(255)        | NO   |     | NULL    |                |
| auditable_type | varchar(255)        | NO   | MUL | NULL    |                |
| auditable_id   | bigint(20) unsigned | NO   |     | NULL    |                |
| old_values     | text                | YES  |     | NULL    |                |
| new_values     | text                | YES  |     | NULL    |                |
| url            | text                | YES  |     | NULL    |                |
| ip_address     | varchar(45)         | YES  |     | NULL    |                |
| user_agent     | varchar(1023)       | YES  |     | NULL    |                |
| tags           | varchar(255)        | YES  |     | NULL    |                |
| created_at     | timestamp           | YES  |     | NULL    |                |
| updated_at     | timestamp           | YES  |     | NULL    |                |
+----------------+---------------------+------+-----+---------+----------------+

$table->morphs(‘auditable’);は、auditable_typeとauditable_idの２つの項目が作成される結果となっていますが、何の値が入るのでしょうね。

モデルでの設定

さて、実際にモデルに設定してみましょう。私の仕組みと同様にトレイト(Auditable)を使用しますが、同じ名前のインターフェース(Auditable)も使われています。以下の「これが必要！」の部分です。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Request;

use OwenIt\Auditing\Contracts\Auditable; // これが必要！

class User extends Authenticatable implements Auditable　// これが必要！
{
    use Notifiable;
    use \OwenIt\Auditing\Auditable; // これが必要！

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    /**
     * ここで監査したい項目を指定！
     *
     * @var array
     */
    protected $auditInclude = [
        'name',
        'email',
    ];

早速、tinkerで実行してみましょう。 tinkerはコンソールの実行なので、設定ファイルを以下のように変更する必要あります。

config/audit.php

...
   /*
    |--------------------------------------------------------------------------
    | Audit Console
    |--------------------------------------------------------------------------
    |
    | Whether console events should be audited (eg. php artisan db:seed).
    |
    */

    'console' => true,
];

Psy Shell v0.10.4 (PHP 7.2.16 — cli) by Justin Hileman
>>> User::truncate(); //　リセットして空にします。
>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3995
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-06-05 17:01:38",
     created_at: "2020-06-05 17:01:38",
     id: 1,
   }
>>> $user->update(['email' => 'test2@example.com']);
=> true
>>> $user->audits; // 作成した監査レコードを取得
=> Illuminate\Database\Eloquent\Collection {#4005
     all: [
       OwenIt\Auditing\Models\Audit {#4021
         id: 1,
         user_type: null,
         user_id: null,
         event: "created",
         auditable_type: "App\User",
         auditable_id: 1,
         old_values: "[]",
         new_values: "{"name":"name1","email":"test1@example.com"}",
         url: "console",
         ip_address: "127.0.0.1",
         user_agent: "Symfony",
         tags: null,
         created_at: "2020-06-05 17:01:38",
         updated_at: "2020-06-05 17:01:38",
       },
       OwenIt\Auditing\Models\Audit {#4026
         id: 2,
         user_type: null,
         user_id: null,
         event: "updated",
         auditable_type: "App\User",
         auditable_id: 1,
         old_values: "{"email":"test1@example.com"}",
         new_values: "{"email":"test2@example.com"}",
         url: "console",
         ip_address: "127.0.0.1",
         user_agent: "Symfony",
         tags: null,
         created_at: "2020-06-05 17:01:43",
         updated_at: "2020-06-05 17:01:43",
       },
     ],
   }

なるほど、

         auditable_type: "App\User",
         auditable_id: 1,

これらの項目には、何のモデルのどのレコードの履歴という情報を残しているのですね。

引き続いて、レコード削除も試みると、

>>> $user->delete();
=> true
>>> DB::table('audits')->get();
=> Illuminate\Support\Collection {#3986
     all: [
       {#4019
         +"id": 1,
         +"user_type": null,
         +"user_id": null,
         +"event": "created",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "[]",
         +"new_values": "{"name":"name1","email":"test1@example.com"}",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:01:38",
         +"updated_at": "2020-06-05 17:01:38",
       },
       {#4025
         +"id": 2,
         +"user_type": null,
         +"user_id": null,
         +"event": "updated",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "{"email":"test1@example.com"}",
         +"new_values": "{"email":"test2@example.com"}",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:01:43",
         +"updated_at": "2020-06-05 17:01:43",
       },
       {#4032
         +"id": 3,
         +"user_type": null,
         +"user_id": null,
         +"event": "deleted",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "{"name":"name1","email":"test2@example.com"}",
         +"new_values": "[]",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:04:27",
         +"updated_at": "2020-06-05 17:04:27",
       },
     ],
   }

削除されたレコードゆえにUser::find()では取得できないので、クエリビルダーで取得しましたが、３番目のauditsのレコードが作成されていること確認できます。また、eventの項目に注目してもらうと、created, updated, deletedという値が入っていることも確認できます。

今回はここまでですが、他にもタグを追加できる機能や、古いレコードを自動的に削除する機能など将来紹介したい機能がたくさんあります。また、クラス定義のインターフェイス、つまり、implementsや、よく知らないmorphsのトピックも将来扱いたいです。

DB変更履歴の作成（３）トレイト

Sun, 31 May 2020 01:34:51 +0900

前回のDB変更履歴保存のメカニズムは、Userのモデルのためだけですが、どのモデルでも同様なことが簡単にできるようにトレイトを作成してみます。

まず、audit_logsのテーブルを作成し直します。

どのモデルかわかるように項目を増やしました。前回、Userモデルのキーという意味でuser_idとしたところは、使用した会員のidの値が入るように変更しました。そして、モデルのキーは、model_keyという項目となっています。

database/migrations/2020_05_28_171205_create_audit_logs_table.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditLogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audit_logs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('route')->nullable(); // 実行したプログラムのルート
            $table->string('path')->nullable(); // 実行したプログラムのパス名
            $table->string('model')->nullable; // モデルのクラス名
            $table->unsignedBigInteger('model_key')->nullable(); // モデルのプライマリキー
            $table->unsignedBigInteger('user_id')->nullable(); // ユーザーのid
            $table->longText('old_value')->nullable(); // 変更前の値
            $table->longText('new_value')->nullable(); // 変更後の値
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('audit_logs');
    }
}

次に、トレイトを作成します。

前回、boot()の関数名が、bootAuditTrait()と、‘boot’ + ‘AuditTrait’（トレイト名）となっていることに注意してください。

app/AuditTrait

namespace App;

use Request;
use Route;

trait AuditTrait
{
	/**
	 * Bootイベント
	 *
	 * 関数名は、boot()でなく'boot' + トレイト名
	 *
	 * @return void
	 */
	public static function bootAuditTrait()
	{
	    // parent::boot()はコールしない

        static::created(function ($model) {
            $model->addAuditLog('created');
        });

        static::updated(function ($model) {
            $model->addAuditLog('updated');
        });

        static::deleted(function ($model) {
            $model->addAuditLog('deleted');
        });
	}

    public function addAuditLog($event)
    {
        $route = optional(Route::getCurrentRoute())->getName();
        $path = Request::path();
        $model = get_class($this);
        $model_key = $this->id;
        $user_id = optional(auth()->user())->id;

        $old_value = $new_value = null;

        if (in_array($event, ['created', 'updated'])) {
            $new_value = serialize($this->attributes);
        }

        if (in_array($event, ['updated', 'deleted'])) {
            $old_value = serialize($this->original);
        }

        AuditLog::create([
            'route'      => $route,
            'path'       => $path,
            'model'      => $model,
            'model_key'  => $model_key,
            'user_id'    => $user_id,
            'old_value'  => $old_value,
            'new_value'  => $new_value,
        ]);
    }
}

上のトレイトにより、Userのクラスでは、use AuditTraittの１行の追加だけで済みます。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Request;

class User extends Authenticatable
{
    use Notifiable;
    use AuditTrait;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];
}

さて、tinkerの出番です。変更をテストみましょう。

Psy Shell v0.10.4 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\AuditLog;

>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3990
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-05-28 18:36:06",
     created_at: "2020-05-28 18:36:06",
     id: 1,
   }

>>> $user->update(['email' => 'test2@example.com']);
=> true

>>> $user->delete();
=> true

>>> AuditLog::all();
=> Illuminate\Database\Eloquent\Collection {#4015
     all: [
       App\AuditLog {#4016
         id: 1,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: null,
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:06";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         created_at: "2020-05-28 18:36:06",
         updated_at: "2020-05-28 18:36:06",
       },
       App\AuditLog {#4017
         id: 2,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:06";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:10";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         created_at: "2020-05-28 18:36:10",
         updated_at: "2020-05-28 18:36:10",
       },
       App\AuditLog {#4018
         id: 3,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:10";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         new_value: null,
         created_at: "2020-05-28 18:36:14",
         updated_at: "2020-05-28 18:36:14",
       },
     ],
   }
>>>

前回と同様に、レコードの作成、編集、削除のすべてが、audit_logsのレコードに記録されています。

DB変更履歴の作成（２）監査のデータを保存

Sun, 24 May 2020 03:33:06 +0900

前回においては、Eloquentのbootメソッドを利用してDB変更の情報（監査の情報）を取得することができました。今回は、これをDBに記録する部分を考えてみましょう。

監査のデータを保存するテーブル

監査のデータを保存するテーブルを、audit_logsとしてmigrationファイルを作成します。

$ php artisan make:migration create_audit_logs_table  
Created Migration: 2020_05_20_024714_create_audit_logs_table

作成されたファイルを編集して、テーブルの項目定義を入れます。

database/migrations/2020_05_20_024714_create_audit_logs_table

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditLogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audit_logs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->unsignedBigInteger('user_id')->default(0)->index(); // Userモデルのid
            $table->string('path')->default(''); // 実行したプログラムのパス名
            $table->longText('old_value')->nullable(); // 変更前の値
            $table->longText('new_value')->nullable(); // 変更後の値
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('audit_logs');
    }

old_valueとnew_valueには、レコードの項目のすべての値をserializeして入れるために大きいデータタイプとしています。

以下を実行してテーブルを作成します。

$ php artisan migrate
Migrating: 2020_05_20_024714_create_audit_logs_table
Migrated:  2020_05_20_024714_create_audit_logs_table (0.02 seconds)

AuditLogのクラスも作成します。

app/AuditLog

namespace App;

use Illuminate\Database\Eloquent\Model;

class AuditLog extends Model
{
    protected $guarded = [];
}

そして、Userクラスのプログラムを書き替えます。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

use Request;

class User extends Authenticatable
{
    use Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    protected static function boot()
    {
        parent::boot();

        static::created(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => null,
                'new_value'  => serialize($model->attributes),
            ]);
        });

        static::updated(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => serialize($model->original),
                'new_value'  => serialize($model->attributes),
            ]);
        });

        static::deleted(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => serialize($model->original),
                'new_value'  => null,
            ]);
        });
    }
}

tinkerでレコードの作成、Eメールアドレスの変更、そしてレコードの削除を実行します。

Psy Shell v0.10.2 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\AuditLog;
>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3058
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-05-20 03:28:18",
     created_at: "2020-05-20 03:28:18",
     id: 1,
   }
>>> $user->update(['email' => 'test2@example.com']);
=> true
>>> $user->delete();
=> true

AuditLogのレコードを取り出してみると、すべてのの変更履歴、監査の情報が保存されています。

>>> AuditLog::all();
=> Illuminate\Database\Eloquent\Collection {#3072
     all: [
       App\AuditLog {#3073
         id: 1,
         user_id: 1,
         path: "/",
         old_value: null,
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:18";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         created_at: "2020-05-20 03:28:18",
         updated_at: "2020-05-20 03:28:18",
       },
       App\AuditLog {#3074
         id: 2,
         user_id: 1,
         path: "/",
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:18";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:38";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         created_at: "2020-05-20 03:28:38",
         updated_at: "2020-05-20 03:28:38",
       },
       App\AuditLog {#3075
         id: 3,
         user_id: 1,
         path: "/",
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:38";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         new_value: null,
         created_at: "2020-05-20 03:28:47",
         updated_at: "2020-05-20 03:28:47",
       },
     ],
   }

DBの変更履歴の作成

Mon, 18 May 2020 11:58:18 +0900

データベースに保存されているデータはいつも現時点での値であり、過去の値は保存されていません。しかし、レコードのデータがどう変更したかという情報は重要です。どう変更したかだけではなく、誰がいつ、アプリのどの機能を使用して、さらにはどういう理由で、という情報も必要になってきます。例えば、カスタマサポートにおいて、会員の住所が変更されて注文した商品が届かなかったとき、それらの情報があれば、いついつにお客様が住所を変更しましたね、とか即答できます。さて、これらの変更イベント時の変更情報（監査あるいはAudit情報）、Laravelではどのように効率的にDBに保存することが可能でしょうか？

Eloquentのイベントメソッド

LaravelのEloquentを利用すると、DBのイベント、つまりレコードの作成、変更、削除の３つのイベントに連結したメソッドが提供されています。そして、それらのイベントが発生する前あるいは後においてユーザー定義のコードをコールバックさせることが可能です。これらを利用したら、希望するAuditの情報をキャプチャすることが簡単にできます。

さてLaravelのデフォルトのプロジェクトを使って見てみましょう。まず、UserのクラスにDBのレコード変更後のイベントのコールバックを作成します。以下のようにbootメソッドにおいて見慣れないクラスメソッドupdatedをコールすることで可能となります。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
...
    protected static function boot()
    {
        parent::boot();

        static::updated(function () {
            echo "updated\n";
        });
    }
}

ちなみに、updatedは更新後にコールされるものですが、新規作成後は、created、削除後はdeletedというメソッドになります。

tinkerを使用して実行してみます。

>>> $user = User::find(1);
=> App\User {#3048
     id: 1,
     name: "近藤 篤司",
     email: "manabu.takahashi@example.net",
     email_verified_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     updated_at: "2020-05-17 18:31:32",
   }
>>> $user->update(['email' => 'test@example.com']);
updated
=> true

コールバックで定義したupdatedが表示されましたね！

変更前後の情報の取得

DBのレコード変更イベントでユーザー定義の関数をコールバックを確認できたら、次は変更前後でのレコードの情報をどうやって取得するかです。以下見てください。コールバックにそれらの情報を表示するコードを追加しました。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
...
    protected static function boot()
    {
        parent::boot();

        static::updated(function ($model) {
            echo "updated\n";
            print_r($model->original);
            print_r($model->attributes);
        });
    }
}

tinkerで実行してみます。

>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3067
     id: 1,
     name: "近藤 篤司",
     email: "test@example.com",
     email_verified_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     updated_at: "2020-05-17 18:59:31",
   }
>>> $user->update(['email' => 'test2@example.com']);
updated
Array
(
    [id] => 1
    [name] => 近藤 篤司
    [email] => test@example.com
    [email_verified_at] => 2020-02-13 04:27:15
    [password] => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
    [remember_token] => cDvZkS5nOA
    [created_at] => 2020-02-13 04:27:15
    [updated_at] => 2020-05-17 18:59:31
)
Array
(
    [id] => 1
    [name] => 近藤 篤司
    [email] => test2@example.com
    [email_verified_at] => 2020-02-13 04:27:15
    [password] => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
    [remember_token] => cDvZkS5nOA
    [created_at] => 2020-02-13 04:27:15
    [updated_at] => 2020-05-17 19:03:27
)
=> true

前後の値、キャプチャできましたね。これで変更履歴を作成するには十分な準備ができました。これらを利用すれば、変更前後の値あるいは差分を保存できますね。

DBの負荷の緩和（3）コントローラにより接続を変える

Sun, 26 Apr 2020 01:28:18 +0900

マスターDBの変更が複製DBに反映されるまでの時間差を考えると、サイトの特定のページでは複製DBのアクセスを使用したくないかもしれません。例えば、会員のログインなど会員のアカウントの情報に関わるページとか、Eコマースのチェックアウトのページとか、あるいは管理者のみがアクセスする管理ページとか。そうなると、特定のコントローラだけに複製DBコネクションを限定するにはどのようにすればよいのでしょう？

まず、マスターDBのみのDBコネクションをmysqlとして、複製DBを使用するDBコネクションをmysql_rwとして、config/database.phpで２つのコネクションを設定します。

config/database.php

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => 'Asia/Tokyo',
        ],

        'mysql_rw' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'read' => [
                'host' => env('DB_HOST_RO', env('DB_HOST', '127.0.0.1')),
                'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
                'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
            ],
            'write' => [
                'host' => env('DB_HOST', '127.0.0.1'),
                'username' => env('DB_USERNAME', 'forge'),
                'password' => env('DB_PASSWORD', ''),
            ],
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE'),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => 'Asia/Tokyo',
        ],
..

.envのファイルでは、DB_HOST_RO, DB_USERNAME_RO, DB_PASSWORD_ROの設定項目の指定が必要となります。 ROはRead Onlyという意味で読み込み専用のユーザーが複製DBにアクセスします。

また、デフォルトは、マスターDBのコネクションであることに注意してください。

次に、例えば、商品閲覧ページにおいてDBコネクションを変えるには、以下のように、コントローラのコンストラクタにおいて、コネクションのデフォルトを上書きしてDB::reconnect()で接続します。

app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

class ProductController extends Controller
{
    public function __construct()
    {
        parent::__construct();

        config(['database.default' => 'mysql_rw']);
        DB::reconnect();
..

簡単ですね。

いちいち、それぞれのコンストラクタでコネクションを変えるのが面倒なら、以下のよう親のコントローラにおいてまとめて指定することも可能です。試してはいないですが、ミドルウェアでの対応も可能なはずです。

app/Http/Controllers/Controller.php

    public function __construct()
    {
        $route = Route::currentRouteName();

        // 特定のページだけDBコネクションを変更する
        $routes = [
            'user.home',
            'user.page',
            'user.shop',
            'user.category',
            'user.collection',
            'user.product',
        ];

        if (in_array($route, $routes)) {
            config(['database.default' => 'mysql_rw']);
            DB::reconnect();
        }
...

DBの負荷の緩和

Mon, 13 Apr 2020 04:47:24 +0900

お客さんのサイトのアクセスが最近10倍以上に増えてきました。ロードバランスもなく1台にウェブもDBもメールサーバーもあるAWSの仮想マシンなので、とりあえず、仮想マシンをアップグレードしました。

しかし、アップグレードしてもDBのトランザクションでデッドロックが起きるなどの問題が起こります。これはDBやOSのカーネルの調整が必要となるか、それともやはり、ロードバランスが必要なときか、しかしそんな専門的知識もないしそれを学習や試験する時間も必要だし。。。と悩んでいるときに、DBの読み書きでDB接続を自動的に使い分ける機能がLaravelにあることを見つけました。

DBの複製は、MySQLデータベースのレプリカにAWS RDSを利用で、すでに設定してあり、これをDBの読み込み専用に使います。書き込みは本マシンのマスターのDBを使います。

さて、Laravel側で変更することは以下のDB設定の変更です。まず、新規にmysql_rwなる接続を定義します。

config/database.php

...
        'mysql_rw' => [
            'write' => [ // 書き込み
              'host' => '127.0.0.1'
            ],
            'read' => [  // 読み込み専用、複製DB
              'host' => '127.0.0.2' // RDSのendpointのURLあるいはプライベートIPアドレス
            ],
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

上の例では、複製のDBのユーザーとパスワードはマスターのDBのユーザーと同じという仮定ですが、違うなら以下のようにも指定できます。

    'write' => [
        'host' => '127.0.0.1',
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
    ],
    'read' => [
        'host' => '127.0.0.2',
        'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
        'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
    ],

さらに、複製DBが1つでは足りないときは、複数の設定も可能です。

    'read' => [
        'host' => ['127.0.0.2', '127.0.0.3', '127.0.0.4'], 
        'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
        'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
    ],

最後に、.envを編集して、

...
DB_CONNECTION=mysql_rw
...

とDB接続を変更します。

レプリカで気づいたタイムゾーンの問題

Sun, 30 Dec 2018 05:11:06 +0900

またまた、前回に引き続きMySQLのレプリカの話です。しかし、今回はLaravelの設定も関係してきます。

timestampのデータが非同期している

MySQLのデータタイプの１つに、timestampがあります。通常はレコードの作成や更新の日時の記録に使います。Laravelでは、Modelのクラスにおいて、デフォルトでcreated_atとupdated_atの項目がtimestampのデータタイプです。それらの項目が対応するDBテーブルにあるなら、

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    public $timestamps = true; //デフォルト設定なので、この行は要らなくともよい
...

と設定しておけば、保存時にいちいち値をセットしなくとも自動にLaravelが面倒見てくれます。

しかし、レプリカの複製を使い始めて気づいたのは、timestampの項目のデータがマスターとレプリカが同期していないことです。

まず、マスターでtinkerを使用してレコードを更新します。

Psy Shell v0.9.3 (PHP 7.1.23 — cli) by Justin Hileman
>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2309
     id: 1,
     name: "山田太郎",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-11-08 05:05:24",
   }
>>> $user->update(['name' => 'John Doe']);
=> true
>>> $user = User::find(1);
=> App\User {#2314
     id: 1,
     name: "John Doe",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-12-30 03:28:42",
   }

nameとupdated_atが変更されていますね。ここで、pt-table-checksumを実行すると、usersのテーブルでマスターとレプリカで値が異なることが報告されるのです。

Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
12-30T03:30:31      0      0        2          0       1       0   1.020 larajapan.migrations
12-30T03:30:31      0      0        1          0       1       0   0.021 larajapan.password_resets
12-30T03:30:31      0      1        5          0       1       0   0.017 larajapan.users

謎です。

謎をひも解く

いろいろと探ってみると、知っておくべきなのに知らなかったことがぽろぽろと出てきました。

まず、知らなかったこと、その１として、

timestampのデータタイプの項目では、値が入るとUTCの時間に変更されて保存される。

例えば、MySQLのセッションが日本のタイムゾーンなら、

created_atの項目に、2018-12-30 03:00:00と入れれば、2018-12-29 18:00:00とＤＢに保存されます。日本のタイムゾーンは、UTCより9時間先です（この時間差を理解するには、このサイト https://www.worldtimebuddy.com/japan-tokyo-to-utcチェックしてみてください）。

そして、SELECTでこの値を引き出すときは、そのときのセッションのタイムゾーンに変換してMySQLは出力します。つまり、同じ時間を世界のどのタイムゾーンに合わせて表示が可能なわけです。

次に、知らなかったこと、その2は、

MySQLのセッションのタイムゾーンは、DBを使用するアプリで指定していないなら、アプリをホストするサーバーの設定となる。

使用しているサーバーはAWSのEC2で、そこでインストールしたMySQLのサーバーでは、特別に設定しない限り、SYSTEMつまりサーバーのシステムのタイムゾーンの設定となります。

マスターのタイムゾーンをチェックしてみると、

mysql>  SELECT @@SESSION.time_zone, @@GLOBAL.system_time_zone;
+---------------------+---------------------------+
| @@SESSION.time_zone | @@GLOBAL.system_time_zone |
+---------------------+---------------------------+
| SYSTEM              | JST                       |
+---------------------+---------------------------+

で、このSYSTEMはマシンのOSが設定するタイムゾーンJST(Japan Standard Time)になります。

さて、AWS RDSのレプリカの方は、

mysql>  SELECT @@SESSION.time_zone, @@GLOBAL.system_time_zone;
+---------------------+---------------------------+
| @@SESSION.time_zone | @@GLOBAL.system_time_zone |
+---------------------+---------------------------+
| UTC                 | UTC                       |
+---------------------+---------------------------+

もしかして、この違いが問題？

実際どんなログがレプリカで受け取られているのでしょう。MySQLが作成しているログファイルを読んでみましょう。

ログを読むには、mysqlbinlogを使用します。

$ mysqlbinlog --no-defaults -v mysql-bin.000004

この出力から、先ほどのtinkerで実行したSQLを探します。

...
# at 35339
#181230  3:28:42 server id 1  end_log_pos 35420     Query   thread_id=492197    exec_time=0 error_code=0
SET TIMESTAMP=1546108122/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=224,@@session.collation_connection=224,@@session.collation_server=8/*!*/;
SET @@session.time_zone='SYSTEM'/*!*/;
BEGIN
/*!*/;
# at 35420
#181230  3:28:42 server id 1  end_log_pos 35587     Query   thread_id=492197    exec_time=0 error_code=0
SET TIMESTAMP=1546108122/*!*/;
update `users` set `name` = 'John Doe', `updated_at` = '2018-12-30 03:28:42' where `id` = 1
/*!*/;
...

updateのSQL文ありましたね！そして、その前に実行されている、SET @@session.time_zone=‘SYSTEM’は、タイムゾーンをSYSTEMと設定しています。つまり、レプリカがこのログを受け取り実行するときに、タイムゾーンをSYSTEMとセットしてからレプリカのレコードを更新します。しかし、レプリカにとってはSYSTEMはマスターと違って、JSTではなくUTCです。日本時間をUTCに変更することなく更新しているのです。それゆえに、pt-table-checksumの実行では非同期となるわけです。

非同期の解決方法

非同期の理由がわかったら、この非同期を解決するのは簡単です。マスターにおいて、タイムゾーンをSYSTEMではなく、Asia/Tokyoを使うようにすればよいだけです（私の環境では、MySQLではJSTの設定ではエラーとなりました。多分にJSTはOSが返す値？）。

サーバーでのアプリがすべて日本時間帯なら、/etc/my.cnfで設定可能です。しかし、my.cnfが編集できない共有ホストの環境、あるいは同じサーバーに違うタイムゾーン向けのアプリがあるなら、使用するアプリでの設定がベストです。

Laravelのプロジェクトでの設定は簡単で、config/database.phpで以下のようにtimezoneの行を追加します。

config/database.php

...
    'connections' => [
        'mysql' => [
            'driver' => 'mysql',
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'strict' => true,
            'engine' => null,
            'timezone' => 'Asia/Tokyo'
        ],
...

tinkerで確認して、前回非同期となったレコードを再度更新します。

Psy Shell v0.9.3 (PHP 7.1.23 — cli) by Justin Hileman
>>> DB::select(DB::raw("SELECT @@SESSION.time_zone, @@GLOBAL.system_time_zone"));
=> [
     {#2316
       +"@@SESSION.time_zone": "Asia/Tokyo",
       +"@@GLOBAL.system_time_zone": "JST",
     },
   ]
>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2307
     id: 1,
     name: "John Doe",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-12-30 03:28:42",
   }
>>> $user->update(['name' => 'Tarou Yamada']);
=> true
>>> $user = User::find(1);
=> App\User {#2309
     id: 1,
     name: "Tarou Yamada",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-12-30 04:50:48",
   }

pt-table-checksumを実行すると、結果は、差分なし！

Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
12-30T04:51:09      0      0        2          0       1       0   0.019 larajapan.migrations
12-30T04:51:09      0      0        1          0       1       0   0.017 larajapan.password_resets
12-30T04:51:09      0      0        5          0       1       0   0.017 larajapan.users

最後に、MySQLのログを見てみます。タイムゾーンは、正しくAsia/Tokyoの設定となっていますね。

# at 38550
#181230  4:50:48 server id 1  end_log_pos 38635     Query   thread_id=492757    exec_time=0 error_code=0
SET TIMESTAMP=1546113048/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=224,@@session.collation_connection=224,@@session.collation_server=8/*!*/;
SET @@session.time_zone='Asia/Tokyo'/*!*/;
BEGIN
/*!*/;
# at 38635
#181230  4:50:48 server id 1  end_log_pos 38810     Query   thread_id=492757    exec_time=0 error_code=0
SET TIMESTAMP=1546113048/*!*/;
update `users` set `name` = 'Tarou Yamada', `updated_at` = '2018-12-30 04:50:48' where `id` = 1
/*!*/;

MySQLレプリカの同期チェック

Sat, 10 Nov 2018 01:56:48 +0900

今回は以前話した、MySQLデータベースのレプリカの話の続きです。

前回はデータベースのレプリカの説明をしましたが、本当にマスターのデータベースと同期しているの？とすぐに疑います。チェックしてみましょう！

調べると、checksum tableというMySQLコマンドが使えるらしい。チェックサムはある計算式をデータに適用してユニークな数を出力するものです。

mysql> use larajapan;
Database changed
mysql> checksum table migrations, password_resets, users;
+---------------------------+------------+
| Table                     | Checksum   |
+---------------------------+------------+
| larajapan.migrations      |  269719583 |
| larajapan.password_resets | 3233767743 |
| larajapan.users           |  669472749 |
+---------------------------+------------+
3 rows in set (0.00 sec)

実行してみるとかなりな速さで結果を出してくれます。私のテストでは500万レコード数もあるテーブルでたったの16秒！

これを、マスターとそのレプリカで、すべてのテーブルに対して実行して比較すれば良いですね。しかし、実際に使用されているDBでは、常に新しいレコードは追加される、更新はある。。。と考えると、ある1時点で両者のデータを比較するのは複雑な作業に見えてきます。

そこで見つけたのが、perconaのツール。perconaはかなり昔からMySQLなどのオープンソースのデータベースの管理をサービスとしている会社です。

準備

AWS EC2では、以下でインストールできます。

$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm

たくさんのツール（perlで書かれている）がインストールされますが、今回必要なツールはマスターとレプリカのデータの同期をチェックする以下のコマンドです。

pt-table-checksum

しかし、このツール、オプションがたくさんあり、ある程度の準備も要る複雑なツールです。私も理解まで何回も何回も試行しました。特に、マスターのDBとレプリカのDBで、MySQLのユーザー名やパスワードが違うとその指定のためにコマンドラインが長くなり、実行にはスクリプトの作成をした方が良いです。

ちなみに、今回は、以前と同様に、マスターはEC2でのMySQL、レプリカは、AWSのRDSのMySQLという仮定です。もちろんレプリカのサーバーにはsshできないので、マスターで実行します。

準備として、以下のMySQLの情報を用意してください。

マスターのユーザー名マスターのパスワードレプリカのユーザー名レプリカのパスワード

マスターやレプリカのMySQLユーザーは以下の権限が必要ですが、以下のように特別に作成しなくとも、通常はrootのような管理権限のあるユーザーで足ります。

mysql> GRANT SELECT ON larajapan.* TO 'checksum_user'@'%' IDENTIFIED BY 'checksum_password';
mysql> GRANT REPLICATION SLAVE,PROCESS,SUPER ON *.* TO `checksum_user`@'%';
mysql> GRANT ALL PRIVILEGES ON percona.* TO `checksum_user`@'%';

次に、ツールが出力するデータを保存するためのデータベース（percona）とテーブル（checksums）を作成します。

mysql> create databaser percona;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'databaser percona' at line 1
mysql> create database percona;
Query OK, 1 row affected (0.00 sec)

mysql> use percona
Database changed
mysql> CREATE TABLE checksums ( db CHAR(64) NOT NULL, tbl CHAR(64) NOT NULL, chunk INT NOT NULL, chunk_time FLOAT NULL, chunk_index VARCHAR(200) NULL, lower_boundary TEXT NULL, upper_boundary TEXT NULL, this_crc CHAR(40) NOT NULL, this_cnt INT NOT NULL, master_crc CHAR(40) NULL, master_cnt INT NULL, ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (db, tbl, chunk), INDEX ts_db_tbl (ts, db, tbl) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.01 sec)

マスターとレプリカの両方で作成が必要ですが、ツールの最初の実行でマスターでは自動的に作成されます。

実行

ここで、まず実行してみましょう。運が良ければここで以下のような出力となります。

$ pt-table-checksum -d larajapan -u checksum_user -p checksum_password --recursion-method processlist --no-check-binlog-format --no-check-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
11-09T07:54:37      0      0        2          0       1       0   1.019 larajapan.migrations
11-09T07:54:37      0      0        1          0       1       0   0.017 larajapan.password_resets
11-09T07:54:37      0      0        5          0       1       0   0.014 larajapan.users

ERRORSとDIFFSの列、これが皆ゼロならマスターとレプリカは同期しています。心配なしです。

さて、どうしてレプリカのホスト情報をコマンドラインに入れていないのにレプリカのチェックが可能なのでしょう？

それは、–recursion-method processlistの部分です（デフォルトでは、ここはprocesslist, hostsとなるのですが、私のトライではhostsの部分でエラーになりました)。

MySQLのshow processlistコマンドを実行すると、

mysql> show processlist;
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
| Id  | User       | Host                                          | db           | Command     | Time  | State                                                                 | Info             |
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
|   2 | slave_user | ip-10-0-1-32.us-west-2.compute.internal:64617 | NULL         | Binlog Dump | 14651 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
| 918 | root       | localhost                                     | NULL         | Query       |     0 | NULL                                                                  | show processlist |
| 919 | root       | localhost                                     | larajapan_wp | Sleep       |     0 |                                                                       | NULL             |
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

レプリカのホスト情報が出て来るのでそれを利用しているのです。

また、ここでは、レプリカでのMySQLのユーザー名とパスワードは、マスターと同じと仮定しています。これが違うなら、

–slave-user admin –slave-password pass

の指定がコマンドラインで必要となります。

本当にチェックしている？

ひとまず成功したところで、本当に差分を出してくれるか興味あるところです。レプリカにおいて、情報変えてみましょう。

mysql> delete from users where id = 6;
Query OK, 1 row affected (0.01 sec)

レプリカのusersのテーブルのレコードを１つ削除しました。

そして再度実行です。

$ pt-table-checksum -d larajapan -u checksum_user -p checksum_password --recursion-method processlist --no-check-binlog-format --no-check-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
11-09T08:18:43      0      0        2          0       1       0   0.021 larajapan.migrations
11-09T08:18:43      0      0        1          0       1       0   0.017 larajapan.password_resets
11-09T08:18:43      0      1        5          0       1       0   0.019 larajapan.users

チェックしてくれましたね。DIFFSに1が表示されているのがそうです。

デバッグ

このコマンドラインでは、本当にたくさんのオプションがあるのでいろいろなチェックが可能なのですが、エラーが理解不可能なときは、以下のようにデバッグモードを使ってみるのが良いです。stderrに情報がたくさん出力されるので以下のようにファイルにキャプチャする必要あります。

$ PTDEBUG=1pt-table-checksum > FILE 2>&1

また、オプションのデフォルトも把握することも大事です。

$ pt-table-checksum --help

の実行でデフォルトの情報が得られます。

重複回避 - DB重複エラーを利用

Mon, 14 Sep 2015 02:46:41 +0900

前回においては入力バリデーションでの重複回避を紹介しました。

小規模なサイトではこれだけで重複回避は十分かもしれません。しかし、以下の状況では、どうなるでしょう？

ユーザーAさんとBさんがいたとして、どちらも、ほとんど同時にtest@gmail.comのログインで登録を試みます。もちろんそんなことは滅多に起こらないのですが、たまたまBさんは間違って自分のEメールアドレスをAさんと同じものとタイプしたとします。それから、test@gmail.comでの会員はまだDBには存在しないという仮定です。

Aさんは、

10時20分00秒：入力完了して送信（登録ボタンを押す） 10時20分05秒：入力バリデーション無事通過！ 10時20分15秒：無事にDBに登録成功！

Bさんも、５秒遅れて、

10時20分05秒：入力完了して送信（登録ボタンを押す） 10時20分10秒：入力バリデーション無事通過！　

（もちろん実際はこんなに遅く物事は進行しませんが、経過を理解してもらうために）

あれあれ、まだAさんのレコードはDBにないから、入力バリデーション効きませんね。

このままだと重複のレコードになってしまいますね。どうしましょう？

通常、会員の登録のDBテーブルでは、同じID、ここではEメールの重複はないよ、ということで、プライマリーキーあるいはユニークキーというものを設定します。

例えば、以下はmysqlでのDB設定ですが、「Unique Key member_unique (`email)」がDBに重複のレコードが作成されるのを防ぎます。

CREATE TABLE `member` (
  `member_id` int(11) NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `email` varchar(100) NOT NULL DEFAULT '',
  `password` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`member_id`),
  UNIQUE KEY `member_unique` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

このDBの設定のおかげで、

10時20分15秒：DBの重複エラーとなり、Bさんのレコードは作成されず重複のレコードの作成は回避されます。

ここの部分、プログラムでは前回の入力バリデーションと合わせて以下のようになります。

public function postSignup(Request $request)
{
    $rules = [
      'email'      => 'required|email|unique:member,email',
      'password'   => 'required|min:6|max:20|confirmed',
      'first_name' => 'required',
      'last_name'  => 'required'
    ];

    $messages = [
      'email.unique' => "Eメールアドレスはすでに使用されています"
    ];

    $this->validate($request, $rules, $messages);

    try 
    {
      $member = Member::create($request->all());
    }
    catch(IlluminateDatabaseQueryException $e)
    {
      $errorCode = $e->errorInfo[1];

      if($errorCode == 1062) //重複エラーをここでキャッチ
      {
        return back()->withInput()->withErrors(['email' => "Eメールアドレスはすでに使用されています"]);
      }
    }

　　return "登録完了";
}

これで重複は完全に回避されます。

これなら、入力バリデーションの重複はチェックはもう要らないのでは？

それを削除をしてもOKと思います。しかし、ルールの記述としてプログラムに残るのは良いかもしれません。将来はDBレベルの重複エラーもフレームワークが面倒みてくれるかもしれません。