https://github.com/SyoAwsBlog/gw-octgn

にコミットしてるので、プルリク（翻訳手伝い、スクリプト手直し（MTG版からGWに合わせて）、応援カンパ（githubスポンサー寄付）、などなど募集してます。

対戦の様子

現時点版で、対戦すると、こんな様子になります。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

そんな訳？で、前回に引き続きStepFunctionから利用するLambdaシリーズ？という事で、Glue Crawlerの状態取得のLambdaサンプルを掲載します。

前回のLambdaと併せて、「Crawlerの実行」→「Crawlerが実行完了するまで？秒毎にループ」といったStepFunctionの定義が可能となります。

githubにて公開

Lambda＋Glue（Crawlerステータス取得）のサンプルソースです。ダウンロードは下記より。
https://github.com/SyoAwsBlog/ShoLambdaSample09

• 環境変数で対象のCrawlerが指定可能
• GlueのCrawlerのステータスを返却する

などの仕様を盛り込んでいます。

StepFunctionsで判定する時は、「Choices」で判定するイメージです。

{
   "Choices":[{
      "Variable":"$.response",
      "StringEquals":"FAILED",
      "Next": "エラーで終了のタスクへ"
     },
     {
      "Variable":"$.response",
      "StringEquals":"READY",
      "Next": "正常終了の後続タスクへ"
     }
   ]
}

利用可能な環境変数

概要

今回も、サンプル１のソースを雛形としています。

特に難しい事もなく、

• 環境変数から対象のCrawler名を取得してパラメータを生成する
• 対象Crawlerのステータスを取得してきて、Lambdaの戻り値にマッピングする

ただ、それだけです。

主要な基底処理

今回は、getTasksをオーバーライドせずに利用していますが、処理の流れを説明します。

  AbstractBizCommon.prototype.getTasks = function (event, context) {
    var base = AbstractBizCommon.prototype;
    try {
      base.writeLogTrace("AbstractBizCommon# getTasks :start");

      return [
        this.beforeMainExecute,
        this.businessMainExecute,
        this.afterMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractBizCommon# getTasks :end");
    }
  };

• beforeMainExecute　・・・　起動引数の返却
• businessMainExecute　・・・　パラメータの生成＆Crawlerのステータス取得
• afterMainExecute　・・・　戻値の整形

という処理の流れになっています。また今回は処理結果をLambdaのプログラムとしての戻り値を制御する必要があるので、GlueCrawlerStatusModule.jsで「afterAllTasksExecute」の実装を行っています。

あとがき

StepFunctions × Lambda × Glue × Athena の組み合わせを使いこなせると、大量データ（今風に言うとビックデータ？）の編集・集計バッチの在り方が劇的に変化するので、簡単に利用できると良いな、、、と思ってサンプルソースをあげてます。

お手元のAWS環境で、サクっと実証実験する時にでも使ってください。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

前回のサンプルソースが取り組んでみたら、かなりの大物になったので、今回は記述量少なめなシンプルなパターンです。最近、StepFunctionsはGlueとの連携をサポートしはじめたようですが、Crawlerの実行には対応していなかったようなので、LambdaからCrawlerを起動するサンプルソースを掲載します。

個人的な嗜好としては、Glueのジョブを使うパターンが少な目なので、ちょっと残念なアップデートでした。

「Glue（Crawler）から、Athenaで集計する。」をStepFunctionsでバッチ化するパターンが、今のところ実務では多めです。
AWS利用料も、Glueジョブ使うより安いのでオススメです。

本投稿から、しばらくStepFunction絡みで、自分が使う再利用可能なLambda達を書いていこうかな？と思ってます。

githubにて公開

Lambda＋Glue（Crawler実行）のサンプルソースです。ダウンロードは下記より。https://github.com/SyoAwsBlog/ShoLambdaSample08

• 環境変数で対象のCrawlerが指定可能
• GlueのCrawlerを実行す

などの仕様を盛り込んでいます。

ここ最近のサンプルソースの中では、「サンプルらしい！」と言えるほどシンプル機能（笑

利用可能な環境変数

概要

今回は、久しぶりにサンプル１のソースを雛形としています。

今回は、特に難しい事もなく、

• 環境変数から対象のCrawler名を取得してパラメータを生成する
• Crawlerを実行する

ただ、それだけです。

主要な基底処理

今回は、getTasksを末端のクラスでオーバーライドしてますが、処理の流れを説明します。

  GlueCrawlerSubmitModule.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = GlueCrawlerSubmitModule.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("GlueCrawlerSubmitModule# getTasks :start");

      return [this.beforeMainExecute, this.businessMainExecute];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("GlueCrawlerSubmitModule# getTasks :end");
    }
  };

• beforeMainExecute　・・・　起動引数の返却
• businessMainExecute　・・・　パラメータの生成＆Crawlerの実行

複雑な処理もないし、パラメータ作って、AWSのAPI実行するだけなので、初学向き・・・ですかね。

あとがき

比較的重たいサンプルソースが続いたので、ライトな感じで行数少な目なサンプルソースです。

