Runner in the High

技術のことをかくこころみ

クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか

何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 https://blog.tai2.net/images/CleanArchitecture.jpg 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。

ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの?」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。

Software Engineeringでは同様の質問がかなり盛り上がっている。同じようなことはみんな考えるのである。この質問についている回答群はどれもかなり興味深いので、ぜひすべての回答に目を通しておきたい。 softwareengineering.stackexchange.com

UsecaseがPresenterを呼び出すメリットは"UsecaseがPresenterをどう使うかを制御できること"

結論としてメリットはこれに尽きる。

ひとつの例として、もしもPresenterの呼び出しがControllerサイドですべて行われるとしたら、Usecaseの呼び出しののちにPresenterの呼び出しを行わないようなコードが書かれてしまっても、コードレビューで防ぐ以外の方法がない。しかしUsecaseでPresenterを利用するということが実装上約束されていれば、基盤ごと破壊されない限りはUsecaseの呼び出しとPresenterの呼び出しをセットにして実装のミスを防ぐことができる。

また別の例として、Presenterが特定の条件によって呼ばれたり呼ばれなかったり、また複数のPresenterが条件によって呼び分けられたり、呼び出し順序にルールを与える実装が必要になったりするケースでは、もはやアダプタ層であるControllerがここまでの知識を責務として持つのはおかしい。したがってドメイン層であるUsecaseにこのような知識が存在しているほうが自然であると言える。

つまり、PresenterをUsecaseが呼び出すところまでをドメイン層の責務としてカバーすることで、実装のミスとドメインロジックの流出を防いだ堅牢なものにすることができている。これこそまさに原典なりのあるべき姿であると言える。

返り値による表現にアドバンテージがあるケース

とはいえUsecaseがControllerに返り値を与えるパターンが有利なのは、コード表現としての簡潔さやシンプルさが求められる場合である。

さほど規模の大きくないWebアプリケーションを作っている限りは、ほとんどの場合RESTやJSONRPCなどを素直にレンダリングするだけのPresenterで溢れるだろう。その場合にわざわざOutput Portのようなインターフェイスを作って完璧にFlow of Controlを守る価値が果たしてあるのかと言われると疑問が残る。もちろん未来のことは分からないが、実装を差し替えたりテストしたりする必要もさほどなければ、存在する意味もない。

また、実際にやってみると分かるが、ウェブ・フレームワークによってはクリーンアーキテクチャのPresenterという存在との相性が悪いケースがある。クリーンアーキテクチャではPresenterはコールバック的な扱いとしてUsecaseから利用されるが、フレームワークによってはリクエストハンドラの関数の返り値としてレスポンスのデータを返さないと処理が正しく終えられないものがある。UsecaseはControllerの中で実行されてもそれ自体は何も値を返さないため、このタイプのフレームワークとは相性が悪い。こうなると、例えばScalaで言うところのPromiseなどを使って手の込んだ実装をせねばならず、まあまあめんどくさい。

この相性の悪さについてはnrsさんも以下の記事で言及している nrslib.com

加えて、ボブおじさんの言うPresenterは我々がAPIサーバを作る際にイメージするそれよりも、もう少し重厚なHTMLのDOM構造のレンダリングなどに相当するもののようである。

例えばクリーンアーキテクチャの本ではHumble Objectなどのパターンなどが言及されているが、それこそ今の時代のフロントエンド文脈で言う「画面と状態の分離」とほぼ同じことを言っているくらいには、いわゆるフロントエンド領域の設計にまで踏み込んでいる。今現在一般的な、フロントエンド・アプリケーションをSPAとして作り、サーバはプレゼンター層でJSONを毎度返すだけというようなケースではOutput Portのような抽象化は必ずしも必要ではない場合があるし、むしろ使わないほうがポジティブなこともあると言える。

余談

