Architecture Night #2に参加してきた
Architecture Night #2
2019/10/18@サイバーエージェント
https://architecture-night.connpass.com/event/147171/
10/18（金）に「アーキテクチャナイト」というアーキテクチャについての各社の取り込みや思想についての発表があるイベントに参加してきました。 ここ最近は言語やツール、もしくはサービス・会社単位での勉強会のみならず、こういった設計やアーキテクチャをテーマとした勉強会が増えているように感じます。
1.WinTicket におけるリアルタイム性と高負荷を考慮したアーキテクチャ(CyberAgent 江頭さん)
メモ
- WinTicketとはオンラインの競輪投票サービス
- 購入・払い戻しのすべての責任を負う
- 常に最新の情報を取得・提供する必要がある = リアルタイム性が求められる
技術スタック
- golang
- k8s(GKE)
- envoy
- アンバサダーパターンを利用
- 当時はistioはアルファやベータ版が主だったのでenvoyを選択
- cloud spanner(DB)
- 3secでスケールアウトできる
fastly
映像周りは aws(elemental media service)
- 認証はfirebase
k8s
- 36個のマイクロサービスが動いている
- Gatewayパターン
- アンバサダーパターン
- どこかが落ちても継続して動かし続けたかったため
- オートスケールが出来るような構成
envoy
- サービスメッシュで可用性の向上
- Outlier detection
- 異常検知のこと
- ここではエラーが多い場合に自動で外す機能のことっぽい
- circuit breaker
- LB
- retry
- ロールアウト時に500エラーを返すなどが結構あるので、その場合にもenvoyがリトライやアクセスが行かないようにするなどハンドリングしてくれる
- Outlier detection
- ロギングなども envoy任せにしている
cloud spanner
- 下記の要件、リスクに対応できるようなものとしてcloud spannerを利用
- 金銭の取引があるのでトランザクション必須なため
- 購入できない場合は事業的損失が大きいというリスク
- レースの締め切り直前などは負荷が大きいというリスク
fastly
- リアルタイム性が求められるので利用
- Instant Purgeが決め手だった
- 導入した結果レイテンシをかなり抑えられている
- goのsingleflight という関数の多重呼び出しを抑制するメカに済でキャッシュミス時のオリジンへの負荷対策をしている
- キーに対して1つしか実行されない
- 参考. golang.org/x/sync/singleflightで重複呼び出しを排除する
サービス
- 払い戻しはキューイングしてワーカーで処理(cloud pub-sub)
- 30 万ユーザーに3分以内に払い戻し、という要件に対応するため
- 1000 ユーザー/sec で払い戻しできることを確認
- 当初の要件は満たせていないが、3 分で18万ユーザーなのでとりあえずここに着地
- 払い戻しはロックを取っている
- ロックでぶつかることはあまりない。ぶつかっても問題にはなっていない
- ミッションクリティカルな処理では UUIDv4 をリクエストに付加して多重実行を防いでいる
- ユーザ作成などは requests テーブルを用意して多重実行されても重複エラーになるようにしている
分散システムでのデザインパターン(?)
感想
お金が絡んでいることやリアルタイム性が重視されていることからか、要件もかなり高度なものが求められているように感じたが、 そこに対してGKEの機能やサービスをうまく活用して対応しているという印象を受けました。 分散システム、クラウドサービスをりゆおする場合のデザインパターンやWebの仕組みを踏まえた対応を、 サービスの環境を活用しながら着実にそして確実に実践することで、おそらく規模の大きいサービスをしっかり運用されているのだなと思い、 学ぶべきところ、見習うべきところがたくさんあるのではと感じたセッションでした。
2.秒間数千万メトリクスを裁く監視基盤のアーキテクチャ(LINE 株式会社 @dxhuy さん)
メモ
Observability
- 昔から使っているモニタリングプラットフォームを使っている
メトリクスのストレージを自前で開発している
- put(バッチ insert)とレンジを指定してデータポイントをクエリする 2 つの機能のみ
mysql や OpenTSDB では限界がきたので新しいストレージの開発の着手を始めた
- OpenTSDB でも書き込みは早いが、read に時間がかかる
- その他の OSS も試したが要件を満たせるものがなかった
要件
- 1ホスト辺り１万弱のメトリクスを保存。それを数十万ホスト
アーキテクチャ
- 機能ごとにマイクロサービスに分散
- 直近 28 時間のデータを全部メモリにのせる
grpc を利用 -> 早くはない。便利な機能が揃っている（クライアント LB など）
Redis や Memcached などは時系列データを効率的に圧縮するのが難しいため利用できない
圧縮には Facebook goriila delta-delta XOR アルゴリズムを利用(prometheus と同様)
再起動対応は、Write Ahead log（ディスクに書いてからメモリに保存）。ディスク保存のバックエンドは RocksDB
ネットワーク障害などによるロスを防ぐために、書き込み失敗した場合は kafka に書き込んで、DB に流している
1つのホストが死んでもデータロスを発生させない
- RAFT ベースでクラスターを構築
永続ストレージは cassandra を利用
- in-memory から GRPC で cassandra に転送
- 4h ごとにバッチ転送
表側は grafana だろうが prometheus だろうが http/udp などだいたい対応している
スケールイン／アウトによるリシャーディングは？
感想
LINEさんのような大規模なサービスでの社内プラットフォームに求められるレベルの高さとともに、 その高いレベルの要求に対して、理論や今まの経験に基づくナレッジやスキル、その仮説や仕組みに対しての検証などをフルに活用されて対応しているということを、 良い意味でまざまざと見せつけられたセッションでした。 理論やアルゴリズムやデータに関することなど、初めて聞く内容も多いセッションでしたが、すごく丁寧に、なぜ？どうして？を説明されていてとても興味深いセッションでした。
3.MirrativサーバのCleanArchitecture移行物語（株式会社ミラティブ 夏さん）
メモ
- Android/iOSはflux化を進めている
- webではCleanArchitecture を導入
- API仕様はblueprintを利用
- goでclean architcture
- まずは慣れている perl を元に Clean architecture での設計をして go に移植していく予定
方針
感想
レガシーシステムにどう対応していっているのかについてのセッションで、 自分もここまでアーキテクチャなどをしっかり考えた対応ではないものの、レガシーシステムの作り変えなどの経験があったので、 その経験などを振り返り、共感したところやなるほど、そうやっているのかと思うところなどがたくさんあり、思わずメモもあまり取れずでした・・ 自分たちの手に馴染んでいる言語で、まずどう作っていくかや検証などを進めつつ、新しい言語、アーキテクチャに段階的に移行していくという手法は、 こういったケースで非常に有効なのではと思い、今回、学びを得たポイントの一つでした。
懇親会
懇親会では、iOSエンジニアの方やSREとサーバサイドエンジニアを兼務さrている方などとお話をさせていただいたが、 みなアンテナが高く、守備範囲も広く、自分も、もっと経験や興味の幅を広げるなどをしてその辺りをキャッチアップできるようにならなくてはと感じました。
あと印象的だったのはサーバサイドはなるべく状態を持たないようにして、アーキテクチャと状態は疎にしていく、というのがベストプラクティスだと言われることが多い一方で、 フロントエンドやiOS/Andoroidアプリは状態を管理するためのフレームワークが需実していたり、そこをどう管理してくのかについての議論も多く、「状態」をうまく管理してくことが求められるので、その辺りに違いを感じるという話がありました。 言われて確かにと思った一方で、自分がメインとしている分野以外もキャッチアップしていくことで「見えてくるものや得られるもの」の重要さを感じた一幕でした。
総じて、得られたものが多く、参加できてよかったイベントでした。主催、運営の方々どうもありがとうございました！
