Box」が表参道ヒルズ(東京・表参道)にて開催されました。エンジニアや研究員,プロダクトマネージャー,デザイナーなど,同社のサービス開発を支えるさまざまな職種のメンバーたちが登壇し,スキルや経験,ノウハウを惜しみなく公開しました。Boxhttps://jp.corp-sansan.com/sbb2018/後編は,全セッションの中から,とくに注目したい3セッションについてレポートします。グローバル展開のための改善⁠」⁠。辰濱健一氏が,名刺アプリEightをインドに展開した際のエピソードを披露しました。日本だけをターゲットにしていたら気づけなかった,グローバル展開のために必要なノウハウについて語りました。日本とはまったく異なる,インドのインターネット環境Eightがインドに展開し始めたのは2017年の秋。辰濱氏は「アプリの品質は高いため,英訳をすれば十分に海外展開できると思っていました」と語ります。インド展開の翌日から,日本では発生しないような不具合が相次いで報告されたのです。「アプリのダウンロードが完了しない,画面がなかなか切り替わらない,通信が終わらない......。配信するアプリのバイナリファイルを間違えたんじゃないかとさえ思いました」と辰濱氏はふり返りました。問題の調査・解決のため,開発メンバーたちはインドを訪問します。そこで直面したのは,インターネット通信速度の遅さでした。インドで立てられている通信アンテナは半径数百メートルほどの領域しかカバーできず,建物に入ると電波のムラが発生します。人口が多いため細い回線を大勢の人が取り合っている状態であり,通信状態が安定しません。「インドにおいては,サーバにリクエストをしてもレスポンスが返ってこないケースがあることを考慮する必要があります。それを前提として,Eightの全体的なつくりを見直す必要が出てきたんです」と解説しました。通信速度が低速であることを前提に,設計・実装する開発メンバーたちがまず着手したのは,アプリのバイナリファイルのサイズを削減すること。EightのAndroid版において,海外用のバイナリファイルと国内用のバイナリファイルを分けて配信することを決定しました。前者のバイナリファイルには,海外用に必要な機能だけを含める方針にしたそうです。Playで推奨されている公開形式を用いることで,配信の最適化も行いました。「⁠こうした数々の対応を行ったことで,もともとは60MBほどあったバイナリファイルのサイズが,なんと9MBほどまで削減できました」と辰濱氏は語ります。次に取り組んだのは,画面がなかなか切り替わらない問題です。この原因は,通信が全て完了した後に画面遷移をしていることでした。電波が弱い場合に,レスポンスが返ってくるまでに時間がかかるケースがあったのです。この問題を解決するため,彼らはWorkManagerというコンポーネントを用いました。これは,処理をキューにためておき,特定の条件に合致して処理が実行可能になったタイミングで,自動的に実行してくれるというものです。「これにより,オンラインになったら自動的にリクエストを再送する仕組みをEightに実装しました。インドの通信環境にマッチした設計にできたのです」と辰濱氏は解説しました。次に彼らは,画像の容量が大きいために通信に時間がかかるという問題を解決していきました。通信時の画像サイズを小さくする,画像の圧縮率を見直す,画像形式をJpegからWebPにするなどの施策を行い,通信量を軽量化していったのです。分析ツールを用いて,どの箇所が通信のボトルネックになっているかを解析しました。辰濱氏は,おすすめの分析ツールをいくつか紹介しました。「Stethoを用いると,Androidアプリのネットワークパフォーマンスを確認できます。CharlesはPCにプロキシを立てて通信内容をキャプチャ可能です。Monitoringも,アプリのパフォーマンス特性を理解するのに役立ちます。私たちはNewRelicMobileを使っています。NewRelicMobileは各種条件でのデータの絞りこみが簡単にでき,ダッシュボード上でさまざまな数値を可視化できるというメリットがあるからです」Eightインド展開の過程で,開発メンバーたちは数多くの知見を得てきました。本セッションは,そんな彼らが持つ貴重なノウハウを学べるものとなりました。運用担当者が考える,SRE実現のために必要なこと続いて紹介するのは,午後のインフラセッション「SRE全盛期にEightのインフラ担当は何をしているのか」です。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上で送信されたメッセージをトリガーに,各種オペレーションを行うような仕組みを構築しました」と間瀬氏は解説します。Energy)名刺交換やリアルタイムレコメンデーション,企業ページなどの機能がEightに実装されました。ここで,Eightインフラの大幅なアーキテクチャ変更が行われます。Serviceに移行したのです。Code実現のためにTerraformを導入していきました。2017年にはEightのバージョン8がリリースされ,グループチャットや企業による投稿などの機能が追加されます。Deploymentなどの仕組みが整備されていきました。2018年には,インド進出に向けて海外専用アプリをリリース。端末上でOCRを利用できるクイックスキャンという機能も実装されました。ECSの導入,行動ログ活用基盤の構築などが行われました。このように,Eightの成長は常にインフラの成長とともにあったのです。DevとOpsが一体となり,SREに取り組むここで,間瀬氏はセッションのテーマであるSREについて触れました。Engineer)の略。ソフトウェアエンジニアリングにおいてシステムの信頼性向上に向き合うことを意味します。開発手法であるDevOpsの概念を持ち出したうえで,「⁠Dev(アプリケーション開発者)とOps(インフラ担当者)が協力体制を築くことを,EightチームではSREだと考えています」と締めくくりました。「インフラ担当者はシステムの可用性や拡張性,パフォーマンスなどと日々向き合います。アプリケーション開発者も,視点が違うだけで大切にしていることは同じ。『⁠信頼性の高いシステムをつくる』という本質は変わりません。間瀬氏は,Eightの黎明期からインフラ基盤と向き合ってきました。インフラ担当者はシステムを支える屋台骨であり,信頼性の重要さを誰よりも痛感するポジションです。そんな彼が語ったEightの歴史とSREの本質は,多くのエンジニアにとって参考になるものでした。クロスメディア事業室室長。