Cloud Penguins

Flying penguins in the cloud.

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

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組み合わせた話はまた後日書けたら書く!

Consul契機でTerraform動かしてネットワーク機器の設定を自動化する

terraform Advent Calendar 2021の22日目!

今日はTerraformとConsulを組み合わせる仕組みによって自動化ができるんだよという話。

Terraformでネットワーク機器の設定!

TerraformをAWSやGCPなどクラウドプロバイダーの設定に利用している人は多いと思うが、それだけでなくネットワーク機器の設定にも利用可能だ。

たとえばCiscoはさまざまなProviderを提供しているし、F5 BIG-IPFortinetVMwareのNSX ALB(AVI)などもVerified Providerがある。

コンピューティングリソースだけでなくネットワークの設定もTerraformで統一できるのは結構便利だと思う。 オンプレ環境でも積極的に活用していきたい。

ちなみに自分は自宅にVMware環境があるので、vSphereもNSX ALBもTerraformで管理している。

余談だがTerraform特集も載っている今月のSoftware Designには、自宅にvSphere環境を作っていく連載企画『はじめよう、おうちクラウド』も載っているので是非読んでね(宣伝)

gihyo.jp

ネットワーク周りのあれこれを実現するConsul

HashiCorpには、Consulというプロダクトもある。

www.consul.io

Consulでやれることは沢山あるのだが、今回の話に関係する機能が "Service Discovery" だ。

f:id:jaco-m:20211221234206p:plain

たとえばapiはどこかとconsulに問い合わせると、該当のIPが返ってくる。

Kubernetesの経験がある人だと、たとえば api という名前のServiceを作ると、 Podから api.namespace.svc.cluster.local を引けば該当ServiceのIPアドレスが得られることを知っているだろう。これがService Discovery。KubernetesにはService Discoveryの仕組みが含まれているのでこういうことが可能になる。これをKubernetesがない世界でも同じようなことを実現したい場合、Consulを使えばいいということになる。

Consulを利用したService Discoveryを使いたい場合、それぞれの環境にConsul Clientを設定することになるのだが、たとえばService DiscoveryではなくLoad Balancerを経由するサービスの場合どうなるか。

f:id:jaco-m:20211221235328p:plain

Load BalancerにはBackendの設定を入れておき、それを元に振り分けて貰う形になるのだが、たとえばその振り分け先情報としてConsulに登録されているアドレスを利用できれば、わざわざLBの設定を手動で変更しなくていいので便利じゃない?と。

ただ世の中のLBにはConsulの情報をそのまま利用できる仕組みは入っていない。じゃあ、Consulの値が変更されるごとにTerraformを叩いて設定を流し込むようにすればいいのでは?

ネットワーク自動化をするConsul-Terraform-Sync

ということで、ConsulとTerraformの連携を可能にするのが、Consul-Terraform-Syncだ。この連携による自動化を、 Network Infrastructure Automation(NIA)と呼んでいる。

ドキュメント: Network Infrastructure Automation | Consul by HashiCorp

仕組みとしてはこんな感じ

f:id:jaco-m:20211222000212p:plain

Consul-Terraform-Syncを立ち上げておくと、それがConsul Clientをチェックしに行き、変更があったらTerraformを叩いて対象のインフラに変更を入れてくれる。

試してみるには

Terraform Registryで "nia" でmoduleを検索すると、Consul-Terraform-Syncで使えるモジュールが色々見つかる。

また、HashiCorp LearnでもA10やPalo Alto Networks、F5 BIG-IPとの連携例がある。

このF5の例だと、環境をAWSに構築しBIG-IP Virtual Editionを自動化している。試すのにいくらか費用はかかるが、さっと立ち上げて試してすぐに消す分には少額でいけるのでCTSを試す用途としては良い。

learn.hashicorp.com

リポジトリはこちら

GitHub - hashicorp/f5-terraform-consul-sd-webinar

このリポジトリの中で特に重要なのがこのConsul-Terraform-Syncに食わせるconfigだ。

driver "terraform" {
  log = true
  required_providers {
    bigip = {
      source = "F5Networks/bigip"
    }
  }
}
#log_level = "trace"
consul {
  address = "${consul}:8500"
}

