Cloud Penguins

Flying penguins in the cloud.

PagerDutyにProduct Evangelistとして入社しました

インシデント対応プラットフォームとして知られるPagerDutyに、Product Evangelistとして入社した。

www.pagerduty.co.jp

▲マスコットのペイジーくん

Evangelistを仕事にするよ

コミュニティ活動で知り合った人からは、「お、ついに本職になるんだね」と、あまり違和感なく受け入れられるんじゃないかなと思っている。むしろ、「今まではDevRelじゃなかったのか」とまで思われるかもしれない。そう、これまではPre-sales Engineerだったし、それより前はProfessional Serviceだったので本業におけるコミュニティ活動はあくまでもボランティアだったのだ。

逆に、自分と付き合いが長い人からすると「え、DevRel? おまえDevRelにはならないって言ってなかったっけ?」と驚かれるんじゃないかと思う。そう、自分はDevRelにはならねぇ!と公言していた時期もあったのだ。

テクノロジーを人に伝えるということ

なんだかんだで社会人生活も長くなってしまったのだが、十数年やってきて自分自身が何に対して情熱を注げるかというのが分かってきた。結局のところ、自分は「テクノロジーが大好き」であり、「よいテクノロジーがあるのならば、是非それを人に紹介して、その人が幸せになってほしい」というのがモチベーションの根源なんだなと。

そのモチベーションを仕事につなげる方法は複数のアプローチがある。

Professional Serviceのときは、テクノロジーを導入してくれたお客さんにガッツリと入り込んで、単にプロダクトを入れるだけではなくそれを使うチームから育てていくことで、価値を最大限に生かせるようにするという仕事をしていた。自分が分かりやすく伝えれば伝えるほどお客さんの理解も高まり、テクノロジーを生かす敷居が低くなり価値が生まれやすくなる。 自分はそういう技術を伝えるプレゼンが得意だと自負しているのだが、それはこのあたりの経験が生きている。この仕事は今でも自分にマッチした天職だと思っている。

前職ではPre-sales engineerだったが、これもまた違ったテクノロジーを伝える仕事のひとつだ。プロダクトを正しく、かつ魅力的に伝えないとそもそも買ってもらえない。最終的には買ってもらうというのが自分の評価になるのだが、それを成し遂げるためには、まずはプロダクトを語る。それも、単に機能を説明するだけでなくてそれが組織にどのような効果をもたらすのか。直接的なものから間接的なものまで、幅広くアピールするのが重要だ。

これも自分のスキルが生かせる仕事であり楽しかったのだが、最終的な評価は どれだけお客さんが幸せになったか ではなく どれだけ売り上げに貢献したか で下される。どれだけお客さんがプロダクトによって幸せになったかは副次的なものであり、そこにジレンマを感じることもあった。

じゃあEvangelistはどうかというと、 どれだけテクノロジーを伝えたか=自分の評価 となるポジションなので、その点においてはうってつけのポジションだといえる。

じゃあなぜDevRelにはならないと公言していたのか

シンプルな話、 かつてDevRel関連で嫌な思いをしたから の1点に尽きる。結構前の話なので掘り返しはしないのだけど、ユーザーへのリスペクトが欠ける対応をされたので、ああいうのはちょっとなぁ・・・となってDevRelを敬遠するようになったのだった。

ただ、それから数年。CloudNative DaysやPaaSJP、Platform Engineering Meetupなどのイベントを自分で主催し、さまざまなDevRel職の方と接する機会が増えてきた。結果として、「あのときはどうも例外に当たっただけで、ほとんどのDevRelの方は真剣にユーザーと向き合っている」ということが分かってきた。

最近ではかわまたさんを中心にDevRel Guildというコミュニティが発足し、活発な情報交換がなされている。

自分も本業の傍ら技術広報的な役割を担うことも増えていたことから、じゃあこれをメインの仕事にしてもいいんじゃないか?と思い始めたタイミングで今回の採用の話が転がりこんできたという流れだ。

入ってみてどうだったか

まだ2日しか経っていないので、プロダクトについてはこれから数週間かけてしっかりとキャッチアップしていく。ただ、現段階で確実にいえることは「本当に面白いプロダクトだな」ということ。

自分もそうだったし世の中からの見え方もそうだと思うが、PagerDutyとは「障害があったら叩き起こしにくるやつ」という認識をされている。それは間違っていないし、プロダクトの中心はそういったIncident Responseの機能だ。

だが、今はそれだけではない。AIによって賢くフィルタリングしてくれる機能、自動で背景情報を提供してくれる機能、イベントに応じて処理を自動化する機能など、めっちゃ便利な機能がたくさんある。

www.pagerduty.co.jp

ポストモーテムを自動で作成してくれる機能まである。自分が現場でプラットフォームを運用しているときに、これがあったらどれだけ楽になったことか・・・

support.pagerduty.com

他にも活用できたら素晴らしい機能がたくさんあるようで、何はともあれまずは自分で触ってみて学習していかないとなと。自分に課されたミッションは、こういった機能を 自分の言葉で 発信していくこと。できるだけ早く役に立つ話ができるよう務めたいと思う。

HashiCorpを退職します

