Googleが千葉ニュータウンにデータセンターを作るらしい。
タグ: Google (1ページ目 (2ページ中))
Googleで「スピードテスト」を検索したら、いつの間にかGoogleがネットワークの帯域幅を測定する機能を実装していたようで。GoogleとMeasurement Lab（M-Lab）の提携で実現しているようだ。40MB程度のようだけど、ある程度のサイズのデータをサーバーとやりとりして計測するのは、他の計測サービスと同じのようだ。ま、他のサービスだと、flashが必須だったりするけど、このGoogleのサービスはflash不要らしい。手軽に計れていいな、と。
nginxのログを眺めていたら、GooglebotとウチのサーバとのTLSの暗号方式に「ECDHE-RSA-CHACHA20-POLY1305」を使ったみたいだった。記憶が怪しいけれど、ChromeではChaCha20-Poly1305を使えるようになっていたけれど、googlebotはまだ対応してなかったような気がしていたんだけどな。
GoogleBookmarksにとあるサイトのURLを入れていて、アクセスしようとしたらリダイレクトの嵐…。うーむ、Googleにはログインしてあるのになんか変だなー。
めまぐるしく、くるくる変わるURLを眺めていると、sidというパラメータをどうにかしようとしているようで…。というわけで、ブラウザのCookieの管理画面を引っ張り出して、google.comのCookieの中で「SID」ってパラメータがあったので、それを削除。改めて、Google Bookmarksにアクセスすると無事にアクセスできた。なんとなーくバグっぽい動きをしているあたり、最近のGoogleでは珍しい気もするけど、とりあえず回避できたからいいや。
ちょっと前、GoogleがPublic DNSに加えて、Google Public NTPをリリースしていた。しばらくの間はtime1.google.com
などはstratum2のサーバとして動いていたと思うが、さっき確認したら、stratum1のサーバ群になってた。
日本国内のLinuxマシンから、time4.google.comを指定してntpdを動かした時の、ntpq -pの結果がこんな感じ。
remote refid st t when poll reach delay offset jitter
==============================================================================
time4.google.co .GOOG. 1 u 5 64 1 35.928 -0.607 0.000
ソースの「.GOOG.」ってなんだろうって感じではあるが、一応、stratum1らしい。ネットワークのdelay的には、台湾あたりのサーバっぽいなという感じだけど、はてさて。
Googleからメールが来ていた。
On October 12, 2016 we will begin enforcing the Google Maps APIs Standard Plan policy updates that were announced in June. Starting October 12th, your website will generate charges if requesting more than 25,000 daily map loads for an API.
雑に訳すと、こんな感じだろうか。
2016年の10月12日から、Google Maps API Standard Planのポリシーの更新を強制します。この更新自体は6月にアナウンスしたものです。10月12日以降は、1日あたり25,000回を越えたリクエストについては課金されます。
というわけで、一日あたり25,000回を越えたAPIの呼び出しについては、1000回あたり$0.5の課金が行われるようですな。…というか、これを強制するってコトは、APIキーを付けていない呼び出しはブロックされるってことだろうなぁ。Googleが細かい制御をどこまでやるかはわからないけれど、APIの呼び出し回数は無料の範囲内で収まっていても、APIキーを貼ってなくて、GoogleMapが表示されないってことが普通に起こりそうな予感…(遠い目)
仕事でさくらインターネットのレンタルサーバを使っている。それも、メールサーバとして使っていて、POPでメールを取りに行くし、SMTPでメールを送っている。ただ、さくらインターネットのレンタルサーバのサービスとして用意されているWebメールは使い勝手がいまいちなので、Gmailと連携させて使っていて、特に、Gmailからメールを送る際には、借りているさくらインターネットのサーバを経由して送信する設定にしていた。
んで、昨日。社内から「Gmailからメールを送れない」という調査依頼がやってきた。昨日まで、普通にGmailからさくらインターネットのレンタルサーバ経由でメールを遅れていたのに、突然、メールが送れなくなったらしい。Gmailに帰って来たエラーメッセージはこんな感じ。
The error that the other server returned was:
550 5.7.1 <XXXX.XXXX.co.jp(送信先のメールアドレス)>… Command rejected
…Command rejectedって…。レンタルサーバのコントロールパネルから調べてみたら、「国外IPアドレスフィルタ」って設定項目が増えていて、それがOnになっていることに気がついた。要は、国外のIPアドレスをブロックする新機能が追加され、デフォルトでOnらしい。
で、「国外IPアドレスフィルタ」について調べてみたら、SMTPも対象になっているらしいので、とりあえず、Offにしたら、正常な状態に復旧した。
つまり、Gmailのサーバがどこにあるかはよくわからないとしても、国内にはない可能性が高く、この「国外IPアドレスフィルタ」に引っかかっていたようだ。
さくらインターネットが海外からのDDoSに悩まされている雰囲気はあって、ユーザーとして協力したい気もするけど、こういう形で影響が出るとなると、ユーザーとしてはOffにせざるを得ない…うーむ。
Googleのdeveloper向けのページでは、ばっちりとサポート終了って書いてあったけど、日本時間の2013年11月18日には終わらなかったように見えた、GoogleMaps API v2だけど、11月20日になって思い出したように終了したっぽい。GoogleMaps API v2で書かれた地図をそのままにしてあったページで地図の部分が真っ白になっているのを確認できた。
一応、Googleとしては
この日以降は V2 を使っている地図は、下位互換機能を持たせた V3 の地図に自動的に切り替わる予定です。この下位互換機能により、大部分のシンプルな地図は機能すると考えますが、この日以前に V3 へ移行を完了することを強く推奨いたします
って書いてはあったけど、シンプルな地図ってどういうものか書かれていないので、妙な期待感を漂わせてしまったような気がする。んで、結果的には、今日になって地図部分が真っ白になっているサイトを増やしているんじゃないだろうか。…まぁ、Googleが責められる話ではないけれど。
タダでAPIを使えて、簡単に地図をWebサイトに貼り付けられるってことでGoogleMap APIを使ったWebサイトは数あれど、このv2のEOLに際して、ちゃんと改修できたサイトってどれくらいあるんだろう。
まぁ、Web系の会社がやるとしても、カットオーバーから何年も経ったサイトのGoogleMapのAPI移行なんて、ほいほいと受けるんだろうか。(さらには、その制作会社が存続しているんだろうかというシビアな話もあるだろうけど)おそらくは割増料金になってしまうんだろうし、顧客によっては今日、明日になって「あ、地図が出てない！」ってことに気がつくところから始まるところも少なくないだろうし。
いかに便利で手軽で無料であるとはいえ、Webサイトの構成要素の継続性をコントロールできないのであれば、それを前提にメンテナンス性を確保する仕組みを作っておくしかないという当たり前なことを、改めてGoogleMap API v2のEOLが気づかせてくれたような気がする。金を払う必要もなく、手もかからないような魔法みたいな仕組みは、あり得ないってことだろう。
Google Readerが7月でサービスを終了するらしい。最近、PulseをフロントエンドにしてGoogle Readerを使ってたのに、ここに来てのサービス終了は本当に残念な気がする。
そういえば、iGoogleもサービス終了だったなぁ。Google Readerよりも猶予期間が長いのは、iGoogleの方がユーザーが多いってことだろうか。
iGoogleにしても、Google Readerにしても、ユーザーは(グローバルで見ても)それなりにいるような印象だが、バッサリと切るのは、さすがGoogleという印象は少なからずあるような気がする。
いずれのサービスとも、それ単体でAdSenseを張り付けまくるという感じでもなかったことから、広告スペースの創出による利益と言うよりは、もっと儲けられる可能性のあるサービスをアシストするような、サポートサービスとしての印象の方が強い。
例えば、iGoogleはgmailと組み合わせて使うと便利だし、Google Readerは、blog黎明期にはPVを稼ぐことができただろうし、その後、SNSが流行った頃には初期のGoogle+において、コンテンツの投入元としての機能を期待されたかもしれない。
いずれにせよ、時代はスマートフォンだ。人々がgmailをチェックするのも、SNSにアクセスするのもスマートフォンから行うようになった。コンテンツ間の関係は、スマートフォンアプリの関係で代替され、確かに、上記のようなサポートコンテンツは役割を終えた感はある。
ただ、そんなGoogleの思惑とは別に、使う側は使う側の論理で動いている。
例えば、スマートフォン全盛期でも、bloggerは、相変わらず、blogを書いているわけだから、エントリーを効率よく読みたい人たちがいる。しかも、只でさえスマートフォンユーザーはバッテリーで悩む機会が少なくないわけだから、スマートフォン単体でRSSを定期的に取得するというのは賢明ではない。RSSを定期的に取得してAPIを公開してくれる、Google Readerには一定の価値がありそうだ。だからといって、例えば、Google Readerを有料化して採算ラインに乗るかどうかと、ユーザーの思いとは必ずしもマッチしないわけだから、なかなか悩ましい。
新しいドメインを取得して、EC2にサイトを設置したけれど、固定IPを持った社内からしかアクセスできないようにSecurity Groupを設定していた。で、公開する必要が出てきたので、Security Groupの設定を変えてインターネットからアクセスできるようにしてみた。そして、ICSなAndroidのChromeからアクセスして、フツーにアクセスできることを確認(ま、社内からのアクセスで確認できてたので、それを3G回線経由でアクセスしたからってアクセスできるに決まっているけれど)してみたら、興味深いことが起こった。
偶然そうなった可能性もあるにはあるものの、AndroidのChromeから新しいドメインにアクセスした後、1分も経たないくらいのタイミングでGooglebotがやってきて、robots.txtを持って行った。新しいサイトはサブドメインを持っているので、そのサブドメインにChromeでアクセスする度に、Googlebotがrobots.txtを取りに来る。
Googleが早く新しいサイトを見つけたいと考えているのは確かだとしても、Chromeのアクセス履歴からクローリング対象リストを作っているとすると、、、なかなか興味深い気がするが、実態はどうなんだろう。ただの偶然なんだろうか。