今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照/更新クエリを実行しています デ
Zero-Downtime Patching の機能が使えるようになりました No maintenance No Life なRDSに、遂にAuroraバージョン1.10からですがダウンタイムゼロでメンテナンスが実施できるようになりました。 https://aws.amazon.com/jp/blogs/aws/amazon-aurora-update-spatial-indexing-and-zero-downtime-patching/ PostgreSQL互換といい、Lambda連携といい(Lambda連携は動作保証が今のところ0回以上なので今後の改善に期待ですが1)、 そろそろAuroraを選択しない理由がなくなってきた感があります。 それでもAuroraを選択しない理由 t2.medium未満のインスタンスタイプで稼働可能なシステム コストをできるだけ節約したい場合 どうしてもb
ウィスキー、シガー、パイプをこよなく愛する大栗です。 Auroraへ移行するお話を頂くことが増えてきました。そこでAuroraへの移行時における冗長化のポイントを考えてみました。 RDSのSLA定義はMulti-AZが前提である旨を追記しました。 そもそもMulti-AZって? ここではMySQLの場合のMulti-AZについて述べます。 Single-AZでは、以下の問題があります。 耐久性: ストレージボリュームで障害が発生した時には、「最新の復元可能な時刻」以降のデータ更新が失われる。 可用性: ハードウェア障害が発生した時に、インスタンスを再作成するため再接続までの時間が必要になる Auroraを除くRDSではストレージボリュームにEBSと同等のものが使用されているようなので通常のディスクに比べて高い可用性と信頼性を備えています。 補足すると、EBSについての具体的な数字としては「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く