本日はHashiCorp Japanにおける最終勤務日。ということで今回はいわゆる退職エントリーというやつ。

HashiCorpでは何をやっていたのか

HashiCorp Japanに入社したのは2021年9月。なので、おおよそ2年と1ヶ月勤務したことになる。

HashiCorpではSenior Solutions Engineerという、いわゆるプリセールスエンジニアというロールで、TerraformやVaultといったHashiCorpプロダクトの商用版を技術的な観点でお客さんに提案するというポジションだった。

担当インダストリーが特に決まっていたわけではないが、ゲーム系やWeb系のお客さんを多く担当した。あと、個人的な興味から「カメラに関するお客さんは自分担当にして欲しい」とお願いして担当していたりもした。やっぱり興味のあるインダストリーだと身が入りやすかったりもするので。

プリセールスエンジニアというロール自体、実質初経験だったというものあって、なかなか大変なこともありつつも楽しく仕事できていたと思う。

前職のVMwareではプロフェッショナルサービスを担当していたため、少数のお客さんに対してガッツリ入り込むという仕事が多かったがプリセールスエンジニアはその逆。たくさんのお客さんに対して広く接するという形になるので、仕事のスタイルは大きく変わることになった。深い技術をしっかりと伝えると言うよりは、お客さんが必要としている技術や情報をテンポ良く提供していくことが求められるため、周囲の助けをうまく求めながらスピード感重視で仕事を回すのが重要だった。これはなかなか良い経験だったように思う。

また、コロナ禍でミーティングの殆どはオンラインであったため、それまで趣味半分で磨いてきたオンラインホワイトボーディングの技術プレゼンの技術などは大いに役立った。

人前でプレゼンすることに抵抗がないため、パブリックでの登壇系も多く引き受けていた。HashiCorpの思想やプロダクトは非常に尖っており、情報発信していくのはとても楽しかったし、ここに関しては会社から求められるものと自分のスキルセットがうまくかみ合っていたように思う。

なぜ退職するのか

仕事内容や自身のスキルと仕事のマッチングには特に大きな不満はなかったのだが、なぜ退職するのか。

一番大きな理由は、HashiCorpの方向性が変わってきたというところ。

ご存じの方も多いと思うが、先日プロダクトライセンスが変更になり、それに対してさまざまな議論が巻き起こっていた。表に見えるのはそのライセンスの話が中心だろうが、会社としての目指す先も変わってきたように感じている。

ソフトウェア、特にオープンソースをビジネスにしていくのは非常にチャレンジングだ。

自分の入社後、2021年の12月にHashiCorpはNASDAQに上場を果たした。ビジネスを大きくしていく上で上場というのは非常に重要である一方、世の中に対して大きな責任を負っていくということも意味する。市場が求める形に会社を変えていかなければいけないし、時にはそれが大きな議論を引き起こすこともあるだろう。

個人的にはビジネスを大きくしていく観点において、HashiCorpが行ったこの方針転換を支持している。簡単な決断ではなかっただろうし、世の中からの反応も予測できていたと思う。それを分かった上で行った決断は尊重したい。

一方で、そういった方針転換後の組織で自分がどういう点に貢献していけるか。自分が尊敬し憧れていたHashiCorpのフィロソフィーみたいなものが変化してきた中で、身を入れて貢献していけるかという点について考える必要性がでてきた。そして色々考えた結果出した結論が、今回の退職という選択肢だった。

このあたりについてはどういう書き方をしてもネガティブな感じに見えてしまうだろうけど、繰り返し強調したいのは会社の方向性に反対するから辞めるわけではないことだ。ライセンスが変わろうともHashiCorpプロダクトが最高なのは変わりないし、導入することによって得られるメリットも変わらない。辞めた後も1ユーザーとしてプロダクトを使い続けるだろうし、積極的に情報発信もしていきたいと思っている。

HashiCorpにはHashiCorp Ambassadorsというアンバサダー制度がある。年末には来年のアンバサダーの立候補ができるはずなので、興味のある人は応募してみて欲しい。

ちなみにHashiCorpプロダクトでいうとみんなTerraformばっかり取り上げるのだが、個人的に一番良いプロダクトはVaultだと思っている。みんなVault使おう。

booth.pm

次はなにをやるのか

次の所属先での勤務は明日から。次も、自分としては初めての挑戦となるロールであり世の中との接し方もこれまでとは違ったやり方が求められるようになる。

ここについては改めて別エントリーで書いていきたいと思う。

個人活動の一環として関与していたCloudNative DaysやPlatform Engineering Meetup、一般社団法人クラウドネイティブイノベーターズ協会との関わり方はこれまでと変わらないので、そちらのほうで絡んでいる方は今後ともよろしくお願いします。

それでも僕らがイベントのライブ配信を続ける理由

TwitterXを見ていたら、とある技術系イベントがライブ配信を取りやめ、現地開催とアーカイブ配信のみにするとのことで、大変盛り上がっていた。賛否両論あるようだが、どちらかというと否定的な意見の方が多かった。

これについて、同じく技術カンファレンスや大規模ミートアップをハイブリッド開催している身としては、どちらの意見も痛いほどよく分かるので、自分の考えを纏めてみようと思う。

