30分で論文流し読みシリーズ2: 「U-root: A Go-based, firmware embeddable root file system with on-demand compilation」
30分で論文流し読みシリーズ1: 「Schedule Processes, not VCPUs」
最近思うところあって意識的に論文を読んでみようかなと思うようになりました。幸いにも研究者およびその卵である友人がいたので、いろいろ勧めてもらったものを読むことにしました。それらについてさらっと読んで要約して自分なりの感想をまとめてみようかなと思ってます。
初回はSchedule Processes, not VCPUs。
実際の所要時間 一時間
概要
問題詳細
- あるvCPU上でロック取ろうとした後に当該vCPUが乗ってるpCPU上でホストの処理ないし別vCPUの処理が動いた場合、以下のような様々な問題が発生する
- vCPU Preemption
- vCPU Stacking
- CPU Fragmentation
- priority inversion
- あるvCPU上でロック取ろうとした後に当該vCPUが乗ってるpCPU上でホストの処理ないし別vCPUの処理が動いた場合、以下のような様々な問題が発生する
解決方法詳細
- 以下によってpCPU上に複数vCPUを割り当てる事態の発生を最小限に抑えることによって設定した問題の発生を最小限に抑える
- 各ゲストにweightを与える
- 各ゲストにweight(全VMのweight合計)を整数値に丸めたターゲットvCPU数を設定する
- 各ゲストにターゲットvCPUを割り当ててそれぞれpinする。ターゲットvCPU数に増減がある場合はたとえばCPU hotplugによってvCPU数を増減させる
- ゲスト数が増減するときに2に戻る
- 以下によってpCPU上に複数vCPUを割り当てる事態の発生を最小限に抑えることによって設定した問題の発生を最小限に抑える
課題
- ゲストのアプリがvCPU数の変動に対応しなくてはいけない
- vCPU数を整数値に丸める必要があるので精度がそんなによくない
感想
- 論文のタイトルと実際論文で取り組んだことが一致してないように思う
- これはそのそも解かなきゃならない問題なのか?
- IaaSであればvCPUは通常占有させる
- pCPUを複数vCPUで共有させる場合は性能をそれほど気にするほど頑張る必要はあるのか?
- ゲスト上のアプリから見てvCPU数がコロコロ変わるのってけっこう辛くない?
- 現在進行形で問題が起きていてもVMの生成/終了まで状況は改善しないのね
- ロックの問題とスケーラビリティの問題がごちゃごちゃしてる
自分ならどうする(既存研究があるとかないとかは知らない)?
- weghtはとくに設定しない。vCPU数も変動させない
- vCPUがアイドルになったらホストに通知する
- そのvCPUが乗っているpCPU上にはvCPUは一つも乗っていないとみなす
- vCPUがアイドルになるたびに上記のことをしているとオーバーヘッドが大きいのでアイドルになってから一定以上の時間が経つとvCPUを使っていない状態にするという閾値を設ける、などの凝った作りにしてもいい
- この方法であればゲストから見たvCPU数は変化しない
「HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢」に参加してきました
はじめに
表題のイベントに参加してきましたので備忘録をば。
HashiCorpの伊藤さんによる製品説明
HashiCorpの伊藤さんがHashiCorp製品について1時間くらい喋ってくれた。話した内容は覚えてる範囲では以下のこと
- terraform enterpriseの諸機能
- SaaS
- Policy as code
- 間違ったregionへのdeploy禁止
- インスタンス作りすぎ防止
- 国をまたいだ制約
- SaaSでやってるサービスをプライベートで構築するPrivate Installということもできる
- Terraform Enterpriseの秘密情報は実は裏でVaultを使って管理してる
- terraformのコードを更新してmaster branchが変更されるとterraform enterpriseが動き出してplanが自動的に動く。設定によってはそのままapplyもする。
- 30日間無料体験可
- HA, DR機能。OSS版でもできなくはないが、enterprise版では面倒くさいところを全部面倒見てくれる
- 鍵作成、暗号化、複合、電子署名、そのverification、鍵のローテンション、などなど全部できる
- vaultによる暗号化はsecretでないもの、かつ、key valueのvalue最大サイズに収まる程度の小さいもの
- Adobeの事例がある
- Nomad
- HashiCorpは日本にはオフィスが無い。社員2人でリモートでやってる
- 参加者30人くらいのうちvaultを知っている人が10人くらい、実際に使っているのは一人。
- HashiCorp製品に関する情報はgoogleで検索すればだいたい出てくる
- 製品開発はドキュメントファースト
- 勉強用の資料が充実している
質疑
自分がした質問とその回答リスト。
- Q: Vaultのdata encryption機能のusecaseは?
A: Vaultによる暗号化はsecretでないもの、かつ、key valueのvalue最大サイズに収まる程度の小さいもの。
Q: Vaultのデータを保存するにはMySQLなどを選べるようだがVault EnterpriseのHA機能やDR機能の裏にはRDBクラスタ?
A: yes
Q: vault on k8sに消極的な理由は何か
A: k8sの証明書を誰が管理するか問題がある。などなど。社としては「Vaultは他のサービスの外に」と言いたい
Q: `vault write auth/approle/loginにおけるsercret_idなど、秘密情報が端末上で丸出しになることがある。回避策はあるか
- A: ここを見るとよい
その他
- HashiCorpの箸というノベルティグッズをもらった
- 質疑が活発で非常によかった
- 伊藤さんはすべての質問を軽く打ち返してくれた。技術がわかる人なので非常によい
- HashiCorpのブログがある
「肉食の思想」を読んだ
日本と西洋の違いを食文化、とくに肉食文化の違いから解き明かそうという本です。なかなか面白い視点なので思わず「なるほどね」と思ってしまいました。
ただし筆者も述べているようにデータの裏付けが少々足りないので、「これが事実に近い」というよりも、あくまで参考情報として認識するほうがよさそうです。この傾向は後半になるにしたがって強くなってゆき、どんどん筆者の想像が種となってきたのは残念でした。
Sonyのα6400を買った
はじめに
カメラが欲しかったのでSONYのα6400を買いました。
なのでどんなOSSを使っているのかをちょっとだけ眺めてみることにしました。
最初に断っておきますが筆者は組み込み機器のことを全然知らないので、「何言ってんだこいつ、なんでこんな基本的なことも知らないんだ」と思われたかたは訂正していただけると助かります。もう一点、この文書は細かいことにこだわらずにフィーリングで読んだことのメモ書きに過ぎないのでとくに自分以外の読者への読みやすさには配慮していませんし、内容の正しさの保証もしていません。
OSSとSONY製品、およびα6400
SONY製品は他の家電製品の例にもれずにOSSをたくさん使っており、必要とあらば製品に組み込まれたOSSのソースコードを公開しています。
これは別に隠しページとかではなく、「sony open source」とかでぐぐればトップに出てきます。
α6400付属OSSのソースはここにあります。
α6400はどんなOSSを使っているのか
ソースコードの一覧は次の通りです。
compat-wireless.tar.gz linux-kernel.tar.gz qrencode.tar.gz R8168-Driver.tar.gz sony-target-dev-busybox-1.13.4-08020205.src.rpm sony-target-dev-busybox-1.13.4-08020504.src.rpm sony-target-dev-dosfstools-2.11-08020202.src.rpm sony-target-dev-dosfstools-2.11-08020502.src.rpm sony-target-dev-e2fsprogs-1.42-08020502.src.rpm sony-target-dev-gcc-gplv3-libs-4.5.1-08020202.src.rpm sony-target-dev-gcc-gplv3-libs-4.5.1-08020502.src.rpm sony-target-dev-glibc-2.11.2-08020205.src.rpm sony-target-dev-glibc-2.11.2-08020503.src.rpm sony-target-dev-hostname-3.05-08020502.src.rpm sony-target-dev-iptables-1.4.10-08020502.src.rpm sony-target-dev-libnl-3.2.22-08020502.src.rpm sony-target-dev-procps-3.2.7-08020202.src.rpm sony-target-dev-procps-3.2.7-08020502.src.rpm sony-target-dev-pump-0.8.16-08020502a.src.rpm sony-target-dev-rpm-4.4.2.3-08020502.src.rpm sony-target-dev-util-linux-ng-2.17.2-08020502.src.rpm
個々のソースについて細かく見るのではなく、どんなOSSのどのバージョンを使っているのかくらいだけを確認だけしました。興味の無いソフトについては飛ばしてます。
linux-kernel.tar.gzというのはその名の通りlinuxのカーネル(以後"linux"と表記)ですね。最近は多くの家電製品にlinuxが採用されていますが、α6400も同様なようです。ちなみにlinuxのライセンスはGPL v2なので、SONYとしては製品を買った人にしかソースを公開する義務はないのですが、誰にでも見られるようにしてくれているようです。やったぜ。カーネルバージョンは3.0.27。3.0が2011年7月に出たもので、3.0.27は2012年4月に出たものです。うーん、7年ものか、古い。伝説に聞く「組み込み系機器に積んであるソフトは古い」というのが確かめられたぞ。そういえばセキュリティパッチはどこまで当たってるんですかね。diffがでかすぎるので追ってませんが、ちゃんと当てるべきものは当たっていることを望みます。なお、そうでない場合にどうなるかというとファインダー越しにDOOMが動くようになったりします。
compat-wirelessは新しいカーネルから古いカーネル用に無線LANのドライバをバックポートしたものです。とうの昔にバックポート対象が無線LANだけにとどまらず他のドライバにも及んで名前もbackportsに改められたはずが、昔の名前で出ています。古い。ちなみにこのパッケージを展開するとcompat-wireless-3.5.4-1-brcmという名前になりました。多分Broadcomの機器を積んでいるんでしょう。
qrencodeはQRコード生成ライブラリです。α6400にはスマホからQRコードを利用して本体と接続してデータをやりとりする機能があるので、それ用だと思います。
R8168-DriverというのはRealtek社のコントローラ(いわゆるカニチップ)を積んだNICのドライバでしょう…と、ここまで書いて思ったのですが、何で(少なくとも見かけ上は)Ethernetポートが存在しない機器にNICのドライバが必要なんだろう?
その他のソフトウェアについては理由はよくわかりませんがソースがsrpmとして提供されています。ソフトウェアによっては複数バージョンが存在することもありますが、番号が大きなほうだけを気にすればいいのかしら。0802...と続く部分は単に日付とも思えないし、一体何を意味するものなのだろうか。
busyboxはlinuxの基本コマンドをシングルバイナリに詰め込んだものです。GNUツールの*-utilsなどのフルセットを持つよりもはるかに小さなサイズで最小限のことができるので組み込み機器などにおいて重宝されます。1.13.4というバージョンは2009年4月に出たものらしいです。うーん、これも古い。
dosfstoolsはFATなどのファイルシステムを操作するためのソフトウェアです。おそらくは本体に挿したSDカード上に存在するFATファイルシステムの操作をするために存在するのでしょう。
e2fsprogsはext系ファイルシステムを操作するためのソフトウェアです。おそらく本体に内蔵されているlinuxシステムのrootfsがext系ファイルシステムなのでしょう。
おわりに
噂には聞いていましたけどソフトウェアのバージョンがどれもこれも古いですね。私の慣れ親しんできたエンプラlinuxの世界でもカーネルバージョンが古い古いとよく言われますが、組み込み機器においてはさらに古いようです。別にけなしているわけではなくて、単に「ほんとにそうだったんだ」とびっくりしているだけです。いい経験になりました。
では、α6400で写真撮ってきます。
「しくみがわかるkubernetes」を読んだ
Kubernetesとはそもそも何者なのか、何のためにどういう設計思想で作られたのか、どうやって使えばいいのか、どういうしくみになっているのか、などなどについて書かれた本です。一言でいうと非常によい本でした。Kubernetesに関する良い本はたくさんありますが、私が読んだ中で下記対象読者(本文より引用)にとってこの本が最適だと思います。
Kubernetesをはじめて使う業務アプリケーション開発者 Dockerの基礎知識がある方
とにかく上記の対象読者の気持ちに寄り添って、Kubernetesの「最低限ここだけは理解しないと話にならない」という部分にだけ的を絞って最短経路で理解してもらいたい、という気持ちがにじみ出ていました*1。他のKubernetes本を見たものの難しすぎて挫折したというかたでも、この本を読んだ上でもとの本に戻ると驚くほど理解しやすくなると思います。Kubernetesを直近で使うことは無くても流行っているからちょっと調べておきたい、というかたにもよいと思います。
本書はKubernetesおよびそれを構成する個々のコンポーネントを説明するにあたって、単に機能説明をするだけにとどまらず、なぜそれが必要なのか、どういう場面でどうやって使うのか、どういうしくみになっているのか、が必ず書かれているため、非常に読みやすい、かつ、腑に落ちやすい作りになっています。初心者が抱きがちな疑問についてもちょうどいいタイミングで回答されていたりと、至れり尽くせりです。
しくみの部分については初心者用の書籍であることやページ数の都合もあり、書いてあることはあくまで概略なのですが、今後他の文書やソースコードを読むときに強い味方になってくれるでしょう*2。Kubernetesの複雑なしくみをよくぞここまで簡略化して説明できるものだと、思わず唸ってしまいました。
Kubernetesを使う上で必要な、重要な設計上の判断が必要になったときの対処方法についても本書は書いてくれています。たとえば本書においては物理的なクラスタ構成をどうするか、どのように計算リソース(CPUやメモリなど)を制御するか、などについて触れられています。これらについても決して「こうでなくてはならない」と筆者の意見を押し付けることなく、判断するための基準、および複数の選択肢を提示したうえで「自分ならこうする」という書き方をしています。こういう書き方を「はっきり書いてよ」と嫌うかたもいるとは思いますが、私はこれがよいと思います。なぜかというと、個々人によって置かれた状況は違うので、安易にその状況を知らない人(この場合は著者)がこうすべき、などと言ってもしょうがないからです。
副題に「Azureで動かしながら学ぶ」と書いてある通り、本書は演習においてMicrosoftのAzure、とくにKubernetesクラスタを容易に作成、管理できるマネージドサービス、Azure Kubernetes Engine(AKS)を使っています。この手の書籍は特定の製品に依存しないほうが好ましいのですが、本書についてはこれでよいと思います。というのもKubernetesは巨大なせいもあってフルスクラッチでクラスタを作るのは死ぬほどめんどくさくて*3苦行だからです。初心者にそこからやらせるとそれだけで嫌になってしまうことうけあいです。それよりはクラスタ構築の詳細については全く触れないと割り切ってマネージドサービスを使うほうがよいでしょう。クラスタを構築した後の演習内容はおおよそAKSに依存していない内容なので、Azureが気に入らなければGCPやAWSなどの他の業者のサービスを使うなり、自前でクラスタを用意するなりすればいいと思います。
Azureを使っていることについてもう一点。著者のおふたりはAzureを提供しているMicrosoft社所属です。このような場合、わたしは「もしや"Azure売らんかな"の精神で書かれたAzure礼賛本ではなかろうか」と身構えてしまうのですが、本書はまったくそんなことはなく、安心して読めました。前節において述べたように一旦クラスタを用意してしまえば後はAzure依存部分はほとんど無いですし、かつ、Azureのサービスについても、あくまで複数ある選択肢の一つとして提示されているに留まっていました。よくある技術書の名を借りた営業パンフレットのような本にありがちな臭みは感じませんでした。
最後に余談。本書は「kubernetesについての入門書を私が書くとしたらこうなる」というつくりになっていたので非常に驚きました。私は普段から何かを学ぶときには関連書籍や記事をたくさん読み込んで咀嚼した上で自分なりの教科書にまとめてアウトプットするのですが、今回はこの本にだいたいそのアウトプットに近いものがまとまっているので、書く手間が省けたと思いました。
*1:テクニカルライターとしては、「ここは書きたかったけども断腸の思いで削ったのだろうなあ」というのが透けて見えて面白かったです
*2:Kubernetesは変化が速いのであまり詳細に書いてもしょうがないという面もあると思います
*3:少なくとも私にとっては
microk8sアンインストール時に発生する不具合と解決方法
1ノードのk8sクラスタを簡単に作るmicrok8sという便利アプリがsnapで公開されています。それを使っているときにちょっとした不具合を見つけたのでメモ
- 1/29 更新: PR投げた
問題要旨
microk8sのアンインストールに失敗する
発生条件
/var/snapのファイルシステムがBtrfs
問題が発生したソフトウェアのバージョン
- Ubuntu 18.04
- snap: 2.36.3
- microk8s: v1.13.2
- kernel: 4.15.0-43-generic
再現方法
インストール後にpodを一回でも立ち上げた後で(一つでもimageを作った後で)アンインストールする。
$ sudo snap remove microk8s
期待される結果
アンインストールが成功する。
実際の結果
以下のようなメッセージと共にアンインストールが失敗する。
$ sudo snap remove microk8s error: cannot perform the following tasks: - Remove data for snap "microk8s" (383) (remove /var/snap/microk8s/common/var/lib/docker/btrfs/subvolumes/<id>: operation not permitted)
原因
microk8sのアンインストール時には.../subvolumes/以下に配置されたコンテナイメージをsnapがrmコマンドによって削除しようとしているが、これらのイメージはbtrfsのサブボリュームであり、かつ、kernel 4.15系ではサブボリュームはrmコマンドでは削除できない。
解決方法
アンインストール時にsubvolumeを削除する
回避方法
2つの方法がある。
microk8sのコンテナ用snapshotを自力で削除する
アンインストールの前に次のようなコマンドを発行すればよい。
for i in $(sudo ls /var/snap/microk8s/common/var/lib/docker/btrfs/subvolumes/) ; do sudo btrfs sub del /var/snap/microk8s/common/var/lib/docker/btrfs/subvolumes/$i ; done
この後アンインストールすれば削除すべきイメージは既にないのでアンインストールは成功する。
$ sudo snap remove microk8s microk8s removed
kernelを4.18以上にアップデートする
$ uname -r 4.18.0-13-generic $ sudo ls /var/snap/microk8s/common/var/lib/docker/btrfs/subvolumes/ <id 0> <id 1> $ sudo snap remove microk8s microk8s removed $
なぜカーネルのバージョンアップで問題が解決するかというとkernel 4.18においてrmdir() syscallによって空のサブボリュームを削除できるようになったからです。
on user demand, rmdir() is able to delete an empty subvolume, export the capability in sysfs
ちなみにこの修正をしてくれたのはFujitsuのTomohiro Misonoさんというかたです。すごいぞMisonoさん。
今後の予定
microk8sのアンインストール時に動作するスクリプトを修正するpull requestをupstream communityに出したので、待ち状態。