Posts for: #2021/11

Kubernetes 使い始めの雑感

1時に寝て7時に起きた。夜にウォーキングし始めてからよく眠れるようになった気がする。

udemy: Kubernetes入門

昨日 の続き。今日はセクション6から最後まで。CI/CD のセクションだけスキップして、他は一通り目を通した。

セクション6 Kubernetes実践

1つずつ書くのは大変だけど、数をこなして徐々に覚えていけばよい。手で書くのもよいが、別のやり方としてクライアント側で dry run すると、設定のひな型を作ってくれるのでそれに必要な設定を足すのもよい。

$ kubectl create deploy mysql --image=mysql:5.7 --dry-run=client -o yaml
$ kubectl exec -n database -it mysql-787f86d65c-nflxx -- mysql -uroot -ppassword

データベースとアプリケーションを異なる namespace にデプロイして、それらが通信できるような設定を行う。基本的には --dry-run=client でひな型を作りつつ、必要な設定を追加していくやり方が簡単そうにみえた。とはいえ、実際に設定していくときはどういう設定を追加するとどういう振る舞いになるかを調べながら作業すると思うのでこんな簡単にはできないとは思う。次のようなアプリケーションをデプロイする一覧の流れを理解できた。

  1. namespace 作成
  2. Deployment 作成
  3. ConfigMap 作成
  4. Secret 作成
  5. Deployment, ConfigMap, Secret 適用
  6. Service 適用
  7. port-forward でローカルからアクセス
  8. (作成したリソースをすべて削除)

セクション7 KubernetesのDebug

基本は pod のステータスを確認しながら問題があれば、その箇所を追いかけていって原因を調査する。

$ kubectl get pod -A
$ kubectl get pod -A --selector run=nginx

k8s 上で実行しているアプリケーションの依存先へ接続できない場合は Service の確認が必要となる。kubectl の get, describe, logs などのサブコマンドをあれこれみながらエラーの原因を把握して、yaml の設定を変更していく。k8s のアーキテクチャとコマンドを覚えていないとなかなか難しそう。

とりあえず動かした後にまとめて全部削除できるのがテストやデバッグに便利そう。

$ kubectl delete -f .

もしくは開発用に独自の namespace を作成して、あとで丸ごと namespace を削除するのでもよさそう。

$ kubectl delete ns mynamespace

k8s の調査

業務のアプリケーションを minikube で作ったローカル k8s クラスターで動かしてみた。ローカルの開発環境の構築方法をメンテナンスして、自分でも一通り k8s の yaml を書いて、デプロイして、振る舞いを確認したりしていた。最初なのでおもしろい。自分で一通りやってみて、k8s が難しいとみんなが言っているのは k8s クラスターを自前で構築するのが難しいのだとようやく理解できた。k8s クラスターがすでにある状態なら kubectl の使い方を覚えるだけで全く難しくない。GKE や EKS を使って運用するなら k8s の運用コストは大したことがないと理解できた。k8s クラスター向けの yaml はたくさん書かないといけないけど、どうせ ECS や EC2 でやっていても CDK や Terraform などのインフラ設定を書くのは同じなのでそこはあまり差がない。k8s はコンテナオーケストレーションをやってくれるメリットが大きいので minikube と EKS の環境の差異があまり問題にならないようなアプリケーション開発であれば、普通に使っていって問題ないように思えた。ローカルで環境作るのが大変なんじゃないかという先入観があったけど、全然そんなことはなかった。コンテナのイメージをビルドしないといけないのが追加のコストかな。

普通の休日の翌日

5時に寝て10時に起きた。昨日は夕方に2-3時間寝てたのでその分、夜に調べものをしていた。休みたい気持ちもあるけど、調べるものが多過ぎて全然時間が足りない。

bizpy 勉強会の資料作り

昨日 の続き。昨日サンプルコードを実装したので、その設定や要点を 資料 に作成した。現時点で Python で Slack のインテグレーションをやってみる勉強会 #2 の参加者は10人。連続シリーズは回を重ねるごとに減っていくものなのでこんなもんかな。あともう1回やったら終わりにする。

udemy: Kubernetes入門

