Cloud Penguins

Flying penguins in the cloud.

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

MIro CloudNative Days

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-IPやFortinet、VMwareの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からの公式回答である。

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

MiroにExcelやSpreadSheetをコピペしたときに付箋にならないようにする

Miro Advent Calendar 2021の10日目！ 今回は小ネタ。

7日目のYasumaさんが紹介してくれている便利なTipsと機能はとても参考になるのでぜひ読んでほしい。付箋の整理整頓の機能は知らなかった。便利。

note.com

その中でひとつ気になったのが

第8位「スプレッドシートのカラムをコピーしてボード上でペーストするとカラムが付箋で生成されて便利」

これ、Miroをしばらく使ってみた人が経験するサプライズの中でもトップ3に入る機能だと思っている。それは、いい意味でも悪い意味でも。自分もMiro使い始めたころにこれを経験して、めっちゃ驚いた記憶がある。

スプレッドシートをコピペすると何が起こる？

改めて解説しよう。たとえば以下のようなスプレッドシートがあったとする。

f:id:jaco-m:20211210010753p:plain:w300

これをMiroにコピペすると何が起こるか。

f:id:jaco-m:20211210010931p:plain:w300

うわぁ

事前情報なしにこの挙動を目の当たりにすると、結構びっくりする。 Tipsで挙げられているように、確かに便利なケースもあるといえばあるのだが…スプレッドシートをコピペする人は、どっちかというと表をそのまま貼ってくれることを期待しているほうが多いんじゃなかろうか。

こんな感じで。

f:id:jaco-m:20211210011606p:plain:w300

Spreadsheetをテーブルとして貼り付けるには

上に貼ったイメージ図のように、テーブルとしてMiroに貼り付けたい場合。 先に空のテーブルを作っておきに、そこにコピペすると良い。

左のメニューからTablesを選択して

f:id:jaco-m:20211210011820p:plain:w300

空のテーブルを作成。行や列の数をコピペ元と合わせておく必要はない。デフォルトの3x3とかでいい。

f:id:jaco-m:20211210011848p:plain:w300

セルを選択して…

f:id:jaco-m:20211210011956p:plain:w300

スプシからコピペ。このように、ちゃんとテーブルとして貼り付けされる。

f:id:jaco-m:20211210012023p:plain:w300

行や列の高さは調整されないので、そこは手でいい感じに修正しよう。

f:id:jaco-m:20211210012223p:plain:w300

なんでもかんでも付箋紙だけじゃなくて、たまには表を使ってビジネスっぽいディスカッションもしたいんじゃい、という場合にはぜひ活用してほしい。

Vimeoで200万円請求話はミスリードなので騙されない方が良い

こういうツイートが話題になっていた。千葉県佐倉市のSound Stream sakuraというライブハウスのようだ。

要約すると、Vimeoから突然200万円請求され支払わざるを得なくなったということだ。

この文面だけ見ると、『なんていう酷いサービスなんだ、許せない！』と感じてしまうだろう。 しかしこれはフェアではない。自分の視点から見ると、Vimeo側に非は殆ど無く、むしろこのツイート主が宣伝目的で炎上させているように感じる。

何故そう言い切れるかというと、自分も全く同じ通知を受け取っているからだ。

TL;DR

  • 使いすぎてもVimeoから突然200万円追加請求されることはない。段階を踏んだ警告が行われる
  • 件のツイートは嘘を言っているわけではないが、恣意的な編集が行われている
  • ビジネスモデルが異なるYouTube Liveと比べるのは無意味
  • Vimeoの価格は決して高い部類ではなく、むしろ安い

Vimeoから使いすぎメールが来る

自分がCo-Chairとして関わっている技術カンファレンスでも、つい先日まで配信プラットフォームとしてVimeoを利用していた。しかし直近のイベントではAWS IVSに切り替えた。何故そうしたかというと、以下のようなメールがVimeoから届いたからだ。

To Whom It May Concern,

I'm reaching out as your account was flagged for heavy bandwidth usage in which consumption was within the Top 1% of bandwidth-consuming accounts and is subject to Vimeo's Fair Use Policy. I have included the term below.

