Wondershake 開発者ブログ

LOCARI(ロカリ)の運営会社の開発者ブログです。

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も提供されたので、
ぜひ試してみたいものです。

明日はいたべさんの記事です!
お楽しみに!