terraform_provider "bigip" {
  address  = "${addr}:${port}"
  username = "admin"
  password = "${pwd}"
}

task {
  name = "AS3"
  description = "BIG-IP example"
  source = "./bigip-example"
  providers = ["bigip"]
  services = ["nginx"]
}

driver blockで、このConsul-Terraform-Syncによって実行されるサブプロセスを指定する。terraform 以外に、 terraform_cloud が指定可能になっている。

consul blockで接続しに行くconsul agentを指定。

terraform_providerは、その名の通り利用するterraform providerとパラメータを指定する。

そして重要なのがtask blockで、consulの何を元に自動化するかや、実行するterarformのコードが入ったフォルダを指定する。Consulの何をきっかけに動かすかを設定するConditionというものも設定可能で、たとえばConsul上のServiceの状態によってトリガーしたり、Consul KVの中身をみたり、あるはCron記法でスケジュール実行したりという設定が可能だ。上記の例ではデフォルト値を利用しているためconditionの設定が見当たらないが、詳しくはドキュメントを参考にすると良い。

実際に動かす場合の解説をステップバイステップで書いてもよかったが、Learnの内容と特に代わり映えしない感じになるので今回は割愛・・・Learnの通りにやってみて、良い感じにロードバランシングの設定が入ることを試して欲しい。

あと実際に動かした様子をHashiCorpのYouTubeチャンネルで公開しているので、気になる人はこちらも見てみるといいかも(録画に問題があったようでカックカク・・・)

www.youtube.com

Vimeoから突然の請求に関する公式回答(最終)

先週お騒がせしたこちらの件。

jaco.udcp.info

元々のツイートに疑義があることは↑の記事を読んで頂くと分かると思う。

これに対して突っ込んだ質問をしてみたところ、当事者からは以下のような回答があった。

ただし、その証左となる情報を出して貰うことは出来なかった。その後のグダグダは以下の通り。

Vimeoから突然200万円請求された話の真相は? - Togetter

Vimeoからの正式回答

この件に関して、Vimeoに直接問い合わせを行っており、回答を得られたので共有する。 個人情報を除いて原文のまま貼り付けている。訳は筆者

■ こちらからの問い合わせ

Hello

I'm currently using your Vimeo Premium plan. Yesterday, I noticed one of your customer complaining about unexpected billing.

https://twitter.com/sound_sakura/status/1467770205913096192 https://twitter.com/SoundNoguchi/status/1468690109520551936

I read your terms of service and fair use policy. https://vimeo.com/terms

If I understand correctly, you will notice us in advance requiring upgrade plan or charging fees.

But hey said they were suddenly required from you to pay retroactivity share of past bandwidth overutilization. I'm not sure that's true or fake, but I have huge concerned about this rumor because we are using same plan.

Could you confirm if this is true?

訳:

こんにちは Vimeoのプレミアムプランを利用しています。昨日、あなたのユーザーの一人が予期しない請求を行われたと訴えていることに気づきました。 https://twitter.com/sound_sakura/status/1467770205913096192 https://twitter.com/SoundNoguchi/status/1468690109520551936

利用規約とフェアユースポリシーは確認済みです https://vimeo.com/terms 私の理解が正しければ、アップグレードプランや料金の請求は事前に通知されると思っています。 しかし彼らによると、突然、過去の帯域超過分を遡及して支払いを要求されたとのことです。嘘か本当か私には判断が付かないのですが、私も同じプランを使っているので、この噂にはとても不安を抱いてしまいます。

この件について確認してもらえますか?

■ 一次回答。回答してくれた担当の方の名前はこちらで伏せた。太字は原文ママ。

Hi there,

Thanks for reaching out about bandwidth usage on Vimeo! While I cannot speak about, confirm, or deny the details of another user's account, I'm happy to share some more information about our policy. In short, we're happy to provide users with unlimited bandwidth for standard use of our embeddable video player for all accounts that are below the 99th percentile of bandwidth usage. You can find more information about this in our Terms, as well as in our Help Center here.

