That's Done!

[en] Linux virtio_can driver

2026-05-06T15:45:00+09:00

I'm working on AGL (Automotive Grade Linux), and now there is a collaboratieve efffort to establish a reference platform for SDV on top of AGL, so called SoDeV.

You can find information regarding AGL SoDeV below.

SoDeV announcement from the AGL/Linux Foundation
AGL Team Workspace
- You can find working code of SoDeV integration there.
- The main target is Renesas R-Car V4H Sparrow Hawk SBC
Accelerating Software-Defined Vehicles: SDV-EG Updates & New AGL SDV Reference
- A great talk given by Jerry Jiancong Zhao from Panasonic Automotive Systems at the ALS 2025.

SoDeV uses Xen Hypervisor and virtio mechanism for inter domain communication.

So far, I was using guest operating system side virtio frontend driver by OpenSynergy team for AGL (based on Yocto 5.x/Scarthgap until 21.0(Unagi release)). Linux kernel version is 6.6.x for Scarthgap. Recently, I noticed that virtio_can driver build fails for Yocto 6.x which is(/would be) based on linux 6.12.x.

After looking into the error logs that I got, I figured out that this comes from a small interface change of a virtio subsystem utility method, virtio_find_vqs().

You can find the patch below, and I hope this makes sense for the community. :)

The original patch (v5) by OpenSynergy team
- LKML post
My port of virtio_can(v5) to 6.12.x
- My work is just porting the Opensynergy teams' great work to Linux kernel 6.18.x. I truely honor OpenSynergy teams' work! License is GPL2 of course.

[ja] Cat's Eye Nebulaにまつわる研究進展

2026-03-08T15:15:00+09:00

このMSNの記事が目について、ちょっとぐぐってみて、へー…と思ったのでメモ。

キャッツアイ星雲、画像自体は昔からよく知られていて、学生の頃にも見た記憶があった。しかし星雲とはいえ、恒星の爆発に伴って形成された構造で、複雑に絡み合ったガスの構造がどう形成されたのかは長らく研究対象だったとのこと。

記事によると、2022頃、当時高校生のRyan Clairmontさんが着想を得てプロに相談して本格的な研究を実行。高密度ガスのリング構造があることを明らかにして論文にしたとのこと。

この業績でRyanさんはISEF(International Science and Engineering Fair)の物理学・天文学部門で1位を獲得。現在はスタンフォードで学生をしている模様。

論文はたぶんこれ "Morphokinematic modelling of the point-symmetric Cat’s Eye, NGC 6543: Ring-like remnants of a precessing jet"

出た当時にSoraeでも話題になっていた模様。

MSNで話題になったのは、最近 Hubble (JWSTではなく)とEuclidを使って非常に精細な画像＋周囲の画像が得られたのが発端らしい。

いやー、自然科学っていいですね :)

[ja] libvirt notes

2026-01-03T13:00:00+09:00

話の発端と何が書いてあるか

Generic qemu qemu notesでvirtio-canの話を書きましたが、qemu-system-ARCHを直叩きするのではなく、libvirtを使い、かつあまり一般的ではないdeviceを使いたいという話です。

/usr/bin 以下のシステム標準品を入れ替えてしまってもよいのですが、切り替えて使えるようにしたい場合、またlibvirt標準でサポートされていないdeviceを使いたい場合、 VM(というかlibvirt用語ではdomain)を定義するにはどうするか？

2通りのやりかた

ざっくり、以下の2通りのやりかたがあります。

標準品libvirtでdomain定義した後、virsh edit や virt-xml で書き換える
virt-installのオプションでがんばる

1.はちょっとうざいので2.の方法を模索していました。なんとか最低限やりたいことはできたのでまとめておきます。

emulatorの変更

上記の記事に書いたように、qemuのmainlineにマージされていないデバイスを使いたいことがあります。この場合、システム標準の qemu-system-aarch64 や qemu-system-x86_64 とは違うバイナリを使うことになります。

AIサーチだと、virt-install に --emulator というオプションがあるよと出てきたのですが、手元の virt-install だと使えなかったので(or ハルシネーション？)、もう少し調べたところ virt-install の --boot オプションに emulator=XXXX と書けることがわかり、フルパスで指定しました。

なお、libvirtdのサーチパスを変更する…といった手法でもイケるようです。

標準的ではないdeviceを使う

qemuレベルだと、CAN device自体については公式にマニュアルがあるように、qemu側の仮想deviceについては -object で定義した上で、対応するqemu側のdriverを指定すればよいです。

qemu mainlineに入っている KVASER というCANのデバイスを、ホスト側のcan0に接続するには、qemu-system0-XXXに以下のように指定すればよいことがわかります。

-object can-bus,id=canbus0
-device kvaser_pci,canbus=canbus0
-object can-host-socketcan,id=canhost0,if=can0,canbus=canbus0

これをlibvirtのdomain定義するのは現状無理な模様です。

ではどうするか？なのですが、libvirtのdomain定義に qemu-system-XXX の command line パラメータを指定することができるので、これを使いました。

virt-install の場合は --qemu-commandline というパラメータに渡します。

PCI IDが衝突することがある

当初、virt-install に以下のようなオプションを付けて試行したのですが、virt-instaellはPCI bridgeをたくさん接続してくれる関係で、IDぶつかってエラーになってしまいました。

--qemu-commandline="-object can-bus,id=canbus2 -device virtio-can-pci,canbus=canbus2 -object can-host-socketcan,id=canhost2,if=vcan2,canbus=canbus2"

じゃあどうするか？なのですが、virtio-can-pci の場合は addr というパラメータがあり、PCIの function IDを指定できることがわかり、lspciの結果とてらしあわせて空きIDを指定することで回避できました。

私の環境の場合はBus 0の 06 まで埋まっていたので、07.0を使いました。以下の通りです。

--qemu-commandline="-object can-bus,id=canbus2 -device virtio-can-pci,canbus=canbus2,addr=07.00 -object can-host-socketcan,id=canhost2,if=vcan2,canbus=canbus2"

なお、Bus 0は PCI Bridgeなので避けたいと思ったのですが、上記を 07:00.0 と書いたところこれもエラー。 (空きのBus IDとdevice IDが両方7なので紛らわしいですね) そこで、同じく virtio-can-pci で使えることになっている busnr が使えるかなと思ったのですが、指定してみたところ「writableではない」という趣旨のエラーが出てしまいました。コードは未調査ですが、最低限やりたいことはできたのでここまででヨシとすることにしました。

なお、qemuのdriverごとのoptionは以下で調べられるようです。以下のvirtio-can-pciを目的のdriverに置き換えてください。

$ qemu-system-aarch64 -device virtio-can-pci,help

また、組み込まれているdriverの一覧は以下で見られます。

$ qemu-system-aarch64 -device help

気づき(未解決)

virt-install の場合、VMを定義するとpower onまでしてくれるのですが、emulatorの変更と --qemu-commandline の指定を入れたところ、power onしてくれなくなりました。virsh start DOMAIN_NAME(等)すればよいのですが、いったん置いてあります。

続くかもしれません。

[ja] Generic qemu notes

2025-12-07T21:40:00+09:00

Zephyr qemu notesでZephyrでのqemu系targetの話を書きましたが、qemu側の話。

virtio-can関連

最近ポストしている記事でCANの話が多くあるように、仕事でCANを使っています。都合でハイパーバイザ上でvirtioベースでCANのトラフィックを流したいという事情があってあれこれ試したメモ。

qemu virtio-can backend

単純に考えると qemu の仮想デバイスとして作ってやることになります。 OpenSynergyが公開していて、以下が最新だと思われます。

https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3

上記は公開が2023/4で、ビルドはすなおに通りますが、残念ながらqemuのベースは6.0.1になります。

なので、qemuのmasterに使えるかなと思ってportしてみたものが以下です。

https://github.com/thatsdone/qemu/tree/virtio-can-port

'25/12時点で、多少のずれはありますがそのまま適用でき、ビルドもすんなり通りました。

いずれも公式の既存のCANデバイスのページ

https://www.qemu.org/docs/master/system/devices/can.html

の記述を参考に、以下のようにqemu-system-xxxにパラメータを渡してやると virtio-can deviceを有効化できます。

      -object can-bus,id=canbus0 \
      -device virtio-can-pci,canbus=canbus0 \
      -object can-host-socketcan,id=canhost0,if=vcan0,canbus=canbus0

上記の例は、ホスト側で vcan を使って vcan0 というデバイスがあるものとし、これにゲスト側のvirtio-can deviceを接続する指定です。

Yet Another virtio-can backend

別解としてvhost-deviceを使う方法があります。

このへんにありますが、まだ試せていません。

https://crates.io/crates/vhost-device-can
https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-can

[ja] 中国旅行時のTIPS('25/11版)

2025-11-15T16:30:00+09:00

最近、中国に出張する機会があり、いろいろ気づきがあったのでメモ。

ネット接続

中国国内からは、Google等のよく使うサービスが使えません。やりかたは各種あって、ざっくりローミングすればいいのですが、今回はティーガイア(T-Gaia)という会社のVOYAGEE eSIMからeSIMを購入しました。

現地ではChina Mobileの(たぶん、香港子会社の？)回線で、香港経由のローミングになるため、GoogleやFacebook等、普通にアクセスできました。

使い勝手は普通の海外用eSIMとほとんどかわりませんが、１点、ローミング中に「データサービスに接続する」設定にする必要があります。

決済/支払い

今回は現金を使う機会が一度もありませんでした。

クレジットカードすら使えないことも多いので、AliPayまたはWeChat Payは必須です。

私はAliPayを使いましたが、以下、いくつか気づきを箇条書きでまとめておきます。

日本国内でもAliPay使えるマークが出ているところは多くありますが、あれは中国からの旅行者専用です。日本のクレジットカードを使ってAliPayのアカウントを作ってあっても、中国でしか使えません。
AliPayのアカウントを作るとき、本人確認のため、携帯の電話番号だけではなく、パスポートの情報を入力(スキャンでもOK)する必要があります。この際、パスポートの写真と照合のため自撮りするステップがあるので面食らわないようにしましょう。
中国国内ではデビットカード的に銀行口座に紐づけるのがスタンダードなようですが、外国人はクレジットカードを紐づけられます。決済の使い勝手としては、少額の買い物でも都度クレジットカードで決済する感覚になります。
クレジットカード情報を登録する時、支払用のパスワード(数字6桁)を作成します。現地で買い物をするたびに必要になるので、ちゃんと覚えておきましょう。
AliPayの中から、Uber相当のDidi等、各種の別サービスを呼び出して使えるようになっています。「ミニアプリ」と呼ばれています。今回は Didi を使いましたが、別項目で。
アプリはAndroid版の場合で、日本語を含めて多数の言語が使えます。ただし、日本語は翻訳が微妙なので私は英語で使いました。
- ホーム画面 -> 右下のAccount -> 右上のねじマークアイコン -> General と画面遷移すると言語設定するところがでてきます。
- なお、AliPayから呼び出す「ミニアプリ」については多言語対応状況はモノによります。(後述)
買い物をするときは以下のどちらかになります。
1. 「支払い/受け取り(Pay/Receive)」のボタンから自分のQRコードを出して、お店の端末でスキャンする
2. 「スキャン(Scan)」ボタンから提示されたQRコードをスキャンする

タクシー/ライドシェア

Uberは駆逐され(?)、Didiがデファクトのようです。
AliPayを入れると、前述の通りAliPayの「ミニアプリ」としてDidiが連携して使えるようになっています。言語設定については、少なくともAliPayのミニアプリの場合は、中国語２種(簡体字と繁体字)以外は英語だけでした。Didi専用のアプリだと違うのかもしれません。(未確認)
Didiの(ミニ)アプリの使い勝手は、Uberとほぼ同じです。Uberを使ったことのある人であれば悩まずに直観的に使えると思います。
AliPayのミニアプリの場合だけかもしれませんが、アプリからあがってくるポップアップが中国語のまま翻訳されていないケースがあるようです。私が見たのは、配車を確定する際に、「車両内の安全確認のためにカメラで(動画)撮影するが承諾するか？」という質問が中国語のままでした。(中国出身の同行者がいたので安心して承諾できましたが、怖いところです)

高速鉄道

今回は上海から南京に移動する必要があり、高速鉄道(＝日本で言う新幹線)を使いました。とても便利かつ、乗り心地もよかったです。

全席指定席のため、チケットを予約＆事前購入する必要があります。
AliPayの"TripAir-Train"からも予約・購入ができます。...が、今回使ったeSIMの回線のせいか、動きがとても遅かったので、Webからtrip.comを使いました。こちらは普通にクレジットカードが使えます。なお、後述の通り、予約・購入時にパスポート情報を入力する必要があります。
trip.comはスマホアプリもあって、Webからの予約情報と一体運用でき、現地で列車番号や座席、チケット番号を移動中に確認できるので便利です。
高速鉄道の改札では、紙のチケットは必要ありません。中国現地の人たちは、日本のマイナカード相当のカードで、外国人はパスポートをスキャンして本人確認＆予約照合が行われます。

地下鉄とかバスとか

...は、今回は結局乗らなかったのでわかりません。ただ、一般的な買い物のように券売機でQRコードスキャンで行けるのではないかと思われます。

カジュアルな食事

おいしいものが食べられる、カジュアルが食堂がたくさんあります。

支払いはAliPayかWeChat Payのみというところがけっこうあります。

ここまでは前述の通りですが、'25/11時点、電子化がまだ進行中らしく、メニューの類を置いておらず、QRコードからWebサイトにアクセスして、オーダー＆即時決済が必用というところがけっこうあります。ここで問題は、そのWebサイトが英語にすら対応していないこともけっこうあり、現時点では外国人にあまりやさしくない状況になってしまっているようです。

これは、例えばカフェの luckin coffee とかでも事情は同じようでした... が、マクドナルド等は最低限英語だけは対応していました。(が、支払はクレジットカードも受け付けていませんでした...orz)

モバイルバッテリー

飛行機に持ち込めるモバイルバッテリーには、容量制限があるのはよく知られていると思います。

今回、同行者がひっかかったのですが、少なくとも国内線に乗る場合、中国のCCC認証を通ったモバイルバッテリーである必要があるようです。例えばAnkerのような中国製のモバイルバッテリーでも、日本で買える輸出モデルだとCCC認証を取得していないケースもあるので要注意とのこと。

続く..かもしれません。

[ja] Zephyr qemu notes

2025-11-05T20:25:00+09:00

Zephyr ESP32 notesを書いたので、次はqemuのメモをダンプしていきます。

対象は以下の2つです。

qemu-system-x86_64
qemu-system-aarch64

...が、そのうち増えるかもしれません(笑)

話の発端

まず、私は数年前から単純にCPUを使いまくるテスト用(というか教育用?)のプログラム(mpmt)を作っています。

ここにおいてあります。

https://github.com/thatsdone/mpmt

取り扱う言語が30を超えたくらいからネタ切れ感がでてきていたのと、 AGLに絡みはじめてから同じLinux Foundation配下のRTOSにZephyrをAGLのSDV Reference PFで使おうよという話、つまり SoDeV プロジェクトに首をつっこみはじめてから、当時者としてZephyrに興味を持つようになりました。

それで、言語やそのランタイムだけではなく、RTOSでもmpmtを動かしてみるか…と思い至ったというのが発端です。

mpmtのZephyr版はこのあたりを見てみてください。

さて、以下気づきのメモを列挙していきますが。他の記事と同様に随時更新していきます。

ターゲット...というかボード指定？のやりかた

west build する際に -b に何を指定するか？という話です。

x86_64の場合
- qemu_x86_64
ARM64の場合
- qemu_kvm_arm64

以下、マニュアル。

x86/x86_64 qemu target board
- https://docs.zephyrproject.org/latest/boards/qemu/x86/doc/index.html
ARM64 qemu target board
- https://docs.zephyrproject.org/latest/boards/qemu/kvm_arm64/doc/index.html

できあがるバイナリ

west build -t run ではなく、qemu-system-xxx から直接実行したい…とか、libvirtで制御できるようにしたいという場合には気にする必要があります。

x86_64の場合

x86_64の場合、buildディレクトリの中にバイナリが2つできあがります。

一方はZephyrのメインプログラムでもう一方はloaderになります。 mpmtのZephyr版のREADMEに書いておきましたがこういう感じです。

kernel: zephyr-qemu-locore.elf
loader: zephyr-qemu-main.elf

aarch64の場合

こちらは一般的な組み込み用のボードと同じで1つだけです。 buildディレクトリの中にzephyr.binができあがります。

KVMの仮想化支援機能を使いたい

west からqemuに指定のパラメータを渡す方法があるのかもしれませんが、現状は未調査です。ただ、qemu-system-x86_64等から直接起動する場合は普通に使えます。

Zephyrのqemu_x86_64 boardでvirtioを使いたい

使えます。 …が、2点ほどハマったのでメモ。(2025/12/31追記)

virtio関連デバイスのdts定義がない

...というか、実はzephyrのツリーに含まれているのですが、ZEPHYR_ROOT/boards/qemu/qemu_cortex_a53.dts に記述がある程度で、qemu_x86_64 や qemu_kvm_arm64 で使おうとすると overlay ファイルを作ってやる必要があります。

これに何を参考にすればよいのか悩ましいのですが、 ZEPHYR_ROOT/tests/drivers/build_all/virtio/boards/qemu_x86_64.overlay がテストに使われているもので、virtio-pci/virtio-net-pci/virtio-console-pci/virtio-entropy まではこれで使えるようです。

私は自分のアプリの boards ディレクトリの下に上記をコピーして持ってきてビルドできました。 (ただし、後述のprj.confの定義にも落とし穴がある)

CONFIG_UART_VIRTIO_CONSOLEが有効にならない？

prj.confで、以下の3つすべてを n に指定してやる必要があります。

CONFIG_EARLY_CONSOLE
CONFIG_X86_VERY_EARLY_CONSOLE
CONFIG_BOOT_BANNER

特に3つめは気づかなかったっすorz

今回は、比較的最近mergeされたらしい virtio-net のドライバを使い、qemu環境で動かそうとしていました。参考までに prj.conf の差分を付けておきます。VIRTIO関連以外には、qemu環境なので、GPIOやLEDは無効にする必要がありました。

(venv) zephyr:~/zephyrproject/zephyr/samples/net/sockets/http_server$ git diff prj.conf
diff --git a/samples/net/sockets/http_server/prj.conf b/samples/net/sockets/http_server/prj.conf
index 5cfe2a04ad2..8b13bb6e150 100644
--- a/samples/net/sockets/http_server/prj.conf
+++ b/samples/net/sockets/http_server/prj.conf
@@ -26,6 +26,21 @@ CONFIG_NET_STATISTICS=y
 CONFIG_NET_STATISTICS_USER_API=y
 CONFIG_NET_LOG=y

+# for virtio_net
+CONFIG_PCIE=y
+CONFIG_ETH_DRIVER=y
+CONFIG_VIRTIO=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_ETH_VIRTIO_NET=y
+
+CONFIG_PRINTK=y
+CONFIG_EARLY_CONSOLE=n
+CONFIG_BOOT_BANNER=n
+CONFIG_X86_VERY_EARLY_CONSOLE=n
+CONFIG_UART_VIRTIO_CONSOLE=y
+CONFIG_UART_VIRTIO_CONSOLE_F_MULTIPORT=y
+
+
 # JSON
 CONFIG_JSON_LIBRARY=y

@@ -64,8 +79,8 @@ CONFIG_NET_CONFIG_PEER_IPV6_ADDR="2001:db8::2"
 CONFIG_NET_TCP_TIME_WAIT_DELAY=0

 # Device drivers
-CONFIG_GPIO=y
-CONFIG_LED=y
+#CONFIG_GPIO=y
+#CONFIG_LED=y

 # Network debug config
 CONFIG_NET_SOCKETS_LOG_LEVEL_DBG=n

続きます。

[ja] Zephyr ESP32 notes

2025-11-03T00:10:00+09:00

直近で書いた Zephyrをはじめましたと Zephyrの一般的な使い方メモ(ボード非依存) の記事の後、とりあえずESP32からいきます。

前提

私はEspressifのESP32-WROVER-E というボードを使っています。 CPUはTensilica XtensaアーキテクチャのLX6というだいぶ古いものです。 Zephyrのboardページだとここにあるものに対応します。

以下、シリーズによってはあてはまらない情報があるかもしれませんが、御承知おきを。

ESP32のCANコントローラ(TWAI)を使いたい

可能です。

ただし、少なくとも v4.2.0-4096-g1c1598601b5c 時点では、disabledにされています。具体的に言うと以下のあたり。(2025/11/02時点)

https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/xtensa/espressif/esp32/esp32_common.dtsi#L438

431                 twai: can@3ff6b000 {
432                         compatible = "espressif,esp32-twai";
433                         reg = <0x3ff6b000 DT_SIZE_K(4)>;
434                         interrupts = <TWAI_INTR_SOURCE IRQ_DEFAULT_PRIORITY 0>;
435                         interrupt-parent = <&intc>;
436                         clocks = <&clock ESP32_TWAI_MODULE>;
437                         status = "disabled"; # ★disabledになっている★
438                 };

このため、overlayファイルを作ってオーバーライドしてあげる必要があります。やり方は前の記事を参照してください。

ESP32でCAN通信をしたい

可能です。

ただし、ESP32はCANのコントローラしか内蔵していないので、CANトランシーバーを接続してあげる必要があります。

私は、MicrochipのCAN-FD対応のトランシーバーのMCP2562FDを使い、この記事で紹介されている回路を組み、対向側としてRaspberry Pi Zero W + DSP SH-C31AおよびRenesas R-Car V4Hを搭載したSBCの Sparrow Hawk で動作確認しました。 MCP2562FDは秋月で200円(当時)でした。

2025/10/20に大阪で開催されたZephyr Project Meetup: Osaka, Japanで話したネタはこの話をしています。

会場で「普通はMicrochipのトランシーバを使うのか？」という質問を受けましたが、 CANは枯れた規格なので、基本的には何でも動くのではないかと思います。NXPのチップとか。動作電圧とかは注意ですが...

CANデバイスの状態を確認したい

微妙です。(...だと思います(4.2.0時点))

prj.confでCONFIG_CAN_SHELLを有効化(=y)すると使えるようになる shellのCANサポート機能を使い、

uart:~$ can show DEVICE_ID

等とやるとトランシーバーの状態まで表示できます。使えるDEVICE_IDは、省略して can show とやると一覧表示されます。

以下は can show DEVICE_IDしてみた時のログの例になりますが、外付けのCAN transceiverの場合は、ESP32とは関係なく、もうひと手間加えてあげないと、 Zephyr側で認識してくれないように思います。

$ west espressif monitor
(snip)
[00:00:00.175,000] <dbg> can_sja1000: can_sja1000_init: initial sample point error: 0
*** Booting Zephyr OS build v4.2.0-4096-g1c1598601b5c ***
(snip)

いきなり余談ですが...

ESP32の場合は westの拡張が入っていて west espressif monitor とかできるので便利です
上記をみるとESP32が内蔵するCANコントローラはNXPのSJA1000互換のIPを使っているものと想像できます。

以下、状態表示してみた結果。

uart:~$ can show can@3ff6b000
core clock:      40000000 Hz
max bitrate:     1000000 bps
max std filters: 5
max ext filters: 5
capabilities:    normal loopback listen-only one-shot triple-sampling
mode:            normal
state:           error-active

ここのstate:はCANコントローラの状態です。error-というprefixが気になるのですが、コードを眺める限りは、これで正常に初期化できているということのようです。

rx errors:       0
tx errors:       0
timing:          sjw 1..4, prop_seg 0..0, phase_seg1 1..16, phase_seg2 1..8, prescaler 1..64
transceiver:     passive/none

次にここ。transceiver: が passive/none という状態になっていて、トランシーバの状態が取れない模様...うん？

statistics:
  bit errors:    0
    bit0 errors: 0
    bit1 errors: 0
  stuff errors:  0
  crc errors:    0
  form errors:   0
  ack errors:    0
  rx overruns:   0

しかし、このまま送信処理をしてみると、以下のように無事に送信処理が終わっている!?

uart:~$ can send can@3ff6b000  234 56
enqueuing CAN frame #0 with standard (11-bit) CAN ID 0x234, RTR 0, CAN FD 0, BRS 0, DLC 1
CAN frame #0 successfully sent
uart:~$

このログを採取した際、CANバスの対向側にRaspberry Pi Zero W+DSD SH-C31Aをつないでおり、実際にデータが流れていることを確認しています。

それで、上記transceiverの表示のところは、ソースの該当部分を眺めると、deviceに対応する管理構造体がない(＝pointerがNULL)だとこういう表示になるようです。

と、いうことは...

dtsで何かtransceiver用の記述をしてあげないといけない？
後述のCAN Busの状態をGPIOで制御したい場合と同様に、GPIO用のpin定義のついでに)deviceも書かないといけない？

