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

概要

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

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

主な機材

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

サイトロンQBPフィルター

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

ZWO ASI294MC Pro

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

ZWO ASIAIR Pro

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

M27亜鈴状星雲

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

f:id:shakemid:20200504180706j:plain

M16わし星雲

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

f:id:shakemid:20200503211939j:plain

ハッブルの写真はこちら。自宅からちょっとハッブル気分です。 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】

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

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

ステライメージ8

ステライメージ8

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

在宅勤務してました

概要

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

よいこと

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

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

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

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

よくないこと

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

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

まとめ

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

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

概要

最近アマチュア天体写真界隈で流行っている 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を使用しました。はてなブログでも、JavascriptCSSを本文に埋め込んで使用できました。

github.com

# 使い方の例

<link type="text/css" rel="stylesheet" href="https://cdn.jsdelivr.net/gh/koenoe/cocoen@master/dist/css/cocoen.min.css">
<script type="text/javascript" src="https://cdn.jsdelivr.net/gh/koenoe/cocoen@master/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

序章

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

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

shakemid.hatenablog.com

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

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

P=p^{125}

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

P=0.99^{125} \fallingdotseq 0.285=28.5\%

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

P=0.999^{125} \fallingdotseq 0.882=88.2\%

たかが大皿といえども、ここまで難しくなるのです。大皿という簡単な技を、難しいと思えるかどうかがこのチャレンジの肝だと言えます。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の時点で頭に入れていました。

P=0.9999^{44} \cdot 0.999^{77} \cdot 0.99^{4} \fallingdotseq 0.885=88.5\%

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

7 \div 8=0.875=87.5\%

2019/12/30 リハ2日目

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

15 \div 17 \fallingdotseq 0.882=88.2\%

2019/12/31 本番

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

24 \div 26 \fallingdotseq 0.923=92.3\%

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

24 \div 27 \fallingdotseq 0.889=88.9\%

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

25 \div 26 \fallingdotseq 0.962=96.2\%

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

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

ameblo.jp

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

www.fujitv-view.jp

次回への展望

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

www.nikkansports.com

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

概要

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

相貌失認

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

相貌失認は高次脳機能障害の一種で、人の顔を覚えられない、人の表情がわからないといった症状があります。 人口の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 で自動導入

概要

f:id:shakemid:20190824160809j:plain

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赤道儀(ステンレス三脚仕様)

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-FiSSID無線LANに接続し、SynScan Pro App で SynScan Wi-Fi に接続します。

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

f:id:shakemid:20190825225512p:plain

「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にしておきましょう。

f:id:shakemid:20190825224521p:plain

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

f:id:shakemid:20190825224856p:plain

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

f:id:shakemid:20190825224914p:plain

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