しばらくは、StepFunctionsから呼び出して使う系のLambdaシリーズを続けようかと思います。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

本投稿ではブログ記事の書き方・文章の質・量については、そんなに触れる気はありません。ブログの中身は千差万別でGoogle様のポリシー違反にならない範囲で好きに書いてオンリーワンを目指せば良いし、合格する為のコツなんて物はありません。
あったとしても、googleの「中の人」しか知りえない情報で世の中に公開されていないからです。

私の場合は、

「価値の低い広告枠: コンテンツが存在しない」

を理由に、２～３回不合格となりましたが、記事の中身というよりも、技術的な対処で合格できたと思っているので、その点について記事にしておきたいと思います。

こういう文章が良い、こんな書き方が良い、というのは、ググれば色々出てきますしね。

最低限用意する内容

• 自己紹介
• プライバシーポリシー
• お問い合わせフォーム

この３点は、用意しておかないといけないみたいですので、Wordpressの固定ページに用意して、トップ画面の分かりやすい所からリンクしておきましょう。（これは他のHow To サイトで良く掲載されてるので割愛します）

X-Serverのサブドメイン対応（HTTPリダイレクトの設定）

GoogleAdsenseで初めて申請する時には、サブドメインを利用する事ができません。一方、X-ServerではWordpressをサブドメインで構築する方も一定数いるかと思います。

ここの設定の仕方が分からずに諦める人も多いんじゃないだろうかと思うので、本サイトがGoogle Adsenseに合格した時の設定内容を載せておきます。

２つの「.htaccess」ファイルに修正が必要です。間違えるとブログサイトが閲覧できなくなりますので、修正前にファイルをコピーして、必ずバックアップを残しておいてください。

ファイルへのアクセスは、X-Serverのインフォパネルから、「ファイル管理」のボタンをクリックして操作してください。
※ クリックしてダウンロードする時に、ファイル名先頭の「.」（ドット）が無くなる事があるのでファイル名は注意

＜public_html＞直下の「.htaccess」ファイルの中身　　サブドメインへの転送（リダイレクト設定）
～～ここから～～
省略

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTPS} !=on [NC]
RewriteCond %{HTTP_HOST} ^physalisgp02\.com$ [NC]
RewriteRule .* https://awsblog.physalisgp02.com/%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTPS} =on [NC]
RewriteCond %{HTTP_HOST} ^physalisgp02\.com$ [NC]
RewriteRule .* https://awsblog.physalisgp02.com/%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTPS} !=on [NC]
RewriteCond %{HTTP_HOST} ^www\.physalisgp02\.com$ [NC]
RewriteRule .* https://awsblog.physalisgp02.com/%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTPS} =on [NC]
RewriteCond %{HTTP_HOST} ^www\.physalisgp02\.com$ [NC]
RewriteRule .* https://awsblog.physalisgp02.com/%{REQUEST_URI} [R=301,L]
</IfModule>

～～ここまで～～

ブログ用サブドメイン直下の「.htaccess」ファイルの中身　　（httpアクセスを、httpsへ転送）
～～ここから～～
省略

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} !=on [NC]
RewriteCond %{HTTP_HOST} ^awsblog\.physalisgp02\.com$ [NC]
RewriteRule .* https://awsblog.physalisgp02.com/%{REQUEST_URI} [R=301,L]
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

～～ここまで～～

太字にした所が大事な設定ですが、これらの修正を加えて、X-Server上のファイルを上書きしてください。

赤字の部分は、もちろん自分の取得したドメインに修正して使ってください。

WordPressのHTTPS対応

WordPressのダッシュボードで、「設定」→「一般」から、

• WordPressアドレス（URL）
• サイトアドレス（URL）

を、「https」に変更する事で、ブログへのアクセスを全て、「https」に強制する事ができます。こちらの設定も忘れずに！

Google XML Sitemaps (プラグイン)の設定見直し

Google Adsenseの申請をする前に、自分のブログ（https://～）をGoogle Search Consoleに登録して「カバレッジ」を確認し、エラーがない事を確認してください。
エラーがある間は、高確率でGoogle Adsenseの申請しても、２～３日後に不合格の連絡がきます。

エラーの種類によって対応方法は異なりますが、Sitemapの設定を見直す事でエラーをなくせる事が多いかと思います。

PageSpeed Insightsの評価

Google Search Consoleの「ウェブに関する主な指標」で、「PageSpeed Insightsを試す」が実施できますので、可能な限り良い評価が出るように、プラグインなどで対策をしましょう。

＜パソコンアクセスの評価＞

＜モバイルアクセスの評価＞

と、この記事を書きながら、モバイルの評価が下がってるの気がついた。。。（＾＾A
Google Adsenseの広告を入れるとモバイルの評価が悪くなるようです。（ヤメテホシイわー）

Google Adsenseに申請して広告を貼ってなかった頃は、モバイルも80～92位の評価を出せてました。

ギラギラのゴテゴテで、ヌルヌルキラキラした重たいデコレーションは、Google Adsenseの合格を貰った後からでも出来るので、Google Adsenseに申請する時は、サイト描画の速さ（PageSpeed Insightsの評価）にも気を配ると良いかもしれません。

