スパイスな人生

素敵な人生をおくるためのスパイスを届けていきたい、そんな想いで仕事をするspice lifeメンバーブログ

tmix今昔物語

前回に引き続き改めまして id:asonas です。
今日は私が普段開発運用している tmix の内側のお話をしていこうと思います

そもそもtmixとは

f:id:asonas:20141221042010p:plain

tmixはWebブラウザから欲しいTシャツやパーカの素地を選びエディタを起動して、ぽちぽち操作をすると自分だけのオリジナルTシャツやパーカをつくることができます。
商品によっては即日発送が可能であったり、色数によって代金がかわることもなく、表示されている価格以上にお金がかかることはありません。

tmixの昔と今

私がspice lifeに入社したのが約1年前で、tmixのチームにジョインしたのが今年の1月ごろです。
そのころからtmixを支える環境や技術がどのように変化していったのか、またどのように育てていったのかを幾つかのセクションにわけてお話してみます。

リポジトリ

tmixにジョインしたころのリポジトリは社内のsvnサーバがあり、そこでバージョン管理をしていました。
私自身svnを使っていた経験もあり問題は無かったのですが、複数人で開発する上ではとても扱いにくく1ヶ月ぐらいかけてsvnからgit、GitHubへ移行していきました。

デプロイ

リポジトリと関連しますが、当時はsshでサーバに接続して該当のディレクトリでsvn upを実行してtouch tmp/restart.txtを実行していました。
当時はほぼviewの更新ばかりだったのでそれでもほとんど問題がなかった(全くではなかった)のですが、新規開発に伴うgemの追加やmigrationの実行などの手順も手動でやるようになり、事故が起きるようになりました。本当にどうしようも無いときは手順書をつくったりダブルチェックをしながらデプロイをしていましたが、安全なデプロイとは到底言えないのでリポジトリのgit化に伴いcapistranoを導入をしました。

また、本番サーバにしかないファイルやdiffもあり、これをバックポートするなどのところから初めて1ヶ月ぐらいでcapistranoによるデプロイ環境を構築しました。
最近ではChatからデプロイができるようになったり、capistranoを利用してブランチごとに確認環境を立ち上げる機能（社内ではotachidaiと読んでいます）をつくり平行して確認環境を触れる環境を用意することができました。

開発環境

tmixは単一のアプリケーションだけでは動かすことができなくて、必要に応じていくつかのアプリケーションを同時に起動する必要があります。（所謂WebサーバとAPIサーバを同時起動するような感じです）

僕が入った当初は、開発サーバと呼ばれるものがあり、そこにすべてのアプリケーションが混在しておりアプリケーション用のApacheとPassenger、リバースプロキシのがためNginxと関連するアプリのためのunicorn、DBのスキーマを管理してないlocalhostのmysqlサーバなどが悪魔合体していました。

ディレクターの方々は手元のマシンでhtmlや画像を修正してsvn commitをしてはこのサーバでsvn upとtouch tmp/restart.txtを実行して動作を確認するという方法を取っていました。
しかし本番とアプリケーションの構成が違うことやミドルウェアのアップデートをするとアプリケーションが起動しなくなることなど、非常に壊れやすい環境で開発が困難だったので開発サーバから各マシンへの開発環境へ移行することにしました。

まず、最初に試したのは Vagrantとpuppetによる仮想環境上に開発環境を用意することでした。
ホスト側からvagrant upを実行すると各アプリケーションのためのミドルウェアのインストールや設定ファイルの設置、データベースの構築などを自動でやってくれるものでした。
ホスト側のファイルを編集してrsyncで仮想環境側とファイルの同期をとり、仮想環境上で起動したRailsサーバにブラウザからアクセスを可能にすることで全体の開発環境の構築を簡略化出来ました。

