2019/08/23のbuildersconに参加してきました
今回は、非同期処理や分散システムなどに興味があったので、そこをメインで見てきました
参加したセッション
- メルペイ開発の裏側
- RDBのトラブルの現場を追え！
- Web API に秩序を与える Protocol Buffers 活用法
- Optimizing Ruby with JIT - 最速の言語を目指して
- ウォレットアプリ「Kyash」の先 〜「Kyash Direct」のアーキテクチャ〜
メルペイ開発の裏側
参加にあたって、特に気になっていたところ
- データ整合性の担保をどうしているのか？
- ロールバックはどうしているのか？
1. データ整合性の担保をどうしているのか？
基本はリトライし、継続不可能なときのみ、処理をやめるようです
リトライと冪等性 - どんなエラーが出ても基本的にリトライする - 冪等性を担保して二重処理されないようにする - 継続不可能なときのみ処理をやめる
引用：P.22
リコンサイル
［名］(スル)《一致させる、の意》複数帳簿間で残高照合を行うこと。また、金融関連では外国の銀行に保有する口座の取引明細と、自行の処理した取引明細と照合すること。 引用：リコンサイル
することで、データの整合性を担保しているそうです
データの整合性を確認すること - 会計データが完全な状態だということを保証する - 各マイクロサービスと会計システム間
引用：P.29
2. ロールバックはどうしているのか？
状態遷移モデルを採用し、どんな処理でも意図せず落ちることがある為、処理単位を記録するように状態を定義しているようです
ロールバックも状態遷移で定義 - 途中で継続不可能（tryが失敗）した場合も遷移先が異なるだけ - Cancelを行う状態を定義して一貫したモデルで扱う 引用：P.25
感想
トランザクション管理はやはり難しそうで、データ整合性を担保する為に、かなり安全に倒して設計されているんだなと思いました
また開発もサービス安定性、品質を重視されているので、リリースまで重厚なプロセスがあると感じました
RDBのトラブルの現場を追え！
参加にあたって、特に気になっていたところ
- どうやって障害理由を切り分け、そして対応してきたのか？
1. どうやって障害理由を切り分け、そして対応してきたのか？
壊れたとは何かをちゃんと特定すること たとえば、
- 突然パフォーマンスが悪化した
- データの不整合が発生している
- データベースが応答を返さない
- コネクションが溢れている
- 間違えてDROP TABLEしちゃった（バルス）
引用
感想
これは知らないDBの機能でした
- MySQLだと beginしても DROP TABLEするとauto commitが走って消える
バルクインサートより、MySQLならLOAD、PostgreSQLならCOPYが早い
MysqlSQLはこちら
PostgreSQLはこちらテキストファイルからテーブルをロードする場合は LOAD DATA INFILE を使用します。通常、これは INSERT ステートメントを使用する場合より、20 倍速くなります。セクション13.2.6「LOAD DATA INFILE 構文」を参照してください。
PostgreSQL に大量のデータを高速に取り込む方法を紹介します。 COPY という専用のコマンドを使うと INSERT よりもずっと高速です。 また、COPY を使う際にひと工夫すると、さらに速くなります。
- B-Treeインデックスは全体の10%くらいのデータ量じゃないとインデックス効かない
Web API に秩序を与える Protocol Buffers 活用法
参加にあたって、特に気になっていたところ
- Web APIのSchema管理について
1. Web APIのSchema管理について
- .proto ファイルを記述して、コードを自動生成する
- 豊富なpluginでswagger.jsonの生成も可能
感想
実装よりも振る舞いに集中するして開発できるのはかなり楽だなと思いました .proto file 自体もシンプルに見えるので、学習コストもあまりかからず導入できそうだなと感じました
Optimizing Ruby with JIT - 最速の言語を目指して
参加にあたって、特に気になっていたところ
- RubyのJust-In-Timeコンパイラがいかにしてそのような言語の高速化を実現しているかのエッセンス
1. RubyのJust-In-Timeコンパイラがいかにしてそのような言語の高速化を実現しているかのエッセンス
- 機械語にしただけでは、早くならない
- 処理を減らすことが最適化への道
感想
JIT コンパイラが何をやっているのか？を知らなかったので、ここが学べたのは、非常に大きいなと思いました
ウォレットアプリ「Kyash」の先 〜「Kyash Direct」のアーキテクチャ〜
参加にあたって、特に気になっていたところ
- いろいろな設計を行っているが運用してみてどうだったのか？
- DDD
- Clean Architecture
- Microservices
- Orchestration/Choreography
- Message Pub/Sub
- Event Driven Architecture/Event Sourcing
- CQRS
- 分散Tracing
1. いろいろな設計を行っているが運用してみてどうだったのか？
運用はこれからなので、まだまだ試行錯誤が続きそう。。。
とのことでした
マイクロサービスの選択理由
- モノリスにするには巨大で複雑すぎる
- 部分的な変更が全体に影響を及ぼすのを避けたい
- 部分ごとに負荷が大きく異なる
- 外部サービスとの接続部分を切り離しておきたい
- 機能追加のスピードは極力落としたくない
Pros.
- 各サービス単体では、小さくてシンプル
- 変更の影響を局所化できる
- スケールしやすい
- デプロイしやすい
- リソース配分を最適化しやすい
Cons.
- 設計・実装が難しい
感想
イベントドリブンアーキテクチャの設計を見たことがなかったので、ここまで難しいのかということと、かなり複雑なアーキテクチャで運用がつらそうと思ったが、エンジニアとしてはかなり刺激的だなと思いました
今日一日の感想
仕事でもすぐに生かしていけそうな知識からエンジニアとしての基礎力を上げるような内容まで幅広く非常に楽しめた一日でした
※ 当日貰ったTシャツとバック
