1時半に寝て6時に起きた。昨日の夜はウォーキングして (朝活あるから) すぐに寝たんで早く起きた分、朝からストレッチをしてた。今週はバタバタしていてあまりストレッチできてない。

朝活: ミクロ経済学入門の入門

[金朝ツメトギ] 2021-11-05 AM 6 金曜朝6時開催のもくもく会 で第7章の独占と寡占を読んだ。用語を次にまとめる。

• プライステイカー: 生産量を増やしたり減らしたりしても価格に影響を与えられない会社
• 完全市場: すべての会社がプライステイカーである市場
• 不完全市場: 完全市場ではない市場、プライステイカーではない会社がいる
• 独占市場: 1つの独占企業だけが存在する市場
• クルーノー寡占市場: 同じ財を生産する少数の会社の総生産量から市場の価格が決まる市場
  • 寡占: 少数の企業がいる市場
    • 複占: 企業が2つだけの市場

前に出てきた市場均衡の話から、供給量を下げると価格が上昇する。生産者余剰がが大きくなり、生産者は得をする。実際にあった事例として、2016年に石油輸出機構 (OPEC) が石油の減産に合意して価格が上昇した。2012年に豊作だった歳に値崩れが起きるのをおそれて、全国農業組合連合会は価格を上げるために農家に野菜の廃棄処分を要請した。

独占市場にいる会社は高い価格で高い利潤を得ることはできるが、やがて価格競争を仕掛けてくる新規参入者を招き、長期的な利益を低めてしまう懸念がある。一方で高品質な財を低い利潤で販売していると、新規参入者が現れずに長期的な利益を得られる可能性がある。一概にどちらが正しいとは言えない。こうした状況を端的に描く 展開型ゲーム を考えると、財を高値にするか安値にするかの思考実験ができるう。 ゲームツリー という図でこのゲームを表している。

A は安値を選び、B が参入しないという選択の組み合わせは、「自分がこう選択したら相手はこう選択してくる」とプレイヤーが予想して、そのうえで自分にとって最も利潤が高まる選択をする状況を表している。これを サブゲーム完全均衡 の結果と呼ぶ。また、このような推論のやり方を 逆向き帰納法 (バックワード・インダクション) と呼ぶ。サブゲーム完全均衡の結果は逆向き帰納法により求められる。

RabbitMQ の dead letter exchange の調査

昨日の続き。RabbitMQ には exchange という概念がある。私が過去に使ったメッセージキュー (Kafka, AWS SQS) にはない概念でトピックをグルーピングしたり、メッセージのルーティングを制御する仕組みになる。普通のメッセージキューではデッドレターキューと呼ばれるものが RabbitMQ だと Dead Letter Exchanges になる。ドキュメントの概要はこんな感じ。

次のイベントが発生したときに “デッドレター” とみなす。

• consumer が basic.reject または requeue=false の basic.nack を ack で返したとき
• メッセージの TTL の期限切れになったとき
• queue の最大長さを超えてメッセージが drop されたとき

注意事項として queue の有効期限が切れても queue 内のメッセージはデッドレターとならない。

設定方法

デッドレター exchange (DLXs) は普通の exchange であり、普通に宣言して通常の種別をセットする。任意の queue に対して2通りの設定方法がある。

• クライアント: queue の引数を使って定義する
• サーバー: ポリシーを使って定義する

詳細は割愛。

ルーティング

デッドレターメッセージのルーティングは、次のどちらかで行われる。

• デッドレターの queue に routingKey が設定されていればそれを使う
• デッドレターの queue に routingKey が設定されていなければ、オリジナルのメッセージが publish されたときの routingKey を使う

例えば、foo という routingKey をもつ exchange にメッセージを publish して、そのメッセージがデッドレターになった場合、foo という routingKey をもつデッドレターの exchange に publish される。もしそのメッセージが x-dead-letter-routing-key を bar にセットした queue に届いた場合は、そのメッセージは bar という routingKey をもつデッドレター exchange に publish される。

queue に特定の routingKey が設定されていなかった場合、その queue のメッセージは、すべてオリジナルの routingKey でデッドレター化されることに注意してください。これには CC および BCC ヘッダによって追加された routingKey も含む (詳細は割愛) 。

デッドレターメッセージが循環する可能性がある。例えば、queue がデッドレター用のルーティングキーを指定せずに、デフォルトの exchange にメッセージをデッドレターした場合などに起こる。このとき同じ queue に2回届いたメッセージは no rejections in the entire cycle だった場合にドロップされる。

安全性

デッドレターメッセージは内部的に publisher confirm を行わずに re-publish される。クラスタ環境の rabbitmq でデッドレターキューを使ったとしても安全性は保証されない。メッセージはデッドレターキューの対象の queue に publish された後でオリジナルの queue からは削除される。このときに対象の queue が受け取れなければメッセージがなくなってしまう可能性がある。

