AWSのDynamoDBがアップデートされて，データ更新をほぼリアルタイムに通知可能になった。この新機能 – DynamoDB Streamsと呼ばれる – は，NoSQLのデータベース・アズ・ア・サービス向けに，DynamoDB Streamsが検出した所定のデータ変更に基づいて発行されるDynamoDB Triggersと，ストリームベースのアーキテクチャによって動作するクロスリージョン・レプリケーションという，２つの新機能を実現する。
リリースに関するブログ記事の中で，Amazon CTOのWerner Vogels氏は，イベント駆動プロセスを取り入れた分散型システムへの継続的な移行について説明している。
管理すべきデータの速度と多様性が増え続けて，データ更新をキャッチアップするタスクの難易度はますます高くなっています。システムやアプリケーションをリアルタイムで管理し，状況の変化に対応することが求められています。一般的に採用されているデザインパターンは，トランザクションあるいはオペレーションの情報を(ログなどの形で)キャプチャする，というものです。これには，DynamoDB内での高いスループットとパフォーマンスを要すると同時に，クラスタおよびデータウェアハウスを検索して，定期的な情報更新を行う必要があります。しかし，これまでは，データ変更を管理し，検索エンジンとデータウェアハウスエンジンの同期状態を保つために，自力でコード開発を行わなくてはなりませんでした。コストや管理上の理由から，パフォーマンスやスケーラビリティの点では妥協して，抽出ジョブとクラスタ検索，データウェアハウスを同じマシンに配置する場合もあります。DynamoDB Streamsはこのデザインパターンを，分散システムのアプローチによって単純化し，改善するものです。
Vogels氏はDynamoDB Streamsを，“任意のDynamoDBテーブルに対して実行されたすべてのアイテムレベルの変更に関する，時間順のシーケンスないし更新ログ”である，と定義している。すべての処理は非同期に実行されるため，パフォーマンスに影響を与えることはない。さらに，新規テーブルあるいは既存テーブルを問わず，DynamoDB Streamsを有効にすることができる。どのような情報 – 主キーのみ，変更前のアイテム，変更後のアイテム，またはその両方 – をストリームに書き込むかの決定は，ユーザに委ねられている。変更レコードは，ストリーム上で最大24時間利用することができる。StreamのコンシューマはAPIエンドポイントに接続して，ストリームレコードに含まれているシャード(shard)の要求を発行する。インターフェースは，AWSの提供するリアルタイムデータ処理サービスであるAmazon Kinesisのそれと，意図的に似通ったものになっている。DynamoDB Streamsは昨年秋からプレビュー版として提供されていたが，今回，すべてのユーザを対象に一般提供されることになった。サービスの利用自体は無償だが，ストリームからのデータ読み込みには課金される。
“トリガ”という概念は，経験豊富なDBAをぞっとさせるかも知れない。Vogels氏も，従来のデータベースでトリガを活用することの難しさは認識している。
データベースの黎明期から，プル方式は，データベースとのインタラクションにおける有用なモデルとされてきました。データを取り出すアプリケーションは，APIコールを実行してデータを読み出すことになります。テーブルの更新を検出するには，さらにAPIコールを行って，定期的にデータベースをプルしなくてはなりません。リレーショナルデータベースでは，アプリケーションがデータ変更に対応するメカニズムとしてトリガを使用します。しかしトリガの実行は，データベースを実行しているマシン上で発生したものとして行われるために，誤ったトリガの実行がデータベース全体に大きな被害をもたらす可能性があります。また，速い速度で移動するデータセットや，大規模なデータベースに対しては，このようなメカニズムでは十分なスケーラビリティが得られません。
真にスケーラブルで，ハイパフォーマンスで，フレキシブルなシステムとするためには，トリガの実行をデータベースから切り離して，データ変更の発生をアプリケーションに伝える必要があります。
Vogels氏の考えるソリューションは，DynamoDB Triggers – DynamoDB StreamsとAWS Lambdaのコンビネーションだ。Lambdaはイベント駆動の計算サービスで，JavaおよびJavaScript関数を実行する。これらの関数は，DynamoDB Triggersを通じてデータベース外部で実行され，DynamoDB Streamsに含まれるデータ変更に応答する。AWSのエバンジェリストであるJeff Barr氏は，先日のブログ投稿で，DynamoDB Triggersの説明とデモンストレーションを行った。
StreamsとLambdaのコンビネーションは，クリーンで軽量なデータベーストリガの実装方法と解釈できます。それもNoSQLスタイルで！従来のリレーショナルデータベースのトリガは，データベースエンジン自体の内部に実装されていました。そのため，オペレーションに対して可能なレスポンスのレパートリは，エンジンの定義するオペレーションによって制限を受けていたのです。トリガ(挿入，削除，テーブルアイテムの変更)に関連付けるアクションの実装にLambdaを用いることで，はるかに強力で，表現力に富んだ実装が実現できます。変更内容を解析するシンプルなコード(新旧のアイテムイメージを比較するなど)を書くことも，他形式のデータに変更することも，ビジネスルールを適用することも，あるいは同期ないし非同期でビジネスロジックを起動することも可能になります。Lambdaにホスティングやスケーリングを任せることで，アプリケーションのユニークで価値のある部分に注力することが可能になります。
Barr氏は，トリガ設定のための簡単なLambda関数を，サンプルとして紹介している。より複雑なシナリオ構築を望むのであれば，セキュアでステートレスなイベント駆動のLambda関数を実装するための，適切なパターンに確実に従う必要がある。Lambda関数の実行するためのコスト以外に，DynamoDB Triggersで使用することに関する特別な費用は必要ない。
今回発表された最後のコンポーネントは，DynamoDB Streams上に構築されたクロスリージョン・レプリケーションのソリューションだ。デフォルトでのDynamoDBは，指定されたリージョンの複数のアベイラビリティゾーンを対象として，データのレプリケーションを実行する。ディザスタリカバリや遅延対策，マイグレーションなどの目的で追加リージョンにデータをコピーしたい場合，これまではレプリケーションのソリューション設計上の責務となっていた。今回からAWSでは，アプリケーションがDynamoDB Streamsを活用して，ソーステーブルから別リージョンのレプリカへのデータコピーを行えるようになった。アプリケーションがCloudFormationプロビジョニングエンジンによってデプロイされることと，以下の構成を持つことが条件だ。
このモデルでは，シングルマスタ構成のみが可能である。つまり，レプリカに直接書き込まれた変更はマスタテーブルに反映されないため，上書きされるリスクが存在する。クロスリージョンでアプリケーションを実行すること自体への課金はないが，複製先のDynamoDBテーブルのスループットやデータ転送量の変化，データストリームの読み込みコスト，EC2コンテナインスタンスの変更，クロスリージョンアプリと交信するためのSQSキューのコストなどに必要なコストは，ユーザ責任となる。