...とか想像できますが、まだ裏がとれていません。

あとは、statistics: のところ、数字が入ってくれるのかどうか、まだ確認できていません。

うーん...

CAN Busの状態を制御したい(BUS Stopさせたり戻したりとか)

can_transceiver_enable() というAPIを使って可能(...なはず)です。 CANコントローラへの指示ではなく、トランシーバのSTBY(だったり、チップによってはSだったりしますが...)GPIOでピンの値を制御することになります。(はずです)

...とはいえ上記に書いたように、何かおまじないが必用...と思われます。

以下、参考。

CAN transceiverまわりの説明
- https://docs.zephyrproject.org/latest/hardware/peripherals/can/transceiver.html
CAN transceiver APIの説明
- https://docs.zephyrproject.org/latest/doxygen/html/group__can__transceiver.html

ESP32の複数コアを使いたい

可能です。

ESP32の場合は、普通のSMPではなく、 AMP(Asymmetric Multi-processing) と呼ばれる使い方になるようです。ビルドの際に、先頭のコア用のプログラムはprocpu、 2番目(以降?)のコアがappcpuという名前でターゲット指定することになります。 sysbuildでブートローダにmcubootを指定し、2番目のコア(前述のappcpu)用のプログラムは remote というディレクトリにわけて作ることになるようですが、識者によると、ここでも「黒魔術」っぽさがある模様...gkbr

複数コアの間の通信や同期には IPM: Inter-Processor Mailbox という仕組みが使えるようになっています。 IPMを使ったプログラミングの具体例は、zephyr公式のサンプルにも含まれています。ESP32用のものはここにあります。

なお、threadを使うだけでは1コアしか使われないことに注意が必要です。(たぶん)

TODO

以下のような確認を行いながら更新してく予定。

multi-threadを使いたい
ESP32のWiFiを使いたい
ESP32でhttp_serverを動かしたい
gdbでリモート(?)デバッグしたい
ESP32にセンサ(I2CとかSPIとか)をつなぎたい
...

[ja] Zephyr generic notes

2025-11-02T13:25:00+09:00

Zephyrをはじめてみて、有識者のみなさんにいろいろ教えを受けつつ気づいたこと、特にボード非依存のメモをまとめる場所にします。(＝断続的に更新していきます)

ボード依存の話は別記事で。現状、以下の子たちくらいを予定しています。

ESP32 (初代無印、Xtensa LX6のDevkitC)
Raspberry Pi (5とZero W)
qemu系 (x86_64とaarch64)
xenvm

自分のアプリをどこにおけばいいのか？

答：どこでもかまいません。

補足：

一次情報
- How to build your Zephyr app in a standalone folder
特に SOME_WHEHERE/zephyrproject/zephyr の下に置く必要はありません。
SOMEWHERE/zephyrproject/zephyr/zephyr-env.sh という環境設定用のファイルがありますので、これをsourceしてください。
自分のアプリのディレクトリの中で west build -p -b YOUR_TARGET_BOARD . とすればOKです。
- 最後の . (ピリオド＝カレントディレクトリを指定)を忘れないでください
ビルドされた生成物は、上記自分のアプリのディレクトリの中に build というディレクトリが作成されて格納されます。
- 未確認すが、自分のアプリのディレクトリとは違うところで west コマンドを起動すると、カレントに build ができるかもしれません

DTSをoverlayしたい場合のファイル名や配置場所は？

答：自分のアプリのディレクトリの中に所定のファイル名で、所定の名前のディレクトリを作って格納してください。

私の事例では、ESP32のdevice treeはzephyr/boards/espressif以下にボードごとに格納されていました。ただ、CANコントローラのTWAIはdisableだったので、okにオーバーライドする必要がありました。こういう場合にどうするか？です

典型的には YOUR_APP_DIR/boards/BOARDNAME.overlay になります。

補足：

一次情報はこのへんにあります。
- Application Development
ディレクトリの名前は board か soc になりますが、ボードごとになるほうが多いように思います。また、アプリケーション固有であれば application.overlay でもかまいません。(...が、アプリ固有でDTSいじる必要ってどのくらいあるんですかねぇ？)

sampleについている sample.yaml は要るのか？

答：不要

自分のアプリを公開するだけなら上記の通り不要です。

ただし、zephyr公式distributionへのマージを目指すようであれば必要になります。

WSL2で使いたい

答：私はWSL2の Ubuntu 24.04環境で問題なく使えています。

WSL2でUSBデバイスを使えるの？

答：使えます。GUI操作でUSBデバイスの付け替えができる usbipd-win がとても便利です。

[ja] Hello Zephyr

2025-10-25T18:10:00+09:00

