Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

Eightの裏側を支える技術(前編)

CTOの藤倉です。Sansanが提供する名刺アプリ「Eight」は、200万人を超えるユーザーに利用されています。今回はEightのリードエンジニアにサービスの成長を支える技術の話を聞きました。
前後編の2回に分けて紹介します。

インタビュアー

藤倉成太:CTO。(シリコンバレーでの開発などを経験したのち、Sansanに入社し、法人向けサービスSansanの開発に携わる。2013年より開発部長。2016年からはプロダクトマネジメント全般を担当。2018年6月より現職。)

インタビュイー

藤井洋太郎:2014年入社。(2014年4月にSansan株式会社に新卒として入社し、サービス全体を支える基盤チームに所属。継続的なパフォーマンス改善や新技術・アーキテクチャの導入に取り組んでいる。社内外での活動も広く、北海道から沖縄まで多くのエンジニアイベントに参加、登壇している。)

f:id:s_yuka:20180905110743j:plain
藤倉(左)と藤井(右)


Eightの基盤チーム


藤倉:まず自己紹介から聞こうかな。

藤井:私は新卒でSansanに入社して、現在5年目になります。入社当初からずっとEightに関わっています。現在はEightのインフラ、サーバサイド合わせて6名のチームのスクラムマスターをしています。

また、6月からはEightの各部署に横断してエンジニアを助けるエンジニアリングマネージャになりました。Sansanにおけるエンジニアリングマネージャの役割は自分のチームに限らず、エンジニアが働きやすい環境を整えたり、彼らの生産性を引き上げるのが主な職務になります。

藤倉:スクラムマスター、エンジニアリングマネージャを兼務している訳だけど、両立できてる?

藤井:正直難しい部分もあります。スクラムマスターとしては、継続的にチームの力を最大化することにフォーカスをおいてきました。しかし、エンジニアリングマネージャはチームをまたいだEight開発全体を見ていく必要があります。組織にフォーカスをあてたり、より個人にフォーカスをあてたり、新たな文化作りや制度作りなど、考えなければいけないことは山程あります。

エンジニアリングマネージャは6月からはじめたばかりですが、いろいろ試行錯誤し新たな課題も見えてきました。そういった課題を解決して、エンジニアのパフォーマンスがどう変わるか楽しみです。

藤倉:最近の主な仕事は何?

藤井:私のチームは基盤チームと呼ばれているのですが、パフォーマンスチューニングやセキュリティ対策、AWS等のインフラの変更管理も行っています。
また、Eightは2012年の2月のサービスローンチから6年半経っており、これまでに積み重なった技術的負債が少なからずあります。これらの負債を抜本的に解消していくためのアーキテクチャ刷新も私のチームで積極的に行っています。

私個人の動きとしては、課題整理や技術調査・設計が主な業務になります。またスクラムマスターとしてチームビルディングやチームの方向性を決めるといったこともやっています。
入社当初に比べ実際にコードを書くことは減りましたが、必要に応じて開発に入ることもあります。

画像圧縮、マイクロサービス、サーバレスアーキテクチャ

藤倉:最近取りかかった改善ネタって何かある?

藤井:最近取り組んでいたのは画像配信におけるコスト削減です。Eightアプリの中では画像データが多数使われています。例えば名刺画像やプロフィール画像です。そんな中、特に課題を感じていたのがニュースフィード内で表示される画像です。ニュースフィードはアプリを立ち上げた際のファーストビューとなります。フィードをスクロールする体験の中で、画像読み込みが遅延し表示ががたつくのはユーザ体験として問題でした。
また、Eightではフィード広告を提供していますが、画像表示の遅延は広告のインプレッションにも大きく影響がでていました。そういった経緯もあり、画像表示の高速化は急務でした。

実際に調査してみると、フィードに表示されるリンクのOGP(Open Graph Protocol)に巨大な画像が設定されている場合が多くあることがわかりました。これまでOGPといった外部の画像に関してはサイズ圧縮やキャッシング等の対策をしてこなかったことが問題となっていました。そこで一度Eightのサーバ側で画像をプリフェッチ & サムネイル化を行い配信するような画像圧縮サービスを開発しています。このサービスを通すと既存の画像と比較し通信コストは1/10〜1/20ほどになり、フィード閲覧時の体験は大幅に改善しました。

藤倉:具体的な実装はどうなっているの?

藤井:対象の画像URLをリクエストパラメータに含めてAPIをコールすると圧縮された画像が返るようになっています。
内部では画像のURLをキーとして、数パターンのサムネイルを生成しています。圧縮時のフォーマットは品質を下げず圧縮率も高いWebPを採用しています。WebPに対応していないデバイス向けにはJPEGで出力しています。仕組み上、初回リクエストは多少遅延することもありますが、次回以降のアクセスはキャッシングされたものを利用するため高速化されます。

仕組みとしては汎用的なものになっているので、ニュースフィードに限らずEight内の他の機能でもこの仕組みが使われ始めています。

藤倉:アーキテクチャはどうなっているの?

藤井:最近、私たちのチームではマイクロサービスであったり、サーバレスアーキテクチャを積極的に採用しており、今回の画像圧縮サービスもメインサービスから完全に切り出す形で立ち上げ運用しています。

アーキテクチャは図の通りです。構成としてはシンプルなものになっています。

f:id:s_yuka:20180904174536p:plain


画像変換についてはAWS LambdaでPythonを使って書いています。Eightのメイン言語はRubyですが、LambdaはRubyに対応していないということもあり、画像周りのライブラリが整っているPythonを採用しました。
サーバレスな環境なのでコードの管理はserverless frameworkを利用しています。ローカル環境やCI環境もdockerで立ち上がるようにしており、開発やテスト、デプロイが容易にできる環境が整っています。

藤倉:画像と言えば、名刺の画像登録の高速化はどうなっているの?

藤井:最近はスマートフォンのカメラの品質が上がっているので、画像サイズが肥大化する傾向にあります。スマートフォンから名刺画像をアップロードする際に、1〜2秒かかっていました。自分たちが普段使っている中でも重たく感じていたので高速化したいと常々感じていました。動作が重たかった理由としては、それまでは名刺の登録処理をすべて同期処理で行っていたことにありました。
特に名刺画像の永続化のために利用しているAWS S3への書き込みが特に重い処理になっていました。これらを非同期処理にすることで約3倍高速化されました。

藤倉:3倍は凄いね。

藤井:キャッシュサーバーのRedisに画像を一時的に格納するようにし、非同期処理でS3への書き込みや名刺登録後の関連処理を行うようにしています。
名刺画像を扱うことになるためRedisはクラスター構成にし耐障害性の高い構成を採用しています。非同期処理はAWS ECS上で名刺登録用のworkerが動いており、名刺の流入量によってオートスケーリングされる仕組みになっています。

f:id:s_yuka:20180904174540p:plain


ただ、実は上記仕組みは以前の方式に切り戻しています。理由としてはキャッシュサーバーを用いた運用は高速ではあるもののデータロストといったリスクが少なからずあると考えているためです。現在はAmazon Elastic File Systemに乗り換えることで、より安全な構成にできないか再検討しています。

AWSは進化も速いですし、Eightとしても彼らのサービスを十分に使っています。新しいサービスについては早めに使い倒して、自分たちの価値につなげるのを意識しています。




後編へ続く)

© Sansan, Inc.