Please note, however, that should a user's bandwidth usage consistently reach the 99th percentile range, typically starting around 2-3TB per month, Vimeo reserves the right to charge for the excessive use of bandwidth. This means that if your aggregate bandwidth usage (across all accounts you control) is higher than 99% of Self-Serve users on our platform in any calendar month, we may, in our discretion, require additional fees and/or a custom solution for your bandwidth needs. Should this be the case, you can rest assured knowing that someone from our Sales Team will reach out to you directly about your bandwidth usage and your options before any sort of action is taken.

Please let us know if you have any more questions!

訳:

Vimeoの帯域幅使用についてお問い合わせいただきありがとうございます。私は他のユーザーのアカウントの詳細について話すことも、確認することも、否定することもできませんが、当社のポリシーについていくつかの情報をお伝えしたいと思います。要するに、帯域幅の使用率が99%以下のすべてのアカウントに対して、埋め込み式ビデオプレーヤーの標準的な使用に対して、ユーザーに無制限の帯域幅を提供しています。これに関する詳細な情報は、利用規約とヘルプセンターでご覧いただけます。

ただし、ユーザーの帯域幅使用量が常に99パーセンタイルの範囲に達している場合(通常は月に2~3TB程度)、Vimeoは帯域幅の過剰使用に対して課金する権利を有しますのでご注意ください。つまり、(お客様が管理するすべてのアカウントの)お客様の合計帯域幅使用量が、いずれかの暦月において、当社プラットフォーム上のセルフサービスユーザーの99%を超えた場合、当社は、当社の裁量により、お客様の帯域幅ニーズに対する追加料金および/またはカスタムソリューションを要求することができます。 このような場合には、何らかの措置を講じる前に、当社の営業チームの担当者が、お客様の帯域幅の使用状況と選択肢について直接ご連絡いたしますので、ご安心ください。

ご不明な点がございましたら、お気軽にお問い合わせください。

他のユーザーの情報については何も言えないが、あくまでもVimeoのポリシーはこうなっているという回答。まあ、真っ当な回答かなと思う。

ポリシーについては利用規約やFAQに記載されている情報と差異はなく、新たに得られる情報はなかった。だが、事前通知無く請求することはないと太字で強調されたのは、Vimeo側の主張が込められていると個人的には感じている。

ただまだ疑問点があったので、以下のように再問い合わせ

Hello <担当者名>,

I'm Kazuto who maintains this account.

Thank you for the information. I'm relieved to hear that you will reach out to us before any action.

To be clarified, I would like to ask a few more details. Will you bill for excess usage in past months? For example, if I used 5TB in August, 4TB in September, and 5TB in October, it means I used a total of 5TB bandwidth in excess. Will I be charged retroactively for this excess usage?

訳:

こんにちは。このアカウントを管理しているKazutoです。

情報ありがとうございます。何らしかのアクションを行う前にご連絡を頂けるとのことで、安心しました。

確認のため、もう少し質問させてください。 過去の過剰利用分について、請求は行われますか? 例えば、8月に5TB、9月に4TB、10月に5TBを利用していた場合、計5TB分が過剰利用ということになります。 この過剰利用分について、遡及して請求は行われますか?

これに対する回答:

Hi Kazuto,

Thank you for following up. We do not bill for past bandwidth usage retroactively. When you have consistent high bandwidth usage, our Sales Team will reach out to you to draw up a custom annual contract with pricing based on your needs and future bandwidth projections.

訳:

こんにちは、Kazutoさん。

お問い合わせいただきありがとうございます。当社では、過去の帯域幅使用量をさかのぼって請求することはありません。帯域幅の使用量が継続的に多い場合は、お客様のニーズと将来の帯域幅予測に基づいて価格設定したカスタム年間契約を作成するために、当社のセールスチームが連絡を取ります。

まとめ

Twitterでのやりとりで「高圧的」とか「聞き方が悪い」 とか言われてしまった(し、確かにその通りだと思う) ので、今回は私見は挟まず事実のみを述べる。

  • 事前通知無く突然請求することはない
  • 過去の過剰利用分について、遡及して請求することはない

というのが、Vimeoからの公式回答である。

今回の件は、これで全て決着したと思う。