mercari DAY 2017 - 技術編 -
mercari DAY 2017に参加してきました。 TechTruck、ProductTruckの二本立てで様々なテーマでの講演がありました。 こちらでは、TechTruckの一部に関してまとめました。
Mercari DAY 2017 @AcademyHills | 2017.01.20
目次
- Mercari - Moving Beyond Borders
- This is mercari, This is a SRE.
- 品質向上の取り組み
- グローバル展開を支える量子的なサービス設計
- アプリファーストの影で頑張るWebの話
- メルカリiOSアプリ開発の現状とこれから
- High意識Android
1. Mercari - Moving Beyond Borders
参加してないセッションだったので割愛
This is mercari, This is a SRE.
登壇者
佐々木 健一
* twitter: @siroken3
* 2014/7入社
* Site Reliability Engineering Team
SREとは
- Googleが提唱
https://www.amazon.co.jp/Site-Reliability-Engineering-Production-Systems-ebook/dp/B01DCPXKZ6
SRE in US
- 採用も活発
- 採用3600件程度
- SRE in JP
MercariとMercariのSRE
Infra
3拠点（JP, US, UK）
* JP => さくら
* US => AWS
* UK => GCP
SREに変更した理由
- インフラのイメージ
- する業務の枠を越える
- 5, 10年信頼し続けてもらう
- 24時間好きなところから好きな場所からアクセスできる「可用性」
SREの業務
MercariのSREの事例
ChatOps Deploy
まとめ
- メルカリはC2Cマーケットプレイス、信頼性重要
- SREは信頼性をシステム面から支える
- 業務はインフラに留まらない。信頼性を追求
2. 品質向上の取り組み
登壇者
鈴木 祥真
- twitter: @shoma
QA/SETチーム
QA Quality Assuarance
- 試験設計
- ログやSQLで結果を確認
- Set Software Engineer in Test
- 2016/10に発足
- エンジニアのバックグランを持つメンバー
- 開発のための開発、QAのための開発
- 別名SWETなど
- 品質と開発の速さの両立
- [QA] 開発チームと隣接
- 各地チームにアサインさせる
- [SET] 開発環境の整備
- Dockerベースで本番環境を模した動作環境
- 入社したその日から開発できる
- [QA] 探索的テスト/ユーザ視点重視
- 試験項目の整備よりも実行ログを重視
- テスト観点を蓄積して試験設計に反映
- ユーザビリティ的観点からもフィードバック
- [SET] 試験環境 TestInfrastructure
- 並行進行するプロジェクトに合わせて多数の環境を提供
- [QA] テスト往路セスの改善
- プロセス改善モデル
- TPI-NEXT導入
- [SET, Dev, SRE] テスト往路セスの改善
- 動くコードとしてのテスト
- 単一ではなく複数のレイヤー
- より速く、安定的に高い信頼性
### まとめ * 品質と開発スピードの両立が課題 * 複数のレイヤー * 終わりなき改善を継続中
グローバル展開を支える量子的なサービス設計
登壇者
中野 拓
- twitter @Hiraku
- JP server
メルカリのバックエンド系
量子的
* 観測者によって違う動きになる
* 仮説実験主義
* 実験した方が速く正確に
1.求められること
- 施策の数打つための土台
- 今すぐリリースが常に可能な存在
- アドホックな障害対応力
- データの最終防壁
2.実は重要でなかったこと
- 公式クライアントのみ考慮
- WebAPIとしての美しさ
- 全然守ってない
- 一貫性のなさ
- 朝令暮改 どんと来い
- むしろ一貫性のない修正に耐えられるように設計する
- プログラマー
- リリースを躊躇しない、不完全でも
- Be Professsionnal Dayで負債返済
思想的キーワード * 薄いフレームワーク・愚直な実装 * DietCake * 非常に薄い * フレームワーク側が縛ってこない * 速さが全てを解決する * API自体が速い（多少無理できる） * 開発の速さ（すぐに消すならアドホック） * guard節の多様 * USのみ、ABテストのAパターン、最新バージョンお使いください * 単一リポジトリという枷 * JS/US/UKは設定とDBで切り替え * サーバ構成、ノウハウ共通化 * JPのみのものがUSに出ちゃうとかの弊害も
重要なこと
できないことも多い
- 小手先のテクニックでは複雑度
エンジニアリング
- CSとインフラチームやテスト
- 何よりもプロダクトとして成功す
アプリファーストの影で頑張るWebの話
登壇者
坂本 結衣 twitterゆいたん | Yui Sakamoto (@yui_tang) | Twitter
サーバサイド、フロントエンド、プロジェクトオーナー
メルカリのWebサイトとは？
機能 * 主要なメルカリの機能は一通り使える * スマホはアプリに送客
Web特有の技術
- AMP
- ECは対象ではないが
- 商品ページは素手に数万ページがINDEX
- Universal Links
- AppIndex
メルカリWebサイトの取り組み
- アプリ誘導
- SNSシェア
- 出品機能
- アプリ使えない人向け
2016/1月 2割弱 2017/1月 4割弱 PV数は10倍増（殆どはアプリに誘導してるにもかかわらず）
パフォーマンス改善
- SREチーム
- TTFB改善
- プロジェクトが止まっているときもガンガン改善
システム構成
開発体制
一日5,6回デプロイ
そしてこれからのこと
- アプリ機能のさらなる移植
- A/BテストによるUX改善
- グローバルなSEOの成功
- フロントエンドの最新技術導入
- PCユーザの傾向に合わせた独自進化
- 各国のユーザにフィットした独自進化
- パフォーマンス改善
メルカリWebの難しさ
- マルチリージョン対応
- パフォーマンス改善
- SEO
- 各国に合わせたデザインと保守性
まとめ
- アプリを支える機能の提供
- Webサイトでしかできないことを実現
メルカリiOSアプリ開発の現状とこれから
登壇者
石川 直樹 * twitter: @jarinosukehttps://twitter.com/jarinosuke * iOSエンジニア
メルカリiOSアプリの現状
環境
コード
- ソースコード
- Objective-C : Swift = 8 : 2
- ライブラリ
- ReactiveCocoa
- APIKit
- Result
- ObjectMapper
- SnapKit
- 設計方針
- MVVM
- Storyboard/xib
- ABテストの考慮
- 設計レビュー
- テスト環境
- Unit Test
- 基本的なアプリケーションロジックをカバー
- QA
- CI Jenkins Mac単体で
- デプロイ
- ブランチ戦略
- masterブランチからtopicブランチ
- コードレビューしてマージ
- releaseブランチを切る
メルカリiOSアプリのこれから
- リリースサイクルの変更
- 原則2週間ごとにリリース
- ソースコード分割
- マルチソースマルチバイナリ
- Jp/US/UKそれぞれmasterを持つ
- ソースコード分割
- UKでのアプリリリース
- USでのGoBoldな施策
まとめ
- 人が足りない
