Google Domains停止の影響

経緯

Google Domainsが新規ドメインの登録を停止し提供終了したのが2023年、それまでGoogle Domainsが管理していたドメインはそのまま放置していればSquarespaceに移管されます。

特にSquarespaceに不満があるわけでもないのですが移管後は価格が高くなるという話もあり、カスタムドメインの更新期限を迎える機会に日本のレジストラに移管することにしました。

それに伴っていろいろとトラブルが発生したので、今回はそれについてです。

まずはドメイン登録事業者の選択

ドメイン登録事業者によって結構価格が異なるので一応比較しました。事業者の比較記事はたくさんあるのでここでは比較の結果は載せませんが、気づいたのは以下。

• 海外の事業者は今回は比較することなく選外。
• 売り込みDMがうざいと悪評高い お名前.com も選外。
• GMOはなんで3つもあるの???
• さくらインターネットは高い。
• 知名度あまりない会社も多い。

トラブル1

最初に選んだのは ValueDomainです。webサイトからユーザ登録してドメイン移管の依頼をしてしばらく待つだけです。

しかし1週間たっても全く何の連絡もなく、移管の作業が進んでいる気配もありません。しかしクレジットカード決済だけは支払い済みという、嫌な状況に... サポートに問い合わせしてみると「移管の手続きがされた形跡がない」「すでに決済済み」という状況であるとの回答がありました。

状況が詐欺と同じです。何のためのクレジットカード決済でしょうね、信用できません。

すぐに移管も請求もキャンセルの旨連絡を入れると、「キャンセルの際はポイントで還元」とか意味不明な回答。「返金で対応して」と要求して、なんとかなかったことに。

トラブル2

最初のトラブルに比べればずっと小さい小さいトラブルですが。

しかし返金がなかなか確認できません。これはクレジットカード会社のwebサイトに反映されるまでに1週間もかかることが原因です。そんなに反映遅いって、いつの時代の仕組みを使いまわしているんでしょう。

トラブル3

返金待ちの間にStarDomainにドメイン移管を依頼しました。今度は依頼や決済のトラブルもなく、すなんり依頼完了。

しかし数時間で「移管不可」の回答がありました。理由が明記されていなかったのでサポートに連絡して理由を確認したところ、WHOISで代理公開しているので「登録されたEメールアドレスが確認できない」とのこと。他の事業者ではこのような理由で拒否されたことはないので、これはStarDomain独自の仕様だと思われます。

WHOISの代理公開を停止して待つこと3日、やっと依頼が通過し、Google Domainsから移管の確認メールが来ました。

トラブル4

ここまででドメイン移管までは完了したものの、カスタムドメインが解決できずDNSエラーになるという事象が発生。StarDomainの管理画面にネームサーバやDNSSEC設定の警告が表示されていたのですが、その警告についてマニュアルには記載がありません。サポートに問い合わせてみると、DNSレコードの設定を有効にするために以下の操作が必要とのことでした。

1. DNSSECを解除して (これはサポートに依頼が必要)、
2. ネームサーバをスタードメイン専用に変更し、
3. DNSレコードを設定。

以上は、マニュアルには全く記載がありません。警告から推測はできるものの、こんなのわかるわけがない仕様です。

以上を設定して、やっとカスタムドメインが復活しました。

トラブル5

Looker StudioでSearch Consoleからデータ取得して各ドメインの表示数・クリック数の分析を行っていたのですが、ドメイン移行でデータ取得できなくなりました。Googleのサービス内で連携するからこそ実現できていた機能です。

最後に

カスタムドメイン移管を行ってみて、感じたことをまとめてみます。

• トップレベルドメインによってはGoogle Domainsは意外と安価で高機能だったということです。なぜ事業売却したんだ。結局移管して2割ほどですが、料金は上がりました。
• ValueDomainの運営会社であるGMOインターネットは意外と怪しい企業かもしれません。何らかの関係を持つのは今回が初めてでしたが、詐欺と変わらない状況で実際にお金の請求にまで至ったのは、長いネット利用歴があるにもかかわらず今回が初めてです。
  またお名前.comと同じようにValueDomainもユーザ登録後は毎日のように売り込みのDMが届きます。かまってちゃんなウザい組織です。
• StarDomainの運営会社であるネットオウルは、少しはまともそうです。サポートの対応は遅くはありませんが、若干稚拙な印象があります。webサイトの完成度はあまりいいとは言えません。作りっぱなしという印象で、マニュアル含めて説明が足らなくてわかりにくいことが多く、経験と勘とサポート頼みになります。改善を提案してみたのですが、「対応しません」と全くやる気のない回答が返ってきました
• カスタムドメインは一度取得してしまうとそのまま更新を続けるだけなのが普通なので、あまりドメイン管理事業者のwebサイトを操作することもありません。ドメインの手続きだけではいかにも儲かりそうにない事業です。各事業者のUIや運用の改善、事業としての健全化に関して後回しにされている印象を受けました。

BASICは今年で60才

