Lambda、Step Functions、CloudWatch Events ルールで Amazon Forecast ワークフローを自動化する

Amazon Forecast は、機械学習 (ML) により、それまでの ML 経験を待つことなく、非常に正確な予測を生成できる完全マネージド型サービスです。Forecast は、製品需要の見積り、エネルギー需要の予測、人事計画、クラウドインフラストラクチャの使用状況の算定、トラフィック需要の予測、サプライチェーンの最適化、財務計画など、さまざまなユースケースに使用できます。

Forecast は完全マネージド型サービスであるため、プロビジョニングするサーバーや手動で構築する ML モデルはありません。また、使用した分だけお支払いいただくようになっており、最低料金や前払い料金を求められることはありません。Forecast を使用するために必要なことは、予測対象の履歴データをご提供いただくことだけです。オプションとして、予測に影響を与えると思われる関連データも併せてご提供ください。後者には、価格、行事、天候など、時により変化するデータと、色、ジャンル、リージョンなどカテゴリに関するデータの、両方が含まれます。このサービスでは、お手元のデータに基づいて機械学習モデルを自動的にトレーニングし、デプロイして、予測を取得するためのカスタム API を提供します。

この記事では、Amazon Redshift のシステムアーキテクチャについて説明します。それにより、Forecast を使ってハードウェアを管理し、お客様が Amazon Redshift クラスターを迅速にスピンアップできるようにします。このシステムアーキテクチャはユースケースに依存せず、複数のシナリオで参照してお使いいただけます。Amazon Forecast の使用方法の詳細については、「Amazon Forecast が一般公開されました」と「Amazon Forecast で自由選択した分位数での予測作成のサポートを開始」を参照してください。

ユースケースの背景

Amazon Redshift は、クラウド上の、ペタバイトまたはエクサバイト規模の完全マネージド型のデータウェアハウスサービスです。Amazon Redshift クラスターは、1 つ以上のノードで構成されています。優れた顧客体験を提供するためにできるだけ早くクラスターをセットアップするには、キャッシュプールを維持して、ウォームプールと一般的に呼ばれるデータベースソフトウェアが事前にインストールされた特定の数のノードを保持します。顧客が新しいクラスターをリクエストするたびに、Amazon Redshift は必要な数のノードをキャッシュプールから取得します。Amazon Redshift はすべてのリクエストを記録し、各エントリには Location、Timestamp、NumberOfNodes の属性が含まれます。次のテーブルにデータの例を示します。

LocationId	Timestamp	NumberOfNodes
A	2019-01-01T18:05:00Z	5
A	2019-01-01T18:20:00Z	7
A	2019-01-01T18:52:06Z	11
A	2019-01-01T19:06:00Z	9
B	2019-01-01T19:31:40Z	9

キャッシュプールで適切な数のノードを維持するために需要を正確に予測することは、運用コストを最小限に抑えながら需要を迅速に満たす上で非常に重要です。プールの容量を少なくすると、クラスターの配信が遅くなり、最高の顧客体験を提供できなくなります。一方、キャッシュプールでノードのインベントリを余分に維持すると、運用コストが高くなります。Amazon Redshift は Forecast を使用して、任意の時点でのノードの需要を予測します。Amazon Redshift が Forecast の前に使用したパーセンタイルベースの予測子と比較すると、ウォームプールの容量使用率は 70% 向上しています。

全体的なシステムアーキテクチャ

次の図は、Forecast を使用してノードの需要予測を自動化するために Amazon Redshift が実装したシステムアーキテクチャの概要を示しています。アーキテクチャには次の手順が含まれます。

AWS Lambda、AWS Step Functions、Amazon CloudWatch Events ルールを使用して需要を発行し、定期的 (毎時) にデータベースをクエリし、過去の X か月 (現在のタイムスタンプからカウント) の需要データをソース Amazon S3 に書き込みます。
Lambda、Step Functions、CloudWatch Events ルールを使用してモデルを生成し、Forecast API を呼び出してモデルを作成および更新します。
Lambda、Step Functions、CloudWatch Events ルールを使用して予測を生成し、Forecast API を定期的 (毎時) に呼び出して、ターゲット S3 バケットに予測をエクスポートします。
新しいファイルがあり、ターゲット S3 バケットまたはフォルダ内に予測がある場合は常に、S3 イベントトリガーと Lambda 関数を使用して、Amazon DynamoDB テーブルにデータをロードします。
DynamoDB を直接クエリして、将来の需要を判断する

Forecast を使用して予測子を設定する

以下のセクションでは、Forecast service API を使用して必要なリソースを作成するときにパラメータを選択する方法について説明します。詳細については、「Amazon Forecast が一般公開されました」を参照してください。

データセットを作成する

データセットグループを作成したら、時系列データセットを作成し、データセットグループに追加します。データセットを作成するとき、スキーマやデータ頻度などの時系列のメタデータを指定します。次のスクリーンショットはスキーマを示しています。item_id はウォームプール ID、target_value は各リクエストのノード数です。ホストの準備期間によってデータ頻度 (つまり、Amazon EC2 RunInstance API を呼び出してからインスタンスがクラスターノードとして使用できるようになるまでの時間) が決まります。CloudWatch メトリクスを使用して、この期間を追跡します。最後に、データセットインポートジョブを使用して、データを S3 から Forecast にコピーします。

予測の作成

次のステップは、ML モデルである予測子を作成することです。予測期間を指定します。これは、モデルが予測のためにトレーニングするタイムステップの数です。この記事では、144 のタイムステップを選択します。各タイムステップは 30 分 (データ頻度に一致) で、基本的にその後 3 日間の予測を生成します。次のスクリーンショットでは、AutoML を使用して、Forecast がデータの最も正確なモデルを選択できるようにしています。最後に、Create Forecast API を使用して Forecast を生成します。

