【ITニュース解説】Designing a Scalable, Serverless Vulnerability Data Processing Pipeline on AWS

システムエンジニアを目指す初心者の皆さん、今回はAWS（Amazon Web Services）を使って、セキュリティ上の弱点（脆弱性）に関するデータを効率的に処理する仕組み（パイプライン）をどのように構築したか、その設計と理由を解説する。このシステムは、サーバーの管理を自分たちで行う必要がない「サーバーレス」という方法で設計されており、多くのメリットがある。

まず、このシステムが解決しようとしている課題は、多種多様な脆弱性スキャンツール（Prowler、Trivy、AWS Inspectorなど）が出力する異なる形式の「脆弱性データ」を、効率的かつ安全に処理することである。具体的には、以下の要件を満たす必要があった。

第一に、データの取り込みは安全に行い、システムの負荷を抑える。そのため、データをクラウド上のファイル置き場であるS3に直接アップロードできるようにする。アップロード時には、利用者情報や使用ツールなどのメタデータも記録する。

第二に、取り込まれたデータは、システム独自の統一された形式に「正規化」する必要がある。ツールによってデータ形式が異なるため、そのままでは分析が難しいからだ。さらに、特に重要な脆弱性については、AI（人工知能）を使って、後で分析しやすいように「エンべディング」（データの特徴を数値の並びに変換すること）を行うオプションも必要である。これはAmazon BedrockというAWSのAIサービスを利用する。

第三に、処理されたデータは、リアルタイムで現在の状況を確認できるダッシュボードや、AIによる脆弱性の修復支援に活用できるよう、Amazon RDSというデータベースに保存する。

これらの要件を満たしつつ、システムは月に900回のデータアップロード、10テナント（利用者）を初期目標とし、最終的には50以上のテナントに拡張できること、そして月額14ドルから23ドル程度の低コストで運用できることが求められた。エラーが発生した場合でも、処理が途中で止まらないように、失敗したデータを一時的に保管する仕組みも必要だった。

この複雑な要件に対し、様々なサーバーレスアーキテクチャを検討した結果、「AWS Step Functions」と「AWS Lambda」を組み合わせる方法が最適であるという結論に至った。Step Functionsは複数の処理の流れ（ワークフロー）を管理する「指揮者」のようなサービスであり、Lambdaは個々のタスクを実行する「作業員」のようなサービスである。

採用されたアーキテクチャがどのように動くかを見てみよう。 まず、利用者がウェブ画面などから脆弱性データをアップロードしようとすると、API Gatewayというサービスがそのリクエストを受け取る。API GatewayはLambda関数を呼び出し、S3にファイルを直接アップロードするための特別なURLを発行する。同時に、アップロードに関する情報（顧客ID、使用ツールなど）はDynamoDBというデータベースに一時的に保存される。

データがS3にアップロードされると、EventBridgeというサービスがS3へのファイル保存を検知し、Step Functionsのワークフローを起動する。Step Functionsは、このワークフロー全体の指揮者として、以下の一連のタスクをLambda関数に指示して実行させる。

1. 冪等性チェック: すでに処理済みのファイルでないかを確認し、重複処理を防ぐ。
2. メタデータ取得・検証: DynamoDBからアップロード情報を取得し、必要な情報が揃っているかを確認する。
3. 顧客・差分チェック: Amazon RDSに登録されている既存の顧客情報と照合し、新しい脆弱性や以前に修正された脆弱性がないかを確認する。
4. ツール固有の前処理: Step Functionsはデータの種類に応じて異なる処理を実行できる。例えばProwlerからのデータであればProwler用の処理、TrivyからのデータであればTrivy用の処理といった具合に、対応するLambda関数を呼び出して、データの検証、重複排除、統一形式への正規化を行う。
5. データ検証: 前処理されたデータが必要な項目をすべて満たしているかなどを最終的に確認する。
6. 一括挿入・更新: 正規化された脆弱性データをまとめてAmazon RDS（PostgreSQL）に書き込む。
7. 書き込み後検証: データがRDSに正しく書き込まれたかを確認する。
8. 条件付きエンべディング: AIによるエンべディングが必要とされており、かつ脆弱性の重要度が高い場合にのみ、Amazon Bedrockを使ってエンべディングを実行し、結果をRDSに書き戻す。これにより、AI処理のコストを必要な場合にのみ発生させる。
9. メトリクスログ記録: 処理された脆弱性の数などの運用指標をCloudWatchに記録する。
10. クリーンアップ: 処理が終わったS3のファイルやDynamoDBのエントリを削除する。

もしこのワークフローの途中でエラーが発生した場合は、Step Functionsがエラーを検知し、失敗したデータをDLQ（Dead Letter Queue）という場所に送る。これにより、エラーの原因を後で調査し、必要に応じて再処理することが可能になる。

