LocariとOpsworks
この記事は Wondershake Advent Calendar 2016 14日目の記事です。
ワンダーシェイクのインフラエンジニアの@whiteray_19です。
Locariでは、最近 Opsworks を利用し始めたので、それについて書きたいと思います
はじめに
Locariでは、Batch, Job, API/Web サーバ群を扱っており、
各サーバの bootstrapping, provisioning は knife-solo を利用していました。
Opsworks 以前は、 API/Web に対して、EC2 autoscaling を利用し、
ロード、スケジュールに応じたスケール イン / アウトを行っており、
あらかじめ想定される負荷に対しては、しっかり対応できていました。
一方で、autoscaling で利用するAMIの変更管理だったり、
Jobサーバのスケールアウトや、Batchサーバのメンテナンスのやりにくさがありました。
他にも、アプリケーションのデプロイはCapistrano を利用していたのですが、
Capistrano の バージョンアップに追従するのが比較的大変で、
デプロイ整備に注力するならアプリケーション開発に集中したい
や
インフラはコード化されてるといっても、
コマンド実行でサーバを立てるより、GUIから操作できた方が楽だし、わかりやすいよね
というような経緯があり、Opsworks移行が始まりました。
状況は改善されたのか
Jobサーバのスケールアウトについて
Opsworks の GUIからクリック一発でサーバを提供できるようになりました
素敵。
Batchサーバのメンテナンスについて
こちらも同様、Opsworks の GUIからクリック一発でサーバを提供できるようになりました
少し脱線しますが、
新規に立てたサーバに対して、メンテナンスを施し、新旧入れ替える運用ができるようになり、
Immutable Infrastructure 的な考えが組み込めるのはうれしいところです。
autoscaling について
Opsworks の autoscaling は EC2 autoscaling と 異なり、少し使いにくい部分があります。
ですが、Locariは比較的ピークタイムがわかりやすいサービスなので、
負荷設計を行い、 Opsworks の Timebase autoscaling を利用することにしました
移行前より、autoscaling の柔軟さはなくなってしまいましたが、
イメージ管理がなくなり、逆にメンテナンスコストは下がったと思います
デプロイについて
Capistrano で行っていることを、chef に変更し、
こちらもクリック一発でデプロイができるようになりました。
blue green deployment の採用
LocariではRack webサーバとして、 unicorn を利用しているのですが、
高負荷時にデプロイを行うと、新旧のプロセスが共存し、CPU負荷が上がってしまい、
一時的にサービス提供できない時間が存在してしまっていました。
それを解決する方法として、
Layer層の blue green deployment を採用することにしました。
blue green deploy を 実装する方法は様々あると思いますが、
Locariでは、Opsworksだけでなく、EC2、ELBが提供している
APIを素直に組み合わせて、運用ツールを作成しています
移行についてのハードル
- Opsworks 用に chef recipe を改修するのが大変。
- Capistrano で行っているデプロイを chef recipe として、作成するのが大変
- Opsworks上での chef recipe のデバッグが結構大変
結構大変なことがありました笑
Opsworks 運用の感想
やはり、GUIの操作だけで、サーバの調達から提供まで行えることはうれしいところです。
また、開発のメイン言語が ruby であることもあり、
chefをプロビジョニングツールとして採用しているOpsworksは相性が良かったです
最近では、chef automateも提供されたので、
ぜひ試してみたいものです。
明日はいたべさんの記事です!
お楽しみに!