デッドレターメッセージの副作用

デッドレターメッセージはヘッダーを変更する。

• exchange の名前がデッドレター exchange の名前に置き換わる
• routingKey がデッドレターキューの routingKey に置き換わる可能性がある
• ↑ が起きると、CC ヘッダーが削除される
• Sender-selected Distribution ごとに BCC ヘッダーは削除される

デッドレターの処理では x-death という名前の配列を、それぞれのデッドレタリングされたメッセージのヘッダに追加する。この配列には {queue, reason} のペアで識別される各デッドレタリングイベントのエントリが含まれる。詳細は割愛。

dapr の調査

dapr について調べた。dapr は分散システム (アプリケーション) の複雑さを解決することを目的としている。様々なミドルウェア (分散システム) とのやり取りを http/grpc の api 呼び出し経由にして、その詳細を隠蔽する。ミドルウェアの上位に抽象化レイヤーを設けて統合的なインターフェースを提供したり、それぞれのミドルウェアにおける設定や運用の面倒なことなどを簡略化してくれる。サイドカーパターンを採用しているので言語に依らず、アプリケーションに dapr のコードを書く必要もない。dapr cli をインストールして dapr init すると docker で dapr プロセスが動いて、それだけで dapr にリクエストできるようになる。使い始めの学習コストは低いし、デプロイも簡単だし、意図している目的もわかりやすい。マイクロソフト社がスポンサーしていてプロジェクトの運営も安定してそうだし、おもしろいツールだと思う。

k8s の調査

せっかくの機会なのでちゃんと勉強することにした。今日は minikube の Get Started! やっただけ。

1時に寝て6時に起きた。朝活があると起きれるな。

朝活: ミクロ経済学入門の入門

【三宮.dev オンライン】リモート朝活もくもく会 で第5章の市場均衡と第6章の外部性を読んだ。

まず第5章から。用語を次にまとめる。

• 完全市場: 誰もがプライステイカー (自分の生産量が価格に影響を与えられない) である市場
• 社会的余剰: 消費者余剰 (価格より多めに払ってよいと考える金額の和) と生産者余剰 (利潤の和) を足し合わせたもの
• 従量税: 販売する量に応じて一定の金額を納める税
  • 例) たばこ税、酒税、揮発油税 (ガソリン)

これまでの章で学んだ内容から価格は需要曲線Dと供給曲線Sが交差する点p*になる。この価格を 市場均衡価格 と呼ぶ。市場全体のよさを測るモノサシとして 社会的余剰 を使う。市場均衡価格に対して価格を上げたり下げたりしたときにできる社会的余剰の差額を 死荷重 と呼ぶ。次の図の C の面積に相当する。

図から市場均衡価格は社会的余剰を最大化させた価格だとわかる。

生産者や消費者に従量税を課すと市場にどのようなことが起きるかを考察する。納税方法として、生産者が納税する方式 (価格に税を含める) と消費者が納税する方式 (価格と税は別) があるが、どちらも社会的余剰が C の分だけ減少するグラフとなり、社会的損失が発生していると言える。余剰の視点からはどちらの方式も全く同じだが、政府が徴税するしやすさの視点だと、相対的に数の少ない生産者から納税する方が管理しやすい。

狙い撃ち課税のダメな点として酒税を例にあげている。ビールの酒税を逃れるために、メーカーは1990年代に発泡酒、2003年に第3のビールを開発した。2016年時点での350ml (1缶) あたりの酒税は、ビール77円、発泡酒47円、第3のビール28円となった。同年、政府はすべて55円へ統一していく方針を発表した。ビールへの従量税が与えた社会的損失として死荷重だけでなく、発泡酒や第3のビールのような劣化ビールの技術開発のコストがあげられる。特定の品目を狙い撃つ従量税は社会的損失を生みやすいと述べられてる。

次に第6章から。用語を次にまとめる。

• 負の外部性: ある生産活動が他者へマイナスの影響を与える
  • 例) 公害や花粉症など
• 正の外部生: ある生産活動が市場取引を経ずにプラスの影響を与える
  • 例) 電鉄会社が駅や路線を開通させるとその地域に経済効果をもたらすなど
• 限界被害: 企業の生産活動が住民に与える被害の生産量に対する総和の金額
• ピグー税: 住民に補償を与える環境税
• ネットワーク外部性: SNS など、サービスの価値がユーザー数に大きく既存する性質
• 調整ゲーム: 何を選ぶかよりも、他人と同じものを選ぶことが重要な状況
• ナッシュ均衡: 自分の行動を変えると損になるので誰も行動を変えない状況

企業の生産活動が住民に被害をもたらせていた場合、その被害をピグー税を通じて企業が支払う。これを 外部性の内部化 と呼ぶ。負の外部性は社会問題となるが、対して正の外部性は社会問題とならない。

