RDSのマルチAZ化
RDSのマルチAZ配置で可用性、フェイルオーバを図ることができる。
Oracle、PostgreSQL、MySQL、MariaDBのマルチAZ配置
… Amazonフェールオーバ機能が適用
SQL Server DBのマルチAZ配置
…SQLサーバのミラーリングが適用
プライマリDBインスタンスのレプリカ（スタンバイレプリカ）が別のAZに複製される。
基本的にRDSマルチAZ配置しておけばフェールオーバがなされるため、障害耐久性が向上する
マルチAZ化のやり方:
新規DBマルチAZ化→ RDSコンソールDBインスタンス作成時に指定
既存DBマルチAZ化 → DBインスタンス変更しAZオプション指定
AWS CLI、 Amazon RDS APIからも可能 ＊参照: link
ポイント: レイテンシについて
マルチAZ使用DBインスタンスは、シングルAZ配置よりレイテンシが上がることがあるので、レイテンシの変動を抑えるために、プロビジョンドIOPSおよびDBインスタンスクラスを使用することが推奨される。
プロビジョンドIOPS… EBSボリューム値タイプの一つ
EBSのボリュームをプロビジョンドIOPSにすることで、マルチAZ化したときに発生するレイテンシを最低限に抑えることができる。
そのほかEBS汎用SSDがあるがプロビジョンドよりパフォーマンスに劣る。
プロビジョンド … 最大IOPS 64000
最大スループット 1000MB/sec
汎用 … 最大IOPS16000
最大スループット 250MB/sec
MySQLの高可用性構成
非同期レプリケーション … アップデート時に１つのDB更新し、時間がたってから別のDBに更新。
準同期レプリケーション…アップデート時にスレーブに変更情報が伝搬した（適用でない）時点でコミット
同期レプリケーション … アップデート時に全てのDBを更新する。
MySQLレプリケーションパターン
・マスタ＞スレーブ
・マスタ＞マルチスレーブ
・マルチマスタ＞スレーブ （非推奨）
・マスタ＞スレーブ＞マルチスレーブ
・マスタ＜＞マスタ
・循環型マルチマスタ
MHAについて
MHA
MySQLのマスタ障害時に最新スレーブをマスタとして昇格させ、自動的にフェールオーバを行うオープンソースツール
マスタ自動フェイルオーバの実現
マスタ無停止メンテの実現
MySQL5.0以降で動作
MySQLの特徴とMHAでできること
- MySQLはマスタ1つのみ
- スレーブの冗長化自体は簡単にできる
- MySQLのレプリケーションは非同期または準同期
- 同期ではないのでマスタ障碍児にスレーブが最新のログを受け取っていない場合がある
- なのでスレーブ間でのずれを解消する必要がある
- これを自動で解決するのがMHA
- 差分の計算、保存をスレーブ間で並列で行う
- 秒単位でのフェールオーバを実現
RDSでなくEC2環境でMySQLを動作させる際は、MHAでフェールオーバできる。（RDSでは自動）
Amazon DB クラスター構成
構造：
- クラスタは1つ以上のDBインスタンスと、1つのクラスタボリュームで構成される。
- クラスタボリューム … マルチAZ化された仮想データベースストレージボリューム
- クラスタはプライマリとレプリカDBインスタンスで構成される。
- プライマリは、全てのクラスタボリュームへの変更を実行する。
- レプリカは、読み取りのみ。ストレージボリュームに接続し、情報を取得。
- 一つのプライマリDBに対して15個のレプリカを持つことが可能。
- レプリカをマルチAZ化することで可用性を高められる。
- プライマリ障害時は自動的にレプリカにフェールオーバしてくれる。
- マルチマスタ構成にするとプライマリとレプリカの間で違いがなくなる。（全DBが読み書き可能になる）
データベースの拡張性保証
高可用性と拡張性
可用性 : 障害時の対処、リカバリ能力
拡張性 : データベース、クエリの負荷を複数のMySQLサーバに分散
シェアードナッシング ： 分散コンピューティングでのリソースの共有の排除
シャードデータベースアーキテクチャ
シャーディング : データを小さなサブセットに分割、それらを多数のデータベースサーバに分配する。
データパーティション設計とスキーマ設計
例 : customer_idをパーティションキーとする
Spiderエンジン
DBの分散処理を可能にするオープンソースツール
EC2でMySQL(Spider編１)
MySQL Spiderエンジンを使ってみた
・ 異なるMySQLインスタンスのテーブルを同一インスタンスのテーブル用に扱うことが可能
・ 更新系DBのクラスタリングに利用可能
・ パーティショニングルールで同一テーブルテーブルを複数サーバに分散配置が可能
・ 仕組み的にはストレージエンジンのテーブル内でシンボリックリンク的な動きをする
・ ローカルMySQLサーバからリモートMySQLサーバへのコネクションで実現
・ リンク先テーブルのストレージエンジンに制限はない
・ ＭｙＳＱＬ、ＭａｒｉａＤＢはサポートされているが、Ａｕｒｏｒａはされていない
1100万以上のユーザデータのスケーリング事例
Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズガイド
スケーリングに必要な要素
・ フェデレーション : データベースを機能に基づき複数のDBに分割
・ シャーディング : 上記説明
・ 従来型リレーショナルSQLデータベースを使用
・ SPOFをなくす（すべての段階を冗長化）
・ インフラの内部、外部のデータをキャッシング
・ インフラ内での自動化ツールの利用
・ メトリクス、モニタリング、ロギングを配備しアプリケーションのパフォーマンスを監視
・ ティアをSOA化
・ Auto Scalingの使用
～まとめ～
・データベースの拡張性、可用性を上げるには、前提として、データベースはAuroraを使用。AWS上でマルチAZ化され、システムは必要であればサービス指向で構成されているものとする。
・可用性、拡張性を保証する手段の一つとしてシャードデータベースアーキテクチャがある
・同じテーブルを複数のデータベース（シャード）に分散して処理の効率化を図る
・異なるシャード間でのデータ共有を排除することにより、データアクセスへのレイテンシを減らす
・障害発生時もシャード毎でフェールオーバするので、拡張性も保証される。
・オープンソースのSpiderというソースを使用することで、コーディングの手間を省き、分散処理を実現することが可能。
おわり