今年('25)の5月くらいまでさかのぼりますが、RTOSのZephyrをさわりはじめました。

しばらく前から趣味で作っているCPU負荷発生器で新言語のネタがなくなってきたのと、やんごとなき事情(?)で関わっているAGLの議論の中で興味を持ったのがきっかけです。

CPU負荷発生器(mpmt)のZephyr版を作ってみる

まず、とりあえずはCPU負荷発生器のmpmtのZephyr版を作ってみました。

README.mdはこんな感じです。 x86_64とarm64のそれぞれやってみました。

kernel threadを使って、指定したcore数を使い切っているなというところまで確認できて、いったん満足してしまいました(苦笑)

CAN通信してみる

CPU負荷発生器を作ってみたあと、しばらく別件で忙しくなってお休みしていたのですが、 AGL方面でZephyrが動くマイコンでCAN通信できることを確認しておこうという話があり、担当することにしました。

お題は、コロナがはじまったころに出来心で買ったまま放置していたEspressifのESP32を使っています。

中間成果を先日('25/10/20)大阪で開催されたZephyr Project Meetup: Japan, Osakaというイベントで話してきました。イベントがこれで、話した小ネタがこれです。

ESP32とRaspberry Pi Zero W、およびRenesas R-Car Sparrow Hawkの2種類のSBCと、対向でCAN通信できるところまで確認しています。

今後

上記の小ネタ発表資料にも書きましたが、以下のようなことを考えています。

AGL付属のCAN負荷発生機の移植
Zephyr virtio-can driver (FE/BE)開発のお手伝い
UDSライブラリの開発

そのほか、ESP32はIoTマイコンとしては比較的ポピュラーな位置づけかなと思うのですが、クラウドというかデータセンタ用のサーバでの開発とくらべていろいろ違いがあるな… という気付きがあったのでぼちぼちまとめていきたいと思います。

[ja] Linux Kernel Build TIPs

2024-11-20T18:10:00+09:00

ある意味、先月のこの記事の続き。

6.12がリリースされたので、PREEMPT_RTとsched_extを試そうとしていて、必要なCONFIGを有効にするのに少し見落としがあったのでメモ。

※'25/04/06: この記事を書いた当時に6.12で遊び、その後6.13、6.14ときて、RUSTでも気づいたことがあったので追記。

前提

ビルド環境: Ubuntu 24.04.1(amd64)
ツール類: 基本的にUbuntu bundle版
- ただし、後述のRust関連だけ、upstreamから持ってきている

PREEMPT_RTの有効化

長らく開発が続いてきて、とうとう6.12でmergeされて話題になっていたReal-Time機能のPREEMPT_RTを使ってみたいと思ったのが発端。

ビルドにあたって、make menuconfigでは、冒頭の"General Setup"の中で、 "BPF Subsystem"の下に出てくる"Preemption Model"...ではなく、 "Fully Preemptive Kernel (Real-Time)" を選択する。(6.14の場合)

選べる詳細条件の確認は kernel/Kconfig.preempt を参照。

PREEMPT_RTで遊ぶには

realtime taskを動かせばよいのだが、例えばrt-testsに含まれるcyclictestとかがよくつかわれるようだ。

sched_ext(CONFIG_SCHED_CLASS_EXT)の有効化

sched_extを使うと、eBPFでオレスケジューラを書いたりすることができる。

ビルドにあたって、make menuconfigでは、PREEMPT_RTと同じく "General setup"の中で、"Preemption Model"の2つ下に出てくる"Extensible Scheduling Class"が該当する。

ハマりポイントとして、上記の項目がでてこないことがあるのだが、私の場合はpaholeがインストールされていなかったのが原因だった。sudo apt install pahole した後でmake menuconfigすると選べるようになる。

同じく選べるための詳細条件の確認は kernel/Kconfig.preempt を参照。

sched_extで遊ぶには

Linux kernelの tools/sched_ext にサンプルが一式ついている。README.mdに書いてある通りの使い方で素直に動く。

ビルドして起動したkernelで、無事にsched_extが有効になっているかどうかは sysfs 経由で確認できる。 /sys/kernel/sched_ext が存在し、stateの中身で enabled/disabledがわかる。以下は初期状態(=disabled)で、これから設定して使う。

$ ls -al /sys/kernel/sched_ext
total 0
drwxr-xr-x  2 root root    0 Mar  2 08:43 .
drwxr-xr-x 18 root root    0 Mar  2 08:10 ..
-r--r--r--  1 root root 4096 Mar  2 08:25 enable_seq
-r--r--r--  1 root root 4096 Mar  2 08:25 hotplug_seq
-r--r--r--  1 root root 4096 Mar  2 08:25 nr_rejected
-r--r--r--  1 root root 4096 Mar  2 08:25 state
-r--r--r--  1 root root 4096 Mar  2 08:25 switch_all
$ cat   /sys/kernel/sched_ext/state
disabled
$

以下、参考リンク

Rustで遊ぶには

私は仕事で機能安全が求められるような組み込みとセンタ側の両方に足を突っ込んでいるのだが、機能安全界隈でもRustが話題になっている関係もあって、遅ればせながら(kernelでも)Rustで遊んでみることにした。

以下、.configに必要な設定を入れるまでの道のり。

ツールチェーン関連
rustコンパイラ/LLVM
- もちろんツールチェーンが必要になる。以下で配っているstable用のものを使うのが安全だと思う。
- https://mirrors.edge.kernel.org/pub/tools/llvm/rust/
bindgen
- x86_64では、当時利用していた llvm-19.1.7-rust-1.85.0-x86_64 付属の bindgenでは不具合があって必要な項目が出てこず選択できなかったため、下記のbindgenのreleaseから 0.71.1 を持ってきて入れ替えて使った
  - https://github.com/rust-lang/rust-bindgen/wreleases
- arm64では、llvm-19.1.7-rust-1.86.0-aarch64 (rustのversionが0.01違うのに注意)にはそもそもbindgenが含まれていなかった。Ubuntu 24.04付属の bindgen は0.66系で古く、同じく不具合を起こすため、上記repositoryをcloneの上 cargo install bindgen-cli して 0.71.1 (aarch64)を入れた。(PATHの更新に注意)
CONFIG_MODVERSIONS
- 少なくとも6.14の時点では、Rustによるkernel moduleを使いたい場合はloadable kernelのバージョニングを無効にする必要がある
- "Enable loadable module support" -> "Module versioning Support" のチェックをはずす
CONFIG_RUST
- "General setup" -> "Rust support" (6.14時点では一番下から２番目)をチェック
- "Rust support"が出てこない場合、前述のツールチェーンが要件を満たしてない場合か、CONFIG_MODVERSIONS等の依存config設定に不整合がある場合がある。その他の条件を確認するには init/Kconfig の "config RUST" のところを参照のこと。
CONFIG_SAMPLES_RUST
- "General setup" -> "Kernel hacking" -> "Sample kernel code" -> "Rust samples" にチェックをつけると samples/rust 以下のサンプルがビルドされる。

Ubuntuの /boot/config-* を流用する場合の注意

私は普段はUbuntuの上で生活している。この関係で新しいkernelを試す時もUbuntuの上になる。

そうすると、.config もあまりベースと違うと動くはずのものが動かなくなったりするため、/boot/config-* を流用することが多い。

この場合の注意として、以下の２つのキーを無効にする(""を設定)必要がある。

SYSTEM_TRUSTED_KEYS
CONFIG_SYSTEM_REVOCATION_KEYS

参考記事

なお、上記の参考記事によると make menuconfig してできあがった .config を書き換えればよいようなコメントがついているのだが、少なくとも6.14の場合はもういちど make menuconfig する必要があった。(設定はなにもいじらないがとにかく保存して終了)

kernelビルドに必要なパッケージ

私は、開発環境用にUbuntuでサーバを作る場合、とりあえず build-essentialとdevscriptsを入れる。 kernelをビルドする際にこれでも足りないものを列挙しておく。

libncurses-dev
flex
bison
libelf-dev
libssl-dev
pahole (前述の通り)
Rust/LLVMのツールチェーン (前述の通り)

そのほか

もっとあったような気がするので別途追記/更新予定。

eBPFで気持ちよく遊ぶ都合でCONFIG_DEBUG_INFO_BTFも有効にしたのだが、これはSCXで求められるんだっけな...(To be updated)

HISTORY

'24/11/20 初出
'25/04/06 Rust関連の記述を追記
'25/04/13 Ubuntuの config-* を流用する場合の注意と必要パッケージを追記

[ja] How to manage GRUB default kernel

2024-10-14T16:52:00+09:00

最近、かなり久しぶりにvanilla kernelをビルドする機会があり、 kernelを切り替えて使いたい場合のGRUBの設定で気づいたことがあったのでメモ。

最近...といっても、20.04くらいからだろうか。submenu というものが導入され、昔のノウハウが効かなくなっている模様。

2024/10/14時点での情報。

Ubuntu 24.04 LTS時点での答

以下の手順でdefaultでbootに使われるkernelを切り替え可能。

/etc/default/grub の GRUB_DEFAULT に saved を設定する
- GRUB_DEFAULT=0 → GRUB_DEFAULT=saved
- Ubuntuだと普通は0になっているので、ここの修正が必要ということ
- なお、記事によっては、/etc/default/grub に GRUB_SAVEDEFAULT=true を設定するべしという説明がある。これを入れると、私の場合は、後述の grub-reboot コマンドによる一時的な切り替えが効かなくなった。
grub-set-default で、'SUBMENU_ID>MENUENTRY_ID' の形式で指定する
- SUBMENU_ID は sudo grep submenu /boot/grub/grub.cfg で調べる
- MENUENTRY_ID は sudo grep menuentry /boot/grub/grub.cfg で調べる
- 例: # sudo grub-set-default 'gnulinux-advanced-69cecedb-4058-4b83-8507-cca6498f4099>gnulinux-6.8.0-45-generic-advanced-69cecedb-4058-4b83-8507-cca6498f4099'
# update-grub する
# reboot する

これで指定したkernelがdefaultに切り替わる。

一時的に次にbootするkernelを切り替える場合

kernelそのものをいじっている場合など、次のboot時のみ一時的に切り替えたい等の場合は、grub-reboot コマンドが使える。

/etc/default/grub の GRUB_DEFAULT が saved になっていることを確認する
# grub-reboot 'SUBMENU_ID>MENUENTRY_ID'
# update-grub する
# reboot する

もう一度rebootすると、元のdefault kernelで起動される。

サンプル /boot/grub/grub.cfg

以下は私の、Ubuntu 22.04 から 24.04へ do-release-upgrade した環境の /boot/grub/grub.cfg の例。

162行目の $menuentry_id_option の後ろの gnulinux-advanced-32227d3a-e56d-453c-b030-d3c44576fa3f' が上記のSUBMENU_IDの例。

この環境では、そのままだと 163行目の 'Ubuntu, with Linux 6.8.0-45-generic' が使われるのだが、 190行目の 'gnulinux-5.15.0-122-generic-advanced-32227d3a-e56d-453c-b030-d3c44576fa3f' を使って # grub-set-default 'SUBMENU_ID>MENUENTRY_ID' すればよい。

ポイントは、私の場合は以下の2点だった。

SUBMENU_ID と MENUENTRY_IDの間は > でスペースを空けずにつなぐ
' でquoteするのが安全

162 submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-32227d3a-e56d-453c-b030-d3c44576fa3f' {
163         menuentry 'Ubuntu, with Linux 6.8.0-45-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.8.0-45-    generic-advanced-32227d3a-e56d-453c-b030-d3c44576fa3f' {
164                 recordfail
165                 load_video
166                 gfxmode $linux_gfx_mode
167                 insmod gzio
168                 if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzop    io; fi
169                 insmod part_msdos
170                 insmod ext2
171                 search --no-floppy --fs-uuid --set=root 32227d3a-e56d-453c-b    030-d3c44576fa3f
172                 echo    'Loading Linux 6.8.0-45-generic ...'
173                 linux   /boot/vmlinuz-6.8.0-45-generic root=UUID=32227d3a-e5    6d-453c-b030-d3c44576fa3f ro
174                 echo    'Loading initial ramdisk ...'
175                 initrd  /boot/initrd.img-6.8.0-45-generic
176         }

(snip)

190         menuentry 'Ubuntu, with Linux 5.15.0-122-generic' --class ubuntu --c    lass gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.15.0-    122-generic-advanced-32227d3a-e56d-453c-b030-d3c44576fa3f' {
191                 recordfail
192                 load_video
193                 gfxmode $linux_gfx_mode
194                 insmod gzio
195                 if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzop    io; fi
196                 insmod part_msdos
197                 insmod ext2
198                 search --no-floppy --fs-uuid --set=root 32227d3a-e56d-453c-b    030-d3c44576fa3f
199                 echo    'Loading Linux 5.15.0-122-generic ...'
200                 linux   /boot/vmlinuz-5.15.0-122-generic root=UUID=32227d3a-    e56d-453c-b030-d3c44576fa3f ro
201                 echo    'Loading initial ramdisk ...'
202                 initrd  /boot/initrd.img-5.15.0-122-generic
203         }

Xenを入れる場合

(2025/04/26追記)

最近、事情でxen-system-(amd64|arm64)を使う必要が発生した。 UbuntuでXenを使う場合、Ubuntu 24.04だとうまくdom0を起動できない…という話もあって、このメモはUbuntu 22.04が前提になるが、この件は24.04でXenが動くようにしたとしても構造上、共通だと思われる。

発生する問題は、xen-system-amd64(等)を入れると、grub-set-defaultやgrub-rebootでの切り替えが効かなくなる。

これは、xen-system-(amd64|arm64)を入れると /etc/default/grub.d/xen.cfg　が追加され、こんな処理を追加しているためである。

$ grep -Ev ^\(#\|$\)  /etc/default/grub.d/xen.cfg
echo "Including Xen overrides from /etc/default/grub.d/xen.cfg"
if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "" ]; then
        echo "WARNING: GRUB_DEFAULT changed to boot into Xen by default!"
        echo "         Edit /etc/default/grub.d/xen.cfg to avoid this warning."
        XEN_OVERRIDE_GRUB_DEFAULT=1
fi
if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then
        GRUB_DEFAULT=$( \
                printf "$(gettext "%s, with Xen hypervisor")" \
                "$GRUB_DISTRIBUTOR GNU/Linux")
fi

私は /etc/default/grub に

# view /etc/default/grub
(snip)
  6 XEN_OVERRIDE_GRUB_DEFAULT=0 　★これ
  7 #GRUB_DEFAULT=0
  8 GRUB_DEFAULT=saved
(snip)

という行を追加することで対応したが、上記の処理を見てわかる通り、"1" 以外なら何でもよい。

最初見落としていたのだが、update-grubする時に以下のようなWARNINGが出ていて、ちゃんとメッセージを読めよという話なのだった。

(snip)
Including Xen overrides from /etc/default/grub.d/xen.cfg
WARNING: GRUB_DEFAULT changed to boot into Xen by default!
         Edit /etc/default/grub.d/xen.cfg to avoid this warning.
Generating grub configuration   file    ...
(snip)

References

Grubで前に起動したシステムを記憶する
- https://www.terakin.com/ja/blog/archives/129
- /etc/default/grub に GRUB_SAVEDEFAULT=true が必要という説明がある。Windowsとのdual boot環境で、Linuxが普段使いだがWindows Updateでrebootを繰り返す...といった場合はこの記事に従うのがよいようだ。
How to get grub2 to remember last choice?
- https://askubuntu.com/questions/148662/how-to-get-grub2-to-remember-last-choice
Setting the desired kernel in GRUB menu
- https://askubuntu.com/questions/1526087/setting-the-desired-kernel-in-grub-menu
- /etc/grub.d/40_custom/ にファイルを作るやりかた
- Windows等とdual以上のboot環境にしたい場合に使うみたいだ
How do you change and set the default Kernel in Ubuntu Machine?
- https://mnzel.medium.com/how-do-you-change-and-set-the-default-kernel-in-ubuntu-machine-7ad1107e1b6f
- 自分としてはコレがアタリだった

[ja] L2 over SSH

2023-09-26T19:00:00+09:00

これまでqiitaやらblogspotに記事を書いてきた記事をここに集約するシリーズ。

今日は、なんと10年前(!)にblogspotに書いた記事。同僚と「sshって通すとなんでもできちゃうよ…」と話していて、思い出しました。

このところ ssh tunnel ネタが多いが、実は ssh を使って port forwarding だけではなく、L3トンネルや L2‘トンネルを作れるのはそんなに知られていないように思う。実際、自分も Software Design 2012/10月号の、川本(@togakushi)さんの記事「SSH力をつけよう！」を読むまで知らなかった。

余談だが、この記事は本当にすばらしい。chef 特集につられて買った号だったのだが、編集部の気合いを感じた一冊だった。

まず、L3トンネルのやり方から。 port forwarding とは違い、今度はオプションに -L ではなく -w を使う。例えば

$ ssh -w 0:0 root@remote_host

とすれば、ローカルとリモートの双方に tun0 という tunnel device (tun) が作成され、 -w の指定値は、

$ ssh -w any:any root@remote_host

のように、any:any とすれば、tun1 とか tun2 とか、ローカルリモートそれぞれで tunnel device 番号の空きの若いものから自動的に採番してくれる。

こうして作成した tunX にそれぞれ適切に IP address を割り当てれば IP レベル(L3 レベル)で通信できるようになる。

ところで、この仮想化の時代、L3トンネルが張れるなら、L2 トンネルも張れないのか？と思うのが、人情だと思う。Software Design の記事では、スペースの関係か触れられていないのだが、実は、以下のように ssh のオプション指定によって、tunnnel device (tunX)だけでなく、Encapsulation が Ethernet に見えるような L2 tunnel、つまり tap も作成できる。

$ ssh -w any:any -o Tunnel=ethernet root@remote_host

tap を作成する場合もやはり -w は必要で、指定値は tun の時と同じように使われる。つまり、tap1 なり tap9 なりと（空いていれば)好きな番号の tap device を作れる。 (1/17追記) なお、/etc/ssh/sshd_config や /etc/ssh/ssh_config に TunnelPermit や Tunnel 等の指定値が明示的に記述されていると強制的に tun になってしまうことがあるので注意のこと。

さて、実はここからが本題である。下図のようにHOST1 と HOST2 があるとして、この２台の間は、proxy なり、NATなり、(多段)port forwarding なりの何らかの手段で ssh 接続可能だとする。(多段)port forwarding については前にも書いたので参考まで。

図の赤い線で結んだssh 接続の間には proxy があっても NATがあってもよい。とにかく、HOST1とHOST2の間でssh接続し、上で説明したオプションを指定して tap を接続してしまうことによって、仮想的に１枚のL2面を作れたことになる。（通信品質についてはいわずもがななので、そこはつっこまないように)

さらに図のように、作成した tap をbridge で VMの仮想NICに接続してしまえば、踏み台の向こうの環境で動いているVMに対して、L2レベルで接続できるので、例えば HOST2 から HOST1 上のVMに対してDHCPでアドレスを払いだす…等といったことも可能である。 (HOST2の構成が図とはちょっと違うのだが)実際やってみたら、問題なく動くし、やろうと思えば３ノード以上でフルメッシュ構成にするのも可能である。(ループが発生しないように若干注意が必要だが...)

世の中では、VXLAN だの STT だの NVGRE といった L2 over L3 技術や、SPB やら TRILL (やそれらの拡張)といった L2 over L2 技術で百花繚乱状態だが、こういう poor man's solution もあるよということで（笑)

[ja] pythonからetcdを使いたい

2023-09-09T21:00:00+09:00

今回は、これまでqiitaやらblogspotに記事を書いてきた記事をここに集約するシリーズではなく今年になってから気づいた話。

Kubernetesの制御データを置くのにetcdを使っていることもあって、etcdをデータベースにして分散制御するというのはよくある話だと思います。

Pythonの場合、Pypiで探してみると、元々...というか、etcd 2.x時代くらいまではこれが

Pypi https://pypi.org/project/etcd/
- ソース https://github.com/dsoprea/PythonEtcdClient

使われていたようですが、残念ながら(?)2014年でリリースが止まっており、現在はこちらがつかわれているようです。フルスクラッチで作り直しているようですね。

Pypi https://pypi.org/project/etcd3/
- ソース https://github.com/kragniz/python-etcd3/
- ドキュメント https://python-etcd3.readthedocs.io/en/latest/

Pypiのページにもサンプルが載っていますが、素直で使いやすい仕様で作られているように思います。

さて、私は、3ノードのetcdサーバのどれか１台が倒れても、もろもろ処理継続できる実験をしたかったのでした。

それで当初は、readthedocsのmanualにあるetcd3.Etcd3Clientの仕様を眺めながら、「あれ？3ノードにコネクション張ってFail Overさせたい時ってどうすればいいんじゃ？」とひとしきり試行錯誤の後「もしかしてサポートされてない？」とコードを読み始めたところ、 MultiEndpointEtcd3Client()を使えばいいことがわかりました。

練習用に作ってみたやつ(本記事執筆時点でまだTo Be Updated)がここにおいてありますが、以下のような感じで etcdサーバ1台ずつ Endpoint classを作った上でリストにし、MultiEndpointEtcd3Client() に endpoint= で渡してあげればよいようです。最初、stringで '192.168.1.101:2379' と書いてリストにしていて動かなかったので、あれれ？と思ったのですが、やっぱりソースを眺めていて気づきました(笑)

(snip)
 39     eps = []
 40     if args.endpoints:
 41         for ep in args.endpoints:
 42             eps.append(etcd3.Endpoint(host=ep.split(':')[0], port=int(ep.spl    it(':')[1]), secure=False))
 43     else:
 44         print('Specify -e / --endpoints')
 45         sys.exit()
 46
 47     client = etcd3.MultiEndpointEtcd3Client(endpoints=eps,
 48                                             timeout=args.timeout,
 49                                             failover=True)
(snip)

ちなこのライブラリ、etcdに対する単純なkey/valueのCRUDだけではなく、lock やtransactionも使えるようになっています。便利ですね :)

なお、ある意味これが一番重用な話になりますが、現状Pypiからインストールできる最新版の 0.2.0 は2020/04/01にリリースされたもので、古いです。 MultiEndpointEtcd3Client() も含まれていません。使いたい場合は、ソースからインストールする必要があります。

そろそろ次のリリース出したほうがいいんじゃないの？とissueも切ってみて、賛同の声もほどほどあるようなのですが、さてどうなりますか...

[ja] Linuxでsystem callをhookしたい

2023-09-03T11:00:00+09:00

これまでqiitaやらblogspotに記事を書いてきた記事をここに集約するシリーズ。

今日は2017年にqiitaに書いた記事。前にここに移植したこの記事の続きです。

イントロ

2013年の3月頃にこんな記事を書いたのを思い出したのだが、最近事情でまた動かしてみたら気づいたことがあったのでメモ。

「GNU ld の--no-as-neededと--as-neededオプションについて」

最初によくわかっている方向けの言い訳^H^H^H説明をしておくと、上記はLD_PRELOADを使って hook を行う場合に準備する shared object を作る際に使用するリンカ(GNU ld)の挙動がUbuntu 12.04 前後で若干変更され、ld の option 指定に注意が必要になったという話だった。当時は上記記事の例に書いた通りに動いていたのだが、どうも今は少し事情が変わっているらしいという話である。

まず、やりたいことはこの記事のタイトルの通りである。各種事情により、system call (やlibrary関数)の処理を入り口で横取り(hook)して動きを変えたいことがある。私がこれまで経験した中では、こんな用途があった。以下、すべて「元のプログラムには手を加えない」という前提である。

socket API で通信するアプリケーションを、InfiniBand のSDPプロトコルを使って、内部通信処理を横取りして高速化したい。
アプリケーションが作成するTCPコネクションのオプションを、接続先によって変更したい。
外部から提供されたライブラリの挙動に問題があることがわかったが、ソースがないため改修することもできない。問題を起こす関数の処理を横取りして正しいものに差し換えたい。

このような場合、後述するようなshared object (拡張子が .so なファイル。動的リンクライブラリと呼ばれることもある)を作っておいて、プログラム実行時に環境変数 LD_PRELOAD で指定してやると、やりたいことを実現できる。

文章で説明してもわかりにくいと思うので、絵を描いてみた。以下の図の左側のように動いていたプログラム(application1)の動きを、実行時に右側のように変えるということである。