調整ゲームにおいて、一方がもう一方よりも好ましい状態を パレート優位、またその逆の状態を パレート劣位 と呼ぶ。ネットワーク外部性においては優勝劣敗が必ずしも正しいとは限らない。先行者としてユーザー数を獲得し、ナッシュ均衡の座をつかむことが勝ちにつながる。

ASUS ROG Zephyrus G15 GA503QR

今日届いたのでセットアップだけ終えた。Windows アップデートすると次々に更新が出てくる仕組みは昔と変わってなかった。4回再起動した。

前々から Windows マシンがほしいと思っていて、次のお仕事が決まったので思い切って購入することにした。買おうかどうしようかを迷っている心の中の動きのコストというか、検討事項としてずっと残り続けるのもあまり生産的ではないなと最近は思うようになっていた。私が Widnows マシンが必要になった背景はこれら。

• 行政の電子申請・手続きはまだまだ Windows アプリが主流

最近は Windows アプリ版とは別に、Web 版というブラウザベースのアプリケーションが提供されつつあるが、まだまだ黎明期で一部の機能しか対応してなかったり、不具合で macos だと動きませんと障害情報が出てたり、ひどい場合だとブラウザベースなのに Linux はサポートしてませんとか言われたりする。毎年この申請は Web 版で対応したやろか？と調べて、やっぱりまだできんかったと紙ベースの申請に切り替えるときの、調べるコスト (とがっかりするコスト) がしんどくなった。

• VR 系アプリケーションのプラットフォームは Windows

Facebook 社が Meta 社になって、ややメタバースが盛り上がりをみせつつある。Oculus Quest 2 を買ったものの、VR 系アプリケーションは Windows がメインターゲットらしく macos や linux は、現時点ではサポートしていないことが多い。Oclus Link も Windows しかサポートしていない。せっかくヘッドマウントディスプレイを購入したので、そのデバイスをもっと活用するためにも Windows マシンがあった方がよいと考えた。

• Microsoft Teams を使いたい

私の周りでも Microsoft Teams を使うことが増えてきた。ゲストアカウントでも会議できるのでエージェントと打ち合わせするときは Teams を使ったりしていた。社内システムを MS 系のプロダクトで固めている企業は普通に Teams を使っているし、顧問さんから聞く話しでも Teams (と MS 製品とのインテグレーション) の評判はよい。チャットツールを対象としたプロダクトを作っていくにあたり、今後は Slack だけではなく Teams 対応も必須になっていく気がする。実際に私も Slack/Teams 両対応のプロダクトもみかけるようになりつつある。Microsoft Teams を Linux で使えるかどうかは調べてないのでわからないけど、Windows マシンが1台あった方が手っ取り早いと考えた。

• オフィスと自宅にパソコンを据え置きたい

オフィスでは普段デスクトップマシンを使いつつ、macbook をサブマシンとして使っている。自宅で作業するときは macbook を持ち帰ったりしていた。人間はどんどん怠惰になるのでこの持ち運びが面倒になってきたり、持ち帰ってないときにパソコンで作業したくなったりしたときは、オフィスに出かけるといったことをするようになってストレスにもなってた。徒歩でも15分あれば行ける場所にオフィスがあるので、タブレットやスマホでの作業効率を考えたらオフィスに行ってしまう。ラップトップを自宅とオフィスに置いておけるといいなぁとは薄々思っていた。これを機にオフィスには asus マシンを、自宅には macbook を据え置くようにしたい。

データ指向アプリケーションデザイン

9.4 分散トランザクションと合意の前半の2つの節を読んだ。

• 9.4.1 アトミックなコミットと2相コミット（2PC）
• 9.4.2 分散トランザクションの実際

分散トランザクションという扱っているテーマが難しいけど、書いてある内容は1つずつ追っていけば理解できるのでそこまで難しくはない。一言で分散トランザクションと言っても次の2つに大別される。

• データベース内部の分散トランザクション
• ヘテロジニアスな分散トランザクション

前者は特定のデータベースシステムだけで動くので相対的に最適化ができたり、うまく運用できるケースもある。後者は複数のシステムを介した汎用の仕組みになるので2相コミットのような プロトコル を使って アトミックなコミット を保証しなければならない。2PC はコーディネータの障害が運用上の大きな問題となることがわかっている。ヘテロジニアスな技術間での2相コミットの標準を X/Open XA（eXtended Architecture の省略） と呼ぶ。多くの RDB やメッセージブローカーでもサポートされているらしい。Java EE アプリケーションの世界だと Java Transaction API （ JTA ）で実装されているらしい。全く聞いたことがなくて、私はいままでこの技術に関わることがなかった。

