NO LIMIT Is. はてな支部'

2024/4/8 北米皆既日食を見てきました

Tue, 16 Apr 2024 23:44:18 +0900

概要
検討
機材選定
移動
前日
当日
撮影プロセス
おまけ

概要

2024/4/8にメキシコのクアトロシネガスで皆既日食を見てきました。皆既日食は2017年にアメリカで見て以来生涯で2度目でした。今回は天気予報が1週間前からずっと悪く、当日も曇りでしたが、薄雲越しにほぼ全過程が見えるというミラクルな展開でした。皆既日食は何度見ても感動しますね。行ってよかったです。

薄雲の向こう側でばっちり皆既日食を捉えました。どうしても雲の影響はありますが、コロナの細かい構造まで撮影できてよかったです。

撮影データ: BORG 107FL, 7108フラットナー, SONY α7S, 648mm, f/6.1, ISO100, 1/1000s～1/2s まで1EV刻みで10枚の画像をステライメージ9でスタックし回転アンシャープマスク, PhotoShop, DenoiseAI

上の写真は回転アンシャープマスクを2回かけて強調しましたが、こちらは1回だけにして眼視のイメージに近づけてみました。眼視だとプロミネンスがもっと赤く見えるのですが、なかなか写真では表現しづらいですね。

第2接触直前のダイヤモンドリングです。薄雲越しなのでちょっとソフトな感じですが、むしろ幻想的な感じになってこれはこれでアリだと思います。薄雲越しだからかゴーストがほぼ出ておらず、綺麗に撮影できたと思います。

撮影データ: BORG 107FL, 7108フラットナー, SONY α7S, 648mm, f/6.1, ISO100, 1/500s, ステライメージ9, PhotoShop, DenoiseAI

第2接触時のプロミネンスです。これも薄雲越しですが、はっきりと写すことができました。

撮影データ: BORG 107FL, 7108フラットナー, SONY α7S, 648mm, f/6.1, ISO100, 1/250s, ステライメージ9, PhotoShop, DenoiseAI

第3接触直前のダイヤモンドリングです。これは動画からの切り出しです。プロミネンスの側から光が現れてとても美しかったです。

撮影データ: BORG 107FL, 7108フラットナー, SONY α7S, 648mm, f/6.1, ISO100, 1/60s, 動画から切り出し, ステライメージ9, PhotoShop, DenoiseAI

第3接触直前のプロミネンスです。右下に出ているプロミネンスが今回見えた中では最大でした。

撮影データ: BORG 107FL, 7108フラットナー, SONY α7S, 648mm, f/6.1, ISO100, 1/60s, 動画から切り出し, ステライメージ9, PhotoShop, DenoiseAI

皆既日食時に広角で撮影していた動画から切り出した画像です。金星と木星は余裕で写っているのでかなり薄い雲だったのだろうと思います。

撮影データ: Tamron 20-40mm, SONY α7C, 20mm, f/2.8, ISO100, 1/60s, 動画から切り出し, ステライメージ9

2017年のときの記事はこちらです。このときは雲一つない快晴でこれ以上ない成功でした。今回は快晴とはいきませんでしたが、事前の天気予報からすると大成功と言っていいと思います。

shakemid.hatenablog.com

検討

2017年にアメリカで皆既日食を初めて見たのですが、2024年にも北米で皆既日食があることはわかっていたので、そのときから計画は始まっていたと言えます。皆既日食を見ると、また見たくなることを、俗に日食病と言うらしいのですが、私は完全に日食病に感染してしまったようです。

2023/10ごろに具体的に今回の旅の検討を始めたのですが、検討ポイントは3つほどありました。

どこで見るのか

今回の皆既日食は、ダラスなど日本からアクセスしやすいメジャーな都市でも見られることがわかっていたので、当初はアメリカで見ようと思っていました。しかし、気候を調べていると、4月のアメリカ東部～南部はかなり晴天率が低いことがわかってきました。せっかく行っても、天候が悪いと皆既日食を見ることはできません。今回の皆既日食はメキシコ～アメリカを通過するのですが、晴天率についてはメキシコの方が高く、観測の成功率を高めるにはメキシコの方が良さそうに思えました。

https://science.nasa.gov/eclipses/future-eclipses/eclipse-2024/where-when/

子供を連れて行くかどうか

私には小学生と保育園児の子供がいます。保育園児の方はさすがに皆既日食を理解できないですが、小学生の方は理科が好きで皆既日食にも興味を示していました。小学生ともなれば、一生の思い出になるだろうと考え、連れて行きたいと思いました。4月の上旬なので、旅程の半分くらいは春休みで、1学期の始業式から数日休むことにはなりますが、大きな影響はないだろうと判断しました。なお、私も当然ながら仕事を休む必要があります。私はただのサラリーマンなので、4月に1週間休むのは多少抵抗がありましたが、私は社畜失格なので堂々と有給休暇を行使することにしました。ここは快く送り出してくれた同僚に感謝です。

旅行の手配をどうするのか

メキシコへ行くとなると、言語の壁や治安の面で、アメリカに行くのとは難易度がだいぶ変わります。2017年のアメリカでは個人で飛行機とレンタカーを手配して適当になんとかなったのですが、メキシコでしかも子連れとなると安全を確保する自信がだいぶなくなりました。個人手配が難しいとなると、旅行会社のツアーが候補になってきます。皆既日食を見に行くツアーはいろいろとあるのですが、ちょっと簡単に手が出ないほどの高価なツアーが多いです。今回については、安全を最優先として、個人手配は諦めました。何社か比較検討した結果、比較的安価で過去実績が良さそうな国際航空旅行サービス社のツアーに申し込むことにしました。

tse2024.kokusaikoku.co.jp

余談ですが、子供を海外旅行に連れて行くとなると、直前に体調を崩すことが心配になります。幸い、わりと丈夫な子供ですが、コロナウイルス・インフルエンザ・ノロウイルスなど、いつ感染してもおかしくない厄介な病気はいくらでもあります。今回は高価なツアーなのでキャンセル料も高価になってしまいます。リスクが高いので、はじめて海外旅行のキャンセル保険に入ることにしました。結局使わなかったですが、心の余裕を買う意味はあったと思いました。

tabiho.jp

機材選定

望遠鏡

望遠鏡は BORG 107FL にしました。通常、10cm以上の口径の望遠鏡を海外に持って行くのは相当大変だと思うのですが、BORG 107FLは対物レンズをコンパクトに収納できるのでカメラバッグに詰め込むことができます。対物レンズを機内持ち込みにできるのは相当のメリットがあると思います。

BORG 107FL と組み合わせる補正レンズはどうするかちょっと悩みました。2017年の時は BORG 71FL と1.4倍エクステンダー（BORG 7215）を使って焦点距離560mmで撮影しました。BORG 107FLと7215を組み合わせると840mmになってしまい、皆既日食を撮影するにはやや長すぎる感じがしました。皆既日食時のコロナを捉えるには600mm前後がよいようなので、補正レンズはフラットナー（BORG 7108）を使うことにしました。これなら、焦点距離648mm、f/6.1になるのでちょうどよいと思いました。

www.tomytec.co.jp

カメラ

カメラは2017年の時と同じく、SONY α7S にしました。2015年に購入したちょっと古いカメラですが、手ぶれ補正がないので軽く、ダイナミックレンジも広いので、皆既日食の撮影には今でも向いていると思います。

難点があるとすれば、バッテリー容量が小さく、日食の始めから終わりまで撮影しようとすると途中でバッテリーの交換が必要になることでした。そこで、USBモバイルバッテリーを接続できるアダプターを導入しました。これなら大容量のモバイルバッテリーを接続できるので、バッテリー切れの心配がほぼなくなります。現状α7Sはほとんど天体写真でしか使っていないので、このアダプターを付けていても特に不自由はありません。

NP-FW50 ダミーバッテリー USB アダプターソニーA7 A7II A7R A7S A7RII A7SII A6000 A5000 A3000 NEX5 NEX3 ILDCカメラ適用バッテリー USBカプラー

Andoer

Amazon

架台

2017年の時はポラリエを使ったのですが、BORG 107FL を使うとなるとカメラ込みで4kgくらいにはなってしまうのでちょっと荷が重くなります。（それでも口径10cm級の望遠鏡としては軽いですが）

そこで、Sky-WatcherのAZ-GTiを使うことにしました。これは赤道儀ではなく経緯台なのですが、皆既日食を撮影するなら特に問題ありません。耐荷重も5kgあるのでまずまず余裕があります。昼間なので自動導入にはあまり期待できませんが、追尾性能は赤道儀とそれほど変わらない精度だと思いました。

Sky-Watcher 天体望遠鏡自動導入 AZ-GTi マウントのみ SW2030020200 【国内正規品】

Sky　Watcher

Amazon

移動

今回の旅は移動がなかなか大変でした。片道で丸2日を費やし、現地に3泊滞在して帰るという弾丸ツアーだったので、日食を見るとき以外は基本のんびりしているしかないという贅沢な時間でした。小学生がこの移動に耐えられるか若干心配でしたが、わりと元気で助かりました。

羽田～ダラス（約11時間）
ダラス～モントレー（約2時間）
モントレーで1泊
クアトロシネガスにバスで移動（約6時間）

前日

前日には撮影のリハーサルを行いました。海外とはいえ、それなりに使い慣れた機材ではあるので、問題なく扱うことができたと思います。

天気は曇りで、太陽の周りに22度ハロが出ていました。なんとか太陽が見えるくらいの薄雲ではあったのですが、なかなか不安になる天気でした。

当日

当日はみなさん朝から撮影機材を設置していました。ホテルの敷地に望遠鏡がずらっと並んで、まるで展示会のようでした。かなり重量のある、タカハシの望遠鏡と赤道儀を持ってきている方もたくさんおられました。私は比較的軽量の機材にしましたが、望遠鏡の口径だけは最大級だったかもです。

皆既日食中は天気予報のとおりずっと曇っていましたが、薄雲を通してずっと太陽が見えていたのでなんとか撮影には成功しました。曇りの天気予報の中でも観測できたのでかなりのラッキーだったのだろうと思います。

小学生の子供も皆既日食を上手に観察できました。比較的年配の方が多いツアーで、小学生は私の子供1人だけだったので、何かと親切にしてもらえてありがたかったです。

日没時にはだいぶ天気が回復して晴れ間が出ていました。この季節の天気の予測はほんとに難しかったようです。プロの手配力には感服しました。

というわけで、2017年に引き続き皆既日食の観測に成功し、二連勝となりました。皆既日食は一生のうちでもそれほど多く見られる機会がないので、元気なうちに見ておきたいと思いました。次に日本で見られるのは2035年なので、それまでは元気でいたいところです。

撮影プロセス

撮影プロセスは2017年のときとだいたい同じですが、ずっと薄雲が出ていたので露出を試行錯誤する必要がありました。2017年の時はBORG 71FL＋1.4倍エクステンダーを使ってf/7.9の光学系でしたが、今回はBORG 107FL＋1.08倍フラットナーでf/6.1の約1段分明るい光学系だったので、薄雲を考慮して概ね2017年の時と同じ露出時間にしました。

第1接触（欠け始め）～皆既1分前まで
- ISO100, シャッター速度1/200sに設定, 念のためブラケット撮影1EVx5枚に設定（1/800, 1/400, 1/200, 1/100, 1/50s で一度に撮影）
- レリーズタイマーで3分おきに自動撮影
- 雲が濃くなってモニターから見えづらくなったらISO200～400程度に変更
皆既1分前～第2接触（ダイヤモンドリング）
- 太陽フィルターを外す
- シャッター速度1/1000sに設定, ブラケット撮影1EVx5枚に設定（1/4000, 1/2000, 1/1000, 1/500, 1/250s で一度に撮影）
- レリーズで手動連写
- ほんとはここで2EVx5枚にするつもりでしたが、露出を試行錯誤しているうちに設定するのを忘れました。今回これが1ミスです。
皆既中1
- シャッター速度1/250sに設定, ブラケット撮影1EVx5枚に設定（1/1000, 1/500, 1/250, 1/125, 1/60s で一度に撮影）
- シャッター速度1/60sに設定, ブラケット撮影1EVx5枚に設定（1/250, 1/125, 1/60, 1/30, 1/15s で一度に撮影）
- シャッター速度1/8sに設定, ブラケット撮影1EVx5枚に設定（1/30, 1/15 1/8, 1/4, 1/2s で一度に撮影）
- レリーズで手動連写各5回くらい
- 薄雲越しで適正露出がよくわからなかったので適当に露出をずらして撮影しました。ここでも2EVにするのを忘れてますが、まずまずいろんな露出の素材を撮影できたのでよかったです。2017年の時は皆既の時間が2分ほどしかなく慌ただしかったですが、今回は4分以上あったのでだいぶ余裕があったように思います。
皆既中2～第3接触（ダイヤモンドリング）
- シャッター速度を1/60sに設定
- 皆既残り1分半ほどでカメラを動画撮影に切り替え
- ここからは肉眼＆双眼鏡での観測を楽しみました
第3接触～第4接触（日食の終わり）
- 太陽フィルターを付ける
- 露出1/200sに設定
- レリーズタイマーで3分おきに自動撮影

おまけ

壁紙用の画像を作ってみました。よろしければ個人利用の範囲でどうぞお使いください。

1920x1080

2560x1440

ZWO AM5のウェイトシャフトをモノタロウで特注してみた

Mon, 05 Sep 2022 23:00:44 +0900

概要
AM5とは？
調査
発注
納品
まとめ

概要

ZWO AM5のウェイトシャフトをモノタロウで特注してみました。結果として純正品の約半額で作ることができたので、何かの役に立つかもしれないと思い共有します。

AM5とは？

AM5とはZWO社から2022年に発売された赤道儀です。波動歯車という方式を採用しており、従来のドイツ式赤道儀とはまったく形状が異なります。ドイツ式赤道儀では、バランスウェイトを使用して望遠鏡とバランスを取る必要がありましたが、このAM5は積載量13kgまでであればバランスウェイト不要です。

astronomy-imaging-camera.com

調査

先述の通り、AM5は積載量13kgまでであればバランスウェイト不要ですが、バランスウェイトを使用すれば最大20kgまで積載することができます。私の手持ちの機材は13kgどころか10kgもないのでウェイトは不要なのですが、将来役立つかもしれないのであってもいいかなと思いました。

ウェイトシャフトは純正品があるのですが、税別5455円と、なかなかいい値段です。天体望遠鏡の界隈では、ネジや棒や板が数千円～数万円することもあるのでそれほど法外な値段でもないような気はしますが、もうちょっとなんとかなるのではないかと思いました。

www.kyoei-tokyo.jp

ウェイトシャフトの仕様を確認すると、オスネジの仕様はM12・ピッチ1.75mmで、シャフトの外径は20mmであることがわかりました。モノタロウで調べてみると、このサイズの金物を特注できることがわかり、レビューを見ると赤道儀のウェイトシャフトとして使っている人もいるのでいけそうな気がしました。

www.monotaro.com

発注

純正品にサイズが近く、半額くらいの値段になるように、以下のようなパラメータで発注することにしました。

項目	値
軸経(D)	20mm
長さ(L)	200mm
P	12mm
G	17mm
V	12mm
N	12mm

こちらのリンクで同じパラメータで作成することができます。2022/9/5の時点で税別2873円でした。

www.monotaro.com

こちらのサービスはかなり素晴らしいのですが、1つ惜しいところがあり、オスネジの根元5mmのところにネジを切ることができません。これだと、オスネジをねじ込んでもちょっと浮いてしまいます。ネジを切らない部分を細くする加工（ヌスミ加工というそうです）ができると完璧なのですが、今のところ解決方法がないので、スペーサーがほしくなりました。内径12mm、外径20mmのものがあればちょうどよかったのですが、見つからなかったので内径12mm・外径15mmと、内径16mm・外径21mmの2個のスペーサーを組み合わせることにしました。税抜189円＋229円＝418円なので許容範囲かなと思います。私は後から別で注文してしまったので送料が別にかかってしまいましたが、3500円で送料無料になるのでいっしょにまとめればよかったと思います。

www.monotaro.com

納品

注文から2週間ほどで納品されました。

丁寧な梱包で届きました。

型番はこんな感じ。型番で仕様がわかるようになっているようです。

オスネジ側。根元の5mmのところにネジが切られていないところがあります。

メスネジ側。

AM5にそのまま取り付けると、ちょっと浮いてしまいます。

スペーサーを取り付けたところ。両面テープで固定すれば十分かなと思います。

スペーサーを取り付ければぴったりです。

反対側は、元々付属していたM12ネジがぴったり取り付けられます。

純正品と見間違うようなぴったり感です。

外径20mmなので、ビクセンGP互換のバランスウェイトなどを取り付けることができます。13kg以上のものを搭載する予定は当面ないので不要なのですが、つけてても害はないと思います。特に、経緯台モードで使うときは若干精神衛生上いいかもしれません。

こんな感じのアクセサリを付けることもできます。

まとめ

モノタロウで特注したシャフトは十分使えそうなことがわかりました。当面使うことはなさそうですが、純正品より安価に作れてとりあえず満足しました。赤道儀用のシャフトをこんなに簡単に特注できるとわかったのは収穫でした。

今回は片側オスネジ、片側メスネジのものを作成しましたが、両側メスネジで、片方にM12の全ネジをねじ込むようにするのもありかもしれないです。強度的には落ちるかもしれないですが。

www.monotaro.com

Switchbot Meterから温度・湿度を取得して、Muninで可視化するメモ

Tue, 26 Oct 2021 22:30:59 +0900

Qiitaに記事を書きました。

Switchbot Meterから温度・湿度を取得して、Muninで可視化するメモ - Qiita

SwitchBot 温湿度計デジタルスマート家電高精度スイス製センサースマホで温度湿度管理熱中症対策アラーム付きグラフ記録アレクサ、Google home、HomePod、IFTTT に対応(ハブ必要)

スイッチボット(SwitchBot)

Amazon

SwitchBot スイッチボットスマートホーム学習リモコン Alexa - Google Home IFTTT イフト Siriに対応 SwitchBot Hub Mini

スイッチボット(SwitchBot)

Amazon

BUFFALO Bluetooth4.0 Class1対応 USBアダプター BSBT4D105BK

バッファロー

Amazon

TP-Link Bluetooth USBアダプタブルートゥース子機 PC用/ナノサイズ / Ver4.0 / 3年保証 UB400

TP-LINK

Amazon

房総半島最南端で天の川を撮影しました

Sat, 14 Aug 2021 01:04:16 +0900

コロナ禍で帰省もままならないので、家族を連れて県内に小旅行してきました。昼間は運転で、夜は天体撮影なのでなかなか肉体に堪えましたが、どちらも幸せなのでよしとしておきます。

maruchiba.jp

撮影スポットは、ここ数年、年に1回は行っている房総半島最南端の野島崎にしました。ここは野島崎灯台があるのでだいぶ明るいですが、肉眼で天の川が見えてアクセスしやすいので私は気に入っています。

房総半島最南端野島崎での天の川(2021/8/10 22:00頃)

今回の成果はこれです。今年は春に天の川を見る機会がなかったですが、8月になって撮影できてよかったです。8月になると22時くらいには天の川が垂直になってかなりの見応えがあります。縦構図がぴったりでした。撮影データは以下のような感じです。

Samyang 24mm f/1.8 FE
SONY α7S
Kenko プロソフトンクリア
Kenko スカイメモSで追尾
f/1.8, ISO3200, 30s x8枚スタック
ステライメージ9でトーンカーブ調整
PhotoShopで背景合成
DenoiseAIでノイズ除去

今回は新機材を2つ使用しました。1つめは Samyang 24mm f/1.8 です。これは今年発売されたばかりの新しいレンズで、星景用に最適との触れ込みなので買ってみました。24mmという画角は、広角ながら天の川の中心部を大きく写すことができて、とても使いやすいと思いました。解放からかなりの解像度で、四隅に若干のコマ収差は見られるものの、ウェブ上で掲載する程度なら十分すぎると思いました。また、f/1.8の明るさは強力で、ISO3200・30秒の露出で十分に天の川を写すことができました。α7SならISO3200程度でもノイズは少ないのでとても相性が良さそうです。

もう1つの機材はKenkoプロソフトンクリアです。これは、星景写真によく使われるプロソフトンAフィルタより控えめなソフトフィルターで、こちらも去年発売された新しめの製品です。テストもせずいきなり使ってみましたが、明るい星のにじみ具合と天の川のつぶつぶ感がちょうどよく、プロソフトンAより好みでした。Samyang 24mmとプロソフトンクリアはとても使い勝手がよいことがわかったので、今後も天の川撮影の主力として使っていこうと思います。

SAMYANG 単焦点レンズ AF 24mm F1.8 FE ソニーEマウントフルサイズ対応フォーカスホールドスイッチ 887506 ブラック

SAMYANG(サムヤン)

Amazon

Kenko レンズフィルター PRO1D プロソフトンクリア (W) 58mm ソフト効果用 001899

ケンコー(Kenko)

Amazon

ステライメージ9+公式ガイドブック

アストロアーツ

Amazon

Kenko ポータブル赤道儀スカイメモS シルバー 455166

ケンコー(Kenko)

Amazon

CentOS 8 を Oracle Linux 8 に切り替える

Thu, 10 Dec 2020 23:49:16 +0900

概要
背景
Oracle Linux とは？
CentOS → Oracle Linux の移行手順
移行してみるテスト

概要

CentOS 8 を Oracle Linux 8 に切り替える方法について記載します。

背景

CentOS 8 の開発が終了し、CentOS Stream に統一されるとの発表がありました。CentOS Stream はRHELのプレリリース版のような位置づけで、特定のバージョンはなくローリングリリース方式となります。RHELの代わりに使えるケースもあると思いますが、特定のRHELのバージョンと合わせた環境がほしいような場合は要件に合わないこともあると思います。

gigazine.net

Oracle Linux とは？

Oracle Linux は、Oracleによって開発されている RHEL Clone のLinuxディストリビューションで、10年以上の歴史があり、今も開発が続いています。 Oracle Databaseを代表とする~~血も涙もない~~ライセンスのOracle製品とは異なり、Oracle Linuxは以下のようなかなり柔軟なライセンス体系となっています。

無料で使用できる。本番環境でも使用できる。（RHELは開発版は無償だが本番では使えない）
サポートが必要なら必要な分だけ購入できる。（RHELは全部購入しないといけない）
RHELやCentOSからも移行してもサポートを受けられる。
Ksplice などの Oracle Linux 独自の機能もある。（要Premier Support）

www.oracle.com

かつてはずいぶん叩かれましたが、当時から今まで柔軟なライセンス体系のまま開発が継続されていますので、CentOSが無くなるなら現実的な移行先として有力なのではないかと思います。

linux.srad.jp

CentOS → Oracle Linux の移行手順

Oracle LinuxはRHELおよびCentOSからの移行方法を公開しています。CentOS 6 or 7 からの移行方法はこちらに公開されていますが、CentOS 8 はやり方が違うようです。

linux.oracle.com

(2020/12/16追記) 移行ツールがCentOS8にも対応しました。このページの内容はさっそく不要になりました。

CentOS 8 から Oracle Linux 8 への移行方法はサポートが必要なところにドキュメントがあるようです。（公開した方がいいと思うなー）

support.oracle.com

サポートが必要な情報を使うのは微妙なので、こちらで言及されていた方法でやってみようと思います。やってる内容はほとんど変わらないと思いますが。

blog.centos.org

移行してみるテスト

VirtualBoxにCentOS 8 をインストールします。

起動時はもちろん CentOSです。

Oracle Linuxのリポジトリから必要なRPMをダウンロードします。

$ repobase=http://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage
$ wget \
  ${repobase}/redhat-release-8.3-1.0.0.1.el8.x86_64.rpm \
  ${repobase}/oraclelinux-release-8.3-1.0.4.el8.x86_64.rpm \
  ${repobase}/oraclelinux-release-el8-1.0-9.el8.x86_64.rpm

そのままだと依存関係でRPMが入らないので centos-linux-release を削除します。

# rpm -e --nodeps centos-linux-release

Oracle Linuxのリポジトリ関連のRPMをインストールします。

# rpm -ivh *.rpm

ociregionファイルを作っておきます。これはOCI（Oracle Cloud）ではリージョンに応じてリポジトリサーバを変えるための仕組みのようです。

# :> /etc/dnf/vars/ociregion

CentOSのリポジトリを削除します。

# dnf remove centos-linux-repos

これで、DNFのリポジトリはOracle Linuxのものになります。

# dnf repolist
repo id                                                repo name
ol8_UEKR6                                              Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream                                          Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest                                      Oracle Linux 8 BaseOS Latest (x86_64)

パッケージをOracle Linuxのものに入れ替えます。CentOSとOracle Linuxのパッケージが混ざってもよければやらなくてもよいです。

# dnf --refresh distro-sync
...
パッケージが入れ替わります

Oracle Linux 独自の Kernel（Unbreakable Enterprise Kernel）を使うこともできます。

# dnf install kernel-uek

EFI bootの場合は再起動する前に grub.cfg を作り直す手順も必要です。

# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

ファイルがあることを確認します。

# ls -l /etc/grub2-efi.cfg 
lrwxrwxrwx. 1 root root 31 Nov  5 14:56 /etc/grub2-efi.cfg -> ../boot/efi/EFI/redhat/grub.cfg

# ls -l /boot/efi/EFI/redhat/grub.cfg 
-rwx------. 1 root root 6544 Dec 11 04:51 /boot/efi/EFI/redhat/grub.cfg

再起動します。

# reboot

再起動後、起動画面はOracle Linuxになりました。

UEKで動作していることがわかります。

# uname -r
5.4.17-2036.100.6.1.el8uek.x86_64

/etc/oracle-release があります。

# cat /etc/oracle-release
Oracle Linux Server release 8.3

Oracle Linuxでは、/etc/redhat-release には Red Hat と書かれてます。

# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)

というわけで、CentOS 8 から Oracle Linux 8 に切り替えることができました。