（審査の評価ポイントに入ってるかどうかは分かりません、私は、かなり気を配ってました。）

あとがき

ブログ開設当初から目標にしていた、Google Adsenseに合格しました。

最初の1週目は、２～３日毎に申請しては不合格を繰り返してました。Google Search Consoleのエラー対応がゼロになったあたりから段々と審査で落とされる時間が長くなっていった感じがしました。

どんなに良い記事を書こうが、「Google Search Consoleのエラー」がある間は、ロボット審査で問答無用で落とされてる感があります。

Google Adsenseの審査にチャレンジする方は、上記の技術サイドでも全力で、Googleに好印象を与えるよう努力して合格を勝ち取りましょう。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

Node.jsでPDFの操作をやった事がなかったので勉強がてら、手を出したらヒドイ目にあった。（ぇ
自前でPDFを、こねくり回すのはシンドイのでライブラリを探したけど、日本では、あまり「やってみた系」がありませんでした。
npmのライブラリを漁った所、hummusが良さそうだったので、このライブラリの検証がてらLambdaで実装してみました。

出力先のS3バケット名をLambdaの環境変数に指定して、S3インプットトリガーで起動するだけで、PDFファイルのページ毎分割ができるLambdaを実装しました。

このLambdaを利用する場合は、S3のputトリガーを仕込むS3バケットと、分割したPDFファイルを保存するようのS3バケット、必ず２つ用意してください。

間違っても、putトリガーを仕込んだS3バケットに分割したPDFファイルを保存して無限ループさせる事がないようにしてください。

hummusのライブラリがサイズ（約12MB）が大きくて、S3に一度アップしてからじゃないとLambdaに登録できないので注意してください。

hummusは、内部でコンパイルしてるので、Windows環境で

「npm install hummus」しても動作しません。

開発プロジェクトから作成したい方は、AmazonLinuxのEC2を一時的に起動して開発プロジェクトを作る必要があります。
githubで公開してる物を落とした場合はAWS Lambdaで動作します。

githubにて公開

S3プットトリガー + Lambda + S3 のサンプルソースです。
ダウンロードは下記より
https://github.com/SyoAwsBlog/ShoLambdaSample07

• S3putトリガーを受け取ってS3オブジェクトをLambdaの/tmp配下に保存する
• PDFファイルをhummusに喰わせて構造解析する
• 1ページ毎のデータを構築して環境変数で指定したS3バケットに保存する
• /tmp配下の保存したPDFファイルを削除する
• S3putトリガーで受け取った原本のPDFファイルを削除する

などの仕様を盛り込んでいます。

利用可能な環境変数

概要というか実装時の四方山話

S3から取得したオブジェクトをメモリ展開したまま、ページ分割データをS3バケットにアップできたら良いなぁ～と思って、試行削除したのですが、、、

「TypeError: Unable to start parsing PDF file」

ライブラリの出力してくる、このエラーが潰せなかった。
エラーとしては、不正な形式ファイルを読み込んだ時に発生するエラーっぽいのだけど、一旦、/tmpにおいて取り込むと処理できるという。。。
（誰か、この謎を解いてください（ぇ

hummusにBufferから取り込む為のクラスも用意はされてるですが、上手く動かない。issueとかを見てると、デカいファイルの時はローカルにファイルを保存してしまった方が格段に処理が早いとのコメントもあったので、/tmpに置く方式で実装しています。

主要な基底処理（制御側）

まずは制御側のS3putトリガーからデータ取得してハンドリングする制御処理から説明します。

AbstractS3PutTriggerCommon　　565行目

  AbstractS3PutTriggerCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractS3PutTriggerCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractS3PutTriggerCommon# getTasks :start");

      return [
        this.initS3PutTriggerParameter,
        this.waitExistsS3Object,
        this.beforeMainExecute,
        this.pdfParse,
        this.businessMainExecute,
        this.afterTmpDeleteExecute,
        this.afterMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractS3PutTriggerCommon# getTasks :end");
    }
  };

• initS3PutTriggerParameter ・・・ putトリガーからS3取得のパラメータを返却
• waitExistsS3Object　・・・ S3のオブジェクト存在確認
• beforeMainExecute　・・・S3オブジェクトデータ（PDF）を/tmpに保存
• pdfParse　・・・PDF構造解析データとページ分割制御データの作成
• businessMainExecute　・・・非同期多重実行の制御
• afterTmpDeleteExecute　・・・/tmpに保存したデータ削除
• afterMainExecute　・・・ putトリガー元となったS3オブジェクト削除

この処理では1ページ毎にファイル分割をしていますが、複数ページでファイル分割した場合は、「pdfParse」で作成しているワーカ処理用のデータを改造すると出来ると思います。

主要な基底処理（ワーカー側）

AbstractWorkerS3UploaderCommon・・・226行目

  AbstractWorkerS3UploaderCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractWorkerS3UploaderCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractWorkerS3UploaderCommon# getTasks :start");

      return [this.beforeMainExecute, this.businessMainExecute];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractWorkerS3UploaderCommon# getTasks :end");
    }
  };