この記事は、現在弊社にインターンで来ている学生とタイトル通りのディスカッションをしたので、ふと思い出して書いてみた。なんでもまずは原典にあたるのは大事であるが、とはいえ「ボブおじさんが言ってるんだからそうするのが当たり前」という考え方はあまりにも思考停止すぎる。アプリケーション設計にはたったひとつの正解なんてないので、こうやって常に疑問を持ちながら探し歩くほかない。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

携帯電話開発とYRP

この記事が気になったのでいろいろ調べてみた

togetter.com

端的に言うとSESで常駐になる企業は地域的な危険性がある、という話。そもそもSESという業態自体がどこにいってもヤバいのかもしれないが、それはそれとして具体的な地名がいくつも挙げられ、そしてそれに共感する人が多いところにも謎のおもしろさがある。

我々一般人からするとただ遊びに行くだけの場所であった豊洲やお台場も、こうしてみるとなんとも言えない感覚を覚える場所になる。「海沿いは総じて危険」というのが特に興味深い。確かに豊洲、お台場、勝どきなどのウォーターフロントから、東陽町門前仲町、木場、西葛西などのいわゆる大江戸下町アーバンタウンも多数エントリーしている。しかしこの江東区の多さたるや、不思議なものである。

YRP

出てくる地名の中でひときわ目を引くのがYRPである。一体YRPとはなんなのか。

https://lolipop-teru.ssl-lolipop.jp/gunsou/gunsou-catch01.jpg

その正体は神奈川県横須賀市に存在する施設で、正式名称は横須賀リサーチパークWikipediaによるとNTTやNEC、ドコモ、KDDI富士通など錚々たるメンツの集結する研究開発拠点とのこと*1Google Mapで所在地を軽く眺めてみると分かるが、マジで施設以外にコンビニもなにも存在していない。ひっそりと単身者用の寮が存在しているのも想像力を掻き立てられる。

この横須賀リサーチパーク、YRP軍曹と呼ばれる人間の手記によって別名横須賀リサーチ"プリズン"という名称が広く知られることとなった。その手記は次のリンクから読むことができる。

lolipop-teru.ssl-lolipop.jp

この手記は主にYRPで開発が行われていた携帯電話関連開発にまつわる手記であるが、どうも2004-2008年あたりの携帯開発の現場はかなり激しい環境だったようだ。

www.chococranky.com

確かに、思い出してみればその当時は本当にガラパゴス携帯全盛そのものであった。ソニー、京セラ、NEC、シャープ、富士通、などなど、多くの会社がしのぎを削って突飛な機能を詰め込んだ携帯電話を量産していた記憶がある。技術的なところではBREWやらDojaプロファイル、KCP+などが入り交じり、まさにガラパゴスなモバイル技術黎明期そのものであった。

自分も2006-2007頃といえばSO902iWP+を使っていたのを覚えている。また、2006年頃といえばNTTドコモによるプッシュトークの提供とも時期が重なる。誰があんな機能を使ってたんだ?と今思い返しても謎だが、どうやらその筋の人によると、そのプッシュトークも大くのエンジニアたちの命のもとに生まれたものらしい。

以下は2006年の記事だが、やはりその当時から激化する携帯電話開発競争の異常性は認知されていたようにも思える。

mimizun.com

■急ピッチの開発に現場が悲鳴

 なぜここまで携帯電話のソフト不具合が頻発するのか。最大の理由は、開発体制の構造的な問題にある。携帯電話会社の需要に、ソフトを開発するメーカー側の供給が追いつかないのだ。

 通話以外に、インターネット接続、ゲーム、音楽再生など、様々な機能が詰め込まれた携帯電話機は、開発の6~7割がソフト開発で占められる。進化のスピードも速く、1年間に最低4回は新モデルが登場。数年に1度のペースで新版が登場するパソコンソフトのそれをはるかに凌ぐ。プログラムの分量は6年前に比べて100倍以上に増えたと言われ、構造も複雑性を増している。

 こうした事態を改善するためには、「開発期間を十分に取って、適度な数に携帯電話機の開発数を抑える必要がある」(前出のソフト会社幹部)。

 ところが、そんな状況は見込めそうにない。携帯電話会社各社の競争激化によって、携帯電話機の新機種投入ピッチは以前にも増して上がっているからだ。

 例えばシャープの場合、昨年はドコモに5モデル、ボーダフォンに9モデルを出荷した。実に、毎月1台以上のペースで新機種を投入しているうえ、今後はKDDIへの携帯電話機供給も決まっており、開発機種はさらに増える。

