rainit2006
commented
7 years ago EC2インスタンスをスケールアップ https://recipe.kc-cloud.jp/archives/1348 スペック不足になった場合でも、このようにEC2インスタンスを1度、停止してインスタンスタイプを変更するだけで簡単にスケールアップをおこなうことができます。
Auto Scaling http://qiita.com/iron-breaker/items/2b55da35429da7b19e49 インスタンスの数を自動で増減できる インスタンスの数は最少、最大を指定する 増減のトリガーはCloudWatchのメトリックスを指定できる 増減のトリガーは時間を指定できる
Amazon Aurora なぜ RDS for MySQLからAuroraへ移行？
※移行案として グーグルの「Cloud SQL」でのMySQLの使用や、「Cloud Database」などは有力な選択肢であったが、Cloud SQLではRDS for MySQL以上のパフォーマンスが出ていなかったこと、Cloud Databaseは大掛かりな移行が必要なことから移行を見送っていた。
Auroraに移行したことで、レプリカラグの課題は解消した。Auroraを複数台で運用してもレプリカラグは数ミリ秒から数十ミリ秒の間に抑えられており、ほとんど気にする必要がない。
RDS for MySQLではマスター1台とスレーブ5台だったシステム構成を、Auroraではマスターとスレーブ1台ずつという構成に変更できた。その後ユーザー数の増加に伴って構成は変更しているが、対処可能なユーザー数は数十倍に増えている一方、Auroraは数台のインスタンス増加にとどまっている
Auroraを複数台で利用する際は、マスターとなる1台のインスタンスのみ読み書きが可能で、その他は読み込みしかできない。Auroraのリリース直後は、マスターに障害が発生したり再起動したりした際、どのスレーブがマスターに昇格するか、ユーザーがコントロールできなかった。現在では、機能強化によってインスタンスに優先順位を付けられるようになった。障害時には同じ優先度が付いたインスタンスの中で切り換えを試み、それが失敗すると優先度の高い順に切り換えるという動作になっている。
Auroraでは、マスターとなるインスタンスには「クラスターエンドポイント」と呼ばれるホスト名（URL）を通じてアクセスできる。クラスターエンドポイントを使えば、再起動や障害が起こってマスターが変更された際も、同じホスト名でアクセスできる。ただしこの機能では、前述のインスタンスに優先順位を付ける機能は考慮されていない。どのインスタンスをリーダーエンドポイントに結びつけるかも設定できず、インスタンスを目的別に使うといったことができない。この点については今後の解決が期待されるが、現在のところ開発者側で留意する必要がある。
インデックスは必須。MySQLと同じく、Auroraでもインデックスは必須に近い。特にAuroraの場合、分散しているストレージから特定のデータを検索するという仕様のため、インデックスがないテーブルからの検索は極端に遅くなる場合がある。これも、実際のアプリケーションと同じデータで試すことが望ましい。