0時に寝て5時に起きた。昨日 slack で質問していた内容に5時頃に返信があるのをたまたまみかけた。この時間に起きているんだと思って返信にコメントしてたら別のメンバーからもコメントが書き込まれて、早起きは三文の得みたいな感じで朝5時から slack でやり取りしてた。いま私はだいたい8時から始業している。開発チームの半分ぐらいのメンバーはそのぐらいから始業しているのが課題管理システムや git のコミットログからわかる。このチームは朝早い人たちが多いなと感心した。

朝活: アジャイル開発とスクラム 第2版

2021-11-26 AM 6 金曜朝6時開催のもくもく会 で第6章と第7章を読んだ。第2部は企業において実際にスクラムを導入していったときの四方山話が出てくる。私はあまり他社の事例に興味はないが、対談の過程で本質的に大事なことや難しいことなどがあぶり出されることもあるので、実務を通しての話題も参考になる場合があることは理解できる。大半の事例は実業務で使われているという結論がわかるだけでも十分だと思う。とくに大企業は様々な厳しい制約や要件の中で採用していると推測されるので、それだけで大きなメッセージをもつ。斜め読みでざっと読み進めながら興味のある話題があれば精読するといった程度で読んでた。

大企業あるあるな話しでスクラムイベントを通してお互いの距離感が縮まってうまくいったといった内容があった。開発者からすると距離感の遠近に関係なく、必要なら適切な相手を探し出してコミュニケーションを取るのが普通だけど、みんながみんなそうではないだろうし、(同じ会社の社員でも)よく知らない人とは話さないといった考え方をもつ人もいるだろう。ある人はこれを単純接触効果で説明していたけど、業務ではなく人間の側面からみてスクラムイベントが多いことにも意義があるのかもしれない。

ある事例でスクラムにおいてイベントがたくさんあってそれに参加することでお互いの距離感を縮めたという効果が書かれている。開発者は気になったことは何でも確認するという姿勢をとりがちだけど、関係者のみんながそうではないというのも理解できる #金朝ツメトギ

— Tetsuya Morimoto (@t2y) November 25, 2021

顧問さんと雑談

隔週で打ち合わせをしている。最近はお手伝いのお仕事が忙しいので今回は雑談になってしまったが、近況としてリーンキャンバス、スクラム実践の話題などを話していた。わりと盛り上がって1時間で切り上げるつもりが1時間半に伸びてしまって、別のお仕事の時間を圧迫したけど、それはそれで意義のある雑談になったので収穫はあった。

ある組織で新規事業を行う上で AARRR (あー) モデル をすごく重視しているといった話題が出た。バケツみたいなイメージがあって、そこに現実の数字を当てはめていってプロジェクト/プロダクトの改善やふりかえりなどに活かしているという。サービスのグロースに責任をもつ人には重要な概念だという。うちのプロダクトはグロースしなくてもよいけど、なんらかのフレームワークに当てはめて抜け・漏れがないかをチェックすることにも使えるかもしれない。世の中でよく使われているフレームワークを調査しておいて損はないと思う。私はビジネスに全く疎いのでリーンキャンバスを通じて、AARRR モデルの話題になって、それがどういった用途で使われているかというお話しは興味深かった。

具体的には AARRR モデルの他に、スクラムの話題からは野中郁次郎氏のオリジナルの論文、大規模アジャイルの方法論などが盛り上がっていくつかキーワードが出た。そういった雑談の中で感性に従って気になったことを深堀りしていくとおもしろい調査や知見になったりすることを経験的に実感しつつある。今後もそういう機会や内容を大事にしていきたい。

カスタム GitHub Actions の開発

先日 調査していたものをベースに、普通にやる方法と カスタム GitHub Actions の compoiste action で実装する場合の検討資料などを作って、カスタム GitHub Actions を実装してよいといった許可をもらった。企業における唯一の懸念は (原則) public リポジトリで運用するところで、CI のような処理に社外秘は含まれないが、public そのものに審査や承認を必要とするような組織では腰が重くなるようなこともあるかもしれない。ロードマップにも private リポジトリでカスタム GitHub Actoins を動かせるようにしようという課題は作成されている。

• Actions: Use actions from internal repositories #74

5時に寝て7時半に起きた。前週末は遊んでたので夜はいろいろ作業してた。朝起きる習慣がついてきたので何時に寝ても起きれる感じになってきた。うまく体調管理もできている。

