Mercari Tech Conf 2018 に参加して見てきたテックカンパニーのマイクロサービス
だい2回めとなる、Mercari Tech Conf 2018 が昨日の木曜に開催され、平日にも関わらず500人くらい来てました。
ちなみに去年は300人って言ってた。
だいぶいい刺激をいただいたので、せっかくなので記事にします。
tl;dr
- テックカンパニーとしての熱量がすごい。僕がCAに入った時と同じようなものを感じた
- メルカリがすごいのはそれをオープンにやる。から、人が集まるんだろう
- 会場とかデザインとかスライドとか凝っててかっこいい
- 参加者全員にモバイルバッテリーと今半弁当くれるマネーパワー
- セッション途中に滲み出る採用宣伝、勧誘
- セッションはマイクロサービスと機械学習の話が大半
- マイクロサービスについては色々肌で感じられてよかった。この施策は、社内エンジニアの成長育成や採用フックという副次効果ともかなりあるとおもう。
- マイクロサービスは数百人規模のいまだからこそやる価値がありそう。逆に少ないフェイズだとやらないほうがいいとさえ感じる茨の道
- micro decisionという言葉もでてきて、各自が小さな決断を繰り返すことで成長してこうという話。名村さんが喋ってた
- 小さくわける、小さく保つというのは、それだけでいいことだということには共感できる。ただ、設計するのが意外と難しい
- 機械学習はかなりニッチな優秀エンジニアがしっかりやっている印象。CAのラボみたいな。
- 「mercari X」という、ブロックチェーン技術を使ったプロダクトを新発表。なういことはすべてやってる
気になったセッションについて
全部に言及すると、多すぎるので、つまむ。
なお、
当日のタイムテーブルはこちら: https://techconf.mercari.com/
資料はこちら: https://speakerdeck.com/mercari
スライドの一枚目が全部同じで見辛いw
★基調講演(名村さん)
テックカンパニーになりたいmercari。そのためにはどうすればいいか?
キーワードは「micro」。以下のような形でまとめられてたわけではないけど、聞こえてきたmicro hogehogeを羅列してみる。
- micro service
- micro service for client side
- micro deploy
- micro decision
スケールするための技術戦略として、micro decisionというワードも。
決断の粒度を可能な限り小さくし、スムーズにどこでもいつでも決断する機会が生まれるようにする。そのうち、これを繰り返すととで大きな決断もできるようになる。ということ。
言わずもがなのマイクロサービスを進めているmercariだけど、それもこの一環。
ちなみに、フロントエンドも同様にその方針で進めているらしい。
デプロイについてもmicro化。
一つのタスクをできるだけ小さくし、多数のタスクの結果シグナルを受信して、おkならば次に進めるという感じでやっていきたい所存らしい。
沈没したタイタニック船のバルクヘッドが機能しなかった話。こういうシステムにお客を載せるわけにはいかないので、一つの独立系を小さくし、不安定な連鎖反応を防ぐ。
以上のmicroさんたち。進化し続けるテックカンパニーを目指す。自走する個人、チームに向けてのいい目標、いい標語だと思う。
★基調講演(曾川 景介さん)
mercari Xという新プロダクトの発表があった。
ブロックチェーン技術を使った価値交換をやるためのものらしい。
機械学習の技術はすでに結構使われてるみたいだし、ナウいところは全部攻めてますね。
★Microservices Platform at Mercari
中島 大一さん
- 現在うごいているmicroservice: 19
- next: 73
めっちゃ増える…
microserviceのつらみ?
モノリスシステムだと、専門性でチームが分かれる。(例えば、backend, frontend, sre
microserviceやるにはそれぞれにowner(担当者)をおく。組織から変える必要がある。
それぞれのmicroserviceでtest,deployを担当する。
チームメンバーが少ないスタートアップだと、microserviceをやっていく決断をするかどうかはじっくり検討したほうがいいと思う。
少ないままに始めたら結局同一人物が複数のマイクロサービスをみることになり、本来の効能が得られないばかりか、作業能率は悪化しそうな気さえします。
ちなみにそのあと会場で会ったSREの友人は、マイクロサービスつらみという話を聞きました。理由は上記に似た感じのもの。
microserviceに関わるデベロッパーは、自然みんなが本来やらなくていいことを覚えなきゃだし、SREのような意識になり、周辺技術を身につけていかなければならない。
そういう意味では技術者としての成長角度はかなり上がりそう。
gRPCとproto
最近個人的にgRPCに興味ある。そんな中、.protoの扱い方の話が少しあったのでメモ。
メルカリでは全てprotocol buffer定義を一つのレポジトリで管理しているよう。そこをbackend, frontendが使う感じ。
これはmicroservice横断で一つということだと思う。micro A → micro Bみたいなこともあるし、多分認識あってるはず。
ドキュメントの機能も果たすのですごくよさげ。まとめたらまとめたで短所もありそうな気もするが。
provisioning
もちろんinfrastructure as code 的なことはちゃんとやってました。terraform。
逆にあの開発規模でやってないのは首締まるだろうなー。
starter-kit as templateってのを用意してるらしく、一瞬でプロジェクトを始められるそう。
deployに関してもterraform同様の形で、kubernates v2 providerを使って infra as code 進めているらしい。現在のデプロイにはSpinnakerを利用とのこと。
★from Monolithic to Microservices
李 同輝さん
既存システムからmicroserviceへの移行のtips
新機能追加とか既存の改修とかどうするか
既存APIと新しいserviceA, serviceBの前面にAPI Gatewayを置いて、振り分けるようにしたそう。細々とリリースできるし、少しずつリアルタイムにnewにシフトできるからいいですね。
★どうして僕らは決済処理をマイクロサービス化しようとしているのか
斎藤 祐一郎 さん
メルペイチームの決済処理移行。
踏み切った経緯
立て直しを重ねた温泉旅館のようなモノリシック
- スケールしない既存の決済処理
- 一方で新しい電子決済を加えなければならない
巨大なswitch分を読み解く 過酷な業務分析w これじゃスケールしない。
得られた効果
- 保守性向上
- 責務の分離
- 決済手段を簡単に追加できるようになった
同時に決済処理の際実装を行うことで決済処理を理解している人間が増えた。
これ意外と大事かも。僕も以前iOS/Android周りの購入処理を書いたんですが、当時新規チームで忙しく、仕様が複雑(特に iOS)なせいで、レビューもままならぬままMerge。怖かった。
分散トランザクション
モノリシックなシステムでは、db transactionを使うことでrollbackできるので簡単だた microserviceの分散システムだと...NO
ステートレスだと問題ないが、決済処理のようなステートフルな処理は、問題が起こる
問題1. カード処理とポイント処理。片方が失敗するケースがありうる。
解決策1:呼び出し側でtransactionの段階を分ける
- 支払い枠を抑える
- 支払い能力が担保された状態で購入処理を続ける
- 問題なければ支払い確定
- 問題あれば支払い枠を解放
とはいえ、結局、
支払い枠を解放
ここの実装が難しそう。
問題2. paymentServiceに障害が起きたら?
メソッド内で、networkを超えて実行しているので、通信経路に障害があるとどうなるか。次の処理が始まらない。
解決策2. ステートマシン
特徴:
- 非同期に処理が可能。呼び出し元を待たせない。
- 失敗じも再度キューイングして、自動リトライ。可用性が高い
- 復帰不能な失敗は状態を巻き戻しできる
ステートマシンという単語小難しくてよくわからない。勉強不足。
分散トランザクショショナルな処理を直列的にやると、通信詰まると死ぬから非同期にして全部終わったら次行こ(確定)ってことでしょうか。
1も2も解決してるけど、この分散トランザクションの問題は、送信先にそういう実装(機能)がないと実現できないんじゃないのかなー。例えば
- キャンセル処理
- dry-run的なチェック処理
まあ、削除処理的なのはあるだろうから最終的にはなんとかなるのかもだけど。
仮に、決済代行A、決済代行Bがあったとして、これが一つの分散トランザクション上にあるとして、上記のようなものを持っていなかったら、巻き戻しを実現するのって無理なきしかしない。
この辺教えて欲しいです。
会計システムへの影響をいかに減らすか。
いきなり移行できないので、平行期間が存在することを留意すべき。
- 決済システム移行じは記録は現システムと新システムで平行書き込み
- paymentserviceに完全移行次第、平行書き込みは終了。paymentserviceのみ。
★Listing Service: モノリスからマイクロサービスへ
森國 泰平さん
先ほども全く同じテーマのセッションを紹介しましたが、こちらの話はとても辛そうな話ばかりでした。
感じたツラミ1. gcp microからさくらインターネットDBへの接続
- リリースまではdb共有
- mysql portを外部公開したくない
solution
databaseだけは北海道においてけぼり。。しかしmysqlのportを晒したくないと。
結果どうしたかというと、dao layerもこちらにおいており、google cloudからそちらを呼んでいるようです。
そして移行のためだけに使うためのgRPCサービスを実装したという。インタフェースはシンプルで使いやすそう。
早く一緒にしてあげて欲しい。。
感じたツラミ2. 機能・追加修正への追随
解決策として、
感じたツラミ3. PHP例外との互換性
問題
解決
- php例外との互換性を保つためのgoのライブラリを開発
これきついだろうなー。これも先ほどと同じく移行専用のツール。
この問題はまさにモノリシックなやつで。負の遺産とはまさにこれのことでそうか。
★Web Application as a Microservice
杉浦 颯太さん
web版メルカリ、冒頭に出たmicroservice for client sideの話がまさにこのプロジェクト。
- 環境の変化
- web周りの技術の変化
このため、Web Re-architectというチームが発足
Goals:
- 変更に強い柔軟なアーキテクチャ
- 開発チームのスケーラビリティ向上
このためにやりたいこと
1 monolithic service to 4 microservices
いきなりこれやるの厳しいから、
1 monolithic service with 4 microservices
並行してやるってこと。これ、李さんの移行のセッションでも同じ手法を取っていましたね。
why?
- not renewal but re-architect
- 小さいスコープで移行する
- 先ずは小さなチャレンジと失敗を積み重ねる
microの思想というか方針が浸透してるんですね〜すごいなあ。
monolithic service + microservicesの共存
CDNはfastly使ってるらしい。
web gatewayを実装
- 各サービスへのbalancingを行う
- 初期は共存のため
- パスによる制御
- 公開範囲の制御
- session persistence
backendのmicroservice化はfrontendにとてどんな意味があるか
- 日々増えるmicroserviceの仕様の把握
- パフォーマンスを意識したコーディング
BFFというバッファリングサーバーを置く。それが複数のマイクロサービスを束ねる。 要するにAPI gateway?
ちなみにbacend for frontendの略らしい
セッション同期問題
- old monolithicにログインしたユーザーからnew microserviceにコール。どうする?
→session管理を行うmicroserviceを立てる
全てmicroserviceで解決!侍!
レイテンシ問題
物理的に距離がある場合ここがネックになる。
そして、mercariは先にも言ったように、ネックになる。
メルカリの北海道ー東京問題はなかなか大変そう。
Storateを前段に置いて、レスポンスキャッシュ。
以上!最後駆け足になった感ありますが。
上にあげたセッション以外にもたくさん面白そうなのありました。
セッションのほとんどはmicroserviceについてで、そうじゃなくても必ず触れると言ったように社内では今メインの関心ごととなっているようです。
また、流行りの機械学習やブロックチェーンについても早々と事業を打ち出していてさすがはと感じたところです。 誤解されないように、流行りだから、ではなくmercariの事業・サービスを実現に必要な手段・技術として適切に選択したといったところだと思います。
にしても恐ろしいテックカンパニーと畏敬の念を抱いたところであります。
来年もまたぜひ参加させていただきたい。