Inside Fintech Meetup ~ Finatext × Kyash × FOLIO ~で発表しました

speakerdeck.com

Inside Fintech Meetup ~ Finatext × Kyash × FOLIO ~ - connpass という勉強会で発表しました。

ここ1年弱くらいずっとやってたので話すネタはいくつかあったんですが、Scala的な部分は趣旨じゃなさそうだしロボアドの仕組みを説明してもいいけどリプレースの話もしたいし・・・と、割とトピック選びの時点で難産でした。 最終的にはイベントストーミングにしたんですが、弊社イベントストーミングの話するの3回目くらいな気がしますね・・・🙄

とはいえ理解が難しい部分、知識差がある部分をどうカバーしていくか?っていうのは重要なテーマだと思うし、イベントストーミングは要件定義ではなくチームビルディングにも使えるんだぜってのは個人的には結構面白いかなと思ってたので発表できてよかったかなーと思っています。

ところで2020/09/25(金)にFOLIOでcats-effect,fs2,doobie使って証券システム作ってみた (仮)っていう発表があるので、 Scala的なところが聞きたい人はこちらもぜひご参加ください(宣伝)

scala-tokyo.connpass.com

pdfを翻訳機に書けやすくするchrome拡張を作った

FOLIO Advent Calendar 2019 - Qiita 13日目の代打です。

chrome拡張を作った

pdfを翻訳機に書けやすくするchrome拡張を作りました。

GitHub - matsu-chara/pdf-translate-replacer

需要あるのかわかりませんがwebstoreにも公開しました*1

chrome.google.com

なにこれ

pdfをgoogle翻訳にコピペすると文末ではなく、pdfの行末で改行が入ってしまうため翻訳ミスが発生します。 このクローム拡張を使うと、文末の . を元に改行を適宜いれた形に整形しなおしてくれます。*2

こういった整形ツールは集中力がなくなった時やとりあえず外観を知りたいときなどに非常に便利です。 最初に日本語でざっと読んでから、次に英語を読むようにするとスルスル頭に入ってくるようになります。*3

一方で自分が読む分野の論文だと e.g.section 1.2.3 などが多く、false-positiveな改行が挿入されてしまう問題がありました。 そこで、自分が読む論文に合わせたオリジナルのreplacerを作りたい!という気持ちになったので作りました。*4

↓みたいにreplaceしてるだけなので使いにくいところがあったらPRするなりforkするなりしてお使いください。 https://github.com/matsu-chara/pdf-translate-replacer/blob/master/script.js#L23

前作った同じようなやつをコピペして中身変えただけなので作業時間は15分です。 ちなみにチキンマカロニグラタンを食べながら作りました。(行儀)

どうやって使うの

以下で整形されます。

  1. インストールすると っていうアイコンが出てくる
  2. 翻訳したいテキストをpdfからコピー
  3. Google 翻訳 に行って翻訳欄にペースト
  4. っていうアイコンをクリック

以上です。

*1:というか変換ルールが完全に自分用なので、forkして自分好みにルールを変えて使ったほうが良さそう

*2:そういえば整形してるんだからreplacerじゃなくてformatterだよなって今思いました(時既に遅し)))

ちなみに、同様の現象に対する先行事例として以下が開発されています。

