きっと、うまくいく~非IT業界をスクラムで変えるための系譜~

一人のPO見習いが業界を変えるために奔走する様子をただただ綴るブログです。

【AWS再入門】5分でわかるRDS

さて、前回から始めたAWS再入門シリーズ。 今回は業務でもAuroraの理解が再度必要になったのでAmazon RDSについてです。

ちなみにEC2はこちら

passionate-po.hatenablog.com

Amazon RDSとは

  • Amazon Relational Database Systemの略
  • 構築、運用、拡張が容易なフルマネージドのリレーショナル・データベース
  • インスタンスのStart/Stopが可能(最大7日間)

 Amazon RDS でマルチ AZ データベースインスタンスの停止および起動が可能に

対応エンジン

制限事項(Oracle Databaseの場合)

  • バージョンが限定される
  • キャパシティに上限がある
  • OSログインやファイルシステムへのアクセスはできない
  • IPアドレスは固定できないRAC,ASM,DataGuard,RMANなどは使えない
  • 個別パッチは適用できない

マルチAZデプロイメント(Multi-AZ)

  • 複数のAvailability ZoneにMasterとSlaveのインスタンスを配置
  • MasterとSlaveは同期される
  • Masterのインスタンスやハードウェアの障害があった場合、自動でSlaveがMasterに昇格(フェイルオーバー)される
  • 手動リブートによる強制フェイルオーバーも可能

リードレプリカ

インスタンスタイプ

  • EC2と同様 vCPU、メモリ、EBS最適化、ネットワークの組合せで決まる。
  • ストレージタイプは下記3タイプ
  • 汎用SSD
  • プロビジョンドIOPS
  • Magnetic
  • ストレージサイズは16TBまで(MySQL,Oracle,MariaDB,PostgreSQL)

スナップショット

  • 日時でデフォルトでスナップショットとトランザクションログが自動でS3に保存される。
  • 保存期間は最大35日分
  • 自動スナップショットはインスタンス削除時に削除される
  • 上記とは別に手動でスナップショットは任意で取得可能。削除も自由
  • スナップショットを元にインスタンスを立ち上げることが可能(リストア)
  • リージョン間、アカウント間でコピー可能
  • スナップショット実行時にI/Oが一時停止する(マルチAZの時は気にしなくてOK)

メンテナンスウインドウ

  • 数ヶ月に一度発生するメンテナンスのタイミングを何曜日の何時に実行して欲しいのかユーザーが指定する
  • 指定した時間帯の中で数分間実行される(詳細な時間は内容による)

暗号化

  • DBインスタンス、自動バックアップ、リードレプリカ、スナップショットを暗号化可能
  • データアクセスと復号の認証は透過的に処理するので気にしなくて良い
  • AWS KMSで鍵管理が可能
  • 対応しているインスタンスタイプは限定される
  • インスタンス作成時のみ設定可能

Amazon Aurora

  • Amazonクラウド時代向けに再設計したDB
  • MySQL5.6、5.7互換
  • MySQLのエコシステムをそのまま活用可能
  • 多くの3rd Party監視ツールを利用可能
  • 3つのAZの6つのディスクに書き込まれる  - 2つのディスクに障害が起きてもread/writeが可能  - 3つのディスク障害が起きてもreadが可能
  • キャッシュとログがプロセスから分離されているので、再起動をしてもキャッシュが残る
  • AES-256で暗号化
  • KMSを利用したキー管理が可能
  • SSDを利用したシームレスにスケールするストレージ
  • リードレプリカもマスタと同じストレージを参照
  • 増分を継続的にS3にバックアップ
  • 64TBまでシームレスに拡張するストレージ
  • 自動で際ストライピング、ミラー修復、ホットスポット管理、暗号化
  • リードレプリカが存在する場合、1分程度でフェイルオーバー
  • クラスタ(WriterとReaderのセット)で常にWriterを示すEndpointが存在する
  • 各ノードそれぞれにEndpointを持っている
  • そのため、フェイルオーバ発生時はノードの昇格が行われ、クラスタEndpointのさし先が変わる
  • Adaptive Thread Pool:アクティブなスレッドに複数コネクションがはられている。スレッド数は動的に変わる
  • MySQLのSnapshotから作成可能

料金モデル

Aurora以外

  • DBインスタンス($/時間)  - 1時間単位で利用可能  - ライセンス込み or BYOL  - DBエンジン、インスタンスタイプ、 Multi-AZなどで料金が変わる
  • ストレージ($/GB/月)  - ストレージ容量、I/Oリクエスト数  - バックアップストレージ容量($/GB/月)
  • データ転送  - 別のリージョンへのデータ通信($/GB)  - インターネットへのデータ通信($/GB)

Aurora

  • DBインスタンス($/時間)  - 1時間単位で利用可能  - MySQL互換 or PostgreSQL互換  - DBエンジン、インスタンスタイプ、 Multi-AZなどで料金が変わる
  • ストレージ($/GB/月)  - ストレージ容量、I/Oリクエスト数  - バックアップストレージ容量($/GB/月)
  • データ転送  - 別のリージョンへのデータ通信($/GB)  - インターネットへのデータ通信($/GB)

2つの価格モデル

まとめと私の思うポイント(あくまでテスト対策)

  • パフォーマンスを考えるとAuroraを採用するのが解
  • ただ、考え方の根本が異なるので、理解を深めてチューニングしないとパフォーマンスがイマイチなことも
  • デフォルトのパラメータグループで最適サイズのインスタンスを選ぶことから始める。
  • うまくいかなかったらパラメータグループをいじってみるのが良いかも
  • クエリの同時実行数やテーブルサイズが大きい時に有効と言われているが、そこまでこだわらず、基本的にAuroraで良い気もしている
  • 複数のサーバにシャーディングしている場合、1つのAuroraにまとめると良さそう(内部的には一つではないので)
  • 現在がMySQLで動いてたら、そのスナップショットから作成してみるとはじめやすいかも。