【Diagram】消費者の購買傾向からレコメンドを提案するECサイト
■WAF＋CloudFront＋Cognito＋Lambda
<セキュリティ>
１．アプリケーション層への攻撃。SQLインジェクション、XSS（クロスサイト・スクリプティング）、OSコマンドインジェクション等々から保護するために、WAFを導入。
（AWS Shieldを併用することで、L3(ネットワーク層)・L4(トランスポート層)のDDos攻撃から保護可能）
標準ルールやカスタムルールを作成し、レートベースのルールにより、大量のHTTP GET による攻撃を緩和することが可能。レートベースのルールで特定のリクエスト条件やウェブサイト全体のアクセスに閾値を定義することにより、5 分間あたりの同一IP アドレスからのリクエスト数が設定された閾値を超過した場合にそのIP アドレスからのリクエストをブロックすることが可能。
２．ユーザ認証のため、Cognito
３．Amazon CloudFront では、最新バージョンのトランスポート層セキュリティ (TLSv1.3) を使用して、コンテンツ、API、またはアプリケーションを HTTPS 経由で配信し、ビューアクライアントと CloudFront 間の通信を暗号化し保護が可能。
AWS Certificate Manager (ACM) で独自 SSL 証明書を簡単に作成し、CloudFront ディストリビューションに無料でデプロイ。証明書の更新は ACM によって自動的に処理されるため、手動更新プロセスの諸費用を節約できます。
<可用性>（システムが利用可能な状態を維持する能力）
１．オリジンフェイルオーバー
急激なリクエストの増加からのオリジンサーバーの保護が可能なため、CloudFrontを利用
プライマリのオリジンサーバーに障害が発生した場合に、事前に登録したセカンダリのオリジンサーバーにフェイルオーバー可能。
同一コンテンツに対するフラッシュクラウド（急激なリクエストの増加）に対して、最初のリクエストのみオリジンサーバーへ送り、後続のリクエストはそのレスポンスを活用することにより、同じ大量のリクエストをオリジンサーバーへ送信しないようにする負荷低減の仕組みを備えている。
<コスト>
１．認証システムの開発コスト低減
<パフォーマンス効率>
１．エッジロケーションでのサービス配信やキャッシュによる高速配信が可能。
静的コンテンツの処理をCloudFront＋S3にオフロード
■APIGateway＋Lambda＋DynamoDB＋SNS＋SQS
<可用性・スケーラビリティ>
１．APIキーと使用量プランを使用して、スロットリングの設定をすることで、リソースの保護も可能。
２．DynamoDBを選択
人気商品の発売時などリクエスト数が急激に跳ね上がるイベントがあり、その際には、特定の在庫データへのアクセスも集中します。その結果、ＤＢが高負荷状態になり、エラーが多発するという課題が考えられます。
システムダウンによる機会損失を防ぐために、データの一貫性を一部犠牲にして、高可用性・高拡張性に重きを置きました。
リレーショナルデータベースの場合、同時接続数が最大で「16,000」で場合によっては、同時接続数の上限に達し、エラーになる可能性もあります。
また、同時接続数を最大「16,000」を維持するためのコストがかなりかかります。
データの一貫性を一部犠牲にして、高可用性・高拡張性に重きを置きました。
費用対効果が高い。
デメリットとしては、DynamoDBは結果整合性が担保されているが、一時的に古い情報が閲覧される可能性がある。
・補足
RDSのメリット：
データの一貫性（Consistency: どこから観測しても同じ値が得られること）や操作の原子性（Atomicity: 一連の操作を全て適用commitするか、全てキャンセルrollbackするかの二択として実現できること）
<コスト>
１．APIGatewayを使用することで、WebAPIの開発コストを削減でき、Backendの開発に集中できる。
<パフォーマンス効率>
１．SQS/SNSを使用して、非同期処理にしたことで、ユーザの待ち時間を減らしパフォーマンスを効率化
■EventBridge＋StepFunctions＋Glue＋Athena＋Fargate
<信頼性>（期待されるタイミングで、意図した機能を正確かつ一貫して実行するワークロードの能力。）
EventBridge + StepFunctionsを使用して、指定した時刻にお勧め商品提案機能を実装可能。
また、Sagaパターンを意識して、StepFunctionsを使用しました。
・Sagaパターンについて
分散アプリケーションの一貫性を確立し、複数のマイクロサービス間のトランザクションを調整してデータの一貫性を維持するのに役立つ障害管理パターンを意味しています。
私が作成した構成では、StepFunctions内でDynamoDBからエクスポートしてDataCatalogを作成しています。その後に、AthenaでSQLクエリを実行し、機械学習するための前処理を実装しています。仮に、何かしらの理由でAthenaのクエリが失敗したとき、EventBridgeが起動する前の状態に戻すために、補償トランザクションを実行し、DataCatalogやS3のエクスポートしたデータを削除する必要があります。
今述べたことを満たすためにStepFunctionsを使用しました。
<パフォーマンス効率>
１．Athena
安価に高速にSQLクエリを実行することが可能なため。また、SQLクエリした結果を手軽にプログラムに利用できるからです。必要に応じて、Lambdaやサーバを立てて、クエリ結果をさらに前処理する。
Glue data catalogのデータをもとに、DynamoDBからS3へエクスポートしたデータ参照し、機械学習ができるようにデータを前処理するのに最善と判断し、GlueとAthenaを使用しました。
２．Fargateの代わりに、Amazon Personalizeを使用するのでも可。
■考えられる課題
１．各機能のステータスがわからない。
・解決方法：
ステータス確認APIをLambdaなどで作成し、ステータスがわかるようにする。
２．各機能の一連フローのどこかで不具合が生じたとき、恒久的なデータの不整合が発生してしまう。
・解決方法
Sagaパターンを意識して、補償トランザクションを実装できるようにするために、StepFunctionsを使用する。
SNSやSQSを使用して、データ不整合が発生したときに、補償トランザクションを実行するためにイベントを発行する。
３．処理の順序性
先着何名などのイベント時には処理の順序性も意識する必要がある。
・解決方法
FIFOトピックやFIFOキューを使用して、順序性を担保する。
４．非機能
Cloudtrail
Cloudwatch
AWS Config
AWS Security hub
を導入してよりセキュリティを強化する。
Discussion