S3 で発生した障害の影響はデカかった [cloudpack OSAKA blog]
ナスです。
米国時間 2/28 に発生した S3 の障害のニュースは、皆さん見られてるかと思います。日本時間で夜中だったので、実際に障害の影響に直面した方は偶然にも少なかったかもしれません。
今回の件で初めて知りましたが、S3 っていろんな web サービスが使っているんですね。Business Insider や Slack も S3 を使っていたようで、サービス影響があったみたいです。私は寝てたので全く気がつきませんでした…
SLA とその考慮
S3 には SLA があって、月あたり 99.9% の使用可能時間が定義されています。
サービスレベルアグリーメント - Amazon S3 | AWS
SLA はあくまで SLA なので、当然障害などでこれを下回る可能性はあります。AWS の場合は、下回ったら返金かサービスクレジットがもらえるだけです。そんなバカな!って思った方は、もう一度 SLA と言う言葉の定義を再確認しましょう。
で、今回の障害では 4 時間くらい S3 が自由に使えなかったわけですが、これを AWS のせいにするのは簡単です。ですが、これを機に、本当に落ちたら困るサービスを設計する時は、何かのサービスやリソースに依存する設計はやめるように改めましょう。本当に数時間落ちたら困るシステムやサービスで実際に同時間落ちたら、それは設計が悪いってことです。
基本的には、使った分だけ支払うモデルなので、うまく使えば安く済みます。が、特定のものに依存して安く済ます=障害でサービスが多少落ちても許容する、ということを関係者全員で共有しておく必要があると思います。
オンプレミスでも同じです
今回の件で「やっぱりクラウドは〜〜」的な論調で話してたり SNS 等でコメントされている方もいらっしゃいますが、別にクラウドは関係なくて、オンプレミス環境でも起こりうることです。今回は 4 時間程度で済みましたが、これオンプレミスだと業者手配とかでもっとかかる可能性だってありますよね。
全てはシステムやサービスの設計、運用設計にかかっているわけです。
というわけで、全てを AWS のせいにせず、そのサービスの要件にあった設計を心がけましょう、というのを私も含め皆さんも再認識してもらえたらと思います。
って、うちの社内の人が言ってました。私は、へー、って思いながら話を聞いてました。
パブリック IP が外せない… [cloudpack OSAKA blog]
ナスです。
とある検証で、EC2 インスタンスにパブリック IP をつけたら外せなくなったお話です。知ってる人にしてみたら当たり前の話ですが、意外と知らなかったって人もいるんじゃないでしょうか。
流れ
EIP は諸事情で使えない状態で、EC2 インスタンスからインターネットに出る必要があったので、VPC のサブネットで自動割り当てパブリック IP を有効化しました。
この状態で EC2 インスタンスを起動しました。この時点では、パブリック IP が付いています。
で、VPC のサブネットで自動割り当てパブリック IP を無効化しました。
結果
EC2 インスタンスのパブリック IP はついたままでした… EC2 インスタンスを再起動しても停止/起動しても、どうやっても外れません。
プライベートサブネットだけど一時的にインターネットに出る必要があってこうした場合、一度ついたパブリック IP は外れませんので、AMI 作成して EC2 インスタンスを再作成してください。これ意外と忘れがちなので、思い出せるように書いておきます。