年末調整と住民税の納付

年末調整は1月末まで、住民税の特別徴収は納付の特例を使うと6-11月の6ヶ月分を12月10日までに納める。年末調整も11月の給与を確定したら調整額を算出して12月の給与に反映する。必要な情報を入力したら会計システム (freee) で自動算出してくれて書類も一通り作ってくれるので難しくない。ここで出力される給与支払報告書を市役所と税務署のそれぞれに申請する。市役所向けの手続きは eLTAX で行い、税務署向けの手続きは e-Tax で行う。先日 Windows マシンを購入 したので、今回は eLTAX の DL 版で完全な手続きができるはず。ただし、e-Tax も eLTAX も祝日・日曜日は利用できないのでやろうと思ったものの、今日は祝日だからできなかった。

住民税の特別徴収の納付も今回が初めての試み。企業が社員に代わり住民税を納付するのが原則であり、これを特別徴収と呼ぶ。昨年は特別徴収への切り替え申請をしないといけないのを私が知らなくて手続きが遅れた結果、個人宛に届いた納付書でそのまま支払いした。納付自体はそれでも問題はない。おそらく徴税側からみたら源泉徴収して企業の担当者が納付した方が誤りがなく確実でサポートコストを削減できるという狙いなんだろうと推測する。住民税の納付も eLTAX でできるようなので後日挑戦してみる。

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

4日前から読み進めていて、第1部アジャイル開発とは何か、スクラムとは何か (第1章から第5章) を読み終えた。

冒頭の序論を読んでいて、スクラムは 1980 年代の日本の製造業の (革新的な) 製品開発スタイルの論文がオリジナルだというのを知った。ソフトウェア開発の文脈だと、米国から輸入した方法論のようにみえるが、もとは日本で編み出された方法論だったという。1986年に書かれたハーバード・ビジネス・レビューに投稿された論文がオリジナルらしい。

• The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka

前に スクラムガイド2020 を一通り読んでいたので、スクラムについての内容はだいたい理解できた。補足でよかったのは、スクラムガイド 2017 から 2020 で改訂された内容やその背景や意図などがコラムで紹介されていた。それらを知ることで、よりスクラムで陥りやすい失敗や誤解されがちなところを理解できた。たとえば「開発チーム」という用語から「開発者」に改められた。スクラムチームの中に別のチームがあるようにみえ、プロダクトオーナー vs 開発チームのような対立構造にならないよう、チームはスクラムチームという1つしかないという意図だという。そして、開発チームの自己組織化 (Self-organized) というキーワードが、スクラムチームの自己管理型 (Self-managed) へといったように、主体である開発チームだけ自律的且つ協働するように読めたのを、スクラムチームという1つのチームしかないと強調されている。

コラム: 2020 スクラムガイド改訂とスクラムの3つの罠

• スクラムが形式的、儀式的になってしまっている
  • 目的を理解せずにハウツーをなぞるだけのチームが増えたので抽象的な表現に変更した
  • 例) デイリースクラムがただの報告するだけになっている
    • デイリースクラムの目的は状況にあわせた再計画であるため、形式的な報告ではいけない
• プロダクトオーナー vs 開発チームの構図に陥ってしまっている
  • チーム内の分断をなくし、ワンチームになることが強調されている
  • 開発チームから開発者へ、チームはスクラムチームが唯一
  • プロダクトオーナー vs 開発者が対立構図になることが多かった
    • 「開発チームの自己組織化」から「スクラムチームの自己管理」へ
    • スクラムは役割を超えて協力していくことが欠かせない
      • 問題 vs 私たち (スクラムチーム) という構図を引き出すことが重要
• スクラムマスターがスクラム警察もしくは雑用係になってしまっている
  • スクラムマスターが「サーバントリーダー」とされていたが、単にサーバントになってしまうことがあった
  • スクラムマスターはプロダクトの成果や組織の目標にコミットメントしないといけない
    • ただスクラムルールを守らせたり、会議の司会役をするだけではない
  • 「真のリーダー」としての資質とプロダクトの成果や組織の目標にコミットメントしていくための熱量を重視して専任していく必要がある

これらのコラムを読むと、私が傍からみていたスクラムは本来の意図したスクラムの開発方法論ではなく、正しく運用されていなかったスクラムなのかもしれないとも思えてきた。本書の第1部を読み進めてみて、スクラムの意図している目的や価値には私が共感できるところが多々あった。

