こんにちは、@corocn です。
今年は例年より寒いですね。私がリモートワークしている部屋も、隙間風が強くて寒いです。
※ 写真は自宅のニワトリ小屋です
新しいRailsのインフラ環境構築
先日この開発者ブログで、@mugi_uno が 新しいRailsのフロントエンドについて紹介してくれました。
Turbolinks、時々Vue.js - Misoca開発者ブログ
今回は、同アプリケーションのインフラ環境で活用しているAWS Elastic Beanstalkについて紹介したいと思います。
AWS Elastic Beanstalk とは
AWSの各種サービスを組み合わせたPaaSです。 環境作成時に、ロードバランサ、オートスケーリング、ローリングアップデートなどの機能が自動設定され、Elastic Beanstalkから一括管理できるようになります。
ウェブサーバーはEC2インスタンス上に構築されますが、自動で作成されたインスタンスは、通常作成のEC2インスタンスと同様に、EC2マネジメントコンソールの一覧に表示されます。ロードバランサなども同様です。
Elastic Beanstalkを選択した理由
インフラ専任のエンジニアが存在しない状況で、 可能な限りインフラ設計に開発コストを割かないようにするためにPaaSを選択しています。 その時に検討したサービスが、以下の2サービスでした。
- Heroku: DevOpsツールとして運用している実績がある
- Elastic Beanstalk: 現在のMisocaのプロダクションはAWSで運用されている
手軽感はHerokuのほうが強いですが、 最終的にElastic Beanstalkを使わないAWSでの運用へ移行することを視野に入れてましたので、後者を選択しました。
既存のプロダクションのしがらみがない状態であれば、Herokuおよび別のPaaSを検討したかもしれません。
構成
Elastic Beanstalkには「アプリケーション」と「環境」という概念が存在し、1つの「アプリケーション」の下に、複数の「環境」を作成して運用します。
環境の種類にはWebTierとWorkerTierが選べます。
- Web: ウェブサーバー用。ロードバランサなどが自動作成される。
- Worker: ジョブサーバー用。メッセージキュー(SQS)が自動作成される。
shoryuken でSQS対応する選択肢もあるのですが、 今回は使い慣れているDelayedJobを利用しています。
RDSを環境内に含めることも可能ですが、 環境を削除した際にDBまで消してしまうのが怖かったので、手動で作成してアタッチする方法をとっています。
構築してみて
良かったこと、辛かったこと(現在進行形で辛いこと)を以下に並べてみました。
良かったこと
- カスタマイズ性が高い
- AWSの別サービス群との連携が簡単
- 環境立ち上げが楽
- コマンド一発でレビュー環境が立ち上がって素敵です
また、AWS全体の話になりますが、今回初めて技術サポートを活用してみました。 対応が早くて非常に助かりました。
辛かったこと
- ドキュメントの少なさ
- .ebextensionsのクセが強い
- 慣れるまで多少時間がかかる
- 環境作成時やデプロイ時のライフサイクルをちゃんと理解しておいたほうが良い
- 最新バージョンへ追従が遅れる
- 前提としてMisocaでは常に最新環境を使おうとしている(2.5.0の時はリリースの翌日に本番反映したほどです)
- 現在はRuby 2.4.3までしか対応しておらず、2.5.0が使えない
- 公式対応が待てない場合はPlatformを自作する方法があるが、試せていない
まとめ
導入時に少しだけ山がありますが、慣れてしまえばAWSという強力なサービス群の恩恵を受けることができます。 インフラ構築に大きく時間をかけれないような状況では強力なツールとなります。ぜひ検討してみてください。
また別の機会に.ebextensionsやデプロイ時の挙動を掘り下げた記事を書こうと思います!
採用
インフラ含め、Misocaの信頼性を一緒に支えてくれるエンジニアを大募集しています!