2時に寝て6時に起きた。前日の夜にウォーキングしたせいか、よく眠れた。朝活を終えてから朝ご飯を作って食べてそのままオフィスに出社した。6時起きを日課にした方が生活のリズムがよい。夕方に眠くなって1時間ほど昼寝した。

朝活: ミクロ経済学入門の入門

【三宮.dev オンライン】リモート朝活もくもく会 で第4章の供給曲線を読んだ。需要曲線の逆からの視点なので考え方は同じで図の形が異なる。用語がいくつか出てきたのでまとめる。

• 収穫逓減 (しゅうかくていげん): 製品をより多く生産するのにかかる経費が増大していくこと
  • 生産活動において2倍の生産量を生み出すには2倍以上の経費がかかる
• 費用関数: 生産量と費用との関係をあらわす
• 限界費用: 追加的に1単位生産する費用
  • 3個を生産する費用は、1個目の限界費用 + 2個目の限界費用 + 3個目の限界費用
    • 個数が増えるごとに費用は高くなっていく
  • 費用を図示するときは限界費用に分解した方が視覚的にわかりやすい
• 限界費用逓増: 生産するごとに限界費用が高まっていくこと

「逓」という漢字は「つぎつぎ」や「だんだん」という意味をもつ。

• プライステイカー: 自分の生産量が価格に影響を与えられない
  • 減産により希少価値を高め価格を吊り上げる市場操作ができない
• 独占企業: プライステイカーの反対。
• 利潤: 売上 - 経費
• 最適解: 利潤を最大化する生産量
  • あと1個追加して生産すると利益がマイナスになるところ
• 生産者余剰: すべての企業の利潤の和
• 供給曲線: すべての企業の限界費用をヨコに足し合わせた曲線

データ指向アプリケーションデザイン

昨日の続き。8.4 を読んで8章分散システムの問題を読み終えた。全体としても学びになったけれど、とくに 8.3 信頼性の低いクロックの節が全く開発・運用で意識したことがなかったので私にとっては学びになった。

分散システムにおいて発生する厄介な問題がある。

• ネットワーク経由でパケットを送信しようとした場合、そのパケットはロストしたり、どれほど遅延するか分からない。同様に、レスポンスもロストしたり遅延したりするので、レスポンスを受け取れなかった場合には元々のメッセージが到達したかどうかも分からない

• ノードのクロックは他のノードと大きくずれているかもしれない（できる限りの努力をして NTP をセットアップしたとしても）。クロックは急に進んだり戻ったりするかもしれず、たいていはクロックの誤差をうまく計る方法がないので、クロックに依存するのは危険

• プロセスは処理中にいつどれほどの長さ一時停止するかもしれず（おそらくはstop-the-worldガベージコレクタのため）、他のノードから落ちていると見なされた後に自身に一時停止があったことを理解しないままに復活するかもしれない。

こういった 部分障害 が生じうるのが分散システムの特徴と言える。ソフトウェアが他のノードが関わる何かをしようとした場合、それは時おり失敗したり、ランダムに速度が落ちたり、まったくレスポンスが返されない（そして最終的にはタイムアウトする）といった可能性がある。分散システムでは、部分障害への耐性をソフトウェアに組み込み、システムの構成要素が一部破損していてもシステム全体としては機能し続けられるようにする。

フォールトに耐えるための最初のステップはフォールトを 検出 することだが、それさえも難しい。多くのシステムは、ノードに障害が生じていることを検出する正確な仕組みを持たないので、ほとんどの分散アルゴリズムはリモートノードが生きているかどうかを判断するのにタイムアウトに頼る。しかし、タイムアウトはネットワークの障害とノードの障害を区別できず、ネットワークの遅延変動のために間違ってノードがクラッシュしていると誤検知することもある。弱っているものの落ちてはいないノードは、きれいに落ちているノードよりもさらに扱いが難しくなる可能性がある。

フォールトが検出されたとして、システムがそれに耐えられるようにすることも簡単ではない。マシン間にはグローバルな変数も、共有メモリも、共通の情報やその他何らかの共有された状態もない。ノードは現在の時刻についてさえ合意できず、ましてやもっと重大なことに合意することなどできない。あるノードから他のノードへ情報を流せる唯一の方法は、その情報を信頼できないネットワークを通じて送ることだけである。重要な判断は単一のノードだけで安全に下すことができないので、他のノードの助けを得てクオラムが合意に至るようにするためのプロトコルが必要となる。

同じ操作をすれば決まって同じ結果を返してくれるような、単一コンピュータにおける理想化された数学的な完全さの中でソフトウェアを書くのに慣れていると、分散システムの雑然とした物理的な現実への移行はちょっとしたショックを伴う。一方、分散システムのエンジニアは、しばしば単一のコンピュータ上で解決できる問題を簡単なものだと見なすが、実際のところ今日では単一のコンピュータがこなせる仕事量はかなりのものになっている。単一のマシンでシンプルにことを済ませられるなら、概してそうする価値はある。