0時に寝て6時に起きた。昨日も疲れててウォーキングには出掛けられなくて寝て、3時や4時に起きつつも気付いたら5時半に起きてて、そう言えばと思い出したときに6時だったというふわふわした寝起きだった。

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

［金朝ツメトギ］ 2021-11-19 AM 6 で第10章の再分配を読んだ。この本はほとんど朝活で読み終えた。

市場は社会的余剰が最大化されるので社会全体の富を増やす働きの強い制度だという。その増える富の方向性をタテとヨコで表現しているが、タテ方向に増やす働き (資本家が莫大な富をもつ) はあっても、ヨコ方向に拡げていく (みんなが裕福になる) 機能はないという。本章では所得の再分配と、再分配が適正かどうかを測るための指標として ジニ係数 について説明されている。ジニ係数を使うと、所得分布から不平等の状態を客観的に把握することに優れているという。富める者から貧しい者へ所得を移転することでジニ係数が下がる。ただし、両者の貧富を逆転させないものを ピグー・ドールトン移転 と呼ぶ。このピグー・ドールトン移転を実行し続けると、最終的に所得分布は全員が同じである 完全平等分布 になる。このときのジニ係数はゼロになる。その逆に、1人がこの世すべての所得を独り占めすると 完全不平等分布 となり、そのジニ係数は 1 (に近い値) となる。

• 絶対的貧困: 世界銀行は生命の維持に必要な基準として1日の所得1.25ドルと定めている、絶対的貧困の指標の1つと考えられる
• 相対的貧困: 所得分布の真ん中の50%と OECD が定めている
  • 相対的貧困の基準に満たない人口の占める割合を 相対的貧困率 と呼ぶ
  • 2019年 国民生活基礎調査の概況 によると、2019年の値は 15.7% になるらしい。6-7人に1人ぐらいの割合になる

メタ認知が暴走

あんちぽさんの日記 に次の動画が紹介されてた。メタ認知で〈学ぶ力〉を高める：認知心理学が解き明かす効果的学習法 を読んでから、学びや書くことについてメタ認知というキーワードを意識して考えるようになっている。この動画ではメタ認知を「相対化」と説明していた。自己を相対化して、様々な文脈や状況、相手の意図なども考慮して結論が出せなくなったり、思考がまとまらなくなってしまうという。そういうメタ認知が暴走する人間を メタモン と名付けていた。ここでいう「モン」はモンスターの短縮なのかな？なかなかおもしろい。こんな極端ではないけど、私も相手の意図や状況を深読みしてしまって静観の姿勢を取るものの、なにも考えてない人だったりすると無駄に時間を浪費してしまうこともある。他にも 銃・病原菌・鉄 の話題が気になって wikipedia を軽く読んだりした。

会食

姪が大学に進学するそうでその面接に来たので一緒に晩ご飯することに。姉の勤め先の関係会社で 神戸プレジール という神戸牛ステーキのややたっかい系のレストランで食べてきた。コース料理で1万円/人で飲みものやデザートなどは別途6千円ほどだった。但馬牛や神戸牛のステーキはもちろんとてもおいしかったんだけど、もう自分はこういう料理を求めてないなというのも感じた。個室で食べてたんやけど、姉の仕事の関係者が5-6人ぐらい、入れ代わり立ち代わりにやってきて、姉は直売所のパートだったのが、いつの間にか社員になって、いつの間にかナンバー2になっているらしい。おまけでフォークリフト免許まで取っている。なんやかんやも含めて、この場所を晩ご飯に選んでいるのもあるんだろうけど、職場の周りの人にしか言っていない今日の予定を、どこかで聞きつけて挨拶にくる関係者の人たち。私が学生の頃「田舎の噂は isdn より速い」と言ったものだけど、いまは「光回線よりも速い」と言うらしい。姉がいろんな関係者に挨拶しているのをみながら、もう自分はこういう仕事もたぶんできないなと実感した。

1時に寝て3時に起きて2度寝して6時に起きた。起き上がれなくて6時半までだらだらしてから起きた。

リポジトリの改行コード指定

