timakin.log

╭( ・ㅂ・)و ̑̑

#attefes Mercariのatte FeS【Go・Swift開発編】行ってたけど最高

どうもtimakinです。先日株式会社メルカリ様のグループ企業である、
ソウゾウ様の、「メルカリ アッテ」リリース記念のMeetupに行ってきました。
控えめにいうと最高で、技術勉強会という面から見ても非常に記憶に残る会でした。

何が最高だったか

・Go,GAE,RxSwiftという、本番導入の際に目新しさがありつつも、それをどう導入検討したか、実際書くときにどんな機能でそれが必要かが詳細に語られていて、実際に自分たちも使える可能性があるな、と強く意識できた点。
・技術要件だけでなく、ビジネス要件、組織として最適な形であるためにどんな技術を選択するべきか考慮された話だった点。
・技術面のトークに終始しており、参加者側として集中が途切れなかったところ。(むしろアッテ自体の紹介やリクルーティングの時間がほぼなかったのですが、逆に技術的なアピールポイントがあれば人は自然と寄ってくるという余裕があるように見えたので、好印象でした)
・ビール

印象的だった点

http://blog.mogmet.com/attefes-go-swift/blog.mogmet.com


プレゼンの網羅的な内容はこちらに記載されているのを見た方がより良いと思うので、印象的だった点を書いていきます。

鶴岡 達也さん【atte開発の技術 -GolangGoogle Cloud Platform-】

DAU数千万、グローバル展開、モバイルファースト前提という要件のお話しをまずされていました。
アークテクチャの一貫性を重視されていて、メルカリ時代に予想を上回る勢いでアークテクチャが変化していったため、その反省点を生かして、一貫性を重要な評価軸にしていたそうです。
ただ一貫性があれば保守的であっていいかといえばそうではなく、将来を見越してエンジニアにとって魅力的で、多様性のある技術開拓の場であれるかという観点も加えられていました。

GCPを検討する際には、Google担当者の方に1ヶ月ついてもらいつつ検証してみたということもあり、行動力とより客観的であろうという姿勢が魅力的でした。また逆にGoogle社も、数年前とは大きく状況が異なっていて、サポートが充実しているため検証もしやすかったそうです。

Goに関しては、もともとメルカリの方がミドルウェアでノウハウが溜まっていたとのことで、僕自身もwidebulletのスライドを見てすごいなーと勝手に思っていて、まあ主な導入理由はそこだろうという考えで行ったら、それに止まらず、割と初心者で固まって開発していたそうです。

widebulletについては以下参照。JSON-RPCのリクエストをnginx前段に立てて、REST API形式で叩くように変換してくれるミドルウェアらしいです。

speakerdeck.com


社内にGolang界ですごい人(gaurunやwidebulletのコミットからしてcubicdaiyaさんとかだと思いますが)がいたが、あえてGo初心者でチームを固めて、初動の学習コストをはかりに行くという大胆さについてお話しされていました。
それでも導入できたのでGolangの導入ハードルは低いというのを体を張って証明されていたようでした。

GAEの話に移って、主にハイスケーラブルであることを考慮して、NoSQLモデルを選ばれたとのことでした。
また、GAEについてるリアルタイムログ機能のおかげで、ビジネスサイドの分析時に有用になるデータのトレーシングが簡単にできる点もよかったとのことです。

あとかなり驚いたのが、Goをベースに立ってるインスタンスが、起動までに200msかからないとのことでした。

大庭 慎一郎さん 【SwiftとRxSwift】

このプレゼンが一番実際のスライドがあったら嬉しいのですが、前半に型の安全性を考慮して、SwiftやJSONRPC-kitを採用されたお話し、中盤からはRxSwiftを題材にリアクティブプログラミングのお話しでした。