友だちから udemy の k8s のコースがよいと聞いたんだけど、そのコースはいまは提供されていなくて、せっかくなので適当に検索してヒットした Kubernetes入門 を受講することに決めた。本当は英語の本格的なコースを受講した方がよいのだろうけど、余裕のあるときはそれでいいけど、いま数日で概要を把握して使えるようにしたいので日本語のコースにしてみた。

昨日インストールした minikube のクラスターを使って「Kubernetes入門」のセクション1からセクション5までやった。だいたい半分ぐらい。所感としては、全く何も知らない人には要点をかいつまんで教えてくれるのと、最初に覚えるとよい基本的な CLI のコマンドとその振る舞いや設定を紹介してくれるのでよかった。初めて k8s に挑戦する自分にとってはちょうどよいレベル感だった。全体像の概念を捉えてコンテキストに沿って順番にハンズオン形式で学習していくスタイル。nakamasato/kubernetes-basics を使って自分でも CLI でコマンドを打ちながら進めてみた。yaml ファイルを定義するのもこれはこれで面倒だけど、この辺は慣れの問題かな?とも思う。いくつか学んだことを整理しておく。

セクション1 Introduction

k8s には2つのコンポーネントがあり、これを k8s クラスターと呼んでいる。

  • Control Plane (API サーバー)
  • 複数の Worker (Kubelet)

yaml で設定する Desired State (理想状態) と呼ばれる設定が登録されると、Control Plane の API サーバーと Worker の kubelet が通信してそれを実現しようとする。pod とは k8s のデプロイの最小単位となる。コンテナ、ポート、レプリカ数などを設定する。pod をそれぞれの Worker にデプロイしたり、Worker がダウンしたときに別の Worker で起動させたりする。

セクション2 Kubernets 概要

k8s はコンテナ化したアプリケーションのデプロイ、スケーリング、管理を行うためのオープンソースのコンテナオーケストレーションシステムである。

  • コンテナ
    • 独立した環境でアプリケーションを実行する仕組み
    • コンテナの実態はプロセス
    • Kernel Namespaces を利用し、プロセスID、ネットワークインターフェース、リソースなどを分離してコンテナ間で干渉しない
    • ホストマシンへの依存度を最小化してアプリケーションをどこでも実行可能にする
      • 従来のやり方の最大の違いはライブラリがホストマシンにインストールされるのではなく、コンテナの内部にインストールされる
  • オーケストレーション
    • デプロイ、スケーリング、管理などの仕組み

1つのアプリケーションは複数のマシン上で動かすことで可用性を高めたいが、コンテナを動かすために考えることが増えていくと管理コストも増えていく。コンテナオーケストレーション機能により次のようなシステム管理者が行っていたことが自動化される。

  • デプロイメント
  • スケジューリング
  • オートスケーリング
    • 負荷に応じてコンテナ数やマシン数を増減させる
  • ネットワーク
  • リソースマネジメント
  • セキュリティ
    • ネットワークポリシーやリソースの権限定義

k8s クラスターの構造は次になる。

  • Control Plane
    • api: kubelet と通信するサーバー
    • etcd: 設定などを格納するキーバリューストア
    • shed: kube スケジューラー
    • c-m: コントロールマネージャー
    • c-c-m: クラウドプロバイダと api 連携する
      • ローカルで使うときは必要ない
  • Worker ノードはコンテナランタイムをいインストールしておく必要がある
    • kubelet は Control Plane と通信するためのエージェントとして動作する

一番需要なこととして、k8s は理想状態と現実状態を比較して、理想状態に近づけようとする。app.yaml の理想状態を kubectl を用いて api サーバーを介して etcd に格納する。現実状態は kubelet から api サーバーを介して etcd に格納される。c-m は理想状態と現実状態のチェックを行い、異なっていれば理想状態に近づけることをしていく。

セクション4 kubectl

minikube で最初に起動しているのは Control Plane を起動していることが理解できた。

$ minikube start
$ kubectl config current-context
minikube

同時に ~/.kube/config に kubectl の設定も追加される。minikube という名前でクラスター、ユーザー、コンテキストが設定される。

リソース一覧の確認。

$ kubectl api-resources

出力フォーマットも様々。例えば、デフォルトの表示は次になる。