git のリポジトリ設定で .gitattributes という設定方法がある。ざっくり理解するには .gitattributesによる改行コードの変換設定 を読むのが早い。とりあえずこんな設定にしてみた。すでに crlf の改行コードでコミットされたファイルがあるため、それらを lf に変換しないといけない。eol=lf にすると crlf でコミットされている既存ファイルも変換してくれるみたい。おそらくチェックアウトしたときにそうなるのかな？

*       text=auto eol=lf
*.jar   binary

ここ数年は Windows マシンを開発に使っている開発者と一緒に働いたことがなかったけど、OS 混在環境だとリポジトリ設定が必要だということに気付いた。多様性は大事。

忘年会

三宮.dev＆bizpy 合同忘年会 に参加登録した。bizpy だけだと、忘年会の参加者を集めるのは厳しそうなので三ノ宮.devと共同でやる。これなら最低でも2人は確定しているのでイベントがなくなることはない。日程は参加者の希望を聞きながら水曜か金曜でやるみたい。いましか飲み会できないだろうからいいと思う。

ミクロ経済学入門の入門

第9章の公共財を読んだ。市場を考察するときに扱う財は一般論として 私的財 を想定している。私的財は次の2つの性質を満たす。

• 競合的: 複数の人々が同時に利用できない
• 排除的: 拠出に貢献した特定のメンバーしか利用できない

一方で私的財と対偶の関係にある競合的でも排除的でもない財を 公共財 と呼ぶ。例えば、国防サービスや一般道路などが相当する。侵攻してくる敵国から自国を防衛するときにすべての国民、納税していない人であっても国防の利益にあずかれる。非競合的だが、排除的である財を クラブ財 と呼ぶ。高速道路などが相当する。みんなが利用できるが、利用料金を収めないと利用できない。競合的だが非排除的な財を コモンプール財 と呼ぶ。漁場などが相当する。どの漁師が魚を獲るかは競合しているが、漁業権をもっている限り漁そのものは制限されない。

これをまとめると、財は次の4つの分類になる。

公共財の自発的供給の問いとして、排除的でも競合的でもない公共財が人々の自発的な行動で十分に供給できるかを考える。自分のお金を寄付する・寄付しないの2択でマトリクスを作成する。自分は寄付せず、他人の寄付から利益を得ることを フリーライド と呼ぶ。みんながフリーライドをしようとすると公共財はまったく供給されない。A と B の2者間における利得表を表すと次のようになる。相手が寄付して、自分が寄付しないときに最大の利益となり、どちらも寄付しないよりは両者が寄付した方が利益が大きくなる。

A が寄付するか・しないかの選択は、B の寄付の有無に関係なく、A は寄付しない方が寄付したよりもトクすることになる。相手がどういった選択をしても自分にとって一番トクな選択肢が同じときにその選択肢を 支配戦略 という。この話は B からみても同じになる。A も B も寄付しないがトクする状態のことを 支配戦略均衡 という。この状態が最善かと言えば、そうではなく、両者が寄付した方が両者が寄付しないよりもトクする状態になる。このように公共財の供給を個々のプレイヤーに任せていては パレート劣位 な結果となってしまう。この状態からどうやって両者が寄付する パレート優位 な状態に移行できるかを考えるのが、政府の徴税の方策と言える。

政府が誰にいくらの税を課して、どの程度の量の公共財を適切と決めるのかは難しい問題である。放っておいて上手くいかないものの、政府に任せて上手くいくことも保証されない。このようなゲーム理論を制度設計に活用する メカニズムデザイン という専門分野がある。

2時に寝て8時に起きた。起きてからドラクエタクトのダイの大冒険コラボイベントをお昼前までやってた。午前中遊んでた割には今日はいろいろ作業した。ゆっくり寝たせいか、個々の作業は集中してできた。

リーンキャンバス

友だちにプロダクトの設計についてレビューしてもらう機会を調整してたらリーンキャンバス作るとよいとアドバイスをもらった。全然やったことがないので試しに自分でもやってみることにした。リーンキャンバス（Lean Canvas）を活用した企画書の書き方【テンプレート付】 を読みながら Canvanizer というツールで作成してみた。リーンキャンバスの利点の1つとしてA4サイズ1枚程度におさめるので短時間で作成できるというのがある。プロダクトの要件定義と設計はすでにできているので、リーンキャンバスは1時間も経たないうちにたたき台を作成できた。また友だちにレビューしてもらうときにフィードバックをもらいながら精度をあげていく。

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

