architecture-night.connpass.com
千葉に引っ越してから、渋谷あたりで開催されるイベントにあんまり行かなくなっていたが、Twitterで設計メインのArchitecture Nightというものがあると知って会社の先輩と参加した。アーキテクチャと銘打っているくらいだから、きっとクリーン・アーキテクチャやデザインパターン、オブジェクト指向などのワードがどんちゃか出てくるのかと思ったが、このあたりのレイヤーにとどまらず、かなりよかった。
『WinTicketにおけるリアルタイム性と高負荷を考慮したアーキテクチャ』
GCPを使った開発をしているとのことで非常に親近感があった。弊社ではDBにGCP Datastoreを使っているが、WinTicketでは金を積んでSpannerを使っているとのこと。懇親会で費用について話を聞いたところ、開発環境だが本番環境だか忘れたが月ウン十万はかかっているらしい。やはり競輪のようなギャンブル事業ともなると動く金も大きいので、そこにかけるコストもケチる意味はあまりないのかもしれない。
DBサーバへ負荷がかかるタイミングでPubsubに対してキューを積み、それをサブスクライブしているワーカーが並列で処理していくというQueue-based Load Levellingが紹介されたが、自分が普段会社で「タスクをちぎる」と教えられているアレはコレだったのか、と思った。メールや通知の送信やら、バッチでの一斉データ更新をこのパターンで行っている。また、マイクロサービスをモノレポで運用してるところも同じで、これがいまの流行りなのかなと思った。
『秒間数千万メトリクスを裁く監視基盤のアーキテクチャ』
個人的にかなり勉強になった。LINEで監視基盤として時系列データベースの内製とそのアーキテクチャ設計をしているという話。
ログ収集基盤を作るにあたって、ReadとWriteとどちらが多いか、どこまでのデータをオンメモリにしてどこまでをファイルとして圧縮するか、などはアプリケーションの特性を判断するにあたって常に重要なヒントだと思う。アプリケーションの特性をちゃんと分析することで、RDBMSではなくあえてCassandraをバックエンドDBとして選択したり*1、データの圧縮アルゴリズムを差分符号化*2にしたり、自分たちの必要とする要件にフィットするような選択ができるようになるんじゃないかなと思う。
アプリケーションの要件分析の重要性
今回のミートアップで思ったが、結局コードがかけて設計が得意でもアプリケーションの要件分析ができなければ何の意味もないよね、というのが最近思うところ。これはISUCONでも同じだと思う。
スタートアップで本当に最初のMVPを作る段階ではとりあえず雑にMySQLを選んでおいても良いと思うが、ビジネスがグロースするにつれて、アプリケーションドメインの特性上実はファイルIOが多かっただとか、ReadよりもWriteなリクエストのほうが多いだとかが分かってくる。例えば、LINEの人が話していたログ収集基盤はCGM的なウェブサービスと比べて圧倒的にWriteに求められる即応性のほうが比重が大きく、その分Readに対する処理はゆっくりやってOK、というような要件があった。
このあたりの嗅覚は技術選定を含むアーキテクチャ設計にまるごと影響を与えるものだと思うし、とくに10→100あたりのサービスグロースにあたってはソフトウェア・エンジニアに対して平均して求められる能力な気がする。
今回のArchitecture Nightで聞いた話が「なにもわからない」状態にならなかったのは、やはり自分の個人的バイブルであるデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理を読んでいたからのような気がする。この本の中でも時系列データベースがいくつかとりあげられていたし、もちろんCassandraも出てきた。最初はどこで使うようなDBなのかさっぱりだったが、今回のミートアップのようにリアルな実例を聞くとわかりがすごい。
*1:厳密にはRocksDBも併用していた
*2:厳密には、Facebookが開発したberingeiというオンメモリ時系列データベースが採用しているdelta-delta圧縮というのを使っているとのこと https://github.com/facebookarchive/beringei