• beforeMainExecute　・・・　制御側から受け取ったデータを返却
• businessMainExecute　・・・　1ページ分のPDFデータを作ってS3へアップロード

と非常にシンプルな構成になっています。

「ExecutorsThreadsNum=5」にして、5多重とかにしても、一応、ちゃんと動いてるっポイです。

あとがき

軽い気持ちで手を出したら、イロイロ上手くいかない事や調査しないといけない事があって勉強になりました。

英語のコミュニティを漁るのは、しばらく、お腹イッパイです。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

サンプル４、サンプル５とデータ連携シリーズを掲載してきたので、今風に言うとデータレイク（S3）へのCSVファイル出力するの為にFirehoseへ連携するLambdaをサンプルとして公開しようと思います。

サンプル４、サンプル５と今回のサンプルソースを全て繋げると

• S3にファイルをputし、putトリガーでLambdaを起動
• DynamoDBに取り込み
• DynamoDBからストリームでSNSへ配信
• SQSにデータ蓄積
• SQSからデータを取り出して分析用に加工しながらFirehose（S3）へ出力

とデータ連携システムをLambdaで実現する時の主要な利用AWSサービス群と、ちょっと編集するだけで、繋がる・動くLambdaが用意できるようになります。

githubにて公開

SQS + Lambda + Firehose のサンプルソースです。 ダウンロードは下記より https://github.com/SyoAwsBlog/ShoLambdaSample06

• SQSから一度に取得できるメッセージ数はAPIで10件まで上限があるので指定件数・リトライ数で可能な限り受信
• データ連携を想定してるのでFirehoseへのputは成功するまでリトライ（落ちる時はLambdaの実行時間上限）
• Firehoseへのputに成功したらSQSキューからメッセージを削除
• SQSにメッセージが残っているようなら自身（Lambda）を再起呼び出し（上限設定あり）

などの仕様を盛り込んでいます。

利用可能な環境変数

今回は、ちょっと利用できる環境変数が多いです。（＾＾A

  AbstractSqsReceiveCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractSqsReceiveCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractSqsReceiveCommon# getTasks :start");

      return [
        this.beforeMainExecute,
        this.businessMainExecute,
        this.afterMainExecute,
        this.reCallSelfExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractSqsReceiveCommon# getTasks :end");
    }
  };

• beforeMainExecute　・・・　指定件数の受信ができるか、0件受信になるまでSQSから受信
• businessMainExecute　・・・　非同期多重実行の制御
• afterMainExecute　・・・　SQSのキュー情報（メッセージ残件）を取得
• reCallSelfExecute 　・・・　SQSにメッセージが残っているようなら自身（Lambda）を再起呼び出し

この処理を実装しようとした時に、一番、驚いたことは、「SQSからメッセージ受信が1回につき10件まで」に制限されている事です。

SAA資格とかで勉強した事がある人は分かると思いますが、「SQSは耐久性があって大量データをキューイングできる。」という触れ込みの設問が多々出題されます。

Lambdaで処理しようとした時に、「APIでMAX10件しか取得できない！」って、「どーゆーことやねん！」と思った物です。
そんな訳で、「環境変数：SqsReceiveMaxSize」で指定して、ある程度の件数を捌けるようにしてます。
連携データ仕様にもよりますが、実体験で50～100件位で処理させる事が多いですかね。

それでも処理しきらない時の為に、SQSに残件があるかどうか確認して自身（Lambda）を再起呼び出しする機能も組み込んであります。
カスタマイズする時は、バグらせて無限ループさせないように注意してください。

やらかして「Lambdaを無限ループさせちまった！？」という時は、AWSコンソールから対象のLambda関数を削除してください。

主要なワーカー処理（Firehoseへのput処理＆キューからメッセージ削除）

制御側から受け取ったデータをFirehoseへputして、SQSキューから処理したメッセージを削除します。

AbstractFirehosePutWorkerCommon　・・・　492行付近

  AbstractFirehosePutWorkerCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractFirehosePutWorkerCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractFirehosePutWorkerCommon# getTasks : start");
      return [
        this.beforeMainExecute,
        this.extractBizInfos,
        this.transformRecordInfos,
        this.businessMainExecute,
        this.afterMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractFirehosePutWorkerCommon# getTasks : end");
    }
  };

• beforeMainExecute　・・・　制御側から受け取ったデータを返却
• extractBizInfos　・・・　データの展開（どのサービスを経由してきたによって要オーバーライド）
• transformRecordInfos　・・・　DynamoDBのデータ構造を単純なマップ構造に変換
• businessMainExecute　・・・　FirehoseへのPut処理
• afterMainExecute　・・・　対象データをSQSキューから削除

Firehoseへの登録に成功しない限り何度でもリトライするようにしてあるので、「環境変数：FirehoseStreamName」のストリーム名やLambdaに付与するIAMロールのポリシー付与は絶対に、絶対に間違わないでください。