昨日から 9.4 分散トランザクションと合意の後半の3つの節を読んだ。第Ⅱ部、400ページを超えたので2/3ほど読み終えた。

• 9.4.3 耐障害性を持つ合意
• 9.4.4 メンバーシップと協調サービス
• まとめ

合意の問題は、次のように形式化される。1つ以上のノードが値を 提案（propose） し、合意アルゴリズムはそれらの値の中から1つを 決定（deside） する。この形式化においては、合意アルゴリズムは次の性質を満たさなければならない。

• 一様同意（uniform agreement） : 2 つのノードが異なる決定をしていないこと
• 整合性（integrity） : 2 回決定をしているノードがないこと
• 妥当性（validity） : ノードが値 v を決定したら、 v を提案しているノードがあること
• 終了性（termination） : クラッシュしていないすべてのノードは、最終的に何らかの値を決定すること

耐障害性を持つ合意アルゴリズムで最も広く知られているのは、Viewstamped Replication（ VSR ）、Paxos、Raft、Zab であり、こういった合意のアルゴリズムは全順序ブロードキャストを実装しており、複数回にわたって合意が行われる。全順序ブロードキャストによって耐障害性を保ちながら線形化可能でアトミックな操作を実装できる。ZooKeeper のようなツールが、アプリケーションから利用できる合意、障害検出、メンバーシップの「アウトソーシング」サービスを提供する上で、重要な役割を果たしている。分散システムにおける様々な問題に耐えうるようなアルゴリズムを独自に開発するよりははるかによいといえる。合意へと落とし込めるような問題の処理が必要で、さらに耐障害性が求められるなら ZooKeeper のようなサービスを使うとよい。

神戸駆動開発イベント

大阪駆動開発 という xr (vr/ar/mr) のコミュニティがあって、いろんな地域に拡張しているようで、その支部？の1つに神戸駆動開発ができて、そのイベントとして 【神戸】XR体験&交流会 に参加してきた。会場が 神戸電子専門学校 だったのでどんなところかを見に行く意図でも出かけてきた。三宮.dev の主催者も神戸電子専門学校の中の人とつながりがあるらしく、今度オフラインの勉強会をそこでしようか検討しているといった話しもあった。bizpy もコロナが落ち着いたらオフラインの勉強会をやってもいいかなとは考えているので接点を作っておいてもいいかもしれない。神戸なんて狭い地域なのでコミュニティ関係者はすぐにつながるけど、神戸でオフラインの勉強会を開くに当たって適当な場所がないというのはあちこちで聞く話しでもあるので、神戸電子専門学校がそういったコミュニティをつなぐハブ的な場になるならそれはそれでいいのかもしれない。

HoloLens 2 と Nreal Light と iphone や apple watch とレンズやミラーを組み合わせて作った手作りのデバイスなども体験させてもらった。HoloLens が思ったよりも映像がみえにくくて、ロボットを操作してロケットを発射させるコンテンツをやってみたんだけど、操作よりもコンテンツが明確にみえなくて難しかった。もしかしたら装着の仕方が悪かったのかもしれない。それに比べて Nreal Light はアイドルのライブみたいなコンテンツをみたんだけど、映像も音声もはっきりしていたので印象はよかった。

適当にスタッフの人と話していて、センサーを使って現実のモノや事象を vr 空間に持ち込むと vr コンテンツを作るのは簡単かも？という話しをした。なんかセンサーを探してもいいかもしれない。そのスタッフの人はピアノを弾くのでピアノ音を取り込んで加工したりしていると話していた。

傾斜枕

胃食道逆流症（英語表記Gastro Esophageal Reflux DiseaseからGERD（ガード）とも呼ばれています）は、主に胃の中の酸が食道へ逆流することにより、胸やけ（みぞおちの上の焼けるようなジリジリする感じ、しみる感じなど）や呑酸（酸っぱい液体が上がってくる感じ）などの不快な自覚症状を感じたり、食道の粘膜がただれたり（食道炎）する病気です。胸が詰まるような痛みを感じたり、のどの違和感や慢性的に咳が持続する患者さんもいます。胃酸の逆流は食後2～3時間までに起こることが多いため、食後にこれらの症状を感じたときは胃酸の逆流が起きている可能性を考える必要があります。

(…)

現在では成人の10～20％がこの病気にかかっていると推測されています。

胃食道逆流症(GERD)