どちらも大変お世話になっていました。ありがとうございます。((これらの力がなかったら40pくらいある https://15721.courses.cs.cmu.edu/spring2016/papers/whatgoesaround-stonebraker.pdf とか多分挫折してました。ちなみにこれはデータモデリングについての35年分の歴史を辿り、そこから得られる教訓についてまとめた論文でとてもおもしろいです。

*3:ちなみにかっこが含まれているときなどに文の肯定・否定がひっくり返ることがたまにあるので原文も読むようにしたほうが良いです。

*4:調べてないですが、おそらくクローム拡張に既に同じようなやつある気がします

ScaleCheck: A Single-Machine Approach for Discovering Scalability Bugs in Large Distributed Systemsを読んだ

FOLIO Advent Calendar 2019 - Qiita 18日目です。 前日は krrrrさんの RustでもServer::Starterでhot deployをする - decadence でした。

毎年この時期にしかFASTを読めていない まっちゃら (@matsu_chara) | Twitterです(´・_・`)

今回はFAST '19からScaleCheck: A Single-Machine Approach for Discovering Scalability Bugs in Large Distributed Systems | USENIXを読んだときの勉強メモです。 自分が面白いと思ったところを中心にしたり、個人的に調べた内容が入っていたりするので正確かつ完全な情報は上記論文や関連文献等を直接読んでいただければと思います。

ざっくり

大規模ストレージシステムに関する新しい種類のバグである Scalability bugs を検出するScaleCheckという手法が提案されています。 Scalability bugsとはノードが数台〜数十台程度では顕在化せず、数百台以上の大規模クラスタになって初めて顕在化するようなバグのことを指しています。

ScaleCheckはこのScalability bugsを実際に数千台規模のクラスタを組むのではなく、1台のマシン上で上記のような問題を潜在的に抱えているかどうかを確認する方法を提供します。 論文ではScaleCheckの提案のみならず、実際に1台のマシンのみを用いてCassandra,Riak等のシステムに適用し、10個の既知のバグ+4個の新しいバグを検出することに成功したことも述べられています。

背景

大規模サービスを運営する企業で運用されているクラスタは、そのノード数も巨大になりがちで論文では以下のような例が挙げられています。*1

  • Netflix runs tens of 500-node Cassandra clusters [34]
  • Apple deploys a total of 100,000 Cassandra nodes [2]
  • Yahoo! revealed the largest Hadoop/HDFS cluster with 4500 nodes [35]
  • Cloudera’s customers deploy Spark on 1000 nodes [24, 27].

本論文はこのような巨大クラスタを運用する際に顕在化するクリティカルなバグをscalability bugsと呼称し、cloud-scale時代に発生するようになった新世代のバグであると呼んでいます。

実際に巨大なクラスタで発生するバグとしては以下のような実例が挙げられています。

f:id:matsu_chara:20191214180153p:plain:w600

https://www.usenix.org/sites/default/files/conference/protected-files/fast19_slides_stuardo.pdf#page=3 より

これを見るとたしかに100, 1000ノード単位で顕在化するバグが存在するようです。

例えばcassandraの内部処理でノード数依存でO(N3)の処理があり、計算に0.1~4sec程度時間が必要になった事例が挙げられています。 こういったことがあると、gossipプロトコルで最新のノード情報を取得するまでに時間がかかりすぎ、あるNodeが故障<->復旧の各状態を高速に繰り返すflappingと呼ばれる問題を引き起こします。 こういった問題はノード数が少ないと影響がでにくいため、クラスターが大きくなった時に初めて顕在化する問題だとされています。

このような問題を見つけるために実際に巨大なクラスタを組んで検証するのはハードルが高いため、 1台のマシンでその問題を検知するためのScaleCheckの提案につながったというわけです。

Scale Dependent Loops

Scalability bugsを検出するためには、Scalability bugsの原因は何なのか?を考える必要があります。

本論文ではまず Scale Dependent Loops が挙げられています。 これはノード数に依存するようなデータ構造のループのことです。

ScaleCheckのSFindでは、メモリ消費の増加傾向からこのループ構造を検出します。

実際には上記以外にもファイル、パーティション、テーブルなど様々な軸で、スナップショット、マイグレーションなど様々なワークロードについて問題を検出するようです。

large-scale testing (in one machine)

巨大なクラスタを使ってテストを行えば当然Scalability bugsを検出できると思われますが、一方で様々なハードルがあるため1台のマシンでテストを行えるようにしたいところです。 しかし実際にそれを行うためには下記のような様々な困難を解決する必要があります。

f:id:matsu_chara:20191214183113p:plain:w450

https://www.usenix.org/sites/default/files/conference/protected-files/fast19_slides_stuardo.pdf#page=11 より

STestでは上記をSPC+GEDA+PILというテクニックで解決し、1台での大規模テストを行えるようにしています。 詳しく説明すると長くなりすぎるため下記では要素のみの紹介とし、具体的な解説は論文に譲りますので興味がある方はそちらを御覧ください。

ナイーブに1台に複数プロセスを立てるのだと50ノード程度しか立たないため今回の目的には向かないようです。 そこでSingle Process Cluster(SPC)として1プロセスに複数ノードを立てる(つまりスレッドでノードを管理する)手法が導入されています。

しかし単純なSPCを行うと、イベントキューやワーカープールがノードごとに作られるためリソースを多大に消費します。(120ノード程度とのこと)

これらを節約するためにGlobal Event Driven Architecture(GEDA)を導入します。 GEDAはグローバルなイベントハンドラを用意し、ノードごとの通信をグローバルイベントキューへのキューイングとして表現します。 また各ノードはグローバルなキューからイベントを取得し処理を行うだけです。

f:id:matsu_chara:20191214191203p:plain:w450

https://www.usenix.org/sites/default/files/conference/protected-files/fast19_slides_stuardo.pdf#page=24 より

上記だけでも大規模テストができるとのことですが、 これだけだと特にCPU-intensiveなタスクの際に結果が正確でないケースがあるため、CPU intensiveな計算をsleepに置き換えるProcessing Illusion(PIL)というテクニックを導入しています。

PILは画像を見ると何をしたいかがわかりやすいと思います。

f:id:matsu_chara:20191214192513p:plain:w450

https://www.usenix.org/sites/default/files/conference/protected-files/fast19_slides_stuardo.pdf#page=28 より

検証

実際にいくつかのミドルウェアで検証を行い、既知のバグや新しいバグを検知しているようです。

新種のバグとしては以下の物が挙げられています。

Cassandraのdecomission時の不安定性 *2

f:id:matsu_chara:20191214190109p:plain:w450

HDFSのsnapshot diff size, metasave

f:id:matsu_chara:20191214190237p:plain:w450

感想

問題設定として様々なミドルウェアに潜む巨大なクラスタで発生するバグを包括的に捉えるのは興味深く感じました。 実はScalability Bugsという問題設定はHotOS'17 Scalability Bugs: When 100-Node Testing is Not Enough において提案されています。 同一の著者グループによる研究のようなので、より深く問題を理解するためにはこちらもみておくと良いでしょう。

ScaleCheckは任意のミドルウェアにすぐ適用できるフレームワークではなく、ミドルウェア側の実装修正が必要になっています。 しかし各ミドルウェアに対して179 ~ 918 LOCレベルなので、そこまで大きな変更を加えずに対応することが可能そうです。

リアルワールドの問題を実際に発生させられるように大規模クラスタを模倣できる開発環境を作るという取り組みを論文中ではlarge-scale testingを民主化すると表現しているのですが、巨大企業に所属していなくても大規模ミドルウェアの開発に貢献しやすくなるという点で意義深いと思いました。*3

FASTあたりの論文を読むと堅牢な分散システムが崩壊していくのはよく見られる(?)*4のですが、実運用では細かいところを追いきれずある程度信用してしまっている側面もあるかと思います。 どのようなミドルウェアファイルシステムでも完璧に障害が起きないようにするのは非常に難しい(はずな)ので、どのような問題が起きうるのか?を研究を通して学んでいくだけでも、(実際にそのテクニックや技術を使うことがなくても)実運用に役立つ視点や、考え方を得られるのではないかなと思っています。って結びの言葉を書いてたら去年も同じようなことを書いていました。成長...

Replicated State Machinesでのストレージ故障からのリカバリー - だいたいよくわからないブログ

ところで、社内からそもそもgossip部分がスケールしないのはアーキテクチャ的に見えてるしループ改善してもすぐ帯域やCPUで限界が来そう*5という指摘がありました。そういった部分をどう乗り越えるかは論文の対象外ではありますが、現実の厳しさを感じつつこの記事を終わりたいと思います。

*1:1クラスタじゃないと思いますが10万のcassandraって何に使ってるのか気になりますね

*2:筆者はCassandraに詳しくないため前提や最新バージョンでの修正状況などを把握できていません。ご了承ください

*3:colocation factor=50のnaive packingでもEC2 10台程度で500ノード建てられるので、そちらでもみたいなところはありますが、ソロコントリビューターでも気軽に貢献できることを目指すとなるともう少しハードルを下げたいと思うので。

*4:当社比というか、自分がいろいろな前提を理解していないだけ...

*5:>This model works well for a system that contains couple of hundreds of nodes https://www.allthingsdistributed.com/2007/10/amazons_dynamo.html より

作ってそこそこ便利だったボットとかまとめ

FOLIO Advent Calendar 2019 - Qiita 10日目代打です。

9日目はlotzさんの 挿入ソートと選択ソートは双対 - Qiitaでした。 recursion schemesの応用って融合変換くらいしか知らなかったんですが身近なアルゴリズムの性質を表現できるのは面白いですね。 自分で学ぶことで見通しよく効率化のアイディアを出せたりad-hocに見えていたアルゴリズムに横のつながりが見えてきて理解が深まりそうです。

最近ブログ書かなさすぎて書き方を忘れていた まっちゃら (@matsu_chara) | Twitterです(´・_・`)

今回は今まで作ってきたボットや社内用サービスをまとめようと思います。 やや内輪ネタっぽいですが、こういうのあると便利かもしれないというアイデアのきっかけになればと思います。 似たようなのあるけどうちはもっと便利だぜ!っていうのあったらぜひ教えて下さい。

社内ブックマーク gol

新しく入社したメンバーに、consulのurlはこれで、prometheusはこれで、ああサービス画面はこっちで。 と教えることはよくあると思いますが、それぞれのリンクを覚えるのは結構大変だったりします。

ドキュメント管理ツールにブックマーク集みたいなページを追加しても慣れてる人は使わないからメンテされない。なんてこともよく起こります。

golはそれらの問題を解決するブックマーク共有&検索サービスです。
まあ実際はただの管理画面付きkvsなんですが、結構便利だったりします。

例えば画像のように、consulと検索するだけで各環境のconsulがすぐに出てきたり

f:id:matsu_chara:20191214160516p:plain:w450

chrome拡張(これは同僚が作ってくれました!)を使うとgolのページに行かなくてもcommand + gとかでさっと検索できます。

検索キーワードをかなり雑に指定してもヒットするようになっていて、 space区切りで適当に「cons stg」と入れれば「consul_stg」だろうが「stg-consul」だろうがヒットしてくれるのが割と気に入っています。 こういう規約とか覚えるの面倒ですしね。

f:id:matsu_chara:20191214160846p:plain:w450

ちなみにgoを書き始めて初めて作ったものなので実装はあれな感じになっています。 許して

slack_user_avatar_emojis

GitHub - matsu-chara/slack_user_avatar_emojis: register slack user avatars to emoji

slackの全ユーザーのiconを取得して、slackのemojiとして登録するものです。 本文に含めてもいいですし、emoji reactionにしても良しで社内の文化作り的にも良いです。 emojiだと名字よりもちょっとほんわかしますしね。

アイコン変更イベントを取ってきて自動で更新し続けてくれるデーモンにしようと思って100年くらいたってるので誰かお願いします(他力本願)

というかこのemoji、公式で実装されて欲しいですね。

ちなみにトークン設定とかが結構必要なので動かすのは結構ダルめです(´・_・`)

reacjira

emoji reactionをつけると特定のチャンネルに通知してくれるreacji-channelerにインスパイアされた、 emoji reactionをつけると特定のjira projectにチケットを切ってくれるボットです。

reaction + jira で reacjiraってわけですね。

アイコンはいらすとやで見つけたかわいいクジラです。(ダジャレ・・・)

↓の感じで、 :○○_story: みたいなemojiをつけてやるとチケットが作成されスレッドとして投稿されます。

f:id:matsu_chara:20191214162615p:plain:w450

この際、チケットの中身として↓の画像のようにdescription欄にslackのスレッドのリンクがデフォルトで記載されます。

f:id:matsu_chara:20191214162623p:plain:w450

reacjiraを使うと依頼を受けた際にすぐチケットを作成できて以下のようなメリットが生まれます。

  • 頼んだ人: どのチケットを見れば進捗が分かるのか分かりやすい
  • 頼まれた人: 詳細を書くのを忘れてしまっても、slackリンクがあるのでどういう文脈で作られたチケットなのか最悪分かる*1

一説によるとzappierとかでできるらしいという話があったりなかったりするんですが、 自作botだとjiraのあらゆるフィールドをいじったり、結構強引なルールを設定したりできるので便利です。

ちなみにjiraの公式integrationとかが進化してくると要らなくなる存在になりそうです(´・_・`) *2

jobdiff

これはかなり社内限定で便利なやつで、jenkins-job-dsl*3のjenkins反映済みcommit ~ 最新masterまでのcompareリンクを生成してくれるというただそれだけのものです。*4

f:id:matsu_chara:20191214163855p:plain:w450

正直bot化するものでもないんですが、jenkins見る => compareリンク作るみたいなのは手間だったので一発で生成してくれるようにしました。

jenkins叩くコードがすでに手元にあったので5秒くらいで完成したし、botデプロイ環境+token登録環境が割と整備されてるので思いついてサクッと作ってすぐデプロイみたいなことがしやすいんでこういう、微妙〜〜〜に不便ってのも解決できていいですね。(環境整備してくれているチームに感謝)

ところでjenkins-job-dslリポジトリが大きくなりすぎて、job-seedに時間がかかりすぎたりいろいろな問題があるので 脱jenkinsも含めて最高のジョブ基盤を作ろうとしています。

それができたらjobdiff君は消え去ることになります。(宿命)

consul bot

これも社内限定で便利なやつで、サービスディスカバリとして利用しているconsulから情報をとってきて、各環境の各サービスのバージョンを一覧として取ってきたり、ip+portを取ってきたりするやつです。

version stg,prod ac のように書くと「stg,prod環境」にある 「acから始まるサービス」のバージョン情報を取得します。*5

サービス名は省略してもいいしフルネームでも大丈夫です。

f:id:matsu_chara:20191217124557p:plain:w450

デプロイしたあとにちゃんと切り替わってるよね?といった確認に使ったり、トラブルシュートする際に参照したりしています。

consulは今の所困っていないんですがServicMeshとか入ってきた時にうちのconsulが生き残るかは不明です。頑張って(´・_・`)

まとめ

作ったけどボツになったやつとかも結構ある(公式機能で対応されてボツとか、使いにくかったりとか)んですが、 社内でも使ってもらえてるのを見るとちょっと嬉しいです。(新しく入ってきた方が早速使ってたりすると特に)

これからも地味だけどあるのが当たり前みたいな便利さを目指して頑張っていきます。

*1:もちろん書いたほうがいいんですが

*2:っていうか元から要らない感はあるんですがreacjiraっていう名前思いついたら作るしかなくない???

*3:groovyでjenkins jobを定義できるやつ。jenkins Pipelineとは異なるもの。

*4:なんでそんなものが必要なのか?みたいな背景書いたけど、社内でしか伝わらなさそうなので消しました。

*5:バージョンはconsulにregisterにするときにgit tagをconsul Noteに入れることで取得できるようにしています。

PFDS(純粋関数型データ構造)を読んだ

手を動かしたい気分だったのでだいぶ後回しになっていたPFDS (Purely Functional Data Structure, 純粋関数型データ構造)を読みながらScalaで実装を後追いしてみた。*1

少し時間がかかったがRedBlackTreeやTrieといった有名な物から、HoodMelvilleQueueやそれを利用したCatenableListなどちょっとおしゃれ(?)なデータ構造についての実装・計算量についての考え方を学ぶことができた。

本の前半はストーリーがあって、「永続的なデータ構造だと計算効率が悪い場合が多い!・・・が!償却計算量の考え方を使いながら実装を工夫していくと短命なデータ構造と同じくらいの性能が出る。(全てではないが償却だけでなく最悪計算量についても同じくらいにできるケースも多い)」ことを確認する旅になる。 軽くまとめてみたので興味がある人はちら見しつつ、実際に本を購入して読んでみてほしい。 https://gist.github.com/matsu-chara/75dd80e36172569343738153d0123bf2

後半は様々なデータ構造を設計するための考え方がまとまっている。 こちらについても雑多になっているわけではなく、前半の考え方(実装方法・計算量の証明方法)を踏襲しつつ、一個ずつ積み重ねになっているので読み応えがある。

2進数のゼロ無し表現というものが途中に出てくる。 これは以下のように普通の2進数では {0,1}で書くところを {1,2}を使って書く記法のことだ。

1,2,3,4,5 は 1, 2, 11, 21, 12, 22, 111 となる。

- 各桁が2^iを表すのは普通の2進数と同じ。
- 0を使わないのが前提になるので、ある数を表す表現は一位に定まる

一見特に意味のない記法に思えるが、これが記数法表現に基づくデータ構造の計算量の削減に役立つというのはなかなか面白かった。 記数法表現が何かについては本を買って(ry

2-3 finger tree

2-3 finger treeといえばHaskellのData.Sequenceにも使われている(償却)計算量の優れたDequeだ。(追加・削除ともに償却定数時間で実行可能)

これはPFDSには載っていないが、ベースとなる 記数法表現暗黙再起減速 の考え方・実装の勘所はPFDSで学ぶ事ができる。*2

読み終わったあとにwikipediaを開いてみたら、以前なんとなく理解していた物よりはるかに解像度高く理解できたので勢い余って実装してみた。*3

https://github.com/matsu-chara/finger_scala

とはいえ、finger treeの実装は世界に一億個くらいありそうなので特に自慢にもならないし、パフォーマンスやメソッドの豊富さよりはわかりやすさを重視している。(が、やはりこういうのは自分で実装してみると理解度が違うと思う。)

ちなみに実用的なFingerTreeに関してはscalazの物などがおすすめ

wikipediaにあるシナリオ 通りのテストを書いてみたがいい感じな見た目になったので記念スクショを貼って終わりとする

f:id:matsu_chara:20190715172055p:plain
テスト

next

本を読むなかでscalaでの実装をいくつかあたっていたところ以下のように、いくつかの実装には論文へのリンクがついていた。

PFDSでカバーされている物もややありそうだけど面白そうなのでいつか読みたい。(けどパタヘネ読み始めた)

*1:ちなみに実装するときはcats.Evalを使うと便利 https://typelevel.org/cats/datatypes/eval.html

*2:このデータ構造の実装自体は多少腕力があればwikipediaを見れば実装できそうだが、一方でなんでDigitといった名前が出てくるのか、このようなデータ構造での計算量の考え方はある程度背景知識がないと理解が難しい気がする。(個人の感想です)

*3:ちなみにwikipediaは英語版より日本語版のほうが図が多くて実装しやすかった