上図のapplication1 は見ての通り、libFOOBAR.so というライブラリ(shared object)の中の funcA()という関数を使う。(実際のところ、libc.so でもかまわない) やりたいのは、図の右のように、application1 のfuncA()呼び出しを HOOK.so の中の funcA()にすり替え、HOOK.so 版の funcA()の中から前後に必要な処理を行った上で元々の libFOOBAR.so 版の funcA()を呼び出すということである。

hook用shared objectの実際の処理

以下、shared object (上図では HOOK.so)でどんなことをするのか説明する。

構造

hook用shared objectは、大きく以下の3つの要素から構成される。

初期化ルーチン(constructor)
hook関数
終了ルーチン(destructor)

初期化ルーチン(constructor)

main() 関数が呼ばれる前に実行される。
hook関数で使うために横取り対象関数のポインタを検索して保存しておくことが多い。
検索には、dynamic link loader の dlsym() を使う。

hook関数

横取りした後の処理を記述する。
横取りする関数とまったく同じ名前と型定義で記述する。
適当な前処理を行った後で、前述の初期化ルーチンで保存しておいた関数ポインタを使って再び元の関数を呼び出す使い方が多い。たとえば、kernel に渡す前に適当な小細工をしたい場合や、条件に合致しない場合の fallback ルートとしての役割である。図は、このパターンの例である。

終了ルーチン(destructor)

main() 関数からreturn (or exit) した後に実行される。
初期化ルーチンやhook関数で確保した資源の解放など。

ビルド方法

通常の単独実行可能なプログラムとは違い、shared object を作るためのリンカ・オプションを使う。こんな感じである。

$ gcc  -Wall -D_GNU_SOURCE -fPIC  -Wl,'--no-as-needed' -shared -ldl hook.c -o hook.so

前の記事のポイントは、 1. --no-as-needed というオプションが必要になったこと。 2. -ldl``` オプションは--no-as-needed` の後ろになければならないこと。の2点だった。

プログラム例

サンプルは以下にあるものをみてほしい。

https://github.com/thatsdone/junkbox/tree/master/c/hook

write(2)をhookして、本物の write(2)を呼ぶ前に適当なバナーを出しているだけなことがわかると思う。

使い方/実行例

プログラム実行時に、今作ったhook用のshared objectを LD_PRELOAD で指定して実行してやる。こんな感じである。

stack@xenial0:~/hook$ cat -n call_write.c
     1  #include <fcntl.h>
     2  #include <unistd.h>
     3  #include <string.h>
     4
     5  int main (int argc, char *argv)
     6  {
     7    char *str = "Hello, World!\n";
     8      return write(1, str, strlen(str));
     9  }

stack@xenial0:~/hook$ env LD_PRELOAD=./hook.so ./call_write
init_hook: constructor called! 0x7f903d9ca6d0
write: hook!
Hello, World!
fini_hook: destructor called!
stack@xenial0:~/hook$

"Hello, World!" の前に "write: hook!" というバナーが出ているのがわかる。

現在ではどうか？

上述の記事では、/bin/ls に hook.so を使い、ls の結果にヘッダを出す例を書いた。しかし、最近また動かしてみたところ、少なくとも Ubuntu Xenial の /bin/ls では write(2)をhookできないことがわかった。

stack@xenial0:~/hook$ ls
call_syscall.c  call_write.c  hook.c   hook.so       call_syscall  
call_write      hook2.c       Makefile

stack@xenial0:~/hook$ env LD_PRELOAD=./hook.so ls
init_hook: constructor called! 0x7f4bdece36d0
call_syscall.c  call_write.c  hook.c   hook.so       call_syscall
call_write      hook2.c       Makefile
stack@xenial0:~/hook$

"init_hook: constructor called! ...." の後にもう1行バナーが出るはずなのだがおかしい。実際、strace してみると、確かにwrite(2)が呼ばれているではないか...なんで？

stack@xenial0:~/hook$ strace -ewrite ls
write(1, "call_syscall\tcall_write    hook2"..., 44call_syscall call_write    hook2.c  hook.so
) = 44
write(1, "call_syscall.c\tcall_write.c  hoo"..., 47call_syscall.c       call_write.c  hook.c   Makefile
) = 47
+++ exited with 0 +++
stack@xenial0:~/hook$

...というわけで、ちょっと調べてみた結果が以下である。

/bin/ls は、write(2)を直接使わず、fwrite(3)を使う。
fwrite(3)は、write(2)を直接使わず、syscall(2)を使う!?
strace は syscall(SYS_write,...) とやった場合も write(2)を呼んだと表示する。
この方法で syscall(2)もhookできる。

余談があと2つある。

上のlsの例ではdestructor が出すメッセージが出ていない。実はこれは前の記事を書いたときから問題なのだったorz 真相は、strace してみるとわかるが、ls の main() 関数が return (or exit) する前に標準出力(fd=1)をclose(2)しているからである。
サンプルの hook.c は printf(3) を使っているので、この中で write(2)が呼ばれて、write(2)のhookが2回出るはずなのではないか？と思うかもしれない。fwrite(3)と同じようにsyscall(2)が使われている可能性もあるが、write(2)が使われていたとしても、printf(3)とwrite(2)は同じバイナリ(libc.so)にふくまれており、既に参照先が解決されているため、LD_PRELOADの枠組みでは横取りできないのである。(systemtap みたいなことをすれば話は別)

まとめ

バイナリをいじらずに system call やライブラリ関数の呼び出しを hook することができる。
作法にのっとった shared object を作っておいてプログラム実行時に環境変数 LD_PRELOAD で指定してやる(昔からある)方法は、今でも有効。
しかし限界もある上に、バイナリ側の実装が変わるとうまく動かないこともあるので注意が必要。

[ja] なんちゃってPrometheus ExporterでGPU利用率を採取する

2023-09-02T20:30:00+09:00

今回はだいぶ前に作ったものの話。

話は2020年にさかのぼります。当時、vSphereで動くGPU関連製品を使った検証をしていました。 GPUはNVIDIA製ですが、検証対象の製品自体は独立系のものでした。

CPU等の他のmetricsについてはPrometheusで一元収集していたので、自然な流れで当該GPUの利用率もPrometheusで収集できないのかと思いました。…が、独自仕様の製品を買ってくれと言われ、しかもいいお値段だったので、それなら自分で作ればいいじゃんと考えたのでした(笑)

まず、その製品はESXi Shell上でnvidia-smiが使えるようになっていました。

よく知られているように、nvidia-smiを内部から呼び出してGPUのmetricsを返すExporterは複数存在し、私はPGMEを使っていました。 PGMEは、一般的なPrometheus Exporterと同様にGo言語で書かれており、GoのバイナリということはもしかしたらESXi Shellで動くか？と思って動かしてみたらSEGVしてしまいました...orz

さて、どうするか？

ESXi ShellはミニマムなLinux Distributionなわけで、確認したところ Python3 も入っていました。

また、Python には標準で http.serverがついてきます。

…ということは、PGMEと同等の処理処理を、http.serverのGET method処理ルーチンで動かしてやればいいじゃん…と思い至って作ってみたものが以下においてあります。

https://github.com/thatsdone/PyPGME

眺めるとわかるのですが、do_GET() の中で nvidia-smi を呼び出し、結果をparseして、PGME互換のmetricsに整形して返しているだけです。

なお、起動引数はこんな感じで

'-p' : Listen port (default: 19101)
'-b' : Bind address (default: 0.0.0.0)
'-e' : Extended Attribute

最後の'-e'は、オリジナルのPGMEには存在しません。後述のmetrics採取例のように、電力関連の pgme_power_draw と pgme_power_limit を追加出力できるように(後から)しました。

他の目的のPrometheus Exporterが欲しくなった時のひな形としても使えるので、けっこう重宝しています(笑)

metrics採取例(IPはダミー、PyPGME.py 起動時には -p 9101と -e を指定)

$ curl http://192.168.1.1:9101/metrics
# TYPE temperature_gpu gauge
# HELP temperature.gpu of nvidia-smi
temperature_gpu{gpu="Tesla P100-PCIE-16GB[0]"} 32
# TYPE utilization_gpu gauge
# HELP utilization.gpu of nvidia-smi
utilization_gpu{gpu="Tesla P100-PCIE-16GB[0]"} 0
# TYPE utilization_memory gauge
# HELP utilization.memory of nvidia-smi
utilization_memory{gpu="Tesla P100-PCIE-16GB[0]"} 0
# TYPE memory_total gauge
# HELP memory.total of nvidia-smi
memory_total{gpu="Tesla P100-PCIE-16GB[0]"} 16384
# TYPE memory_free gauge
# HELP memory.free of nvidia-smi
memory_free{gpu="Tesla P100-PCIE-16GB[0]"} 16280
# TYPE memory_used gauge
# HELP memory.used of nvidia-smi
memory_used{gpu="Tesla P100-PCIE-16GB[0]"} 0
# TYPE pgme_power_draw gauge
# HELP power.draw of nvidia-smi
pgme_power_draw{gpu="Tesla P100-PCIE-16GB[0]"}  25.63
# TYPE pgme_power_limit gauge
# HELP power.limit of nvidia-smi
pgme_power_limit{gpu="Tesla P100-PCIE-16GB[0]"}  250.00

GPUが2023年にもなってP100なのは愛嬌ということで(笑)

[ja] GNU ld の--no-as-neededと--as-neededオプションについて

2023-08-30T17:20:00+09:00

これまでqiitaやらblogspotに記事を書いてきた記事をここに集約するシリーズ。

今日は2013年(!?)にqiitaに書いた記事になります。これには続きがあるのですが、また別途。

GNU ld の挙動で気が付いたことがあったのでメモ。

例によって少し前置きが長くなるが、端的にいえば、system call 等の他人が提供する関数呼び出しをフックして、処理を横取りしたくなることがたまにある。

例えば、system call の write(2) をフックしたいなら、以下のようなプログラムを書くことになる。

  1 #include <dlfcn.h>  /* これが必要 */
  2 #include <unistd.h> /* 今回hookしたい write(2)が定義されている */
  3 #include <stdio.h>
  4 #include <errno.h>
  5
    ↓ hook したい関数、この場合はwrite(2) と同じようにする。
  6 ssize_t (*org)(int fd, const void *buf, size_t count) = 0;
  7
    ↓main()実行の前に呼ばれる初期化ルーチン
  8 __attribute__((constructor))
  9 static void init_hook()
 10 {
 11     org = (ssize_t(*)(int, const void *, size_t))dlsym(RTLD_NEXT, "write");
 12     printf("%s: constructor called! %p\n", __func__, org);
 13 }
 14
    ↓main()から抜けた後に呼ばれる終了ルーチン
 15 __attribute__((destructor))
 16 static void fini_hook()
 17 {
 18     printf("%s: destructor called!\n", __func__);
 19 }
 20
    ↓write(2)の処理を横取りするルーチン
 21 ssize_t write(int fd, const void *buf, size_t count)
 22 {
 23     int ret;
 24
 25     /*
 26      * Do what you like to do here
 27      */
 28     printf("%s: hook!\n", __func__);
 29     ret = (int)org(fd, buf, count);
 30     /*
 31      * Do what you like to do here
 32      */
 33     return ret;
 34
 35 }

これを、hook.c として保存しておき、hook.so という名前の shared object を作成する。この際、初期化ルーチンの中で、オリジナルの write(2)のエントリを探すのに使っている dlsym(3)のために、-ldl オプション(と -D_GNU_SOURCE)が必要になる。

$gcc -D_GNU_SOURCE -fPIC -shared -ldl hook.c -o hook.so

ぐぐると日本語の解説もいくつか出てくるので参照してほしいのだが、上記のようにして shared object 作り、プログラムの実行時に LD_PRELOAD 環境変数で読み混ませてやれば目的を達することができる。

…はずだった。これまでは。

しかし、上記を(少なくとも) Ubuntu 12.10 上で作成して、実行してみると

  $ env LD_PRELOAD=./hook.so cat /tmp/foo
  cat: symbol lookup error: ./hook.so: undefined symbol: dlsym

…と、エラーになってしまう。オリジナルの write(2)を探すのに使っていて、-ldl でちゃんと指定しているはずの dlsym()が見つからないとか言っている。

なんで？ …ということで確認してみると、当然リンクされているはずの libdl.so がリンクされていない！

  $ ldd hook.so
          linux-vdso.so.1 =>  (0x00007fff8edba000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f06d3745000)
          /lib64/ld-linux-x86-64.so.2 (0x00007f06d3d1a000)

どういうことなの？ …と、ぐぐっていて出てきた以下のトピックを読んで初めて知ったのだが、

http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/005078.html

実は、少なくとも現行の Ubuntu ではリンカ (GNU ld) の挙動が変更されており、以下のように、--no-as-needed というオプションを指定しないといけないことが分かった。（脱線するが、L4のMLって、まだ普通に生きているのだなぁ...と、遠い目になったのはひみつ）

  $ gcc -D_GNU_SOURCE -Wl,'--no-as-needed' -fPIC -shared -ldl hook.c -o hook.so
  $ ldd hook.so
          linux-vdso.so.1 =>  (0x00007fff5494d000)
          libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2d72be2000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d72823000)
          /lib64/ld-linux-x86-64.so.2 (0x00007f2d72ffc000)

赤字部分のように、今度は意図の通り、リンクされている。

現行のデフォルトの挙動は'--no-as-needed'の逆の'--as-needed'で、これは、リンカ(ld)に -ldl 等と渡された shared object の一覧の中から、プログラムの中で実際に使われているシンボルが入っている shared object のみ実際にリンクするという意味になるようだ。

でも、ちゃんと使っているじゃん？…と思うかもしれない。これについては、ソースレベルでは(まだ)未確認なのだが、今回の場合は、_init ルーチンの中で dlsym() を使っており、'--as-needed' の場合に探索される範囲から外れているから…というのが真相らしい。

さて、ここでもうひとつ注意がある。'--no-as-needed' をコマンドラインのどの順番で指定するかには意味がある。この例では -ldl の前に指定する必要がある。実際、-ldl の後ろに指定して shared object を作ってみると

  $ gcc  -g -Wall -D_GNU_SOURCE -fPIC -shared -ldl -Wl,'--no-as-needed' hook.c -o hook.so
  $ ldd hook.so
          linux-vdso.so.1 =>  (0x00007fffea666000)
          libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb722dc8000)
          /lib64/ld-linux-x86-64.so.2 (0x00007fb72339d000)

の通り、また libdl.so がリンクされなってしまうので注意のこと。

ちなみに、以下は man ld からの引用なのだが、赤字のところが　--no-as-neededの場合は逆になる…ということのようだ。そんなの気がつかねーよ...orz

LD(1)                        GNU Development Tools                       LD(1)

NAME
       ld - The GNU linker

SYNOPSIS
       ld [options] objfile ...

DESCRIPTION
  (snip)
       --as-needed
       --no-as-needed
           This option affects ELF DT_NEEDED tags for dynamic libraries
           mentioned on the command line after the --as-needed option.
           Normally the linker will add a DT_NEEDED tag for each dynamic
           library mentioned on the command line, regardless of whether the
           library is actually needed or not.  --as-needed causes a DT_NEEDED
           tag to only be emitted for a library that satisfies an undefined
           symbol reference from a regular object file or, if the library is
           not found in the DT_NEEDED lists of other libraries linked up to
           that point, an undefined symbol reference from another dynamic
           library.  --no-as-needed restores the default behaviour.

最後に、今回作った hook.so を実際に使ってみるとどうなるかも載せておく。

write(2) を使うできるだけ単純なプログラムということで、cat を使って

$ cat /tmp/bar
FOO

というファイルを表示してみると、

$ env LD_PRELOAD=./hook.so  cat /tmp/bar
init_hook: constructor called! 0x7fd48f0228f0
write: hook!
FOO

$

ということで、冒頭のサンプルに書いてある通り、実際の write(2)が走る前に "write: hook!" と自分で追加した処理が実行されていることがわかる。

[ja] MySQL版pgbenchについて

2023-08-27T17:00:00+09:00

これまでqiitaやらblogspotに記事を書いてきた記事をここに集約するシリーズ。

今日は2017年にqiitaに書いた記事から。

とはいえ、2013年2月(10年以上前！)に書いた記事の残TODOの自分へのリマインドなので、そんなに沈めていたのか…と目が遠くなります。(苦笑)

MySQL版のpgbench(ざっくり、TPC-B likeなコンパクトなベンチマーク)って、需要はありそうな気もするのですが、そうでもないんですかねぇ。

(これは、自分にプレッシャーをかけるためのメモです)

2013年の2月にこんな記事を書いたのを思い出した。

「MySQL版の pgbench ってないの？」

当時、MySQLに軽く負荷をかけてみる必要が発生し、sysbench 付属のアレだともともとSQLレベルのdeadlockが発生する性質のものなので、当時やりたかったことには使えず、PostgreSQLのpgbenchみたいなお手軽なやつがないかなー…と思って探したら MySQLユーザー会の有志の方が昔(2004年!?)移植したものを発見し、2013年当時でも1行手直しするだけで動いたという話だった。

そして、続編がこれである。

「python 版 mysqlbench」

これは、当時 python の修行がてら上記の MySQL版pgbench(言語はC言語)を Python に移植しようと思ったのだった。

実は、上記がおいてある git repository には、さらに sqlalchemy を使って移植し(ようとし)たものも置いてあったりする。

仕掛中のまま放り出してあったのだが、この際ちゃんとまとめようよ > 自分

…というわけで、逃げられなくなった...w

(オチは(まだ)ありません(笑))

[ja] OpenStack Nova のスケジューラを作ってみた (NumProjectsFilter)

2023-08-23T23:59:00+09:00

これまで、qiitaやらblogspotに記事を書いてきたのですが、ここに集約しておこうと思います。

まず、2017年にqiitaに書いた記事です。ネタとしてはそのまま今でも使えると思います。

今年の9月の話なので、もうだいぶ前の話になるのだが、そういえば OpenStack Nova のスケジューラを作ってみたので、記録として残しておきたい。