ここ1-2年、睡眠がうまくとれなくなったことと関連して、寝ていて胃酸が逆流してむせるといったことも2-3ヶ月に1回ぐらいと稀ではあるけれど、起きるということに気付いた。2年ほど前、健康診断で胃カメラを受診したときに医師から胃の入り口の弁が、普通の人は逆流しないように閉じているものが私のは開いているという話があった。そのときは特に日常生活に困ってないからいいんじゃないで流してたんだけど、加齢とともに胃食道逆流症が起こっているのかもしれないと、いくつかの事象を認識して思うようになってきた。喉の違和感も気になるようになっていた。その症状の軽減に逆流しにくいように傾斜を付けて寝るとよさそうというのをみつけて、傾斜枕を買ってみた。しばらく試してみて寝心地や胃食道逆流症がどうなるかを観察してみる。

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 ）で実装されているらしい。全く聞いたことがなくて、私はいままでこの技術に関わることがなかった。

3時に寝て7時に起きた。ウォーキングから帰ってきて0時にベッドに入ったものの、選挙結果の総括記事を読んだり、宇宙よりも遠い場所 をみたりしていたら3時になってしまった。全13話すべてみた。どちらかと言えばおもしろかったけど、ツィートみて期待値が高かった分、そこまで私の中に響くものはなかったかな。南極へ行く道中や南極の生活がわりと遊んでいるようにみえてあまり大変そうにみえなかった。とはいえ、実際の船上や南極でもやることなくて娯楽ないと持て余すのかなとも思えた。南極地域観測隊 って現実にあるんだなとみてた。

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

9.3 順序の保証を読んだ。

データベースや分散システムにおいて順序付けは重要な基本的概念である。順序と線形化可能性、合意との間には深い関係がある。順序付けが重要なのは 因果関係 を保つのに役立つことがあげられる。

全順序 があれば任意の2つの数を比較して大小関係を必ず判断できる。たとえば自然数には全順序があると言える。線形化可能なシステムは操作に全順序がある。一方で因果律には並行という概念があり、どちらが先に行われたかが重要ではない場合に操作が並行に行われたとみなせる。したがって、因果律は全順序ではなく、 半順序 を定義すると言える。半順序とは、大小関係を比較できる場合もあるしできない場合もあることを指す。

因果律に基づく順序と線形化可能性との関係は、線形化可能性は因果関係を 暗に含む といえる。線形化可能性を持つシステムは、因果律を正しく保持する。しかし、システムを線形化可能にすればパフォーマンスや可用性が損なわれる可能性がある。特にネットワークの遅延が大きい（たとえば地理的に分散している）システムで問題になる。そのため、分散データシステムの中には線形化可能性をあきらめることでパフォーマンスを向上させたものの、扱いが難しいものもある。因果律を保持する方法は、線形化可能性が唯一というわけではなく他の方法もある。多くの場合、システムに本当に必要なのは線形化可能性ではなく因果律における一貫性だけであり、これは線形化可能性よりも効率の良い実装が可能となる。

因果律における一貫性を保持する方法として次のものがあげられている。

• シーケンス番号またはタイムスタンプ
• ランポートタイムスタンプ（Lamport timestamp）

しかし、分散システムではネットワークを介して他のノードの状態を確認しないと因果律の一貫性を確定できない。たとえシングルリーダーアプリケーションであっても、リーダーに障害が発生したときにリーダーのフェイルオーバーが必要となる。この問題は 全順序のブロードキャスト と呼ばれる。ZooKeeper や etcd のような合意サービスが全順序ブロードキャストを実装している。

詳細は省くが、ネットワークを介した分散システムで線形化可能な compare-and-set （あるいは increment-and-get ）を実装しようとすると、必然的に合意アルゴリズムに行き着く。これらと全順序ブロードキャストは等価であることが証明できる。したがって、これらの問題のいずれかを解決できれば、他方の問題の解決策に変換できるという点は重大な知見である。

REALFORCE のワイヤレスモデル

ユーザーから待望されていた REALFORCE のワイヤレスモデルがとうとう発売された。

• 高級キーボードREALFORCEから待望のワイヤレス機「R3」が登場、見どころは？