分散システムを利用する理由はスケーラビリティだけではない。耐障害性や低レイテンシ（地理的にユーザーの近くにデータを置けることによる）も同様に重要な目標であり、こういったことは単一ノードでは実現できない。本章ではネットワーク、クロック、プロセスの信頼性の低さが避けがたい自然の法則なのかも調べた。安全ではなく、クリティカルではないシステムの多くでは、高価な高信頼性よりも安価な低信頼性が選択される。また、信頼性の高いコンポーネントを前提としているスーパーコンピュータも取り上げました。スーパーコンピュータはその前提が故に、コンポーネントに障害が生じてしまった場合には完全に停止させて再起動することになる。これに対し、分散システムはサービスレベルでは中断することなくいつまでも動作し続けられる。これは、少なくとも理論上はすべてのフォールトやメンテナンスはノードレベルで処理できるためである。

お昼ご飯

気分でスーパー寄って買いものして家に帰り、お昼ご飯を作って食べた。前に適当に作った かぼちゃの煮物 がおいしかったので再挑戦してみた。今度は圧力鍋を使っていろいろ具材を入れてみた。過去に作っておいしかった料理のレシピを evernote に書いたりしていたけど、もういまは書いてないので気が向いたら日記に書くようにする。

材料

• A
  • 水 900cc
  • めんつゆ 100c
  • 醤油 適量
• B
  • かぼちゃ 1/4切れ
  • なす 3個
  • にんじん 2本
  • 玉ねぎ 1個
  • しめじ 1パック
• C
  • 卵 2個
  • 豆苗
  • せみ餃子

作り方

1. 圧力鍋に A を入れて火にかける
2. B の野菜を切りながら圧力鍋に入れていく
3. 圧力鍋に B をすべて入れたら圧をかける (高圧30秒)
4. 圧が下がったら蓋をあけて C を入れる
5. C に火が通るまで2分ほど煮込む

所感

圧力が強過ぎたのか、かぼちゃが煮汁に溶け出してしまって原形がなくなってしまった。スープとして飲んでもおいしいけれども、水を入れ過ぎたのかもしれない。肉の代わりに餃子を使ってみた。水餃子っぽくなるので焼き餃子で油使うよりヘルシーな気持ちになっておいしい。

bizpy 勉強会

Python で Slack のインテグレーションをやってみる勉強会 #1 を開催した。半年以上開催してなかったので億劫になってしまっていたけど、再開できてよかった。10名ほどが参加してくれた。用意したコンテンツを話し終えたら8時半ぐらいで時間もちょうどよかった。初参加者も数人いた。slack インテグレーションの調査も兼ねてあと2-3回は集中的にやっていきたい。

4時に寝て6時に起きた。朝活があると何時に寝ても6時に起きれる。終わってからやっぱり眠くなって1時間ほど寝てた。お昼の外出から戻ってきて雑務やってから、なんか集中できなくて15時から帰ってお昼ご飯食べて2-3時間寝てた。寝る時間帯がずれると生活のリズムが狂ってしまい、全体でみると生産性が落ちるように思えてきた。水と金だけ6時に起きるのをやめて毎日6時に起きるべきだと強く思うようになった。

朝活

Webデザイントレンドのよりみち の金朝ツメトギに参加した。今回から「つめとぎ」から「ツメトギ」のカタカナに名前変更してパワーアップ？したみたい。本を読んでもよかったんだけど、チャット欄でコメントしながら live をみてみようと思って普通に聴いていた。#金朝ツメトギ というハッシュタグは私がコメントして生まれた。コミュニティ的に盛り上げるならタイムラインを共有した方がよいとは思う。youtube live のチャットにコメントした方がいいか、twitter で気軽にコメントした方がいいか、まだよくわかってない。youtube のチャット欄のコメントの一覧性とか、普段使いのツールになっていないせいか、なんとなく抵抗感がある。いま参加者が少ないせいか、コメントするとスピーカーがコメントに反応して返答したりするので、あまりカジュアルに書き過ぎるとスピーカーの作業の邪魔にならないかな？とか思ったりもした。youtube live という勉強会の人間関係の距離感が難しい。

あと Facebook Connect 2021 というイベントがあることを教えてもらった。友だちに共有したら会社を休んで参加するとか言っているので私も参加してみることにした。どうしようか迷ってたけど、身近な人たちが参加するとつられるのかもしれない。

法人県民税と法人市民税の中間申告と納付