$ kubectl get node
NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   7m21s   v1.22.2

$ kubectl get node -o wide
NAME       STATUS   ROLES                  AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
minikube   Ready    control-plane,master   8m38s   v1.22.2   192.168.49.2   <none>        Ubuntu 20.04.2 LTS   5.11.0-38-generic   docker://20.10.8

より詳細な情報をそれぞれのフォーマットで表示する。

$ kubectl get node -o json
$ kubectl get node -o yaml

namespace を確認する。

$ kubectl get namespace
NAME              STATUS   AGE
default           Active   10m
kube-node-lease   Active   10m
kube-public       Active   10m
kube-system       Active   10m

namespace を指定して pod 一覧を取得する。

$ kubectl get pod --namespace kube-system
NAME                               READY   STATUS    RESTARTS      AGE
coredns-78fcd69978-qxqbn           1/1     Running   0             11m
etcd-minikube                      1/1     Running   0             11m
kube-apiserver-minikube            1/1     Running   0             11m
kube-controller-manager-minikube   1/1     Running   0             11m
kube-proxy-g55hg                   1/1     Running   0             11m
kube-scheduler-minikube            1/1     Running   0             11m
storage-provisioner                1/1     Running   1 (10m ago)   11m

グローバルな CLI のオプションを確認する。

$ kubectl options

ノードの詳細を表示する。

$ kubectl describe node

describe は名前の接頭辞を指定できるので namespace ならこんな感じに実行できる。

$ kubectl describe namespace kube-

セクション5 Kubernetes リソース

pod とは k8s 上のデプロイの最小単位である。

  • 1つまたは複数のコンテナをもつ
  • ネットワークやストレージを共有リソースとしてもつ
  • コンテナの実行方法に関する仕様をもつ

pod が使えなくなった場合に他のノードにデプロイされることもある。1つのアプリケーションを複数の pod でデプロイすることが多い。なるべく複数のアプリケーションを1つの pod に入れない。個別の pod を直接操作しない。

共有コンテキスト

  • 同一 pod 内のコンテナは同じストレージにアクセスできる
  • 同一 pod 内のコンテナは ip アドレスとポートを含むネットワーク名前空間を共有する

k8s オブジェクト

  • クラスタの状態を表現する
  • 2つのフィールドをもつ
    • spec: 理想状態 (desired status)
    • status: 現実状態 (current status)

pod の作成は k8s オブジェクトを作成している。オブジェクト作成時の必須フィールドが4つある。

  • apiVersion
  • kind
  • metadata
  • spec

namespace は同一クラスター上で複数の仮想クラスターの動作をサポートする。

  • 仮想クラスターとは、物理的には同じマシンで動いているかもしれないが、仮想的に環境を分離している
    • 1つのクラスターを論理的にわける
    • チームや部署ごとにわけて使い分けたりすることも多い

namespace を使うメリットは次になる。

  • pod やコンテナのリソースの範囲設定
  • namespace 全体の総リソース制限
  • 権限管理

初期の namespace として4つあるが、初心者は最初の2つだけをまず覚えておく。

  • default:
  • kube-system:
  • kube-public:
  • kube-node-lease

namespace と cluster の違い。

  • Namespace-scoped リソース
    • namespace に属しているリソース
  • Cluster-scoped リソース
    • クラスター全体で使われるもの

次のコマンドで確認できる。

$ kubectl api-resources --namespaced=true 

namespace の作成

$ kubectl create namespace my-namespace

ワークロードリソースとは複数の pod を作成・管理するためのリソース。ワークロードリソースは pod テンプレートを使って pod を作成する。

  • ReplicaSet
    • 常に指定したレプリカ数の pod を保つ
  • Deployment
    • ローリングアップデートやロールバックなどのアップデート機能を提供
    • ReplicaSet のロールアウト
    • 不安定な場合の前のバージョンへロールバック
    • 使用頻度が高い
      • ほとんどのアプリケーションは Deployment で管理
  • Secret
    • 機密情報を保存・管理し、Pod から参照可能
    • 主な使用方法としてコンテナの環境変数の設定
      • アプリケーションの DB のパスワードなどに使う
  • Service
    • pod の集合を抽象化して公開する
      • pod の集合に対する DNS 名
      • pod の集合に対する負荷分散

