本日勉強したことをメモします。
EC2インスタンスストアのボリュームをバックアップする方法
EC2インスタンスストアを使用してMySQLを起動している場合、インスタンスストアは揮発性なので再起動するとデータが消えてしまう。
そのため、以下の対応をしてバックアップを取る。
・データベースファイルストアをS3にバックアップする。
・新しくEBSボリュームを作成し、EC2にそのボリュームをアタッチする。マイグレーションツールなどを用いてMySQLデータベースをEBSにエクスポートする
上記対応を行うためAMIなどを作成する必要はない。また、インスタンスストアボリュームはスナップショットを作成することはできない。スナップショットを作成できるのはEBSのみ。
インスタンスストアボリュームのAMI作成方法
AWS CLIツールを使用してボリュームのバンドルをS3にアップロードし、そのS3上のファイルを使用してAMIを作成することができるようです。
具体的なイメージまではまだできていませんが、概要をまず押さえておく。
DynamoDBでProvisionedThroughputExceededExceptionが頻発する場合の対応
DynamoDBでProvisionedThroughputExceededExceptionが頻発する場合は以下のような対応が考えられる。
・CloudWatchコンソールから確保されてるキャパシティと消費されたキャパシティを確認する
・書き込み、読み込みキャパシティを増やす。その後、ログを見て問題が解消されたか確認する
リザーブドRDSインスタンスをAWS Organization内の別アカウントで使う時のポイント
購入済みのリザーブドRDSインスタンスをAWS Organization内の別アカウントで使う時は、以下の点を守らないとリザーブドインスタンスの割引が適用されない。
・どちらも同じリージョンである
・どちらも同じDBエンジンである
・どちらも同じDBインスタンスクラスである(m1.largeとか)
・マルチAZの有無は同じである
RTOとRPOの意味
RPO（Recovery Point Objective）とは、障害発生時、過去の「どの時点まで」のデータを復旧させるかの目標値である。例えば更新頻度の少ないシステムでは、障害発生の24時間前までのデータ（RPO＝1日）で復旧できれば支障ないこともある。逆に24時間365日連続的にサービスを提供する通販サイトでは、復旧時に停止直前までのデータ（RPO＝0秒）が求められる。
RTO（Recovery Time Objective）とは、障害発生時「どのくらいの時間で（いつまでに）」 復旧させるかを定めた目標値である。言い換えると、RTOは「システム停止やサービス中断が許される時間」とも言える。