前日(というか今日)に4時まで起きてたのは申告書の内容確認や記入をしてたから。せっかく申告書を作成したのですぐ納付したくなった。それで新長田の合同庁舎まで申告に行ってきた。eltax は相変わらず windows 向けの DL 版でないと申告できそうにない。WEB 版もあって一部対応しているようだけど、よくよく調べていくと DL 版でしかできないようにみえる。毎年 WEB 版でできるようになっているかどうかを調べている。この互換性を調べるような作業を都度やるのが面倒になってきた。vr 用途 (oculus link を使いたい) にも使えるので windows マシンを購入してもいいかもしれないと考えるようになってきた。申告書を郵送してもよいけど、1時間もあれば往復できる距離なので気分転換も兼ねて合同庁舎に出向いてきた。

帰りに新長田駅の近くの三菱UFJ銀行の支店で納付する。前回は窓口納付をしたが、今回は STM (Store Teller Machine) での納付に初挑戦した。STM(Store Teller Machine)の存在意義とは のブログ記事にも書かれている通り、納付書を OCR でスキャンすることでどんな納付書でも対応できるという汎用性はすごいと思うものの、その裏で人間がチェックしているんじゃないかと思えるメッセージや引き落とす合計金額はユーザーが手入力で決定する (OCR で合計がどの金額かわからなかった場合のみ？) といったオペレーションになっていて、なんか全く自動化されてない感があって残念に思った。見た目上、機械化されているけど、運用には人手がかかっているようにみえた。まぁでも、初めて使ってみて経験としてはおもしろかった。

Jira のフィルターとリマインダー

所得税や住民税の納付は原則毎月納付する必要があるけど、小さい企業は納付の特例という制度があって6ヶ月単位にまとめて納付できる。小さい企業の事務手続きの工数削減を狙いとしてある制度だと思う。うちもその特例制度を利用して6ヶ月ごとに納付している。カレンダーに繰り返し予定として登録してあるのでカレンダーをみていれば見落とすことはないのだけど、そのときに都度チケットを作ってやるのも面倒なので納付の親チケットを作っておいて、子タスクとして毎回作業するようにしている。それをみていて、納付期限を設定しておいてリマインダーしたら課題管理システムっぽくていいなと思って Jira でのやり方を調べてみた。Jiraにて期限の近い課題の通知を受け取りたい というのがあって、任意の JQL で期限を調べるフィルターを書いて、そのフィルターに対してサブスクリプションというメール配信設定を行う仕組みになっている。これはこれでよくできたうまい仕組みだと思う。しかし、いまチケットのイベントに対してメールを送る設定は無効にしていて、Slack インテグレーションを使ってすべて Slack の通知チャンネルにイベントを流すようにしている。できれば、Slack インテグレーションで期限のリマインダーを通知できるのが望ましいた。公式の Jira Slack app だと、JQL でフィルターはできるけど、イベント発生時に通知する仕組みなので毎週フィルター実行するような用途には使えない。

たまたまそんな話しをツィートしてたら Jira API と Slack API を使ってスクリプトを書いているというのを教えてもらった。これはこれで便利そう。

こんな感じのスクリプトでJIRAからslackに通知してます https://t.co/UzeIZ9Nbol

— Takanori Suzuki (@takanory) October 22, 2021

0時に寝て6時に起きた。だいたい夜中に2-3回は起きるのが普通になりつつあって、前日ジョギングしてたせいか腰やお尻の筋肉に張りがあったので3時頃起きてストレッチして張りの箇所を伸ばしたりしながら寝てた。午前中、いけさんから上等なお酒をいただいた。造り酒屋の一族らしい。感謝。

朝活

朝起きる目的にいいかも？と思って Webデザイントレンドのよりみち の金朝つめとぎに参加してみた。やっぱり目的があれば6時に起きれる。でも、終わってから1時間ほど寝てたので今日はプラスマイナスゼロ。前回の朝活 と同様、ミクロ経済学の入門書を読んでた。第2章の予算線と最適化を読んだ。経済学とはこういうものだという説明が腑におちた。当たるかどうかよりも考え方を理解しておく方が大事なように思えた。

ときどき経済学に対して「経済学が想定するほど実際の消費者は懸命に選択しているとは限らない」といった批判がなされることがある。でもこれまでの説明から明らかなように、その批判は勘違いにもとづくものだ。批判したいなら「経済学は、消費者がはたから見て確実に愚かな選択をしても、それを非難しない傾向が強い」というほうが適切だろう。

もう1つおもしろかったのがこの一節。

予算線と選好を用いたミクロ経済学的分析は、現金給付のよさを指摘する。ただし、制度の悪用、人々の支持、必要原理といったことを考えると、現物給付のほうが好ましいとなる。現金給付と現物給付のどちらが総合的によいのか、これらの話だけで結論づけることはできない。とはいえここで、ミクロ経済学が有用な政策分析ツールたりえること、またミクロ経済学だけで政策を論じるのは不十分ということが分かったのは十分な収穫である。