(この記事はOpenStack Advent Calendar 2017参加エントリ...ではありません(笑))

発端

発端は某所でこんな議論をしていたことだった。 OpenStackでつくった基盤があって、その上にいろいろサービスを収容するのだが、運用を真面目に考えていると、当然何かの故障時に影響をどれだけ抑え込めるかも検討することになる。

まず、「サービス」の運営主体というものを考えてみると、管理会計上も組織編制上も独立になっていることが多い。この主体を、OpenStack の Project にマッピングするのはとても自然な考え方だと思う。

ここで、「故障」の話に戻る。この時の議論では、compute が 1 台故障で落ちた時に「影響を受けるサービスの数」に制約をつけられないか？というのが発端だった。この記事を読むような人はよく承知の通り、OpenStack Nova では以下の公式ドキュメントにあるように、様々な FilterScheduler が提供されている。これらをくみあわせればなんとかならないだろうかと、考えた

https://docs.openstack.org/nova/pike/user/filter-scheduler.html

...のだが、NumInstancesFilter のように、ある compute (あるいは host aggregate)の上で作成可能なVM数に制約をつけるFilterはあっても、「ある compute の上でVMを作成可能な Project (にマッピングされたサービス)の数に制約をつける」ことはできないのだった。(実はうまい組み合わせがあって、見落としているだけなのかもしれないが、当時同僚と考えた検討した結果は「無理じゃね？」だった)

そういうわけで、「ないなら作ってみればいいじゃん」と思った結果がここに置いてある。

https://github.com/openstack/nova/compare/master...thatsdone:feature/num-prj-filter

以下、仕様、設計と実装について説明する。

仕様

以下のパラメータを追加した。

max_projects_per_host

意味は「computeノードあたりのVM作成可能プロジェクト数の上限」である。

nova.conf に指定して、システム全体で一意に指定する方法と、
host_aggregate の metadata に指定して aggregate 単位で指定する方法

を用意した。デフォルトは50(projects)とし、普通の運用では不用意にこのFilterが有効になってしまっていても無視できるくらい大きくした。

設計と実装

設計自体は、実は公式ドキュメントに "Writing Your Own Filter" というセクションがあるくらいで、

https://docs.openstack.org/nova/pike/user/filter-scheduler.html#writing-your-own-filter

インターフェースははっきりしており、特に難しいことはない。敢えて言えば、中から使う機能のI/Fだろうか。特に、DBから情報をひっぱってくる場合にどのDB APIを使うべきなのか、類似コードを探しながら検討を行った。

実装だが、仕様が NumInstancesFilter ととても近いため、num_instances_filter.pyをベースにした。しかも、(練習用という意味あいもあったので...という言い訳)比較的 Naive な作りである。(笑) 規模としても、既存ファイルの修正が1つ（パラメータ処理部分）と、新規ファイルが2つ(このFilterの実装本体とテストコード)だけである。

以下、本体部分を見てみよう。

FilterSchedulerの場合、以下にある host_passes() というメソッドが、今、選択対象候補になっているホストごとに呼び出され、各Filterのcriteriaに基づいて True (VM配置可能)またはFalse(VM配置不可能)を返すようになっている。

    def host_passes(self, host_state, spec_obj):
        max_projects = self._get_max_projects_per_host(host_state, spec_obj)

        LOG.debug("DEBUG: NumProjects filter called. "
                  "spec_obj='%s' host_state='%s'", spec_obj, host_state)
        LOG.debug("DEBUG: host_state.host='%s' project_id='%s'",
                  host_state.host, spec_obj.project_id)

        admin = context.get_admin_context()
        filters = {"host": [host_state.host], "deleted": False}
        instances = objects.InstanceList().get_by_filters(admin, filters)

まず、ここで指定されたホスト上で実行中のVMの一覧を取り出している。実は、必要なのは project_id の一覧の集合だけなのだが、あまり低いレベルのDB APIを呼ぶのもよろしくないので、ここではオーバーヘッドは承知で上記のI/Fを使っている。

        LOG.debug("DEBUG: instances='%s'", instances)

        projects = set()
        for instance in instances:
            LOG.debug("DEBUG: uuid='%s', project_id='%s'",
                      instance['uuid'], instance['project_id'])
            projects.add(instance['project_id'])

次に、さきほど得られたVM一覧から project_id を取り出し、set 型にの変数に格納している。

        if spec_obj.project_id in projects:
            # FIXME(thatsdone):
            # This 'True' allows to run multiple VMs on a sigle host.
            passes = True
        elif len(projects) >= max_projects:
            passes = False
        else:
            passes = True

最後に、 1. 要求元のユーザの project_id が、今つくった set 型の変数の中にあれば通過 2. なければ、VM実行中のproject数が閾値を超えているかチェックという順番で判定を行っている。

        if not passes:
            LOG.debug("%(host_state)s fails num_projects check: "
                      "Max projects per host is set to %(max_projects)s",
                      {'host_state': host_state,
                       'max_projects': max_projects})
        return passes

これだけである。

新機能追加も、この程度であればたいして難しくないというのがわかると思う。

課題

この実装で、一応やりたいことは実現できる。ただし、いくつか問題も抱えているので記しておく。

DBアクセスの負荷への影響
- ホストごとに、Instance 型でVM一覧を取り出していること
あるホストで、1つのプロジェクトのVMが2つ以上実行されうる
- あるサービスへの影響も最小化したいというのは自然な要求だからである。ただしこれは、他のFilterで解決すべき問題かもしれない。

これをどうするのか？

もろもろの背景事情もあり、今のところは upstream に提案するつもりはない。 ...が、英語で記事くらい書いてみてもいいかもしれない。

まとめ

OpenStack Nova の FilterScheduler に新しいFilterを追加する例を紹介した。
仕様を決めるにあたって、どういう motivation だったのかを説明した。
まあ私もなんとなく生きていますよ...ということで(笑)
Happy Hacking!!

[ja] Variations of Merry Christmas, Mr. Lawrence (Forbidden Colours)

2022-06-19T23:59:00+09:00

実は「戦場のメリークリスマス」、ロケをやっていた頃にNHK FMで「サウンドストリート」という番組がありました。当時、坂本龍一も担当曜日があったのですが、現地のラロトンガ島から製作・作曲現場の生の雰囲気を伝えてくれていたのでした。

あの頃から大好きです。

さて、この曲、いろんな人がカバー、演奏しているわけですが、気に入ったものの一覧を書き出してみました。 (断続的に更新しています)

オリジナル -- 坂本龍一 & David Sylvian
- Trio 2011 World Tour - Merry Christmas Mr.Lawrence (London)
  - Piano - Ryuichi Sakamoto, Live
- Sylvian & Sakamoto - Forbidden Colours
  - The very original.
- Forbidden Colours by David Sylvian
  - David Sylvian's album.
オリジナル -- ライブほか
- 戦場のメリークリスマス／坂本龍一　矢野顕子
- 1983~1984位の映像らしい。フランスのTOKYO MELODYというテレビ番組(?)由来らしい。しかし、よくこんな映像が残っていたな...
- Ryuichi Sakamoto - Merry Christmas Mr. Lawrence (Live 1987)
  - 1987年NHKホールでのライブ。古筝(Guzheng)はJiang Xiao-Qing
ピアノ
- 【Lv.100】Merry Christmas, Mr. Lawrence
  - ストリートピアノで有名なけいちゃんのコンサートでの演奏。
- 【Merry Christmas, Mr. Lawrence 】Concert in Ukraine
  - 中村天平さんによる、Ukrainaでの演奏。2019年なので戦争前。
- Ryuichi Sakamoto – Merry Christmas, Mr. Lawrence (Piano Cover)
  - いわゆるハラミちゃんw
- I played “Merry Christmas Mr. Lawrence” at a station in Japan and many people stopped to listen.
  - 日本在住のJacobさん。アレンジ多め。スタジオ録音の別演奏
- 【都庁ピアノ】都庁展望室が静まり返る？！美しすぎる戦場のメリークリスマス【Merry Christmas,Mr.Lawrence/あさぴ（朝香智子）】
  - あさぴさん。想いがのっている演奏
- 【都庁ピアノ】「戦場のメリークリスマス」を弾いてみた Merry Christmas, Mr. Lawrence piano by.Ryota Kikuchi
  - 菊池亮太さんはヨーロッパの境界での追悼演奏ほか、たくさんバリエーションがある。
- 戦場のメリークリスマス Merry Christmas, Mr Lawrence / Ryuichi Sakamoto #坂本龍一 Covered by #KanakoHara #はらかなこ
  - YMO好きで知られるはらかなこさん。
- 元自衛官、この曲への想いが熱すぎる【戦場のメリークリスマス/坂本龍一】ストリートピアノ
- Ryuich Sakamoto / Merry Christmas Mr.Lawrence / Jazz
  - Jazzだとこんな感じになるのか...
- 【2台ピアノ】「戦場のメリークリスマス」をアメリカ人と日本人が合奏してみた【よみぃ×Jacob Koller】Merry Christmas Mr.Lawrence
  - ピアノ連弾というのもある。というか個性的すぎる二人での連弾では(笑)
- 'Merry Christmas Mr Lawrence' Steinway Piano Cover by Japanese Otaku. Yomii (Ryuichi Sakamoto)
  - 上記連弾の片方の人。ちょっと変わったアレンジ
- Merry Christmas Mr. Lawrence - Ryuichi sakamoto 4hands piano(by RayKana)
  - 同じくピアノ連弾。ご夫婦らしい。しっとりした中からの盛り上がりがなかなかよい。
- 戦場のメリークリスマス2010 Merry Christmas Mr.LAWRENCE Smooth Jazz Version
  - Another Jazzバージョン
- 戦場のメリークリスマス (Merry Christmas Mr. Lawrence) - 坂本龍一 - Austin Nash Park
  - カナダ出身で現在は京都在住のピアニストのAustin Nash Parkさん。世界の一流ホテルでのパフォーマーというバックグラウンドのためか、派手すぎない味があると思う
  - テクノポリス、ライディーンもすばらしい
- merry christmas mr lawrence but soulful
  - ソウルピアノ？これもすごい...
- Ryuichi Sakamoto - Merry Christmas Mr Lawrence Orchestral Version
  - イギリスのピアニスト/作曲家のLukas Kingさん。
- 戦場のメリークリスマス / 坂本龍一【ピアノ】
  - 元はFlower dance / 転調 ver.からやってきて発見したのですが、間のとりかたというか、ためというか…が独特ですね。しかしerenaさん、中３ですか..
- GKO - Merry Christmas, Mr. Lawrence
  - この演奏は東京らしいけど、アメリカの人かな？何者なんだろう？他にも何本かある模様
ピアノ+ハーモニカ
- Merry Christmas Mr. Lawrence - Cateen & Cy Leo
  - Cy Leoさんは香港出身のハーモニカ奏者らしい
- I played "Merry Christmas Mr. Lawrence" with a world-class harmonica player I met on the street.
  - 2021/12/23 広島の原爆ドーム前での演奏。ピアノのJacobさんは日本在住で日本語ペラペラ。
ストリングス＋ピアノ
- Ryuichi Sakamoto | Merry Christmas Mr Lawrence (with the TSUNAMI VIOLIN)
  - TSUNAMI VIOLINってなんだ？と思ったら、東日本大震災支援だった...
- Sakamoto I Merry Christmas, Mr. Lawrence I Morphing Chamber Orchestra
  - バイオリン、ビオラ、チェロ、コントラバス、ハープの構成。"As a tribute, we are releasing a new interpretation of Merry Christmas, Mr. Lawrence." と書いている通り、ちょっと新しいかもしれない。
- Merry Christmas Mr. Lawrence《聖誕快樂，勞倫斯先生》｜大提琴演奏版｜LuNaMusic
  - ピアノ伴奏のチェロ。台湾の人らしい。日本のアニメ系ポピュラーも好きな模様
- 《Merry Christmas, Mr. Lawrence》坂本龍一電影主題曲《Forbidden Colours》大提琴版本Cello cover 『cover by YoYo Cello』
  - 同じくピアノ伴奏のチェロ。この人も台湾の人のようだ。
- BOSSA CELLI - Merry Christmas Mr Lawrence(Ryuichi Sakamoto Cover)
  - シンガポールのチェロカルテット。チェロも４本いるとすごいなー
- 坂本龍一『戦場のメリークリスマス』Merry Christmas Mr.Lawrence / Ryuichi Sakamoto (Violin) LIVE at 2023.10.21【弓代星空】
  - バイオリン、ピアノ、チェロ。バイオリンの歌いっぷりがすごい。ぱっと見、宝塚っぽいな？と思ったけど、男性だった(苦笑)
- 【映画『戦場のメリークリスマス』】Merry Christmas, Mr. Lawrence / 坂本龍一【ヴァイオリン】
  - ひかえめなんだけど、なかなかよい。ピアニスト側からの映像もあった。戦場のメリークリスマス / Merry Christmas, Mr. Lawrence - 坂本龍一 / Ryuichi Sakamoto【ヴァイオリン&ピアノ】
- 「戦場のメリークリスマス」坂本龍一　ヴァイオリンソロ演奏　戦後80年献奏①
  - しずかな演奏なのだけど、献奏ということで想いが載った演奏。
- 【ピアノ＆チェロカバー】戦場のメリークリスマス　　坂本龍一
  - この演奏、ピアノもチェロもかっこいいなー :)
- "Merry Christmas Mr. Lawrence" Piano and Violin Duet by MAiSA and Jacob Koller
  - さすがこの２人だけあって、ピアノもヴァイオリンもかっこいい:)
ギター
- Kotaro Oshio Merry Christmas Mr Lawrence Live cực chất
  - やはりギターは押尾コータローの印象が強いかなぁ
- REAL DUO / Forbidden Colours Ryuichi Sakamoto - Luciano Damiani, mandolino Michele Libraro ch.
- Kaori Muraji - 村治佳織 - Merry Christmas,Mr Lawrence - Ryuichi Sakamoto's
- Merry Christmas Mr Lawrence (戦場のﾒﾘｰｸﾘｽﾏｽ) - Ryuichi Sakamoto arr. by Hirokazu Sato
  - Singapore出身のクラッシックギタリスト
- Merry Christmas Mr. Lawrence - Ryuichi Sakamoto Played by Christopher Rodrigues
  - クラッシックギター。ブラジルの人らしい。中盤からラテン風？の色が出てくる
- Merry Christmas Mr Lawrence / Ryuichi Sakamoto arr.by Hirokazu Sato | 戦場のメリークリスマス坂本龍一　演奏：高田英里佳
  - クラッシックギター。間のとりかたに情感が載っているように思う
- Ryuichi Sakamoto | Merry Christmas Mr Lawrence | Guitar
  - クラッシックギター。情熱が載った演奏。一つ上の演奏と楽譜は同じとのことなんだけど、ここまで変わるものか。
