はじめに
SREチームの @minamijoyo です。 先日 CrowdWorks (crowdworks.jp) の本番環境のRailsアプリケーションを Docker (AWS ECS: Elastic Container Service) に移行しました。
CrowdWorksは2012年にサービスを開始し、2019年10月現在、ユーザ数は300万人、月間で数億円規模のお仕事がやりとりされる、国内最大級のクラウドソーシングプラットフォームにまで成長しました。 サービスの規模拡大に合わせて、ソースコードも数十万行規模に成長し、 決して小さくはない規模のRailsアプリケーションに成長しました。
CrowdWorksの開発環境にDockerが導入されたのはもうかれこれ3年半前の2016年の4月頃、2017年1月頃にはCrowdWorks本体から切り出された一部の機能で本番環境に投入され、 その後新規に追加される周辺サービスや新規事業などでは最初からDockerが利用されるようになりました。 しかしながらCrowdWorksのコア部分であるモノリシックなRailsアプリケーション(通称CrowdWorks本体)は、いわゆる普通のEC2サーバで長らく運用されていました。
開発環境や新規の本番環境にDockerを導入するのはそれほど難しくはありません。 しかし既存の本番環境をDockerに移行するには、現行のシステムの仕様や制約事項など考慮すべきポイントが多く困難が伴います。 それが会社の主力事業であるそれなりに規模と歴史あるWebアプリケーションなら尚更です。 変更に伴うリスクが大きいのはもちろんですし、そもそも歴史あるWebアプリケーションはコンテナフレンドリーではないことが多く、 Dockerに移行するためには単にDockerfileを書けばよいという単純な話ではありません。 アプリケーションのアーキテクチャレベルでの変更が必要です。
これを技術的負債と言ってしまうのは簡単ですが、そもそもDockerの初期リリースは2013年で、イミュータブルなインフラが提唱されるようになってきたのもここ数年の出来事です。 それより以前からあるアプリケーションにコンテナフレンドリーを求めるのはちょっと厳しいかなと思います。
CrowdWorksではこれまでも、本番環境でDockerを利用していましたが、小規模な周辺のサービスで利用してもその恩恵は限定的でした。 というのも、多くの機能は依然としてCrowdWorks本体に実装されており、維持管理上の多くの問題も必然的にCrowdWorks本体に関連するからです。 とはいえDockerに移行するために解決すべき課題は多く、組織的な優先度の高い案件が次から次に降ってきたり、なかなか難しい時代が続きました。
しかし、Dockerというソフトウェアが生き残るかはさておき、 Webアプリケーションをコンテナ化していく時代の流れは巻き戻ることはなさそうですし、 コンテナフレンドリーではないCrowdWorks本体を、歯を食いしばって少しずつコンテナフレンドリーにしていかない限り、我々に幸せが訪れないことは明らかでした。
この記事では、コンテナフレンドリーではなかったCrowdWorks本体のRailsアプリケーションをDocker(ECS)に移行するためにやったことを紹介します。 網羅的なタスクの一覧を挙げるとちょっと書ききれないので、コンテナフレンドリーではない依存からどうやって脱却したのかを中心に、ハマりポイントで学んだ知見を共有します。
続きを読む