0時に寝て4時に起きて6時半に起きた。今回のスプリントは1つの機能拡張のチケットに専念していてとても疲れた。
オフィスの近くに 珠しっぴん という坦々麺専門店ができているのに気付いた。半年ぐらい前にオープンしたらしい。あまり通らない場所だったせいか、全然気付いてなくて試しに入ってみたら私の好みの味でとてもおいしかった。食わず嫌いだったのか何なのか、昨年ぐらいまで担々麺はほとんど食べたことなかったんだけど、近所においしい担々麺のお店がいくつかできて、担々麺そのものも好きになってきた。新しい担々麺のお店をみかけるととりあえず入ってみるようになった。
0時半に寝て6時半に起きた。
いまお手伝いしているお仕事はスクラム開発をしている。課題管理システムに backlog を使っている。アリエルを退職後、この10年、私より課題管理システムを使いこなす開発者をみたことがない。0-9段階で言うと、師範代として私のレベルが8だとすると、他のメンバーは0から2ぐらいのレベルしかない。このぐらいの差がある。0というのはほとんど使っていないという意味。情報共有とは、メンバー全員がいつでもどこでも同じ情報を取得できる仕組みを確立した上で、情報の提供側ではなく、その情報を必要とする受け手が常に最新の情報を取得し続ける運用ができて初めて成り立つ。情報共有を成功させるには受け手の意識の問題が大きい。まずメンバー全員がやっていない時点で情報共有の価値が大きく毀損する上に、受け手が自律的に検索して最新の情報を取得するようにならなけば実務において生産性を向上させることにもつながらない。
役に立つ情報がないから検索しない、検索しないから役に立つ情報を書かないは表裏一体だ。まず役に立つ情報を溜め、受け手が検索して情報収集するようになり、検索の精度をあげるためにカテゴリやタグでラベリングし、業務に活かすために最新情報を更新するようになる。これをチーム全員でやるようになるのは一朝一夕ではできない。
そのため、私は課題管理システムの運用に関して特異な開発者である (言うてもアリエルなら普通) という前置きをした上で、チームの開発者も非開発者も課題管理システムをうまく使えていない。私が課題管理システムをどう使っているのかをみて、開発者が真似して同じように使い始める。そして、非開発者向けにはどう使えばよいかというプラクティスを機をみて提案したり啓蒙したりしている。これは半年から1年かかる作業だと見積もっている。というのは、私が半年ぐらい働いて実践的な課題管理システムの使い方をみせないと多くの人は学べない。半年ぐらい経って、普段私がやっている価値はどういうものかを実際の実務で理解した後、模倣者がやり始めて慣れてくるのに半年ぐらいはかかる。お手本をみせるのに半年、模倣するのに半年で1年かかる。いろんなチームを指導してきたのでチームがどのような学習曲線を辿るかは概ね推測がつく。これをコンテンツにしてビジネスしようといまは考えているので、こういう実践的な機会にコンテンツとしてのノウハウも溜めていこうと考えている。
実家からみかんが送られてきた。実家で作っているみかんなのかな？なんか微妙に腐り始めようとしている雰囲気もある。お正月に帰ったときから実家に置いてあったやつだろうと思う。段ボール箱の空きスペースを埋めるために入ってた 「りんちょこ」 というお菓子を初めてみた。冬季限定らしい。軽く食べてみると思いの外おいしい。えびせんべいをチョコレートでコーティングしていてチョコフレークの食感に近い。チョコフレークが好きな人にはうけると思う。お土産にもよさそう。
オフィスの郵便受けに KOBE SALON S という会員制バーのチラシが入っていた。新規会員を募集しているらしい。個人だったら全く興味はないけど、経営していると接待する機会がたまにある。前に顧問さんに経営コンサルティングを受けたときに交際費が少な過ぎるという指摘を受けた。交際費は5年後10年後のお仕事をとるための先行投資もしくは調査費用のようなものだという。そこで今期は交際費の予算に30万円を見積もっているが、現時点で46,971円しか使っていない。4月までにあと2-3件は飲みに行くあてはあるけど、このままいくと30万円は消化できない。コロナ禍というのもあるけど、何もしないと私は交際費を使わないので積極的に使っていく仕組みを作らないといけない。その一環として会員制バーは接待にいいかもしれない。すぐ退会するかもしれないけど、チラシをみた縁で入会してみる。
1時前後に寝て6時に起きた。前日から母が泊まっていて、母は5時ぐらい起きて作業し始めるので必然的に朝起こされる。部屋を掃除してくれたのできれいになった。
今週もお仕事に忙しくてあまりストレッチもウォーキングはできなかったものの、前週から中殿筋 (ちゅうでんきん) の張りはずっと残っていて、今日もトレーナーさんによく伸ばしてもらったものの張りが強いなと言う印象がある。今日の開脚幅は開始前168cmで、ストレッチ後169.5cmだった。前週とほぼ同じで現状維持ちょっとよくなったぐらいかな。ボールを使った中殿筋のストレッチが気持ちよくて疲れたときによくやっているけど、やっぱり1人でやるストレッチには限界があって、誰かに押してもらったり伸ばしてもらったりする方がよく効く。
親族が来ているので観光案内してきた。うちの会社のオフィスなども紹介した。三ノ宮・元町でショッピングして、南京町で豚まんや小籠包を買い食いしてきた。お昼は 饂飩の四國 という老舗のうどん屋さんに入った。前からお店は知っていて、いつか入りたいなと思いつつ、やや価格帯も高いのでうどんだとちょっと高いかな？とも思っていたけど、今日初めて入ってみて食べたらおいしかったので価格は妥当と言える。私はおろし醤油焼きなすうどんを食べた。コシがあって長い麺はそれだけでもおいしかった。天ぷらが豪華だったので、接待などで天ざるや天丼をお勧めするのもよさそう。
住んでいるところに一番近いレンタカーに オリックスレンタカー がある。前に一度借りたことがあって、そのときは普通にお店に行って明日借りたいと言えば予約できた。今日も同じノリで明日借りたいと言ったら予約が埋まってますと返された。仕方ないと思って次に近いトヨタレンタカーで尋ねてみたけど、同様に予約が埋まっていますと返された。ネットで探すかなぁと思って、試しにオリックスレンタカーのアカウント作成して、予約検索してみたらちょうど探していたコンパクトサイズで予約できた。ほんの1時間前は予約で埋まっていると店員さんが言っていたのに、、、と思い返しながらいくつかのケースを考察した。
昨日のメタ認知が暴走するではないけど、メタ認知を働かせるといろんなケースが出てくる。明日お店に行ってちゃんと配車されることを期待する。
3時に寝て8時半に起きた。夜眠れなくて、野菜サラダに目玉焼きをのせて食べたり、お茶をわかしてボトルに入れ替えたりしてた。休日だと時間に余裕があるせいか、空き時間に自炊してなにか作ることが多い。
朝ご飯は野菜サラダと納豆を、お昼ご飯は豚肉としめじと2回目の豆苗を炒めたものを目玉焼きでとじたものを食べた。豆苗のパッケージに食べた後の根を水に浸しておけばまた生えてくるとあったので試しにやってみた。キッチンという日当たりのよくない場所で育てたせいか、薄い緑色の苗が生えてきた。
水に浸して2日目 水に浸して6日目
今回は適当に育てた。再生栽培のコツ を読んで次はもうちょっとちゃんと育ててみよう。
6章パーティショニングを読んだ。昔からパーティショニングとシャーディングの違いはなんだろう？と漠然と思っていた。パーティションの設計 を読むと、3つのパーティション分割があげられている。
パーティショニングは大規模なデータセットをデータ分割するための手法または概念として広い意味をもって使われるように読める。一方でシャーディングと呼ばれるものは水平パーティショニングのことを指している。いま分散データベースで一般的に使われている仕組みがそうなのかもしれない。本書では水平・垂直のパーティショニングの定義は行われていないが、次の説明が出てくる。おそらく主に水平パーティショニングを意図しているのではないかと思う。まとめはこんな感じ。
用語の混乱
ここで パーティション と呼んでいるものは、 MongoDB 、 Elasticsearch 、 SolrCloud では シャード と呼ばれています。これは HBase では リージョン 、 Bigtable では タブレット 、Cassandra や Riak では vnode 、 Couchbase では vBucket と呼ばれています。とはいえ最も確立されている用語は パーティショニング なので、本書ではこの呼び方を使っていきます。
パーティショニングも普通に開発をしていたらデータベースの設計で必要になるので身近な概念と言える。だいたいは知っている内容ではあったけど、パーティショニングとセカンダリインデックスの仕組みとか考えたことがなかった。Cassandra ではセカンダリインデックスをうまく設計しないとパフォーマンスに影響を与えることからあまり使われない傾向にあると思う。
大規模なデータセットを小さな部分集合にデータ分割することをパーティショニングと呼ぶ。パーティショニングが必要になるのは、単一のマシンで保存や処理をするのが現実的ではないほどのデータがある場合になる。パーティショニングが目標とするのは、データやクエリの負荷を複数のマシン間で均等に分配し、ホットスポット（不均衡に高い負荷がかかるノード）が生じないようにすること。パーティショニングが均等になっておらず、一部のパーティションが他に比べて多くのデータやクエリを受け持っているような状態は スキュー（skew） と呼ばれる。そのためには、データに適したパーティショニングのスキームを選択し、クラスタへのノードの追加やクラスタからのノードの削除が生じたときにパーティション群をリバランシングする。
パーティショニングのアプローチとして主に2つがある。
- キーの範囲によるパーティショニング
- キーはソートされ、1つのパーティションには何らかの最小値と最大値の間にあるすべてのキーが保存される
- キーをソートすることで、範囲に対するクエリが効率的に処理できるというメリットがある
- アプリケーションが頻繁にアクセスするキーがソート順の中で近接していると、ホットスポットが生じるリスクがある
- 通常このアプローチでは、パーティションのリバランシングはパーティションが大きくなりすぎたときにその範囲を2つに分割することによって動的に行われる
- ハッシュパーティショニング
- ハッシュ関数がそれぞれのキーに対して適用され、1つのパーティションにはハッシュの一定の範囲を保存される
- この方法ではキーの順序が失われるので範囲に対するクエリは非効率になるが、負荷分散より均等にしやすい
- ハッシュによってパーティショニングを行う場合は、事前に固定数のパーティションを作成し、各ノードに複数のパーティションを割り当てておき、ノードの追加や削除が行われた場合にはパーティションをそのままあるノードから他のノードに移動させるのが一般的となる。また、動的パーティショニングも利用できる
ハイブリッドなアプローチを取ることもできる。たとえば複合キーを使い、キーの一部でパーティションを決め、他の部分でソート順を決めるといったやり方がある。Cassandra のプライマリーキーはこのアプローチを採用している。また、セカンダリインデックスもパーティショニングする方法が2つある。
- ドキュメントによってパーティショニングされたインデックス（ローカルインデックス）
- セカンダリインデックスをプライマリキー及び値と同じパーティションに保存する
- 書き込みの際に更新しなければならないパーティションが1つですむ
- セカンダリインデックスの読み取りにはすべてのパーティションに対する スキャッタ/ギャザー が必要となる
- 語によってパーティショニングされたインデックス（グローバルインデックス）
- セカンダリインデックスはインデックスが張られた値を使って独立にパーティショニングされる
- セカンダリインデックスのエントリには、プライマリキーのあらゆるパーティションのレコード群が含まれる
- ドキュメントが書き込まれる際には、セカンダリインデックスの複数のパーティションを更新しなければならない
- 読み取りは単一のパーティションだけで処理できる
クエリを適切なパーティションにルーティングする手法は、データベースに限った話題ではなく、サービスディスカバリ と呼ばれる一般的な問題である。有名な OSS として ZooKeeper がある。これにはシンプルなパーティションを認識するロードバランシングから、洗練された並列クエリ実行エンジンまで様々である。すべてのパーティションは、ほぼ独立に動作できるように設計されている。パーティショニングされたデータベースが複数のマシンにまでスケールできるのはそのおかげである。