- [Merry Christmas Mr. Lawrence / Daisuke Minamizawa (acoustic guitar solo)(https://www.youtube.com/watch?v=Y36Zd9LjUiA)
  - わりと広く出まわっているHirokazu Satoさんの楽譜とは違うアレンジ。
ウクレレ
- Merry Christmas, Mr. Lawrence – Ukulele Cover by Feng E
  - この熱量はすごい...
ハープ
- Merry Christmas Mr. Lawrence - Ryuichi Sakamoto - Harp Cover
シロフォン
- Pius Cheung - Merry Christmas Mr. Lawrence by Ryuichi Sakamoto
  - Pius Cheng、すばらしい...
- Kazukos Duo - Merry Christmas Mr. Lawrence / Ryuichi Sakamoto
ソプラノサックス
- Merry Christmas Mr Lawrence (Sakamoto, Arr. Metcalfe)
  - Beautiful Soprano Saxophone lead.
ハンドベル＆パーカッション
- MERRY CHRISTMAS MR LAWRENCE (Handbells & Percussion)
  - これ、練習大変だろうなぁ...
ボーカル
- Paul Potts Ryuichi Sakamoto "Merry Christamas, Mr Lawrence" (Forbidden Colours)
- Utada - "Merry Christmas Mr. Lawrence - FYI" on TV (2009)
  - Trekkie(StarTrekファン)なら、「えっ？」と思ったのではないでしょうか。
- Julienne Taylor - Forbidden Colours (Sylvian / Sakamoto) with lyrics
ギター+フルート+ボーカル
- Forbidden Colours - Merry Christmas Mr Lawrence (R. Sakamoto) INDACO acustica
フルート
- 【13Flutes +】戦場のメリークリスマス/坂本龍一 Merry Christmas, Mr. Lawrence【pic~bass】
  - Rydeenを一人で何多重もやっている人もいたけど、フルートの一人多重録音。シンバルっぽい音は息で出しているのかな？
ハンドパン
- Merry Christmas Mr.Lawrence, Jam
  - つい最近存在に気が付いたお気に入り。Handpan, Violin and keyboardのJam session。このviolin、すばらしい...
バンドネオン
- Ryuichi Sakamoto – Merry Christmas Mr. Lawrence (Bandonegro Live in Japan 2025)
  - バンドネオンはアコーディオンの一種。ピアノ、バイオリン、コントラバスとのカルテット。しかし、このバンドネオンかっこいいな...
和楽器
- 和楽器のプロが戦場のメリークリスマス弾いてみた！ーJapanese traditional musical instruments ensemble "MAHORA"
  - 和楽器バンドではないです
二胡
- 戦場のメリークリスマス - 坂本龍一｜二胡演奏［RYUICHI SAKAMOTO - MERRY CHRISTMAS Mr.LAWRENCE on the Erhu］
  - 二胡の二重奏 w/インスト。坂本龍一本人の演奏で、中国の伝統楽器の奏者と演奏しているやつがあったと思うけど、あれはラストエンペラーだったかな。
そのほか
- Ryuichi Sakamoto - Merry Christmas Mr. Lawreance (Dachs Uplifting Trance Remichs)
  - トランス。ドイツの人？と思ったら、どうも日本人らしい。1:30位からトランスらしくなるってことなのかしら？
- Merry Christmas Mr. Lawrence - Electric Youth Remodel | A Tribute to Ryuichi Sakamoto
  - これはどう分類すればいいのかしら。
- Merry Christmas Mr. Lawrence
  - MAKSIMさんはピアノの人らしい
- Kraftwerk - Merry Christmas Mr. Lawrence / Geigerzähler / Radioaktivität
  - Kraftwerkの2025年のライブ。冒頭が戦メリ
- Merry Christmas Mr. Lawrence (lo-fi Beat)
  - lo-fi beat？
- Ryuichi Sakamoto - Merry Christmas Mr. Lawrence (Apr1x Remix)
  - このremixはなんていうスタイルって呼べばいいんだ？Melodic House & Technoとか？
- 戦場のメリークリスマス　トランスカバー(HEART OF ASIA)
  - Trace Remix。これは日本製かな？
- Ain't Nobody Know-ish Merry Christmas, Mr. Lawrence
  - 星野源の"Ain't Nobody Know"との短いリミックス。30秒くらいと短いんだけど、フルコーラス作ってくれればいいのに
- Merry Christmas, Mr. Lawrence Ft. Frankie Yip (Keyboard and Bamboo Flute)
  - 中国の伝統楽器の「笛子(Dizi)」とピアノによる演奏。独特な音色な笛と思ったら「吹き口の隣にある穴に「笛膜（てきまく）」という竹の薄い膜を貼り付けている」ためらしい。
ダンス
- RYUICHI SAKAMOTO - Merry Christmas Mr.Lawrence Dance Film
  - 演奏ではなくダンス。音楽はこれを使っているらしい。
  - アルバム情報によるとチェロはJakis Morelenbaum、バイオリンは Judy Kang とのこと。
- Stefan Obermaier - Merry Christmas, Mr. Lawrence (Sakamoto)
  - ダンスというかインプロビゼーション？

[ja] Object Storageのベンチマークについて(COSBench編)

2021-10-01T18:00:00+09:00

最近、AWS S3のようなObject Storageの性能評価をせねばならん…という事情があり、「そういえば、COSBenchってかなり昔からあるよなー」と思いつつ、最近あれこれ調べていました。

COSBenchのリポジトリとか、論文とか、 COSBenchの構造等の詳細は開発者による2013年のSNIA SDCの講演の資料を見てもいいかもしれません。

上記のCOSBenchのリポジトリを眺めてみると、2018年でcommitが止まっているので死んでいるのかなー？と思いつつ、ちょっと調べてみたところ、やはり「COSBenchを使って〇〇を評価してみた」というような記事は日本語の記事もそれなりに出てくるのですが、2014~2016年くらいのものがほとんどです。

それでも、2019年にはSNIAの講演 Object Storage Workload Testing Tools でRedHatのエンジニアが使いどころを紹介しているほか、2021年にはTencentが自社Object Storageサービスの性能チューニングのベストプラクティスの一環でWorking with COSBench という記事を出しているようで、まだ買われているようです。

さて、本題は'21/10初頭時点でのリポジトリ…というか、コードの状態の話。 (前置きのほうが長かったかも(苦笑))

ちょっと動かしてみた後、独自APIのObject Storageのドライバを追加しようかとビルドも試してみて気づいたことをいくつか。

Ubuntu 20.04だと素直に動かない
- release版だと0.4.0.0まで戻せば動く
  - 使っているeclipse.equinox.launcherが古いせい
EclipseのGUIから作ったままの設定情報があちこちに残っている
ライブラリの類を全部抱え込んでいる
テストがない
EclipseのGUIからビルドする前提のつくりで、CI/CDに向いていない(mavenにしたい)

などなど

前半に並べたものは既に issue に報告&PRしたりしています。こんなかんじ

それぞれ、こんな問題があって、どう解決すべき…とか、つらつら書こうと思いますが...続きます。

[en/ja] Resuming Again/(ふたたび)再開します

2021-09-23T17:30:00+09:00

It's been one and a half year since I posted the last article.

As the last post was on Feb. 15, 2020, I guess I could not afford to make time for fun things because of physical stress because of COVID-19 and increased meetings.

This year, I have already made presentations twice, and I'm writing including those topics. Maybe I write on Japanese Light-Novels. Haha..

意図して停止していたつもりはなかったのですが、気づいたら前回更新してから約1.5年も経っていました。

前の投稿が2020/02/15なので、思えばコロナで在宅がデフォにってしばらくの間、腰痛がひどくて正直毎日生活しているだけで苦痛だったのと、在宅生活に体が慣れた後は出退勤の移動コストがなくなってずっと仕事(というか、会議(笑))の量が増えまくって余裕がなくなっていたせいかもしれません。

今年は、既に2度ほど外部登壇しているので、そんな話もまじえてつらつら書いていこうと思います。ラノベの話題も混ざるかもしれません(笑)

[ja] JSONをParquestに保存するのにApache Arrowを使ってみる

2020-02-15T21:00:00+09:00

事情で表記のようなことを考える必要があり、Parquetをちょっと調べています。

とりあえず、使いたい言語がPythonだったこと、Pandas等とも連携できることを考えて、Apache ArrowのPython bindingを使ってみることにしました。

参考情報

Apache Parquet 公式サイトのHigh Level Document
- 物理pフォーマット(の概要)の解説も出ています。
Apache Arrow ドキュメント
Apache Arrow(PyArrow)を使って簡単かつ高速にParquetファイルに変換する
- Athena の CTAS (Create Table AS)では、デフォルトではParquetで保存されるらしい。
Python: Apache Parquet フォーマットを扱ってみる
Conversion of JSON to parquet format using Apache Parquet in JAVA
- Javaの場合

インストール

大人の事情でCentOS7系で動作確認したかったので、Pythonは(未だに)2.7系を使っています(苦笑)

Apache Arrow自体は新しいものを使いたかったので、virtualenv を使って以下のようにお手軽に作成しました。

$ virtualenv venvs/arrow
$ source venvs/arrow/bin/activate
$ pip install pyarrow

とりあえずやってみたこと

以下のようなテストデータを作って

{
    "key1": 1,
    "key2": "value2-1",
     "key3": ["value3-1", "value3-1"]
}

以下のようなプログラムで試しました。

import pyarrow.parquet as pq
from pyarrow import json as pajson

table = pajson.read_json('test.json')

print('==================write table')
pq.write_table(table, 'test.parquet')

print('==================using parquet.read_schema')
schema = pq.read_schema('test.parquet')
print(schema)

実行するとこんな感じになります。

$ python test.py
==================write table
==================using parquet.read_schema
key1: int64
key2: string
key3: list<item: string>
  child 0, item: string
metadata
--------
OrderedDict([('ARROW:schema', '/////wgBAAAQAAAAAAAKAAwABgAFAAgACgAAAAABAwAMAAAACAAIAAAABAAIAAAABAAAAAMAAACcAAAAXAAAAAQAAACA////AAABDEAAAAAQAAAABAAAAAEAAAAIAAAAsP///6D///8AAAEFFAAAAAwAAAAEAAAAAAAAAMz///8EAAAAaXRlbQAAAAAEAAAAa2V5MwAAAADU////AAABBRgAAAAQAAAABAAAAAAAAAAEAAQABAAAAAQAAABrZXkyAAAAABAAFAAIAAYABwAMAAAAEAAQAAAAAAABAiQAAAAUAAAABAAAAAAAAAAIAAwACAAHAAgAAAAAAAABQAAAAAQAAABrZXkxAAAAAAAAAAA=')])

後述の通り、先にスキーマを作らなくても動くのかどうか確認したかったのですが、入力に従ったスキーマが作成されているようです。

余談ですが、1レコードしかないので、サイズはこんな感じになりますね(苦笑)

$ du -b test.json test.parquet
80      test.json
232 test.parquet

TODO

圧縮を試す
複数レコード格納する
- 後述のトップレベル名無し配列の件も調べる
事前にスキーマを定義した場合と動的に作成させた場合の違いの確認
スキーマにないelementが現れた場合の挙動の確認

TIPS(というか気づいたことのメモ)

スキーマは事前に準備しなくても動く

確かに動くのですが、これで最適なのか、確認要。(TBD)

pyarrow.json では Objectのネストはできない

以下の例では "key4"の値はさらにObject(Pythonではdcit)になっていますが、これはpyarrow.json.read_json()に食わせるとエラーになるようです。

{
  "key1": 1,
  "key2": "value2-1",
  "key3": [
    "value3-1",
    "value3-1"
  ],
  "key4": {
    "key41": 4,
    "key42": "value42"
  }
}

JSONで許されているトップレベルの名無しArrayは通らない

JSONの規格上、以下のようなデータは許されているのですが、

[
  {
    "key1": 1,
    "key2": "value2-1",
    "key3": [
      "value3-1",
      "value3-1"
      ] 
  },
  {
    "key1": 2,
    "key2": "value2-2",
    "key3": [
      "value3-2",
      "value3-2"
    ]
  }
]

しかし、こんな感じでエラーになります。これは、Arrayの要素を1つに減らしても同じです。

$ python test.py
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    table = pajson.read_json('test3.json')
  File "pyarrow/_json.pyx", line 193, in pyarrow._json.read_json
  File "pyarrow/error.pxi", line 84, in pyarrow.lib.check_status
pyarrow.lib.ArrowInvalid: JSON parse error: Column() changed from object to array in row 0

続きます。

[ja] Jupyter Notebook Dynamic Plot

2020-02-13T23:00:00+09:00

Jupyter Notebookを使っていて、どんどんあたらしい結果が出てくる場合等、描画結果を動的に更新したいと思って調べたメモ。

Plot dynamically changing graph using matplotlib in Jupyter Notebook
- このやりとりによると、自前でやる方法もいろいろあるようだが、matplotlib の animation を使うのが一番基本なのかな。
Developing Advanced Plots with Matplotlib : Interactive Plots in the Jupyter Notebook | packtpub.com
- ipywidgets　を入れて使う方法。すごく詳しいライブ解説。
Interactive Visualizations In Jupyter Notebook
- Plotly と ipywidgets　を入れる方法。
Attempt to create a dynamically changing plot in console and notebook
- こんな matplotlib の issueを見つけたのだが、まだopen状態のようだ...

[ja] Light Novels (3)

2020-02-12T23:30:00+09:00

前にも書いたラノベ話の続き。

異世界ファンタジーものは、これでもか…と似たような話がてんこ盛りなわけですが、それでも「その発想はなかったわー」というのがけっこうあったりします。そういうものをいくつか。(再掲も含みます)

モニカの奇妙な相棒　～　最強スキルは、俺自身！？　～
- 私が一番好きな話です。前にも挙げたのですが、タイトルが変更になっています。転生ものですが、普通は主人公本人に転生するところ、転生先のファンタジー世界のキャラクタ(主人公)が持つ「インテリジェント・スキル」に転生するのです。作品世界も壮大で、面白いです。…が、この発想はなかったわー(笑)
勇者→魔王→勇者→魔王の順で転生してきた勇者、疲れたので役目を放棄する
- 主人公のまわり自体はチート&ハーレムな感じでよくあるパターンですが、タイトルの通り、勇者→魔王→勇者→魔王と４回転生した後で、女神様にもう一回勇者に転生してくれと言われてキレたあげく、女神様を倒そうとするところから話が始まります。いや、その発想はなかったわー。(笑)
まりんこ！～立ち塞がる敵はすべて倒す！不屈の悪役令嬢は異世界を海兵隊と駆け抜ける～
- この話も前に単独で取り上げているのですが、ファンタジー世界の登場人物に、なぜか日本のラノベ文化の知識があるアメリカ海兵隊の人が転生し、侯爵令嬢にブートキャンプをほどこすと。いや、この発想もなかったわー(笑)
「九人目」の荷物持ちの手記
- 異世界ファンタジーの作品ではパーティーを組んだ「八英雄」とかよく出てくるのですが、そのパーティーに動向していた「奴隷」だった主人公の手記という体裁。しかも、八英雄たる8名それぞれの暗部を告発するという。いや、この発想もなかったわー(笑)

なお、ありそうでない話の例としてこんな話もあります。

異世界転生したけど日本語が通じなかった
- タイトルの通り、異世界に転生はするけれど、なぜか現地の言語がわかる…という鉄板なパターンに逆らい、この作品世界では、転生した主人公が現地の言語を勉強するところから始まります。現地の言語は作者さんのオリジナルで(たぶん)、本当に新しい言語を作り上げています。読むのが結構たいへんですが、話が進行していくにしたがって、「えっ？そんな世界観だったの？」と驚きが待っています。パロディな姉妹編もあります(笑)

また、面白い話を見つけたら更新しようと思います。

[ja] Kubernetes Patterns

2020-02-11T21:00:00+09:00

BPF本の話も書きかけなのですが、そういえば同僚がSan Diego でもらってきた本の中にKubernetes Patterns: Reusable Elements for Designing Cloud-Native Applicationsもありました。

同じく章構成はこんな感じになっています。

    1. Introduction

Part I : Foundation Patterns

まずは基本パターン…というよりは、見てわかる通り、k8s を使いこなすにあたって押さえておくべき基本概念ですね。

    2 Predcitable Dememands
    3 Declarative Deployments
    4 Health Probe
    5 Managed Lifecycle
    6 Automated Placement

Part II : Behavioral Patterns

プログラムやサービスの挙動に応じたパターン分類。だいたい名が体を表しているように思いますが、ぱっと見て11のStateful Serviceと13のSelf Awarenessの違いって何よ？と思ったのですが、Self Awarenessのほうは、コンテナが自分が動ているpodを意識する必要があるようなケースのためのものです。

    7 Batch Job
    8 Periodic Job
    9 Daemon Service
    10 Singleton Service
    11 Stateful Service
    12 Service Discovery
    13 Self Awareness

Part III : Structural Patterns

Part IIIはプログラムやサービスの構造に基づいたパターン分類。

    14 Init Container
    15 Side Car
    16 Adapter
    17 Ambasaddor

Part IV : Configuration Patterns

プログラムやサービスの設定情報をどう持ってまわるか？に基づいたパターン分類。

    18 EnvVar Configuration
    19 Confiuration Resource
    20 Immutable Configuration
    21 Configuration Template

Part V : Advanced Patterns

進んだトピック。22のControllerと23のOperatorは、いわゆる kubernetes のController/Operatorの解説、24はkubernetesによってアプリケーションをスケールさせる方法、最後の25はここまでの話題とは少し毛色が変わってkubernetes clusterの中でイメージを維持管理する方法論です。

    22 Controller
    23 Operator
    24 Elastic Scale
    25 Image Builder

    Aferword

まとめ。

さて、ここまでざっと本の構造を眺めただけなので、ちゃんと読まなくては(笑)

[ja] BPF Performance Tools - Brendan Gregg

2020-01-29T22:30:00+09:00

海外出張しているうちに、Brendan Gregg の "BPF Performance Tools" が届いていました。:)

前著のまとめを書いている最中ではあるのですが、こっちもまとめようかと思います。(つまり、やっぱり書きかけ…)

本書の構成

まず、目次の章レベルの構成は以下のような感じになっています。

Part I : Technologies
    1 Introduction
    2 Technology Background
    3 Performance Analysis
    4 BCC
    5 bpftrace
Part II : Using BPF Tools
    6 CPUs
    7 Memory
    8 Filesystems
    9 Disk I/O
    10 Networking
    11 Security
    12 Laguages
    13 Applications
    14 Kernel
    15 Containers
    16 Hypervisors
Part III : Additional Topics
    17 Other BPF Performance Tools
    18 Tips, Tricks and Common Problems
Part IV : Appendixes
    A BPF Trace One-Liners
    B BPF Trace Cheat Sheet
    C BCC Tool Development
    D C BPF
    E BPF Instructions

Part Iで大事なのは3章の3.2節"Performance Methodologies"でしょうか。この3.2節に相当する内容は、前著では2章すべてをあててかなり包括的に性能解析の考え方を説明していたのですが、本書では必要最小限のかなりコンパクトな量におさえています。 Part Iではそのほか、1章で全体像、2章でBPFそのものと関連コンポーネントの紹介、4章で"BCC" (BPF Compiler Collection)と題してBPF関連の開発ツールについての紹介、5章が一番よく使われるツールで"bpftool"の詳しい解説になっています。

Part IIは、前著でいうと5章以降の、"Application"や"CPU"といった具体的な切り口に即したBPF関連ツールの使い方の紹介です。なお、15章のContainersと16章のHypervisorsは、前著にも含まれないトピック自体新しい内容なので、最初は全体を流す人も読んだほうがいいかもしれません。(というか私もそうします(笑))

Part IIIの17章は "Other BPF Performance Tools" とはなっているのですが、Prometheus等のモニタリングツールとの組みあわせや、kubernetes との連携話もあり、読み飛ばせません。また、18章も "Tips, Tricks and Common Problems" というタイトルが示すように、実用上おさえておきたい勘所が載っているようです。

ところで、ここまであたかも読了したような書きぶりですが、読みながらメモっています。なので、当分は更新が続くと思います。

留意事項:Ubuntu 18.04(Bionic)でのインストール

本書も武内さんの本と同じように「試して理解」するのが重要だと思いますが、現時点でUbuntuで使いたい人に、インストールで一点留意事項があります。

まず、インストール方法は4.3節の"BCC Installation"で各種distroでのインストール方法が解説されています。

Ubuntuの場合はuniverseにbpfcc-toolsというパッケージ名で入っているのでこれを入れてもよいのですが、特に 18.04(Bionic)付属のものは古いので、できれば新しいものを使いたいところです。4.3.2 節のUbuntu用の説明では、https://repo.iovisor.org/ の apt-line が紹介されているのですが、'20/2時点でメンテナンスが止まっているようです。

調べてみたところ、Colin Ian Kingさんがメンテしているppaから最新版が入れられるようなので、どうしても自前でビルドしたい人以外はこちらを使うとよいでしょう。

https://launchpad.net/~colin-king/+archive/ubuntu/bpftrace-backports

以下の手順でインストールできます。(bpftraceも一緒に入れてください)

sudo add-apt-repository ppa:colin-king/bpftrace-backports
sudo apt-get update

sudo apt-get install bpfcc-tools bpftrace

性能分析の方法論

一番大事なところ(だと私は思う)、性能分析の方法論は3.2節で解説されています。

具体的には以下の通りですが、1) 問題を定義する、2) 段階的詳細化、3) 構造の理解の上でリソースの状態の分析…と、もっともな内容になっています。

