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