普通の休日

0時に寝て5時半に起きたが、休日だからゆっくりするかと思って二度寝して8時に起きた。知人のタイムラインで紹介されていていい言葉だなと思ったので書いておく。日記があるとこういう流れていくちょっとしたことを書く場所にもなるな。コミュニティ活動の本質はこれなんじゃないかという気もする。

自分にまったく利益をもたらさない人間を、どう扱うかでその人がどんな人間かがはっきりわかる

サミュエル・ジョンソン

ストレッチ

今週もジョギングの代わりにウォーキングをしてた。ジョギングやると筋肉痛や疲労から他の日を休みがちになるけど、ウォーキングならジョギングよりは継続しやすい。今週は4-5日ほど歩いた。ただストレッチはさぼってて2日しかできなかった。ウォーキングのせいかわからないけど、右足太もも後ろの筋が張るようになった。ストレッチを始めてから日々の運動や生活の変化と関節や筋肉の張りが変化するのも意識するようにもなってきた。今日の開脚幅は開始前167.5cmで、ストレッチ後168cmだった。前週よりは数値がよくなっているのでこんなもんかもしれない。

神戸のコワーキングスペースの半歩先の未来を考える

たまたまタイムラインでみかけたので 神戸のコワーキングスペースの半歩先の未来を考える を視聴していた。私はシェアオフィスとコワーキングスペースが併設された場所で働いているのでテーマには関心がある。途中からだけど、13時半から15時までみていた。

第一部はコワーキングスペースの運営者が登壇して、どちらかというそれぞれの運営者がやっていることの、宣伝的な要素が強かったように思う。ある運営者が起業家を育てるのは大学生からでは遅くて、保育園から起業家教育をしているという話題があった。そこで何を教えているかというと、子どもの頃から徹底的に自己肯定感を高めるための教育をしているらしい。たまたま 自己肯定感が高い人の4大特徴が明らかに! の記事をみたら、自己肯定感が高い人は他人も肯定するという内容がある。たしかに日本/日本人の同調圧力は異質なものを拒む傾向があると考えると、自己肯定感の高低がそういった文化の背景にも現れているのかもしれないと思えた。

第二部はコワーキングスペースの利用者として、二地域居住シェアハウスプロジェクトの研究/実践をしている佐藤さんと、メディアアートをされている 浅井宣通 さんが登壇していた。佐藤さんが冒頭でコワーキングスペースにはびっくりするほどすごい人がいるみたいな話しをした後で、浅井さんが登場するといった流れが偶然できてて、ほんとだ、これはすごいとなったw 浅井さんはメディアアートを言葉で説明しても伝わりにくいので動画でみてもらうようにしていると話されていた。私もみてこれはすごい人だとすぐに理解できた。私が興味をもつ作品だと 攻殻機動隊 新劇場版Virtual Reality Diver の Creative Director も務められたらしい。企業やイベントの PR のための映像で浅井さんが手伝っている作品はいくつもあるそうだ。

浅井さんは東京を脱出したいという想いがずっとあって、コロナでリモートワークが普通になり、奥さんの実家の須磨に引っ越してきたらしい。ただ自身は神戸にはほとんど知り合いがいない状態でコワーキングスペースを利用しているうちに、人を紹介してもらって人脈を形成することができたという。東京は大半が地方から出てきた人たちの集まりなので必然として孤立しており、競争関係になってしまうという。神戸の人たちは地元で育ってそのつながりが強いという違いを感じているらしい。地元の人なので協力の関係を築きやすい。コワーキングスペースがその触媒になっていると話されていた。人がつながるには、場所や触媒が必要でコミュニティマネージャーもそういった役割を担っていて大事だという。

多様性は大事だが、多様性だけでも人のつながりができない。同じ分野だとライバル関係になってしまったりする。そこで対話の深さが重要だと話されていた。同じ分野であってもお互いが対話を通して理解を深めると、共通項があったり、細かい得意分野が違ったりもする。デザイナー同士がかぶってしまうと、よく競争の関係になってしまうし、全然違う人と話しても話が噛みあわなくて仕事で苦労することもあったという話があった。それで対話の深さが大事ということに気付いたといった話だった。もう1点、おもしろかった話が地元の人は土地への感情として、この場所・土地が好きだという共通項があるので協力の関係を築きやすいのではないかと。東京は多くの人が生まれ育った土地ではないのでそういった感情は抱きにくいが、神戸っ子という言葉があるように神戸の人たちにはそういった土地に根ざした愛着があり、それを媒介につながるのも美しいといったことを話されていた。

