Cloud Penguins

Flying penguins in the cloud.

vExpertになりました

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

blogs.vmware.com

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

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

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