リレーショナルデータベース

Amazon Aurora

• MySQL, PostgreSQLと互換性あり 同等のパフォーマンスと可用性を1/10のコストで実現
• 3つのAZ間でレイテンシの低いリードレプリカを最大15個追加できる
• 分散型で耐障害性と自己修復機能を備える
  • プライマリDBクラスタ設置リージョンと別のリージョンにリードレプリカを作れる
  • 障害回復機能の向上
• マルチAZ構成による高速フェールオーバー
  • Auroraのinnodb_read_onlyグローバル変数によりMasterとSlaveの接続先を変更
• 自動バックアップ...最大 35 日まで設定可能

エンドポイント

ホストアドレスとポートを含む固有のURLとして表される

• クラスターエンドポイント
  • DBクラスターのプライマリDBインスタンスに接続
  • 唯一書き込み処理ができる
• リーダーエンドポイント
  • DBクラスターへの読み取り専用接続を負荷分散
  • クエリなどの読み取りオペレーションで使用
• カスタムエンドポイント

Auroraサーバレス

• AuroraのオンデマンドのAuto Scaling設定
• アプリケーションの状態に応じて自動的に起動、シャットダウン、容量変更ができる
• 不定期、断続的、または予測不能なワークロード向き

Amazon Aurora Global Database

• 単一のAuroraデータベースを複数のAWSリージョンにまたがって運用できる
  • →リージョン規模の停止から災害復旧
• クロスリージョンレプリケーションのレイテンシは通常1秒未満

Amazon RDS

• マネージド型サービス
• マルチリージョンは非対応
• 推奨ストレージ: InnoDB
• 最大5つのリードレプリカを利用可能

リードレプリカ

• 非同期にレプリケートされる個別のデータベースインスタンス
  • レプリケーションラグ: レプリケーションデータが遅れ、最新のトランザクションが反映されない
• パフォーマンスと耐久性向上
• 読み取りと書き込みを分離し、読み込み処理を担当させ負荷緩和
• RDS, Auroraは対応 DynamoDBは非対応
• リードレプリカには自動フェイルオーバーはないよ

ストレージの自動スケーリング

• 空き容量不足を自動で検出し、自動でスケールアップ
• インスタンス新規作成時あるいは既存のインスタンスで設定できる

シャーティング

• DB内の複数テーブルにデータを分割

フェイルオーバー

• 複数のAZにデータを複製し、障害時に複製したDBを参照
• Oracle, PostgreSQL, MySQL, MarinaDBで利用される
• SQLサーバは独自のDBM(データベースミラーリング)機能を使用

マルチAZ配置

• DBの可用性と耐久性を強化
• プライマリDBインスタンスが自動的に作成されると同時に、異なるAZのスタンバイインスタンスにデータが複製される
  • 障害が起こるとスタンバイに自動でフェイルオーバー

RDSプロキシ

• Amazon RDS Proxy の使用
• アプリケーションとDBの仲介機能
• 必要となるDBのコネクションプールを確立及び管理し、アプリケーションからのDB接続を少なく抑える
  • 耐障害性の向上
• AWS LambdaでAmazon RDS Proxyを使用する
  • DBインスタンスと直接接続すると、Lambdaから大量にコネクションが発生し過負荷となる
  • RDS Proxyと対話することで、大量の同時接続をスケーリングするのに必要なコネクションをプーリング
    • Lambda関数ごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用

拡張モニタリング

• DBインスタンスが実行されているOSのメトリクスをモニタリング
• 設定と有効化
  • 拡張モニタリングへのアクセス用IAMロール作成
  • DBインスタンス作成時 or 変更時にコンソールからモニタリングを有効にできる
• メトリクス例
  • RDS Child Process: DBインスタンスをサポートするRDSプロセス
  • RDS プロセス
  • OS プロセス

Amazon RDS on Outposts

• オンプレミスの環境でRDSをデプロイ
• 現在SQL Server、MySQL、PostgreSQLをサポート

Amazon RedShift

• データウェアハウス用として利用可能な列指向型データベース
• シングルAZ配置のみサポート
• スナップショット用に無料ストレージを提供
  • 空き容量が上限に達すると課金が発生

クロスリージョンスナップショット

• プライマリークラスタがダウンした場合に備えて即座に利用できる構成を維持できる

データベース暗号化

• KMSとは自動的に統合されている
• HSMと統合するには、RedShiftとHSMの間で信頼された接続を設定する必要がある

拡張VPCルーティング

• RedShiftクラスターとデータリポジトリ間の全てのCOPY及びUNLOADトラフィックがVPCを通るよう強制
  • Redshiftクラスターと他のリソース間のデータフローを監視できる
• スタンダードVPC機能が利用可能になる(セキュリティグループ、ネットワークACL、VPCエンドポイント、igw、DNSサーバetc)
• RedShiftと他のリソース間のトラフィックをVPC内に制限できる(インターネットを介さない)

RedShift Spectrum

• 多数のユーザが同時に分析レポートを発行したり、より複雑な検索クエリや分析シナリオを利用できたりする
• S3のエクサバイトの非構造化データに対してSQLクエリを直接実行できる

WLM (Work Load Manager)

• クエリ処理を実行する際、クエリ処理をキューとして実行順序を定義

NoSQL

DynamoDB

キャパシティモード

• オンデマンド: 利用した分だけ
• プロビジョニング済み: あらかじめ予測される読み書き回数を指定し、その分の性能が確保
• データ処理の分散: リクエストをSQSに格納し非同期に処理→キューをトリガーにしてlambdaで処理実行
• データ整合性モデル: 結果的に整合性のある読み取り設定 or 強い整合性設定 を指定できる　

DynamoDBストリーム

• DBテーブルへの変更ステータスが履歴として残る
• ↑をトリガーにLambda関数の動作をしたり、モニタリングで変更管理の実施をしたりできる

DAX(DynamoDB Accelerator)

• DynamoDBと互換性のあるキャッシュサービス
• マイクロ秒単位の応答を必要とするユースケースに利用 (DynamoDBの応答時間はミリ秒単位)
• 最大10倍のパフォーマンス向上
• DynamoDB Accelerator (DAX) とインメモリアクセラレーション
• コスト効率が高いのはDAXよりSQSによる処理分散

クライアント/サーバ暗号化

• サーバ側暗号化
  • HTTPS接続を介して転送中に暗号化→DynamoDBエンドポイントで復号化→DynamoDB保存前に再暗号化
• クライアント側暗号化
  • ソースからDynamoDBストレージまで、転送中および保存中のデータを保護
  • DynamoDBにアプリケーション暗号化機能を追加する必要あり

DynamoDB AutoScalingによるスループット容量の自動管理

• 実際のトラフィックパターンに応じてスループットを調整
  • →トラフィックの急増に対応

ElastiCache

• 高速なキャッシュ処理用
• インメモリ型
• ユースケース
  • アプリケーションのパフォーマンス向上
  • バックエンドデータベースのロードを容易に
    • データをキャッシュしてバックエンドデータベースの負荷軽減
  • 低レイテンシのデータストア構築
    • リアルタイムアプリケーションをサポート
• リザーブドキャッシュノード
  • 予約するキャッシュノードごとに定額の予約金を一括で支払い 大幅な割引が受けられる
• Memcached と Redis の比較

Redis

• pub/sub機能が必要
• シングルスレッド
• Redis AUTH コマンドによるユーザーの認証

Memchached

• マルチスレッド
• ランキングやレコメンデーションの実装に便利な機能を有する