ハイブリッドイベント(現地開催&ライブ配信)は死ぬほど大変

自分はCloudNative DaysとPlatform Engineering Meetupという2つのイベントを主催している。CloudNative Daysは申し込み数が4桁、多いときで6トラック平行で開催する日本最大のクラウドネイティブ技術のカンファレンス。Platform Engineering Meetupは今年から始めたイベントだが、初回から申し込み数が500人を超えるという、かなりの大規模勉強会だ。

そのどちらも、現地開催とライブ配信両方を行うハイブリッドイベントの形式を取っている。

cloudnativedays.jp www.cnia.io

正直言って、運営側は相当しんどい。かかる負担について、ライブ配信のみのオンラインイベントを1とすると、現地開催のオフラインイベントだと4ハイブリッドイベントだと8くらい労力がかかる。

オンラインイベントであれば、自室でもどこでもいいので環境が整った部屋を用意し、OBSなりStreamYardなりでオペレーションをすれば良い。スタッフ全員が自室に居ながらイベントを完遂することも可能だ。

それが現地開催になると、まず会場を抑えるところから始めなければいけない。規模が大きくなればなるほど、費用と労力がかかる。また、イベント当日も会場設営から受付の人員配置、誘導員の配置などたくさんの人を動かす必要がある。オンラインイベントに比べると数倍大変だ。

一方で、セッション自体はプロジェクターでスライドを映しつつ、会場の音響を使って参加者に声が届けばそれで済む。どのイベントでも共通してこの要件なので会場側にも知見があるし、依頼できるイベント会社もたくさんある。

ハイブリッドイベントが何故大変か

これがハイブリッドイベントだとどうなるか。オンラインの手間+現地開催の手間 の足し算で済むかと言えばそんなことはなく、感覚値で2倍くらい大変になる。

まず会場選びの難易度が上がる。物理的な広さだけでなく、回線の本数や品質が非常に重要になってくるし、どこにカメラや照明、オペレーション卓を設置するかも考えなければいけない。

登壇者のスライドだって、プロジェクターに出しつつキャプチャして配信しないといけない。プロジェクターをカメラで撮る形だと、とても読みづらいよね。

音響も、会場の設備を使って音声を流しつつ、それをクリアに配信にも載せないといけない。単に会場の音をマイクで拾えばいいってわけじゃないのだ。

先日CloudNative Days Fukuoka 2023というイベントを福岡で開催した。現地開催のみであれば会場の図面だけでほとんどの設計が可能なのだが、このようなライブ配信の要件があると、現地で直接確認しないとなにも分からない。なので、仕事の休みを取って現地に飛び、念入りにチェックする必要があった。もしこれで要件を満たさないことが分かったら、また別に下見をしないといけない。この時点で負担が大きいことが分かるだろう。

イベント当日も大変だ。これまで通り、現地で受付したり誘導したりする人員は必要だし、それに加えて音響や配信に関わるメンバーをトラックごとに配置する必要がある。CloudNative Days Fukuokaでは、配信周りもほとんど全てを実行委員会で設計し、運用した。

検証に検証を繰り返し、最新の機材も投入し、なるべく少人数で運用を回せるようにして、なんとかボランティアの実行委員内でやり遂げた。これを自力でやり遂げられるイベント運営は数少ないだろう。

そうでない場合は、外部の専門業者に依頼することになる。そうすれば運営側の負担を軽減しつつ配信を行えることになるが、当然それなりの人数と技術を要求する作業なので、費用はかなりかかってしまうことになる。様々な地域で開催する場合、都度地元の業者を探し当てて交渉しないといけない。

お金を払ってでも運用を任せるか、あるいは人手を割いて自分たちで頑張るか・・・いずれにせよ、超大変である

自分が思いつきで始めたPlatform Engineering Meetupのほうは、基本的に1トラックのみなのでCloudNative Daysに比べると負担は少なかった。

それでも、配信をスムーズに行えるようにするため、35万円するRolandのVR-6HD個人で購入することになったので、大変なのには変わりがなかった。

結果として、個人で運用出来る範囲を早々に超えてしまったため、Platform Engineering Meetupを運用するための法人を作ったほどである。

prtimes.jp

オンライン配信は盛り上がらない (と錯覚する)

運営側視点に立つと、やっぱりイベントは現地会場が一番盛り上がる。イベントに対する反応も来場者の顔を見れば分かるし、参加者同士が談笑したり、熱く語っていたりする姿を見るのは、やはり良いものだ。

参加者からは「いいイベントをありがとう、また来ます!」と声を掛けられたりもする。主催者冥利に尽きる瞬間だ。

一方で、オンライン配信は盛り上がらない。。。いや、これは正確ではない。『盛り上がっているかどうか、良く分からない』というのが正直なところ。チャットやTwitterハッシュタグで書いてくれる人はいるが、それは参加者のほんの一部。参加者全体がどういう反応をしているのかは、よく分からないのだ。