Unlimited Bandwidth Fair Use Policy: Generally, we do not limit or impose additional fees for bandwidth consumption on Self-Serve accounts (i.e. the data used in order to deliver your videos to viewers). However, this policy is subject to fair use: 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, charge fees for excessive usage, require you to upgrade to a more suitable plan, or terminate your account(s) upon advance written notice. For more information on bandwidth and our fair use policy, please see our Bandwidth on Vimeo article.

If you would like to continue streaming at your current levels you would be required to upgrade to an Enterprise or Custom plan which is priced based on the amount of bandwidth needed.

your account was flagged for heavy bandwidth usage in which consumption was within the Top 1% of bandwidth-consuming accounts ということで、上位1%に入りましたよと。件のツイートと一緒。ただ、 おめでとうございます！ なんて表記は一言もない。この時点で脚色されている･･･

めんどくさいので以下DeepL翻訳そのままぶっ込み

一般的に、当社はセルフサービスアカウントの帯域幅消費（お客様のビデオを視聴者に配信するために使用されるデータ）を制限したり、追加料金を課したりしません。ただし、このポリシーはフェアユースの対象となります。お客様が管理するすべてのアカウントの帯域幅使用量の合計が、いずれかの暦月において、当社プラットフォーム上のセルフサービスユーザーの99％を超えた場合、当社は、当社の裁量により、事前に書面で通知した上で、過剰使用に対する料金を請求し、より適切なプランへのアップグレードを要求し、またはお客様のアカウントを解約することができます。 帯域幅とフェアユースポリシーの詳細については、「Bandwidth on Vimeo」の記事をご覧ください。

現在のレベルでストリーミングを継続する場合は、必要な帯域幅に応じて料金が設定されているエンタープライズプランまたはカスタムプランにアップグレードする必要があります。

はい。 追加料金を課したりはしない が、過剰に利用が行われた場合は 事前に書面で通知した上で 、 過剰使用に対する料金を請求し、より適切なプランへのアップグレードを要求し、またはお客様のアカウントを解約することができる。

とある。随分受ける印象が違うんじゃなかろうか。 確かに 上位1%に入ったので過剰利用分を請求する という捉え方が出来ないとは言わないが、かなり恣意的と言えるんじゃないか。 警告を無視して使い続けるユーザーに対する牽制の意味合いが強いと思われる。 いずれにせよ、いきなり請求されることはない。

ちなみにどのくらい使うとこれが来るかというと、FAQに具体的な記載があり、 月あたり2TBから3TBの転送量で上位1%になる。

警告を無視して使い続けると何が起こるの？

数回の警告後、アカウントが凍結される。

自分も初回の警告受けてからすぐに返答が出来なかったが、1週間にわたり細かく返事の催促が来るので返答した結果、凍結はされなかった。

数回の催促メールには、"何月何日までに返事しないと、申し訳ないがアカウントを凍結する" と期日まで書かれていたので、Twitterのように突然凍結されるような理不尽さは全く無く、丁寧にフォローアップしてるんだなと感じたほどだ。

実際に凍結されてしまった例をみるとこうある。

Vimeoアカウントが停止されて焦った話 -この動画は存在しません- – オレンジの国

この例だと、1ヶ月ほど警告が続き、その後アカウント凍結に至ったよう。しかし

ちょうど1か月前にこのようなメールが届いていましたが、普段英語のメールは全てスパムなので読まずに削除していました。

うーん。これはVimeoに非はなく、利用者側の問題だよね･･･。

Vimeo Enterpriseの見積額も年間200万とのことで、件のツイートと同じ。 つまり、同レベルの利用量でもアカウント停止には至ったが、それまでの利用料を遡って請求されたということはない。

同様の事例を十数件聞いているが、やはりいきなり請求されたり、過去の分まで遡及された例は一例もなかった。

で、お前の場合はどうなったの？

自分たちの場合は、年に数回のテクノロジーカンファレンスの利用だったので、そのときだけ転送量がスパイクする。しかし今後しばらくはイベントやらないから大きな負荷はかけないよと返したところ、以下のような返事があり事なきを得た。

First off, a pleasure to meet you via email and I appreciate your feedback! With that being said, I just re-ran your daily bandwidth report and can confirm that your traffic has ceased.

このあとLookerによるサマリーが送られてくるようになり、毎日の正確な転送量が分かるようになった。出来ればこれがサイトから見られれば良かったなとは思うが。

