DynamoDBとの接続でlaravel-dynamodbを使ってみた感想

DynamoDBとの接続でlaravel-dynamodbを使ってみた感想

laravel-dynamodについて簡単にまとめます。

個人的な感想でしかありませんが、私はこの様に感じました。
laravelがバックエンドの本番環境で実装するならAWS-SDK-for-PHPか AWS-SDK-for-JavaScriptの2択だと思います。

Laravel-dynamodbのスゴイところ

最初のハードルはテーブルを作成するところになります。
テーブルを作成してしまった後は、正直言ってもうLaravelEloquentです。
それくらい抵抗なく抽出文を記載できます。

App\Models\Movie::where('search_key', '1')
    ->where('date', 'between', ['2017-01-01', '2018-01-01'])
    ->toDynamoDbQuery()

これですから。Eloquent likeでしょ。
入口としては入りやすいですが、それ故に　「noSQLってなんだったっけ　？」　と思ってしまうところもあります。

aws-sdk-for-phpだとこんな感じで書く様です。（抽出条件の内容は異なります。）

$search_key = 1;
$jsonStr = '{'.'":search_key":'.'"'.$search_key.'"'.'}';
$eav = $this->marshaler->marshalJson($jsonStr);

$params = [
    'TableName' => $tableName,
    'KeyConditionExpression' => '#id = :search_key',
    'ExpressionAttributeNames'=> [ '#id' => 'device_id' ],
    'Limit' => 1,
    'ScanIndexForward' => false,
    'ExpressionAttributeValues'=> $eav,
];

比べるとよく分かりますよね、圧倒的な書きやすさが。

Laravel-dynamodbのツライところ

今回の環境では、SES先の社長より「これでいいんじゃね？」とlaravel-dynamodbをプッシュされて居た事もありコイツいで行くつもりでした。が、テスト用のAWS上のDynamoDBにアクセスしてみて「？？？」と思うコードが点在していました。

その結果として、この様な判断に至り、AWS-SDKでの開発が確定しました。

Laravel-dynamodbで散見した課題

私がGitHubから最初のコードを取得したのも問題だと思います。
このコードの中には、configなどにハードコートされたパートが複数ありました。
結果として「.envを修正したのに何も変わらない」という状況を引き起こし「バグが出た時に探すコストが大変」との判断が降りました。

具体的にはこんなところです。

■.env.php

以上略

##############################################
# AWS-SDK の設定
##############################################

AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=secretkey
AWS_DEFAULT_REGION=ap-northeast-1
AWS_DEFAULT_REGION=localhost:8000
AWS_REGION=localhost:8000
AWS_BUCKET=

##############################################
# DynamoDB の設定
##############################################

DYNAMODB_CONNECTION=local
DYNAMODB_REGION=localhost:8000
DYNAMODB_KEY=accesskey
DYNAMODB_SECRET=secretkey
DYNAMODB_DEBUG=true
DYNAMODB_LOCAL_ENDPOINT=http://dynamodb:8000 #<=Local限定だがエンドポイントを指定

以下略

■config/aws.php

    'credentials' => [
        'key'    => env('AWS_ACCESS_KEY_ID'),
        'secret' => env('AWS_SECRET_ACCESS_KEY'),
    ],
    'region' => env('AWS_REGION'),
    'endpoint' => 'http://dynamodb:8000', #<=固定値になっている
    'version' => 'latest',
    'ua_append' => [
        'L5MOD/' . AwsServiceProvider::VERSION,
    ],

■docker-compose.yml

  dynamodbadmin:
    image: instructure/dynamo-local-admin
    ports:
      - "8001:8001"
    environment:
      DYNAMO_ENDPOINT: http://dynamodb:8000/ #<=固定値になっている
      AWS_ACCESS_KEY_ID: accesskey
      AWS_SECRET_ACCESS_KEY: secretkey
      AWS_DEFAULT_REGION: localhost:8000
      AWS_REGION: localhost:8000

１箇所修正しても他がハードコートされているので動かない。
「完全に動かない」ならまだ良いが、「まれに動かない」となった場合には問題箇所の確認作業にコストと時間がかかる可能性がある。
=> 本番環境の構築について、あえて選ぶ必要はない。

まとめ

dynamodb-localを利用した環境をあっという間に構築でき、ORMで簡単に記載ができる。
入口としてはもう最高のツールだと思います。

課題は実際に運用するとなるとどう判断するかに尽きます。
今回参画しているプロジェクトでは私から「やめましょう」と伝えました。

そもそも、バックエンドがDynamoDBに直接繋いでやりとりするメリットって固定な4つのカラムで検索するくらいしかありません。
Lamdba使っていじったデータをAPIで受け取った方が遥かに効率が良いと思います。
事情によりLambdaの利用ができない場合の代替手段程度に思っていれば、まぁそこそこ使える道具。

それがlaravel-dynamodbの立場だと思います。超絶書きやすいんですけどね。