AWS SAA 合格体験記

S3 は強い整合性モデル．アップデートがオブジェクトに対して同じキー名で設定しても，誤差が生じることがない．not 結果整合性モデル．

ストレージクラス．

• STANDARD

  • 複数個所にデータを複製するため耐久性あり

• STANDARD-IA

  • Infrequent Access
  • 低頻度アクセスデータ用
  • データ取得は早い
  • Standard より安い

• OneZone-IA

  • マルチ AZ されていないので可用性が低い
  • Standard-IA より安い

• INTELLIGENT_TIERING

  • 高頻度と低頻度(Standard-ia)のアクセスを自動的に判断して適切なストレージクラスに配置
  • アクセスパターンが不明な場合に有効
  • 最初は Standard に配置
  • 30 日アクセスがないと Standard-IA に移動
  • 90 日アクセスがないと Glacier に移動
  • 180 日アクセスがないと Glacier Deep Archive に移動

• S3 Glacier

  • 1 年に 1~2 回くらいのアクセス用
  • データ検索で 3~5 時間かかる
  • 迅速取り出しというちょっとお金がかかる取り出しを使うと 2~5 分で取り出せる

• S3 Glacier Instant Rtrieval

  • アクセスされることがほとんどなく，ミリ秒単位の取り出しが必要な長期間有効なデータ向け
  • 医用画像やニュースメディアなど
  • S3 Standard と同じパフォーマンス

• S3 Glacier Deep Archive

  • 7~10 年以上保持される長期間使用されるが，めったに取り出さないデータ向け
  • 標準の取り出しで 12 時間以内かかる

• S3 Transfer Acceleration

  • edge を使って地理的に近いとこにアップロードするため高速でアップロードできる

• S3 レプリケーション

  • リージョン間をまたぐ S3 の複製
  • 別アカウントへの複製も可能

• 6 つの柱
  • Reliability 信頼性
  • Performance Efficiency パフォーマンス効率
  • Security セキュリティ
  • Cost Optimization コスト最適化
  • Operational Excellence 運用の優秀性
  • Sustainability 持続可能性

上 4 つが SAA の試験範囲．Well Architected Framework を利用することで，最適解や改善点を見つけることができる．ただ，あくまで参考であり，絶対ではない．

• ELB

  • ヘルスチェック
  • クロスゾーン負荷分散
    • オフだと AZ 間で均衡
    • オンだとインスタンスごとに均等(ゾーンレベルでは不均衡)
  • スティッキーセッション
    • セッション維持のために，端末が別インスタンス宛にならないようにする機能
  • Connection Draining
    • インスタンスに異常が発生した場合，そのバックエンドインスタンスへの指定した数秒は通信が切れずに，処理中のリクエストが終わるまで一定期間待機する

• Auto Scaling

  • 負荷が高まった時に，新しくインスタンスを増設してくれる機能
  • 垂直スケーリング
    • サーバの性能の増強
  • 水平スケーリング
    • マシンの台数を増加
  • 起動テンプレートから起動設定を設定
    • 閾値の設定等をする

• RDS

  • プライマリとセカンダリは自動同期
  • プライマリに障害が発生した場合，自動でフェールオーバーが実行．セカンダリがプライマリに昇格
  • Aurora ではリードレプリカからプライマリに昇格可能
  • キャッシュ
  • ElastiCache がインメモリ DB
  • MySQL なら MemCached 機能を利用することも選択肢

• Dynamo

  • 大量の読み書きには向いていない

  • IoT データとか，ゲームのセッションデータとかに向いている

  • 無制限に性能を拡張可能

    • テーブルサイズには制限なし
    • データ項目は 400kb まで

  • 高可用性

  • DAX つかえば高速になる

    • インメモリキャッシュ

  • デフォルトでは結果整合性

    • オプションで強い整合性モデル

  • オンデマンドモード

    • ストレージ，Read, Write により，課金
    • Read/Write を自動スケーリング

  • プロビジョニングモード

    • 設定したキャパシティに基づいて課金
    • キャパシティ要領に近づくと HTTP400 を返す

  • クロスリージョン可能(別料金)

  • Dynamo DB ストリーム

    • データのイベントをキャプチャできる機能
    • 24 時間以内の履歴を参照できる
    • Kinesis と連携してイベントをストリームする

  • バックアップ

    • オンデマンドバックアップ
      • 任意のタイミングでテーブルの完全なバックアップの作成
      • 長期間の保存とアーカイブを実施
    • ポイントインタイムリカバリ
      • 連続バックアップを有効化して，バックアップを継続的に実施
      • 最大 35 日間の任意の地点にテーブルを復元可能

  • セカンダリインデックス

    • プライマリキー以外にインデックスを作りたいときに作成する

  • TTL

    • データの生存時間を設定できる

• Aurora
  • 自動で 3 つの az にコピー
  • 各コピーは仮想ボリュームで，これを 1 つの DB としてみている
  • リードレプリカは最大 15 個(RDS は最大 5 個)
  • マスタに障害が起きると，リードレプリカがマスタに昇格してフェールオーバー
  • マスタを複数作ることもできる(マスタ・スレーブ構成)

• Aurora サーバレス
  • Aurora と同様に自動で CPU 数などをスケーリングしてくれる
  • エンドポイントを使用して接続せずに SQL を実行できる
  • 変動が激しい場合にサーバレスの利用

• Redshift

  • マルチ AZ で自動フェールオーバーもできる

  • プライマリのリージョンで障害に起きたとき，別 AZ に自動で移動することも可能

  • ただし，スナップショットからの復元のためちょっとダウンタイムがある

    • コンピュートノードをリザーブドノードにするとコスト削減が可能

  • 利用時間が限られるなら Redshift Serverless を使用するほうがコストが低い

    • Redshift から移行可能

  • Redshift Spectrum

    • S3 にあるデータをぶんせきできる

• ElastiCache

  • インメモリキャッシュ DB

    • Memcached は一時的．基本的に Redis を使用

  • Encryption In Transit

    • 通信路の暗号化

  • Redis Auth

    • 認証

  • Encryption at REST

    • 保存時の暗号化

ちゃんと処理がおわったら Delete MessageAPI で削除する．

• 標準キュー

  • 重複の可能性あり
  • なるべく順番通り

• FIFO キュー

  • 順番通り
  • トランザクション数に制限ができる

アクセスポリシーで許可などの設定．

可視性タイムアウトを設定することで一定期間 1 つのコンシューマだけがそのメッセージを閲覧できるようになる．