Lambdaの実行時間上限まで動作する事になります。

Firehoseへのputに成功したらSQSキューから削除としたかったので、Firehoseのput処理成功時の次のPromise処理に、SQSキューからの削除を配置しています。

主要なカスタマイズ①（出力レイアウト）

AbstractFirehosePutWorkerCommon.businessMainExecuteから、getFileOutputLayoutを呼び出して出力フォーマットを変換しています。

getFileOutputLayout　・・・　338行目付近　　　recordには対象の行データ

      var recordData = "";
      var cols = base.getFileOutputColumns();

      for (var i = 0; i < cols.length; i++) { var colName = cols[i]; if (i > 0) {
          recordData = recordData + ",";
        }

        if (
          colName in record &&
          record[colName] &&
          record[colName].length > 0
        ) {
          recordData = recordData + "" + record[colName];
        } else {
          recordData = recordData + "";
        }
      }

      recordData = recordData + "\n";

という感じで、カンマ区切りのCSVデータに変換しています。

主要なカスタマイズ➁（出力項目）

AbstractFirehosePutWorkerCommon.getFileOutputLayoutから、getFileOutputColumnsを呼び出して出力対象とするDynamoDBの項目名を配列で決定しています。

こちらは、カスタマイズのオーバーライド例として、SampleFirehosePutWorkerModule側にオーバーライド関数：getFileOutputColumnsを実装しています。

SampleFirehosePutWorkerModule　・・・　30行付近

  SampleFirehosePutWorkerModule.prototype.AbstractBaseCommon.getFileOutputColumns = function (
    record
  ) {
    var base = SampleFirehosePutWorkerModule.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace(
        "SampleFirehosePutWorkerModule# getFileOutputColumns : start"
      );
      var cols = ["PrimaryKey", "SortKey"];
      return cols;
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace(
        "SampleFirehosePutWorkerModule# getFileOutputColumns : end"
      );
    }
  }.bind(SampleFirehosePutWorkerModule.prototype.AbstractBaseCommon);

colsに代入する配列に、DynamoDBの項目を設定すると、その順序でCSVデータが並び替えられて出力されます。
データの送出元となったDynamoDBの項目名に合わせて、この関数を書き換えてください。
後は、Lambdaの環境変数を整備してIAMロール＆ポリシーを整えるだけで流用できると思います。

あとがき

データ連携シリーズ（サンプル４、サンプル５、サンプル６（今回））は、いかがだったでしょうか？

Firehoseまで連携できれば、ElasticsearchやS3に置いてglue&Athenaなど分析系サービスにデータを繋げていく事ができるので、業務に応用のきく実戦的なLambdaを掲載できたのではないかと思います。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

Webアプリやデータ連携バッチで、S3のputトリガーを起点にしてLambdaを起動して何らかの処理をする。Lambdaの使い方としてはアイデアとして思いつきやすい用法ですが、実は考慮しておいた方が良い点があるので、実体験で得た情報と共に説明していきます。 今回も出力側は、DynamoDBを選択しましたが、batchWriteItemのAPIで複数件データを登録＆リトライ処理する辺りについても触れていきます。

だんだん、サンプルと言いながらソース記述量が増えていってるのは、突っ込まないで！

具体的なAWSサービス同士の連携を考えると、考慮しておきたい機構や仕組みなんかが増えていく。。。

githubにて公開

S3 putトリガー + Lambda + DynamoDB のサンプルソースです。 ダウンロードは下記より https://github.com/SyoAwsBlog/ShoLambdaSample05

• S3でputトリガーからのLambda起動を使う際の注意点
• DynamoDBへの複数件一括登録の再起呼び出しリトライループ

などの小技を織り込んでみました。

利用可能な環境変数

概要

今回も組み上げには、サンプル２を利用しました。
サンプル集として、「S3からファイルを読み込んで正常に処理できたらオブジェクトを削除する」と「読み込んだデータを受け取って処理する（今回はDynamoDBへ登録する）」が別クラスになっていた方が別用途での使い回しが効きやすいし、コードが読める人には読みやすいという理由からの選択です。

DynamoDBの書き込みキャパシティは大量に増やすとAWS利用料の課金が増えるので注意してくださいね。

書き込みキャパシティにデカい数字を割り当てられる程、お財布事情に余裕があるのであれば、存分に多重非同期の効果を確認してみてください。

主要な基底処理（S3のデータ読み込み～オブジェクト削除）

まずはS3からのトリガーを処理している方の簡単な流れから説明します。

AbstractS3PutTriggerCommon　　540行目近辺

  AbstractS3PutTriggerCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractS3PutTriggerCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractS3PutTriggerCommon# getTasks :start");

      return [
        this.initS3PutTriggerParameter,
        this.waitExistsS3Object,
        this.beforeMainExecute,
        this.businessMainExecute,
        this.afterUnProcessedItemCheck,
        this.afterMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractS3PutTriggerCommon# getTasks :end");
    }
  };

