おことわり

• 主観であり何らかのデータにもとづいてはいない
• この記事に書いてあることは信じずに自分で試そう

EC2 t2 ファミリーはクソ不安定

どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確立が非常に高い気がする

なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる

インスタンスをまとめて起動すると同じホストに配置されがちで同時に死ぬ

なのでホストが故障するとインスタンスもまとめて死にます。サポートに文句いうと「複数のAZに分散して配置していただくことで、、、」と案内されますが、3台のDBを2AZにそれぞれ1台と2台配置して、2台が同時に故障したりすると目も当てられないのは明白です。

「もしくはDedicated Hostsを…」とか案内されたりもするので、我々の取れる対策としては

• なるべくAZをわける
• Tokyoを捨てて3AZ以上使えるRegionに引っ越す
• クラスタにインスタンスファミリーが別のものを加える
• なるべく時間を空けてインスタンスを起動する
• Dedicated Hostsを2台以上かりてそれぞれに配置する（バカ高い）

あたりでしょうか。Tokyoで使えるAZふやしてくれー

EBSはガチャ

(少なくともGP2とPIOPSについては）相当な頻度で故障して、裏側で再構築が走ったり、ギリギリ故障判定のしきい値に達せずに低性能のまま放置されていたりする。サポートに問い合わせると故障を認めてもらえることもあるが、そんなことしても有意義なことは起きないので黙ってそのEBSを破棄して再構築しよう

最近だとインスタンスストレージ付きのi3がr3と同じくらいの値段で使えるのでそういうのを使ってEBSにDBを置く頻度を減らすとEBSの障害も回避できるかも

RDSはそうなったときの対処がfailoverしかない上にMulti-AZでEBSの故障率も2倍なので本当に酷いことになりがち、AuroraはEBSはクソという教訓を元につくられているのでできればAurora使ったほうがいいのではないでしょうか

VPCについているDNSサーバーは以外と貧弱

以外と貧弱なのでDBなどをドメイン名で指定していたりと、頻繁に名前解決しまくるようなサービスだとDNSが死ぬ。各インスタンスでDnsmasq起動してキャッシュして負荷低減に勤しんだり、自前でDNSキャッシュサーバー建ててVPC付属のやつを使わないようにしよう。やれやれ

99%の障害はコンソールには何も表示されていない

https://status.aws.amazon.com/
こことか Managed Console とか見ても何も書いていないことがほとんど

サポートに問い合わせると50%くらいの障害は「そういった事象が発生していました」と認めてもらるが認めてもらえても得るものは何も無いので、なんかおかしいなーという箇所は全部再構築すると大抵直る