読者です 読者をやめる 読者になる 読者になる

俺の報告

RoomClipを運営するエンジニアの日報(多分)です。

日報 #47 - RDSダウンタイム

誰もが寝静まつた夜。
不精を極めたような風体の男達が、仄暗いオフィスに集まつていくのを見た。
ぼんやりと光るディスプレイの前に下ろした腰は、
どれもまあるく縮こまつており、滑稽にすら映る。
ときおり聞こえる打鍵音と男達の不安げな独り言は、
闇の隅のほうへと悉く消えていつた。
ただただ「しん」としたオフィスだ。
大きな深呼吸の後、一人の男が言つた。
「それでは、RDSのアップグレードを実行しよう」
闇がさらに深くなつた―。

世界が寝静まっているようです。
連休らしいですね。素晴らしいことです。

とってもハッピーな気持ちなので、
「どうしてもRDSをスケールアップしなければならない時、どの程度のダウンタイムがあるのか」
というアンニュイな話題もスキップしながらできるわけですね。

MultiAZとてスケールアップ時にフェールオーバーがあるんですから、
種々のタイミングにおいて、RDSの再起動は避けて通れぬ道なわけです。
では一体どの程度「落ちる」のか、見て行きましょう。

大体2GBくらいあるDBをサンプルにして、
Tokyoリージョンでdb.t1.microをスナップショットから立ち上げ、
リードレプリカを作成し、
そしてdb.m1.smallにスケールアップする。
というテストケースにどれだけ時間がかかるか、
どの時間帯にNot Connectになるのかをちょち計測しました。
(接続はphpmysql_connectみたいな奴。select文を1回走らせるテスト)
以下そのデータ。


<スナップショットからのt1.micro立ち上げ>
00:00 | creating : endpointなし
05:03 | backingup :接続できている
07:00 | modifying:接続できている
08:04 | available : 接続できている

<t1.microからt1.microのレプリカ作成>
レプリカ
00:00 | creating : endpointなし
06:12 | modifying : 接続できている
07:18 | available : 接続できている

マスタ
00:00 | modifying : 接続できている
04:02 | available : 接続できている

(レプリカはダウンタイムなしでいけますが、
親のDBがmodifyingステータスになります)

<db.t1.microをdb.m1.smallにスケールアップ>
00:20 | modifying : 接続できている
02:41 | modifying : エラーを吐き出し接続できない
03:20 | modifying : エラーすら吐き出さず接続できない
05:30 | modifying : エラーを吐き出し接続できない
08:08 | modifying : 接続できている
09:36 | available : 完全につながる
リードレプリカは生き続けています。
吐き出すエラーはmysql_conn関数の「Can't connect to MySQL server on」エラー


という感じでした。
実質の立ち上げは大体5分程度ですが、
ステータスベースで言えばAvailableまでは8分程かかってます。
レプリカはダウンタイムなしなのでさておき、
スケールアップの挙動は結構不思議です。
スケールアップすたーとぅ!から大体3分弱くらいは落ちません。
なんか準備しているんでしょう。
そして突然落ちます。
で、スタートから9分たって完全スケールアップ完了。
EC2からの繋ぎテスト等考えると、大体10分くらいを見ておくといいですね。
この実験の後用なしになった親のDBをDeleteしたんですが、
それでもリードレプリカは生存し続けました。(一瞬modifyingになるけど)

というか、
どうやってか簡単に落とさずやる方法ないもんかなぁ。。。