「ケータイの開発はマジで死人が出る」 「携帯の開発現場凄いよ。マジで」 「携帯の開発にはもう二度とかかわりたくない」 などのレスがどこまで本当のことを言っているのかは分からないが、おそらくそれなりの事実があるのではないかと思う。

携帯電話が世の中の一般的なインフラになりはじめ、そしてMRRで継続した利益を得続けられるというビジネスモデルはどう見てもうまみ100%のビジネスモデルだったろう。端末と回線契約の抱き合わせ販売は海外では珍しい。しかし、日本ではこの当時から携帯キャリアの抱き合わせによる独占がはびこり、それが巡り巡って携帯関連開発案件のデスマ化に繋がったのではないかと思う。

いまでこそAndroidiOSという2大モバイルOSによる市場独占によって各社の独自ソフトウェア開発競争は終わりを迎えたようにも見えるが、果たしていまYRPはどうなったのだろうか。誰かこの当時のことを知ってる人がいたら教えてください。

*1:いまもWikiにかかれている企業群が在籍しているかは定かではない

昔からいるプログラマーたちはいまも職を失わずに仕事をしているのですか?

https://www.quora.com/What-happens-to-older-over-30-programmers-Do-they-get-fired-as-they-get-older-and-less-innovative-Does-mid-career-pay-increase-much-for-software-engineers/answer/Bruce-Hoult

ぼくは今年で55歳になる。81-84年ごろに大学を卒業して、働き始めたのが85年だ。同年代のプログラマーは多くなかったし、それに私達以前にはプログラマーはいなかった。もし君がITの領域で仕事をしようと思うのなら、競い合うことになるのはおそらくぼくらのような歳の人間ではなく、きみより5,6年ほど若い人間たちになるだろう。

で、どうしてるかって? まだコードを書いてるよ。

僕らが基本的に大学で扱っていたのはPascalだった。85-86年ごろにはデータ・ゼネラル社のスーパーミニを使い、87-89年ごろにはマッキントッシュ上でObject Pascalを書いて、89年後半ごろにC++を書き始めた。FirefoxLinuxカーネル, LLVMAndroid Java向けのJITコンパイラ、Tizen C/C++で動く.NETあたりのプロジェクトにも取り組んだのを覚えている。

もちろん、1994年にはPerlを(ちょうどPerl5が出始めたころ)、1998年にはJava、1999年にDylan, そして2001年にはPythonを勉強した。

2014年前半のぼくが51歳だったとき、丁度僕はニュージーランドで次の仕事を探していて、AmazonGoogleそしてSamsungにそれぞれ声をかけた。AmazonGoogleアメリカでのオンサイト・インタビューへと招待したが、Samsungは私に6ヶ月間の契約でリモートワークをオファーしてくれた。仕事はAndroidの改善に関わるもので、すぐに始まった。契約がそろそろ終わる、というころに私はモスクワにあるチームのみんなに会いに行った。そこで彼らは私に正社員としての契約をオファーしてくれたので、いまはそこで働いている。それ以来、おもにJavaC#, OpenCLを使ってコンパイラとランタイムシステムの開発をメインでやっている。

私の同僚はほとんどがとても若い。多くがロシアの優秀な大学で学士号以上の学位を持ってやってくる。彼らは間違いなくとても優秀だ。とはいえ、同じオフィスにいる自分を含め50を超えたプログラマーでも、やはり未だにマネジメントではなくプログラミングをしたがっているよ。

このBruceさんの回答以外にもめちゃくちゃいろんな回答がついていて興味深いが、どの人もやはり低レイヤな知識か、ソフトウェアのアーキテクチャに強みを持っているという印象が強い。ただコードを書けるだけでは生き残れないということがよく分かる。

