AWS ElastiCache / SimpleQueueとDynamoDB
ElastiCache/SimpleQueueを使用する理由と、DynamoDB内に「キャッシュ」テーブルと「キュー」テーブルをそれぞれ持つ理由について疑問に思っています。
キャッシュ/キューサービスへのネットワークレイテンシはパフォーマンスの向上の多くに勝るようであり、EC2がDynamoをキャッシュ/キューサービスと同じように処理するため、Dynamoは同じレイテンシとスループットを提供します（Dynamoでは、負荷）。
それは主に、負荷のかかったダイナモと他のサービスの価格についてですか？
DynamoとElastiCache/SQSを比較したおおよそのレイテンシの数値はありますか？
追加の複雑さを正当化する他に欠けている重要な考慮事項はありますか？
ありがとう。
DynamoDBとElastiCache Redisを使用している理由はさまざまです。
DynamoDB：
- より複雑なことを実行できるクエリ言語があります（より大、より大など）。
- 外部のインターネット向けAPIを介して到達可能（変更や独自のインフラストラクチャなしで異なる地域に到達可能）
- テーブルまたは行に基づく権限も可能です
- データサイズの観点から無限大にスケーリング
- リクエストごとに支払う->リクエスト数が少ないほど請求額が少なく、リクエスト数が多いほど請求額が高い
- 読み取りと書き込みのコストは異なります
- データはAWSによって複数の施設に冗長的に保存されます
- DynamoDBはすぐに使用できる高可用性です
- 自動スケーリングはサービス自体で使用できます
ElastiCache Redis：
- シンプルなクエリ言語-複雑な機能はありません
- 他の地域からは（そのまま）到達できません。
- 常にメモリ量（またはクラスター内のすべてのプライマリインスタンスの合計）に制限されます
- 複数インスタンスのシャーディングはアプリケーション内でのみ可能です-Redisはここでは何もしません（Redisクラスターはここで役立ちますが、シャーディングロジックはアプリケーションで使用しているドライバー/ SDKの内部にあります）-スケールインとスケール現在、ダウンタイムなしではアウトは不可能です
- 負荷やリクエストの数に関係なく、インスタンスごとに支払います。
- データの冗長性が必要な場合は、レプリケーションをセットアップする必要があります（異なるリージョン間では不可能）
- 高可用性を実現するにはレプリカを使用する必要があります
- 自動スケーリングは利用できません（上記のスケーリングがないことに関する部分を参照してください）
したがって、ほとんどの場合のセットアップは次のとおりです。DynamoDBが永続的で耐久性のあるストレージとしてバックアップするRedisでの大量のリクエストを含むシンプルなキャッシュ。これにより、Redisのインスタンスごとの支払いモデルによる読み取りの暗黙的な割引が得られるため、コストが抑えられますが、DynamoDBの冗長性の利点も得られ、DynamoDBクエリ言語を使用してさらに複雑なもの（必要な場合）。
お役に立てば幸いです。
更新：Amazon DynamoDB Acceleratorの発表（ https://aws.Amazon.com/de/dynamodb/dax/ ）により、（最後に）DAXをそのまま使用するように切り替えますDynamoDBとRedisを組み合わせて使用していたこととまったく同じです。 DAXはAWSによって完全に管理されておらず、アプリケーションで常にDynamoDB言語を使用する機会を提供するだけでなく、Redisのようなライトスルーキャッシュのメリットも得ます。
DynamoDBではなくElasticacheを使用する主な理由は速度です-小さなオブジェクトの場合、ラウンドトリップ遅延が1ms未満になります。ボックスはEC2マシンに本当に近く、メモリはSSDよりもディスクよりもはるかに高速です。
さまざまな価格設定モデルを考えると、コストの利点もあるかもしれませんが、ここではそれほど詳しくは説明していません。
Redis/memcachedはメモリ内ストアであり、通常、キャッシュ/キュータイプのデータについてはDynamoDBより高速です。また、期限切れキー、RedisのPub/Subなど、Dynamoにはない便利な追加アイテムもあります。