###おことわり
- 主観であり何らかのデータにもとづいてはいない
- この記事に書いてあることは信じずに自分で試そう
#EC2 t2 ファミリーは他ファミリーと比べて不安定
どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確率が非常に高い気がする
なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる
追記: CPUクレジット理解していないだけではとか書かれていたんですがその辺は確認している。
t2の可用性が問題になったケースいくつかあるんだけど、自分の場合はネットワークがたまに断する問題が多くて、分散DBクラスタの死活監視で1secごとにpingするだけでCPUは常に1%以下みたいなものとかに使うとカジュアルに10sec以上ネットワーク断してくれることが多くて困ったりとか。
t2.medium以上のサイズはm3ファミリーを選択してしまうので使ったことないので、いいのかもしれないですね
#インスタンスをまとめて起動すると同じホストに配置されがちで同時に死ぬ
なのでホストが故障するとインスタンスもまとめて死にます。サポートにきくと「複数の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/
こことか Management Console とか見ても何も書いていないことがほとんど
サポートに問い合わせると50%くらいの障害は「そういった事象が発生していました」と教えてもらえるのですが「すでに直った」か「再構築をお願いします」と言われることが多い。なんかおかしいなーという箇所は全部再構築すると大抵直るのでおすすめです