2018年11月10日，Sansan史上初の，ものづくりに携わるメンバーを中心としたカンファレンス「Sansan Builders Box」が表参道ヒルズ（東京・表参道）にて開催されました。エンジニアや研究員，プロダクトマネージャー，デザイナーなど，同社のサービス開発を支えるさまざまな職種のメンバーたちが登壇し，スキルや経験，ノウハウを惜しみなく公開しました。

Sansan Builders Box

https://jp.corp-sansan.com/sbb2018/

後編は，全セッションの中から，とくに注目したい3セッションについてレポートします。

英訳だけじゃダメ！Eight のグローバル展開のための改善

午前中のモバイルセッションとして用意された「英訳だけじゃダメ！Eight のグローバル展開のための改善⁠」⁠。

本セッションでは，Eight事業部Global Groupスマートフォンアプリエンジニア 辰濱健一氏が，名刺アプリEightをインドに展開した際のエピソードを披露しました。日本だけをターゲットにしていたら気づけなかった，グローバル展開のために必要なノウハウについて語りました。

日本とはまったく異なる，インドのインターネット環境

Eightがインドに展開し始めたのは2017年の秋。辰濱氏は「アプリの品質は高いため，英訳をすれば十分に海外展開できると思っていました」と語ります。ですが，インド展開の翌日から，日本では発生しないような不具合が相次いで報告されたのです。

「アプリのダウンロードが完了しない，画面がなかなか切り替わらない，通信が終わらない……。配信するアプリのバイナリファイルを間違えたんじゃないかとさえ思いました」と辰濱氏はふり返りました。

問題の調査・解決のため，開発メンバーたちはインドを訪問します。そこで直面したのは，インターネット通信速度の遅さでした。インドで立てられている通信アンテナは半径数百メートルほどの領域しかカバーできず，建物に入ると電波のムラが発生します。さらに，人口が多いため細い回線を大勢の人が取り合っている状態であり，通信状態が安定しません。

「インドにおいては，サーバにリクエストをしてもレスポンスが返ってこないケースがあることを考慮する必要があります。それを前提として，Eightの全体的なつくりを見直す必要が出てきたんです」と解説しました。

通信速度が低速であることを前提に，設計・実装する

開発メンバーたちがまず着手したのは，アプリのバイナリファイルのサイズを削減すること。EightのAndroid版において，海外用のバイナリファイルと国内用のバイナリファイルを分けて配信することを決定しました。前者のバイナリファイルには，海外用に必要な機能だけを含める方針にしたそうです。

さらに，Android App Bundleという，Google Playで推奨されている公開形式を用いることで，配信の最適化も行いました。「⁠こうした数々の対応を行ったことで，もともとは60MBほどあったバイナリファイルのサイズが，なんと9MBほどまで削減できました」と辰濱氏は語ります。

次に取り組んだのは，画面がなかなか切り替わらない問題です。この原因は，通信が全て完了した後に画面遷移をしていることでした。電波が弱い場合に，レスポンスが返ってくるまでに時間がかかるケースがあったのです。

この問題を解決するため，彼らはWorkManagerというコンポーネントを用いました。これは，処理をキューにためておき，特定の条件に合致して処理が実行可能になったタイミングで，自動的に実行してくれるというものです。

「これにより，オンラインになったら自動的にリクエストを再送する仕組みをEightに実装しました。インドの通信環境にマッチした設計にできたのです」と辰濱氏は解説しました。

画像容量の圧縮と分析ツールによって，通信量を最適化

次に彼らは，画像の容量が大きいために通信に時間がかかるという問題を解決していきました。通信時の画像サイズを小さくする，画像の圧縮率を見直す，画像形式をJpegからWebPにするなどの施策を行い，通信量を軽量化していったのです。

さらに，分析ツールを用いて，どの箇所が通信のボトルネックになっているかを解析しました。辰濱氏は，おすすめの分析ツールをいくつか紹介しました。

「Stethoを用いると，Androidアプリのネットワークパフォーマンスを確認できます。また，CharlesはPCにプロキシを立てて通信内容をキャプチャ可能です。Firebase Performance Monitoringも，アプリのパフォーマンス特性を理解するのに役立ちます。