必要な処理をストリームという単位で扱い、加工、フィルタリングを行う方式で、その実用例をコードを見つつ解説されていました。
インクリメンタルサーチや画像アップロード機能等、どの画面で必要になりそうかがわかる実例ベースで説明されていました。
RxJSでワイワイ言われてるときに入門し損ねたタイプだったので、非常にありがたく、mapとかreduceとかガンガン使っていけて、一つの処理をまとめられると確かに無駄にメソッドに切り出すこともなく綺麗でした。

ただ一方で、大庭さんご自身が「リアクティブプログラミングに慣れすぎると、一からこの処理を書けって言われたときに案外忘れそうになって不安になる。プログラミング力が下がる恐れがある」とおっしゃっていて(実際大庭さんが下がっているとは思えないのですが)、隠蔽される箇所が多くなるのと、書き方間違えると他人に読みにくいコードになるだろうから、使う場所は最初は限定した方がいいかもなと思います。

石川 洋資さん 【アッテiOSの設計と開発フローの変遷】

Try! Swiftでご登壇されていた石川さん。
iOSがどうこう、というよりは、処理の共通化とキャッシュ戦略についてでした。

ページネーション、フォームのバリデーションなど、多くのページで共通で用いる処理をどう共通化するか、と言うお話で、Swiftプロトコルで処理のI/Oを記述しておき、実際の処理では全画面共通の機能を入れるとのことでした。それだけ聞くとまあ、という感じですが、実際にページネーションを例に、ページのリクエスト情報を受け取り、レスポンスと次のページがあるかというフラグを返すプロトコルにしておき、そのページをどう扱うかは各画面専用のクラスに任せており、責任の分割が綺麗にされていました。本当に共通化しているところがどこなのかを見極めて、小さな範囲でもそこだけは最低限安全に保つという方が、最終的に共通の処理を書き直してさらに共通化して...というような流れを踏まずに済みそうです。

キャッシュ戦略については、RealmとLRUディスクキャッシュ
のお話しでした。当初Realmで全てキャッシュしていたものを、レスポンスの永続化と、各画面で共通に変更を見たいようなデータの保存先として集中させる方針をとったそうです。というのも、基本的に大事なデータはサーバーが持っていてくれるだろという信頼がある前提で、捨てていけるデータは捨てていこうということでした。限られた範囲のビューで完結するキャッシュは、LRU(最近最も使われていないデータを最初に捨てることで、不要なデータをパージしてキャッシュ効率を上げる)という方式で、キャッシュを行っているそうです。

LRUキャッシュ実は勉強不足で知らなかったので帰ってgoのソースを見てたのですが、仕組みとしてはGetしたタイミングでList.MoveToFrontで要素を一番最初に持ってきて、Addしたタイミングで最も古いもの(リストの最後尾)を除去するという流れで、割とシンプルなオンメモリキャッシュでした。

参考

github.com

まとめ

総じて最高だった。
アッテチーム内で完結したノウハウではなく、今後参加者が学習 or 導入する上で踏みそうなポイントを踏まえて、概念の説明をしつつ導入でクリアした課題をお話しされていて、各位の強さが伝わってきました。

あと本当に凄いのは、最近話題になってた以下の記事であげられてる課題点が全てクリアされたプレゼンで、学習した実感がしっかり持てたことでした。本当に貴重なお話しをありがとうございました。

shin1x1.hatenablog.com


もっとこうして欲しかったところ

・正直トークの内容がよすぎてあんま気にならなかったのですが、最初マイク不調すぎだったので、よりよいマイクを...!
・登壇者の方だけで語り尽くせない部分もあったと思うので、もっとメルカリ社の方々とお話ししたかった気持ちもある。

余談

・ソウゾウの方々、自社のことをソウゾウ社って言ってて、最初なんやなんや世界を創ったんかという気持ちだったが、最終的にこれ言えると気持ちいいやつだなとほっこりして帰りました。
・個人的に懇親会も最高だった。
・mono-repositoryで開発されてるとのことだったのですが、マイクロサービス化とか検討しなかったんですか云々という質問をして、アッテのトートバックをもらいました。ペンギンがかわいい。

f:id:u_tis:20160420001802j:plain

以上だ!また勉強があったら行きたいです!