3.2.1節 Workload Characterization
3.2.2節 Drill-Analysis
3.2.3節 USE Method
3.2.4節 Checklists

チェックリストで定型化するのはサポート部隊等でよく取られる手段ですが、直後の3.3節ではLinuxの場合に1分でできるチェックリストの実例ということで以下のようなコマンドが挙がっています。

uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top

本書で詳細に解説される bpfcc-tools 付属の各種スクリプトやツールで同等のことはできるのですが、上記は大体どんな環境にも入っていますし、併用するのも有益でしょう…という記述もあります。

[ja] Methodologies of Systems Performance - Brendan Gregg

2020-01-14T00:01:00+09:00

Brendan Gregg の "Systems Performance: Enterprise and the Cloud" という本があります。 (翻訳はこちら) 言わずと知れた DTrace の作者が書いた本で、全体的な考え方から、CPU・メモリ…等と、具体的な観点ごとに包括的かつ詳細に解説されているので非常によい本です。軽い勉強会みたいなやつで使おうと思って、まずは方法論(Methodology)が書いてある2章のまとめを作っています。 …が、書いてみたら、結局、目次を追っていくのが一番いいのかなー…という結論に（笑）

なお、昨年末に"BPF Performance Tools"という新しい本も出ていて買ったのですが、私は発送待ち状態です。いつ日本に来るんでしょうか？(苦笑) まあ、eBPF/XDPについてはこれも読んだので、まあぼちぼちでいいっちゃいいのですが。(笑)

一番大事なところ - 方法論の章(2章)の構成

方法論(Methodology)は2章になります。この章だけでけっこうな分量になるので、まずは全体を俯瞰するという意味で、目次構成を眺めるだけでも意味があるでしょう。目次の構成をそのまま引用しながらまとめていきます。少し長いですが、落ち着いて眺めてみると頭が整理できると思います。

なお、著者本人は、冒頭でこの章をざっくりまとめると以下の３点であると書いています。 2.5節の具体的な方法論と、これらを使うときに使う具体的な Metric の２点が大事なのであって、他はみんなこの２点を使うための背景知識なのだというわけです。

Background
Methodology
Metrics

以下、２章の目次にしたがって見ていきます。(ただし、まだ書きかけ)

2. Methodology ★一番大事な章★

2.1 Terminology ＃まずは用語定義

2.2 Models ＃モデル

2.2.1 Systems Under Test

評価・分析するシステム自体のモデル化しておく。いわゆるSUT。

2.2.2 Queueing System

待ち行列理論 = 数理モデルの基本

ちなみにこんな本もありますね。Performance Modeling and Design of Computer Systems: Queueing Theory in Action

2.3 Concepts ＃基本概念

この節、個人的には項目の選択とか並びが ad hoc すぎるのではないか？という感がありますが、それは別途整理するとして、並んでいる順番に見ていきます。

2.3.1 Latency

一言で「通信遅延」と言っても、測定する場所によって、例えばコネクション接続+データ転送+処理時間…等分解されるのに注意。

2.3.2 Time-Scales

CPUの命令サイクル、メモリアクセス、DISKアクセス…等、モノによってかかる時間のスケールが違うのに注意。

2.3.3 Trade-offs

例えば、I/OサイズとI/O性能・I/Oパターンの関係等、両立しないものの間のトレードオフを知ること。

2.3.4 Tuning Efforts

アプリ～MW～OS～ハードのどのレイヤで性能チューニングを施すのか？一般論としては(アプリに近い)上のレイヤで実施するほど効果は高い。

2.3.5 Level of Appropriateness

性能分析、チューニングにどこまでコストをかけて深堀りするのかは組織としての投資対効果による。

2.3.6 Point-in-Time Recommendations

チューニングパラメータの推奨値は、条件によって変わるものなので「その時点のもの」(point-in-time)と思うべし。

2.3.7 Load versus Architecture

システムの性能に影響するのは個々のソフトの「設定値」だけでなく、システムの構造（アーキテクチャ）に由来することもある。

2.3.8 Scalability

スケーラビリティ＝負荷量に対する性能値のふるまい。ふるまいの変化は、スループットの場合はリニアな伸びが変わるところ、レスポンスは一定値（≒リニア）から徐々に劣化が始まるところで見える。典型的な理由は、(なんらかの)リソースの utilization が 100%に達すること(saturation)。

2.3.9 Known-Unknowns

いわゆるknown-known/known-unknown/unknown-unknown。性能評価を進めるにしたがって、unknown-unknownに気づいていくのに注意。

2.3.10 Metrics

実際に見る具体的な指標。例としては、IOPS、troughput、utilization、latenc等々。忘れてはいけない大事な点として、1) metricの採取自体にもコストがかかること、2) metricの定義や実装そのものに信頼がないようなケースもあること。

2.3.11 Utilization

利用率には「時間(time)ベース」と「容量(capacity)ベース」の２つがある。前者は単位時間あたりに仕事をしていた時間(busy率)で、後者は処理可能な容量に対する割合。特に前者のbusy率の場合、リソースによっては多重処理が可能なケースもあるので、utilization が100%であっても限界とは限らないのに注意が必要。

cloud (というか、仮想化)環境の場合には、non-idle time という見方をしたほうがよいという考え方もある。

2.3.12 Saturation

saturation (飽和)状態とは、処理可能な量を超えて、どの程度のリクエスト(仕事)量が流入しているかを示す程度。処理しきれないリクエストは、待ち行列につながることになる。

2.3.13 Profiling

一般論としては、調べて理解できるような対象システムの「描像」を得ること。実際のシステムの Profiling では、典型的にはサンプリングが基本であって、(サンプル間隔しだいだが)得られる描像は荒い（疎な）ものになるの注意。

2.3.14 Caching

本書では後ろの方でキャッシングとバッファリングの違いの話も出てきますが、ここではキャッシュのヒット率と性能の関係、キャッシュのアルゴリズム(MRU/LRU/MFU/LFU)や、キャッシュされたデータのCold/Hot/Warmという分類(と、キャッシュ暖かさ(Warmth)という用語)が出てきます。

2.4 Perspectives ＃全体像

性能分析には、大きく、1. Resource Analysis と 2. Workload Analysis の2つの側面がある。

1.の Resource Analysisには文字通りリソースの利用状況の分析であり、さらに a) 性能問題の調査と、b) Capacity Planning が含まれる。

2.の Workload Analysisはアプリケーションの構造を鑑みて指標(SLIかな)をどう定義するのか？という話で、典型的には Latency(Response)とThroughputが含まれる。

2.5 Methodology ＃方法論（★一番大事なところ★）

この節は一番大事なところなのですが、2.3 Concepts と同様に、並んでいる順番が少し ad hoc すぎないか？という気がしています。

2.5.1 Streetlight Anti-Method

Anti-Method(やっちゃダメ)な例。意図的な方法論がないケースのこと。適当に探してなんとなく見つかったツールで測定した指標を使うということで、検出された問題は実際のところは問題なこともあるし問題でないこともある。

2.5.2 Random Change Anti-Method

これも Anti-Method。原因になっていそうポイントをランダムに想定し、その条件を問題が消えるまで変え続けるということ。

2.5.3. Blame-Someone-Else Anti-Method

同じく Anti-Method。自分の担当範囲外の部分を見つけて、そこに原因があるという仮説を立てて担当チームに押し付ける。(ごくまれによく採用される方法論...gkbr)

2.5.4 Ad Hoc Checklist Method

定型のチェックリストにしたがう方法。チェックリスト自体は最短時間で多くの範囲をカバーできるが、あくまでその時点での推奨であって、頻繁に更新する必要があるのに注意。

2.5.5 Problem Statement ★最重要★

新しい問題に取り組むときには最初にとるべき方法。以下のような手順で、問題を具体的に書き下して定義していきます。これによって、問題点がわかることも多いです。

性能問題があると考えた理由は何か？
今まで想定どおりに動いていたか？
最近何か変えたか？
問題はlatencyかthroughputの指標で表せるか？
その問題は、他の人やアプリケーションに影響を及ぼしているのか？それとも自分だけか？
環境は？どんなソフトとハードを使っているのか？バージョンは？設定は？

2.5.6 Scientific Method ★重要★

通常の自然科学の研究でとるアプローチ。

課題設定(Question)
仮説を立てる(Hypothetis)
予想をたてる(Prediction)
テスト(Test)
分析(Analysis)

最初の 'Question' は 2.5.5の Problem Statement であって、これが出発点になる。

2.5.7 Diagnosis Cycle ★重要★

Scientific Method と似ているが。仮説をたてる → 計測する → 分析する →　新しい仮説をたてる…という分析的なアプローチ。

2.5.8 Tools Method

手順は「使えるツールのリストを作る → 各ツールで得られる有用なmetricの一覧を作る → 各metricの解釈のルールを作る」。これが完璧というわけではないし、十分とは言えないこともあるが、現実的にはこの方法でリソースのボトルネックやエラー等の問題を検出できる。

2.5.9 The USE Method ★重要★

まず特定のリソースに着目、当該リソース関連のErrorがあるか？、Utilization は高いか？Saturationが発生しているか？の十番で事象の発生有無をチェックし、検出した事象が原因なのかどうか検討する。原因でなければ次のリソースに着目するという手順をとる。

着目すべきリソースは、リソースの一覧表を使う(CPU/Memory/Network/Storage/Controller等)、機能ブロック図(例として図2.13)から考える方法がある。

リソースの種別ごとに様々な metric がある。(表2.5と表2.6)手元のツールで取得できない metric は known-unknownとして意識しておくべき。

CPUのようなハードウェアリソース以外に「ソフトウェアリソース」がある。例えば、mutex lock の衝突数等、thread poolの空き状況等。

解釈の例

Utilization
- きちんと評価するには、待ち行列を使って考えるべし。
Saturation
- 飽和状態が発生しているということは問題な可能性がある。待ちキューの長さ滞留時間を調べる。
Error
- エラーのカウンタが0でなく、数値が増え続けているのであれば調べる価値がある。

2.5.10 Workload Characterization

「ワークロードの説明」をしておくのは、問題点を明らかにするための良い方法。以下の4つを問うことによって説明できる。

Who : 誰が負荷を発生させているのか？ PID？UID？remote IP address？
Why : なぜその負荷が発生しているのか？code pathをstack traceで調べる？
What : その負荷の特徴は？IOPS？throughput？方向(read/write) ？分散(や標準偏差)も込みで。
How : その負荷には時間に依存したパターンがあるか？日時など。

2.5.11 Drill-Down Analysis

いわゆる段階的詳細化。以下の３段階がある。

Monitoring
- 継続的にリソースの監視を行う。
Identification
- 特定のリソースの挙動によって、ありうるボトルネックを特定する。
Analysis
- 根本原因の特定と問題の定量化を試みる。

「なぜは５回くりかえせ」…って、某自動車メーカーでも言っていますね。ただし「５回」自体にはあまり意味はなくて、例えば "human error" で「なぜ」の追及をやめるな…等、あります。

2.5.12 Latency Analysis

１つのリクエストの処理を細かい部分処理に分解・分析していく。根本原因を特定・定量化できるように、最も時間のかかっている部分処理を調べる。

2.5.13 Method R (by Oracle)

Oracleのツール固有の話。SQL Query の 2.5.12 Latency Analysisに相当する。

2.5.14 Event Tracing

システムの動きは離散的なイベントの処理ということができる。ここでいうイベントとは、CPU命令とか、DISKコマンドとか、Networkパケットのような低レイヤのものから、SQLクエリなどもイベントとみなせる。

性能分析とは、これらのイベントのサマリを検討することであり、例えば、単位時間あたりの操作、単位時間当たりのデータ量などが含まれるが、サマリ（集計値）に詳細が埋もれてしまうこともある。

例として、systemcallのトレース(strace)、I/Oトレース(Solarisのiosnoop)、パケットダンプ(tcpdump)が挙げられている。 …が、perf (というか BPF/eBPFや、昔は systemtap)を使うことによって、多彩な種類のイベントをイベント単位で知らべることもできる。

2.5.15 Baseline Statistics

基準になる性能値とその時の各種リソースの値等を採取しておくこと。

これはまあPOCするときの基本ですね。

2.5.16 Static Peformance Tuning

静的性能チューニングは、例えば、NICのportが意図のリンク速度でLINK UPしているか？等の設定、状態を確認していくこと。

2.5.17 Cache Tuning

そもそもキャッシュ機能が有効になっているか？
キャッシュのヒット率/ミス率
キャッシュサイズが動的に変わる場合の現在のサイズ
複数レイヤにキャッシュがある場合、処理をしている一番近くでキャッシュが効いているか？
CPUキャッシュ(L1/L2/L3)の場合、レイヤごとに削れるレイテンシと効果が異なってくる。

2.5.18 Micro-Benchmarking

アプリケーションレベルだと負荷自体が複雑になりすぎて問題点がわかりにくいことも多いが、「ピンポン通信」等の、これ以上分解できないくらい細かい視点でのベンチマーク。

2.6 Modeling

2.6.1 Enterprise versus Cloud

TBD

2.6.2 Visual Identification

性能特性をグラフにしてみると、特徴的なパターンがいくつかある。

Linear scalability (線形)
Contention (競合)
Coherence　(干渉)
Knee point (適切な日本語が見つからないのだが、まあ折れているということ)
Scalability Ceiling (天井にあたったように水平になってしまうこと)

2.6.3 Amdahl's Law of Scalability

いわゆるアムダールの法則。

C(N) = N/(1 + α(N-1))

2.6.4 Universal Scalability Law

C(N) = N/(α(N-1) + βN(N-1))

2.6.5 Queueing Theory - 待ち行列理論

待ち行列大事。典型的には以下くらい？

M/M/1
M/M/c
M/G/1
M/D/1

2.7 Capacity Planning

TBD

2.7.1. Resource Limits

2.7.2 Factor Analysis

2.7.3 Scaling Solutions

2.8 Statistics

統計も大事。だが、TBD。

2.8.1 Quantifying Performance

2.8.2 Averages

「平均値」って何種類もあるって意識していただろうか？

アルキメデスの3平均
- Arithmetric - 算術平均(一番普通に使うやつ)
- Geometric - 幾何平均
- Harmonic 調和平均(Fの定義で出てきますね)
Averages over Time
Decayed Average

2.8.3 Standard Deviationos, Percentiles, Median

2.8.4 Coefficient of Variation

2.8.5 Multimodal Distributions

2.8.6 Outliers

Anomaly???

2.9 Monitoring

2.9.1 Time-Based Patterns

2.9.2 Monitoring Products

Summary-since Boot

2.10 Visualizations

2.10.1 Line Chart

2.10.2 Scatter Plots

散布図の有用性をちゃんと意識している人って少ないような気がする。

2.10.3 Heat Maps

2.10.4 Surface Plot

2.10.5 Visualization Tools

2.11 Exercises

2.12 References

13. Case Study : むかーし、Redis がナニモノかも知らなかった頃の話

[ja] back to basics - SRECon19 EMEA revisited, and beyond

2020-01-13T12:21:00+09:00

さて、SRECon (や、USENIX LISA)では、ここしばらくCore Principles トラックという形で、 SREのチームの作り方やSREチームの運営のしかた…等といった話を多数聞くことができるわけですが、前に書いた記事で少し触れたように、 SRECon19EMEAの特徴だった、運用まわりで使える確立した方法論の話をもう一回振り返ってみます。

まえおき

この記事はあと３回更新します。

まずはポインタの一覧だけ(DONE)
それぞれ解説(みたいなの)を追加
SRECon の本筋の Core Princilple の話を追加
日本発のback to basicな話の事例ということでTPSの話(これは別記事にするかも)

運用まわりで使える back to basic な方法論

とりあえず、私が現地で聞いたセッションの中で気づいたものの一覧だけ。

Systems Theory -システム理論
- wikipedia(ja)
- SRECon19EMEA セッション
  - Speaker : Prof. Leveson, MIT
Control Theory - 制御理論
- wikipedia(ja)
- SRECon19EMEA セッション
  - Speaker : Ted Hahn, TCB Technologies, and Mark Hahn, Ciber Global
Incident Command System - 現場指揮システム
- wikipedia(ja)
- SRECon19EMEA セッション
  - Speaker : Alex Hidalgo and Alex Lee, Squarespace
Fault Tree Analysis - 故障木解析
- wikipedia(ja)
- SRECon19EMEA セッション
  - Speaker : Andrey Falko, Lyft
Formal Verification Method - 形式的検証手法
- wikipedia(ja)
- SRECon19EMEA セッション
  - Speaker : Heidy Khlaaf, Adelard LLP

SRE Core Principles

TBD

TPS : Toyota Production System - トヨタ生産方式

まずはとりあえず、関連情報のリンクだけ。

『トヨタ生産方式』ー脱規模の経営をめざしてー (大野耐一・著)
- https://www.amazon.co.jp/dp/4478460019/
- ISBN-10: 4478460019
- ISBN-13: 978-4478460016
- 1978年5月25日初版発行
参考
- トヨタ生産方式のかんばんja/en
- ソフト開発のカンバンja/en

[ja] Light Novels(2) - Princess Marines

2019-10-29T22:30:00+09:00

さて、私が読んでいるラノベも、例にもれず異世界ファンタジーものが多いのですが、このジャンルはパターン化したものがとても^2多いのも事実。

一部の文章が軽妙で読みやすいものや設定が面白いもの以外は、さすがに食傷気味だったのですが、ひさしぶりに面白いのを見つけました。

これです。