この間、特に不快になるような対応はなく、極めて真っ当なやり取りが行われたと思っている。

じゃあ何故AWS IVSに乗り換えたかというと、金額ではなくAPIの充実度合いや低遅延配信の品質を理由に決めた。見直したきっかけはこの通知だったが、決め手は金額ではない。AWS IVSはこれ単体では解決出来ず、MediaLiveやMediaPackage、S3、CloudFrontを組み合わせてようやくVimeoに近い機能が実現出来るので、それらのコストや開発コストを加味するとむしろ高くなった。

上位1%になるってことはスゴいんじゃないの？

件のメールでは、上位1%に入ったことをむしろ誇るかのような展開になっているが、実はこの上位1%には簡単に達してしまう。

3TBの転送量で上位1%になると書いたが、例えば動画を平均4Mbpsで、月に延べ32時間配信したとすると、平均同時接続数50人 程度で達してしまう。これが誇れる数字かというと･･･？ 物は言いよう ってことだね。

たぶん、自分がこれから毎日1時間、技術トークをするソロライブ配信を行ったとしてもそのくらいは行っちゃいそうだ。

Vimeo Entepriseは転送量や人数などを加味した料金体系になっているようで、年間200万程度の見積もりが来るということは、それよりは多い人数だと思われるが、平均同時接続数で500は下回る規模かなと思われる。

まあ、ピンチをチャンスに変えようという強かさは見習うべきところがあるかもしれないが、他人を下げて自分を上げるやり方はアンフェアではないか。

たったそれだけで200万!? やはりVimeoは悪、YouTube Live最高!

と思うかもしれないが、まあ落ち着け。

まず、動画配信はとてもお金がかかる という認識を持つべきだ。たとえば先ほど3TBの転送量はたった50人で達してしまうと書いたが、たとえばAWSを使って、動画配信関係なく単にインターネットへデータを転送するだけで、 $0.114/GBかかる。3TBだと4万円弱かかる。これに配信システムを動かす金額やCDN(Content Delivery Network)の金額がかかるわけで、動画配信の仕組みを自分で作ったとしても結構お金がかかるのだ。

一方でYouTube Liveは無料で配信が出来る。超人気の配信者だと同時接続数万人になるわけで、この差はなんなの？と思うかもしれない。

しかしこれはVimeoが暴利を貪っているのではなく、YouTubeが慈善事業をやっているのでもなく、単にビジネスモデルの違いだ。

YouTubeは配信者には課金をしていないが、企業からの広告やYouTube Premiumの有料課金、メンバーシップ、スーパーチャットの手数料など、主に視聴者からお金を稼ぐモデルになっている。 スーパーチャットで2億円稼ぐVTuberなどが記事になっているが、そのうち6000万円はYouTubeの取り分になっている。ちなみにスマホでスパチャした場合、さらに3割がAppleやGoogleの取り分で持って行かれる。そりゃぁ、配信者には課金しなくてもいけるよね。 Twitchも同じようなビジネスモデルだ。

3割どころか半分以上持って行くメガプラットフォームのやり方のほうがよっぽどエグいなと感じるが、プラットフォームビジネスとはこういうもの。世の中そういうふうに出来ているので不当だとは思わない。

ともかく、もしも無料でライブ配信をやりたい場合、配信者目線ではYouTube LiveやTwitchを活用するのが最善手だろう。メガプラットフォームのおこぼれに預かれる。

しかし件のツイートに対するリプライを見ると、『YouTube Liveにしましょう、無料ですよ！』なんて意見が沢山付いているが、それは無理だろう。なぜなら、YouTube Liveで有料配信を行うことは規約で禁止されており、BAN対象となるからだ。件のライブハウスはライブを有料配信しており、そういう場合は、Vimeoのような有料の動画配信サービスを使わざるを得ない。 まあ、無料のプラットフォームを使い倒して稼ぐなんていう虫の良い話があるはずもないので、当然だろう。

有料だとしても200万は高い！ Vimeoは暴利を貪っている！

と言いたくなるかもしれないが、その場合はこの言葉を口に出して読んでみよう。高いと思ったら使わなければいい。 他にも有料配信可能なプラットフォームは沢山あるので、探して引っ越せば良いだろう。

では、Vimeoの200万という数字は高いのだろうか。