AWSソリューションアーキテクトアソシエイト(SAA-C02)受験体験記

Sun, 06 Dec 2020 22:45:21 +0900

概要
モチベーション
勉強方法
申し込み～試験
合格後の対応

概要

AWSソリューションアーキテクトアソシエイトの試験に合格しました。勉強期間は4週間ほどでした。幸い1回目の試験で合格することができました。勉強方法や試験の流れをメモしておきたいと思います。

モチベーション

勉強期間は少し特殊な状況でした。2020/10に第2子が生まれたのをきっかけに、会社の制度（妻出産休暇）を利用して4週間の休暇をいただきました。この1ヶ月はほぼ専業主夫状態で、家事全般と上の子（5歳）の世話をしてました。休暇といってもそんな感じなので、まとまった時間を取るのは難しいと思っていましたが、平日は上の子が保育園に行っている間に隙間時間があるかなと思ったので、何か資格でも取ろうかなと思っていました。

aws.amazon.com

私はインフラエンジニア歴は長い部類ですが、クラウドの体系的な勉強はしたことがなかったので、AWSの勉強をしてみようと思いました。体系的に勉強するなら資格の勉強をするのがよいと思ったので、AWSの資格を取得してみようと思いました。AWSソリューションアーキテクトアソシエイトは、AWSの資格の中では中級程度に位置づけられる資格で、AWSのサービスを比較的幅広く理解している必要があります。今は業務上で開発や構築を本格的に行う機会は少ないですが、クラウドについて理解している必要はあるので、私に合っているかなと思いました。

勉強方法

勉強に用いた教材を紹介します。

www.udemy.com

私は主にこの教材で勉強しました。定価は12000円ですが、私が購入したときは1800円くらいでした。Udemyは毎月のように9割引とかのセールをやっているので、セールのタイミングで購入するのがいいと思います。最安だと1200円くらいになります。（定価っていったい...）

このコースでは、ハンズオン形式で実際のAWSのサービスに触れながら学習を進めることができます。今回は、試験に合格することよりも、AWSの様々なサービスに体系的に触れることが目的だったので、ハンズオン形式で勉強できるのがよかったです。AWSをあまり使ったことがなくても、インフラの知識がある程度あれば、タイトルのとおりこれだけで合格することは十分に可能だと思います。

AWSでは頻繁なサービスの変更がありますが、AWSのサービス変更に追随して、こちらのコースの教材も頻繁にアップデートされているようです。変更があった部分は都度説明が追加されていて親切だと思いました。画面が現行のサービスと多少異なる部分もありますが、AWSを使うならその程度は気にしない方がよいということだと思います。

AWSでは高額のサービスも簡単に使えてしまうので、気をつけないと後で高額の請求に驚くということになることがあります。勉強代とはいえ何万円もかかってしまうのはつらいですが、ある程度経験がないと勘所がわかりにくいと思います。このコースでは、月額だと何万円にもなる高額なサービスも使うことがありますが、高額なサービスは使用後すぐに削除するようにアドバイスしてもらえるので、AWSのコストは最小限で済みます。会社等でAWSを使える場合もあると思いますが、このコースではルートアカウントを使ったりするので、できれば自分でアカウントを作って、自分のクレジットカードでコストを気にしながら使った方がよく身につくんじゃないかと思います。結果的に、コース開始から終了まで約3週間使いましたが、AWSのコストは2.09米ドルでした。コーヒー1杯分くらいなので、このくらいなら安心して使えるのではないかと思います。

コストの内訳は以下のようになりました。

EC2が多いですが、EC2自体ではなくNATゲートウェイのコストが高めでした。EC2自体は無料枠で済んでいました。Elastic IPも少し課金されてますが、デタッチして放置してしまったことがあったので課金されてしまいました。デタッチしてすぐに解放すればもう少しコストを抑えられると思います。数十円なので誤差みたいなもんですが。

www.udemy.com

上記のハンズオンにも2回分の模擬試験が付いていますが、さらに6回分の模擬試験を収録した問題集です。こちらも割引があるときに1200円くらいで購入しました。難易度はやや高めなので、これで7割前後得点できていれば本番でも合格できる可能性が高いと思います。

wa.aws.amazon.com

こちらは試験用の教材ではありませんが、AWSソリューションアーキテクトの原典とも言える文書です。技術的なことだけでなく、組織やビジネスのあり方についても書かれていて、AWSの利用者に限らず役に立つと思うので、目を通すといいと思いました。

申し込み～試験

aws.amazon.com

AWSの試験はベンダ系のIT資格でおなじみのピアソンで受験することができます。ウェブから都合のよい日を自分で選んで予約することになります。AWSの試験は、今ではオンラインでも受験することができるようになっていますが、周りに何もない部屋を用意しないといけないなど、私の自宅ではちょっと難しく、東京駅近くの試験センターに行って受験しました。

試験時間は140分です。140分で65問なので、まあまあ余裕があります。70分ほどで全問に解答し、自信がない問題にはマークを付けました。全問回答後、20分ほどでマークした問題を見直し、さらに20分ほどで全問を見直しました。12問ほど自信がない問題がありましたが、8割程度は得点できているだろうと判断し、30分ほど残して試験終了にしました。試験が終わると画面上で合否を確認することができます。無事に合格と表示されていたのでひとまず安心しました。

試験の言語は日本語で受験しましたが、画面上で英語も確認することができます。外資系ベンダの試験としてはそれほど変な日本語ではなかったかなと思いますが、ところどころサービス名や機能名の訳が実際のサービスと異なっているところがありました。日本語に違和感があったら英語を見てみた方がよいと思います。実際にAWSを使うなら英語のドキュメントを読むこともあると思うので、あまり細かいことは気にしない方がいいということだと思います。

合格後の対応

合格の翌日、正式な合格通知がメールで送られてきました。スコアは1000点中775点でした。8割くらいかなと思ったので想定の範囲内ですが、あまり余裕はなかったみたいです。合格するとこんな感じのロゴがもらえます。

www.youracclaim.com

試験に合格すると、模擬試験の無料での受講や、次回の試験の割引などの特典があるので、他の資格の取得を狙ってみてもいいかもしれません。試験に合格はしたものの、AWSのサービス一覧を見ると全く知らないサービスが山のようにあって正直なんもわかりません。AWSサービス多過ぎです。継続的な学習が必要かなと思います。

BORG 107FL + 笠井トレーディングV-POWER接眼部のセットアップ

Mon, 21 Sep 2020 21:00:41 +0900

概要
背景
鏡筒パーツ
重量
7872レデューサとの組み合わせ
7108フラットナーとの組み合わせ
7215テレコンバータとの組み合わせ
直焦点

概要

BORG 107FL と、笠井トレーディングV-POWER接眼部を組み合わせてみたメモです。BORGの各種補正レンズと組み合わせても無限遠が出る組み合わせになっています。

背景

2019年の消費税増税前に駆け込みでBORG 107FLとBU-1のセットを購入していました。シンプルでとてもいい組み合わせのように思ったのですが、BU-1のヘリコイドはアソビがやや大きくピントを合わせづらいと感じたのと、台座が1点支持なので107FLの対物レンズを支えるにはやや心許ないという不満点が出てきました。

天体写真を撮るには接眼部に微動装置がほしいと思ったので、サードパーティ製品も含めて探していたところ、笠井トレーディングのV-POWER接眼部がよさそうかなと思いました。以前はBORGのOEMで発売されていたこともあったようですが、今はより安価になって笠井トレーディングから発売されています。

www.kasai-trading.jp

鏡筒パーツ

鏡筒は以下のようなパーツを組み合わせています。

V-POWER接眼部＋オプション

V-POWERII接眼部L + BORG互換アダプター
ファインダー脚台座

BORGパーツ

80φＬ135ｍｍ鏡筒ＢＫ【7138】
Ｍ77.6→M68.8AD【7801】
M57回転装置DX【7352】
マルチバンド80Φ【7085】 x2個
マルチバンド用スペーサーL20【7020】 x2個
ロングプレート200【3200】
アリミゾ式ファインダー台座ＢＫ【0610】

V-POWER接眼部はBORG互換のアダプター付きの製品があるのでそちらを購入しました。BORGの延長筒はたくさん種類があって迷いますが、各種補正レンズを取り付けてもピントが出る長さとして135mmを選びました。また、ドロチューブ無しでV-POWER接眼部を接続するためにＭ77.6→M68.8AD【7801】も購入しました（買うのを忘れて、後から購入しました）。M57回転装置DX【7352】は元々持っていました。ちょっといい値段しますが、デジカメを取り付ける場合はあった方が便利です。鏡筒バンドはBORG純正にしたのでなかなかいい値段しますが、サードパーティ製品ならもうちょっと安価にできると思います。ファインダー台座はファインダーとガイド鏡を取り付けるために2個付けましたがこれはお好みで。

重量

BORG 107FLの対物レンズは1772gでした。

鏡筒部分は1643gでした。

対物レンズと鏡筒部を合わせると約3.4kgになります。ここに補正レンズも加えるともうちょっと重くなりますが、口径10cm級のアポクロマート鏡筒としては相当に軽いです。さらに分解収納できるので、飛行機での遠征等を視野に入れると非常に有力な選択肢になると思います。

7872レデューサとの組み合わせ

7872レデューサと組み合わせると下の写真のあたりで無限遠が出ます。ドロチューブを24mmほど繰り出した位置でピントが出ているので、135mmより長い150mmの鏡筒でも無限遠が出そうですが、かなりギリギリになってしまいそうです。

7872レデューサは90FLと71FL用なので107FLとの組み合わせはサポートされていませんが、相性はかなり良好に見えます。以下の作例はm4/3のカメラで撮影したものですが、ノートリミングで四隅までシャープです。フルサイズだと四隅が少し流れるらしいです。

ところで、海外では107FL専用レデューサとのセット製品が販売されているのですが、日本では発売されておらず残念です。かなり高価ですがほしい人はいるんじゃないでしょうか。

astrohutech.store

7108フラットナーとの組み合わせ

7108フラットナーと組み合わせるときは、M57/60延長筒M【7603】を使うとちょうど良いようです。下の写真のあたりで無限遠が出ます。

7215テレコンバータとの組み合わせ

7215テレコンバータと組み合わせるときも、M57/60延長筒M【7603】を使うとちょうど良いようです。下の写真のあたりで無限遠が出ます。

直焦点

あまり使うことはないと思いますが、補正レンズを使わない直焦点でも無限遠が出ます。バックフォーカスは十分あるので、天頂プリズムを取り付けて眼視もできます。

BORG 107FL 天体鏡筒セットCR 【6207】

メディア: エレクトロニクス

BORG 107FL 望遠レンズセットCH 【6210】

メディア: エレクトロニクス

M57 回転装置DX 7352 BORG ボーグ

メディア: エレクトロニクス

天体望遠鏡 1.4×テレコンバーターGR 7215

メディア: エレクトロニクス

都会でのM27亜鈴状星雲とM16わし星雲

Sun, 03 May 2020 22:02:25 +0900

概要
主な機材
M27亜鈴状星雲
M16わし星雲
撮影データ

概要

ゴールデンウィークはどこかに遠征しようと思ってましたが、昨今の世界的な新型コロナウイルスのパンデミックの影響で全くそんな雰囲気ではなくなってしまいました。天体観測は屋外でやることなので3密ではありませんが、買い物や食事はするので、旅行するのと大差はないでしょう。

しかし、この状況も裏を返せば、本来どちらかといえばアウトドア趣味と言える天体観測を、自宅でいかに楽しむかということを考えるチャンスとも言えます。というわけで、最新鋭の機材を使って、東京近郊の都会から夏の星雲を撮影してみました。

主な機材

都会で星雲を撮影するにはそれなりの機材が必要です。近年では、アマチュアでもなんとか手の届く範囲の機材で、一昔前のプロを凌ぐような写真を撮れるようになったのでいい時代です。

サイトロンQBPフィルター

都会で星雲を撮影するなら必須アイテムとも言えるフィルターです。光害を強力にカットしつつ、主に星雲が発するHα, Hβ, OIII, SIIの4つの波長を通すようになっています。いくつかのメーカーから似たような特性のフィルターが発売されていますが、価格対性能のよさから人気があるようです。