第三部はコワーキングスペースを支える人たちとして、カフーツ の伊藤さん、ANCHOR KOBE の立ち上げ に関わった神戸市のイノベーション専門官の松山さん、fixU というサービスを提供している山岡さんが登壇していた。

私がもっとも興味深かったのは伊藤さんの話しだったのでそれをまとめておく。コワーキングスペースはただ作業する場所ではなく、課題を解決したい人がいて、それを手伝いたいという人がつながることで価値が生まれるという。長い間、コワーキングスペースに関わってきたことから経験が積み重なってわかってきたことがあると話されていた。「コミュニティはどうやって作るんですか?」という質問に答えるのは難しいものの、その取っ掛かりとして、まず課題をみえる化するのが大事だという話しをされていた。イベントなどで課題を表明して、多くの人たちに知ってもらうことで、その課題の解決に興味をもつ人たちが集まってきて、それが協調となり、コミュニティへとつながっていくという。Facebook 社が Meta 社に社名変更して、Microsoft もそれに追従し、メタバースの話題が盛り上がっている。ビッグワードに流されるつもりはないが、コロナによりオンラインでできることの幅が広いことを、仕事はオンラインでよいと多くの人たちは気付いた。じゃあ人と人との関わりがどんな価値をもつのか、コロナが落ち着いてくる時期 (この先1-2年) でそういう方法論も新たに出てくるんじゃないかとも話されていた。

Slack apps の調査

次回の bizpy 勉強会向けに 新機能、アプリのホーム・ヴューを活用しよう🏡 を読んで実際に bolt-python やってみた。UI の設定は JSON で記述できるようになっていて、Block Kit Builder でぽちぽちやるとどんな JSON を書けばよいかのサンプルのペイロードを確認できる。これらの UI に対して操作すると、プログラミングの用語で言えば、すべてイベントが発生してリクエストが届くような仕組みになっている。bolt のコード上ではそれぞれ eventactionview という名前が付いたイベントを扱うことで任意のモーダル画面を表示したり、そのフォームのユーザー入力を取得したりできる。一通りサンプルコードはできた。あとは簡単に資料をまとめるだけ。

調べものだらけ

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 の調査

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

新しい職場で働き始め

0時に寝て6時半に起きた。朝活の日以外に6時に起きるのは難しいけど、だいたい6-7時の間には起きているような気がする。とはいえ、休日は8時に起きたりもしてたけど。10月25日 から生活リズムの移行を促してちょっとずつ近づいている気はする。

働き始め

今日から新しい職場で働き始め。3ヶ月ほど自社のお仕事をしていたが、ずっとやっていると会社が倒産するので出稼ぎに行くことに決めた。まずは開発の定例会議に出てみた。最初なんで話していることがなんもわからん。3ヶ月ぐらいは業務のキャッチアップに集中する。intellij idea のコードフォーマッターで開発しているそうなので intellij idea を使うことにした。eclipse をやめて vscode に移行したいとは思っていたが、コードフォーマッターの問題は厄介なので仕方ない。コミュニティエディションを使う。

RabbitMQ のチュートリアル を1から5までやった。チュートリアルのサンプルコードはそのままだけど maven でビルドできるようにして https://github.com/t2y/rabbitmq-sample に置いた。今日のところはチュートリアルに書いてあることの振る舞いなどを確認していた。なんか調査や検証するときにまた使うと思う。

ASUS ROG Zephyrus G15 GA503QR

ASUS ROG Zephyrus G15 GA503QR

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

ワイヤレス REALFORCE

ワイヤレス REALFORCE

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

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

9.3 順序の保証を読んだ。

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

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

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

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

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

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

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

REALFORCE のワイヤレスモデル

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

先週から 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 定理から議論を始めることは無意味であると言う。