例えば、ニコニコの有料生放送は、売上代金の14%が手数料としてかかる。 SPWNの場合は8%+220円のようだ(代理店によって異なるかもしれない)

仮に 3000円のライブを、300人に対して、 年間100回開催したと仮定する。すると、年間の売上高は9,000万円だ。 この売上高から、以下の金額をプラットフォームに支払うことになる。Vimeoには課金機能がないため、Tiget Liveというチケット販売サービスを組み合わせて計算してみる。また、Vimeo Enterpriseは利用量に応じて課金額が変わるようなので、今回は仮に200万円としよう。

プラットフォーム 手数料 PFへの支払い
Vimeo + Tiget Live 200万円 + 5% 650万円
ニコニコ生放送 14% 1,260万円
SPWN 8% + 220円 1,380万円

･･･これでもVimeoが高いと言えるだろうか。むしろ圧倒的に安い。自分がこの中で選べと言われたら、Vimeoが第一選択肢になるだろうというほどの価格差だ。件のライブハウスが他に乗り換えずVimeo Enterpriseへの移行をしたということは、このあたりの価格感が分かっていたからではないかと推察されるが、にもかかわらず後ろ足で砂をかける行為は全く感心できない。

なぜこの記事を書こうと思ったか

自分はもうVimeoから乗り換えてしまったので、これを書くことによって得られるメリットというのは特にない。

にも関わらず何故これを纏めたか。それは、コロナ禍により通常のイベントが行えずオンラインによる試行錯誤を余儀なくされた身として、動画配信の業界が健全に育っていくことを強く願っている。

しかし今回のように、自身の宣伝を目的として非のないプラットフォームが不当に貶められる、しかもそれが誤解を含んだまま拡散している様子は、業界の発展に間違いなく悪影響を及ぼしてしまうと考える。

自分のこの記事によって、拡散した誤った情報が訂正されること、そして動画配信サービスに対する公平な認識が広がることを願っている。

あと。

自分を宣伝するんだったら、フェアにやろうや。

おまけ

他の動画配信プラットフォームとの比較

Vimeo (Premium)

Pricing plans | Vimeo Pro, Plus, Business, Premium, Enterprise & OTT

  • ￥7,500/月 (年払いの場合。月ごと払いの場合￥13,500/月)
  • 無制限のライブイベント、ウェビナー。ただしFair use policyのため3TB/月程度で警告が来る
  • これ以上使う場合はEnterprise版。価格はお問い合わせ (今回の場合、それが200万という話だった)

IBM Video Streaming (Platinum)

IBM Video Streaming - 料金体系 - 日本 | IBM

  • かつてのUSTREAM
  • ￥138,500/月
  • HD(720p)まで
  • 20チャンネルまで
  • 総視聴時間合計5,000時間 (同時接続数300, 1回当たり2h, 月8回の配信でこのくらい)
  • これ以上はカスタムプラン。価格はお問い合わせ

た、たか・・・

dacast (Scale)

https://www.dacast.com/live-streaming-pricing-plans/

  • $188/月(年払いの場合。月ごと払いの場合$250/月)
  • 無制限のチャンネル
  • 転送量 年間24TBまで（月あたり2TB）
  • それ以上はカスタムプラン、価格はお問い合わせ

同種のサービスで比較すると、やっぱりVimeoのお得さが際立つ。でも、VimeoがPremiumプランのことをUnlimited live streamingと書いているのは分かりづらいし、実際のところの制限は存在するわけで、FAQだけでなく価格表にも明記して欲しいな。。

しかしかつてのUSTREAMさん、高いな･･･。これには驚いた。

追記

ツイートによると、50TBで50万円程度のプランが提案されることもある様子。3TBで10万円⇒50TBで50万円 と提案されるのであれば、極めて真っ当なんじゃないかな。それが200万円という提案になったということは、それだけ帯域を使っているということだと思うので、それはちゃんと払おうよ

追記の追記

ツイート主から返信があったので一連のやりとりをまとめてみた。結局真相は謎のまま…

togetter.com

追記の追記の追記

Vimeoからの公式回答が得られました。

jaco.udcp.info

2022/3/27 さらに追記

分かりづらかった「上位1％」という基準を「2TB以上消費時」に変更することや、使用帯域についてのアラートが実装されるなどの改善が発表された様子

vimeo.com

gigazine.net