サイトロンジャパン Quad BP Filter II (クワッドバンドパスフィルター）48mm

メディア: その他

ZWO ASI294MC Pro

ここ数年で一気にメジャーになった感のあるZWO社の天体専用カメラです。高感度のm4/3サイズのセンサーは星雲・星団・銀河などDSOの撮影にちょうどいいです。

ZWO ASI294MC-PRO 11.3 MP CMOS カラー天文カメラ USB 3.0 # ASI294MC-P

メディア: Camera

ZWO ASIAIR Pro

ASIAIR ProはRaspberry Piベースの小型デバイスです。これがあれば、赤道儀のコントロール、オートガイド、撮影などがスマートフォンやタブレットだけでできます。ZWO社のカメラを持っているなら買って損はないと思います。 hoshimiya.com

M27亜鈴状星雲

夏の大三角の中にある夏を代表する天体の1つです。緑のOIIIと赤のHαで光っているのでQBPフィルターとは相性がいいです。遠征してきたのとほぼ変わらない写りだと思います。亜鈴状というよりラグビーボール状に写すことができました。

M16わし星雲

こちらも夏を代表する天体の1つです。主にHαで光っている赤い星雲なのでこちらもQBPフィルターとは相性抜群です。ハッブル宇宙望遠鏡の写真で有名な創造の柱がはっきりと写りました。自宅からここまで写るとは感動ものです。

ハッブルの写真はこちら。自宅からちょっとハッブル気分です。 natgeo.nikkeibp.co.jp

撮影データ

M27もM16も同じ条件で撮影しました。どちらも露出時間はちょうど1時間です。

BORG 107FL + 7108フラットナー (648mm, f/6.1)
サイトロン QBP Filter
ZWO ASI294MCPro （gain390, 冷却0C）
ZWO ASIAIR Proで撮影・オートガイド（30mm, f/4, ASI290MC）
Sky-Watcher EQ5GOTOで追尾
Deep Sky Stacker でスタック（60s x 60フレーム, ダーク20フレーム, フラット20フレーム）
ステライメージ8でトーンカーブ調整等
Topaz DenoiseAIでノイズ除去

撮影風景はこんな感じです。光害がひどいので肉眼では2等星すらよく見えません。

というわけで、最新機材のおかげで、都会でも、月や惑星だけでなく、星雲の撮影も楽しめるようになりました。自宅でできることは増えましたが、天の川などは遠征しないと見えないので、この状況が落ち着いたらまた遠征したいなと思います。

BORG 107FL 望遠レンズセットCH 【6210】

メディア: エレクトロニクス

Sky-Watcher EQ5 GOTO赤道儀（ステンレス三脚仕様）

メディア: エレクトロニクス

ステライメージ8

発売日: 2017/02/15
メディア: DVD-ROM

在宅勤務してました

Thu, 19 Mar 2020 23:31:33 +0900

概要

風邪を引いた後おそらく急性副鼻腔炎で咳が止まらなくなる症状が出て、このご時世でコロナウイルスの可能性もゼロとは言えず、ここしばらく在宅勤務してました。わずか8営業日ほどでしたが在宅勤務してみた感想です。

よいこと

咳が止まらない症状があったので、電車通勤と、オフィスに行く必要がないのは大きいと思いました。咳をしても誰かを気にすることがなく気分的に楽でした。

日常の業務連絡は、SlackやTeamsが定着していたのでそんなに不便に感じませんでした。対面でコミュニケーションしたいときもありますが、文字だと記録が残ったり、自分のタイミングで確認することができたりと、よい面もあると思います。

リモート会議はTeamsを使うことが多かったです。最初はちょっと緊張しましたが、自分も慣れて、みんなも慣れてくると自然と受け入れられたように思います。会議のメンバーの中で、複数人がリモート参加だとやりやすいのですが、自分1人だけがリモート参加だと若干疎外感があった気がします。マイクの品質は大事でした。iPhoneのマイクは専用機器には敵わないものの、かなり優秀だと思いました。

ちゃんと仕事をする気になれるか若干心配でしたが、特にサボる気にはなりませんでした。むしろ、オフィスにいてもPCに向かっていれば仕事をしているのか遊んでいるのかは区別しづらいので仕事をする場所はあまり関係ないのかもしれません。通勤とは一体何なのか、考え直してもいい気がしました。

よくないこと

在宅勤務だとびっくりするくらい動かないです。トイレに行くときくらいしか動かないので、ものすごく運動不足になります。オフィスでは意外と歩いていると思いました。体重が増えるかと思いましたが、動かなさすぎておなかが減らず、昼食をほぼ抜いてたのでむしろ若干減りました。

業務時間はエンドレスになりがちなので、その日の仕事は終わりと決めたらきっぱり終わった方がいいです。オフィスにいても同じかもしれないですが。

まとめ

というわけで、基本は楽しかったです。また機会があればやってみたいです。今回のコロナウイルスの騒動で、日本全国にリモートワークやリモート会議に慣れた人がかつてないほど増えていると考えられるので、ちょっと世の中が変わるんじゃないかな？と思っていたりします。

Anker PowerConf, スピーカーフォン会議用マイク Skype Zoom など対応 24時間連続使用 USB-C接続オンライン会議テレワーク在宅会議用システムウェブ会議テレビ会議ビデオ会議

メディア: エレクトロニクス

Topaz DeNoise AI で天体写真のノイズ除去

Sun, 01 Mar 2020 15:06:07 +0900

[email protected]/dist/css/cocoen.min.css">

概要
M45 プレアデス
馬頭星雲
ばら星雲
天の川
まとめ

概要

最近アマチュア天体写真界隈で流行っている Topaz DeNoise AI というノイズ除去ソフトを使ってみたテストです。 DeNoise AI はこちらからダウンロードできます。1ヶ月間は無料で使用できるのでとりあえずお試し。

topazlabs.com

M45 プレアデス

こちらは、2017/9に戦場ヶ原で撮影してきたM45です。コンポジット枚数が足りていないので拡大するとノイジーですが、DeNoise AIを使うとなめらかになりました。しかもディテールは損なわれていないように見えます。

shakemid.hatenablog.com

馬頭星雲

今度は、2019/12に自宅から撮影した馬頭星雲です。東京近郊のひどい光害の下でよくここまで写ったものだと思いましたが、DeNoise AIを使うとさらになめらかになりました。恒星の周りの赤ハロも目立たなくなってる感じがします。

ばら星雲

同じく、2019/12に自宅から撮影したばら星雲です。これも、DeNoiseAIでディテールを保ったまま、ノイズを低減できているように見えます。

天の川

今度は、2020/2に房総半島最南端の野島崎で撮影してきた天の川です。RAW1枚だけなので拡大するとノイズだらけですが、だいぶなめらかになります。散光星雲のような対象だけでなく、星景にも使えそうですね。

まとめ

話題の Topaz DeNoise AI を使ってみました。想像以上にノイズを除去できて、しかもディテールは保ったままで驚きました。天体写真のコンポジット枚数が足りないとき、もう一押し強調したいけどノイズが気になってしまうときなどに、かなり有効なツールだと思いました。

なお、画像の比較には、Cocoenを使用しました。はてなブログでも、JavascriptとCSSを本文に埋め込んで使用できました。

github.com

# 使い方の例

<link type="text/css" rel="stylesheet" href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/cocoen.min.css">
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/[email protected]/dist/js/cocoen.min.js"></script>

<div class="cocoen">
  <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/shakemid/20200301/20200301140314.jpg" alt="">
  <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/shakemid/20200301/20200301140319.jpg" alt="">
</div>

<script>document.querySelectorAll('.cocoen').forEach(function(element){ new Cocoen(element); });</script>

数字で振り返る、紅白歌合戦けん玉ギネスチャレンジ2019

Sun, 05 Jan 2020 00:33:31 +0900

序章
2019/12/29 リハ1日目
2019/12/30 リハ2日目
2019/12/31 本番
次回への展望

序章

2019年の年末も、2017年、2018年に引き続き、三山ひろしさんとともに、紅白歌合戦のステージ上でギネス世界記録に挑戦させていただきました。今回も、2018年に続いてちょっと分析的な視点で振り返ってみたいと思います。今回は私は最前列の115番を務めさせていただきました。

2018年の振り返りは↓から。

shakemid.hatenablog.com

2018年は、成功必達を命題として、定員124人に対して140名を招集し、選抜を行うとともに、練習で1回でも失敗したらリザーバーと即入れ替えるというかなり厳しい進め方でした。今回は、成功必達と言うよりは、挑戦を楽しむことを重視して、選考や入れ替えは行わないことになりました。事故や急病の際のやむを得ない場合に備えて、数人の控えメンバーだけを確保していました。

そのため、成功の確率は、集まったメンバーの個々の実力にすべて依存することになります。2018年は124人でしたが、今回は125人連続で大皿を成功させるチャレンジなので、125人連続で成功する全体の成功率をPとして、個々の大皿の成功率をpとすると、Pは以下のように表すことができます。

これの意味するところは、125人連続で成功するのは非常に難しいということです。仮に100回中99回大皿を成功できるメンバーを125人揃えたとすると、125人連続で成功する確率は以下のように28.5%となります。99％は高い成功率のように思えますが、ぜんぜん低いということになります。

さらに、仮に1000回中999回成功できるメンバーを揃えたとしても、125人連続となると88.2%となり、9割を超えません。

たかが大皿といえども、ここまで難しくなるのです。大皿という簡単な技を、難しいと思えるかどうかがこのチャレンジの肝だと言えます。2018年にこのチャレンジに成功したのはいかに難しいことであったかがよくわかると思います。

2019/12/29 リハ1日目

この日初めて、ギネス記録に挑戦する125人の内、一般人115人が一堂に会しました。今回この企画が決定したのは12/8ですから、準備にかけられたのはわずか3週間しかありませんでした。この短期間で115人集まったことはそれだけで驚くべきことです。そのうち2018年の経験者は7割ほどで、3割ほどは初めて参加するメンバーでした。

集まってすぐに、練習として大皿を100回連続で行いました。今回は、大皿100回連続を楽にできることを条件として参加者を募っていましたが、それでも、4名が1回ずつ失敗しました。100回の試行で個々の実力を正確に推定することは難しいのですが、昨年考えたモデルに当てはめて、成功率を推定してみました。

参加者のレベルを以下のように分けてみることにします。大皿100回のうち1回失敗するということは、下記の中級者のカテゴリに入ると考えられます。達人や上級者は100回程度の試行では失敗しないことが多いので、推定することしかできません。

カテゴリ	大皿1回の成功率	大皿100回連続の成功率	例示
達人	99.99%	99.0%	1万回に1回失敗する。高段者、大会上位者など。三山ひろしさんはここ。
上級者	99.9%	90.5%	1000回に1回失敗する。おそらくけん玉ヒーローズのボリュームゾーン。一般的な目で見れば「けん玉名人」。
中級者	99%	36.6%	100回に1回失敗する。2018年のDJ KOOさんはおそらくこのへん。
初級者	90%	0.027%	10回に1回失敗する。2017年のDJ KOOさんはおそらくこのへん。（例に出してごめんなさい。）

2018年と同様、達人クラスは44人と仮定して、中級者は4人、残りのメンバー77人は上級者として計算してみます。

達人： 44人
上級者: 77人
中級者: 4人
初級者: 0人

これで成功率を計算すると、以下のようになります。9割を切っているものの、まずまずの成功率ではあります。この値を12/29の時点で頭に入れていました。

12/29 は、スタジオでの練習と、ステージ上でのリハーサル（板踏み）を含めて、8回の全体練習を行い、7回成功しました。1回の失敗はスタジオでの練習のときでした。成功率は87.5%となり、推定値と近い値になりました。

2019/12/30 リハ2日目

12/30 も引き続き、スタジオでの練習と、ステージ上でカメラリハーサルを行いました。スタジオでの失敗はありませんでしたが、カメラリハーサルの際に1回失敗しました。全体練習は12/29からの累積で17回行い、成功は15回となりました。成功率は88.2%と、推定値に近い値のままでした。

2019/12/31 本番

この日は本番を迎えるのみで、スタジオでの練習を行いました。練習での失敗は1回もありませんでした。全体練習の回数はは12/29からの累積で26回で、そのうち24回成功していました。成功率を計算すると92.3%となりました。（試行回数が1,2回違うかもしれませんが成功率はほぼ変わりません）

この状態で、非常によい雰囲気で本番に臨みましたが、残念ながら本番では成功することができませんでした。最終的には3回失敗したので、成功率を計算すると以下のように88.9%となり、推定値と非常に近い値になりました。

ちなみに、2018年は本番含めて26回中25回成功しているので、成功率は以下のように96.2%と、非常に高い値に達していました。2018年の方がやや成功率が良かった印象ですが、試行回数が少ないので、有意な差があったとまでは言い切れません。

残酷なようですが、個々の大皿の成功率は元々かなり高く、そこからさらに2,3日で大幅に上昇することはまずないので、最初に集まった時点で成功率はほぼ固定されるということになります。全体練習の成功率に表れるのはあくまで結果なので、大数の法則により、個々の成功率に基づく期待値に収束することになります。決して低い成功率ではなかったので、願わくば本番で成功したかったですが、これは結果として受け止めるしかありません。

なお、ギネス挑戦後の現場は、非常に和やかで爽やかなものであったことを、重ねて強調しておきます。三山ひろしさんも他の芸能人の方も含めて、あの場のメンバーには信頼関係が醸成されていて、誰も責めたりせず、みんなで挑戦したことを讃え合っていました。三山ひろしさんもブログで言及されていますね。

ameblo.jp

フジテレビけん玉部部長のシマヲさんのこちらの記事もおすすめです。

www.fujitv-view.jp

次回への展望

結果は惜しくも失敗に終わりましたが、すでに4回目の挑戦に言及されていたりして、次回に期待が持てそうです。過去3回は、あまりにも時間がない中での準備でしたが、次回は挑戦がある前提ならもっと準備に時間をかけることができるかもしれないですね。三山ひろしさん、そして、けん玉ヒーローズの今後の挑戦に乞うご期待です！

www.nikkansports.com

Kata Containers on Oracle Linux について Oracle Open World でお話ししてきました

Sat, 23 Nov 2019 23:57:21 +0900

概要
導入
アプリケーションコンテナ
アプリケーションコンテナのセキュリティ
Kata Containers
Demo
まとめ

概要

2019/9にサンフランシスコで開催されたOracle Open World 2019で登壇する機会をいただきました。Linuxとセキュリティという切り口で、Oracle LinuxのPMのSimon Coterさんといっしょに、Kata Containersというセキュリティ指向のコンテナランタイムについてお話ししてきました。

実は英語で登壇するのは初めての経験だったので、出落ちのクレイジージャパニーズくらいの気持ちで行きましたが、それなりに形になってたようです。我ながらかなりの変態ミッションだったと思います。

夏休みの個人旅行でOracle Open Worldに行く
個人で登壇する
英語で30分ぐらい話してデモもやる
アイスブレイクでけん玉をちょっとやる

Oracle Open Worldに登壇した日本人はいっぱいいますが、けん玉をやった人はいないでしょう。

Oracle Open World 2019 の資料はこちらのサイトからダウンロードできます。（英語版です）

events.rainfocus.com

2019/8に日本で開催された、Oracle Modern Cloud Day Tokyoでも、同じ内容を日本語でお話しさせてもらったので、そちらの資料を使って解説したいと思います。

Oracle Modern Cloud Day Tokyo の資料はこちらのサイトからダウンロードできます。

https://www.oracle.co.jp/campaign/moderncloudday/2019/

導入

表紙の背景に特に意味はありませんが、自分で撮影してきた天体写真をぶっ込むスタイルでいきました。この写真は2017年8月にアメリカで撮影してきた皆既日食の写真です。OOWで皆既日食を見た人がいるか聞いてみたら、2,3人手を上げてくれました。

余談ですが、2017/8/21 北米皆既日食の記事はこちら。

shakemid.hatenablog.com

自己紹介スライドはいつもながら自己主張強めです。OOWではちょっとけん玉やりました。だいぶうけてたのでアイスブレイクには成功したようです。芸は身を助ける、です。

アプリケーションコンテナ

コンテナ型仮想化の歴史は、1979年にUnixに実装されたchrootに遡ります。chrootはプロセスからファイルシステムを隔離する仕組みで、今でもよく使われます。2000年には、FreeBSDでJailという仕組みが導入されました。これはchrootをさらに強化したもので、プロセス空間も隔離します。Jailによって、OSの中に仮想OSを作るような使い方ができるようになりました。2005年には、Solaris 10でSolaris Zones (Solaris Containers)という仕組みが導入されました。これはほぼ仮想サーバのような機能で、ZonesがあるからSolarisを使っていた方も多いんじゃないかと思います。Solaris 11では、Kernelまで隔離した、Kernel Zonesというほぼハイパーバイザのような機能も導入されました。

またも余談ですが、2014年にSolarisのVPのBill Nesheimさんといっしょに、Solarisの仮想化についてお話ししたことがありました。我ながら、面白い機会をいただいていてありがたいことです。 www.sbbit.jp

Linuxでのコンテナ型仮想化も歴史が長く、2000年代半ば頃から、OpenVZ/Virtuozzoや、Linux-Vserverがレンタルサーバなどによく使われていました。初期のDockerでも使われていたLXCや、LXCを便利にした感じのLXDや、systemdに統合されたsystemd-nspawnなど、様々な実装があります。 2013年にDockerが登場してからアプリケーションコンテナが一気に広まってきました。2014年にKubernetesが登場し、今回紹介するKata Containersは2017年に登場したかなり新しい技術です。

今ではすっかり、「コンテナ」と言えば「アプリケーションコンテナ」のことを指すようになってしまいましたが、私は単に「コンテナ」と言うと、コンテナ型仮想化（OSレベル仮想化・システムコンテナ）の方を想像してしまうので、なるべく「アプリケーションコンテナ」と言うようにしていたりします。コンテナ型仮想化は、仮想サーバと同じような使い方をしますが、アプリケーションコンテナはその延長線上にはないのではないかと思います。

アプリケーションコンテナと従来のコンテナ型仮想化は似ていないと言いましたが、アプリケーションコンテナはサーバ仮想化などのインフラの話よりも、アプリケーション開発やDevOpsの文脈で語られることが多いのではないかと思います。Dockerの典型的な使い方としては、ビルド、パッケージング、デプロイという流れになると思いますが、昔からあるサーブレットコンテナととてもよく似ていたりします。アプリケーションコンテナとは、仮想サーバを置き換えるものではなく、アプリケーションをデリバリするためのものであると捉えるのがわかりやすいと思います。

アプリケーションコンテナのセキュリティ

ガートナーが最近出しているリサーチによると、2019年時点で、アプリケーションコンテナを商用で使っている組織は、ワールドワイドで30%未満とのことです。しかし、2022年にはこれが75%超になると予想されています。会場の方に、アプリケーションコンテナを商用で使っているか聞いてみたところ、日本のModern Cloud Dayでは10%未満でしたが、アメリカのOpen Worldでは30～40%くらいの方が手を上げました。ガートナーのリサーチはそれなりに当たっていそうな感じです。ガートナーは同じ記事の中で、アプリケーションコンテナを商用で使うための、6つの重要な要素を挙げていて、その1番目に「セキュリティ＆ガバナンス」を挙げています。

www.gartner.com

アプリケーションコンテナのセキュリティと一言に言っても、どうすればいいのかなかなか難しいです。NIST（米国国立標準技術研究所）がよくまとまった文書を公開しているので、そちらを参照してみましょう。NIST SP800シリーズはセキュリティ関連の文書で、SP800-190 はアプリケーションコンテナのセキュリティについてまとめられています。2017年9月に公開されたものなので、かなり新しい文書です。その中で、アプリケーションコンテナの典型的なアーキテクチャは上の図のようなコンポーネントから成り立っていると述べられています。図の左から、開発者がコンテナイメージを作って、テストして、レジストリに登録して、管理者がオーケーストレータを使ってホストにデプロイする、という流れになっています。Docker、Kubernetes、DockerHubなどは、このアーキテクチャの実装例といえます。

SP800-190はこちらからダウンロードできます。 csrc.nist.gov

一部の文書はIPAが日本語化して公開しています。SP800-190はまだないようです。 www.ipa.go.jp

同文書の中で、アプリケーションコンテナには5つの主要なリスクがあると述べられています。5つのリスクとは、イメージのリスク、レジストリのリスク、オーケストレータのリスク、コンテナランタイムのリスク、ホストOSのリスクです。

コンテナイメージの中身は、概ね上のような図のようになっています。先ほど、アプリケーションコンテナはアプリケーションをデプロイするためのものだと述べました。誤解を恐れずに言えば、アプリケーションの開発者はほぼアプリケーションにしか興味がないことが多いんじゃないかと思います。でも、コンテナの中身はOSイメージそのものなので、インフラやセキュリティの人は、ライブラリやユーザランドが気になってしまうのではないかと思います。でも一般に、アプリケーションコンテナの場合は、中に入ってプロセスを監視したりログを監視するようなことはあまりやりません。むしろお行儀が悪いと言われたりします。これは仮想サーバのように使うコンテナ型仮想化の場合とは異なるやり方が必要になりますが、セキュリティとしてはコンテナイメージの中身も見る必要があります。DevOpsにセキュリティを加えたDevSecOpsのような考え方が必要になるということだろうと思います。

次に、ホストOSのリスクの中の、Kernelの共有の項目に注目したいと思います。一般的に、アプリケーションコンテナ環境では、アプリケーションレベルで隔離が行われているものの、Kernelを共有しており、ハイパーバイザによる仮想化より隔離のレベルが低いと考えられます。Kernelを共有しているので、1つのアプリケーションコンテナが侵害されれば、ほかのアプリケーションコンテナもリスクにさらされる可能性が高いといえます。この手の攻撃が刺さる可能性はそう高くないかもしれませんが、カーネルを共有していることがセキュリティの論点になることはあるということです。

Kata Containers

Kernelの共有がセキュリティのリスクになることがあるということから、ようやくKata Containersの話に入ります。ハイパーバイザの技術を利用し、アプリケーションの強い隔離を実現するコンテナランタイムで、OpenStack Foundataion（OSF）がサポートしています。2017/12に出たばかりのとても新しい技術です。コンテナオーケストレータは、今のところKubernetesがデファクトスタンダードといえますが、一方、コンテナランタイムはいろいろな特性を持ったものが出てきています。Kata Containersはかなりセキュリティに振り切ったコンテナランタイムだと言えます。

katacontainers.io

この図は、Kata Containersのアーキテクチャを模式図にしたものです。一般的なコンテナランタイムでは、左の図のように、Kernelを共有して、Namespaceの機能でアプリケーションを隔離します。それに対して、Kata Containersでは、アプリケーションコンテナ毎にKernelが分離するので、ハイパーバイザによる仮想化と同等の隔離を実現しています。

この図は、DockerとKata Containersの関連性を表したものです。kata-runtimeはLow-Levelのコンテナランタイムです。また、CNCFが策定したOCI Runtime Specificationに準拠しています。Dockerでは、通常runCがLow-Levelコンテナランタイムとして使用されますが、もちろんrunCもOCI Runtime Specificationに準拠しています。つまり、runCをkata-runtimeに置き換えることが可能ということになります。Kata ContainersはDockerやKubernetesを置き換えるものではなく、組み合わせて使うものと考えるのがよいと思います。

Kata Containersは、Oracle Linuxでは Oracle Linux Cloud Native Environment (OLCNE) の一部として取り込まれています。とはいえ、OLCNEという製品があるわけでもなく、サービスがあるわけでもありません。Oracle Linuxには、クラウドでのアプリケーション開発や運用に必要な機能がバンドルされているという、コンセプトのようなものだと私は理解しています。

Demo

こんな感じの環境で簡単なデモを行いました。仮想化にはVMware Playerを使いましたが、Oracle LinuxのPMのSimonさんは、VirtualboxのPMでもあるので、できればVirtualboxを使いたいと思っていました。Kata ContainersはKVMを使うので、仮想環境で動かすには、Nested VMができる必要があります。Virtualbox 6.0でAMDのCPUではNested VMに対応しているのですが、IntelのCPUではまだ対応していませんでした。VMware PlayerではIntel CPUでもNested VMができました。Virtualbox 6.1では、Intel CPUでもNested VMに対応予定のようなので、期待したいと思います。イベントでは機材トラブルがつきものなので、デモをやるのは度胸が必要です。幸い日本でもアメリカでもデモ環境はすんなり動いてくれてよかったです。

デモのシナリオです。Docker Hubから取得した、Nginxのイメージを、Docker+runC と Docker+kata-runtime でそれぞれ起動するというデモを行いました。docker run の --runtime オプションを指定するだけで、必要に応じてコンテナランタイムを切り替えることができ、混在させることもできます。 Solaris 11をよく知っている方は、Native ZonesとKernel Zonesとの関係に似ていると考えるとわかりやすいんじゃないかと思います。

Oracle LinuxでKata Containersを使うのはわりと簡単です。この手順は、Developer Previewでの手順なので、GA(General Availability)になったら変わるかもしれませんのでご了承ください。

必要なYum リポジトリを有効化します。

# yum-config-manager --enable ol7_addons
# yum-config-manager --enable ol7_developer
# yum-config-manager --enable ol7_developer_kvm_utils

必要なRPMをインストールします。

# yum install docker-engine
# yum install qemu
# yum install oracle-olcne-release-el7
# yum install kata-runtime

Dockerの起動オプションを変更して、kata-runtimeを有効にします。

# vi /etc/sysconfig/docker
---
OPTIONS='-D --add-runtime kata-runtime=/usr/bin/kata-runtime'

# systemctl restart docker

Kata Containersを使用するには、KVMが有効になっている必要があります。

# lsmod
…
kvm     643072  1 kvm_intel

設定がうまくいっていれば、docker info でランタイムが追加されているのがわかります。

# docker info
…
Runtimes: kata-runtime runc

docker run でコンテナを起動すると、runCの場合は1秒くらいで起動しますが、kata-runtimeは仮想マシンを起動するので4～5秒くらいかかりました。パフォーマンスのテストは詳細にはやっていませんが、KVMで仮想化しているのと同じくらいのオーバーヘッドはあると考えられます。 pstreeでプロセスを見ると、runCのほうはNginxのプロセスが見えているのに対して、kata-runtimeのほうは、qemuのプロセスが見えて、たしかに仮想化されているのがわかります。Nginxのプロセスは仮想マシンの中なので、ホストOSからは見えなくなっています。

まとめ

というわけで、アプリケーションコンテナを商用環境で使うときにはそれ相応のセキュリティを考慮する必要があるということと、Kernelの共有はセキュリティリスクとして論点になりうるという話から、ハイパーバイザの技術でアプリケーションコンテナを隔離するKata Containersというコンテナランタイムについて紹介しました。今後、Kata Containersが主流になるかはまったくわかりませんが、コンテナランタイムは必要に応じて特性の違うものを使い分けるようなケースが増えてくるのではないかと考えています。

またも余談ですが、最後のスライドも自分で撮影してきた天体写真をぶっ込みました。2018年に、世界有数の美しい星空だと言われる、ニュージーランドのテカポ湖で撮影してきた天の川の写真です。ニュージーランド旅行の記事はこちらから。 shakemid.hatenablog.com

相貌失認

Thu, 12 Sep 2019 22:06:19 +0900

相貌失認（そうぼうしつにん）をご存じでしょうか。

相貌失認は高次脳機能障害の一種で、人の顔を覚えられない、人の表情がわからないといった症状があります。人口の2%が該当するとも言われ、意外と多いです。程度は様々で、重症だと家族の顔すら覚えられないこともあるそうです。治療法は基本的にはありません。

私は軽度の相貌失認を自認しています。

ja.wikipedia.org

ブラッド・ピットなど、相貌失認を告白している著名人もいます。この人がブラッド・ピットだと、皆さんわかるのだと思いますが、たぶん私は目の前にいてもわかりません。

movie.walkerplus.com

私はまったく覚えられないわけではないので、軽度なのだと思いますが、以下のようなことがよくあり、困ることがあります。

およそ3人～4人に1人は顔を覚えるのが非常に難しい。法則性は特になし。
仕事で顔を合わせていても、街中など、違う場面だと誰かわからない。
大勢の中から目的の人を探せない。オープンスペースのようなところで待ち合わせると詰むことあり。
2回目以降会っても誰かわからない。何回も会っている人でも、初めて会うのか会ったことがあるのかわからない。
芸能人の顔がわからない。映画などで役柄はわかっても、誰なのかわからない。

こちらのサイトで、相貌失認のセルフチェックができるサイトが紹介されていました。ふつうの人だと平均80%で、60%を切ると相貌失認の疑いありとのことなのですが、私がやってみたところ50%ほどでした。まあまあの相貌失認なのだと思います。

www.gizmodo.jp

テストはこちらのサイトです。（英語です）

www.bbk.ac.uk

治療法はないので、受け入れるしかないのですが、自分が他人の顔を覚えられないので、なるべく自分が覚えていただけるように心がけていることから、自己主張が強めに感じる方もいるかもしれません。街中など、たくさんの人がいる中で私に会って、無視しているように見えても、おそらく顔を認識できていないので、気を悪くしないでいただけるとありがたいです。

こうして相貌失認のことを書けば、少しは世の中の役に立つかもしれないので、書かせていただきました。

ZWO ASIAIR + Sky-Watcher SynScan Wi-Fi + EQ5GOTO で自動導入

Sun, 25 Aug 2019 22:51:15 +0900

概要
シナリオ

概要

ZWO ASIAIR と Sky-Watcher SynScan Wi-Fi を組み合わせて、 EQ5GOTO で自動導入できるところまで検証してみたメモです。

ASIAIR は1年ほど前からアマチュア天文界で話題になっているデバイスで、天体写真に必要な、カメラや赤道儀の操作を、スマートフォンやタブレットでまとめてできてしまうという画期的な製品です。私は Sky-Watcher EQ5GOTO を、SynScan Wi-Fi でスマートフォンから操作できるようにしていたので少し様子見していましたが、ASIAIRは23,000円とこの手の製品にしては安いので気付いたら買っていました。

http://hoshimiya.com/?pid=133669448hoshimiya.com

hoshimiya.com

Sky-Watcher EQ5 GOTO赤道儀（ステンレス三脚仕様）

メディア: エレクトロニクス

通常は ASIAIR と EQ5GOTO の接続は、ハンドコントローラにシリアルケーブルを挿して有線で連携するのですが、どうせなら無線で連携したいと思いました。 ASIAIR と AZ-GTi での連携は公式にサポートされていたので、中身がほとんど同じと思われる SynScan Wi-Fi との連携もできるだろうと思いました。

https://astronomy-imaging-camera.com/manuals/ASIAIR_Sky-Watcher_AZ-GTI.pdf

ZWO社のFacebookページで、AZ-EQ5GT での動作報告例があったので、私も EQ5GOTO での動作報告を共有しておきました。

www.facebook.com

シナリオ

設定の手順を簡単に解説します。無線LANの設定のところが少々ややこしいかもしれません。私は、光学や制御のことはさっぱりですが、ネットワークのことは仕事上得意分野です。最近のアマチュア天文界はIT化が著しいようなので、私にはありがたいかもしれません。

私はiPadで検証したので、画面はiPadのものですが、たぶんAndroidでもだいたい同じ手順でいけると思います。

SynScan Wi-Fi の設定

iPad/iPhone を、SynScan Wi-Fi のSSIDで無線LANに接続し、SynScan Pro App で SynScan Wi-Fi に接続します。

SynScan Wi-Fi は、アクセスポイントモード（無線LAN親機）として動作していますが、ASIAIR と同じネットワークセグメントに接続するために、ステーションモード（無線LAN子機）に変更します。ASIAIR のSSIDとパスワード（ASIAIRの本体側面に記載）を入力し、固定IPアドレスを割り当てます。ここでは 10.0.0.10 に設定します。

「Apply（適用）」を押すと設定が反映され、以後は、ASIAIRを無線LAN親機として接続するようになります。設定を間違えると、SynScan Wi-Fi に接続できなくなるので慎重に設定してください。

もし設定を間違えたら、SynScan Wi-Fi をリセットする必要があります。説明書によると、SynScan Wi-Fi をリセットするには、電源を入れて接続せずに1時間放置すればよいようです。（なんという仕様...）

ASIAIRの設定

iPad/iPhone を、ASIAIR のSSIDで無線LANに接続します。デフォルトでは、ASIAIRの無線LANの周波数帯は5GHzになっていますが、SynScan Wi-Fiは2.4GHzにしか対応していないので、2.4GHzにしておいてください。そもそも、日本では電波法により屋外で5GHz帯は使ってはいけないので、おとなしく2.4GHzにしておきましょう。

SynScan Pro App でのアラインメント

iPad/iPhone を ASIAIR のSSID（ASIAIR_xxx）に接続したら、SynScan Pro App で SynScan Wi-Fi に接続してください。設定がうまくいっていれば、10.0.0.10 で SynScan Wi-Fi に接続できると思います。

SynScan Pro App で、アラインメントを行ってください。3スターアラインメントが推奨らしいのですが、ASIAIRの Plate Solving が優秀なようなので1スターアラインメントでも十分な気がします。アラインメントを行わないと、ASIAIR から接続ができないようです。

ASIAIR から SynScan Wi-Fi への接続

ASIAIR のアプリに切り替えて、望遠鏡のアイコンを選択し、以下のように設定して SynScan Wi-Fi に接続してください。

Telescope: EQMod Mount (SynScanではなく)
IP: 10.0.0.10
Port: 11880
Protocol: UDP

接続がうまくいけば、ASIAIRから自動導入などが行なえるようになります。

まずはここまでしか検証できていませんが、オートガイドや Plate Solving など、魅力的な機能が他にもあるので、徐々に試したいと思います。

野辺山で星を見てきました

Mon, 06 May 2019 22:44:09 +0900

令和最初の天体観測ということで、GWの後半は3泊4日で野辺山高原に出かけてきました。野辺山は首都圏からアクセスしやすい天体観測スポットで、私が住んでいる千葉県浦安市からだと車で3～4時間ほどで行くことができます。 www.kanko-nobeyama.jp

野辺山には2014年にも来たことがあるのですが、そのときは1泊だけで、残念ながら夜は曇ってしまい星を見ることができませんでした。約4年半ぶりのリベンジです。

撮影場所は、野辺山駅から車で5分くらいのところにある、八ヶ岳ふれあい公園にしました。24時間無料で使える駐車場とトイレがあり、天体観測スポットとして人気があるようです。深夜でも常に星を見に来ている人がいました。

公園には1周500mの大きな池があります。水面を使った星景写真を撮るのも面白いと思います。

妙に整った形の池だと思ったら、もともとはスケートリンクだったとのことです。

こんな感じの清掃の行き届いたトイレが24時間使えます。管理人さんが常駐しているようです。

今回の装備です。1日目は、 BORG 71FL＋α7S＋EQ5GOTO で、主に系外銀河を狙いました。BORG 71FLは400mmしかないので系外銀河を撮影するにはちょっと小さいです。系外銀河をちゃんと撮影しようとするとさらに上の機材が必要ですが、比較的コンパクトな機材で10分くらいで気軽に撮影してきたことに価値があると思います。

2日目は池のほとりで一晩中天の川を見ていました。この日は一晩中快晴でした。夏の天の川を見るなら梅雨の前の4月～5月の夜2時～3時頃がおすすめです。池の水面を入れて、星景っぽく天の川を撮影してみました。野辺山は天頂近くは暗いのですが、低空は残念ながら光害がかなりあります。冬場はスキー場の照明でさらに光害がひどいようです。せっかくの星空なのに、残念なところです。

一晩中外にいたらカメラバッグに霜が降りてました。ホームセンターで買った防寒作業着が優秀でした。標高1300mの山と同じようなもんですから、防寒着がなかったら凍死しますね。山での天体観測は凍死との戦いです。

3日目は、北天にカメラを向けてタイムラプス撮影してみました。水面にも星が写っていい絵になるかなと思ったのですが、野辺山上空は飛行機が多すぎでした。人工衛星や流星ぽいものも写ってますね。これはこれでおもしろいです。

3泊中3晩とも晴れて、天体観測を楽しむことができました。3日目は体力が続かず、ほどほどにしてホテルに帰りました。

野辺山高原は首都圏からアクセスしやすい天体観測スポットとしては屈指ではありますが、思ったより低空の光害が目立つと思いました。特に南側が明るいので、天の川の撮影にはあまり向いてないように思いました。空の暗さでは栃木県の戦場ヶ原のほうが暗かったと思います。

shakemid.hatenablog.com

戦場ヶ原も南側はそれなりに光害があるので、関東周辺で天の川を撮影するなら千葉の南房総がよいように思います。ただし、南房総も、北側は東京の光害があります。関東周辺で光害がないところはないので、撮影したい対象に応じて撮影場所を選ぶ必要があると思います。

Elasticsearch Cluster on Linux Container

Sun, 07 Apr 2019 08:54:56 +0900

概要
背景
シナリオ
構築
まとめ

概要

Linuxコンテナ（systemd-nspawn）を使って、複数ホストにまたがるElasticsearchクラスタを構築してみました。私はコンテナ歴12年くらいですが、ほとんどSolarisコンテナ（Zones）ばかり使っていて、Linuxコンテナはどんなものかよくわかっていないので、おかしなことを言っていましたらご指摘ください。

背景

以下のような感じの要件で、基盤のアーキテクチャを考えていました。

50～100ノード規模のElasticsearchクラスタを作りたい
オンプレ環境で
一度起動したら年単位で動き続ける
商用ライセンスはあまり使いたくないけど、人柱になって自力でなんとかする気概はあり

なんとなく以下のような実現方式を考えました。本音はSolaris Zonesを使いたくてたまりませんが今回はLinux縛りです。

カテゴリ	方式	評価（主観）
物理系	物理サーバ50台	× ラックが足りない。運用嫌だ。
	物理サーバ＋マルチプロセス	△ 運用嫌だ。
ハイパーバイザ系	VMware	△ ライセンス必要。オーバーヘッド嫌だ。
	KVM, Xen	△ オーバーヘッド嫌だ。
コンテナ系	Docker	△ どうも合わない。k8s, Swarmとかは大がかりすぎ。
	OpenVZ	△ まだあるのだろうか？
	LXD	○？良さそう。使うならUbuntuが良さそうか。
	systemd-nspawn	○？ほぼOS標準の機能！

Dockerは少し検証してみたのですが、動くには動くのでしょうが、ホストまたぎのネットワークを構成するのが面倒で、KVSを立ち上げて、VXLANでオーバーレイネットワークとかになるのでやる気がなくなりました。そのためだけにKubernetesとかSwarmを使うのも大がかりすぎに思えました。

qiita.com

DockerをDisる気はなく、用途がマッチすれば良いと思いますが、仮想マシンのようなことがやりたいならまったく不向きで、無理矢理使っても悲惨な運用になるのが落ちという感じがします。長年Solarisコンテナを使ってきたのもあって、なるべくシンプルでほぼOS標準の機能で動作するということから systemd-nspawn にたどり着き、検証してみようと思いました。

なお、クラウド前提なら、Amazon Elasticsearch Service を検討するのもいいと思います。

aws.amazon.com

シナリオ

今回構築する環境は以下のようなイメージです。物理マシンがあれば使ってもいいですが、私はVirtualBox上に構築することにしました。

構築は以下のような流れで進めました。

ホスト構築編
- CentOS 7 をインストールする
- systemd-networkd をインストールする
- ZFS をインストールする（任意）
コンテナ構築編
- コンテナイメージをインストールする
- コンテナを起動する
- Elasticsearchをインストールする
- コンテナをコピーする

構築

ホスト構築編

CentOS 7 をインストールする

OSはユーザが多いであろうCentOSにしました。バージョンは現時点で最新の7.6にしました。

インストールはできましたが、グラフィカルインストーラだとマウスでボタンをクリックできないことがある謎の事象に遭遇したので、テキストインストーラを使う方がいいような気がします。

qiita.com

今回はホスト間で通信できる必要があるので、VirtualBoxのネットワークの設定でブリッジアダプターを使うとよいと思います。また、プロミスキャスモードを許可する設定も必要です。

また、OSの領域とコンテナの領域を分けたいので、ストレージの設定画面でディスクイメージを1つ追加しました。

SELinuxは無効にしました。

$ sudo vi /etc/sysconfig/selinux
----
...
SELINUX=disabled
...

systemd-networkd をインストールする

今回はホスト間で通信できるようにネットワークブリッジを使うので、ネットワークの管理をsystemd-networkdで行うのがよいようです。以下のページを参考にしました。

renediepstraten.nl

以下のページも参考にしました。systemd関連のドキュメントはArch Linuxのものがわかりやすい感じがします。

wiki.archlinux.jp

systemd-networkd と systemd-resolved をインストールします。

$ sudo yum install systemd-networkd systemd-resolved

設定ファイルを作成します。内容は環境に合わせて適当に変えてください。Redhat標準の /etc/sysconfig/network-scripts/ 以下のファイルは使われなくなります。

/etc/systemd/network/br0.netdev
----
[NetDev]
Name=br0
Kind=bridge

/etc/systemd/network/enp0s3.network
----
[Match]
Name=enp0s3

[Network]
Bridge=br0

/etc/systemd/network/br0.network
----
[Match]
Name=br0

[Network]
Address=192.168.0.10
Gateway=192.168.0.254
DNS=192.168.0.254

systemd-networkd と systemd-resolved を有効にします。

$ sudo systemctl disable network NetworkManager
$ sudo systemctl enable systemd-networkd systemd-resolved
$ sudo reboot

resolve.conf を入れ替えておきます。

$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

networkctl コマンドで、IPアドレスなどを確認することが出来ます。

$ networkctl status
●      State: routable
     Address: 192.168.0.10 on br0
     Gateway: 192.168.0.254 (XXX) on br0
         DNS: 192.168.0.254

ZFS をインストールする（任意）

ZFSは必須ではありませんが、コンテナの領域を管理するのに都合が良さそうなので使ってみたいと思います。 systemd-nspawn はBtrfsと連携する機能があるようなのですが、ここは慣れ親しんだZFSにします。

ZFSをCentOSで使用するには、カーネルモジュールを追加する必要があります。ZFS on Linux の公式の手順に従ってインストールします。

github.com

ZFSのYum リポジトリを使えるようにします。

$ sudo yum install http://download.zfsonlinux.org/epel/zfs-release.el7_6.noarch.rpm

zfs-kmod のほうを有効にします。

$ sudo vi /etc/yum.repos.d/zfs.repo
----
 [zfs]
 name=ZFS on Linux for EL 7 - dkms
 baseurl=http://download.zfsonlinux.org/epel/7/$basearch/
-enabled=1
+enabled=0
 metadata_expire=7d
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux
@@ -9,7 +9,7 @@
 [zfs-kmod]
 name=ZFS on Linux for EL 7 - kmod
 baseurl=http://download.zfsonlinux.org/epel/7/kmod/$basearch/
-enabled=0
+enabled=1
 metadata_expire=7d
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux

ZFS をインストールします。

$ sudo yum install zfs

ARCのサイズを制限しておきます。

$ sudo vi /etc/modprobe.d/zfs.conf
----
options zfs zfs_arc_max=1073741824

ストレージプールを作成します。ZFS on Linux では、ls -l /dev/disk/by-id で表示されるデバイスIDを使用することが推奨されているようです。

$ sudo zpool create tank ata-VBOX_HARDDISK_XXXXXX-XXXXXX

tank という名前でストレージプールができました。

$ zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  39.8G   291K  39.7G         -     0%     0%  1.00x  ONLINE  -

コンテナ用の領域（データセット）を作成します。compressionの設定はお好みに合わせてという感じです。近年はCPUが高速なので、圧縮した方が Disk I/O が減って高速になるケースもあります。

$ sudo zfs create -o compression=lz4 -o mountpoint=/var/lib/machines tank/machines
$ sudo zfs create tank/machines/es11
$ sudo zfs create tank/machines/es12

こんな感じでデータセットができました。

$ zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank                 162K  38.5G  25.5K  /tank
tank/machines         73K  38.5G    25K  /var/lib/machines
tank/machines/es11    24K  38.5G    24K  /var/lib/machines/es11
tank/machines/es12    24K  38.5G    24K  /var/lib/machines/es12

systemd-nspawnでは、 /var/lib/machines/ 配下のディレクトリ名がコンテナのhostnameになるように想定されているようです。長さの制限は一見ないように見えるのですが、systemd-networkd がインタフェース名を自動生成するときに先頭11文字で切り落としてしまうようで、先頭11文字がユニークでないと名前が衝突するようです。そのうち改善するのかもしれませんが、ディレクトリ名（コンテナ名）は11文字以下にするのが無難なようです。

github.com

コンテナ構築編

コンテナイメージをインストールする

systemd-nspawn では、コンテナイメージをインストールする方法は主に3種類くらいあるようです。

yum install --installroot でインストールする。chroot環境を作るのと似た感じ。
ビルド済みのイメージを使う。Dockerのイメージも使えるようだ。
すでに作成済みのコンテナからコピーする。

ひとまずオーソドックスな1.でやってみることにします。3.はあとからやります。

ZFSで作成した領域に最低限のパッケージをインストールします。

$ sudo yum -y --nogpg --releasever=7 --installroot=/var/lib/machines/es11 install systemd systemd-networkd passwd yum vim-minimal

lsで見ると、OSのイメージぽく見えます。

$ ls -l /var/lib/machines/es11/
total 17
lrwxrwxrwx.  1 root root   7 Apr  6 23:24 bin -> usr/bin
dr-xr-xr-x.  2 root root   2 Apr 11  2018 boot
drwxr-xr-x.  2 root root   3 Apr  6 23:24 dev
drwxr-xr-x. 47 root root 113 Apr  6 23:25 etc
drwxr-xr-x.  2 root root   2 Apr 11  2018 home
lrwxrwxrwx.  1 root root   7 Apr  6 23:24 lib -> usr/lib
lrwxrwxrwx.  1 root root   9 Apr  6 23:24 lib64 -> usr/lib64
drwxr-xr-x.  2 root root   2 Apr 11  2018 media
drwxr-xr-x.  2 root root   2 Apr 11  2018 mnt
drwxr-xr-x.  2 root root   2 Apr 11  2018 opt
dr-xr-xr-x.  2 root root   2 Apr 11  2018 proc
dr-xr-x---.  2 root root   2 Apr 11  2018 root
drwxr-xr-x. 12 root root  12 Apr  6 23:25 run
lrwxrwxrwx.  1 root root   8 Apr  6 23:24 sbin -> usr/sbin
drwxr-xr-x.  2 root root   2 Apr 11  2018 srv
dr-xr-xr-x.  2 root root   2 Apr 11  2018 sys
drwxrwxrwt.  7 root root   7 Apr  6 23:25 tmp
drwxr-xr-x. 13 root root  14 Apr  6 23:24 usr
drwxr-xr-x. 18 root root  21 Apr  6 23:24 var

ちなみに、圧縮率を見てみると2倍以上になっていてなかなかいい感じです。lz4は圧縮率と速度のバランスが良く、ZFSを使うならおすすめです。

$ zfs get compressratio tank/machines/es11
NAME                PROPERTY       VALUE  SOURCE
tank/machines/es11  compressratio  2.03x  -

コンテナを起動する

systemd-nspawn -Dオプションで、イメージをインストールしたディレクトリを指定してコンテナを起動し、rootのパスワードを設定します。

$ sudo systemd-nspawn -D /var/lib/machines/es11
-bash-4.2# passwd
...
-bash-4.2# exit

SELinuxを適切に設定するか無効にしないとパスワード変更で↓のようなエラーになるようなのでご注意ください。私は恥ずかしながらSELinuxをまともに使ったことがありません。

passwd: Authentication token manipulation error

コンテナをデーモンモードで起動します。

$ sudo systemd-nspawn -b -D /var/lib/machines/es11

起動シーケンスが走って、ログインプロンプトが出てくるのでrootでログインします。

Spawning container es11 on /var/lib/machines/es11.
Press ^] three times within 1s to kill container.
systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to CentOS Linux 7 (Core)!