これは良い悪いではなくて、単純にオンラインの限界なのだ。CloudNative Daysでも、なんとかオンラインイベントを盛り上げられる仕組みを試行錯誤したが、難しかった。カメラ映像と音声をリアルタイムでやり取り出来るZoom会議ですらリアル会議に比べると意思疎通に課題があるわけで、一方通行なライブ配信でオンライン側の反応を正確に把握することなんて、到底無理な話である。

実際にはオンライン側もすごく盛り上がっているかもしれない。視聴者の反応もすこぶる良いかもしれない。でも、どうしてもそれが伝わらないのだ。主催者側の感情としては、リアルな反応を得られる現地開催と、反応がよく分からないオンラインを比べたら、どうしても現地開催側に重点を置きたくなってしまうのは理解できる。

でも実際のところ、参加者はライブ配信を求めている

ここからは参加者側からの視点の話。

主催者側は現地開催を重要視する方向になりがちだが、実際のところ多くの参加者はライブ配信を求めているという現実がある。

たとえばPlatform Engineering Meetupは、登録者のうち現地参加が10%、オンラインが90%程度である。これは現地参加人数を意図的に絞っているところも大きいが。

CloudNative Daysは、2022年の東京開催以降はハイブリッド形態を取っているが、どの回もおおよそ現地参加が20%、オンラインが80%だ。現地会場に余裕があってものこの程度なので、実際のところ8割の参加者はオンライン参加を希望している

オンラインで見たいのであれば、別にライブ配信じゃなくてもアーカイブ動画があればそれで良くない?と思うかもしれない。しかしこれも数字があり、アーカイブの視聴数は20%から30%程度であり、70%から80%はライブ配信の視聴数なのだ。アーカイブ視聴者数はロングテールで増えていくため、長い目でみれば徐々にアーカイブ視聴数の割合が増えていくだろうか、少なくとも短期的な視点では、多くの視聴者はオンラインのライブ配信を求めている と、数字からは判断ができる。

何故オンラインのライブ配信が好まれるのか

ここから先は数字による裏付けはなく、伝聞や推測の話になってくるのだが、さまざまな理由でライブ配信が希望されているようだ。

情報収集が主であり、コミュニケーションはそこまで必要ではない

イベントに参加慣れしている人からすると、「コミュニケーションこそが大事だよ、むしろ懇親会が本番」という人も居て、その考え方は間違っていないと思う。でも、必ずしも全員にそれが当てはまるかというとそうではない。知識を得るためにセッションを見ているんだという考え方も、当然正しい。

また、自分の主となる分野であればコミュニケーション取りたいが、専門以外の領域については情報を得られればそれでいいという人も多いだろう。コミュニケーションが必要かどうかは、時と場合によるのだ。

コミュニケーションを取りたい気持ちはあるが、まずはオンラインで雰囲気を見て現地参加するかどうかを決めたい

コミュニケーションが苦手というわけではないが、何も知らないコミュニティにいきなり飛び込むというのはなかなか勇気が必要だ。オンライン配信があれば、登壇者や司会者のノリでなんとなく雰囲気を掴むことができる。それをみて楽しそうだなと感じたら、次回以降は直接参加するというやり方を取れる。

他の地域に住んでいるので、距離の問題で参加できない

一番人口の多い東京で開催する場合でも、関東圏の人口は約4400万人であり、日本全体の半分以上は「物理的に遠い場所」での開催となってしまう。もちろんそれでも参加する人はするのだが、少数派だろう。ただ、異なる地域にいても配信があれば参加できるので、有り難い話だ

出来ることなら現地に行きたかったが、スケジュールや費用などの都合で断念

普段なら間違いなく現地に行く!という人でも、スケジュールの都合でどうしても参加できないというケースは多々ある。丸一日別の用事と被ってしまうというのであればスッパリ割り切ることもできるかもしれないが、会期中のたった1時間だけ、どうしても外せない大事なミーティングがあって泣く泣く断念・・・というケースの場合はなかなか割り切りづらい。TwitterXを見れば楽しそうな様子が伝わってくるが自分は体験することすらできない、アァ・・・。という。

ライブ配信があれば、100%ではなくてもいくらかは「イベントに参加している感」を得ることができる。

何故アーカイブ配信ではダメなのか

上記の理由に対して「アーカイブ配信があるから、それで良くない?」と思うかもしれない。確かに、1つめに挙げた「情報収集がしたいだけ」というニーズに対してはそれで応えられるかもしれない。

でも多くの場合、ライブ配信の需要はアーカイブ配信では救えないのである。

「イベントに参加する」という感覚は、他人と何かを共有することから生まれる。例えば現地参加であれば、時間と場所を共有できるので強い参加体験が生まれるのだ。ライブ配信の場合、場所の共有は曖昧になるが時間の共有は可能になる。100%ではなくても、イベントに参加した感は得られるのだ。

アーカイブ配信のみとなった時点で、そのコンテンツはudemyの動画を視聴するのと同義になってしまい、イベントに参加した感は綺麗さっぱり無くなってしまう。本当はイベントに参加したかったのに諸事情で断念せざるを得なかった人に対して「アーカイブ配信あるからいいでしょ」と伝えてしまうと、逆に強い疎外感を与えてしまう可能性すらある。

それでも僕らがイベントのライブ配信を続ける理由