人間の活動を予測するような学問の便宜上、前提条件や制約を課している。経済という人間にとって重要な社会システムを扱う経済学への期待値が大き過ぎるがために経済学の言うことが当たった・当たってないといった議論になりがちなのかもしれないと思えた。

データ指向アプリケーションデザイン

5章レプリケーションを読んだ。200ページ超えたことで1/3を読み終えた。まだまだ先は長い。

シングルリーダーレプリケーションは一般的なものだし、Cassandra の運用をしていたのでリーダーレスレプリケーションもだいたいは知っていた。並行書き込みの問題は意識したことがなかった。そういう状況が発生するアプリケーションにおいてはとても難しい問題なことが理解できた。Cassandra で採用されている衝突解決アルゴリズムは 最後の書き込みを勝たせる（last write wins、LWW） というものであり、これで十分なように考えていたけど、不十分なケースもあることがわかった。

レプリケーションとは、ネットワークで接続された複数のマシンに同じデータのコピーを保持しておくこと。

• データを地理的にユーザーの近くで保持しておく => レイテンシを下げる
• 一部に障害があってもシステムが動作し続けられる => 可用性を高める
• 読み取りクエリを処理するマシンをスケールアウトする => スループットを高める

レプリケーションはいくつかの目的で使われる。

• 高可用性/耐障害性
• レイテンシ
• スケーラビリティ

対象のデータが時間が経っても変化しないのであれば、レプリケーションは容易。単にデータのコピーを各ノードに一度だけコピーすれば完了するから。レプリケーションの難しさは、すべてレプリケーションされたデータへの変更の扱いから生じる。変更をノード間でレプリケーションするのに広く使われているアルゴリズムは次の3つになる。

• シングルリーダーレプリケーション
  • クライアントはすべての書き込みを1つのノード（リーダー）に送り、リーダーはデータ変更イベントのストリームを他のレプリカ（フォロワー）に送る
  • 読み取りは任意のレプリカから行えるが、フォロワーから読み取るデータは古い可能性がある
• マルチリーダーレプリケーション
  • クライアント群は、それぞれの書き込みを複数あるリーダーノードのいずれかに送信する
  • これらのリーダーノードはどれも書き込みを受け付ける
  • リーダー群は、データ変更イベントのストリームをお互いに、そしてすべてのフォロワーノードに送信する
• リーダーレスレプリケーション
  • クライアントは、それぞれの書き込みを複数のノードに送信し、古いデータを持つノードを修正するために読み取りを複数のノードから並列に行う

データベースのレプリケーションの原理は1970年代から研究されていてそれほど変わっていない。とはいえ、分散データベースがメインストリームで利用されるようになったのは最近のこと。アプリケーション開発者の経験不足により 結果整合性 のような問題に関しては多くの誤解が生じた。いずれのレプリケーションのアプローチにもメリットとデメリットがある。シングルリーダーレプリケーションは理解しやすく、衝突解決を気にする必要がないことから、広く使われている。マルチリーダーとリーダーレスのレプリケーションは、ノードの障害、ネットワークの障害、レイテンシのスパイクがあっても頑健になる。しかし障害の理由を説明するのが難しく、一貫性についても弱い保証しか示せない。

レプリケーションは、 同期 で行うことも 非同期 で行うこともできる。どちらにするのかは、障害があったときのシステムの振る舞いに大きく影響する。非同期のレプリケーションは、システムがスムーズに動作しているときには高速に動作するが、重要なのはレプリケーションのラグが大きくなったり、サーバーに障害が生じたりしたときに何が起こるのかを理解しておくことになる。リーダーに障害が発生し、非同期に更新されていたフォロワーを新しいリーダーに昇格させたら、直前にコミットされたデータは失われてしまう可能性がある。

レプリケーションラグが生じている状況下でアプリケーションがどのように振る舞うべきなのかを決める際に役立つ一貫性モデル。

• 書き込み後読み取り (read-your-writes)
  • ユーザーは、自分自身が投入したデータを常に見れる
• モノトニック読み取り (monotonic reads)
  • ある時点のデータをユーザーが一度見たら、それ以前の時点のデータは見れない
• 一貫性のあるプレフィックス読み取り
  • ユーザーは、たとえば質問とその質問への回答を適切な順序でといったように、適切な因果関係を保持した状態でデータを見れる

マルチリーダーとリーダーレスのアプローチは本質的に並行性の問題を抱えている。複数の書き込みが並列に行われることがあるので、衝突が生じる場合がある。ある操作が他の操作よりも先に行われたのか、あるいはそれらが並行して行われたかを判断するためのアルゴリズムについて説明されている。

Slack apps の調査

Workstreams.ai を試してみた。

Results-driven task management for Slack, Microsoft Teams and Google