...
CentOS Linux 7 (Core)
Kernel 3.10.0-957.el7.x86_64 on an x86_64

es11 login: root
Password:
Last login: Sat Apr  6 23:43:37 on console

ps -ef で見ると、最低限のプロセスが起動しているのがわかります。

container# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  1 23:45 ?        00:00:00 /usr/lib/systemd/systemd
root        14     1  0 23:45 ?        00:00:00 /usr/lib/systemd/systemd-journald
dbus        19     1  0 23:45 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfil
root        21     1  0 23:45 ?        00:00:00 /usr/lib/systemd/systemd-logind
root        23     1  0 23:45 ?        00:00:00 login -- root
root        25    23  0 23:45 console  00:00:00 -bash
root        37    25  0 23:45 console  00:00:00 ps -ef

デフォルトでは、ホストとネットワークを共有しています。

container# networkctl status
●      State: n/a
     Address: 192.168.0.10 on br0
     Gateway: 192.168.0.254 (JStream Technologies Inc.) on br0

Ctrl+] を3回入力するとコンテナが終了します。

Container es11 terminated by signal KILL.

ネットワークの設定を追加します。コンテナの中身はただのディレクトリなので、ホスト側からも見えます。

$ cd /var/lib/machines/es11
$ cd etc/systemd
$ sudo mkdir network
$ cd network

systemd-nspawnではhost0という仮想NICが自動的に作られるので、以下のように設定ファイルを作成します。

$ sudo vi host0.network
----
[Match]
Name=host0

[Network]
Address=192.168.0.11/24
Gateway=192.168.0.254
DNS=192.168.0.254

今度は、--network-bridge オプションを追加して起動します。

$ sudo systemd-nspawn -b -D /var/lib/machines/es11 --network-bridge=br0

host0にIPアドレスが設定されていることがわかります。これで、コンテナに独自のIPアドレスを割り当てて外部と通信できるようになりました。

container# networkctl status
●      State: routable
     Address: 192.168.0.11 on host0
     Gateway: 192.168.0.254 on host0
         DNS: 192.168.0.254

machinectl login でrootでログインできるように、/etc/securettyにpts/0を追記しておきます。

container# echo pts/0 >> /etc/securetty

いったん Ctrl+] を3回入力してコンテナを終了します。

Container es11 terminated by signal KILL.

ここからは、machinectlコマンドでコンテナを操作します。

ネットワークブリッジを使うように起動オプションを書き換えます。また、network.targetより後に起動するようにします。

$ sudo vi /usr/lib/systemd/system/systemd-nspawn\@.service
> After=network.target
...
< ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth --machine=%I
---
> ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-bridge=br0 --machine=%I

machines.targetを有効にします。

$ sudo systemctl enable machines.target

machinectl enable でコンテナが自動起動するようにします。

$ sudo machinectl enable es11
Created symlink from /etc/systemd/system/machines.target.wants/[email protected] to /usr/lib/systemd/system/[email protected].

machinectl start コマンドで、コンテナを起動できます。

$ sudo machinectl start es11

machinectl login コマンドで、コンテナにログインできます。

$ sudo machinectl login es11

ここまでで、コンテナを仮想サーバと同じような感覚で扱えるようになりました。

systemd-nspawn の概要は、例によって Arch Linux のページがわかりやすいと思います。

wiki.archlinux.jp

Elasticsearchをインストールする

ホスト側で、vm.max_map_countの値を増やしておきます。

$ sudo vi /etc/sysctl.d/10-vm.conf
---
vm.max_map_count=262144

$ sudo sysctl -p

Elasticsearchのyum リポジトリを追加します。

