詳細技術解説：Redis/Memcachedの高度な機能完全ガイド
東京、大阪、福岡に銀行支店があるイメージです。各支店は独立した電力、通信回線を持ち、一つの都市で災害が起きても、他の都市の支店で業務を継続できます。さらに、各支店間でリアルタイムにデータを同期しているため、どの支店でも同じサービスを受けられます。
レプリケーション仕組み： プライマリノードからレプリカノードへ非同期でデータを複製。RPO（Recovery Point Objective）は通常数秒以内。
ネットワーク分離： 各AZは物理的に分離されたデータセンターで、独立した電力・冷却・ネットワークインフラを持ちます。
Multi-AZ構成により、インスタンス数が増加（プライマリ + レプリカ）するため、 コストは約2-3倍 になります。しかし、ダウンタイムによる機会損失を考慮すると、多くの場合コスト効果は高いです。
メインのレジが故障したら、AIが即座に故障を検知し、自動的にサブレジに切り替わります。さらに、レジのデータ（商品マスタ、在庫情報）も瞬時に同期され、お客さんは何の違和感もなく、待たされることなく会計できます。店員が手動で切り替える必要もありません。
障害検知メカニズム： ElastiCacheは30秒間隔でプライマリノードのヘルスチェックを実行。3回連続で応答がない場合、障害と判定。
フェイルオーバー時間： 通常1-6分以内。DNS TTLが60秒の場合、アプリケーションの再接続時間を含めて完了。
データ整合性： 非同期レプリケーションのため、最大数秒のデータロスの可能性あり。
一つの巨大なレストランではなく、専門店（寿司、焼肉、中華、イタリアン、フレンチ、カフェ）に分けて運営します。お客さんは料理の種類に応じて自動的に適切な専門店に案内され、各店舗が得意分野の注文を並列処理します。新しい専門店の追加も、既存店舗の営業を止めることなく可能です。
シャーディング方式： CRC16ハッシュアルゴリズムを使用。16,384個のハッシュスロットに分散。
ノード間通信： Gossipプロトコルでクラスタの状態を共有。各ノードが他の全ノードの状態を把握。
スケーリング限界： 最大1,000ノード、合計最大500TBまでサポート。
お客さんの迷惑をかけずに、営業しながらショッピングモールのテナント配置を最適化します。人気店舗が集中している階の負荷を分散するため、一部の店舗を段階的に他の階に移転させます。移転中も店舗は営業を続け、お客さんは移転先で同じサービスを受けられます。全体の効率が向上し、混雑も解消されます。
移行方式： ハッシュスロットを段階的に移行。1つずつスロットを移動し、データ整合性を保持。
移行速度制御： 本番環境への影響を最小化するため、移行速度を調整可能。
ダウンタイム： 完全にゼロダウンタイムで実行。クライアントからは透明。
リシャーディングにより、 負荷分散で個々のノードサイズを小さくできる 場合があります。例：r6g.2xlarge × 3台 → r6g.xlarge × 5台で、コストを抑えつつ性能向上が可能。
構成: Redis（Non-Cluster）+ Multi-AZ + 自動フェイルオーバー
ノード: cache.r6g.large × 2台（プライマリ + レプリカ）
容量: 〜50GB、〜10,000 RPS
月額コスト: 約$200-300
構成: Redis Cluster + Multi-AZ + オンラインリシャーディング
ノード: cache.r6g.2xlarge × 6台（3シャード × 2レプリカ）
容量: 〜500GB、〜100,000 RPS
月額コスト: 約$2,000-3,000
構成: Global Datastore + 複数リージョン
地域: 東京、シンガポール、バージニア
容量: 〜2TB、〜500,000 RPS
月額コスト: 約$8,000-12,000
Created by SSuzuki1063
AWS SAP Learning Resources