〜IT資格と転職 〜 Galaxy log

私は、今現在、AWSを使ったサービスを運用していますが、
いざ使ってみると、ポチポチと画面操作を行うだけで、一瞬でサーバーを立ち上げたり、
負荷によってサーバを増やしたり、その便利さに酔いしれるものです。

その簡単さの反面、ハードウェアやインフラの管理はAWS側が行うので、
ハードウェアやネットワーク障害が、いつ起こるか予測できない。
また、障害という判断も、AWSの基準で障害と認められたときに障害が発生します。

クラウドであると、どうもその辺が麻痺してしまって、
アプリケーションやミドルウェアの管理だけすればよいと思ってしまいがちですが、
AWS側のインフラ障害も少なくありません。

AWSには障害情報というページがありますが、（http://status.aws.amazon.com/）
基本的に、いつ見ても常時全サービスが正常となっています。
しかしこれは自分のアカウントでAWS側の障害に遭遇したときも、常に正常扱いでした。
そしてそういった場合でも、「こちらからAWS側で障害おきてましたか？」
と聞かないと、AWS側で障害が起きていましたと教えてくれません。

また、ハードウェアに関しても運が悪いと、EC2を起動して数日で劣化してたりもします。
そういった場合、数日後に削除するからよろしくね！といったメールが来ます。
なので、クラウドもオンプレミス同様にハードウェア障害はあるよ。と考え、
サービスを止められないような仕組みは提供せず、そういった状況にもなることを想定して設計しましょう。

あとはAWSを利用して頭を悩ませる種の一つとして、有名なのはI/O周りです。
いざ運用してみたら思ったよりスピードがでない。なんてこともありますし、
また、S3やSQSへの接続も稀に500や503エラーなどで失敗します。
この関連のことを調べてみると、ドキュメントには「失敗してもリトライすればいいよ！」と書いてあります。
ちょっと日本人的には、このノリについていけません。。。

RDSに関してもMulti-AZを採用していて、不具合があれば勝手に別リージョンのSlaveにFailoverしてくれますが、
この不具合として判断する基準もAWS基準なので、運用の中で一時的に負荷が高くなるようなサービスを使った場合に、
AWS側での監視の疎通がとれなかったりすると、それだけで障害と認知しFailoverしてしまったりします。

私のように初心者だと、まず覚えることが沢山で、こういった事がおこる。と言ったところまで頭が回りませんでした。
クラウドといえど、データセンターのなかに物理サーバがあって…という前提は一緒で、
それをいかに感じさせずに構築できるかがサービスの売りな訳で、
実際運用し始めれば、今まで上げたようなAWS障害にも遭遇していきます。

サービスを提供する以上、オンプレミスで起こる障害は、オンプレでも勿論発生するよ。というのを念頭に置きましょう。
個人で使うには楽しいですみますが、大規模になればなるほど事前に考慮しなければならないことはたくさんです。