container# cd /etc/yum.repos.d
container# vi elasticsearch.repo
---
[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Javaをインストールします。

container# yum install java-11-openjdk

Elasticsearchをインストールします。

container# yum install elasticsearch

設定を変更します。

container# cd /etc/elasticsearch
container# vi elasticsearch.yml
---
...
node.name: ${HOSTNAME}

network.host: 0.0.0.0

discovery.zen.ping.unicast.hosts: ["192.168.0.11", "192.168.0.12","192.168.0.21", "192.168.0.22"]

本番で使うなら Shard allocation awareness も考慮した方がよいと思います。

www.elastic.co

サービスを有効にします。

container# systemctl daemon-reload
container# systemctl enable elasticsearch.service
container# systemctl start elasticsearch.service

動作確認してみます。ひとまず単一ノードで無事に起動しているようです。

container# curl http://localhost:9200/
{
  "name" : "es11",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "Rnvu_GRyQoapvhnodWHb4A",
  "version" : {
    "number" : "6.7.1",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "2f32220",
    "build_date" : "2019-04-02T15:59:27.961366Z",
    "build_snapshot" : false,
    "lucene_version" : "7.7.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

コンテナをコピーする

いったんコンテナを停止します。

$ sudo machinectl poweroff es11

machinectlコマンドには、export-tarというオプションがあるようなのですが、CentOS 7 に付属のものはバージョンが古いのかそのオプションがありません。

machinectl(1) — Arch manual pages

仕方がないので、rsyncでコピーすることにします。

$ cd /var/lib/machines/
$ sudo rsync -av es11/ es12
...

Node IDが重複しないように消しておきます。

container# rm -rf /var/lib/elasticsearch/nodes/0/

ネットワークの設定を書き換えます。

$ cd es12
$ cd etc/systemd/network
$ sudo vi host0.network
----
[Match]
Name=host0

[Network]
Address=192.168.0.12/24
Gateway=192.168.0.254
DNS=192.168.0.254

machinectl enable でコンテナが自動起動するようにします。

$ sudo machinectl enable es12
Created symlink from /etc/systemd/system/machines.target.wants/[email protected] to /usr/lib/systemd/system/[email protected].

machinectl start コマンドで、コンテナを起動します。

$ sudo machinectl start es11
$ sudo machinectl start es12

2台でクラスタ構成を組めていることを確認できました。

$ curl http://192.168.0.11:9200/_cat/health?v
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554574589 18:16:29  elasticsearch green           2         2      0   0    0    0        0             0                  -                100.0%

ホストの追加

もう一式ホストを追加します。私はVirtualBoxのクローン機能を使って作りました。以下のあたりに気をつければ良いと思います。

ホスト
- ホスト名変更: hostnamectl set-hostname ...
- machine-id変更: rm /etc/machine-id; systemd-machine-id-setup
- IPアドレス変更: /etc/systemd/network/ 以下
- ブリッジのMACアドレス変更
- zpoolのimport: zpool import -f tank
コンテナ
- コンテナ名変更: zfs rename
- IPアドレス変更
- ElasticseachのID情報削除

クラスタの状態を確認すると、無事に4台でクラスタ構成を組めていることを確認できました。

$ curl http://192.168.0.11:9200/_cat/health?v
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554575745 18:35:45  elasticsearch green           4         4      0   0    0    0        0             0                  -                100.0%

まとめ

Linuxコンテナ（systemd-nspawn）でホストまたぎのElasticsearchクラスタを構築してみました。 Docker+Kubernetes よりはるかにシンプルにできたと思います。今回は私の趣味で ZFS on Linux を使っていますが、ほぼOS標準の機能だけでもできるので、運用の観点でも安心感があるのではないでしょうか。

今回の検証で、Linuxコンテナを完全に理解しました（※チュートリアルを終えたレベルという意味）。なお、Solarisコンテナについては何もわかりません（※10年以上キャリアグレードの商用環境で使いまくったという意味）。

Qiitaにも上げてみました。 qiita.com

Solaris 11.4 on SuperMicro X10SDV-4C-TLN4F

Sat, 23 Feb 2019 23:27:11 +0900

背景
マザーボード選定の経緯
購入情報
10G NIC の認識
現状の構成
冷却の注意

背景

SuperMicroの X10SDV-4C-TLN4F で Solaris 11.4 が動作したのでメモしておきます。

www.supermicro.com

私の家の自宅サーバはかれこれ14年ほどSolarisです。主な用途はNASなので、NAS専用機にしてもいいのですが、ZFSのpoolを脈々とスケールアップしてきたので（ZFSなら簡単）、わざわざ移行するのが面倒なのと、そもそもSolarisを使うこと自体が目的化しているので、敢えて他のOSに乗り換える理由が見当たりません。

最初に自宅サーバをSolarisにしたのは2005年なので、Solaris 10 が出てすぐくらいのときですね。 shakemid.hatenablog.com

2008年にAtomプロセッサが出たときにSolarisを動かしてました。 shakemid.hatenablog.com

2009年からOpenSolarisを使ってました。なつかしす。 shakemid.hatenablog.com

2012年に自宅サーバをXeonにしていました。このときは VMware ESXi 上で Solaris 11 を動かしてましたが、その後、ベアメタルにしていました。 shakemid.hatenablog.com

Solarisは2018年に出た11.4が現時点の最新バージョンで、今も進化しています。しかも、少なくとも2034年までサポートが継続されることが決まっており、安心して使えるOSだといえます。 https://blogs.oracle.com/solaris/oracle-solaris-114-released-for-general-availabilityblogs.oracle.com

SolarisはOracle DBなどと同じOTNライセンスの元、個人用途や開発用途では無償で使用できます。現実的に、自宅で使える商用UNIXはSolarisだけじゃないでしょうか。 www.oracle.com

マザーボード選定の経緯

要件は↓のような感じです。

小型がいいのでMini-ITXで
CPUはXeonで
なるべく省電力で
IPMIでリモート管理ができて
10G NIC が付いてて
当然Solarisが動くこと

この条件だと選択肢はほぼ SuperMicro しか残りません。昔から、Solarisが動くハードウェアを探すのはLinuxより難しいですが、SuperMicro の X10SDV シリーズはSolarisで動作確認が行われているというアドバンテージがあります。今回の目当ての X10SDV-4C-TLN4F は厳密にはテストされていないようですが、ほとんど同じ構成のものがテストOKなので大丈夫だろうと思いました。 www.supermicro.com

ちなみに、1世代後の X11SDV シリーズはなぜかSolarisでテストされていませんでした。 www.supermicro.com

SuperMicroに問い合わせてみたところ、「俺たちSolarisでテストするのやめたんだ」という回答が返ってきました。悲しいorz

From: Technical Support <[email protected]>
Subject: RE: Does X11SDV series support Solaris 11?

Hi,

We stop validating Solaris OS on our new boards.

Thanks,

-----Original Message-----
To: Technical Support <[email protected]>
Subject: Does X11SDV series support Solaris 11?

Hi,

I am interested in running Solaris 11 on X11SDV series, such as X11SDV-8C-TLN2F.
But it does not seem to be tested yet, according to following page.
https://www.supermicro.com/support/resources/OS/skylake-d.cfm
Are there any plan testing X11SDV series with Solaris 11?

Regards,

X11SDVシリーズでもたぶんSolarisは動作すると思うのですが、このシリーズに搭載されている Xeon D-2100 シリーズは、Xeon D-1500 シリーズよりかなり消費電力が上がっていて、低消費電力のモデルがないので、1世代前のX10SDVシリーズを選ぶことにしました。

www.servethehome.com

Xeonにこだわらなければ、DenvertonコアのAtomプロセッサが搭載されている、A2SDiシリーズもいいんじゃないかと思います。 www.supermicro.com

NICの選定もなかなか難しくて、安価な10G NICによく搭載されているAquantiaのチップはSolaris用のドライバがないので、安心なのはIntel X550系のチップになります。Xeon DシリーズやDenvertonコアのAtomは10G NICが統合されているので、Solarisでも動く可能性が高いと思いました。

現時点で、自宅サーバでSolarisを使うなら、SuperMicroのマザーボードは鉄板だと思います。

購入情報

2019/2の時点で、日本での価格は\79,100でした。それに対して、米Amazon.comでは$485で、送料を含めても日本円で約62,000円と、それなりに内外価格差があったので、Amazon.comで買うことにしました。近年、個人輸入の敷居は劇的に下がっている感じがします。

価格.com - SUPERMICRO X10SDV-4C-TLN4F 価格比較

Amazon.com: Supermicro X10SDV-4C-TLN4F Mini-ITX Motherboard : Electronics

マザーボードとしてはかなり高価ですが、XeonとIntelの10G NICが乗ってると思えば、むしろ安く思えてきます。若干感覚が麻痺しているような気もしますが、気のせいということにしましょう。

10G NIC の認識

Solaris 11.4を入れてみて、起動までは問題なくできましたが、10G NICを認識していませんでした。 10G NICを認識させるには、一手間必要でした。

dladmで、1GのNICしか見えていません。

$ dladm show-phys
LINK            MEDIA         STATE      SPEED  DUPLEX    DEVICE
net0            Ethernet      up         1000   full      igb0
net1            Ethernet      unknown    0      unknown   igb1

prtdiagでは Intel X557-AT2 Ethernet という名前で見えています。

$ prtdiag -v
System Configuration: Supermicro Super Server
BIOS Configuration: American Megatrends Inc. 2.0a 10/12/2018
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)

==== Processor Sockets ====================================

Version                          Location Tag
-------------------------------- --------------------------
Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz CPU1

==== Memory Device Sockets ================================

Type        Status Set Device Locator      Bank Locator
----------- ------ --- ------------------- ----------------
DDR4        in use 0   DIMMA1              P0_Node0_Channel0_Dimm0
DDR4        empty  0   DIMMA2              P0_Node0_Channel0_Dimm1
DDR4        empty  0   DIMMB1              P0_Node0_Channel1_Dimm0
DDR4        empty  0   DIMMB2              P0_Node0_Channel1_Dimm1

==== On-Board Devices =====================================
 ASPEED Video AST2400
 Intel i350 Ethernet #1
 Intel i350 Ethernet #2
 Intel X557-AT2 Ethernet #1
 Intel X557-AT2 Ethernet #2

==== Upgradeable Slots ====================================

ID  Status    Type             Description
--- --------- ---------------- ----------------------------
1   available Unknown          M.2 PCI-E 3.0 X4
1   available PCI Express Gen3 x16 SLOT7 PCI-E 3.0 X16

scanpciで見ると、Vendor ID は 0x8086、Device ID は 0x15ad のようです。Intelの Vendor ID は製品名にちなんで 8086 なのですね。

# scanpci
...
pci bus 0x0003 cardnum 0x00 function 0x00: vendor 0x8086 device 0x15ad
 Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T

pci bus 0x0003 cardnum 0x00 function 0x01: vendor 0x8086 device 0x15ad
 Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T

こちらのサイトでも確認できます。 pci-ids.ucw.cz

似たようなことを聞いている人がいて、ixgbeドライバで動くんじゃないかとのことなので、ドライバをattachできればよさそうな感じがします。 https://community.oracle.com/thread/4163075community.oracle.com

PCI ID が 8086,15ad のデバイスに、ixgbeドライバをattachする手順は以下のようになります。

/etc/driver_aliases に以下の行を追加します。

ixgbe "pciex8086,15ad"

デバイスを再構成します。

# touch /reconfigure
# init 6

もしくは

# reboot -- -r

再起動後、無事に 10G NIC が認識されるようになりました。

$ dladm show-phys
LINK            MEDIA         STATE      SPEED  DUPLEX    DEVICE
net0            Ethernet      up         1000   full      igb0
net1            Ethernet      unknown    0      unknown   igb1
net3            Ethernet      unknown    0      unknown   ixgbe1
net4            Ethernet      up         10000  full      ixgbe0

ドライバがattachされているのがわかります。

$ grep ixgbe /etc/path_to_inst
"/pci@0,0/pci8086,6f06@2,2/pci15d9,15ad@0" 0 "ixgbe"
"/pci@0,0/pci8086,6f06@2,2/pci15d9,15ad@0,1" 1 "ixgbe"

$ prtconf -D
System Configuration:  Oracle Corporation  i86pc
Memory size: 16282 Megabytes
System Peripherals (Software Nodes):
...
        pci8086,6f06, instance #3 (driver name: pcieb)
            pci15d9,15ad, instance #0 (driver name: ixgbe)
            pci15d9,15ad, instance #1 (driver name: ixgbe)
...

余談ですが、Solaris 11.4 から path_to_inst は sysobj という仕組みで管理されるようになったようです。いろいろ変わってますね。

docs.oracle.com

というわけで、無事に 10G NIC を使えるようになりました。めでたしめでたし。

現状の構成

現状の自宅サーバの構成は以下のような感じです。この構成で消費電力はだいたい50W前後です。電気代は月800円くらいになるようです。

種別	品名
Case	Fractal Design Core 500
Power	Corsair SF450 CP-9020104-JP (SFX 450W)
MB	SuperMicro X10SDV-4C-TLN4F
CPU	Intel Xeon D-1518 (On Board)
Memory	SanMax SMD4-U16G48M-24R (DDR4-2400 16GB Micron)
Storage	SanDisk 120GB SSD, Western Digital 6TB HDD x2
OS	Solaris 11.4 x86

NASとしては若干パワフルすぎますが、Solarisサーバを手元に置いておきたいという手段と目的が入れ替わった状態なのでそれでよいのです。

冷却の注意

このマザーボードはファンレスですが、ファンレスで運用するのはほぼ不可能と思った方がよいです。ケースファンだけで冷却できるかなと思いましたがぜんぜん無理で、アイドル状態でも80℃を超えて温度が上昇してしまう状態でした。

さすがにこれではダメなので、CPUのヒートシンクにファンを取り付けることにしました。6cm角がちょうどよいサイズのようです。このマザーボードはファンの回転数をPWMだけで制御しており、PWM非対応のファン（3pinのもの）だと全力で回転してしまいます。 6cm角で、PWM対応となるとほとんど選択肢がなく、安心の山洋電機製のものを選びました。

オウルテック PCケース用山洋電気製標準PWMファン 6cm 25mm厚 1000~4600rpm F6-PWM

オウルテック

Amazon

↓のような、PWM非対応のファンをPWM対応にするアダプタを使うのもありだと思います。

アイネックス 3ピン-PWM4ピン変換制御ケーブル [ 20cm ] CA-PWM

アイネックス(AINEX)

Amazon

工作能力が足りないので、↓のような感じで、ビスと輪ゴムで固定しました。見た目はいまいちですが、冷却は充分にできているようです。

ファン付きの、X10SDV-4C+-TLN4F（型番に+が付いてる）というモデルもありますが、このファンはかなりうるさいらしいので、好みに合わせてという感じで。 www.maple-rice.com

SUPERMICRO X10SDV-4C-TLN4F - Motherboard - mini ITX - Intel Xeon D-1518 - USB 3.0 - 2 x 10 Gigabit LAN, 2 x Gigabit LAN - onboard graphics

Supermicro

Amazon

SUPERMICRO X10SDV-4C+-TLN4F - Motherboard - mini ITX - Intel Xeon D-1518 - USB 3.0 - 2 x 10 Gigabit LAN, 2 x Gigabit LAN - onboard graphics

Supermicro

Amazon

zpool remove を試すメモ

Wed, 06 Feb 2019 22:29:13 +0900

Solaris 11.4 では、zpool add したデバイスを remove できるようになっています。以前は zpool add すると外せなかったのでかなりの勇気が必要でしたが、remove できるようになったので構成変更がより柔軟にできるようになりました。

docs.oracle.com

zpoolのバージョンが44以上だと、Device removelという機能が有効になります。

$ zpool upgrade -v
...
 44  Device removal
...

こんな感じの構成で、mirror-0 を remove してみたいと思います。上記のサイトの例では、mirror を remove することができるようです。

$ zpool status epool
  pool: epool
 state: ONLINE
  scan: ...

config:

        NAME        STATE      READ WRITE CKSUM
        epool       ONLINE        0     0     0
          mirror-0  ONLINE        0     0     0
            c2t2d0  ONLINE        0     0     0
            c2t3d0  ONLINE        0     0     0
          mirror-1  ONLINE        0     0     0
            c2t1d0  ONLINE        0     0     0
            c2t0d0  ONLINE        0     0     0

errors: No known data errors

# zpool remove epool mirror-0
cannot remove device(s): operation not supported on this type of pool

あれれ、remove できませんね。

理由はわかりませんがmirrorはremoveできないのかもしれないので、detachでmirrorを解除してみました。

# zpool detach epool c2t3d0

mirror-0がなくなってディスク1本になりました。

$ zpool status epool
  pool: epool
 state: ONLINE
  scan: ...

config:

        NAME        STATE      READ WRITE CKSUM
        epool       ONLINE        0     0     0
          c2t2d0    ONLINE        0     0     0
          mirror-1  ONLINE        0     0     0
            c2t1d0  ONLINE        0     0     0
            c2t0d0  ONLINE        0     0     0

errors: No known data errors

こんどは、残った1本をremoveしてみます。

# zpool remove epool c2t2d0

おっ、コマンドが通りました。

STATEを見るとREMOVINGになっています。

$ zpool status epool
  pool: epool
 state: ONLINE
status: One or more devices are being removed.
action: Wait for the resilver to complete.
        Run 'zpool status -v' to see device specific details.
  scan: resilver in progress since Wed Feb  6 21:26:33 2019
    10.8G scanned out of 988G at 560M/s, 29m48s to go
    0 resilvered
config:

        NAME                        STATE      READ WRITE CKSUM
        epool                       ONLINE        0     0     0
          c2t2d0                    REMOVING      0     0     0
          mirror-1                  ONLINE        0     0     0
            c2t1d0                  ONLINE        0     0     0
            c2t0d0                  ONLINE        0     0     0

errors: No known data errors

zpool iostat -v で見ると、少しずつデータが移動しているのがわかります。

$ zpool iostat -v epool 1

                               capacity     operations    bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
epool                       1023G  5.36T      0  6.73K      0   171M
  c2t2d0                        -      -      0      0      0      0
  mirror-1                   524G  4.94T      0  6.74K      0   171M
    c2t1d0                      -      -      0    185      0   172M
    c2t0d0                      -      -      0    187      0   174M
--------------------------  -----  -----  -----  -----  -----  -----
...

resilver時はディスクがかなり高負荷になり性能に影響が出ます。I/O負荷が低いときに実施するのがおすすめです。

resilver完了後にzdbで見てみると、mirror-0の部分（children[0]のところ）がpseudoデバイスとして取り込まれているような感じに見えます。もしかしてashiftが違う（512bセクタと4kbセクタ）HDDが混在していたpoolだったのでこうなったのかもしれません。パフォーマンスに影響が出るかもしれないですね。

$ zdb
epool:
    version: 44
    name: 'epool'
    state: 0
    txg: 39458571
    pool_guid: 4817329454252204261
    timestamp: 1549469022
    hostid: 564057
    hostname: 'xxxx'
    vdev_children: 2
    vdev_tree:
        guid: 4817329454252204261
        id: 0
        type: 'root'
        children[0]:
            guid: 8473064149679056020
            id: 0
            type: 'pseudo'
            path: '$VDEV-C18B8487D547E670'
            phys_path: 'epool/$VDEV-C18B8487D547E670'
            removing: 1
            metaslab_array: 27
            metaslab_shift: 33
            ashift: 9
            asize: 1000191557632
            is_log: 0
            is_meta: 0
            DTL: 5887
            create_txg: 4
        children[1]:
            guid: 16792445297974810689
            id: 1
            type: 'mirror'
            whole_disk: 0
            metaslab_array: 111
            metaslab_shift: 33
            ashift: 12
            asize: 5995774345216
            is_log: 0
            is_meta: 0
            create_txg: 23955738
            children[0]:
                guid: 15198708556418494849
                id: 0
                type: 'disk'
                path: '/dev/dsk/c2t1d0s0'
                devid: 'id1,sd@SATA_____WDC_WD60EZRZ-00G_____WD-WX61D68AAPFE/a'
                phys_path: '/pci@0,0/pci8086,2036@1f,2/disk@1,0:a'
                whole_disk: 1
                DTL: 4160
                create_txg: 23955738
                msgid: 'ZFS-8000-QJ'
            children[1]:
                guid: 6065348894095674914
                id: 1
                type: 'disk'
                path: '/dev/dsk/c2t0d0s0'
                devid: 'id1,sd@SATA_____WDC_WD60EZRZ-00G_____WD-WX61D68AA6EP/a'
                phys_path: '/pci@0,0/pci8086,2036@1f,2/disk@0,0:a'
                whole_disk: 1
                DTL: 5328
                create_txg: 23955738
                msgid: 'ZFS-8000-QJ'

紅白歌合戦けん玉ギネスチャレンジ～コンサル編～

Sun, 06 Jan 2019 20:35:21 +0900

私は誰？
序章
問題の特定
現状認識（AS-IS）
ゴール設定（TO-BE）
ギャップ
問題の深掘り
対応策の提示
2018/12/29
2018/12/30
2018/12/31
総括

私は誰？

2018/12/31、第69回NHK紅白歌合戦で、三山ひろしさんとともにけん玉ギネス記録を達成した、けん玉ヒーローズのNo.6です。仕事はエンジニアのようなコンサルタントのようなことをやっています。

news.livedoor.com

序章

2018/11/28、ある知らせが舞い込んできました。「再び、紅白歌合戦の舞台にて、ギネス世界記録に挑戦できることとなりました！！」と。昨年末の残念な結果から11ヶ月、うれしい反面、「今回は絶対に失敗できない」という認識を持ちました。日本で最も視聴率が高い番組と言ってよい紅白歌合戦の中でのギネスチャレンジという試み、昨年のチャレンジは立派に終えたものの、心ないバッシングがあったのもたしかです。2度目のチャンスが回ってくるという奇跡を裏返すと、今度また失敗すれば一体どれほどの損失になるのか想像できません。私はいち参加者ですが、けん玉歴は長い方で、参加者の中でも年長者になるので、今回は自分にできることをやろうと思ったのでした。

問題の特定

今回もチャレンジの内容は、けん玉の大皿という技を124人連続で成功するというものです。2017年と同じ内容ですので、2017年と同じようにやれば当然2017年と同じ結果になる可能性が高いと言えます。2017年に成功できなかったのはなぜなのか、まずは問題を特定する必要があります。ここはギャップ分析というフレームワークを使ってみましょう。

現状認識（AS-IS）

2017年も、年末の12/29にけん玉ヒーローズ約120名のメンバーが招集され、ギネス記録達成に向けた練習が行われました。本番まで当日を含めてもわずか3日しかなく、できることには限りがありました。単にけん玉をやればよいというだけではなく、ステージ上では「演者」であることを求められます。姿勢、表情など、テレビに映るための訓練をしないといけないのです。また、紅白歌合戦は日本最大級の生放送番組でもあります。5時間もの時間、秒刻みのスケジュールで何千人もの人々が動くのです。その中でも最大のグループであるけん玉ヒーローズは、移動のときの隊列の組み方、ステージ上での並び方、ステージからの退出の仕方などを細かく練習する必要があるのです。そんな中で、何度か124人で大皿を連続で行なう全体練習をやってみたものの、成功しないのです。「大皿」といえば、けん玉の最も基本的な技なので、楽勝ムードが漂っていたように思います。結局、本番を迎える12/31までを通して、成功率は3割程度でした。成功率3割の状態で、生放送一発で成功させるのは無理があったのです。

www.oricon.co.jp

2018/12/19に紅白歌合戦の番宣のロケを兼ねたリハーサルがあり、集まることができた60名程度で練習を行いました。このときもあまり時間がなく、全体練習を何回かやったのみでした。本番の半分の60人しかいないにもかかわらず、60人連続で大皿を決められた成功率は5割程度でした。「これでは去年と同じ結果を迎えてしまう。」本番のわずか12日前、我々は、極めて危機的な状況にあったのです。

ゴール設定（TO-BE）

問題を解決するにはゴール設定が必要です。ビジネスだとこれはかなり時間がかかるのですが、今回は明確です。124人連続で大皿を成功できればよいのです。ゴールはより具体的な方がよいので、「紅白歌合戦の本番で、90%以上の確率で、124人連続で大皿を成功させる」というのはどうでしょうか。これなら誰でも理解できるのではないかと思います。

ギャップ

ゴール設定の90%と、現状の30%では、なんと60%もの開きがあります。これが「ギャップ」であり、今回の問題です。大事なのは、問題を当事者が理解できるように整理し、説明して、納得してもらうことにあります。これは問題解決において重要なプロセスです。

問題の深掘り

成功率を高める必要があることはわかりました。では成功率とは何なのかもう少し深掘りしてみたいと思います。 124人連続で成功する全体の成功率をPとして、個々の大皿の成功率をpとすると、Pは以下のように表すことができます。

この式から言えることは、全体の成功率は結果でしかなく、個々の成功率にすべて依存するということです。2017年は全体練習をひたすら繰り返しましたが、個々の成功率には目を向けていませんでした。「木を見て森を見ず」になってはいけないとよく言われますが、この場合は「森を見て木を見ず」のような状態に陥っていたのです。

ではなぜ、個々の成功率が低かったのか、今度はなぜなぜ分析フレームワークを使って考えてみましょう。分析してみるとなんとなく共通項が見えてきます。「このチャレンジは簡単だと思っていた」というのが根本原因の一つとして挙げられそうです。大皿というけん玉の最も基本的な技を「難しい」と思えるかどうかが本当の難しさだったのだと言えそうです。

上の図はXMindで描きました。フリー版でもかなり使えます。

http://jp.xmind.net/

対応策の提示

なぜなぜ分析より、以下のような対応策が見えてきました。本来はここで見えてくるのは仮説なので、仮説を検証しないといけないのですが、今回は問題が明確なので省略します。

難しさの言語化と周知
個別の練習方法の言語化と周知
選抜の方法の言語化と周知
集合後の練習方法の言語化と周知

まず、1.は急務と考えました。2018/12/25に以下のような情報の共有を行いました。いろんなエッセンスを詰め込んでみたつもりですが、我々のチャレンジが如何に困難なことであるのかを理解するという意味で、一定のインパクトはあったように思います。

https://www.facebook.com/shakemid/posts/2244599345559437

この時点で本番6日前でした。時間はありませんでしたが、それでもそこから成功率を高められる余地は充分にあると考えました。元々けん玉のレベルがある程度高い人ばかりなので、質の高い練習によって自己鍛錬することができると考えました。

次に、2.ですが、その前に、個々の成功率を高めればよいことはわかったので、どのくらい高めればよいのか考えてみましょう。大皿の成功率で、便宜的に以下のように分けてみようと思います。

カテゴリ	成功率	例示
達人	99.99%	1万回に1回失敗する。高段者、大会上位者など。三山ひろしさんはここ。
上級者	99.9%	1000回に1回失敗する。おそらくけん玉ヒーローズのボリュームゾーン。一般的な目で見れば「けん玉名人」。
中級者	99%	100回に1回失敗する。2018年のDJ KOOさんはおそらくこのへん。
初級者	90%	10回に1回失敗する。2017年のDJ KOOさんはおそらくこのへん。（例に出してごめんなさい。）

124人全員を達人クラスで集められれば話は簡単なのですが、それはほとんど無理です。12月29日、30日、31日に終日拘束されるのは、一般人でも相当厳しいはずです。また、けん玉の高段者はかなりの部分が小中学生なのですが、出演時間の問題で小中学生は出られません。今回、リザーバー候補も含めて全国から140人集まっていますが、この条件で140人も集まるのがまず奇跡なのです。みなさん、けん玉への愛と、使命感で動いているということを忘れてはいけないと思います。

集まったメンバーの中で達人クラスは、三山ひろしさんを含めて45人前後と見ています。計算上、44人としておきます。このクラスの人は現実的な試行回数で大皿を失敗することはまずありません。残る80人をどうするかが問題です。初級者クラスの人は残念ながら今回のチャレンジでは戦力になることができません。中級者クラスの99%でもかなりリスクが高いのです。以下のようなモデルケースを考えてみます。

達人： 44人
上級者: 78人
中級者: 2人
初級者: 0人

これで成功率を計算すると、以下のようになり、90%をなんとか超えます。

よって、目標としては、個々の大皿の成功率99.9%以上を目指し、中級者クラスが数人入ってもやむなしとするあたりが妥当な感じがします。

参加者は最低でも中級者以上でないといけないので、以下のような練習方法を提案しました。

大皿100回連続成功
とめけん10回連続成功

同じ大皿でも、漫然とやるのと「100回連続成功する」と意識してやるのとでは、やり方がまったく異なります。100回連続成功するためには、安定が必要です。けんのグリップ、構え、玉を引き上げる軌道、玉をよける軌道、玉を受けるときの膝の使い方などを高度に安定させないと、100回連続は難しいのです。 2018/12/19の練習のときに、三山ひろしさんが来られて「必ず成功する型を見つけるのが重要です」と、仰っていました。三山さんはけん玉の指導員の資格を持っている方なので、よくわかっておられます。それを数値目標にして、より具体化すると「100回連続成功できるような型を見つける」ということになるかと思います。100回連続成功が安定してできるなら、上級者の領域にかなり近いと言えます。

とめけんについては少し毛色が違います。とめけん10回連続成功は、大皿100回連続成功よりも難しいです。けん玉は面白いもので、大皿ばかりやってもなかなか上手くなりません。むしろ上位の技を練習することで、結果的に大皿も上手くなる効果があります。また、とめけん連続成功の10回目はそれなりに緊張感があり、本番を想定したメンタルの強化にも役立ちます。

私が主にやったのはここまでです。 12/29に集合してリハーサルを行う段階で、個別の成功率がどの程度に達しているのかが、結果の明暗を分ける大きな鍵だと考えました。

3.と4.は、進行に大きく関わるので今回のチャレンジの統括者に任せました。今回は強い思いを持って集まったけん玉プレイヤーを選考することになります。選考に落ちた人は非常に苦しい思いをすることは想像に難くありません。けん玉の大会に慣れている人は、予選落ちも経験していると思いますが、そのような経験がない人も多いでしょう。他人に何らか負担を強いるようなことをお願いするときは、明確に言語化して、事前に書面(できれば対面)で周知して、合意を取ることが納得感につながります。このプロセスは省いてはいけません。

2018/12/29

この日初めて、今回のチャレンジを行う140人が渋谷のNHK放送センターに集まりました。140人ものけん玉プレイヤーが一堂に会すると壮観です。全体練習の開始前に、統括者より、事前にメンバーの選考を行うことが周知されていました。選考方法は以下のようなものでした。選考の実施は、流れから私が引き受けました。

大皿に100回連続挑戦する。途中で失敗したらリザーバー候補に回る。
30人ほどのグループに分かれて、順番に大皿を行う。途中で失敗したらリザーバー候補に回る。
とめけんに連続挑戦する。途中で失敗したらリザーバー候補に回る。リザーバー候補が定員に達するまで繰り返す。

選考1.は私が提案した練習方法と同じものです。よい選考方法とは、以下の2点を満たしている必要があります。(1)はよくわかると思うのですが、意外と(2)には考えが回っていなかったりします。

(1) 成功率が低い人をふるい落とす
(2) 成功率が高い人をふるい落とさない

上の方で分けた成功率の人が、大皿100回連続成功できる確率は二項分布によって求めることができます。計算してみると以下のようになります。

カテゴリ	大皿1回の成功率	大皿100回連続の成功率
達人	99.99%	99.0%
上級者	99.9%	90.5%
中級者	99%	36.6%
初級者	90%	0.027%

二項分布の計算サイト https://keisan.casio.jp/exec/system/1161228843

この選考で、中級者以下の大部分をふるい落とすことができ、上級者以上はほぼ落ちないと期待できるので、妥当性はありそうです。ちなみに、ほぼ確実に99%以下の成功率の人をふるい落とすには膨大な試行回数が必要になります（失敗する確率1%、95%信頼区間、誤差10%で計算すると38000回くらい）。さすがにこれは現実的な時間ではできません。大皿という極めて成功率が高い技で差を付けるのは難しいのです。興味のある方は、大数の法則やベルヌーイ試行のあたりを調べてみてください。

実際にこの選考で落ちてしまったのは140名中5名でした。去年の感じだと30名前後落ちてもおかしくないと考えていたので、これはうれしい誤算です。みなさんかなり練習を積んできているのだと期待できました。反面、選考はより過酷で、理不尽なものになることを意味していました。大皿がきちんとできる人を落とさなければいけないということだからです。

選考2.では1人も落ちませんでした。本番に近い緊張感を得るには悪くありませんが、個々の大皿の試行回数は少なくなるので、選考方法としてはあまりよくなかったようです。

選考3.は非常に厳しいものでした。大皿で決まらない以上、技の難易度を上げる必要はあるのですが、とめけんは大皿とは特性が異なるのです。大皿の成功率ととめけんの成功率には強い相関があると想像できますが、とめけんは達人クラスでも99%以上の成功率にすることが難しいのです。これは、玉を引き上げた後の調整がほとんどできないことに起因するのですが、そこが大皿とは決定的に違います。（上級者クラスになると、むしろとめけんよりふりけんのほうが成功率が高くなります。）そのため、連続成功だと、どんなに上手い人でも外してしまうリスクがあります。技術よりも、むしろ度胸試し・運試しの要素が強くなってしまうのです。上記の、条件(2)を満たせない可能性が大いにあるのですが、このときはこのやり方でやると周知している以上、このやり方でやるしかありませんでした。不安は的中し、世界クラスのけん玉プレイヤーを選考で落としてしまうことになりました。

選考後には様々な人間模様がありました。泣き出す人、納得できずその場を去る人、リザーバーになったときのために練習をする人、自分の実力を認め進んでサポート役に回る人など、これは一言では言い表せないものがあります。私自身、けん玉の大会に遠征して、予選落ちした経験もありますので、似たような状況は想像できますが、今回はそれが3日間続くので、プレッシャーは相当なものだったと思います。

続いて、全体練習に入りました。けん玉を、武道やスポーツでよく用いられる「心技体」のフレームワークに当てはめて考えてみると、今回は「体」はほぼ関係ありません。「技」については、上記の練習と選考でかなり高められると考えられます。残る「心」については、打ち手を考える必要がありました。 2017年に失敗した方は、練習では1度も失敗しなかったにもかかわらず、本番で震えて頭が真っ白になってしまい、失敗したといいます。上の方で言及したゴール設定の「紅白歌合戦の本番で、90%以上の確率で、124人連続で大皿を成功させる」の「紅白歌合戦の本番で」という部分です。

プレッシャーのかかる状況で技を成功させるには、場慣れするのが最もよいのですが、そのような時間はありません。2017年の経験者も多いですが、今回初めて参加するメンバーも相当数いました。本番では、当然ですが1回でも失敗すればそれで終わりです。そのため、練習においても1回でも失敗すれば何かが起こる仕組みを作る必要がありました。検討の結果、選考に落ちた人の中からリザーバー候補を選出しておき、全体練習で1回でも失敗すれば、その場でリザーバーと交代するというやり方で進めることになりました。これは、リザーバー候補にはチャンスになりますが、いったん選考に通ったメンバーには非常に強いプレッシャーになります。本番までの3日間、本番と同等の「1回失敗したら終わる」というプレッシャーに慣れていただく必要があったのです。

この日は、板踏み（ステージでのリハーサル）を含めて、10回の全体練習を行い、いずれも124人連続で大皿を成功することができました。リザーバーとの交代はありませんでした。当初目標の成功率9割は確保できているように思いました。少なくとも、2017年は3割程度しか成功していなかったので、明らかに違ったと言えます。

2018/12/30

この日も、全体練習を開始する前に、大皿を100回連続で成功する選考を行いました。成功率を高く維持する必要があるのと、成功率を見極める試行回数は多いほど正確になるからです。選考の結果、2名が失敗し、リザーバー候補と交代になりました。また、1名遅刻者が出たので、その1名もリザーバーと交代になりました。

この日の全体練習の5回目、29日から数えると15回目に、1名が大皿を失敗しました。全体練習での失敗はこれが初めてでした。大皿の試行回数はこの時点で 124*15=1860回になり、個々の大皿の成功率は 1-1/1860≒0.9995=99.95% に達していることが伺えました。これほどの成功率でも大数の法則により、試行回数を重ねると失敗が現れます。

全体練習では個々の成功率を上げる効果はあまりありませんが、全体の成功率の確認と、本番へのプレッシャーへの慣れのためにある程度繰り返す必要があります。29日から累積で20回の全体練習を行い、失敗したのは上記の1回のみでした。本番まであと1日、非常に高いレベルで仕上がっている手応えを感じました。

上記の失敗の内容は、引き上げた玉がけん先にぶつかるというものでした。実は1日前の板踏みの際にも危ない場面があり、けん先にぶつかった後かろうじてキャッチしているところを見ていました。99.9%の成功率でもこれはあり得るのです。けん先を避ける技術はあるので、伝えようか迷いましたが、フォームを変えることになるので、一時的に成功率が落ちるリスクもあります。しかし、2度あることは3度あると考え、以下の動画を公開することにしました。中皿を上にして構えれば、けん先に玉をぶつけることはまずなくなります。後で何人かから参考になったと言っていただけたので、公開してよかったのかなと思います。

2018/12/31

この日は本番を迎えるのみでした。全体練習を5回行って失敗はなく、最終的に25回全体練習を行って24回成功していました。極めて特殊な状況下で、プレッシャーに耐え、皆さんよくがんばったと思います。心・技ともに非常に高いレベルでまとまっていたように思います。本番は承知のとおり、危なげなく成功することができました。終わるタイミングまで完璧で、練習でも出たことがないほどの出来でした。本番で練習以上のものが出るのは、質の高い練習と、高い集中状態が重なった理想的な状態だったということに他ならないと思います。しかし、そこまで行ってようやく「人事を尽くして天命を待つ」といえる状態で、運命を引き寄せることが出来て本当によかったと思います。

ステージ上で私は6番目でしたが、自分が成功したあと、半分を過ぎたあたりで成功を確信し、ステージ上で泣いていました。映ってないと思いますのでご勘弁いただきたいところです。

総括

けん玉ギネスチャレンジをコンサル的な視点で振り返ってみました。けん玉ギネスチャレンジを通して、「数値目標の力」というものを感じていただけたのではないかと思います。これはビジネスにも使えるものだと思いますので、何かの機会に思い出していただけますと幸いです。

ぷららのIPoEでIPv4 over IPv6を使いつつPPPoEも共存させるメモ

Sat, 01 Sep 2018 13:54:45 +0900

概要
元々の環境
機器の購入
構成の問題
構成案
具体的な設定

概要

近頃、夜間や休日などの混雑時間帯にあまりにインターネット接続の速度が遅いのでIPoE方式にしてみようと思いました。これは、一般的な家庭である我が家でIPoE（IPv4 over IPv6）を導入したときのメモです。

元々の環境

元々のインターネット接続環境は以下のような感じです。

アクセス回線：フレッツ光マンションタイプ(VDSL方式)
ISP：ぷらら(ぷらら光マンションタイプ)
PPPoEルータ： NTT Web Caster V120

ぷららではIPoEサービスを「ぷららv6エクスプレス」という名前で提供しています。 2018/3/1以降にぷららに申し込んだユーザは自動的に有効になるようですが、それ以前からのユーザはマイページから自分で申し込む必要があります。私はマイページで申し込んでから2日ほどで開通のお知らせメールが来ていました。「ぷららv6エクスプレス」については、↓のページに説明があります。 www.plala.or.jp

機器の購入

IPoEでIPv6インターネットに接続するには、Web Caster V120でも問題ありません。IPoEが開通すると、特に何もしなくてもIPv6でつながるようになります。しかし、IPoEでIPv4インターネットに接続するには、「IPv4 over IPv6」が必要になります。IPv4 over IPv6の方式にはDS-Lite方式やMAP-E方式などいくつかの方式があります。ぷららは方式を非公開にしていますが、MAP-E方式のサービスの1つである「OCNバーチャルコネクト」を使用しているようです。 OCNバーチャルコネクトを使用するには専用機器が必要で、今のところ「ドコモ光ルーター01」しか対応していないようです。

[asin:B079CK8GGL:detail]

「ドコモ光ルーター01」はNECのAterm WG1200HPのOEM製品のようですが、ファームウェアは別物のようで、各社のIPv4 over IPv6方式に対応しているようです。無線LANルータとしてはやや割高な気はしますが、これしかないので仕方がありません。

構成の問題

さて、家庭内からインターネットに向けて接続するだけなら、Web Caster V120をドコモ光ルーター01に入れ替えてしまえばよいのですが、そう簡単にはいきません。問題点は以下の2つです。

自宅サーバ
ぷららフォン for フレッツ（IP電話）

自宅サーバはダイナミックDNSで外にIPアドレスを公開しているのですが、IPoEだとIPv4アドレスの使用には制限があります。OCNバーチャルコネクトだと、公開できるポートが限られているようでした。少なくともWebやメールで使うようなWell-Knownポートは使えません。そのため、外部に公開するIPアドレスを使用するには、PPPoE接続を残さなければいけません。また、Web Caster V120はVoIP ゲートウェイの機能を内蔵しており、我が家では電話機をつなげています。これがないと、ぷららフォン for フレッツを使用できません。あまり使うことはないのですが、それでもたまに使うのでなくすわけにもいきません。

構成案

というわけで、Web Caster V120は残しつつ、ドコモ光ルーター01を追加して、PPPoE接続かIPoE接続かを選択できるようにする方式が最もよさそうです。図にすると↓のような感じです。

VDSLモデムのLANポートは1つしかないので、WAN側にL2スイッチを挟んでWeb Caster V120とドコモ光ルーター01を接続することにしました。LAN側は、2つの機器を同一のネットワークに置いて、配下の機器ごとにデフォルトゲートウェイを選択することで接続方式を分けられるようにしました。

具体的な設定

Web Caster V120では、IPv6ブリッジ機能を無効にしておきます。これで、IPv6での通信はドコモ光ルーター01側からになります。

ドコモ光ルーター01は起動時に接続方式を自動判定します。IPoE接続は、手動では設定できないようでした。

自動判定で何をやっているのかはわかりませんが、おそらく取得したIPv6アドレスのレンジからIPoE接続事業者（VNE）を判定しているのではないかと思います。ぷららの場合は「OCNバーチャルコネクト」と判定されました。再起動を促されるので再起動します。

再起動すると、動作状態が「OCNバーチャルコネクト」になりました。これで、IPv4 over IPv6が使えるようになっています。

IPoEの動作確認は↓のサイトを使うと便利です。 ipv6-test.com

まずは、デフォルトゲートウェイをWeb Caster V120側（PPPoE接続）にした場合は以下のようになりました。IPv4アドレスがぷららのものになっているのがわかります。

続いて、デフォルトゲートウェイをドコモ光ルーター01側（IPoE接続）にした場合は以下のようになりました。IPv4アドレスがOCNのものになっているのがわかります。

Googleの「インターネット速度テスト」で速度を測ってみました。結果は一目瞭然で、IPoEが圧倒的に速いです。計測したのは土曜日の23時台なので混雑している時間帯だと思います。今はまだ設備が空いているからだとも言えますが、VDSLの限界の100Mbpsに迫る速度が出ていて驚きました。

というわけで、IPoE接続でIPv4 over IPv6を使いつつ、PPPoE接続も共存させることができました。しかし、IPoEを巡る状況はずいぶん複雑になってるのですね。一般的なネットワークエンジニアならわかると思いますが、一般的な人にこれを理解してもらうのはかなり難しいように思います。

Kenko スカイメモS に Vixen ポーラメーターを取り付ける

Wed, 02 May 2018 14:20:47 +0900

Kenko スカイメモSにVixen ポーラメーターを取り付けてみたメモです。

Kenko ポータブル赤道儀スカイメモS シルバー 455166

出版社/メーカー: ケンコー
発売日: 2015/04/21
メディア: Camera
この商品を含むブログ (1件) を見る

Vixen ポータブル赤道儀星空雲台ポラリエ(WT) ホワイト 355051

出版社/メーカー: ビクセン
発売日: 2011/11/30
メディア: エレクトロニクス
購入: 1人クリック: 41回
この商品を含むブログを見る

4年ほど遠征用の赤道儀としてVixen ポラリエを使ってきましたが、Kenko スカイメモSがどうしても気になってしまったので購入してしまいました。スカイメモSはポラリエと同価格帯のポータブル赤道儀ですが、後発だけあってポラリエより優れている点がいくつかあります。ポラリエもオプションで機能拡張できるのですが、本体に対してかなり高価な感じがするのでスカイメモSはお買い得かなと思います。

	ポラリエ	スカイメモS
実売価格	37000円前後	35000円前後
耐荷重	2kg（オプション追加で6.5kg）	5kg
極軸望遠鏡	オプション（約30000円）	付属
電源	単3乾電池2本で2時間	単3乾電池4本で72時間

ポラリエにあってスカイメモSにないのは方位磁石くらいかなと思います。ポラリエにはポーラメーターというオプションがあり、北極星が見えなくてもある程度の精度で設置することができます。

Vixen 天体望遠鏡アクセサリガイダーポーラメーターポラリエ撮影用 35511

出版社/メーカー: ビクセン
メディア: Camera
購入: 3人クリック: 8回
この商品を含むブログを見る

スカイメモSにこんな感じで取り付けられたらいいなあと思いました。ポーラメーターはカメラのアクセサリーシューに取り付けられるようになっているので、スカイメモSにアクセサリーシューを取り付けてみることにしました。

材料はこんな感じです。

エツミのE-6617は1/4インチネジ（カメラネジ）でアクセサリーシューを取り付けることができます。私が持っていたのはE-6117という旧製品で、ネジ穴が貫通しているところが違うようです。

ETSUMI アクセサリーシューII E-6617

出版社/メーカー: エツミ
発売日: 2014/10/10
メディア: Camera
この商品を含むブログを見る

インチネジはホームセンターではなかなか売ってないのでモノタロウで購入しました。長さは3/8インチのものにしました。 www.monotaro.com

ピンバイスで電池ボックスのふたに穴を開けます。

開けました。

さらに、リーマーで穴を拡げます。だいたい直径7〜8mmくらいが良いと思います。拡げすぎには要注意です。

拡げました。きれいに仕上げたい方はヤスリがけしてください。

アクセサリーシューをネジ止めします。かなりがっちり止まります。

裏側はこんな感じです。

ネジの頭が少々浮いていますが、このくらいなら電池に干渉しませんでした。電池とふたの間の余裕があまりないので、見極めながら穴を拡げてください。

電池ボックスにふたをするとこんな感じです。

ポーラメーターを取り付けるとこんな感じです。うーん、まるで純正品のような自然さ。

というわけで、スカイメモSにポーラメーターを取り付けてみました。これで、たとえば日食のときなど北極星が見えなくてもある程度極軸を合わせることができます。

余談ですが、スカイメモSは日本ではKenkoがスカイメモSという商品名で販売していますが、元はSky-WatcherのStar Adventurerという製品です。本体の販売価格は、日本と海外であまり変わらないですが、微動台座などのオプションは海外の方がだいぶ安いようです。少しの価格差なら日本の代理店経由で買う方が安心感があるかもしれませんが、さすがに倍とかになると、送料を考慮しても海外サイトで購入した方がお得な気がします。

Star Adventurer – Sky-Watcher USA

Star Adventurer Accessories – Sky-Watcher USA

テカポ湖で星を見てきました

Sun, 22 Apr 2018 00:19:48 +0900

ニュージーランド・テカポ湖に星を見に行ってきました。テカポは世界一星空が美しいと言われているので、天体観測が趣味の私はいつか行きたいと思っていました。テカポのベストシーズンは4月〜8月と言われていて、訳あって4月に時間ができたので、新月のタイミングを狙って行ってみることにしました。4/16が新月だったので、その日を挟んで4/14-18の4泊5日間滞在しました。

retrip.jp

日本からのアクセスは、まず北島のオークランドに飛んで、そこからクライストチャーチかクイーンズタウンを目指すのが一般的なようです。だいたい合計12時間くらいのフライトになります。空港からテカポまでは、バスかレンタカーでの移動がよいようです。クライストチャーチからは1日に1回バスが出ているようなのですが、飛行機のタイミングとうまく合わず、余計に一泊する必要がありそうだったので、私はクライストチャーチでレンタカーを借りることにしました。海外での運転は、去年の北米皆既日食のときにアメリカで経験していました。そのときに取得した国際免許がまだ有効でした。ニュージーランドは日本と交通ルールが似ていて、左側通行・右ハンドルで、速度はkm表記なのでアメリカよりだいぶ日本人向けだと思います。また、レンタカーの料金は保険込みで1日5000円くらいで、アメリカで借りたときの半額くらいでした。車があると現地での移動や機材の運搬も楽なので、レンタカーはおすすめかなと思います。

ニュージーランドの歩き方 - ニュージーランドの交通ルール

クライストチャーチからテカポまでは、だいたい3時間くらいかかります。飛行機に12時間くらい乗った後、3時間くらい運転するのはきつかったですが、交通ルールをあまり気にしなくていいのでアメリカでの運転より楽だった気がします。テカポへの道中では、サービスエリアのようなものはなく、景色の99%が草原でたまに羊がいっぱいいるような感じだったので、だいぶ眠くなりました。さすが人間より羊の方が多いニュージーランドです。途中にアシュバートンという大きめの町があるので、そこで休憩しました。途中での給油は必要ありませんでしたが、ガソリンスタンドは何十kmもないので、半分を切ったら給油するくらいでちょうどいいと思います。

経路はほぼ1号線と8号線だけなので難しくないと思います。ナビはGoogle Mapのアプリで充分だと思います。途中79号線を通るほうが少し早いようなのですが、山越えで50kmくらい何もなくてしんどかったので、次に行くことがあったら上のような経路で行くと思います。

www.booking.com

テカポでの宿はAirbnbでバックパッカー向けのホステルを予約しました。ホテルもありますが、1泊2万円以上してちょっと高めなところが多いようです。夜は星ばかり見ているのと、近くにスーパーやレストランがあって食事に困ることもなさそうだったので、私は安めのホステルでちょうどよかったかなと思います。3人部屋しか空いていなかったので、1人で3人部屋を占有してましたすみません :-p

ホステルの庭からでも余裕で天の川が見えるすばらしいところでした。天気を見ながらちょっと庭に出て撮影できるのは楽でした。

テカポ湖に来たら、まず多くの人は湖畔にある善き羊飼いの教会を目指すと思います。

私は初日に到着したのは日没直後くらいでした。宿にとりあえずチェックインした後、善き羊飼いの教会の近くに行ってみました。夜7時台から真っ暗で、空には見たことないくらい濃い天の川と南天の星空が見えて感動しました。

善き羊飼いの教会の周辺で、天の川は十分に見えます。しかし、有名観光地なのでヘッドライトを点けた車が深夜でもひっきりなしに出入りするので、写真撮影にはまったく向いていません。ヘッドライトが被ってひどいことになります。被ってもここまで天の川が写っているのはすごいのですが。

たぶんみなさん南半球に来たからには南天の空を撮影したいであろうと思うので、写真撮影するなら、テカポの村を少し南に抜けたあたりがおすすめです(地図上の赤いポインタのあたり)。このあたりは南側にまったく明かりがなく、南天の撮影には絶好の条件でした。

昼間は特にやることを決めていなかったので、テカポ湖の西のマウントジョンにある天文台に行ってみました。テカポ湖から車で15分くらいで頂上まで行けます。通行に8NZDかかります。歩いて登るのは無料です。夜は道路が閉鎖されて、有料のツアーの申込者だけが入れるようになるようです。団体行動が苦手なので私は行きませんでしたが、地上よりも星空がさらによく見えて、天文台から望遠鏡で星を見たりできるようなので、行ってみる価値はあると思います。ツアーは150NZDほどかかります。テカポ村のスーパー(4 SQUARE)の横に受付があります。

頂上からは、エメラルドグリーンのテカポ湖が見えて、すばらしい眺めでした。昼間に行くのもおすすめです。

ニュージーランドの4月は秋です。昼は15度くらいまで上がるので、日本の4月とそんなに変わらないかなと思いますが、昼夜の気温差はわりと大きく、夜は氷点下まで下がりました。真冬用の防寒着を持って行ったのでちょうどよかったです。6月〜8月は真冬になってしまうので、日本からニュージーランドに行くなら気温差が比較的小さい4月はベストかもしれません。

テカポに4泊滞在して、4晩とも天の川が見える天気に恵まれました。ニュージーランドの天気は「1日で全ての季節がやってくる」と例えられることもあるほどに、非常に変わりやすいです。4日中2日は夜に雨が降りましたが、待っていると快晴になりました。私はweather.com(iPhoneの天気予報)で1時間単位の天気予報をチェックして行動していました。weather.comの予報は1時間単位でかなり的確に当たっていたように思います。最近の天気予報はよく当たります。なので、雨が降っていても諦めないで、晴れそうな時間まで寝て待っていました。

今回の機材は以下のような感じです。北米皆既日食のときとだいたい同じで、BORG 71FL、α7S、ポラリエの軽量トリオを持って行きました。ポラリエは南半球にも対応しています。

望遠鏡
- BORG 71FL
- BORG 7872 x0.72レデューサ
- BORG 6015 ミニボーグDX-LD鏡筒
- BORG 7761 M57ヘリコイドDXII
- BORG 7000+5005+八仙堂 EOS EF → SONY E マウントアダプター（この組み合わせはフルサイズでも四隅がケラレません。また、5005に48mmフィルターを取り付けることができます。）
- BORG 0037 ファインダー
カメラ
- SONY α7S
- ロワジャパンタイマー機能付きリモートレリーズ
三脚・赤道儀
- Vixen 星空雲台ポラリエ
- BORG 3101 片持ちフォーク式赤道儀
- SIRUI トラベラー三脚 T-2005X
- SIRUI 2ウェイ雲台 L-20S

赤道儀を使うときはまず極軸を合わせないといけません。北半球では北極星というわかりやすい目印がありますが、南半球の場合は「南極星」のようなものはありません。代わりに、はちぶんぎ座という星座の中にある5〜6等星の暗い星で構成される台形の形を目安にするのですが、知識としては知っていましたが実際に南天の星空を見てもさっぱりわかりませんでした。3日目まではポラリエのポーラメータで大雑把に合わせていました。30秒くらいしか露出しないのでそれでも十分なのですが、ちょっと悔しいので勉強して、最終日にようやく台形を見つけられるようになりました。台形は、8倍の双眼鏡で視野いっぱいによく見えました。探し方はいくつかありますが、小マゼラン雲から辿るのがいちばんわかりやすいと思いました。こちらのサイトを参考にしました。 ryutao.main.jp

今回、初のニュージーランド・初の南半球で、テカポの世界一の星空を見ることができて感動しました。この先どんな星空を見ても満足できない贅沢な体になってしまった気もしますが、最高の星空を見ることができてよかったです。またいつか来てみたいです。

71FL+レデューサー7872セット 6472

メディア: エレクトロニクス

ソニー SONY フルサイズミラーレス一眼 α7S ボディ ILCE-7S

メディア: Camera

ソニー SONY フルサイズミラーレス一眼 α7SM2 ボディ ILCE-7SM2

メディア: Camera

SIRUI(シルイ) アルミニウム中型三脚 T-2005X (コード000114)

メディア: エレクトロニクス

SIRUI シルイプロ2ウエイ雲台 L-20S [並行輸入品]

メディア: エレクトロニクス

ロワジャパン互換シャッターリモコンコードレリーズ SONY RM-VPR1 対応【プロ専用液晶LCD タイマー機能付撮影回数設定無制限】【PDF日本語説明書あり】

メディア: エレクトロニクス

【国内正規品】 LEE 角型ポリエステルレンズフィルター SP-32 ソフト No.3 100mm×100mm ソフト描写用 209559

発売日: 2015/11/06
メディア: Camera

CISSP受験体験記

Thu, 15 Mar 2018 02:00:28 +0900

概要
勉強方法
申し込み～試験
- 福岡センタでの残念な出来事
- 東京センタで再試験
今後の対応

概要

CISSPの試験に合格しました。勉強期間は約4週間で、幸い一発合格できました。

CISSPは米国発のセキュリティの認定資格で、国際的に認められています。セキュリティ業界では有名な資格ですが、日本ではCiscoやOracleの資格と比べるとあまり知名度はないかもしれません。

試験の内容は、NDAにより一切口外してはいけないことになっているので、勉強方法や受験の流れについて振り返ってみたいと思います。

CISSPを目指す方の一助になれば幸いです。

勉強方法

まず、CISSPの試験はそれなりに難しいです。少なくとも、IPAの情報セキュリティスペシャリスト（今は情報処理安全確保支援士という~~ださい~~名前の試験に変更）と同等かそれ以上の難易度という感想です。難しいと思った理由は主に3つです。

(1) 範囲がすごく広い

CISSPの試験範囲は8つのドメインに分かれていますが、その1つ1つで本が何冊も書けるんじゃないかというほど広いです。問題集には、裁判の進め方からNmapコマンドのオプションまで出てきます。全てに精通しているような人は超人だと思います。私は、IPAのネットワークスペシャリストと情報セキュリティスペシャリストを取得していますが、それでもカバーできるドメインはせいぜい3つか4つくらいだと思います。

(2) 問われる内容がそれなりに深い

出題形式はだいたい4択問題なので、IPAの情報処理技術者試験の午前問題と似たような感じですが、同等と思うのは甘いです。午後問題程度のそれなりに深い内容を問われると思った方がよいと思います。出てくる用語もそれなりに難解です。例えば、Certification と Accreditation の違いとか。日本語だと認証と公認という感じで違いがよくわかりませんが、両者は違います。試験は日本語で受けられますが、外資系ベンダの試験にありがちな感じで、日本語だと意味がわからなかったり、誤訳としか思えないところもあるとかないとか。英語の原文も同じ画面で確認することができるので、英語の原文を必ず確認した方がよいと思いました。

(3) 独特で曖昧な問題が多い

この3つ目が最大の難関だと思います。問題に対する答えを覚えるだけでは全く歯が立たないと思います。表現するのは難しいですが、自分の主観は捨てて、「CISSPであればそう考えるべきである」というような視点が必要だと思います。 CISSPは、現実的でビジネス（経営者）寄りな視点を求められるので、例えば、リスクマネジメントの目標が問われるような場合は、「リスクを完全に無くす」のではなく「（経営者が）リスクを許容できるレベルにする」のような選択肢がおそらく正解に近いんじゃないかと思います。これは、問題集をやってみるとわかると思いますが、何を言っているのかさっぱりわからない問題が出てくると思います。私もそうでしたが、「CISSPにあるべき視点」のようなものを意識して、慣れてくるとなんとなく正解が見えてくるようになってきたと思います。

CISSPの一般的な勉強方法として、NRIさんがやってる1週間のセミナーがあります。しかし、私は未受講です。セミナーの評判は良いのですが、受講に50万円くらいかかるのが大きな障壁です。これを受講するのは会社のサポートがないと厳しいでしょうね。独学だと知識の偏りが気になるので、合格後でもなんとかして受講したいところです。

https://www.nri-secure.co.jp/service/isc2/cissp.html

以下に、私が勉強に用いた教材を紹介していきたいと思います。

CISSP認定試験公式ガイドブック

作者:Susan Hansche,John Berti,Chris Hare
発売日: 2005/09/23
メディア: 大型本

数少ない日本語の本です。なんとなく購入していましたが、あまりの厚さに3分の1ほど読んで挫折しました。現在は絶版になっていて、新版が予定されているようですが、紙の本はいらないかなと思います。（売却してしまいました...）

新版 CISSP CBK 公式ガイド

発売日: 2018/09/20
メディア: Kindle版

こちらが新版です。だいぶ値上がりしましたね。。

CISSP Official (ISC)2 Practice Tests (English Edition)

作者:Chapple, Mike,Seidl, David
発売日: 2018/05/22
メディア: Kindle版

練習問題が1300問収録された本です。私はKindle版を購入しました。比較的お手頃な価格で非常におすすめです。この本を購入すると、本と同じ内容のテストがWebで利用できるようになります。Webテストの作りがいいので本を読むことはほとんどなかったです。

ちなみに、Webテストの登録方法は、本のあるページに書いてある内容を入力するというものでした。セキュリティ的には弱いですね :-p

Webテストはこちら https://testbanks.wiley.com/

私はまず、このWebテストで50問ほどのミニテストを作ってなんとなく実力を判定してみました。初見でおおむね7割前後は得点できていたので、苦手なドメインを中心に後述の本を拾い読みして偏りを埋めるという勉強のやり方で進めました。ネットワークセキュリティや暗号のところは初見で8割くらい得点できましたが、米国の法律や裁判のところはさっぱりわからず、半分くらいしか得点できませんでした。 IPAの情報処理技術者試験でも法規の出題はありますが、午前問題でせいぜい数問とかなので、まるごと捨ててもなんとかなりますが、CISSPでは2,3割がそんな感じなので捨てるわけにはいかず苦労しました。考えてもわからない暗記物はかなり苦痛ですが、そういう試験なので仕方ありません。暗記するしかない問題もありますが、大部分は考えないといけません。問題に対する答えを覚えるのではなく、なぜその答えになるのか、納得できるまで後述の本で該当箇所を勉強するのがよいと思います。

(ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide (English Edition)

作者:Chapple, Mike,Stewart, James Michael,Gibson, Darril
発売日: 2018/04/11
メディア: Kindle版

この本も非常におすすめです。これもKindle版を購入しました。こちらも登録するとWebテスト1421問を利用できるようになります。Webアプリの作りは前述の Practice Test のほうがしっかりしてます。

Webテストはこちら http://sybextestbanks.wiley.com/course/index/id/102

1000ページ以上ある辞書のような本なので、全部読むのは苦しいと思います。気になるところを拾い読みするだけでも充分勉強になると思いました。時間と根性がある人は全部読むととても勉強になると思います。これももうすぐ新版が出るようです。

【発刊記念キャンペーン価格】ALL-IN-ONE CISSP認定試験　学習参考書　第5版　～情報セキュリティプロフェッショナルのための総合事典～

作者:ション・ハリス
発売日: 2014/02/02
メディア: Kindle版

これも数少ない日本語の本です。半額になってたのでKindle版を購入してみました。ちょっと内容が古く、ときどき誤訳じゃないかと思うところがあったりしますが、日本語で概要を捉えるにはよいんじゃないかと思います。章末の問題集が、公式の本よりひねられた感じになっていて、本番の雰囲気に近いような気がしました。

Official (ISC)² CISSP Study

learnZapp
Education
$14.99
[email protected]" width="60px" height="15px" />

前述の Official Study Guide から、Exam Essencials と Review Questions を抜き出したようなアプリです。本があればいらない気はしますが、手軽にテストの練習ができて楽しいので、1200円がそれほど高いと思わなければ買ってもいいと思います。

申し込み～試験

福岡センタでの残念な出来事

2週間くらい勉強して、なんとなく模擬テストで8割くらい得点できていたので、そろそろ行けるかなと思って申し込むことにしました。受験するだけで7万円くらいかかる試験なので相当の覚悟が必要です。現在のところ、日本では東京・大阪・福岡の3カ所でしか受験することができません。私が申し込もうとしたときには、東京・大阪は1ヶ月以上先までほとんど空いていませんでした。福岡だけはわりと空いていたので、たまには福岡まで旅行するのもいいかなと思って、福岡センタで受験することにしました。試験日は約2週間後にしました。

Pearson (ISC)² 認定試験 (ISC)2 :: ピアソンVUE

福岡センタは博多駅の近くにあるので、博多駅の近くで前泊しました。試験開始の30分ほど前に行き、静脈の登録や写真撮影などを行ないました。 CISSPの試験では、途中の休憩は自由で、試験ルームの外に出ることもできます。ただし、休憩中も時間は経過していきます。試験センタに来る前に、飲み物と軽食を買っておくのがよいと思います。

適当に休憩をはさみつつ、250問中150問ほど回答したところで、画面がフリーズしました。システム担当の方が慌てた感じで試験ルームに入ってきて、トラブルシューティングを始めました。どうやら、サーバのトラブルで、部屋にいた全員が影響を受けたようです。部屋には6人くらいいたと思いますが、4人くらいは試験を途中から再開できたようでした。しかし私ともう1人は、途中経過を復元できなくなってしまい、その日はもう再開できないと謝られてしまいました。ピアソンで何回か別の試験を受けたことはありますが、こんなことは初めてです。思わぬトラブルで試験を中断されて困惑しましたが、こういうトラブルの時のシステム担当の方の気持ちは痛いほどよくわかるので、同情してしまいます。

別の日程での再試験を提案されましたが、私はわざわざ福岡まで来てるのでそれなりに旅費がかかっています。完全に先方の過失なので旅費を補填できないのか交渉しましたが、受験の規定に何が起きても受験料以上は保証できないとの記載があり、聞いてもらえませんでした。再試験については、たまたま2日後に東京センタの空きができたようなので、東京センタで受験することとなりました。旅費については無念な気持ちでいっぱいですが気持ちを切り替えるしかありません。わざわざ福岡まで来たのはいったい。博多でラーメンを食べて帰るだけの旅になってしまいました。

東京センタで再試験

東京センタは有楽町と新橋の中間くらいにある、帝国ホテルタワーの18階です。試験は9時からなので、30分くらい前に来て、同じように静脈の登録や写真撮影などを行ないました。

100問毎くらいに休憩を挟みつつ、2時間くらいで250問に回答しました。わからない問題にはマークを付けました。 250問一通り終わった後、50問くらいマークした問題を見直し、さらに250問全てを2回見直しました。結局マークした50問くらいはよくわかりませんでしたが、合格基準はおおむね70%と言われていて、仮に全部外していても80%くらいは得点できているだろうと判断したので終了しました。その時点で、3時間10分ほど経過していました。制限時間は6時間なので、時間的にはだいぶ余裕がありました。朝の9時前から始めて、12時頃には終わっていたのでそれほどお腹も減らず、体力的にも余裕がありました。

試験終了後、結果はすぐにわかります。画面には何も出ませんが、受付で試験結果が紙で出力されます。結果を見ると、無事に合格していました。昔から、いつか取得しようと思っていた資格だったのでうれしかったです。 CISSPの試験では合格すると点数はわかりません。不合格だと弱かったドメインがわかるらしいです。

福岡で150問ほど進んでたので、本番の試験の傾向をなんとなく知ることができ、それを踏まえて余分に1日勉強できたので、再試験の時は気持ちに余裕があったように思います。結果的には良かったんじゃないかなと思いました。合格してしまえば福岡でのトラブルもレア体験として笑い飛ばせるというものです。

今後の対応

今後は、(ISC)²に登録して正式にCISSPと認定される予定です。CISSPホルダーからの推薦（エンドースメント）が必要なので、知人のCISSPホルダーにお願いしようと思います。知人にCISSPホルダーがいない場合は(ISC)²が直接認定してくれるようですが、レジュメを提出したりしないといけないようでちょっと面倒かもしれません。

CISSPの試験は、2018/4から大幅に変わるようなので、この記事の内容は古くなる可能性があります。最新の情報は(ISC)²のウェブサイトをご参照ください。

japan.isc2.org

最も大きな変更は、試験の方式がCAT(Computer Adaptive Testing)という方式になるところだと思います。問題数が250問から100問になり、時間も6時間から3時間に短縮されるようです。難易度はおそらく上がるのではないかと思います。現行の250問の試験では、各ドメインの出題比率が決まっているので、苦手なドメインを得意なドメインである程度カバーできますが、CAT方式だと、おそらく最初に採点に関係ない苦手なドメインを見極めるための問題が出題されて、その後苦手なドメインの問題が重点的に出題されるような形式になるのではないかと思います。これから受験される方は、苦手なドメインがなくなるよう、より満遍なく学習するようにがんばってください。

皆既月食 2018/1/31

Sun, 11 Feb 2018 22:37:26 +0900

2018/1/31は久しぶりの皆既月食でした。前回は2015/4/4でしたがこれは曇って見えなかったので、2014/10/8以来約3年3ヶ月ぶりでした。日食と比べて月食は見る機会が多いですが、それでも条件よく見られるのはせいぜい2,3年に1度なので貴重な機会です。今回は天気が全国的に微妙で半分諦めていましたが、関東地方は皆既月食の前後だけ晴れるという奇跡のような天気に恵まれ、堪能することができました。写真もきれいに撮れて非常に満足しました。

地球の影がわかるように写真を合成してみました。地球の直径は月のだいたい4倍ということがわかります。

3日前の時点で天気予報は曇時々晴で、きれいに見えるのはかなり厳しいかなと思っていました。

しかし、当日になると1時間予報で皆既月食がピークになる22時～23時は晴の予報になっていました。結果的にまさにこの通りになったので、weather.com(iPhoneの天気予報)恐るべし。最近の天気予報はほんとよく当たりますね。

月の出の時点ではまだ薄雲がかかっていて月はぼんやりとしか見えませんでした。

でも予報どおり徐々に雲が薄くなってきたので諦めず最強装備で出撃です。いつもの自宅マンションの通路から狙いました。

装備は以下のような感じで、月を撮影するにはかなりのハイスペックです。

鏡筒: Celestron Edge HD800 2032mm, f/10
赤道儀: Sky-Watcher EQ5GOTO
カメラ： SONY α7S

19:25ごろです。月が高くなってくると、かなり雲が薄くなり、満月がはっきり見えるようになりました。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO100, 1/160s

20:47ごろです。月が欠け始めました。この頃には雲はほぼ晴れていました。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO100, 1/200s

21:18ごろです。半分ほど欠けました。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO200, 1/160s

21:39ごろです。月の欠け際に見える青い帯をターコイズフリンジと言います。地球のオゾン層を通った光でこのように見えるそうです。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO800, 4s, ステライメージ8でトーンカーブ調整等。

22:03ごろです。皆既月食になりました。α7Sの絵画調HDRモードで撮影したらとても階調豊かに写りました。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO800, 2s, 絵画調HDRモードLowで撮影

22:29ごろです。食の最大です。この頃には天気は快晴になっていました。完璧な皆既月食を堪能することができました。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO800, 4s

これもα7Sの絵画調HDRモードで撮影しました。暗い部分は赤黒く、明るい部分は青っぽく、階調豊かに写りました。α7Sは皆既月食の撮影に相当適性があるように思います。

Celestron Edge HD800, SONY α7S, 2032mm, f/10, ISO800, 2s, 絵画調HDRモードLowで撮影, ステライメージ8でトーンカーブ調整等。

23:13ごろです。皆既後のターコイズフリンジがよく写ってます。

サブカメラのNEX-5Rで、広角レンズで2分おきくらいにタイムラプスっぽく撮影してみました。最後は少し曇りましたが、ほぼ全行程きれいに見えました。

SIGMA 19mm F2.8 DN Art, SONY NEX-5R, Siriuscompで合成

皆既月食の後に光輪が現れました。換算28mmで画面いっぱいなのでかなり大きいです。月暈（つきがさ・げつうん）と言うそうで、満月と薄雲の条件が揃ったときに現れるそこそこレアな事象のようです。この日は何かと奇跡的でした。

SIGMA 19mm F2.8 DN Art, SONY NEX-5R, 19mm, f/2.8, ISO1600, 1s, GIMPでトーンカーブ調整等。

2011年のときと2014年のときとの比較です。2011年はカシオのコンデジ（EX-FH20）でふつうのカメラ三脚で撮影しました。当時はこれでも感動したものです。2014年は装備の本気度が上がって、Vixen A80MとSONY NEX-5Rで撮影しました。まだ赤道儀を持ってなかったのでポルタII経緯台で追尾しながら撮影するのはなかなか大変でした。今回の装備は月を撮影するにはちょっと過剰すぎるくらいなのでとても快適に撮影できました。天体写真という奴は、投資額が結果に如実に表れやすいです。故に沼にハマりやすいとも言えます。私はかなり沼にどっぷりです。

というわけで、条件の良い皆既月食を存分に堪能できて非常に満足できました。次の皆既月食は2018/7/28ですが、これは日本では夜明け前で月入帯食となり、あまり条件が良くありません。今回ほど条件の良い皆既月食は2022/11/8まで待たないといけないようです。

ソニー SONY フルサイズミラーレス一眼 α7S ボディ ILCE-7S

メディア: Camera

ソニー SONY フルサイズミラーレス一眼 α7SM2 ボディ ILCE-7SM2

メディア: Camera

【国内正規品】 CELESTRON 天体望遠鏡 EdgeHD 800 CG-5 鏡筒 CE91031-XLT

メディア: Camera

Sky-Watcher EQ5 GOTO赤道儀（ステンレス三脚仕様）

メディア: エレクトロニクス

Build GCC 7 on Solaris 11.3

Tue, 03 Oct 2017 19:25:41 +0900

GCCが7まで出てることにちょっと驚愕しつつ、なんとなくSolarisでコンパイルしてみたメモです。 Solarisを使っているとコンパイルが趣味になりがちです。

GCC, the GNU Compiler Collection - GNU Project - Free Software Foundation (FSF)

環境

$ uname -a
SunOS mercury 5.11 11.3 i86pc i386 i86pc Solaris

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/lto-wrapper
Target: i386-pc-solaris2.11
Configured with: /builds/hudson/workspace/nightly-update/build/i386/components/gcc45/gcc-4.5.2/configure CC=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/cc CXX=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/CC --prefix=/usr/gcc/4.5 --mandir=/usr/gcc/4.5/share/man --bindir=/usr/gcc/4.5/bin --libdir=/usr/gcc/4.5/lib --sbindir=/usr/gcc/4.5/sbin --infodir=/usr/gcc/4.5/share/info --libexecdir=/usr/gcc/4.5/lib --enable-languages=c,c++,fortran,objc --enable-shared --with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CFLAGS='-g -O2 '
Thread model: posix
gcc version 4.5.2 (GCC)

ダウンロード・展開

$ wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-7.2.0/gcc-7.2.0.tar.xz
...
$ tar Jxvf gcc-7.2.0.tar.xz
...
$ cd gcc-7.2.0
...

依存ライブラリ(gmp, mpfr, mpc, isl)のダウンロード

$ contrib/download_prerequisites
...

configure

$ ./configure \
  --prefix=/opt/gcc7 \
  --enable-languages=c,c++ \
  --enable-shared \
  --disable-bootstrap \
  --without-gnu-ld --with-ld=/usr/bin/ld \
  --with-gnu-as --with-as=/usr/gnu/bin/as \
  CC='gcc -m64' CXX='g++ -m64'

オプションはあんまりちゃんと吟味してませんが、なんとなくOS付属のgccを参考にしました。

make

$ gmake -j8
...
$ sudo gmake install
...

/opt/gcc7 配下にインストールされます。

$ /opt/gcc7/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc7/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc7/libexec/gcc/x86_64-pc-solaris2.11/7.2.0/lto-wrapper
Target: x86_64-pc-solaris2.11
Configured with: ./configure --prefix=/opt/gcc7 --enable-languages=c,c++ --enable-shared --disable-bootstrap --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CC='gcc -m64' CXX='g++ -m64'
Thread model: posix
gcc version 7.2.0 (GCC)

戦場ヶ原で星を見てきました

Sun, 24 Sep 2017 14:22:27 +0900

9月の3連休は、台風18号の列島縦断で大荒れでしたが、転んでもただでは起きない精神で、台風一過の晴れ間を逃さず9/18の夜に天体観測しに行くことにしました。月齢的にも9/20が新月なのでちょうどいい時期です。場所は、栃木県奥日光の戦場ヶ原にしました。戦場ヶ原は関東屈指の星空スポットとして有名なのでそのうち行きたいと思っていました。

www.tochigiji.or.jp

戦場ヶ原へは浦安から車でちょうど3時間くらいかかりました。公共交通機関もあるにはありますが、機材の運搬もあり、車内で仮眠することも考えると車の方が便利かなと思います。

天体観測スポットとして有名な、戦場ヶ原の三本松駐車場に着くと、すでに天体観測目当ての方々がたくさんいて、口径40cmくらいの巨大なSky-Watcherのドブソニアンや、タカハシの赤道儀と鏡筒など気合いの入った機材を展開している方もいました。私も赤道儀を持ってきたのでそれなりに重装備ですが、世の中上には上がいるものです。

三本松駐車場では三本松茶屋がほぼ唯一の補給スポットになります。夜は18:30ラストオーダーで、19:00閉店と早めなので、明るいうちに到着して夕食を取り、機材を準備するのがよいと思います。トイレは24時間利用可能で、自動販売機もあるので、天体観測スポットとしてはかなり充実していると思います。

sanbonmatsu.moon.bindcloud.jp

天気は予報どおり快晴でした。台風は困りものですが、台風一過の晴れ間は見逃せません。写真左下の山は男体山です。戦場ヶ原はこの男体山の噴火でできたそうです。

標高1400mなので気温はかなり低いです。概ね東京より10度～20度くらい低いようです。その日は東京では30度を超える真夏日でしたが、戦場ヶ原では最高気温20度くらいで、最低気温は10度以下まで下がりました。真冬用の防寒着を持っていってちょうどよかったです。まだ真夏日の初秋でこれなので、冬だと雪山用の装備とかが必要だと思います。

日が沈むとすぐに辺りは暗くなり、19時台には肉眼で天の川が見えました。さすが評判どおりの暗さです。ただし、三本松駐車場は有名スポットだけあって、暗くなってからもヘッドライトを点けた車がひっきりなしに出入りしていました。望遠鏡を空に向けているぶんには大きな影響はありませんが、広角レンズで星景写真とかを撮るには駐車場から離れる必要がありそうです。

戦場ヶ原の天の川。夜7時台から天の川が肉眼で見える暗さでした。 Samyang 14mm f/2.8, SONY α7S, ISO6400, 30s x16, 総露出時間 8分, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

夏の大三角と天の川。拡大すると迫力あります。 SONY SEL28F20, SONY α7S, 28mm, f/2.0, ISO6400, 30s x10, 総露出時間 5分, Sky-Watcher EQ5GOTOで追尾, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

NGC7000 The North America Nebula. はくちょう座のデネブの近くにある北アメリカ星雲。たしかにこれは北アメリカ。思っていたより大きく、フルサイズの画角でいっぱいに写りました。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, 総露出時間 5分, Sky-Watcher EQ5GOTOで追尾, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

M16 The Eagle Nebula and M17 The Omega Nebula. わし星雲とオメガ星雲。夏の代表的な天体ですね。ノーマルカメラだとちょっと色が出づらい対象です。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, 総露出時間 5分, Sky-Watcher EQ5GOTOで追尾, Lightroomで現像, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

NGC869/884 Double Cluster. ペルセウス座の二重星団。秋の代表的な天体の一つです。宝石箱のような美しさです。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, ISO25600 30s x10, 総露出時間 10分, Sky-Watcher EQ5GOTOで追尾, ステライメージ8でスタック、トーンカーブ調整等。

NGC7293 The Helix Nebula. らせん星雲。M57 環状星雲と似ていますがこっちの方が大きいです。そのぶん淡いので都会ではほぼ見えません。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, ISO25600 30s x10, 総露出時間 10分, Sky-Watcher EQ5GOTOで追尾, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

M51 Question Mark Galaxy. おもしろい形をした子持ち銀河。400mmではかなり小さいですが形はよく分かります。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, 総露出時間 5分, Sky-Watcher EQ5GOTOで追尾, Lightroomで現像, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

M33 Triangulum Galaxy. さんかく座の銀河。銀河の腕がよく写っています。大きな銀河ですが淡いのでこれも都会ではほぼ見えません。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, ISO25600 30s x10, 総露出時間 10分, Sky-Watcher EQ5GOTOで追尾, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

M31 Andromeda Galaxy. 秋の天体の代表格、アンドロメダ銀河。文句なくきれいに写ります。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO6400 30s x10, ISO12800 30s x10, ISO25600 30s x10, 総露出時間 15分, Sky-Watcher EQ5GOTOで追尾, Lightroomで現像, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

M45 Pleiades. 夜が更けると東の空に見えてくるすばる。都会でもそれなりに写りますが戦場ヶ原だと青い星雲がはっきりと写ります。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO12800 30s x10, 総露出時間 5分, Sky-Watcher EQ5GOTOで追尾, Lightroomで現像, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

M42 Great Orion Nebula. 冬の天体の代表格、オリオン星雲。夜更けには冬の天体を先取りできる季節です。これも都会でもそれなりに写りますが、はるかにきれいに写ります。 BORG 71FL, 7108フラットナー, SONY α7S, 432mm, f/6.1, ISO6400 x10, ISO12800 30s x8, 総露出時間 9分, Sky-Watcher EQ5GOTOで追尾, Lightroomで現像, ステライメージ8でスタック・トーンカーブ調整等, GIMPで微調整。

夜半過ぎには少し曇りましたが、概ね快晴ですばらしい星空を堪能することができました。戦場ヶ原よかったです。冬は寒さが厳しそうなので、また暑めの季節に訪れてみたいものです。

Solaris de USB温度計

Fri, 01 Sep 2017 19:17:53 +0900

自宅サーバを運用していると、家の温度を測ってグラフ化したくなるというニーズはそれなりにあるようで、多くのブログ記事等がヒットします。情報を集めてみると、PCsensor社のTEMPerというシリーズのUSB温度計が、1000円くらいから入手できてよく使われているようです。

USB温度計! USB thermometer-528018

出版社/メーカー: OEM
メディア: エレクトロニクス
購入: 5人クリック: 48回
この商品を含むブログ (2件) を見る

pcsensor.com

安いのでとりあえずAmazonで購入してみました。私が購入したのは Gold TEMPer という製品のようです。中国語混じりのちょっと怪しげなパッケージです。ドライバCDが付いていますが、Windows用のソフトウェアしかないので無視することにします。

検索すると、ラズパイやLinuxサーバでの動作成功例が見つけられましたが、私の家の自宅サーバはSolarisなので、当然Solarisでやってみたくなります。

USBポートに挿してみて、cfgadmで見てみたところ、TEMPerV1.4 としてOSには正しく認識されているようです。これはいけそうな気がしてきました。

$ cfgadm -v
Ap_Id                          Receptacle   Occupant     Condition  Information
When         Type         Busy     Phys_Id
...
usb2/1.6                       connected    configured   ok         Mfg: RDing  Product: TEMPerV1.4  NConfigs: 1  Config: 0  <no cfg str descr>
unavailable  usb-device   n        /devices/pci@0,0/pci8086,2036@1d/hub@1:1.6
...

prtconfで見ると、VendorID:0c45, ProductID:7401 のデバイスであることがわかります。

$ prtconf -v
System Configuration:  Oracle Corporation  i86pc
Memory size: 8106 Megabytes
System Peripherals (Software Nodes):

...
                        name='usb-product-name' type=string items=1
                            value='TEMPerV1.4'
                        name='usb-vendor-name' type=string items=1
                            value='RDing'
...
                        name='usb-product-id' type=int items=1
                            value=00007401
                        name='usb-vendor-id' type=int items=1
                            value=00000c45
...

メーカーサイトではWindows用のソフトウェアしか公開されていないようですが、USBプロトコルアナライザで解析して作られたと思われるLinux用のドライバを作っている方がいました。

https://relavak.wordpress.com/2009/10/17/temper-temperature-sensor-linux-driver/

このブログのレスの中にある pcsensor-0.0.1 は、 0c45:7401 のデバイスに対応しているようなので、試してみることにしました。Linux用ですが、カーネルモジュールではなく、ユーザモードで動作するlibusbというライブラリを使って作られているので、Linuxでなくても動作すると期待できます。実際、FreeBSDでの動作成功例も見つけることができました。

ymlab.hatenablog.com

Solarisでとりあえずmakeしてみましたが、だめでした。

$ tar zxvf pcsensor-0.0.1.tar.gz
$ cd pcsensor-0.0.1
$ CC=gcc make
gcc -DUNIT_TEST -o pcsensor pcsensor.c -lusb
pcsensor.c: In function 'interrupt_read':
pcsensor.c:235:5: warning: incompatible implicit declaration of built-in function 'bzero'
pcsensor.c: In function 'interrupt_read_temperatura':
pcsensor.c:254:5: warning: incompatible implicit declaration of built-in function 'bzero'
Undefined                       first referenced
 symbol                             in file
usb_detach_kernel_driver_np         /var/tmp//ccUZxvwd.o
ld: fatal: symbol referencing errors
collect2: ld returned 1 exit status
make: *** [pcsensor] Error 1

libusbのドキュメントを見たところ、usb_detach_kernel_driver_np はLinux専用の関数のようなので、コメントアウトしてみたところ、makeは通るようになりました。

http://www.electric-spoon.com/doc/libusb-dev/html/function.usbdetachkerneldrivernp.html

$ diff pcsensor.c.orig pcsensor.c
77c77
<       ret = usb_detach_kernel_driver_np(lvr_winusb, iInterface);
---
>       ret = 1; //usb_detach_kernel_driver_np(lvr_winusb, iInterface);

実行してみたところ、デバイスを見つけてはいるようなのですが、claimのところでうまくいってないようでした。（後述のmodunloadしてもだめでした）

$ sudo ./pcsensor -v
...
lvr_winusb with Vendor Id: c45 and Product Id: 7401 found.
usb_open: device ptr is 0x8065f68
usb_open: pindex = 0
Detach failed: Error 0[0]
Continuing anyway
Detach failed: Error 0[0]
Continuing anyway
Could not claim interface

libusbのバージョンには0.1系と1.0系があり、このドライバは0.1系を使っていました。libusb-1.0のドキュメントを見ると、Solarisを正式サポートしているようなので、1.0系に対応すれば動作するかもしれないと思いました。

github.com

Linux用のドライバ（pcsensorまたはtemper）は派生版がたくさんあるようでしたが、libusb-1.0に対応しているものは見つけられなかったので、対応する意味はそれなりにありそうです。

libusb-0.1系と1.0系ではAPIが異なっており、互換性がありません。とはいえ、関数名はだいたい先頭を usb から libusb に置き換えたものが同等の機能のようなので、ドキュメントを眺めつつなんとなく似た名前の関数に置き換えていきました。libusbの使い方がちょっとだけわかったような気がします。

丸1日ほど格闘した結果、なんとなく動くようになったのでGithubに上げました。

github.com

Solaris 11 と RHEL 6（CentOS 6）で正常に動作することを確認しています。いくつかの派生版で、複数デバイスに対応する機能追加が行われていたので、それも取り込んでいます。

Solaris 11 だと↓のような感じでビルドできます。事前にgccとlibusb-1を入れておいてください。

$ sudo pkg install gcc libusb-1
...
$ git clone https://github.com/shakemid/pcsensor-temper
$ cd pcsensor-temper
$ make
...
$ sudo ./pcsensor.sh
...

複数デバイスがある場合は、↓のような感じで列挙されます。1つのデバイスに2つのセンサが付いているものにも対応していますが、私のものは2つ目のセンサ（external）はないので異常な値になっています。

$ sudo ./pcsensor
2017/08/31 19:00:35
Temperature (0:internal) 81.28F 27.38C
Temperature (0:external) 214.60F 101.45C
2017/08/31 19:00:35
Temperature (1:internal) 81.16F 27.31C
Temperature (1:external) 214.60F 101.45C
...

また、Muninでグラフ化できるようにプラグインも作ってみました。Githubの同じリポジトリの中に置いてあります。

github.com

MuninのRRDにはキャリブレーションしていない生の値を記録し、CDEF機能で補正するような作りにしてあります。補正した値をRRDに格納してもよいですが、CDEF機能を使うと、後でキャリブレーションをやり直しても以前に取得した値も補正できる利点があります。 CDEF機能はとっつきづらいですが、逆ポーランド記法(RPN)でRRDに格納された値に様々な計算を加えることができるRRDtoolの機能で、いろいろと応用が利きます。

RRDtool - rrdgraph_rpn

上記のプラグインの場合は、たとえば↓のように env.cdef オプションで比率とオフセット値を設定できるようになっています。

/path/to/munin/etc/plugin-conf.d/temper
----
[temper]
    user root
    env.pcsensor /usr/local/bin/pcsensor
    env.cdef  temperature,1.0287,*,0.85,-

TEMPerのキャリブレーションについては↓の記事がわかりやすいと思います。

www.okahiro.info

Muninでグラフ化すると↓のような感じになります。さすがに8月の室内は30度を超えて暑いですね。

詳細は不明なのですが、どうも16回データを取得すると、17回目にデータを取得できなくなるような事象に遭遇しました。

$ sudo pcsensor
2017/09/01 19:14:57
Temperature (0:internal) 89.60F 32.00C
Temperature (0:external) 214.60F 101.45C

16回繰り返す

$ sudo pcsensor
USB read failed: 0
USB interrupt read: File descriptor in bad state
Fatal error> USB read failed

↓で議論されているのと同じ事象のように見えますが、どうも解決していないようです。 github.com

Linuxだと、もう一度実行すると温度を取得できるようなのですが、Solarisだと何度実行しても取得できないままでした。この状態のときは、何かがUSBデバイスをロックしているように見えたので、HIDドライバをmodunloadしてみたところ、温度を取得できるようになりました。

$ sudo cat /dev/usb/c45.7401/0/if0in1
cat: /dev/usb/c45.7401/0/if0in1: Device busy

$ modinfo | grep hid
168 fffffffff7e5d000   5858  20   1  hid (USB HID Client Driver)
...

$ sudo modunload -i 168
...

これはちょっとあんまりな気がするのでもっといい方法があるとよいのですが、今のところ他に方法を見つけられていないので、HIDドライバをmodunloadしてpcsensorコマンドを実行するラッパをpcsensor.shとして公開しています。

というわけで、SolarisでもUSB温度計を使用できるようになりました。めでたしめでたし。

2017/9/14追記

↓のPerlモジュールがSolarisでも動作しました。

Device::USB::TEMPer1F - search.cpan.org

cpanに登録されているのでcpanmでインストールできます。

$ sudo cpanm -v Device::USB::TEMPer1F
...

↓のようなサンプルスクリプトで温度を取得できました。

#!/usr/bin/perl

use strict;
use warnings;

use Device::USB::TEMPer1F;

my $temper = Device::USB::TEMPer1F->new or die $@;
print $temper->fetch, "\n";

動作はしたのですが、どうもfetchメソッドでexternalのセンサーの値を読んでいるようなので、internalのセンサーの値を読むように変更しました。これは作者にフィードバックしておこうと思います。

--- TEMPer1F.pm.orig    2017-09-14 10:21:37.907791130 +0900
+++ TEMPer1F.pm 2017-09-14 10:21:48.015163258 +0900
@@ -79,7 +79,7 @@
     ) || die "Cannot read the the temperature!\n";

     my $r = [unpack "C8", $self->{buffer}];
-    return sprintf "%0.2f", $r->[4] + $r->[5]/256;
+    return sprintf "%0.2f", $r->[2] + $r->[3]/256;
 }

 ############################ private methods ##############################

実行例
$ sudo perl temper.pl
33.69

このモジュールだと16回以上取得してもエラーにならないようです。しかし、最初にmodunloadする必要はあるようでした。上記のCプログラムも、このPerlモジュールに倣って、不要そうなini_control_transferのあたりを削除したらエラーが出なくなりました。

ずいぶんシンプルになりました。今までの苦労はいったい。でもだいぶ勉強になった気がしました。

2017/9/28追記

eBayで、センサーが2つ付いたTEMPer2と、湿度計が付いたTEMPerHUMも買って対応してみました。なんだかTEMPer工場みたいになってしまいました。はじめは部屋の温度を記録したかっただけなのにすっかり手段と目的が入れ替わってます。 USBハブに直接挿すと熱が伝わってしまうので、100円ショップのUSB延長ケーブルを使っています。

eBayで買うとだいたい10日～2週間くらいで届きました。ちょっと納期はかかりますが値段は日本のAmazonで買うより安めです。 stores.ebay.com

ソースコードはGithubで公開しています。 github.com

温度と湿度の計算式はこちらをだいぶ参考にしました。 github.com

かなり車輪の再発明感はありますが、より簡単にビルドできて、Solarisでも動きます。Solarisでも動きます。（大事なことなので2回言いました）

2017/8/21 北米皆既日食を見てきました

Thu, 24 Aug 2017 14:03:17 +0900

今世紀最高の条件（観測地へのアクセスのしやすさ、晴れやすさなど）と言われた、北米皆既日食を見てきました。皆既日食帯のほぼ中心に位置するオレゴン州ライオンズ(Lyons)という小さな町で、雲一つない快晴に恵まれ、パーフェクトな条件で観測することができました。皆既日食を見るのはこれが初めてで、超感動しました。本当に行ってよかったです。

皆既日食中のコロナを多段階で合成。 BORG 71FL, 7215 x1.4, SONY α7S, 560mm, f/7.9, ISO100, 1/1000+1/250+1/60+1/15+1/4s, RAW5枚合成, ステライメージ8でローテーショナルグラディエント, トーンカーブ調整, アンシャープマスク等。

双眼鏡で眼視したイメージを思い出して再現してみました。プロミネンスから外部コロナまで全部見えていて、空は青く見えました。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 1/1000+1/250+1/60+1/15+1/4+1+4s, RAW7枚合成, ステライメージ8でローテーショナルグラディエント, トーンカーブ調整, アンシャープマスク等。

コロナがよく見えるように調整してみました。フルサイズの画角からはみ出るくらいコロナが広がっています。調整の仕方で印象がずいぶん異なりますね。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 1/1000+1/250+1/60+1/15+1/4+1+4s 各2～3枚、合計RAW19枚合成, ステライメージ8でスタック、ローテーショナルグラディエント, トーンカーブ調整, アンシャープマスク等。

皆既日食中のコロナ。1枚だと内部コロナが白く飛んでしまいます。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 1/4s, RAW1枚, GIMPでAPS-C相当にトリミング, トーンカーブ調整, アンシャープマスク等。

ダイヤモンドリング。コロナやプロミネンスも見え始めています。 BORG 7215のおかげで、ゴーストはかなり少なめだと思います。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 1/60s, RAW1枚, GIMPでAPS-C相当にトリミング, トーンカーブ調整, アンシャープマスク等。

長く露出するとコロナがフルサイズからはみ出るくらいに広がっているのが写りました。地球照に照らされた月面の模様も見えてきました。太陽がたしかに月に隠されているのがよく分かります。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 4s, RAW1枚, GIMPでトーンカーブ調整, アンシャープマスク等。

ベイリービーズ。皆既の直前です。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 1/8000s, GIMPで調整。

プロミネンス。α7Sだとちょっと解像度が足りない感じですが、炎のような感じで写りました。 BORG 71FL, 7215 x1.4, SONY α7S, ISO100, 1/1000s x6枚, ステライメージ8でスタック, 調整, GIMPで微調整。

撮影機材

撮影機材は機動性重視で、ミニボーグを中心に構成しました。旅の荷物の総重量は20kgほどで、追加費用なしで余裕で飛行機に乗れる重さでした。レンズをばらして機内持ち込みにできるのも組み立て式のBORGのいいところです。

望遠鏡
- TOMYTEC ミニボーグ71FL対物レンズ（BK）【2572】
- TOMYTEC M57ヘリコイドLIII【7861】
- TOMYTEC M57ヘリコイドDXII【7761】
- TOMYTEC ミニボーグ鏡筒DX-LD【6015】
- TOMYTEC M57/60延長筒S【7602】
- TOMYTEC 1.4×テレコンバーターGR【7215】
- TOMYTEC カメラマウントホルダーM【7000】
- TOMYTEC M49.8延長筒S【7921】
- TOMYTEC M49.8延長筒M【7922】
- TOMYTEC カメラマウントソニーNEX用（Eマウント）【5013】
- MARUMI ステップダウンリング 72mm → 49mm（部分日食中のみ）
- Kenko PRO ND1000+ND100 (ND100000相当) 49mm（部分日食中のみ）
カメラ
- SONY α7S
- SONY NEX-5R（予備）
- ROWA-JAPAN タイマーレリーズ
赤道儀
- Vixen ポータブル赤道儀星空雲台ポラリエ
- Vixen ポーラメーター
- TOMYTEC 片持ちフォーク式赤道儀【3101】
- TOMYTEC アルカクランプボーグ用【3110】
- TOMYTEC アングルプレート35VP（ブラック）【3235】
- USBリチウムイオン電池（何かのノベルティグッズ）
三脚
- SLIK AMT 340HD
- SIRUI L-20S 雲台
- SLIK ストーンバッグDX
双眼鏡
- TO-PLAN Solar Opera 3倍
- Carl Zeiss Terra ED 42x8 （もちろん皆既中のみ）

71FL+レデューサー7872セット 6472

メディア: エレクトロニクス

ソニー SONY フルサイズミラーレス一眼 α7S ボディ ILCE-7S

メディア: Camera

Vixen ポータブル赤道儀星空雲台ポラリエ(WT) ホワイト 355051

発売日: 2011/11/30
メディア: エレクトロニクス

旅行記

半年前

皆既日食は一生のうちには見たいと思っていましたが、行くかどうか迷っていました。北米でアクセスしやすいとはいえ、皆既日食帯に入るのは比較的田舎の州がほとんどで、半年前の時点ですでに皆既日食帯内のホテルはほとんど満室で、公共交通機関も混雑であまり期待できない状態でした。皆既日食帯に入るには、少し離れたところに宿泊し、レンタカーで移動するのがほぼ必須という状況だったので、海外で運転したことがなく、日本でもあまり運転しない私は困ってしまいました。そんな中、1月にアメリカ居住経験がある友人の1人がポートランド近辺で日食を見に行くというのを聞き、それが後押しになって、私も行くことを決めました。ポートランドはけん玉プレイヤーの友達も多く、いざとなったら頼れるのも理由の1つでした。 3年くらい車を運転しておらず、運転に自信がなかったので日本で何回かレンタカーを借りて練習しました。国際免許も初めて取得しました。国際免許は免許センターに行って2000円払えば誰でももらえます。

撮影機材は天体観測遠征用のものをある程度持っていたのでそれらを使うことにしました。望遠鏡は、そのときに持っていたBORG 45EDIIでも充分に撮影できますが、せっかく海外まで遠征するので新しいものがほしくなり、BORG 71FLを購入しました。

2017/8/17

羽田からロサンゼルスを経由して、ポートランドに入りました。空港近くのAlamoレンタカーでまずレンタカーを借りました。営業所は空港から少し離れていて、数分おきにシャトルバスが運行されています。営業所につくと、予約を確認し、わりとすぐに車に案内されました。日本車がいいと思って日産の車を予約していたのですが、同等の車ということで現代が出てきてちょっとがっかりしました。これはもうしょうがないです。設備をチェックすると、GPSナビを予約していたはずが付いていませんでした。スタッフに確認すると、在庫がなくて、別の営業所に取りに行かなければならないけどキャンセルするか？というようなことを聞かれました。さすがにナビは必要と思ったので待つことにしました。20分くらいして持ってきてくれたのですが、電源コードの接触が悪く、すぐに電源が切れてしまう状態だったので、交換してもらいました。しかし今度は取付の部品が合わず、車に取り付けられませんでした。もう1度交換してもらい、ようやく使えるようになりました。さすがアメリカという感じでかなり適当なので、出発前によく確認した方がよいと思いました。今回は不安だったのでGPSナビを借りましたが、今ならiPhoneアプリと車載ホルダーでも充分かもしれません。

心配だった運転はそれほどでもなく、なんとか大丈夫でした。交通ルールを事前に予習しておいたのと、日本で運転の練習をしておいたのがよかったです。日本との最大の違いは右側通行なので、常に意識しておいた方がよいです。日本と逆で右折は簡単ですが、左折はちょっと怖いです。油断すると逆車線に入りそうになるので、左折時は特に意識が必要です。左ハンドルはあまり気になりませんでしたが、ワイパーとウインカーが左右逆なのは慣れるまで数日を要しました。最初の2日くらいは10回くらいワイパーを動かしてしまいました。

abroad.driver.jp

空港から1時間弱ほど運転してホテルに到着しました。ホテルはポートランドのダウンタウンから少し南に行ったところにある↓のホテルにしました。

www.booking.com

半年前の時点で空き部屋が残り少なく、ちょっといい部屋しか空いてませんでした。やたら広く、キングサイズのベッドがある部屋でした。ベッドに枕が5個置かれていて、何に使うのかよく分かりませんでした。

2017/8/18

18日は観測地の下見に行きました。皆既日食当日の朝はポートランドから南に向かう道は大渋滞することが予想されていたので、前日の内にセイラム（Salem）まで移動して車中泊し、さらに南東に向かって皆既日食帯のほぼ中心で観測する計画を立てました。 Googleマップで調べたところ、セイラムから南東に向かうと、ライオンズ（Lyons）という小さな町があり、小学校があったのでそこをめざしてみることにしました。

ポートランドからセイラムまでは車で1時間弱くらいでした。セイラムはオレゴン州の州都なので、それなりに店などが多く、駐車場で車中泊ができる程度に平和なようでした。比較的アクセスしやすい場所に24時間営業のデニーズがあったので、そこを前泊場所の候補にしました。セイラムからさらに南東に車で30分くらい走ると、ライオンズに着きました。小学校には芝生の大きなグラウンドがあり、観測に適していそうでした。今は夏休みなので児童はほとんどいませんでしたが、職員の方はいたので、話をしてみたところ、少人数だったらグラウンドで観測してもよいと快く承諾してくれました。トイレも借りることができました。ひとまず練習で太陽を撮影してみました。

夜はオレゴン州の最高峰、フッド山（Mt. Hood）の方面に走り、天体観測してみることにしました。山に向かって走ると、トイレがある簡易休憩所のようなところがあったので、そこで夜になるのを待ちました。オレゴンは緯度が北緯45度程度と、北海道よりやや北なので今の季節は日照時間が長く、夜8時を過ぎてもまだ少し明るいくらいでした。夜9時を過ぎてくると星が見えてきて、天の川も見えました。しかしこの日は部分的に曇りですっきりと晴れませんでした。なんとか天の川は撮影できましたが、雲が晴れそうになかったので日が変わらないうちにさっさと退散しました。

2017/8/19

19日は、朝食のために朝8時くらいに起きましたが、前日の200km以上の運転と、時差ボケでそのあと午後2時くらいまで寝てしまいました。午後2時は日本時間で朝の6時なので、だいたい日本時間に近い感じで生活することになり、結果的に時差ボケはそれほどなかったような気がします。

午後からゆっくりとローズガーデンに観光に行きました。バラの花と、森の中のトレッキングを楽しむことができました。自然を楽しめるのはオレゴンのいいところです。

夜は星がきれいに見えそうな、マウントフッドビレッジというところを目指してみました。明るい内に到着したかったのですが、時間を読み間違えて夜9時過ぎに到着してしまい、車のライト以外ほとんど真っ暗な状況で、ロケハンに難航しました。携帯の電波も入ったり入らなかったりで、Googleマップも当てになりません。

www.tripadvisor.jp

たまたま広場のような場所を見つけて入ってみたところ、素晴らしい星空で、天の川がはっきりと見えました。この日は雲もほとんどなく快晴で、天体観測にはパーフェクトでした。後から調べてみるとここはゴルフ場だったようです。

満天の星空と天の川。Samyang 14mm f/2.8, SONY α7S, ISO6400, 30s, RAW1枚, iPhone版LightRoomとInstagramで編集。

上の写真を再処理しました。Samyang 14mm f/2.8, SONY α7S, ISO6400, 30s x20枚, LightRoomで現像, ステライメージ8でスタック, GIMPで微調整。

M31アンドロメダ銀河。BORG 71FL, SONY α7S, ISO6400, 60s, RAW1枚, iPhone版LightRoomとInstagramで編集。

上の写真を再処理しました。BORG 71FL, SONY α7S, ISO6400 30s x10枚, ISO12800 30s x10枚, LightRoomで現像, ステライメージ8でスタック, GIMPで微調整。

立ち上るような天の川。地平線近くまで夕焼けのように赤く写りました。 Contax Carl Zeiss Distagon 35mm f/2.8, SONY α7S, ISO6400, 30s x10枚, LightRoomで現像, ステライメージ8でスタック, GIMPで微調整。

夏の大三角と天の川。35mmレンズの画角は天の川の幅と合っててよいです。 Contax Carl Zeiss Distagon 35mm f/2.8, SONY α7S, ISO6400, 30s x10枚, LightRoomで現像, ステライメージ8でスタック, GIMPで微調整。

M27亜鈴状星雲。小さめですがよい発色で写っていると思います。α7SのISO12800はちょい撮りには充分常用できるほどノイズが少ないと思います。 BORG 71FL, SONY α7S, ISO12800 30s x10枚, LightRoomで現像, ステライメージ8でスタック, GIMPで微調整。

2017/8/20

20日も昼過ぎまで寝て、午後にゆっくりマルトノマ滝を見に行きました。道路が混みすぎていて駐車場までたどり着けませんでしたが、なんとか路上駐車することができました。マルトノマ滝は落差約180mの見事な滝でした。

夜はいよいよ皆既日食の観測地への移動です。夜の時点ではまだ道路はそれほど混んでいませんでした。無事にセイラムにあるデニーズの駐車場に停車することができました。夕食もそれほど待たずに食べることができました。しかし、あれよあれよという間に満席になり、駐車場も満車になりました。やはり、前泊しようとしている人が多かったようです。早めの行動が功を奏しました。

2017/8/21

朝5時頃にセイラムを出発し、日の出前にライオンズに到着することができました。セイラムから東の方向に行く人は少ないと読んでいたとおり、道路はそれほど混んでいませんでした。日の出前から天気は快晴で、パーフェクトな条件での観測が期待できました。

場所を確保して機材を準備していると、徐々にグラウンドに人が集まってきました。それでも最終的にだいたい30人くらいで、のんびりと落ち着いて観測できました。

太陽が昇り始めたらさっそく望遠鏡を太陽に向け、赤道儀で追尾を開始しました。ノートラブルで好調でした。

日食が始まる直前に、↓のような感じの緊急警報が携帯に送信されてきました。地震でも起きたのかと思ってちょっと驚きましたが、太陽を直接見ないようにとの注意喚起でした。日本だと地震くらいでしか見たことがないですが、こんな使い方もあるのですね。

注意喚起をしても、日食がある度に残念ながら失明する人が出るそうです。なんせ大統領が裸眼で見てしまうくらいですからね。本当に危険なのでダメ絶対です。

www.bbc.com

午前9時過ぎから太陽が欠けはじめました。太陽が半分以上欠けてくると、気温が体感できるレベルで下がり、少し肌寒いくらいでした。また、だんだんと暗くなっているのがわかりました。夕方や、曇りのときとは明らかに違う暗さで、日食独特の雰囲気でした。

部分日食中はタイマーレリーズで自動撮影していたので、太陽双眼鏡で眺めたり、ふつうの双眼鏡で↓のような感じで投影して遊んだりしていました。

皆既の時間が近づいてくると、いよいよ気分が高まってきました。皆既日食が継続している時間はわずか2分しかありません。私は撮影が主な目的ですが、その場で撮影パラメータを考える余裕はほぼありません。あらかじめパラメータは決めておき、予定どおり行動できるようにイメージトレーニングしていました。結果として↓のような感じで行動することができ、98%くらい完璧でした。このイメージ力はけん玉スキルだと思います。

第1接触（欠け始め）～皆既1分前まで
- ISO100, シャッター速度1/200sに設定, 念のためブラケット撮影1EVx5枚に設定（1/800, 1/400, 1/200, 1/100, 1/50s で一度に撮影）
- レリーズタイマーで2分おきに自動撮影
皆既1分前～第2接触（ダイヤモンドリング）
- 太陽フィルターを外す
- シャッター速度1/1000sに設定, ブラケット撮影2EVx5枚に設定（1/8000, 1/4000, 1/1000, 1/250, 1/60s で一度に撮影）
- レリーズで手動連写
皆既中1
- シャッター速度1/60sに設定, ブラケット撮影2EVx5枚に設定（1/1000, 1/250, 1/60, 1/15, 1/4s で一度に撮影）
- レリーズで手動連写5回くらい
- ここで興奮して三脚に足が当たってしまい構図がずれました。カメラの視野内になんとか収まっていたので、10秒くらいで中心に戻すことができました。視野から出ていたらアウトでした。
皆既中2
- シャッター速度1/4sに設定, ブラケット撮影2EVx5枚に設定（1/60, 1/15, 1/4, 1, 4s で一度に撮影）
- レリーズで手動連写3回くらい
皆既中3～第3接触（ダイヤモンドリング）
- シャッター速度を1/60sに設定
- カメラを動画撮影に切り替え
- ここまでで、皆既時間は残り30秒くらいだったようです。
- ふつうの双眼鏡で観測。広がっているコロナがくっきり見えて感動的でした。
- 広角レンズで撮影。金星が写りました。
第3接触～第4接触（日食の終わり）
- 太陽フィルターを付ける
- 露出1/200sに設定
- レリーズタイマーで2分おきに自動撮影

皆既中の写真は上の方に掲載しています。

皆既中の太陽と金星。冬の星座が見えるかと思いましたが、そこまでは暗くなりませんでした。

第3接触が終わると、帰っていく人がかなりいました。私は折角なので最後まで撮影してましたが、最後までグラウンドに残っていたのは私でした。撮影機材は私が一番重装備だったくらいで、重装備な人がほとんどいない穴場でとてもいい観測場所だったように思います。

帰り道は、ライオンズからセイラムまでは混雑もなくたどり着けましたが、セイラムからポートランドの間が大渋滞でした。高速も下道も大渋滞でかなり迂回しましたがそれでも渋滞していて、通常なら1時間弱くらいのところ、5～6時間かかりました。これが行きでなく帰りだったのが救いです。やはり前泊して移動したのは正解でした。

初めての皆既日食観測にも関わらず、最初から最後まで雲一つないパーフェクトな天気で、観測機材も順調で、予定していた観測がほとんどうまくでき、非常に満足度の高い旅になりました。北米行きを後押ししてくれた友人、快く送り出してくれた家族、観測場所を提供してくださった小学校の方、Facebookで地元の情報を教えてくれた友人達と、そのほかにも多くの方のおかげで素晴らしい体験をすることができました。感謝感謝です。次は2024年にまた北米で皆既日食があるのでまた行きたいですね。日本で次に見られるのは2035年なのでまだだいぶ先ですが、今から楽しみです。

おまけ

壁紙として使えそうな感じに加工してみました。よろしければご自由にどうぞ。

http://www.shakemid.com/pub/total_solar_eclipse_wall_1920.png

http://www.shakemid.com/pub/total_solar_eclipse_wall2_1920.png

Celestron Edge HD 800 にファンを取り付ける

Mon, 12 Jun 2017 23:59:01 +0900

Celestron Edge HD 800 に温度順応のためのファンを取り付けたメモです。

Edge HD はシュミカセなので安定した観測のためには温度順応が必要になります。シュミカセの温度順応は1時間以上かかると言われていますが、できるだけ早く温度順応させるために、サードパーティ製品で、TEMP-estという小型のファンを取り付けるキットが販売されています。鏡筒の通気穴（チューブベント）にファンを取り付けるというもので、面白い発想ですが、価格は165ドルとちょっといい値段です。 www.deepspaceproducts.com

日本で購入された方の記事によると、17mm角のファンが使われているようです。見た感じなんとなく自作できそうだったので、DIYしてみることにしました。 d.hatena.ne.jp

17mmのファンとなると非常に小さいので、PCパーツショップとかでは売っていないようでした。探してみるとマルツオンラインで、同じような17mm角のファンを取り扱っていました。マルツオンラインは、個人でも1個単位で注文できるので、電子工作のパーツ調達などに重宝します。購入したのは、日本電産コパル電子の「F17HA-05MC」という型番で、1個1170円でした。私は8000rpmのものを購入しましたが、もう少し回転数が多い11000rpmのものもあります。 www.marutsu.co.jp

注文してから5日ほどで、こんな感じのパッケージで届きました。

品物はこんな感じです。1円玉より小さい極小のファンです。こんな小さいファンは初めて見ました。

ケーブル類はPCのパーツを流用することにしました。もっと安いパーツもあると思いますが、PC自作が趣味なので、こんな感じのパーツは余ってます。

冷却ファンをUSB電源動作にできるケーブル　ファン用USB電源変換ケーブル　XC-USB5V

メディア: エレクトロニクス

StarTech.com ファン用二股分岐電源ケーブル 15cm CPUクーラーやファンの電源用に 1x 3ピン(メス) - 2x 3ピン(オス) TX3SPLITTER

発売日: 2002/10/18
メディア: Automotive

アイネックスファン用電源延長ケーブル CA-090

発売日: 2015/04/28
メディア: Personal Computers

アイネックスファン用電源延長ケーブル CA-092

発売日: 2015/04/28
メディア: Personal Computers

ファン用延長ケーブルのプラスチックのカバーは外してしまいます。ちょっと強めに引っ張れば外れます。黄色のケーブルは使わないので外してしまいます。

ファンのケーブルに半田付けします。

熱圧縮チューブで絶縁しておきます。

鏡筒にこんな感じのチューブベントが2つあるので、ドライバーで取り外します。

外すとこんな感じです。プラスチックのパーツに、金属製のメッシュが挟まっていました。

鏡筒の中が見えます。鏡筒の中に何か落とすと取り出すのにかなり苦労しそうなので要注意です。

二股電源コネクタのプラスチックのパーツを外します。これも少し力を入れて引っ張れば外れます。こちらも黄色のケーブルは使わないので外してしまいます。

こんな感じでケーブルを通します。メッシュは端を折ってケーブルが通るようにします。

二股分岐ケーブルに、プラスチックのパーツを再度取り付けます。赤と黒のケーブルの位置を間違えないように注意します。

ファンを取り付けます。ちょっと不格好ですが針金で縛りました。寸法的には20mm角くらいのファンでも取り付けられそうな気がします。（2017/6/28追記 20mmのファンを取り付けられました）

一方が吸気、一方が排気になるように逆向きにファンを取り付けます。

鏡筒の中に、二股分岐ケーブルが付いていない方のファンの電源ケーブルを通します。なるべくグリスまみれのネジに触れないように注意します。

チューブベントのパーツを取り付けます。ファンがきれいに収まっています。

二股電源コネクタにファンの電源ケーブルを接続します。

ふたをすると電源コネクタが外に出ている形になります。

USBコネクタを取り付けて完成です。

試運転。小さいファンですが風を感じるので、それなりに効果はありそうな気がします。

材料費4000円弱でファンを取り付けることができました。惑星がよく見えるシーズンなので、きれいに見えるようになるといいなあ。

(2017/6/28追記)

20mm角のファンを取り付けられそうだったので取り付けてみました。

20mm角のファンはSUNON（サンオン）社くらいしか作っていないようで、あまり選択肢がありません。「MC20100V2-000U-A99」という型番のものを購入しました。 www.marutsu.co.jp

17mm角のものと比べると一回り大きいです。性能は3倍です。F17HA-05MC が 0.5CFM（立方フィート/分）に対し、MC20100V2-000U-A99 は 1.5CFM です。より温度順応が早くなると期待できそうです。

チューブベントのパーツに取り付けてみました。こっちの方がぴったりですね。

梅雨で天気がすっきりせず望遠鏡の出番がありませんが、機材のメンテナンスをするにはいい機会かもしれませんね。梅雨明けが楽しみです。

Celestron Edge HD 800 にガイドスコープを取り付ける

Sun, 11 Jun 2017 22:08:19 +0900

Celestron Edge HD 800 にガイドスコープを取り付けたメモです。

CELESTRON　EDGE　HD800-CG5　鏡筒　【国内正規販売品】

出版社/メーカー: Celestron
メディア: エレクトロニクス
この商品を含むブログを見る

なんとなくオートガイドをやりたくなったので、Edge HD 800 にガイドスコープを取り付けることにしました。鏡筒にガイドスコープを取り付ける方法はいくつかありますが、今回は、BORGのファインダー台座(旧式の7755)をたまたま持っていたので、これを活用してみることにしました。

アリミゾ式ファインダー台座ＢＫ｜製品情報｜BORG(ボーグ)天体望遠鏡

Celestron鏡筒のネジは、UNC規格（インチねじ）なのですが、近所のホームセンターでは売っていませんでした。なかなか店頭では売ってないようなので、モノタロウの通販で購入することにしました。日本で売られているほとんどすべてのネジが入手できるようです。さすがモノタロウ。Celestron鏡筒には、#8×3/4インチ程度の皿ネジが適合するようです。ネジだけ買うと送料の方が高くなってしまいますが、数百円の話なので目をつむることにします。 www.monotaro.com

鏡筒のネジを1本外してファインダー台座を取り付けてみたところ、ぴったりでした。ネジ1本での固定ですが、がっちりと止まっているように見えるので大丈夫そうです。

ガイドスコープを取り付けたところです。

ガイドスコープは 60mm, F/4 の安いのにしました。

AstroStreet 60mm F4 ガイドスコープセット脚付きファインダー/CCDオートガイドに

出版社/メーカー: アストロストリート
メディア: Camera
この商品を含むブログを見る

オートガイダーは、シュミットで安売りしていた Celestron NexGuide にしました。

【国内正規品】 CELESTRON オートガイダー NexGuide,AutoGuider CE93713

出版社/メーカー: セレストロン
メディア: Camera
この商品を含むブログを見る

全体はこんな感じです。バランスは悪くない感じです。このガイドスコープで Edge HD 800 をガイドできるかは未知数ですがさてさて。