ここまで書いてきた、主催者側と参加者側の考えのミスマッチが議論を呼んでいる理由ではないかと考えている。

冒頭にも書いたように、ハイブリッド配信は死ぬほど大変だし高コストだ。であれば現地に絞ってクオリティの高いイベントをやりたいという主催者の意向は尊重されるべきだし、その決断に対して非難の言葉を投げかけるのは止めた方が良い。

一方で、参加者としてライブ配信が無くなることに対して残念な気持ちになるというのは正しい反応だし、イベントとしての評判が下がってしまうことは避けられない。なんせ8割の需要を切り捨ててしまったわけで、そのデメリットを主催者は覚悟しなければいけない。

じゃあ自分がやっているイベントについてはどうするか。これに関しては、少なくとも自分が関わっている限りは、ハイブリッド配信を貫こうと考えている。

技術を普及させたいという想い

CloudNative Daysにしても、Platform Engineering Meetupにしても、どちらも比較的新しい、まだ十分に普及したとは言い難い技術やカテゴリを扱うイベントだ。これらを普及させるには、とにかく存在を知ってもらい、触ってもらい、メリットを理解してもらうことが重要だ。

特にそういった情報やイベントに触れる機会が少ない地方に対してイベントを届けていくことが大事だと考えていて、ライブ配信は絶対に無くしたくないというのが自分の考えだ。

関東圏以外でもイベントを開催することも重要だと考えていて、先ほど紹介したCloudNative Days Fukuokaもそうだし、Platform Engineering Meetupも名古屋と福岡で開催した。これまた難しい話なのだが、地方でイベントを開催すると「その地方のみを対象としたイベント」と捉えられがちだ。そうではなくて、地方で開催することによって直接参加できる機会を広げつつも、コンテンツの内容は全国向けでありたいなと思っている。そうなると、今度は人口の多い関東圏に向けてライブで配信するという観点が重要になってくる。

いずれにせよ、自分がやりたいイベントをやっていくには、ハイブリッド配信がキーというわけだ。

ハイブリッド時代に向けて培ってきたノウハウ

2020年、2021年はそもそも現地参加のイベントが開催できなかったのでオンライン配信のみにせざるを得なかった。しかしこの頃から「仮にコロナが明けたとしてもオンラインでイベント参加するという習慣は残り続けるだろうな」と考えており、配信技術やノウハウの蓄積を積極的にやってきた。

CloudNative Days実行委員会の配信担当メンバーを中心に組織しているイベント配信チーム EMTEC は、この界隈では屈指のノウハウを持っていると自負していて、地方開催であっても迅速にハイブリッド配信を行える体制を整えている。

数年掛けてこの体制を作ってきたので、ハイブリッド配信に強気でいられるというのも大きい。

ちなみに最近立ち上げた 一般社団法人クラウドネイティブイノベーターズ協会 では、コミュニティイベントの配信を支援するというのも活動内容の一つとして掲げている。いろいろな形でEMTECチームが支援できると思うので、もしハイブリッドイベントをやりたいというイベント主催者がいたら相談して欲しい。

まとめ

  • ハイブリッドイベントは主催者にとって超絶負担が大きい
  • ライブ配信やめる決断も尊重すべき
  • とはいえ、今やライブ配信はマジョリティ
  • 自分としてはライブ配信に積極的に取り組み、そのノウハウを広げていきたい

というのが今回言いたかったこと。ではでは

vExpertになりました

本日vExpert 2023 Awardsの発表があり、なんと自分も受賞することができました。

blogs.vmware.com

vSphereとHashiCorp Stackを組み合わせた活用周りや、Tanzu中心としたCloud Native Application周りの情報発信を積極的にやっていきたいなーと思ってます。去年はあまりブログ書かなかったなーという反省があるので、vExpertの名に恥じないよう、ちゃんと書いていこうかなと思います。

CloudNative Days Tokyo 2022でMiroを使ったオンラインホワイトボードをやった話

Miro Advent Calendar 2022の2日目!

今回はCloudNative Days Tokyo 2022(CNDT2022)でMiroを使ったオンラインホワイトボードをやってみた話。

オフラインイベントとホワイトボード

CNDTは2018年から続いているクラウドネイティブ技術のオンラインカンファレンス。2020以降はコロナ禍もありオンライン開催のみとなっていたけれど、徐々に対面のイベントも再開の兆しを見せており、CNDTもオンライン&オフラインのハイブリッドイベントで開催することに。

そこで個人的に力をいれて企画したのが、ホワイトボード企画。 参加者に自由に描いて貰えるホワイトボードを用意し、技術的なテーマでディスカッションしたり、フリーテーマで書き込んだり、求人情報を書き込んだりできるスペースを作りたいなと。

以前 @Ladicle@superbrothers と一緒にやっていたCloudNative Deep Diveという企画がベースとなっており、さらに書き込めるテーマを広げた形だ。

deepcn.connpass.com

このホワイトボードを置く企画は見た目以上に効果があり

  • カンファレンスがもたらすコミュニケーションの要素をさらに強化する
  • 同期的なコミュニケーションだけでなく、過去の書き込み対してリプライするという非同期のコミュニケーションを実現する

