こんにちは。 ランサーズの金澤です。私は2013年の11月にランサーズにジョインして以降、バックエンド、インフラの構築に携わってきました。
私が入社した頃はちょうどクラウドソーシングサービスの広がっていた時期で、ランサーズのユーザ数も右肩上りで増えていきました。もちろんサービスが増え成長していくに当たってインフラ体制も変化。さまざまな課題に対して変更を加えることで対応してきました。
今回はランサーズのバックグラウンドのプロダクト技術をどのように変遷させていったのか。これまでのことを思い出しながらお話していこうと思います。
10年を超える開発で出会った3つの技術的転機
ランサーズは2008年に創業してから、クラウドソーシングサービスLancers.jpを皮切りにサービスを展開してきました。2011年の東日本大震災以降、リモートワークという働き方が注目され始め、社会的な時勢を背景に2012年には利用者が10万人を突破。その1年後の2013年には20万人を越えるなど一気に成長していきました。
私は入社以降、インフラエンジニアとして会社の成長と共に、サービスを支えるバックエンド、インフラにアップデートを加えていきました。
ランサーズでのバックエンド、インフラの大きな変化は3つあります。1つ目はサーバを既存のサーバからAWSへと移行したこと。2つ目はDockerの導入。そして3つ目はPHPのバージョンをアップデートしたことです。
これら3つの技術転換を行ったことで、ランサーズのインフラ体制は大きく改善されていきました。3つの転機について順に解説していきます。
転機1:日本国内でもいち早く進めたAWS移行
1つ目の転機はAWSへの移行です。これはユーザが急増した2012年5月頃のことで、私がランサーズへの転職を決意したきっかけでもあります。現在ではほとんどの企業が活用しているAWSですが、当時はまだまだ認知も低く、導入している企業もとても少なかったです。そんな中、ランサーズはいち早くAWSの導入を決めました。当時としては思い切った判断だったと思います。
私もAWSを知った時は、これはすごい技術だと思いました。近い将来AWSのようなクラウドインフラが主流になり技術の概念が変わる。そう感じていました。そこでもっと実務レベルでAWSを触りたいと思いランサーズへの入社を決意。以降は念願だったAWSを使ったバックエンド構築に携わらせていただきました。
私が入社した頃は、AWSへと完全に移行を終えていましたが、データベースに関してはAWSのマネージドサービスであるRDSを利用していない状態でした。
その理由としてはまだRDSのストレージパフォーマンスが悪かったことと、細かいレベルでのログを見られなかったという背景がありました。
しかし、その頃にインデックス要因で不整合が起こりサービスが丸2日止まってしまうといったトラブルも起きていたため、RDSへ移行しながら解決してくれと上司にお願いされたのが私の最初の仕事でした。
▲右側(移行後)が、入社直後のシステム構成 (【JAWS DAYS 2014】ランサーズを支えるRDSより)
AWSの技術によって作業が効率化し、サービスも安定するように
データベース移行のためにAWSに触れたのですが、やはりその技術に衝撃を受けたことを今でも覚えています。中でも一番驚いたことはリードレプリカを使ってデータベースの複製を右クリック1つで行えたことです。当時データベースを複製するには、タイミングを合わせてログの位置を確認し更新日程を確認して作らなければいけなかったのですが、その工程が一瞬で完了してしまうというのは信じられませんでした。
作業効率でいえば普段、1時間以上かけて慎重に行う作業が1分でできるほど向上しました。
AWSはまだ進化の途中でもあったので、その後も2年くらいかけてアップデートされたものを置き換えていって、安定して動かせるサービスへと落ち着かせていきました。
将来性のあるクラウドインフラをいち早く導入して整えていった。これがランサーズの最初の転機でした。
転機2:開発環境の「社内サーバ → Docker移行」
2つ目の転機は2015年頃に開発環境をDockerに切り替えたことです。当時はWindowsPCを使って社内のサーバにアクセスして開発していた状態だったのですが、会社に来ないと開発を進められないというのがとても不便でした。また、新しい開発環境になったときに人数分だけ手動でアップデートをしなければいけないという手間や、ディスクが足りなくなるなどの物理的な問題も生じていました。当初は私が秋葉原までサーバを買いに行くくらいギリギリの状態でした（笑）。
サービス拡大とともに、スケーラビリティのあるDockerへ
2012年まではサービスがほぼ単一だったので、社内サーバにアクセスしてみんなで開発するということもできていました。しかし徐々にサービスの規模や社員数も増え、不便を感じ始めるとVagrantを活用するメンバーが出てきました。スペックの高いパソコンを持つメンバーが自前のPCにVirtualBoxを入れてLinuxを立ち上げるというやり方で2013年ごろから2年ほど運用していました。
しかし2015年ごろに限界がきました。大規模な案件に対応した「Lancers for ビジネス」や法人向けのアカウントサービス「Enterprise」といったサービスも増え、開発環境も増えたのでディスクが足りないといった問題も起きるようになりました。サービスは今後も増えるのにこのままではやっていけないという話になりDockerを入れようという決断に至りました。
実は、私は最初Dockerに反対派でした。Dockerの機能や将来性に未知数な部分があったからです。なのでまずは1つのVirtualBoxに入れてみたらどうかと思い試してみたのですが、環境ごとにPHPのバージョンが違ったりとか、Rubyの環境だとかを整えるのがあまりにも大変でした。これは1つにまとめるのは無理だという結論になり、最終的にDockerに賭けるという形で導入をしたのですが、結果的に大成功でした。
アップデートも自分が作ったものをDocker内のリポジトリに上げておくだけで、メンバーがそれを更新するだけで済んだりと、少ない作業でメンバー全員の開発環境を整えられるのはとても楽になりました。
私は新しい技術に対して飛びつく方ではなくて、色々とメリットデメリットを吟味した上で慎重に取り組む方なのですが、この時は思い切って試して成功するという貴重な経験ができたと思っています。
▲2019年時点のランサーズのシステム構成図( 成長サービスのDB負荷問題を解決するより)
転機3:PHPの一大アップデートプロジェクトで処理速度が4倍、費用は4分の1に
3つ目の転機は2017年から2019年にかけてPHPのアップデートを行ったことです。ランサーズでは創業当初からPHPを使っていたのですが、常に最新バージョンへアップデートしていたわけでありませんでした。2017年まで使っていたPHP5.3はもうサポートが終わっており、アップデートをこれ以上先延ばしにできないと感じていました。
私はインフラエンジニアとしてサーバのスピードアップや処理速度をあげることに力を注いでいるのですが、PHPを7にアップデートすると処理速度が2倍以上になることがわかっていたので、いずれやらなければと考えていました。
アップデートはプロダクト開発と比べて事業へのインパクトが見えづらいため、優先順位が下がってしまっていたのですが、2017年の3月ごろからようやく本腰を上げて行うようになりました。
処理速度が大幅に上がり、サーバ費用も削減
PHPのアップデートは、古い機能から新しい機能への置き換えが必要で大変な作業なのですが、最も大変だったのはフレームワークであるCakePHPのアップデートです。この作業では、コードを読んでいって該当するところを洗い出して置き換えていく必要があります。一般的には一旦開発を止めてコードの洗い出しに集中するのですが、ランサーズの場合はコードの規模も大きく開発を止めることができなかったため、新しいバージョンと古いバージョンを共存させながら少しずつ置き換えていきました。
共存させながらのアップデートは、一度始めたら最後までやり切る必要があります。途中で挫折してしまうと新しいバージョンと古いバージョンが中途半端に残ってしまい、以前よりもメンテナンスしにくくなってしまいます。
過去にこの状態に陥ったケースに関わっていたことがあるのですが、ランサーズでは絶対にやりきるぞという決心のもと最後までやり切りました（笑）。
約2年という長い時間をかけて無事に2019年にアップデートが完了したのですが、改善された環境にとても感動しました。処理速度は体感で4倍近くになったことでサーバ費用も4分の1に削減できました。メンバーも仕事効率が上がったと喜んでいて、諦めずに取り組んでよかったと感じています。
さらに、最新のバージョンにアップデートしたことでCakePHPのOSSに貢献したり、コアデベロッパーの方々と繋がれるようになりました。
最新のバージョンにキャッチアップし続けるメリットには、使っているOSSなどで問題が起こった場合に、OSS自体に修正提案を行うことができることです。ここでバージョンが古くてサポート期限が終了していると、プロダクト側で余計な修正を行う必要がでてきて、それがさらにバージョンアップの足枷になったりして悪循環に陥ります。
また、最新の技術についての意見交換できる場を作れることで、自分自身の技術力の向上に繋がりアップデートの意義はかなりあったと感じています。
10年超のプロダクトにおける技術スタックでは”技術の見極め”と”断捨離”が大事
ランサーズは、Lancers.jpというプロダクトの成長に合わせて技術スタックも様々な改良を加えてきました。運用10年を超えるプロダクトに関わるインフラエンジニアとして考える、長期のプロダクトの技術スタックで重要なことは「技術を見極めた上で断捨離すること」です。
ベンチャー企業においては、流行りの技術を導入することは、エンジニア採用の面においても重要だと感じています。
一方で、その技術が確実に市場に浸透するか見極めることが更に重要だと感じています。
流行る技術はたくさんあるのですが、実は市場に生き残れる技術は一握りです。
一度コアな技術として取り入れると、そこから移行することは困難なので、中長期で活用できる技術なのかという視点を持って、実用性を吟味していくことが大事だと思います。
また、新しい技術を取り入れたら古くなった技術を必ず捨てることも大切です。新しい技術を積極的に取り入れる会社は多いですが、古くなった技術をそのまま放置してしまいがちです。ランサーズのPHPアップデートの事例でも見たとおり、古い技術を残したままだと、開発環境がごちゃごちゃしてしまったり意外なところで干渉していたりとデメリットが多いので、新しい技術を取り入れるのと同じくらい、古い技術を置き換えることに目を向けることが大事です。これによって将来的なタスクが減っていき、プロダクトを長い時間をかけて作っていくための地盤ができていきます。。
インフラエンジニア目線の意見になりましたが、このお話が少しでもプロダクト開発の参考になれば幸いです。