このような設計により、データのアップロードと実際の処理が切り離され、効率的かつ安全なシステムが実現されている。また、AI処理も必要なデータにのみ適用することでコストを最適化している。初期段階での月額コストは、およそ14ドルから23ドルと見積もられている。

次に、この設計を選ぶに至った経緯として、検討した他のサーバーレスアーキテクチャとの比較を説明する。

一つ目の選択肢は「純粋なLambdaベースの処理」である。これは、一つの大きなLambda関数、または複数の小さなLambda関数を連鎖させて、すべての処理を実行する方法だ。メリットは、Lambda自体のコストが非常に低いことと、自動で処理能力を増減できることである。しかし、複雑な処理の流れや条件分岐、エラー時の再試行といったロジックをすべてLambdaのコード内に記述すると、コードが肥大化し、エラーが発生しやすくなる。処理の流れも視覚的にわかりにくく、デバッグやメンテナンスが難しいという課題があった。

二つ目の選択肢が、今回採用された「Step FunctionsとLambdaの組み合わせ」である。この設計は、Step Functionsがワークフロー全体の流れを管理し、個々の処理を独立したLambda関数として実行させる。 この方法のコストは、純粋なLambdaよりもわずかに高くなるが、全体で見ればMVPの予算内に収まる。スケーラビリティは高く、Step FunctionsもLambdaも、多くの処理を同時に実行できる。信頼性は非常に強く、Step Functionsには、処理が失敗した場合の自動的な再試行や、エラーを適切に処理する機能が組み込まれている。視覚的にワークフローを確認できるため、デバッグも容易である。運用上の複雑さは低く、Step Functionsの視覚的なエディタを使えば、複雑な処理の流れも直感的に設計でき、Lambda関数はシンプルなタスクに集中できるため、メンテナンスがしやすい。条件分岐やツールごとの処理の切り替えも容易に行える。

三つ目の選択肢は「Step FunctionsとAWS Glueの組み合わせ」である。Glueは、特に大量のデータをETL（抽出・変換・読み込み）するのに特化したサービスだ。 この方法では、Step Functionsが全体の流れを指揮し、データの正規化や前処理といったETLタスクをGlueジョブが担当する。大規模なデータセットを扱う場合にはGlueの高いスケーラビリティが非常に有効だが、今回のデータ量（月間50GB程度）では、Glueの最小課金がコスト面で不利に働く。小規模なデータ処理でもGlueを起動すると、必要以上の費用がかかってしまうのだ。運用もGlueのスクリプトを書く必要があるため、少し複雑になる。そのため、今回のプロジェクトのようにデータ量がそこまで大きくない場合には、コストと複雑さが増すというデメリットがあった。

以上の比較から、「Step FunctionsとLambdaの組み合わせ」が、コスト効率、スケーラビリティ、信頼性、そして運用のしやすさの全ての面で、今回のプラットフォームの要件に最も適していると判断された。

この設計を選択した具体的な理由をさらに詳しく説明する。コスト効率の面では、Step FunctionsとLambdaは両方とも「使った分だけ支払う」という従量課金モデルなので、無駄なコストを抑えられる。特にAIによるエンべディングも、「クリティカルな脆弱性のみ」に限定することで、Amazon Bedrockの利用コストを大幅に削減できる。

スケーラビリティと柔軟性も大きな理由である。Step Functionsの視覚的なオーケストレーションは、特定のツールからのデータに対してのみ特定の処理を実行するといった複雑な条件分岐や、新しい脆弱性スキャンツールが追加された際の対応が非常に容易である。サーバーレスなので、利用テナントが増えても自動的にスケールしてくれる。

信頼性とエラー処理も非常に重要である。Step Functionsは、各タスクの自動再試行機能や、エラーが発生した場合に適切な処理を実行できる仕組み、そして失敗したデータをDLQに送る仕組みが組み込まれているため、非常に堅牢なシステムを構築できる。

運用上のシンプルさも大きな利点だ。Step Functionsの視覚的なワークフローエディタを使えば、処理の流れを直感的に理解・設計でき、個々のLambda関数は単一の役割に特化できるため、開発やメンテナンスが容易になる。

さらに、将来的な拡張性も考慮されている。このアーキテクチャはモジュール化されているため、新しい脆弱性スキャンツールに対応する場合でも、新しいLambda関数を追加し、Step Functionsのワークフローに分岐を追加するだけで済む。既存のコア部分に大きな変更を加える必要がないため、システムの進化が容易である。

この「Step FunctionsとLambdaの組み合わせ」というアーキテクチャは、AWSのサーバーレスなベストプラクティスを体現しており、脆弱性データ処理のニーズに対して、スケーラブルで信頼性が高く、そしてコスト効率の良いソリューションを提供している。純粋なLambdaの複雑さや、Glueの持つオーバースペックな面を避けながら、必要な要件を満たし、将来的な成長にも対応できる基盤を確立できたと言える。このような設計は、これからシステムエンジニアを目指す皆さんにとって、クラウドサービスを効果的に活用する良い例となるだろう。