オンプレミスから AWS に移行して変えた 3 つのこと
Posted on
- #aws
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。
移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。
今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。
稼働中のサーバに変更は加えない
いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。
オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていましたが、本番稼働中のサーバに変更を加えることはリスクであり、また複数人でチェックしながら作業しても人的ミスは防げません。変更を積み重ねたサーバはブラックボックスになり、他の人が運用できない状態を作り出します。
今はアプリをリリースするときもコマンド 1 つで新しいサーバが立ち上がり、アプリのデプロイまですべて完了します。あとは ELB 配下のインスタンスを入れ替えるだけです。ここまで自動化したおかげで、リリースはより短い間隔で行えるようになりました。何より開発者が主体的になってリリースできるようになったのは大きな変化です。
運用手順書は作らない
そもそも運用手順書がないと安心して作業できないような状態を作り出さないように工夫しました。
実際に自分が運用チームにいたからよく分かるのですが、運用手順書は作るコストよりも日々メンテナンスしていくコストの方が大きいです。ですが、往々にして運用手順書は放置され内容は古くなっていきます。半年後には実際のサーバとはかけ離れた状態になっており、いざというときにまったく役に立たないという場面を何度も見てきました。
AWS への移行をキッカケに運用チームに任せることをやめ、開発者がインフラの面倒を見ています。開発が本業なのでこれまでと同じだけの時間はかけられません。当然、サービスレベルを落とすわけにもいきません。
そこで工夫したのが徹底的な自動化です。 AWS ならありとあらゆる操作を API で行えるので、これまで手作業でやっていたことを自動化できます。徹底的な自動化を推し進め、属人的なオペレーションを減らすことで運用手順書を不要にしました。運用手順書に頼る運用は気合と根性と勘に頼ることが多かったですが、API による自動化なら誰がやっても同じ結果が保証されます。
長時間稼働したサーバはリスクと見なす
オンプレミスのときはサーバの連続稼働時間を伸ばすことが正しいと思っていました。ですが、長時間稼働したサーバは不安定になり障害の芽を生みます。また、稼働時間が長くなると「動いているサーバは触りたくない」という心理的障壁を生み出し、より良い構成に変えようという気持ちを削ぎます。
これらの理由から長時間稼働したサーバはリスクと見なし、一定時間を超えて稼働しているサーバは新しいサーバに入れ替えています。 Immutable Infrastructure なのでサーバはいつでも破棄できる状態であり、新しいサーバを立ち上げるのも自動化できているので運用の手間は増えません。
こうやって定期的にサーバを入れ替えていると、サーバ障害のときに慌てることがなくなります。なぜなら、障害が起きているサーバを調査していちいち直さなくても、新しいサーバを立ち上げてしまえば復旧できるからです。サーバにそれほど詳しくない開発者でも落ち着いて対応できるのです。
AWS の世界でサーバの連続稼働時間を伸ばすことに意味はありません。プロダクトの連続稼働時間を伸ばすことに注力しましょう。
まとめ
オンプレミスと同じ考え方で AWS に移行してもあまりメリットはないと思っています。オンプレミスで凝り固まった常識はいったん捨てて、まっさらな状態でインフラをデザインすると楽しいのではないでしょうか？
よい AWS ライフを！