[まりんこ！～立ち塞がる敵はすべて倒す！不屈の悪役令嬢は異世界を海兵隊と駆け抜ける～] (https://kakuyomu.jp/works/1177354054884156287)

話は、いきなりヒロインの公爵家の令嬢が、婚約者だった第二王子様から婚約を破棄されてしまうところから始まります。危機一髪…ということころで、従者の若者が(…といっても系列伯爵家の人間)に現代世界の人間の記憶が覚醒。しかも、覚醒したのはアメリカ海兵隊の少佐の記憶だったのです。

この従者（少佐？）、その場をなんとかおさめた後、主人の令嬢を自立させるためにとった策は、なんと海兵隊の新兵教育(bootcamp)を施すことだったという(笑)

この公爵令嬢、立派に新兵教育を勤め上げ、一人前の脳筋令嬢(?)として婚約破棄のショックを乗り越えて成長していきます。

いやー、悪役令嬢に転生しちゃうパターンの話は、けっこうあるのですが、これは斜め上でした。この先が楽しみです。

[ja] Film: Yesterday

2019-10-07T23:00:00+09:00

Dublinへ行き返りの飛行機の中で久しぶりにゆっくり映画を観ました。

Yesterday という映画ですが、これ、なかなかいいですね。

改変世界…というか、普通に現代世界なのですが、あるとき突然世界中が12秒間 blackout する…という超常現象(?)が発生します。

この超常現象の最中に交通事故にあった主人公は、周りの人が覚えていないナニカを自分だけが覚えていることに気づきます。

実は「ナニカ」はたくさんあるのですが、売れないシンガーソングライターだった主人公にとってはビートルズが自分の記憶の中にしか残っていない…というのは重大なことでした。

紆余曲折を経て、スターダムにのしあがる...けど、永らく応援してくれていた恋人とも離れ...苦悩する主人公の前に現れたのは、他にもビートルズの記憶を残している夫婦だったのです。

さてこの後どうなるか？…というような話です。

主演の Himesh Patel さんの歌唱力もあいまって、オススメです。 :)

ちなみに、この世界、ビートルズ以外にも消えた存在がいくつかあります。例えば、Coca Cola は存在しないので、コーラを飲みたい時は "Pepsi ちょうだい" と言わないといけません。そのほか、Harry Potter も存在しないのですが、ヒロインを演じた女優さんが Lily James さんだと知った時、「あっ！」と思ってしまったのは私だけでしょうか(謎)

ヒント: Harryの両親 (と、長男・長女も)の名前

[ja] Schengen Agreement and Ireland/UK

2019-10-06T01:30:00+09:00

さて、Ireland の Dublin で開催された USENIX SRECon19 EMEAに参加していたわけですが、今回、行きは Frankfurt 乗り継ぎ、帰りは Dusseldorf の乗り継ぎでした。

前に、Air France の CDG 乗り継ぎで Barcelona に行ったことがあるのですが、あの時はCDGで入国審査だったので、今回も同じ…とおもいきや、 Dublin で入国審査だったので(?_?)状態でした。

知人と話していたところ、実は、アイルランドとイギリスはシェンゲン協定に参加していないため、他のEUの国どうしのように最初に入った国で入国審査をするわけではなく、国際線乗り継ぎになるとのこと。知りませんでした。

https://en.wikipedia.org/wiki/Schengen_Agreement

あるいは日本語版を眺めていると経緯がわかります。

陸路でつながった国同士は簡略化したほうが便利だけど、島国はまた事情が異なる…というのがイギリスの意向らしいです。ちな、アイルランドは参加の意向はあるのだけど、北アイルランドとの国境がめんどくさくなるのでまだ実現していないのだとか。

ちな、この記事は Dusseldorf の空港(しかも、Passport Control の外側)で書いています(笑)

[ja] SRECon19 EMEA

2019-10-03T14:30:00+09:00

アイルランドのダブリンで開催中の SRECon19EMEA に来ています。

ダブリンは初めてで、気温をみて寒そう…とは思っていたのですが、10月頭でもう冬みたいな恰好をしている人が多いとは想像しておらず、正直、外は寒いです(苦笑)

初日で一番面白かったのはGoogleの Todd Underwood さんの以下のセッションでしょうか。

All of Our ML Ideas Are Bad (and We Should Feel Bad)

MLを使って運用をラクにしたい…というのはけっこう誰でも考える話で、適用対象としては例えば以下のようなものがあるでしょう

Categorizing/Prioritizing Tickets
Root Cause Analysis
Canary Analysis

しかし、実際に使ってみると...

(MLよりも)もっといい方法ある
データが足りない
ラベル付きのデータが足りない

といった理由でうまくいかないことがよくあります。

Todd さんは、これは流行りのやり方を、深く考えずにそのまま使おうとするからだ…と言います。よく言われる ML というのは、Marketing ML だと。

Todd さんのおすすめはこんなふうにまとめられます。

Think
- あなたのアプリ、インフラ、お客さんをよく知る人に話を聞きましょう。
- そして、それらを理解するためのアイデアを出すためにブレストをしましょう。
Gather
- まずはデータを一か所にあつめる。
- 整理してみないとなにもできないので、とにかく整理する。
Learn
- まずは基本を押さえましょう。
- MLワークロードを動かすプラットフォームは既にたくさんあるので、こういうものを知りましょう。
- そして、集めたデータを使ってプロトタイプをやってみましょう。

もっと先まで踏み込む場合は

Ontology
Epistemology
Metaphysics

の３点を挙げていました。用語は難しいですが、一言で言うと「自分の頭で本質をよく考えろ」ってことですね。 :) 具体的にこうしたらうまくいっているよ…という事例紹介ではありませんが、考え方として、私にはとても参考になったtalkでした。

Day1 だけでも他にもいろいろ興味深い講演がありました。例えば、Network trouble の解析の紹介で、よく聞いてみたら eBPF でがんばってCloud Providerにも認めさせたぜ...という「よくある」話だったりとか(笑) ぼちぼち更新しようかと思います。

Stay Tuned ! :)

2019/10/04 (Dublin現地時間)追記

SRECon19EMEA、無事に終了しました。ハリケーンが来ていてアイルランド直撃が予測されいたのですが、大した影響なく済んでよかったです。

closing での主催者の話によると、今回の出席者は約700名とのこと。3月のNorth Americaでは4桁に届くでしょうか。

3日間終わってみての所感は、初日のkeynoteのLeverson教授の Systems Theory からはじまり、 Control Theory (制御理論)、Fault Tree Analysis といった、数十年前に確立された理論を振り返る話が多かったことです。果ては一番最後のセッションが Formal Verification Method...ということで、Program Committee の心意気を感じたように思います。

私は主に Core Principle の Track に出ていました。具体的にこの手法でうまくいったよ…という話もあることはありましたが、むしろ Silver Bullet はない。利用者のことをよく知り、自分の頭で考えるべし。ついてはその指針は…という話を多く聞くことができました。現状の私には非常に参考になる話でした。

3月の SRECon '20 North America はスケジュールの都合で出席できないのですが、来年度もどれかのSREConに顔を出したいと思います。 :)

[ja] Light Novels

2019-09-29T18:00:00+09:00

ここ１年ほど、隙間時間はラノベを読んでいることが多いです。

その昔は、ラノベは敬遠していたのですが、幼女戦記のアニメをチラ見した後、原作を読み、他にも…といろいろ読みはじめたらハマってしまいました(笑)

これまで読んだものはけっこうな量になるのですが、以下はとりあえず印象に残ったもののリストです。そのうちもっと増やすかも(笑)

幼女戦記 (完結済)
- 言わずと知れた「幼女戦記」の原点。転生もの。コミックもアニメも好きですが、私はやっぱりこれが一番面白いですかねぇ。
魔法大学院第三呪術研究室には研究費がない (完結済)
- 研究者ファンタジーとでも言えるでしょうか。これは転生は関係なく、自然科学に魔法とか呪術とかが普通に混ざりこんだ世界での博士課程の学生の奮闘話。「『魔研費』におちた」...とか、泣けます。
辺境の老騎士 (完結済)
- グルメファンタジーとか言われているようです。これも転生は関係なく、辺境で隠居した...はずの老騎士が活躍する話。後半SFっぽくなります。
この争いの絶えない世界で　～魔王になって平和の為に戦います
- 転生もの。転生先で魔王になりますが、よくある異世界ファンタジーとは趣がだいぶ異なります。キーワードは「魔王というシステム」でしょうか。とても面白いです。
公女殿下の家庭教師
- 転生もなしの、普通の異世界ファンタジー。ストーリーが面白いのと、軽妙な語り口で人気があり、書籍版も出ているようです。
転生したらスキルになっていた！？　～　モニカの奇妙な相棒　～
- 転生もの。ただし、普通は主人公本人に転生するわけですが、転生先の魔法ファンタジー世界のキャラクタが使う「スキル」に転生したというのが他と違うところです。これもすごく面白いです。
ジェミノシストーリア　～化学で捗る魔術開発～
- 転生もの。化学研究者がファンタジー系の異世界転生する話。
異世界城主、奮闘中！　～ガチャ姫率いて、目指すは最強の軍勢～（旧題ガチャ姫）
- 転生もの。「仲間、ダイジ！」系、かつハーレムっぽいですが、面白いです。'19/9時点で作者の方は新作に力を入れているようで更新停止中ですが、再開されないかなぁ。
リビルドワールド
- SF。ミュータントが跋扈する未来世界で、旧世界の秘密にヒロイン(?)と一緒に挑むハンターの話。
鉄錆びの女王機兵
- SF。ミュータントが跋扈する近未来世界で、四肢を戦車に接続して戦うヒロインと、不器用なハンターの話。
異邦人、ダンジョンに潜る。
- 転生...ではなく、魔法な異世界に送り込まれたところが違うところ。SFのような異世界ファンタジーのような話。
Hi-G. -ハイスピードガールズディスタンス-
- 21世紀の女子高生(ただし、戦闘素養は抜群？)が2500年後に転移(?)した話。スぺオペ…かな。
神様のモニタリング　～人類滅亡回避のススメ～
- 転生もの。転生させる神様が被転生者のモニタリングをしている…という設定。
放浪者達の狂騒曲
- 転生...というか、だいぶ未来の異惑星(だだし、地球から軍隊を送り込まれて数百年)に転移(?)した主人公が、だいぶ昔に地球から送り込まれたAI搭載野良(?)戦車と現地で頑張る話。アニメ系の各種ネタ満載ですが、私は半分もついていけません(笑)
ソ連の宇宙技術は最強過ぎたのだが、それを西側諸国が完全に理解したのはつい最近だった (完結済)
- ラノベ(?)としては変わりダネ。最初見た時、宇宙技術系の知る人ぞ知るうんちく解説記事だと思ったのですが、まさかweb小説だったとは...(笑)
異世界辺境経営記 (完結済)
- 転生もの。異世界「経済」ファンタジー…かな？
空言ミストノーツ (完結済)
- 異世界ファンタジー。転生なし。この世界観、とても好き。

[ja] BGP in the Data Center

2019-09-21T20:00:00+09:00

一部で話題の O'reily の "BGP in the Data Center" を読んだ。

[https://www.oreilly.com/library/view/bgp-in-the/9781491983416/(https://www.oreilly.com/library/view/bgp-in-the/9781491983416/)

これは面白い…というか、自分が今やってること的にとても勉強になったのでメモ。

日本語の他の方の記事もけっこうあるようだ。

遡ると'14の JANOG33 で Microsoft の人が講演していたりとか。(時期はこの本よりも早い)

https://www.janog.gr.jp/meeting/janog33/program/bgp.html

1. Introduction to Data Center Networks

物理構成の話。L3 Leaf-Spine 型のNWの構成のベストプラクティスの解説。

2. How BGP Has Benn Adapted to the Data Center

物理構成ができたら、その上の routing をどうやるのか？の話。BGP話。

しかし、BGPの Best Path Algorithm が参照する metric が8つあって、それを覚えるのにこんなのがあるとは知らなかったw Cisco(当時?)の Denise Fishburne さんが考えたらしい。

mnemonic	-	BGP metric
Wise	W	Weight
Lisp	L	LOCAL_PREFERENCE
Lovers	L	Locally Originated
Apply	A	AS_PATH
Oral	O	ORIGIN
Medication	M	MED
Every	E	eBGP over iBGP
Night	N	NextHop IGP Cost

(うー、Pelican の調整がまだ不完全で border が出ないな...)

3. Building an Automatable BGP Configuration

各router (というか、TOR/Leaf/Spine等スイッチ)の BGP 設定は、愚直に書くと機器ごとに個別の設定や、個別の機器内でも重複した記述が多数出てくるわけだが、これを自動化のためにカイゼンできるか？の解説。

Spine側のASNの割り当てはちょっと誤解していたところがあった...

4. Reimaging BGP Configuration

3章の解説でもろもろ設定を単純化したとして、まだ以下のような pain point がある。

NW機器間(というか、ホストも含むかな...)のインターフェースに付与して管理するのは大変。
隣(neighbour)のASの定義をいちいち書くのも大変。

一つ目の問題の解決として、(IPv6) Un-Numbered の解説。

二つめの問題の解決として、remote-as 構文の拡張の external / internal を使う方法の解説。

ちな、僕が読んだバージョンの p58 の Figure 4-2 の下半分の図は 10.1.1.0/24 じゃなくて、10.1.2.0/24 だと思う。

5. BGP Life Cycle Mamagement

状態表示でよく使うコマンドのほか、メンテのために停止させたい時の常套手段と、デバッグのやりかた。

デバッグ用の機能を使って、経路計算のロジックを勉強する…というのもあるのか。

6. BGP on the Host

この構成で本格的に動かす場合、ホストも BGP をしゃべることになるわけで、今までのSEとNEという境界もあいまいになるよね…という話。

そのほか、Anycast 話とか、Dynamic Neighbour とか。

そういえば、題材に使われている FRR を使い込む… というタスクもあったのだが、再開せねば...(とおいめ

[ja] Stray Sheep - OpenShift and CloudFoundry

2019-09-14T15:01:00+09:00

こんな記事が話題になっているようだ。

IBM brings Cloud Foundry and Red Hat OpenShift together

オレPaaSはこれだぜ…といって始まったはずが、kubernetes 使うならOpenShift…に言うことが全然変わり、そしてまた Cloud Foundry ですか…迷える子羊さんだなー…というのが第一印象。

とはいえ、API(と、それで制御されるざっくりした構造も…かな)だけ維持して、既存のk8sベースのインフラでCF用に作られたアプリケーションを収容できるようにするというのは自然な発想と言えるかなと思うのだが、この動きって最初から計画されていたのか、それとも Cloud Foundry に大々的に投資していたIBMの意向なのか、どちらなんでしょう？あと、OpenShiftの場合、Kuryr とか使ってOpenStackと並べて動かすみたいな話もあるようだし、ただでさえ重量級な OpenShiftがますます複雑化しそうな雰囲気なのがちょっと...(とおいめ

余談だけど、OpenShift の歴史、特に v1 と v2 の頃ってどんなんだっけ？とググっていたらこんな記事も出てきた。

A brief history of Kubernetes, OpenShift, and IBM

これって、8/1付の記事なのだけど、最初の記事が 9/11-12の Cloud Foundry Summit 2019での IBM による発表の記事なので、情報は先に出ていた...ということですか。

ところで、１つめの記事から、こんな記事もリンクされていた。

[With its Kubernetes bet paying off, Cloud Foundry doubles down on developer experience] (https://techcrunch.com/2019/09/09/with-its-kubernetes-bet-paying-off-cloud-foundry-double-down-on-developer-experience/)

Fortune 500に載る会社の50%以上がCloud Foundry使っているって本当？…というのはおいておいて、 PivotalもCloud Foundryをk8sの上で動かすぜー…なんて言っていたのね。知りませんでした...orz

Pivotal Makes Kubernetes Easier for Developers and Operators

[ja] Science

2019-09-12T23:00:00+09:00

私は物理系の出身ということもあって、テクノロジ系だけではなく自然科学系の話題にも興味があります。

最近気になった記事だとたとえばこんなのがありました。

"New Lifelike Biomaterial Self-Regenerates and Has a Metabolism"

生物の要件の１つである自己複製を行うようなものを作り出したと。メカニズムとして、生成と破壊が同時進行する新陳代謝の機能を備えている...というわけで、これって既に、Virus よりも普通の生き物に近いと思うのですが、そうすると、"life-like" と "alive" の境界ってなんだろう...とか思うわけです。

[ja] On OpenSDS

2019-09-03T00:00:00+09:00

最近は趣味と実益を兼ねて OpenSDS をいじっています。

OpenSDS は、名前からして「また新しい Software Defined Storage の実装ですか？」と聞かれるのですが、実は複数のストレージコントローラをたばねるものです。 block storage から出発して、今はNFSのような file storage や Object Storage もサポートしています。

その昔いじっていたOpenStackも sub project がたくさんありましたが、OpenSDS もだいぶにぎやかになってきました。

この中では telemetry と anomaly-detection (仕事的には multi-cloudも) に興味があるのですが、まずは簡単に使えるようにしなくちゃね...ということで、 githubの私のページの activity を見てもらってもわかる通り、 opensds-installer をせっせと直しています。まずは ansible で、helm chart はその次ですかね...

余談ですが、現在、OpenSDSの認証には OpenStack の Keystone が導入されています。 Keystone の場合、認証した結果に各種関連サービスの endpoint の一覧が返却されるという変わった(?)仕様なのですが、このあたり、どこまで integration するかはまだやわらかいようです。

[en/ja] Resuming github pages

2019-09-02T22:50:00+09:00

[en] I'm resuming this github page after several years interval. Recent my (technical) interests are below.

Connected Cars /Autonomous Cars
Open Source
MLOps
etc.

[ja] 数年ぶりにこのページの更新を再開しようと思います。最近の興味は以下のような感じです。

Connected Cars /Autonomous Cars
Open Source
MLOps
等

About Me

2019-09-01T00:00:00+09:00

I'm a kind of software engineer and researcher.

Since April of 2018, I'm working on mainly infrastructure things shooting for DataCenter side of Connected Car/Autonomous Car systems.