事前定義されたリズムで予測生成を自動化する

モデルを作成し、それを使用して、特定のリズムで予測を生成できます。ほとんどの場合、データパターンが短期間で大幅に変化することはほとんどありません。したがって、モデルを 1 回トレーニングして、新しいデータが利用できるようになるたびに予測を生成し、データパターンが変化すると予想されるリズムでモデルを再トレーニングする別のジョブまたはワークフローを用意することが最適です。このセクションでは、Forecast を使用して予測モデルのトレーニングと予測生成のワークフローを自動化する手順を説明します。

システムの冗長性を組み込む

最初に、過去の需要データの開始時刻と終了時刻を指定するルックバック期間と、予測対象の将来の期間である予測期間を定義する必要があります。この記事では、過去 100 時間をルックバック期間として使用し、4 時間を予測期間として使用します。このルックバック期間内にデータをアップロードします。たとえば、現在の 100 時間前から現在まで (次のグラフで黄色でマーク) の間にデータをアップロードし、現在から現在の 4 時間後 (次のグラフで緑色でマーク) までの結果を生成するようにサービスに処理させます。次のグラフは、自動予測プロセスの 1 サイクルを示しています。

ルックバック期間と予測期間の両方を 1 時間進めることで、このプロセスを 1 時間後に繰り返します。

次のスクリーンショットは、更新された予測期間を示しています。

生産に冗長性を持たせるために、1 時間ごとに新しい予測を作成します (予測期間は 4 時間ですが)。依存するサービスから予期しないエラーや停止が発生する可能性がいつもあります。Forecast により長い期間を予測させる場合、根本的な問題が修正されるまで、最後に作成した予測を使用できます。新しい予測は、2 時間実行する間に重複する時間間隔の予測をオーバーライドする必要があります。

予測ワークフローの自動化

予測ワークフローを自動化するために、2 つの cron (時間ベースのジョブスケジューラ) ジョブを作成します。1 つ目はモデルを定期的に再トレーニングし、2 つ目は更新されたデータをインポートし、既存のモデルを使用して推論を生成します。

次のスクリーンショットは、モデルを定期的に再トレーニングするための最初の cron ジョブを示しています。過去の需要には頻繁に変化する傾向がないため、モデルを頻繁に再トレーニングする必要はありません。ユースケースでは、30 日ごとに 1 回実行します。このリズムは、特定のユースケースに左右される場合があります。データパターンに変更がある場合、Forecast の AutoML 機能がこれを検出し、モデルを再トレーニングするときに最適なアルゴリズムを提案します。

次の図の 2 番目の cron ジョブは、新しいデータと既存のモデルを定期的にインポートして、新しい予測と関連するエクスポートジョブを作成します。Forecast は更新された需要データを使用して、新しい期間の予測を生成します。この cron ジョブを 1 時間ごとに実行します。パブリッシャーは同じファイル名を新しい需要データで置き換え続けるため、S3 入力ファイルパスはそのままにします。

サンプルコード

サンプルコードは GitHub リポジトリからダウンロードできます。

まとめ

この記事では、モデルを 1 回作成し、それを使用して予測を複数回生成するという一般的なシナリオで、Amazon Redshift が Forecast を使用する方法 (基になるシステムアーキテクチャを含めて) と、Forecast を使用して予測を自動化する方法を (サンプルコードと併せて) 説明しました。このソリューションは複数のユースケースに適用でき、予測ワークフローを自動化する作業を容易にします。この記事に関するフィードバックを AWS フォーラムか通常の AWS サポートチャネルを通じてお寄せください。

著者について

Zhixing Ma は、Amazon Redshift チームのシニアソフトウェア開発エンジニアで、Amazon Redshift 在庫管理プロジェクトをリードしました。 Amazon Forecast の最初の内部顧客である彼のチームは、信頼性が高くスケーラブルな自動予測システムを構築するために、サービスチームの科学者、製品マネージャー、エンジニアと緊密にやり取りしました。

Srinivas Chakravarthi Thandu は、Amazon Redshift チームのソフトウェア開発エンジニアで、専門分野には機械学習とデータ分析などがあります。彼が Redshift で扱ったプロジェクトには、ML モデリングと応用コンピューティングにかかわるコスト最適化とインフラストラクチャ管理が含まれます。彼は、サービスを実用化する間、Amazon Forecast の研究およびエンジニアリングチームと緊密に連携する機会がありました。

Vivek Ramamoorthy は AWS Redshift のソフトウェア開発マネージャーで、現在、クラスター管理とインフラストラクチャを担当するチームを率いています。余暇は映画を見たり、IoT デバイス用のソフトウェアを構築したりして楽しんでいます。

Yuyang (Bernie) Wang は、Amazon AI ラボのシニア機械学習サイエンティストです。主に、大規模な確率的機械学習の予測アプリケーションについて研究しています。彼の研究対象は、統計的機械学習、数値線形代数学、ランダム行列理論におよびます。予測分野における Yuyang の研究は、実践的なアプリケーションから基礎理論までの、あらゆる側面をカバーしています。

Rohit Menon はシニアプロダクトマネージャーで、現在は AWS で Amazon Forecast の製品の陣頭指揮をとっています。現在は、機械学習を使用して時系列予測を民主化することに取り組んでいます。余暇はドキュメンタリーを読んだり見たりしています。

Amazon Web Services ブログ