といったメリットがあり、オフラインイベントを復活させる際には是が非でもやりたいと思っていた。

CNDT2022でも実施した結果、想定していたとおりかそれ以上にに盛り上がり、大変満足な結果となった。

オンライン側はどうするか? ⇒ Miroを使おう

オフライン企画についてはホワイトボードとマーカーを置くことで実施できるが、じゃあオンライン側はどうするのか?というのが課題として残る。CNDT2022はオフライン(+α オンライン) という形態ではなく、オフラインにもオンライン同等に力を入れる、むしろ参加人数的にはオンラインのほうが数倍多いというイベント設計にしていたため、オンライン側でも同様に実現したかった。

じゃあどうするか?と考えた結果投入したのがMiroだった。

Discussion Board

技術的なトピックについてディスカッションするスペース。

Job Board

Free space

いずれも思った以上にちゃんと付箋紙貼って参加してくれる人が多くてとてもポジティブだった。

工夫したポイント

使い方の説明をあらかじめ書いておく

現地ホワイトボードの写真を定期的に貼り付けることでオフラインとオンラインの橋渡し

あとはベースとなるデザインのほうには必ずロックをかけておくことが重要。そうしないと参加者が意図せず触って移動させてしまったり消してしまったりする。

次への課題

結果としてMiroのおかげでオフライン側でもイメージしたとおりのホワイトボード企画を実施できた。 なので目標は達成できたのだが、自分たちが理想とする世界を実現出来たかというとまだその域には達していない。

CloudNative Daysは、OMO (Online Merges with Offline) とも言われるオフラインとオンラインが融合したカンファレンスを目指している。

▲ 記者発表会で説明したスライド

今回実現出来たのはオフライン、オンラインそれぞれで同様の仕組みを用意するというものであり、依然としてオフラインとオンラインの間に隔たりが存在した。今後はこのあたりをどうやって上手く融合させていくかを考えたい。

今回もアイディアとしては

  • MiroのiFrame Embed機能をつかって現地のライブストリーミングをMiro上に表示する
  • Miroの様子を現地のディスプレイやプロジェクターに投影する
  • ARを活用してスマホをのぞき込むと巨大なMiroが表示されている

といったものがあったが、それぞれユーザー体験の面でまだ難があったり、そもそも実行委員会側にそこまで作り込む余裕がなかったりとで踏み込むことができなかった。

言い方を考えると今後もいろいろと工夫出来る余地があるということで、Miroコミュニティとも相談しながらハイブリッド時代に向けたMiroの活用方法を見いだしていきたいなと思う

Miroの画面移動が左クリックから右クリックに変更になった話

Miro Advent Calendar 2021の最終日

Miroをマウスで使っている人は気づいたかもしれないが、最近キャンバス内の移動操作が左クリックから右クリックに変更になった。

操作感という意味ではとても大きな変更なので、驚く人も多いだろうと思ってこのエントリーを書くことにした

ナビゲーション設定が変わっている!

Advent Calendarの5日目に以下のような記事を書いた

jaco.udcp.info

操作に違和感があるときはマウス操作なのにトラックパッド設定になっているとか、その逆になっていないか?というのが記事の趣旨である。

そのときに使ったスクリーンショットがこれだ。

今この設定を開くとどうなっているかというと、こうだ

マウスとトラックパッドの設定の他に、Auto switchという設定が増えている。

Auto switchにしておけばマウスとトラックパッドどちらも使うような環境であってもうまいこと切り替えてくれるので、基本Auto switchで問題ないと思われる。

それよりも影響が大きいのが、冒頭にも書いたキャンバス移動操作だ。

キャンバス移動が右クリックになった!

そう、このキャンバスの移動操作が右クリックになったのである。

過去のスクリーンショットのほうを見ると、明らかに左クリックをする操作になっているので、今回のアップデートに伴って入った変更だと分かる。

このアップデートは、過去数ヶ月にわたり順次ユーザーにリリースされたようで、自分の環境では1週間ほど前から有効になった。

右クリックによるメリットは?

左クリックによる移動をやめて右クリックにするメリットは明確だ。

左クリック時代には、キャンバス内移動をしようとしたところ誤ってオブジェクトやフレームを掴んで動かしてしまうという誤操作が多発していた。1人で使っているだけであればUndoすればいいだけなので大きな問題には感じないが、複数人でワークショップを行っている際には混乱の元だった。どこかの参加者が間違ってフレームを動かしてしまい、他の参加者が驚くというのはよく見られる光景だった。

コミュニティを見てみると、この機能の提案は8ヶ月程前に投稿されていた。

community.miro.com

といってもいきなり変えられても困る

メリットが明確であったとしても、操作の習熟には時間がかかるわけで、これまで手足のようにMiroを使っていたユーザーからすると戸惑うことも多いようだ。

公式のコミュニティにも、左クリック操作に戻せるようなオプションを付けて欲しいという要望が投稿されている。

community.miro.com

community.miro.com

コメントも多く付いており、反響も大きいように見える。同意・不同意、あるいは何らしかのアイディアがある人はコミュニティに投稿していくと良さそう。(英語の壁はあるけれど・・・)