結果駆動タスクマネジメントという聞いたことない用語が書いてある。SaaS 型の Web アプリケーションとしての課題管理システムとチャットツールとの連携が密になったプロダクトにみえる。UI もよく作り込まれている。Workstreams.ai のアカウント管理は Sign in with Slack を使っている。ドキュメントによると openid connect と oauth 2.0 の仕組みを組み合わせているのかな。認証よくわかってないので背景も勉強しないといけない。簡単にタスク作成やコメント、更新などを Slack クライアントと Web アプリケーション上で触ってみた。

もう1つ Google Sheets for Workflow Builder というのも試してみた。ワークフロービルダーのステップに簡単に Google Sheet との連携を実装できるのでめっちゃ簡単。ワークフロービルダーは本当によくできているな。

ジョギング

今日は調子はよかったけど、お仕事の区切りがよかったので19時に終えて近所の公園にジョギングしてきた。昨日も走ってたのでやや筋肉痛が残りつつ、走り始めは筋肉がきしむ感じだったけど、走っているうちに体があたたまってきて気にならなくなった。時間帯は同じだけど、昨日より陸上部の人たちが半分ぐらい少なかった。曜日によって違うのかなぁ。

2時頃に寝て6時に起きる。普段、日記は vim で書いている。ちょっとした過去の日記の検索に vimgrep でこと足りるのが嬉しい。テキストで日記を書いていることの利点かな。夜に fin-pyコードリーディング会#4 に参加した。事前に hackmd に発表内容のメモを書いてた。いろんな発表者の視点があってコードリーディングのイベントはおもしろかった。

朝活

【三宮.dev オンライン】リモート朝活もくもく会 に参加してみた。何もなかったらだいたい7時頃に起きるのがなにか目的があると6時に起きれる。人体の不思議。せっかく起きたので 前に More Joel on Software を読んだとき に学生向けのアドバイスにあったミクロ経済学の勉強のためにその入門書を読み始めた。参加者が勉強会の常連ばかりだったので朝からわりと雑談してた。2人転職するという話で2人とも東京の会社でフルリモートワークで働くらしい。働き方が変わったなと感じる。その後、第1章の無差別曲線を読んだ。

YouTube 配信と集中力

あんちぽさんの 2021年10月9日 の日記でスライド作成の興がのらないので YouTube 配信しながらやったら集中できてよかったと書いてあったのでちょっと眺めてみた。なんかスライドの作成のやり方とか、自分と違うのかな？とか思いながらみたけど、やり方自体は普通だった。ただ集中できてよかったとあるので普段のやり方とは異なることをすることに意義があるのかな？とも思えた。試しに YouTube Live やってみようとしたら初期設定？に24時間かかるとのこと。代わりに kazam というスクリーンリコーダーの使い方を調べてた。勉強会で作業したログとかを録画しておいてなにかに使えたりするかもしれない。

データ指向アプリケーションデザイン

半日ほどかかって3章ストレージと抽出を読んだ。読みながら書いているので時間がかかる。今日はこれだけ。まとめはこんな感じ。

データベースのシステムには2つの用途があり、その特性やパフォーマンスを最適化するためにストレージエンジンやデータ構造が異なるもので運用されるようになってきた。

• オンライントランザクション処理 (OLTP)
  • 行指向、トランザクション処理
• オンライン分析処理 (OLAP)
  • 列指向、分析クエリ

OLTP には2つの主要なストレージエンジンがある。

• B ツリー
  • 1970年代からあり、成熟していて且つ効率的なインデックスのデータ構造
• LSM ツリー
  • 比較的最近開発された、ディスク上でのランダムアクセスをシステム的にシーケンシャルアクセスに変換して、書き込みのスループットを高める手法。もとは Google の BigTable の論文？

OLAP の典型的なデータウェアハウスの高レベルでのアーキテクチャでは、大量の行をシーケンシャルにスキャンしなければならないクエリの場合、インデックスはあまり関係なく、データを非常にコンパクトにエンコードし、クエリがディスクから読まなければならないデータの量を最小限にとどめることが重要となる。この目標を達成するのに列指向のストレージが役立つ。

過去に Cassandra を使ったプロダクトの開発に関わっていたから B ツリーと LSM ツリーの概要は知っていて3章で書いてあることはだいたい理解できた。データウェアハウスに関しては、前にお手伝いしていた会社で普通のログを Amazon Athena で処理すると1時間とかかかって分析クエリが Parquet に変換すると数分で完了したりするのを目の当たりにしてた。分析処理で読み込むデータ量を削減する列指向の考え方は理解しておく必要がある。行指向のデータを列指向フォーマットである Parquet に変換する columnify のコードも読んだことがあったので内容のイメージはできるけど、実務経験が少ないと全体像がわかっておらず、本書を読みながら学び直ししてた。