TypeScript で DynamoDB を触るときに気をつけること

TypeScript で DynamoDB を触るときに気をつけること

TypeScript で実装されているとあるサーバーサイドの要件を実現するためにハマった内容を共有いたします。2025年一発目の記事です…。
2025.11.18

こんにちは、高崎@アノテーション です。

はじめに

我々は基本、運用保守業務を行っているのですが、エンハンス開発業務も行うこともありまして、今回はエンハンス開発において少しハマったことを記事にいたします。

開発要件

とある記録を行うアプリのサーバーサイドの処理において、以下のような追加要件がありました。
※他にもいくつかあったのですが、現象が起きた要件のみ抜き出しています。

  • 現行
    • 記録を削除してからメイン画面に戻った際、記録の残りがゼロだと「記録がゼロです」という表示を行う。
  • 変更
    • 記録を削除してからメイン画面に戻った際、記録の残りがゼロだと未記録として 初期状態の画面に戻す

変更する前の処理

対応しようとしているソースにおける処理概要としては下記のようになっていました。

ソースは TypeScript で実装されており、下記のような感じでした。

    DynamoDBDocumentClient ddbDoc = new DynamoDBDocumentClient(省略);
      :中略
    try {
      await ddbDoc.send(
        new TransactWriteCommand({
          TransactItems: [
            {
              Put: {
                TableName: 更新先ユーザーテーブル,
                Item: 状態を更新したいユーザーのアイテム,
              },
            },
            {
              Delete: {
                TableName: 削除したい記録テーブル,
                Key: {
                  id: 記録対象となるキー,
                },
              },
            },
          ],
        }),
      );
    } catch (error) {
      console.error("削除処理で予期せぬエラー発生", error as Error);
      throw new Error();
    }

削除を行う際に対象ユーザーの状態を更新する必要があったため、ユーザーのテーブルを更新しつつ、記録テーブルを削除する、という実装になっていたわけですね。

今回の対応で、当初以下のように対応しました。

リリース前に起きた謎現象

開発環境で無事動作しステージング環境へデプロイ。
お客様の動作確認を依頼しての受け入れテスト中に以下のご指摘を頂きました。

調査

画面のスクリーンショットを頂き、確かにそのとおり。
こちらで再現確認をするも何度試行しても再現しない。
対象の LINE User ID を教えていただき、CloudWatch Logs にてログを調査すると、ログの出力が不思議な順序になっていました。

  1. 更新&1件削除の開始のログ
  2. 更新&1件削除の終了ログ
  3. 残り件数の取得開始のログ

となるはずが、

  1. 更新&1件削除の開始のログ
  2. 残り件数の取得開始のログ
  3. 更新&1件削除の終了ログ

となっていて、改めて他のデバイスによる実施ログを見ても上記の順序でログが出ていたことが判明しました。

立てた仮説

async 〜 await を使って同期的に処理する形で進めてはいたのですが、意図していない順序で実行されてしまうことはよくあることです。

特にこの環境においては、ログのレベルを以下のように変えておりました。

  • 開発環境:全て console 出力を行う。
  • ステージング環境:一部 console 出力させない。
  • 本番環境:エラー以外は console 表示させない。

更に深く調査する必要もあったのですが、リリースを急ぐこともあり、ログの出力タイミングにより先に残り件数を取得する処理が動作し、このデバイスにおいては先に取得件数が返ってきたことでまだ全削除状態ではない、と判断したと推測いたしました。

対応

発生する確率を考えると本番環境では更にログが出ないことで再現率が高まる可能性があるため、以下のような形に実装を変更して対応いたしました(★が変更箇所です)。

異常系は省略していますが、概要として消す前に残り1件だったらフロントエンドへはデータ件数ゼロである旨を返すようにしました。

おわりに

他にもアイディアはあるかと思いますが、DynamoDB への更新が確定する確証が得られない場合は同じテーブルの件数を取得する等のアクセスは避けた方が良いですね。

この記事が何かのお役に立てれば幸いです。

アノテーション株式会社について

アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。

サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイト をぜひご覧ください。

この記事をシェアする

FacebookHatena blogX

関連記事