私たちはNewRelicMobileを使っています。NewRelicMobileは各種条件でのデータの絞りこみが簡単にでき，ダッシュボード上でさまざまな数値を可視化できるというメリットがあるからです」

Eightインド展開の過程で，開発メンバーたちは数多くの知見を得てきました。本セッションは，そんな彼らが持つ貴重なノウハウを学べるものとなりました。

Eightのインフラはどう成長してきたのか？ 運用担当者が考える，SRE実現のために必要なこと

続いて紹介するのは，午後のインフラセッション「SRE全盛期にEightのインフラ担当は何をしているのか」です。

スピーカは，名刺アプリEightのインフラ基盤を支えてきた，Eight事業部Development Groupエンジニア間瀬哲也氏。Eightの成長とともにインフラはどう成長してきたのか。そして，EightチームにおけるSREの概念について間瀬氏が語りました。

サービスの成長に伴い，インフラ基盤も成長

間瀬氏はまず，Eightとインフラの歴史についてふり返りました。Eightの誕生は2010年9月。当時はまだベータ版であり，社内や一部のユーザのみに公開されていました。そのころ，間瀬氏はSansanへ入社したそうです。

「入社後，まずはサービスの監視設定に着手しました。当時はSaaSの監視ツールがそれほど普及していなかったため，NagiosとCactiを用いて設定を行ったんです」

2012年に，Eightの一般公開版であるバージョン3がリリースされます。それに伴い，インフラ基盤強化のためにAWSを導入。さらには構成管理・リソース監視のためにChefやCloudForecastなどが用いられるようになりました。

2013年にはEightのバージョン4が登場。UI/UXが刷新され，現在のビジュアルに近づきます。その後の2014年に，インフラチームではアカウント管理用のLDAP導入など，セキュリティ向上のための施策を行ったそうです。

2015年に登場したバージョン6～7.0では，プレミアムサービスやフィード，プロフィールなどの機能が増えていきました。インフラチームでは，Slackの流行に伴いChatOpsを導入。「⁠Slack上で送信されたメッセージをトリガーに，各種オペレーションを行うような仕組みを構築しました」と間瀬氏は解説します。

より現代的なアーキテクチャへの刷新

2016年には，BLE（Bluetooth Low Energy）名刺交換やリアルタイムレコメンデーション，企業ページなどの機能がEightに実装されました。

ここで，Eightインフラの大幅なアーキテクチャ変更が行われます。可用性や運用容易性向上のため，データベースの構成をRDS MySQL+SpiderからAmazon Aurora+Amazon Elasticsearch Serviceに移行したのです。さらに，Infrastructure as Code実現のためにTerraformを導入していきました。

2017年にはEightのバージョン8がリリースされ，グループチャットや企業による投稿などの機能が追加されます。インフラチームにおいては，AutoScalingやBlue/Green Deploymentなどの仕組みが整備されていきました。

2018年には，インド進出に向けて海外専用アプリをリリース。さらには，端末上でOCRを利用できるクイックスキャンという機能も実装されました。インフラチームでは，MySQLの4バイト文字対応やAmazon ECSの導入，行動ログ活用基盤の構築などが行われました。

このように，Eightの成長は常にインフラの成長とともにあったのです。

DevとOpsが一体となり，SREに取り組む

ここで，間瀬氏はセッションのテーマであるSREについて触れました。SREとは，Site Reliability Engineering（またはSite Reliability Engineer）の略。ソフトウェアエンジニアリングにおいてシステムの信頼性向上に向き合うことを意味します。

開発手法であるDevOpsの概念を持ち出したうえで，「⁠Dev（アプリケーション開発者）とOps（インフラ担当者）が協力体制を築くことを，EightチームではSREだと考えています」と締めくくりました。

「インフラ担当者はシステムの可用性や拡張性，パフォーマンスなどと日々向き合います。でもアプリケーション開発者も，視点が違うだけで大切にしていることは同じ。『⁠信頼性の高いシステムをつくる』という本質は変わりません。だからこそ，SREにおいては両者が手を取り合うことが何よりも大切なんです」

間瀬氏は，Eightの黎明期からインフラ基盤と向き合ってきました。インフラ担当者はシステムを支える屋台骨であり，信頼性の重要さを誰よりも痛感するポジションです。そんな彼が語ったEightの歴史とSREの本質は，多くのエンジニアにとって参考になるものでした。