こんにちは、まっつーです。 Builderscon2019が終わって早1ヶ月が経とうとしていますが、builderscon2019の2日目に参加してきたのでそのレポートを書きたいと思います!
↓ マイクロアドのエンジニア達です。スポンサー特典で招待枠をもらったので参加させてもらいました!
目次
- Open SKT: メルペイ開発の裏側
- CN Buildpacksが作る未来
- 非同期処理の歴史から見たコンピューティングの進化
- ウォレットアプリ「Kyash」の先 〜「Kyash Direct」のアーキテクチャ〜
- まとめ
Open SKT: メルペイ開発の裏側
1本目は株式会社メルペイ Masahiro Sanoさんの発表を聞きました。 「Open SKT: メルペイ開発の裏側」ということで、幅広いテーマを取り上げて、タイトル通り開発の裏側を紹介されていました。
金融系サービスということで、やはりトランザクション管理は重大なテーマになるようです。また、メルペイは40以上のマイクロサービスで構成されているとのことで、プロダクトの規模の大きさがうかがえます。
さらにサービス毎に開発チームが分かれている都合上、サービス間での協調は難しいといった理由から下記の「決済サービス」による中央管理の方針に決まったそうです。
そして驚きだったのが、コーディネーションには「状態遷移モデル」を利用しているとのこと。 異常時を想定した状態遷移モデルを定義し、各状態を記憶しておくことで、あらゆる状況でシステムがダウンした際にも、処理を再開できるとのことです。
状態をどのように保存しているのかは気になりますが、少なくともどこかに永続化する必要がありそうですね。気になります！
さて、状態はTry, Confirm, Cancelが定義されており、2相コミットでいうPrepare, Commit, Abortの意味に近そうな印象でした。
他にも不正検知、開発フローのお話等々、驚きや参考になることばかりでした。
CN Buildpacksが作る未来
続いては、GMOペパボ株式会社 @pyama86さんの発表を聞いてきました。 CloudNative Buildpacks(CNB)自体初めて知ったこともあり、大変勉強になりました。
まず、Buildpackとは「herokuやCloudFoundryで開発されてきたコンテナビルドの仕組み」とのことです。 なるほど、個人的には「開発者はソースコードさえ書けば、後のビルドやデプロイをよしなにやってくれるモノ」という理解をしました。
Buildpackは元々使われていた技術でしたが、2018年10月にCNCF Sandboxに追加(プロジェクト自体は同年1月に開始)されたことで、CNBが誕生したようです。 CNBはOCI(Open Container Initiative)イメージを作成する仕組みとのことです。OCIという業界標準化団体によって、コンテナイメージ等の標準化が進められており、OCI v1というRuntime SpecとFoirmat Specを定めているそうです。
そして、Buildpack lifecycleの具体的な説明と実際にRubyのイメージをbuildするデモンストレーションを交えながら詳しい説明を聞かせて頂けました。
Buildpack lifecycleとは処理フローのことで、大まかに下記の工程が必要になるようです。
また、DockerfileとCNBの比較も興味深かったです。 CNBを使うことで散在しがちなDockerfileの管理から解放され、ビルド環境がBuilder Imageにまとめられる点は便利そうに感じました。 ただし、Dockerデーモンに依存しているので特権が必要とのことで、メリットばかりではないようです。
最後は「Kubernetesの登場によりインフラエンジニアはどうなる？」をテーマにした興味深いお話に。 アプリケーションエンジニア、プラットフォームエンジニアに分け、前者はアプリ開発に集中、後者は実行環境の開発、運用の責務を負うのではないか、といった考察をされておりました。
非同期処理の歴史から見たコンピューティングの進化
そして、マーベリック株式会社 リチャード伊真岡さんから「非同期処理の歴史から見たコンピューティングの進化」の発表を聞いてきました。 Java/Scalaから見た非同期処理の歴史を追っていくお話で、Scalaエンジニアとしては大変うれしい発表でした！
まず、CPUのクロック数が2005年頃に頭打ちになり、以降はマルチコアが主流になり始めた、という歴史的な背景の説明から丁寧にして頂きました。 2004年、Java5.0にはjava.util.concurrentパッケージが追加され、並行プログラミングをサポートするようになり、これが非同期処理の始まりにあたるとのことです。 下記より、マルチコアCPUの登場時期と時系列的にも被っていることからも納得です。
thread interference, data race、C10K問題などを取り上げながら、それらをどのように解決したかを図や動画を用いた説明で非常にわかりやすかったです。
また、発表の終盤ではAkkaのアクターモデルが取り上げられていました。 Akka Actorの性質によって、volatileを指定するなどのデータ競合に対処する必要がなくなる利点を話した上で、共有変数を扱う方法の1つの解であると紹介されていました。
マイクロアドでは、Akka Actorを含む多くのAkkaツールキットを利用しておりますが、まさに本セッションで挙げられていたような問題を如何に解決できるかを考慮した結果、Akkaを採用しています。
他にも盛り沢山な内容で、最早ここで語れる規模の発表ではありませんので、是非動画や資料等を閲覧して頂きたいです。 また、参考資料もたくさん紹介して下さっていますので、必見です！
ウォレットアプリ「Kyash」の先 〜「Kyash Direct」のアーキテクチャ〜
最後は株式会社Kyash 岩藤さんから「ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ」を聞きました。 法人向けの新決済プラットフォーム「Kyash Direct」の開発の裏側を赤裸々に語られており、非常に貴重なお話だと思います。
まず、既存の資産を使わず、スクラッチ開発に踏み切った経緯が非常にパッションに溢れていて、聞いていて非常に楽しかったです。 もちろん、意思決定の要因は下記のようにいくつもあるとのことでしたが、特に「面白そう」の部分を強調されていたのが印象的でした。（面白さ、大事！）
そして、アーキテクチャ設計において大きな選択となったのが、「Microservices」と「Monolith」だったとのことです。 エンジニア数が十分でないことで、運用管理、障害調査が辛い等は懸念としてはあったものの、将来的なスケールの容易さ、デプロイのしやすさ等のメリットを優先し、「Microservices」を選択したとのことでした。 ここでもあえて困難に挑戦していく姿勢に感動。
そして、お話はアーキテクチャの具体的な内容になっていきます。 まず、各サービスの独立性を保つために、DDDの「境界づけられたコンテキスト」毎にサービスを分割、DBもサービス毎に分割するという大胆な手法を取っていました。 ちなみにサービスの分割は「意外にシュッ」と決まったそうです。
DBに関しては、下記のようなサービス毎にDBを持ちつつ、障害時の復旧等を想定したイベントストアを組み合わせる方法になったとのことです。
サービス間の連携にはPub/Subを利用し、全てのサービスはPub/Sub経由で連携するようで、これによりサービスの依存を局所化できるそうです。
しかし、サービス毎にDBを持つようにしたため、サービスをまたいだ処理をする場合、「補償トランザクション」の仕組みが必要になり、またイベントソーシングを実現するためのストレージもコストがかかるそうです。 「補償トランザクション」には「Sagaパターン」を採用したとのことで、株式会社メルペイ Masahiro Sanoさんの発表にもあった「状態遷移モデル」の仕組みと共通点もあるような印象を受けました。
と、まだまだたくさん内容はありましたが(他にも分散トレーシングのお話等々)、同様に書ききれませんので、動画、資料等を是非見て頂きたいです。
まとめ
Builderscon初参加だったのですが、予想以上に密度の濃い発表ばかりで非常に楽しめました。 こちらの記事には、まとめる都合上で詳細に立ち入れてない部分が多々ありますので、引用させてもらった資料や後日公開される予定の動画を見て頂ければ幸いです。
来年も参加します！