Elmに興味があるなら見ておきたいIzumiSyのスライド3選

過去に「NoRedInk*1の筋肉の人」としておなじみリチャード・フェルドマンをフィーチャーする記事を書いたので、今度は自分をフィーチャーしようと思う。 www.izumisy.work

おすすめはやはり一番最後の「jQueryからElmまで」だが、正直このスライドはElmに関する説明成分が少なかったと反省しているところがある。なので、個人的にはこの記事で並べている順番に見てもらうほうが、Elmに対するわかりが生じやすいと思う。

Elm, the functional frontend

Elmの基本的な部分をざっくり説明するスライド。このスライドは関数型プログラミングカンファレンス2019で使った。Elm意外にもRustやElixirなどの関数型プログラミングのエッセンスを持つ言語の人たちとコラボレーションするタイプのイベントだったので、関数型的な部分に言及するのは少なめでElmの良さをアッピルするような内容にした。

Elmというとその文法がHaskellライクな部分に焦点が向きがちだが、個人的にもっと重要なのはやはりシンプルかつ必要充分な型システムと、そして万人にとって優しいエラーメッセージであると思う。型のある言語というと、絶対に型パズルから逃れられないような気がしてしまうが、Elmで型パズルをすることはそうそうない。あるとしても1年に1回あるかないかくらいだ。今年はElmで型パズルしてない。

また、フロントエンドという画面的な仕様変化の激しい領域で求められるのはMaintainabilityとProductivityの両立であり、そこにはやはり大胆に変更を加えることを恐れさせない型安全性が重要だというメッセージも込めた。このあたりのはなしはとても齟齬なく伝えられてよかった。 www.izumisy.work

Elmのあるきかた2019

Elm Meetup in Summerで使ったスライド。Elmのイベントだけあって、もうElmがなんたるかはある程度すっ飛ばした話にした。ひとつめのスライドでも、末尾の方でこのスライドに言及している。

Elmを学ぶ情報はググるといろいろと出てくるが、なかでも意外とあまり知られてないのがリチャード・フェルドマンのトーク動画だろう。あまりカンファレンスの動画というのは学習資料にならないようなイメージが自分の中にもあったが、しかしScalaやElmの動画というのは比較的具体のコードを交えた設計に関するトークなどがちらほらある。僕の所属する事業部では、Elmを書くフロントエンド・エンジニアが集まって彼の動画を見る会を開催したりしていたくらいには、リチャードの動画は学びが多い。 www.izumisy.work

なお、スライドの中で言及している一丁目ラボ技術報告は以下のリンクから購入できる。本当にElmの初歩的な内容をカバーしたものだが、それでも何も読まないよりはいいと思う。 1chome-lab.booth.pm

jQueryからElmまで

初夏のJavaScript祭り2019で話すのに使ったスライド。自分意外の登壇者がほとんどまじめな(?)JavaScriptばなしであったのに対して、自分だけElmでなかなかアウトサイダー感があった気がする。

内容的にはこれまでのフロントエンドでよく見られたカオスが、いかにしてFluxアーキテクチャによって統治され、そしてElmの持つパラダイムへと向かっていったかをそれっぽい雰囲気で話すもの。これまで触ってきたAngularやVue.js, Reactの経験を集約してフロントエンドの大変さがどこにあったのかを改めてアウトプットできたのは、常にいい経験になった。社内のLT会でも比較的好評だったので、それだけでも作ったかいはあった。

このスライドを見ると、やはりこれまでの自分のフロントエンドの経験というものが、改めてElmに対する思いや向き合い方に出ている気がするなと思った。特に「フロントエンドは大きな関数である」という考え方も、Elmをやるまでの自分には絶対になかったと思う。しかし、様々なフロントエンド・フレームワークに触れてからFluxを知り、そしてReduxに触れ、さらにその元になったElmに触れて、と来るともはやフロントエンド・アプリケーションが関数の組み合わせとして考えること自体が、むしろ自然で当然だったかのように思えてくる。 www.izumisy.work

