AIシステムのアーキテクチャパターン

本番環境のAIシステムは、モデルファイルだけで構成されるものではありません。データパイプライン、特徴量ストア、サービング基盤、監視などが含まれます。アーキテクチャパターンは、これらの要素を信頼性の高い形で組み立てるための、実績のある設計図です。

AIシステムでは、多くの場合、次の両方が必要です。

• 履歴データに対して正確で包括的な結果を得るためのバッチ処理
• 新しいイベントに対して鮮度の高い、低レイテンシーな結果を得るためのリアルタイム処理

この2つを両立させることは、繰り返し登場する設計上の課題です。

Lambdaアーキテクチャでは、並列に動作する2つのレイヤーでこの問題に対応します。バッチレイヤーはすべてのデータを対象に正確なビューを再計算し、スピードレイヤーは新しいデータを低レイテンシーで処理します。サービングレイヤーがクエリに対して両方の結果を統合します。

バッチレイヤーは、完全なデータセットを定期的に再処理して、信頼できる正確な結果を生成します。たとえば、夜間に特徴量を再計算します。正確である一方、レイテンシーが高いため、直近数秒間のイベントを反映することはできません。

スピードレイヤーはストリーミングデータをほぼリアルタイムで処理し、前回のバッチ実行以降に生じた差分を埋めます。鮮度を優先するために一部の正確性を犠牲にしており、その結果は次回のバッチ実行によって最終的に置き換えられます。

Feature Storeは、ML特徴量を一元管理するシステムです。トレーニングとサービングで同じ特徴量定義を使う必要があるという重要な問題を解決します。定義が異なると、本番環境でモデルがトレーニング時とは異なる入力を受け取ることになります（トレーニングとサービングのスキュー）。

オフラインストアは、大量の過去の特徴量値を保持します。通常はデータレイクやデータウェアハウス内のparquetファイルとして保存されます。スループットがレイテンシーより重視されるトレーニングやバッチスコアリングで利用されます。

オンラインストアは、最新の特徴量値をRedisなどの低レイテンシーなデータベースに保持します。サービング時には、モデルがここからミリ秒単位で特徴量を取得します。オフラインストアと同じ定義が使われます。

Feature Storeは、トレーニング用に計算された特徴量（オフライン）が、サービングで読み取られる値（オンライン）と一致することを保証します。この一貫性により、本番環境で気づきにくいバグの大きな原因が取り除かれ、これがFeature Storeの中核的な価値となります。

本番環境で新しいモデルを信頼して使う前に、シャドーモードで実行します。実際のトラフィックを受け取って予測を行いますが、その予測はユーザーに提供せず、ログに記録します。ユーザーにリスクを与えることなく、現在のモデルと比較できます。

シャドーモードによって、新しいモデルが実際のトラフィックに対して正確かつ安定していることを確認できたら、多くの場合はカナリアリリースによって昇格させます。シャドーモードとカナリアリリースを組み合わせることで、トレーニング済みモデルを本番トラフィック全体に移行する安全で段階的な道筋が得られます。

アーキテクチャの知識を確認しましょう。

AIシステムのアーキテクチャパターンについて学びました。

• Lambdaアーキテクチャ：バッチレイヤー（正確）とスピードレイヤー（鮮度）を組み合わせます
• Feature Store：トレーニングにはオフラインのparquet、サービングにはオンラインのRedisを使い、一貫した定義を保ちます
• シャドーモード：昇格前に実際のトラフィックで新しいモデルを検証します