先週から amazon で予約販売を受け付けていたので REALFORCE 東プレ R3 キーボード 静音 ハイブリッドモデル 日本語配列 91キー ブラック R3HC12 を予約して、本日届いた。私はとくに必要ないけど、bluetooth のマルチペアリングに対応していて最大4つまで接続できる。オフィスの机はそこそこ広いけれど、本とラップトップとモニター2台置いたらスペースが埋まってしまっている。ご飯を食べるときや書類を作成するときにキーボードを立てかけたりしてスペースを確保していて不便に感じていた。

ubuntu 環境での bluetooth の設定に少し手こずった。GUI の設定マネージャー (blueman) でペアリングしようとしても失敗する。キーボードの情報は取得できるけど、ペアリングは失敗する。試しに macos でペアリングしてみたらパスキーの入力画面が表示されて、6桁の数字を入力して ENTER した後に接続するとペアリングできた。blueman だとパスキーが表示されないなと気付いてググってたら [SOLVED] Bluetooth keyboard: Unable to pair (authentication timeout) を見かけて、bluetoothctl でも設定できそうなのでやってみた。

キーボードの情報を表示
[REALFORCE_3]# info F6:9D:A5:80:B7:1F
Device F6:9D:A5:80:B7:1F (random)
	Name: REALFORCE_3
	Alias: REALFORCE_3
	Appearance: 0x03c1
	Icon: input-keyboard
	Paired: no
	Trusted: yes
	Blocked: no
	Connected: yes
	LegacyPairing: no
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
	UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
	RSSI: -45

ペアリングを実行
* エージェントからパスキーが表示されて、キーボードで入力して ENTER したらペアリングに成功した
[bluetooth]# pair F6:9D:A5:80:B7:1F
Attempting to pair with F6:9D:A5:80:B7:1F
[CHG] Device F6:9D:A5:80:B7:1F Connected: yes
[agent] Passkey: 323759
[CHG] Device F6:9D:A5:80:B7:1F Paired: yes
Pairing successful
[CHG] Device F6:9D:A5:80:B7:1F Modalias: usb:v08ACp0302d0001
[CHG] Device F6:9D:A5:80:B7:1F ServicesResolved: yes

キーボードを信頼する
[REALFORCE_3]# trust F6:9D:A5:80:B7:1F
Changing F6:9D:A5:80:B7:1F trust succeeded

契約書の確認

先日 の業務委託案件の契約書が届いたので内容を確認した。

これまで クラウドサイン でしか契約したことがなくて、紙の契約書で契約を締結するのは初めての挑戦でもある。レターパック を使って郵送するのがお作法？といったところから調べてた。明後日から働き始める。フルリモートなので物理的な職場は変わらないけど、新しい職場は緊張するな。うまく入っていけるやろか。フルリモートの経験もだいぶたまってきたし、体調も万全だし、憂うことは何もないはず。いまの状況は純粋に私ががんばるだけだ。

4時に寝て8時に起きた。夜に資料作りに集中していたので家に帰ってきたのが3時頃で、くつろいだりアニメみたりしてから寝た。遅くに帰ってきてもすぐに寝るわけじゃなくて、だらだらして実際に寝るまで1-2時間はかかる。こういうところ、生活が堕落していて改善していくべきなのかもしれない。良かったこととして、ウォーキングのせいか、夜はよく眠れた。

みんなの Python 勉強会の資料作り

昨日の続き。一晩寝てから最後の仕上げをした。時間を置く、とくに一度寝てから資料を洗練させると改善点があちこち出てきてより良いものになっていく気がする。午前中に主催者に連絡したものの、午後になってから思い付いたことをちょくちょく修正したりもした。オンラインの資料だと、先方に連絡した後でも微修正できるところがよい。業務の資料だとさらに2-3日かけて洗練させていくけど、勉強会の資料だからこれでいいかな。タイトルはすごく気に入っているというわけではないけど「本と学びの段階」とした。ひとまず完成したので自分のやりたいことに取り組める。

神戸市長選

神戸市は衆議院選挙とは別に市長選挙も一緒にあった。神戸市長選 によると、投票率は53.79％で439,749 (67.7%)の得票を得た現職の市長が完勝した。3回目の当選になるらしい。私が神戸に戻ってきてから初めての市長選挙だった。起業してから手続きなどで行政が身近になったことから関心をもつようになってきた。自分ごとで考えるというのか、どんなものでも身近なことは関心をもつのかもしれない。

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

9.2 線形化可能性を読んだ。