総括

こう見ると結構Elmのトークしてるなぁ。これからもElmのあれこれをガンガン盛り上げていきたい。

あとmentaでElmのメンタリングやってるんで誰か(いまんとこゼロ人) menta.work

*1:Elmを開発するEvan擁するアメリカの教育系スタートアップ。Elm開発者のメッカ。

関数型プログラミングカンファレンス2019に登壇してElmの話をした

Scala, Haskell, Rust, Elixirあたりの関数型の匂いを感じさせる言語の人たちが、一堂に会してそれぞれのプログラミング言語のあれこれをトークする「関数型プログラミングカンファレンス2019 in Japan」というイベントが新しく爆誕していた。このイベントは今回初開催であったが、自分はElmの人としてトップバッターでトークをさせてもらった。

fpc2019japan-event.peatix.com

参加者規模でいうと100人くらいと言う感じで、茅場町のイベントスペースであるFinGATE KAYABAが会場であった。

個人的な話だが、もともと自分は新卒1年目の頃江東区のちょうどど真ん中に当たる扇橋という場所に住んでいた。なので、お隣の中央区は馬喰町や水天宮そしてもちろん茅場町も頻繁に天気のいい日にはお散歩することがよくあった。少しねばって歩けばすぐに東京駅にも行ける上、日本橋や銀座も近い。まさに大江戸アーバンシティを感じられる素晴らしい場所だと思う。大抵テック系の勉強会と言うと六本木や渋谷が定番であるが、もう少し東部の下町でもこういった活動が増えると嬉しい限りである。

自分のトークのトピックはElmであったが、少しづつElmが盛り上がってきているとはいえ、まだまだ知名度的にも少し不安であった。なので、内容としてはできるだけElmを知らない人にもそのよさをしっかりと感じてもらえるような万人向けの内容を作った。

僕が現在所属しているUniposは、現時点で日本最大規模のElmアプリケーションを開発しており、そこにはElmならではの良さがふんだんに感じられる機会がたくさんある。

自分はElm以外にも別件の開発案件やアルバイトでVue.jsやReactとTypeScriptを中-大規模で触った経験があり、それらと比較するとどうしてもElmマンセーとなってしまう状況のほうが多い。ただ、ちゃんとしたエビデンスもなしにマンセー言ってもただの宗教にしか見えないので、そこにはもう少し肉付けをした説明をすることとした。

正直、自分以外の人達はもう少し込み入った内容の話をしていたので、自分の内容は参加費を払って聞きに来てもらうに足りるものだっただろうか?という不安はあった。しかし、発表後の質疑応答はかなりいろんな人達から質問を頂けて嬉しい限りであった。

Twitterのタグタイムラインを見ていても、自分が一番強調したかったElmの特徴はエラーメッセージが徹底的に優しいことというポイントが共感頂けたようで、そこも意図通りの伝え方ができてよかった。また、Elmの徹底的な型安全性や、TEAによるアプリケーション構造のルールづけ、というあたりの話も、懇親会で比較的分かりを感じて頂けたという声があり、またElmの良さが伝えられてよかったという気持ちである。

Elmのプロダクション利用に関して

懇親会で数人の方から、Elmをプロダクトで利用してみたいな〜とは思うが実際やはりハードルが高いというはなしを頂いた。これは確かにそうだなと思う。リチャード・フェルドマン*1も、もし社内でElmを使いたいと思うならElmに詳しい人間を必ずひとりは用意しろと言っている。

これはたしかにそうで、Elmはどう考えても学習コストやメンテナビリティ的な観点からしてコストパフォーマンスに優れた言語であるが、それでもやはりひとりはメンターとなって様々なElmに関する"初めて"の意思決定を下すほうが圧倒的に失敗が少ない。これはElmに限らずReactやVue.jsでもそうだと思うが、特にElmはまだインターネット上にリソースが少ないという点でも、ひとりElmマスターがいるというだけでも大きな違いになる。