また、このような機能を導入する際にどうやってユーザーとコミュニケーションを取っていくべきかについても意見を募集しているようなので、もし意見がある場合は伝えると良いかもしれない。

今回の件に限らず、製品に対しての改善アイディアについては、Yasumaさんの記事を参考にWishListに投稿していこう。

note.com

vSphere環境が崩壊したのでTerraform活用して一から構築した

今日はTUNA-JP Advent Calendarの24日目

9月からHashiCorpに転職したわたくし。仕事でTanzuプロダクトを触ることはあまりなくなってしまったが、HashiCorpプロダクトを活用してTanzu環境を便利にしていく連携も可能なので、TerraformやVault、Consulを組み合わせて色々やる記事を書くつもりだったのだが・・・

vSphere環境が崩壊した!

我が家のラボ環境は3台のESXiでvSAN+その他用途に独立した1台のESXiという構成で構築しているのだが、そのうちvSANを組んでいる2台が起動しなくなった。2週間ほど前に1台が起動しなくなり、つい数日前にまた1台が起動しなくなってしまった。3台のうち2台が死んでしまったので、vSAN環境は見事に崩壊してしまった。

理由はおおよそ分かっている。この環境は、ESXiをUSBメモリからブートしていたのだ。

ESXi 7.0からUSBメモリやSDカードからESXiをブートするのはサポートされない。

Removal of SD card/USB as a standalone boot device option (85685)

日本語情報だと yuki_kawamitsuさんがまとめてくれている。

kwmtlog.blogspot.com

ESXi 7.0以降、ブート領域へのアクセス頻度が跳ね上がっているためUSBメモリのような耐久性の低いデバイスだと壊れてしまう可能性があるという。

このあたりの情報は、以前からkawamitsuさんの上記ブログやツイート、VMware DevOps Meetupでの発表を聞いて知っていた。

なので乗り換えるために先日のAmazonブラックフライデーで、ブート用SATA SSDを買ったりもしていたのだ。準備は完璧にできいたのだ。準備だけは。

しかし乗り換えもそれなりに手間がかかるものだし、「動きが怪しくなってきたら移行作業しようかな・・・」程度に考え、ついつい作業を後回しにしていたのだ。

その結果がこれだ。しかもAdvent Calendar予定日の数日前に壊れるという・・・。1台だけならまだどうにかなったんだが・・・。同じモデルのUSBメモリに、同じタイミングでセットアップを行っていたため、故障するのも同じタイミングになってしまったと考えられる。

もし自分と同様にUSBメモリにESXiをインストールしている人がいたら、とにかく早めに乗り換えよう。

f:id:jaco-m:20211224194618j:plain:w300

ということで、生き残った1台も壊れるのは時間の問題と考えられたので、この際vSAN環境含めて一から構築し直すことにした。

Terraformで設定していくぞ

ここからが本題。これまでの自宅ラボでは、vCenterやESXi自体の設定は手動で行っており、VMの作成をTerraformで行っていた。

しかし、Terraformのvsphere providerは、VMの作成だけでなくさまざまな設定を行うことが可能だ。そこで、vCenter周りもTerraformで宣言的に設定出来るようにしてみた。 お察しの通り、Tanzu要素はない・・・ 時間なかったの許して・・・。

ちなみにTanzu x Terraformな要素としては、先日carvel providerがVerified providerとしてリリースされた。そのうち記事にしたい。

https://registry.terraform.io/providers/vmware-tanzu/carvel/latest

TerraformでvCenterを設定する例

今回のコードはこちらのリポジトリにpushしてある。

https://github.com/jacopen/terraform-vsphere-cluster

Datacenter / Clusterの設定

DatacenterとClusterを以下のように定義。ClusterはDRSとHAを有効にしている。ドキュメントだと vsphere_datacenter.datacenter.id を使っているが、 今回は vsphere_datacenter.datacenter.moid を使う。

resource "vsphere_datacenter" "datacenter" {
  name = "Datacenter"
}

resource "vsphere_compute_cluster" "compute_cluster" {
  name          = "Wells"
  datacenter_id = vsphere_datacenter.datacenter.moid
  host_managed  = true

  drs_enabled          = true
  drs_automation_level = "fullyAutomated"

  ha_enabled = true
}

HostをClusterに追加する設定

Hostは vsphere_host リソースで設定可能だ。そのままべた書きしていっても良いが、このリソース以外でも今後ホスト単位に設定したい項目があるので、以下のようなmapを変数として渡せるようにしておき