ただ、最初はうまく行ったのですが、人によっては仮想環境を立ち上げる際のマシンのリソースや、データベースの同期のしづらさ、仮想環境とrsyncでのディスクアクセスの遅さなどもあり、次第にストレスが溜まってきたことや、tmixを触る人が全員Macだったこともあり、Homebrewとrbenvだけで環境を構築するようになりました。

開発環境に仮想環境を選ぶのは良い場合もありますが、今回のケースではデメリットのほうが多く断念する形になりましたが、開発環境にDockerを使う野望もあるのでこちらでなにか成功することがあればブログでお知らせしていきたいと思います。

ソフトウェアテストと継続的インテグレーション

昔はJenkinsが社内のサーバに居たのですが、当時インフラを管理していたのが僕しかいないことによるメンテナンスのコストや開発の最中だった他のサービスのCIとのサーバリソースの兼ね合いもあり、TavisCIやCircleCI、CodeshipなどいくつかのCIサービスを検証をし、最終的にCircleCIを採用しました。
また、 tmix では様々なアプリケーションが動いていますが、そのほとんどがソフトウェアテストのない状態だったので、RSpecの導入をしてCircleCIをつかって継続的にテストを実行しています。
最近ではCoverallsをつかってカバレッジの計測もしていてテストを書く上での指標にしています。

地道にカバレッジを高めている様子です。
f:id:asonas:20141221043035p:plain

データベース

開発環境の部分でも少し述べましたが、tmixはmigrationを使わずに開発をしていた経緯があるようで素直に開発環境でrake db:migrateを実行しても本番のデータベースと同じスキーマが作成されません。
そのため、本番のスキーマファイルから開発環境のDBをつくる必要があったり(最近はridgepoleの導入も考えています)、Tシャツの素地など本番と同等のデータがないとアプリケーションが正常に動作できないなどがあり、それを開発者個人ごとに構築していると無駄が多いのでAWSのRDSを使い共通のDBサーバを開発者同士で使っています。
共有のDBサーバを扱う上で気をつけていることはRDS自体をインターネットから直接アクセスできるようにはせず、gatewayサーバを通して接続するようにしています。

Apache+Passengerとnginx+unicorn

私は普段からnginxとunicornを使って自分のアプリケーションを運用していることや、nginxのパフォーマンス・チューニングにはまっていたこともあり今年の4月に移行をしました。
それによりアプリケーション全体のパフォーマンスが5%から10%ほど向上しました。
この時期から本番環境にもpuppetを導入してサーバの中身の構成を管理するようにしました。

RailsとRubyのバージョンアップ

tmixのWebアプリケーションの一部ではRuby1.8.7とRails2.3系が使われていましたが、今年の6月にRuby2.1 Rails3.2系にアップデートしました。

以下がアップデートをしたときのNewRelicで計測していたグラフです。

f:id:asonas:20141222124710p:plain

12時ごろを境に大幅にパフォーマンスが向上していることが伺えます。

既にRails3を使っているアプリケーションのリポジトリには、Rails4系に向けたブランチがあったり、一部のアプリケーションではRails4.2を採用し本番で運用を開始しているなど、新しいバージョンに追従していく姿勢で普段開発を進めています。

また、古いRuby/Railsから新しいRuby/Railsへのアップデートの方法に関しては別の記事で詳しく解説していきたいと思います。

tmixのこれから

いかがでしょうか、今年に私がtmixのチームにジョインしてから主に開発基盤に関わることを書いてきました。（もちろんECとしての機能の開発もしてきましたが、今回は割愛させていただきました）
この他にも沢山の技術的な出来事や知見があるのですが、長くなるのでまた別の記事にて紹介していこうと思います。

長く動いているWebアプリケーションであるが故にいたるところにほころびが見えてきますが、それを見てみぬふりや我慢をするのではなく、1つずつ丁寧になおしていくことで開発者のモチベーションを維持し、日々の開発をより安全に楽できるようにしてきました。
技術的に改良を施せる余地がまだまだあるのでこれからもtmixを支えてよりよくしていこうと思います。