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