• initS3PutTriggerParameter　・・・　AWS SDK で S3 の各APIで使う汎用引数を生成
• waitExistsS3Object　・・・　putトリガーで対象となったS3オブジェクトのアクセス待機
• beforeMainExecute　・・・　S3オブジェクトからファイル読み込み、処理データ整形
• businessMainExecute　・・・　非同期多重実行の制御
• afterUnProcessedItemCheck　・・・　DynamoDBへの登録残件の有無判定
• afterMainExecute　・・・　S3のオブジェクト削除

それぞれの関数の詳細は、実際の関数を見てもらうとして、、、「やってみた系」では、よく省略されている、「～S3.waitFor(“objectExists”～」の必要性について訴えていきたいと思います。

S3のputトリガーはLambdaで、すぐにアクセスすると「オブジェクトが存在しない！」というエラーでErrorをスローする事があります。

Errorをスローする事があります。（大事な事なので2回書きます）

もう１つ、紛らわしい事があってS3の障害時や、ちょっとだけ調子が悪くなった時（ネットワーク遅延）などに、1回のS3オブジェクト保存で、putトリガーが同じ内容で２～３回起動される事があります。

後続の処理では、リトライ＆再実行が行われても問題ないような連携仕様にしておくと幸せになれる。と留意が必要です。

その点、DynamoDBへの連携は上書きされるだけなので、選択肢としては申し分なしですね。

主要なワーカー処理（DynamoDBへの一括登録）

制御側から受け取ったデータをDynamoDBへ一括登録する処理になります。

AbstractWorkerDynamoDbBatchPutCommon　・・・490行付近

 AbstractWorkerDynamoDbBatchPutCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base =
      AbstractWorkerDynamoDbBatchPutCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace(
        "AbstractWorkerDynamoDbBatchPutCommon# getTasks :start"
      );

      return [
        this.beforeMainExecute,
        this.transformRecordInfos,
        this.businessMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractWorkerDynamoDbBatchPutCommon# getTasks :end");
    }
  };

• beforeMainExecute　・・・　制御側から受け取ったデータを返却
• transformRecordInfos　・・・　オーバライド用関数の呼び出しとデータ重複排除処理
• businessMainExecute　・・・　DynamoDBへの登録実行＆リトライ

DynamoDBには、batchWriteItemという複数データを一度に登録するAPIがありますが、データを渡しても必ずしも登録される訳ではない。というのが注意点になりますかね。
APIのレスポンス情報の、UnprocessedItemsに登録されなかった情報が返却されるので、登録されなかった分は使い手側でハンドリングしろよ。という仕様です。
サンプルはリトライ上限（環境変数で設定）を設けて、処理して貰えるまで何度かリトライ（1秒待機）するという感じにしてあります。

主要なカスタマイズ（読み込み行データからテーブル項目への変換）

SampleWorkerDynamoDbBatchPutModule　・・・　30行目付近

      var argLine = String(record);
      base.writeLogTrace(
        "SampleWorkerDynamoDbBatchPutModule# argLine" + argLine
      );
      var values = argLine.split(",");

      var primaryKey = base.getPrimaryKey();
      var sortKey = base.getSortKey();

      var rtnObj = {};
      rtnObj[primaryKey] = { S: values[0] };
      rtnObj[sortKey] = { S: values[1] };
      rtnObj.ColumnB = { S: values[2] };

      base.writeLogTrace(
        "SampleWorkerDynamoDbBatchPutModule# JSON :" + JSON.stringify(rtnObj)
      );

      return rtnObj;

ファイルから読み込んだ1行のデータを引数で受けて、DynamoDBに登録する為の項目マッピングする部分は、末端のクラスに関数を切り出してあるので、DynamoDBのカラム＆設計に合わせて書き直すだけで流用できるようにしてあります。

SortKeyをテーブルに定義していない場合は、基底側（AbstractBaseCommon.transformRecordInfos）の一括登録データ内の重複データを排除する処理に修正が必要です。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

前回の投稿でサンプルソースを掲載しましたが、いわゆる「やってみた系記事」のように、関連AWSサービスを、どう設定するか簡単に説明していきたいと思います。
Lambdaの関数登録手順は、今回は省いて、周辺AWSサービスの設定に焦点をあてて記事を書いていきます。

DynamoDBの設定

まずは、DynamoDBのテーブルのプロパティで「概要」タブの中から「ストリーム管理」をクリックして、ストリーム管理の有効化を行います。下記図

次に、DynamoDBのテーブルからトリガーとして、登録したLambdaを指定します。

この設定だけで、テーブルのデータに変更があった際に、DynamoDB Streamから変更データを供って、Lambdaを起動するように準備ができました。

SQS（Simple Queue Service）の設定

SNS（Simple Notification Service）のトピックが実行できているか確認する為に、SQS（Simple Queue Service）も併せて設定しておくと良いでしょう。

キューの作成は下記の通り、クイック作成で構いません。

SNSからSQSに情報連携する際には、SQS側にアクセス許可を与える必要があります。
※忘れがちですが、注意しましょう！

• 条件：ArnLike
• キー：aws:SourceArn
• 値：arn:aws:sns:リージョン名:AWSアカウントID:*