なので、もしElmを本格的にプロダクトで使いたい、使うことを検討していて、そのメンターを探しているという場合には、気軽にTwitterでDMでも頂ければと思う。実際に開発フローに入って手を動かすことは難しいが、業務委託などの形でElmに関する相談や設計の壁打ち相手をすることはできる。もちろんElmではなくフロントエンド・アプリケーション設計そのものの相談でもOKである。Elmを使った高生産性とメンテナビリティを両立させたアプリケーション開発の手助けができれば、これほど嬉しいことはない。

twitter.com

*1:NoRedInkに所属するElm系の長尺トークをたくさんしている人 https://www.izumisy.work/entry/2019/08/17/152455

gcloudコマンドの対象プロジェクトIDを関東最速で取得する

iTerm2にはステータスバーという機能があり、そこで現在のgcloudのCLIで操作対象になっているプロジェクトIDを出すと非常に捗る。

f:id:IzumiSy:20191106135443p:plain

単純に考えるとgcloudコマンドのconfigオプションを使い、プロジェクトIDの取得ができるだろうなと思うが

gcloud config list project --format='value(core.project)'

いかんせん、これがめちゃくちゃ遅い。Pythonで作られているっぽいが、そのせいなのかは分からない。だが、とにかく遅い。1-2秒は普通にかかる。iTerm2はステータスバーに表示するデータをディレクトリ移動のたびに取得するのでcdするたびに数秒まってると日が暮れてしまう。

同じようなことをしている先輩が会社にいたので、どうやっているか聞いてみたところ、以下のようなコマンドで取得しているらしい。これでかなり速度を改善できた。

gcp_profile=$(cat $HOME/.config/gcloud/active_config)
gcp_project=$(awk '/project/{print $3}' $HOME/.config/gcloud/configurations/config_$gcp_profile)

catとawkの組み合わせのほうがよっぽど早いのは言うまでもない。

Datastoreでは将来の変更を見越してフラグ系もStringで格納するのがいいんじゃないか

たとえば以下みたいなデータ構造がDatastoreにあるとする

type UserSetting struct {
  UseNotification Bool `datastore:"useNotification"`
}

これはユーザーの設定として「通知をするか/しないか」を表現しているものだが、もしも仕様変更でTrue/False以外の値を設定したくなった場合には問答無用でマイグレーションを行わねばならない。マイグレーションを行うということは、アプリケーションを停止したり不整合を防ぐなどの処置をせなばならず、そこそこ負荷が大きい。

このような将来の変更を見越すのならば、以下のようにStringとするのがよい。

type UserSetting struct {
  Notification Notification `datastore:"notification"`
}

type Notification = String

const (
  On  Notification = "on"
  Off Notification = "off"
)

文字列の列挙型のような形で表現すれば真偽値と同等の表現は問題なくできる上、もし真偽値以上のデータを取りたくなった場合にも容易に対応できる。

また、文字列ではなく数値で表現(1=on, 2=off)するのはどうなんだ、という話もある。

これは実際にプロダクトで使った経験から言うと、非常にデバッグがしづらい。もちろん、文字列を使っている場合でもその文字列が正しい表現になっていなければそれまでだが、数値だと今度は「その数値がなにを表しているのか?」を知るためにコードを読んだり、別のドキュメントにマスターデータ的な対照表を用意しておく必要が出る。

「コードを読むのが一番正しい」というのは間違いないが、たとえば新人が入ってきた際にフラグが表すものを知るために1からコードを読ませるというのは相当工数の無駄だろう。もちろん、新人じゃなくたって大変だ。

RDB技術者のためのNoSQLガイド

RDB技術者のためのNoSQLガイド

Architecture Night #2 がかなり良かった

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なのかさっぱりだったが、今回のミートアップのようにリアルな実例を聞くとわかりがすごい。

izumisy-tech.hatenablog.com

*1:厳密にはRocksDBも併用していた

*2:厳密には、Facebookが開発したberingeiというオンメモリ時系列データベースが採用しているdelta-delta圧縮というのを使っているとのこと https://github.com/facebookarchive/beringei