線形化可能性 とは、データのコピーが1つしかなく、そのデータに対する操作がすべてアトミックであるかのようにシステムにみせることを指す。古くなったキャッシュやレプリカからの値ではないことを保証する、最新性の保証（recency guarantee） と言える。トランザクションの章に出てきた 直列化可能性 とはまったく異なる。直列化可能性が保証するのは、複数のトランザクションが何らかの順序で実行された場合に同じ結果になることを保証するもの。

あと「役に立たない CAP 定理」というコラムもおもしろい。CAP 定理とは次の3つはすべて成り立たず、2つを選択することを強いる。

• 一貫性（Consistency）
• 可用性（Availability）
• 分断耐性（Partition tolerance）

CAP 定理は歴史的にデータベースのトランザクションのトレードオフについての議論の出発点として引用され、有名な定理ではあるが、分散データベースの研究者の中では1970年代から知られていたことであったらしい。そして、ネットワークを介した分散システムは、分断耐性が必須 (ネットワークが切断しないことはないから) であることから一貫性か可用性のどちらかを選択するしかない。ここで一貫性とは線形化可能なシステムを実装することだが、これはパフォーマンスのデメリットが大きい。そのため、現代の多くの分散データベースは線形化可能性を提供しないことを選択しており、結果として可用性と分断耐性を選択することになっている。したがって、CAP 定理から議論を始めることは無意味であると言う。

0時に寝て6時半に起きた。久しぶりに勉強会でたくさん話したせいか、疲れて抜け殻になってた。昨日もよく眠れた。今日は調整作業が多かったので集中力を欠いてチケットの業務は進められなかった。

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

第Ⅱ部の最後の章である9章の一貫性と合意を読み始めた。この章も内容は難しそう。9.1 まで読み終えた。時間をかけて1節ずつ読んでいく。

間違っているかもしれなくても動き続ける方が良いのか、それとも正しくあるべく停止してしまう方が良いのか？

―― Jay Kreps, “A Few Notes on Kafka and Jepsen” （ 2013 ）

冒頭の格言で kafka というキーワードが気になったので原文を探して (deepl で翻訳して) 読んでみた。一般論で考えたらこの問いの答えは停止してしまう方を選択するように私は考えてしまったが、原文の記事によると、この答えはアプリケーションに依るという。ダウンタイム=データの損失という特性のアプリケーションであれば、間違っている可能性があってもすぐに復旧して動かした方がよいという場合もあると言っている。kafka はどちらかと言えば、間違っていても動き続ける方のシステムに分類されると思う。メッセージの到達保証も At Least Once だし。

もう1点、意識しておかないといけないのはレプリケーションを行うデータベースの大半は 結果整合性（eventual consistency） であること。私は本書を読むまで、結果整合性をスケーラビリティやスループットの高い分散システムのキーバリューストアの特性だと考えていたが、RDB であってもレプリケーションはリアルタイムに行われるわけではなく、ネットワークという遅延の上限が保証されないインフラの上に構築されたものである以上、結果整合性で同期される。レプリケーションをしないデータベースシステム以外はすべて結果整合性の特性があると考えて設計や開発をする必要がある。

PMBOK ガイド第7版

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準 を購入して届いた。たぶんいつか電子版も出ると思うけど、現時点では紙の本しかなさそう。ぱらぱらとめくりながら中身を眺めているとそんなに文字がびっしり書いてあるような本ではないので読むのはそんなに大変ではなさそうな印象を受けた。索引で知りたいキーワードを探しながらその箇所を拾い読みしたりしてた。またがっつり読み込んでまとめていきたい。

選考面談の最終決定

先日受けた 選考面談 で2社ともオファーをいただいた。感謝。自分の中では決まっていたが、顧問さんにも双方の案件の概要を話してアドバイスをもらった。その結果、私の意思と顧問さんのアドバイスも一致した。何の憂いもなく Java の開発案件の方を選択した。11月上旬から働き始める予定。3ヶ月ほど課題管理の調査・研究みたいなことをやっていたけど、いつまでもやれるほど財務に余裕がないので普通に働きながら自社のプロダクト開発も並行してやっていく。以前は2社のお仕事を引き受けて他のことをやる余裕がなくなってしまっていただけど、その失敗を教訓に今回は1社の仕事だけを専念しつつ、自社の仕事も少しずつ進めていきたい。

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回は集中的にやっていきたい。