で、発信元を自AWSアカウントのSNSからのアクセスのみ受け付けるように限定できます。

サブスクリプション登録用に、SQSのARNをメモしておく。

SNS（Simple Notification Service）の設定

トピックを作成したら、トピックの詳細画面からSQSをサブスクリプションとして追加する。

後は、SNSのARNをメモします。

Lambdaの環境変数設定

Lambdaの環境変数：TargetSnsTopicArnに、前手順でメモしたSNSのARNを設定します。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

次は、どの組み合わせのサンプルにしようか、若干迷ったのですが、DynamoDBへの登録処理のサンプルソースを掲載したので、DynamoDBに絡めて DynamoDB Stream からトリガーでLambdaを実行して、AWS SNSに通知するサンプルソースを選択してみました。 せっかくなのでサンプル２の多重度指定つき並行処理を雛形に組み上げしています。

githubにて公開

DynamoDB Stream + Lambda + SNS(Simple Notification Service) のサンプルソースです。

ダウンロードは下記より
https://github.com/SyoAwsBlog/ShoLambdaSample04

・Dynamo Streamから新規登録（INSERT）のレコードのみをSNSに通知する

利用可能な環境変数

概要

組み上げには、サンプル２を利用してみました。転用して実装すると、こんなイメージになります。
動作確認にも、特にコードを変更せずに、関連サービスの設定とLambda環境変数指定で動くようにしてあります。

主要な基底処理

AbstractDynamoDbStreamCommon　120行目近辺

     return new Promise(function (resolve, reject) {
        if (event && event.Records) {
          resolve(event.Records);
        } else {
          reject("event.Records Not Exists");
        }
      });

がポイントになるでしょう。DynamoDB Streamからの引数の中身は、下記のようなイメージです。

Records配下に DynamoDB Stream で連携されてきた各行の変更内容が連携されてくるので、そのデータを取得します。

{
    "Records": [
        {
            "eventID": "0123456789XXXXXXXXXXXXXXXX",
            "eventName": "INSERT",
            "eventVersion": "1.1",
            "eventSource": "aws:dynamodb",
            "awsRegion": "リージョン名",
            "dynamodb": {
                "ApproximateCreationDateTime": 1600000000,
                "Keys": {
                    "PrimaryKey": {
                        "S": "XXXXX"
                    }
                },
                "NewImage": {
                    "ColumnB": {
                        "S": "YYYYY"
                    },
                    "ColumnC": {
                        "S": "ZZZZZ"
                    },
                    "SortKey": {
                        "S": "2020-07-01T00:00:00.000+0900"
                    },
                    "PrimaryKey": {
                        "S": "XXXXX"
                    }
                },
                "SequenceNumber": "0123456789XXXXXXXXXXXXXXXX",
                "SizeBytes": 88,
                "StreamViewType": "NEW_AND_OLD_IMAGES"
            },
            "eventSourceARN": "arn:aws:dynamodb:リージョン:AWSアカウントID:table/テーブル名/stream/2020-07-01T00:00:00.000"
        }
    ]
}

AbstractWorkerSnsCallTopicCommon

  AbstractWorkerSnsCallTopicCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractWorkerSnsCallTopicCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractWorkerSnsCallTopicCommon# getTasks : start");
      return [
        this.beforeMainExecute,
        this.extractBizInfos,
        this.transformRecordInfos,
        this.businessMainExecute,
        this.afterMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractWorkerSnsCallTopicCommon# getTasks : end");
    }
  };

• beforeMainExecute  ・・・ DynamoDB Streamの1行データを返却
• extractBizInfos　・・・ 新規登録行のみを連携データとする判定
• transformRecordInfos　・・・  AWS SDKのAPI利用用にパラメータ組み立て
• businessMainExecute　・・・　API実行
• afterMainExecute　・・・　API実行後のログ出力

といった処理の流れになっています。

動作させる為のAWS設定手順は、別記事にて掲載予定。

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.

あらためてサンプルソースを使って、前回のようなDynamoDBへのアクセスをするLambdaを実装する場合を例として、手順・ポイントを説明したいと思います。
自分流のお作法的な所もありますが、慣れるとログが読みやすい・デバックしやすいなどのテクニックもあるので、このサイトの雛形を使ってLambdaを実装してみよう。と思う方は、簡単に目を通してください。

開発環境

筆者の開発環境について掲載しておきます。

• ソース管理：Git
• ソース管理：TortoiseGit + TortoiseGit-LanguagePack
• 開発環境：VSCode
• テキストエディタ：さくらエディタ

VSCodeのプラグインは、ほとんど入れてない状況です。
自分は、古風？人間なので、さくらエディタのみのエディタ開発でLambdaを制作する事が、苦でもなかったります。
なのですがブログ掲載するにあたり、流石にフォーマッターで整形したソースにしないとお目汚しがヒドイかな。。。と思い、VSCodeを使い始めました。

githubで公開しているソースは、VSCodeのデフォルトフォーマッターで整形したソースになっています。

手順１．githubからソースを取得

Githubからのダウンロード操作