『「BASIC」誕生60周年--コンピューター利用を容易にしたシンプルな言語の歴史』によると、BASICの誕生から2024年5月で60年だそうです。

BASICは私が最初に学んだ言語でもあり、過去(1980年前後)には一世を風靡した言語でした。それ以前にもCOBOL, FORTRANなどの言語もありましたが、目的とする分野以外では使いにくく、理解も容易でないと感じるような代物でした。それゆえBASICはそれらの言語の目的外の分野で、特に情報処理に入門する人達に受け入れられたように思います。

この当時の一般的なPCのスペックは以下のとおり。

• CPU : バス幅=8ビット、クロック=4MHz
• メモリ : 64kB
• 記録媒体 : データレコーダ(カセットテープ) or フロッピーディスク(容量は320kB程度)
• モニタ : 640×400 (or 480)ピクセル、8色

現在のPCと比べるとゴミ並みにしか見えません... 単純に、バス幅×クロック×メモリ で比較すると...

• 当時 : 8bit×4MHz×64kB=2,048
• 現在 : 32bit×4GHz×16GB=32bit×4096MHz×16,777,216kB=2,199,023,255,552

いったい何を計算しているんだろうという疑問は置いておいて、現在は当時の 1,073,741,824(約10億7300万)倍です。

ここでさらに疑問。現在は当時と比べて10億倍のことができるようになったのでしょうか。そんな感じはしません。それどころかせいぜい10倍程度にしか感じません。それだけ無駄なことにいろいろなリソースを費やしているように感じます。

Cloud Runのインスタンス起動時間

 動機

Cloud Runのドキュメント「実行環境について」については以下の記述があります。

第 2 世代の実行環境は、一般に持続的な負荷の下では迅速に動作しますが、ほとんどのサービスでは、第 1 世代よりもコールド スタート時間が長くなります。

このように書かれると、第1世代／第2世代ともどの程度インスタンスの起動時間がかかるのか、どの程度違うのか気になります。また第2世代のジョブはバックグラウンドで動作するものなので起動時間はあまり気にされるものではありませんが、これも知りたくなってきます。

実行速度は目的によって測定方法も変えることになるので面倒ですが、インスタンスの起動時間については過去の記事「GAEのインスタンス起動時間」「GAEのインスタンス起動時間 #2」と同様に測定できますので測ってみました。

測定方法・条件

今回はCloud Runなので言語やランタイムのバージョンについては、使う人がDockerコンテナを作る際にいいようにすればいいだけの話です。なので純粋にCloud Runのインスタンス起動時間として、Hello World相当のGoでリクエスト→処理開始までを測ることにします。

• リージョン : 大阪
• ネットワーク : NTT Flets光 隼、実効300Mbps程度
• サービス : 
• ブラウザからAjaxでリクエストし、JavaScriptでレスポンスが返るまでの時間を測定。
• スピンアップあり／なしの2パターンで、それぞれ10回測定し、平均値を算出。
• 前記2パターンの差から、インスタンス起動時間を計算。
• ジョブ : 
• GAEからジョブを起動し、GAE/Cloud Runそれぞれに仕込んだログから、インスタンス起動時間を測定。
• スピンアップは毎回行われるのでサービスのような「スピンアップなし」に該当するパターンは無いはず。念のため検証目的で、前回起動から15分以上時間空けてをスピンアップあり相当、前回起動から時間空けずにをスピンアップなし相当として、2パターンでそれぞれ10回測定し、平均値を算出。

測定結果

単位はすべてmsです。測定結果をtableにするのが面倒だったので、今回もExcelのキャプチャ画像です。

スピンアップあり。

スピンアップなし。

そしてインスタンス起動時間。

第1世代	第2世代
service	service	job
158.7	452.5	9344.4

まとめ

Cloud Runの世代間

公式ドキュメントの記載どおり、インスタンス起動時間は第1世代のほうが速いという結果です。

ジョブの起動時間はおおむね10秒程度でした。ちなみにジョブ終了→GAEで終了を検知も、おおむね10秒程度でした。

GAEとの比較

「GAEのインスタンス起動時間 #2」と比較してみるとCloud Runは全体的に遅く、第2世代のサービスだとGAEの素のJavaよりいいくらいになっています。

本稿の趣旨からちょっと外れますが、スピンアップなしのケースではGoだろうがJavaだろうがほぼ確実に100msを切れるGAEに対して、Cloud Runだと3倍程度のレイテンシが発生しています。Webフロントエンド専用のプロダクトとしてgVisorという独自コンテナ技術まで作っただけあって面目躍如といったところで、汎用のDockerコンテナを利用するCloud Runは一歩及びません。

GoのコードはそのままでGAE/Goに実装したRESTful APIを、Cloud Runサービス/Goに変えたところ、ちょっともっさりするようになった気がした経験があります。これは気のせいではなかったと改めて認識しました。

Firebase Hostingには動的コンテンツをCloud Runで配信する機能「Cloud Run を使用した動的コンテンツの配信とマイクロサービスのホスティング」があるのですが、今回の結果を見ると、App Engineにも対応してほしいと思います。