CTOの藤倉です。
Eightのリードエンジニアに聞くサービスの成長を支える技術の話、後編です。
（前編はこちら）
インタビュアー
藤倉成太：CTO。（シリコンバレーでの開発などを経験したのち、Sansanに入社し、法人向けサービスSansanの開発に携わる。2013年より開発部長。2016年からはプロダクトマネジメント全般を担当。2018年6月より現職。）
インタビュイー
藤井洋太郎：2014年入社。（2014年4月にSansan株式会社に新卒として入社し、サービス全体を支える基盤チームに所属。継続的なパフォーマンス改善や新技術・アーキテクチャの導入に取り組んでいる。社内外での活動も広く、北海道から沖縄まで多くのエンジニアイベントに参加、登壇している。）
藤倉（左）と藤井（右）
チャレンジングなこともわくわくして取り組みたい
藤倉：ニュースフィード自体のアーキテクチャも変えたいって聞いたけど？
藤井：そうですね。Feed機能は3年前に初リリースしましたがベースのアーキテクチャは当時から大きく変わっていません。しかし、ここ最近パフォーマンス劣化や新規機能開発に難しさを感じており、現状の構成に限界があるのではと感じるようになりました。
例えば、現状のFeedではAWS DynamoDBを使ってフィード配信と閲覧制御を実現しています。DynamoDBはスループットの変更などを簡単にできますが、Eightの全250万ユーザに対して投稿の一括配信をしたいと考えた場合には、現在のアーキテクチャではDynamoDBに対してO(n)のRead/Writeコストが発生してしまいます。これではリアルタイムな配信は難しく、システム負荷の調整など運用していく上で大きなボトルネックとなっていました。
当時は50万〜100万ユーザ程度をターゲットにしていたたため現状のアーキテクチャでも十分でしたが、今後さらに拡大していく上では今変えるべきと判断しました。
新しいアーキテクチャでは、これまでの知見を活かし「高速化」「メンテナンサブル」「スケーラブル」なものにできるよう鋭意開発中です。DB層から設計をしなおし、Feed機能のマイクロサービス化なども視野にいれたプロジェクトになっています。
藤倉：いつぐらいにリリースするの？
藤井：目標は9月末です！
藤倉：おお、それはもうすぐだ（笑）。
藤井：新しいアーキテクチャの設計もそうですが、現状すでに存在する数億件のデータの移行も考えないといけません。チャレンジングですが、それも含めてわくわくして取り組みたいと思っています。
デプロイ/リリースの改善状況
藤倉：次にデプロイやリリース周りについて聞こうかな。まずはデプロイの改善前の状況ってどうだったんだろう？
藤井：約2年前まで、固定のWebサーバを数十台抱えていたんですが、リリース時はテンポラリのWebサーバを立ち上げてデプロイをし、新旧サーバーを少しずつ付け外しながらリリースするということをしました。しかもこれを手作業でやっていました。負荷の高い時には4台ずつといった具合で。長いときにはリリース作業に4時間くらいかかって、それが週2くらいで発生していました。
藤倉：それは…職人技だね（笑）。
藤井：そうですね（笑）。改善に改善を重ねて、今はコマンドを2回叩くだけでリリースまで完了します。運用におけるヒューマンエラーやアラートが出ることも格段に減りましたね。リリースブランチを作ってマスターにマージされたタイミングでゴールデンイメージが作られます。これには数十分かかるのですが、完了するとSlackに通知が来ます。通知にはコマンドが書かれており、それを実行するだけでデプロイが完了します。
藤倉：今はぐっと自動化が進んだわけだ。
藤井：そうですね。ここはインフラチームのメンバーが頑張ってくれました。イメージ化する際にもクレデンシャル（認証）情報をどこに置くのか、どう通知を出すのかなど、リリースフローを整理してきました。そのお陰で、現在は固定のWebサーバと言った概念はなくなり、リリース時には新しいインスタンスを立て、古いインスタンスは破棄すると言ったいわゆるイミュータブルインフラストラクチャな運用になっています。
藤倉：リリース周りでの改善はどうだろう？
藤井：なるべくムダな処理をなくすようにしています。例えばRailsアプリケーションのリリース時にgemというrubyのライブラリをインストール処理があるのですが、これを数十台の各サーバで実施していました。当然のことながら、これではトラフィックもムダに使いますし、時間もかかります。現在は事前に一つのサーバでインストールし、パッケージとして固めて各サーバに配布する方式に切り替えています。こういった細かい対応が地味に効いてきます。
常に改善を！
藤倉：改善ポイントはどう見つけているの？
藤井：毎週運用者間で共有を行っていますし、Slackに課題をポストするチャンネルがあったりするので、そういったところから改善につながることは多いです。
また、個人的にも常に目を光らせていて、各チームとコミュニケーションをとりながら課題を拾っています。どこで困っているとか、生産性を落としているポイントを把握するようにしています。それをチームに持ち帰って効果が高そうなものから改善につなげています。
藤倉：開発環境やテスト環境についてはどう？
藤井：1〜2年前の話をすると、ステージングや結合環境と呼ばれるものは3つくらいしか用意されていませんでした。また、ステージング環境ごとに異なるデータベースを参照していました。そのため、一番よく使われる環境と別の環境とではテストデータ量が大きく異なっており十分な検証ができないこともありました。また、メンバーやチームが増えていくにあたり環境がそもそも足りないという大きな課題にも直面しました。
現在はDBは共用しているものの、チーム毎にサブドメインを割り当てwebサーバやワーカーを個別に用意しています。これだけでも大きな改善となり生産性は格段に上がりました。また、本番環境に近いステージング環境も新たに用意し、QAのテストや動作検証を安定して行える環境を作っています。
藤倉：残る課題は？
藤井：1〜2年前に比べると開発環境面に関しては格段によくなってきました。サーバに入ってデプロイコマンドを打つこともありませんし、それこそSlackでデプロイしてって言えばやってくれるようになっています。ただ、今は手順こそ少ないですがリリース作業における待ち時間は1時間くらいあります。これを短くするのが目下の課題です。
藤倉：コマンドを打ったら何もしなくて良いわけじゃないもんね。
藤井：そうですね。現在はRailsとJavaScriptを繋ぐビルド部分が15分くらいを占めていて、イメージ作成の大部分の時間がこれです。このビルドプロセスに手を入れ、それぞれ別サイクルでリリースできるようになればビルド自体速くなりますし、価値を届けるスピードも格段に早くできると考えています。これはすでに取り組み始めています。
藤倉：なるほど。次回は改めてエンジニアリングマネージャとしての取り組みについても聞かせてもらおうかな。
藤井：はい。
仕事の話になると思わず力が入ります