ダウンロードした Zipファイルを解凍したら、サンプルソースの開発用フォルダが展開されます。
サンプル１、サンプル２、のソースなどは、展開して出てきたZipファイル（ShoLambdaSample.zip、ShoLambdaSample02.zip）を、そのままAWS Lambdaに登録して動かす事も可能です。（CloudWatchへのログ出力のみ）

手順２．VSCodeへの登録

VSCodeでフォルダを開く

細かい業務処理を実装・編集する場合には、VSCodeの方が良いでしょう。

手順３．ファイル名・クラス名の変更（命名のリファクタリング）

継承ツリー上、雛形から転用する際に個人で命名して欲しい階層は、２つです。

• 機能共通：AbstractBizUnitCommon　　→　DynamoDBに登録する為の共通処理だと分かる名前へ変更する
• 業務名：SampleBIzModule　→　ユーザ登録機能・グループ登録機能など、業務に由来する名前へ変更する

先日のサンプルソースでは、

• 機能共通：AbstractBizDynamoPutCommon
• 業務名：SampleBizDynamoPutModule

と変更しました。

まではエクスプローラーなどで、それぞれのファイル名を
変更前：AbstractBizUnitCommon.js　→　変更後：AbstractBizDynamoPutCommon.js
変更前：SampleBIzModule.js　→　変更後：SampleBIzDynamoPutModule.js
に変更します。

ファイル名の変更に伴って、それぞれ（AbstractBizDynamoPutCommon.js、SampleBIzModule.js）のファイルの中身も、さくらエディタの一括置換機能を使って置き換えます。

置換前：AbstractBizUnitCommon　→　置換後：AbstractBizDynamoPutCommon
置換前：SampleBIzModule　→　置換後：SampleBIzDynamoPutModule

一括置換機能の使い方

手順４．継承関係の整備

前手順でファイル名を変更しているので、読み込むファイル名を変更後のファイル名に変更する必要があります。

SampleBIzDynamoPutModule.js は、AbstractBizDynamoPutCommon.jsを読み込むように変更します。

index.jsは、SampleBIzDynamoPutModule.js を読み込むように変更します。

SampleBIzDynamoPutModule.js

module.exports = function SampleBizDynamoPutModule() {
  // 疑似的な継承関係として親モジュールを読み込む
  var superClazzFunc = new require("./AbstractBizDynamoPutCommon.js");
  // prototypeにセットする事で継承関係のように挙動させる
  SampleBizDynamoPutModule.prototype = new superClazzFunc();

index.js

  // 非同期実行関数の宣言
  function* main() {
    try {
      // 業務用の処理を書いたモジュールを読み込む
      var executeBizModule = require("./SampleBizDynamoPutModule");
      var executeBizObject = new executeBizModule();

具体的には、上記の require で、ファイルを読み込んでいるのでファイル名の変更に合わせて名称変更をします。

業務共通処理の実装

前回の投稿でも書きましたが、処理の構造を設計して、直列処理の単位で割り当てます。

• initEventParameter    ・・・   API Gatewayから起動引数の取り扱い（おまじない）とブラウザへの戻り値初期化
• beforeMainExecute　・・・　DynamoDBへの登録情報を生成する処理
• businessMainExecute　・・・　DynamoDBへの putItem処理を実行
• afterMainExecute　・・・　ブラウザへの戻り値を成功で上書き

DynamoDBへの登録の共通処理としては、上記の4処理を組み込むと設計しました。

AbstractBizDynamoPutCommon

  AbstractBizDynamoPutCommon.prototype.AbstractBaseCommon.getTasks = function (
    event,
    context
  ) {
    var base = AbstractBizDynamoPutCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace("AbstractBizDynamoPutCommon# getTasks :start");

      return [
        base.initEventParameter,
        base.beforeMainExecute,
        base.businessMainExecute,
        base.afterMainExecute,
      ];
    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractBizDynamoPutCommon# getTasks :end");
    }
  };

のように、getTasks をオーバーライドする事で、直列処理を追加できるので、上記のように業務共通処理層（AbstractBizDynamoPutCommon）に記述することで直列処理を４つにできます。

AbstractBizDynamoPutCommon

  AbstractBizDynamoPutCommon.prototype.AbstractBaseCommon.関数名= function (
    args
  ) {
    var base = AbstractBizDynamoPutCommon.prototype.AbstractBaseCommon;
    try {
      base.writeLogTrace(
        "AbstractBizDynamoPutCommon# 関数名 : start"
      );
      
      // ～～　ここに実装する　～～

    } catch (err) {
      base.printStackTrace(err);
      throw err;
    } finally {
      base.writeLogTrace("AbstractBizDynamoPutCommon# 関数名: end");
    }
  }.bind(AbstractBizDynamoPutCommon.prototype.AbstractBaseCommon);

直列処理を追加する場合は、上記をコピペして、関数名を好きな名前に変更して、ご利用ください。
※ 追加したら getTasksへの追加を忘れずに！

Copyright © 2026 とあるAWSエンジニアの戯言 All Rights Reserved.