cluster_hosts = [
  {
    ip           = "10.9.8.152",
    name         = "esxi152",
    user         = "root",
    password     = "<password>",
    thumbprint   = "87:81:f3:24:b7:f1:5d:b5:7c:81:c6:75:af:8e:9c:9d:f4:d2:40:51",
    vsan_nic     = "vmnic2",
    vsan_cidr      = "10.9.13.2/24",
    cplane_nic      = "vmnic1"
  },
  {
    ip           = "10.9.8.153",
    name         = "esxi153",
    user         = "root",
    password     = "<password>",
    thumbprint   = "46:b7:db:60:e6:19:f3:63:00:f8:4c:3b:ae:ed:82:f8:40:56:67:84",
    vsan_nic     = "vmnic0",
    vsan_cidr      = "10.9.13.3/24",
    cplane_nic      = "vmnic1"
  },
  {
    ip           = "10.9.8.155",
    name         = "esxi155",
    user         = "root",
    password     = "<password>",
    thumbprint   = "dd:ae:f0:a1:f7:f6:04:52:d3:9b:16:34:f5:a6:e6:18:0d:d3:5b:8d",
    vsan_nic     = "vmnic1",
    vsan_cidr      = "10.9.13.5/24",
    cplane_nic      = "vmnic2"
  },
]

以下のようにfor_eachで回す

resource "vsphere_host" "cluster_hosts" {
  for_each = { for i in var.cluster_hosts : i.name => i }
  hostname = each.value.ip
  username = each.value.user
  password = each.value.password
  license  = var.licenses.esxi
  cluster    = vsphere_compute_cluster.compute_cluster.id
  thumbprint = each.value.thumbprint
}

thumbprintはESXiにブラウザ等でアクセスして証明書の情報を見る方法や、opensslコマンドを利用する方法が考えられる。 f:id:jaco-m:20211224201131p:plain:w300

openssl s_client -connect <ESXiのIP>:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin

Resource poolやFolderの作成

これは簡単

# Resource Pools
resource "vsphere_resource_pool" "tkg" {
  name                    = "tkg"
  parent_resource_pool_id = vsphere_compute_cluster.compute_cluster.resource_pool_id
}

# Folders
resource "vsphere_folder" "tkg_folder" {
  path          = "tkg"
  type          = "vm"
  datacenter_id = vsphere_datacenter.datacenter.moid
}

vDSやPortGroupの作成

以下のようにvDSを作成。dynamic blockを活用してホストとUplinkに使う物理インターフェースを設定している。ホストによって使いたい物理インターフェースの名前が異なる可能性があるため、Cluster設定時に作った cluster_hosts から値を渡せるようにしてある。

resource "vsphere_distributed_virtual_switch" "vsan_vmotion" {
  name          = "dPlane"
  datacenter_id = vsphere_datacenter.datacenter.moid
  version       = "7.0.2"

  dynamic "host" {
    for_each = { for i in var.cluster_hosts : i.name => i }
    content {
      host_system_id = vsphere_host.cluster_hosts[host.key].id
      devices        = [host.value.vsan_nic]
    }
  }
}

PortGroupを作成。デフォルトではstatic bindingで作られるが、 type = "ephemeral"とすればEpehemralで作成も出来る。また、この例にはないが、 vlan_idでVLANの設定も可能だ。

resource "vsphere_distributed_port_group" "vsan_vmotion" {
  name                            = "vsan-pg"
  distributed_virtual_switch_uuid = vsphere_distributed_virtual_switch.vsan_vmotion.id
  number_of_ports                 = 32
}

ライセンスの設定

以下のようにvariableからvCenter, vSAN, ESXi, Tanzuのライセンスを渡せるようにした

resource "vsphere_license" "vcenter" {
  license_key = var.licenses.vcenter
}

resource "vsphere_license" "vsan" {
  license_key = var.licenses.vsan
}

resource "vsphere_license" "esxi" {
  license_key = var.licenses.esxi
}

resource "vsphere_license" "tanzu" {
  license_key = var.licenses.tanzu
}

Storage周りの設定

vSAN周りの設定も自動化できそうだがまだ行っていない。もしかすると数カ所手動設定が必要な雰囲気もある・・・

以下のようにDatastore Clusterだけ作成しておいた。

resource "vsphere_datastore_cluster" "datastore_cluster" {
  name          = "das_datastore_cluster"
  datacenter_id = vsphere_datacenter.datacenter.moid
  sdrs_enabled  = true
}

設定出来なかったこと

iSCSIのSoftware Adapterの設定は今のところやる方法が見つかっていない。

あとESXiの細かな設定も今のところやる方法がないように見える。

vCenterの設定をTerraformで管理するメリット

変更や追加が多い物、数が多くなるものについてはTerraformの恩恵を受けやすい。例えばVMの作成やディスクの作成などはメリットを感じやすい

一方でvCenterの設定はそれほど頻繁に変更するものではないため、もしかすると「手で設定した方が早い」と感じることもあるかもしれない。

今回設定してみて感じたTerraform化の理由やメリットとしては

  • あまり頻繁に変更しないものだからこそ、コード化する
    • 手で変更を行う場合、きちんと記録を残しておかないと、どういう設定を行ったのか忘れてしまう。今回一から組み直したが、かつて何を設定したか思い出すのが大変だった。Terraformにしておけば、コードを見れば入っている設定が一目瞭然
  • 万が一環境を設定し直しとなってもすぐに戻せる
    • 今回ちゃんとTerraform化したので、次また環境が壊れて修復することになったとしても設定がすぐに戻せる(壊れて欲しくはないけど)
  • いつ誰がどういう設定を変更したのが記録に残る

といったところだろうか。

今回はここまで。Tanzu組み合わせた話はまた後日書けたら書く!