当社はIT技術のオンライン教育を得意としたセミナー専門会社です。

ITエンジニアの技術力UPをお約束します。

Google Cloud Platform 無料枠(Always Free :常時無料)を使ってみた。

Google Cloud Platform 無料枠(Always Free :常時無料)を使ってみた。


GCP(Google Cloud Platform)にはAWSにあるような無償枠の利用12ヶ月と常にある一定の条件下なら無料になるサービス使用枠が存在する。今回はそれを実際に使ってみた。まず一番気になるところは無償枠とはどのような条件なのかだと思う。大前提、無償枠は基本北米のリージョンセンターを選択する必要があります。

Always Freeの条件

GOOGLE COMPUTE ENGINE1 つの非プリエンプティブ f1-micro VM インスタンス
  • オレゴン: us-west1
  • アイオワ: us-central1
  • サウスカロライナ: us-east1
次のリージョンで 5 GB スナップショット ストレージ(期間合計)
  • オレゴン: us-west1
  • アイオワ: us-central1
  • サウスカロライナ: us-east1
  • 台湾: asia-east1
  • ベルギー: europe-west1
1 GB の北米から全リージョン宛ての下りネットワーク(1 か月あたり、中国およびオーストラリアを除く)

日本と北米間のレスポンス

pingでレスポンス測ってみるとやはり177ms前後の遅延はあるね!今回はオハイオ州のus-west1を借りて使ってみました。でも良い方だとおもいます。WEBサーバーを高速サーバにしてhttp2仕様にするとそこそこ表示は早くなると思うので。

実験環境

このサイトはまさにGCPの無料枠で稼働しています。検証ツールで測定した限りだとそれほど遅くないですね。十分な速度が出ています。キャッシュを効かせない初回アクセスでFinishタイム:2.02秒なら悪くないかと。キャッシュをさせると500ミリ秒前後なので希望が持てます。OSはDebian10+nginx+php7.3-fpmを使用しました。 インスタンス作成はAWSより簡単な印象でした。入力は多いですが「多分こう使えばよいだろう!という推測で進めていける感じはGCPの方が数段上ですね。使いやすいと思います。ただし、グーグルさんはプラットフォームビジネスに関しては日本には本気出していない感じはします。無料枠の東京リージョンがないですからねぇ。

タグ: , , , , ,

GoogleのreCAPTCHAのバージョンがVersion3になってチェックが不要に。


私ごとで恐縮ですが、たまたまフランスからコンタクトフォームからスパム投稿があった。
なんだろう?なぜだろう?と思いながらホームーページを調べていたら設定していたはずのGoogleのreCAPTCHAは効かなくなっている。



どうしてだろう?と思い調べてみるとContactForm7の最新版プラグインはreCAPTCHAのバージョンが上がっており、プラグインを更新した際に 以前のreCAPTCHA(v2)が使えなくなっていた。つまりreCAPTCHA(v3)を使いなさいということです。



どうやら再度、新規登録をGoogleのreCaptcha登録サイトで行わないと利用できない。そこで登録した際の「サイトキー」と 「シークレットキー」が発行されるのでそれをContactForm7に登録しないといけないようになっている。

またGoogleのreCaptcha登録サイトで案内されてるJavascriptの埋め込みコードを自サイトへ2種類登録する必要がある。 コンタクトフォーム7で作成したそれぞれのプロファイルの入力HTMLコードの先頭に埋め込んでおけば良いだろう。下記の様なものを埋め込む。



実は、もう一つ盲点があってContactForm7にGoogleのreCaptchaのチェック画像が以前はあったと思うが、今回のリリースで不要になった。 そのためreCaptcha(v2)で使っていたContactForm7の埋め込みタグは不要になりました。 知らずに、どうやったらreCaptcha(v3)が使えるのか1時間ほど悩んでしまった。そのかわり右下にGooglenoの安全マークアイコンが出るように なりました。

タグ: , , ,

Google Analysticsと他WEB解析ツールでの統計差異を考察してわかったこと


複数のWEB解析ツールでサマリーの統計情報として基本的なPVや訪問数、滞在時間、直帰率がツールの種類で大きく異なっているケースが多い。これを調べてわかったことはGoogleはよくも悪くもすべての母数で平均値をとっている。それに対してGoogle以外の解析ツールはもう少し高度な事をしていることがわかった。つまり集計に値しないものは母数に入れていない。言い換えると人間目線のマーケティング思考で集計されている。

例えば、平均滞在時間があったとしよう。この中には(not set)等の怪しいリファラーSPAMが大部分占めている可能性がある。202レスポンスで戻ってくるDoS攻撃もあるだろう。どうやらこのような怪しい(not set)を積極的に統計情報の中に取り込んで統計除外対象に組み込んでいるのが読み取れる。

気づいたきっかけ

セキュリティ攻撃を受けている時の統計グラフの数字の差異がGoogle Analysticsと他WEB解析ツールとの差が激しく出たからだ。こう考えると、改めてWEB解析ツールは複数使う必要があると感じたし、どこを比較して見たらより正確な状態をつかめるかも理解できた。実勢にあっていないところもあるがやはり全体像を掴むためGoogle Analysticsの素の情報も必要だと感じる。

キーワードに出てくる分かりにくい表記を理解してより正確な実態像をつかもう

  • (not set) キーワード計測不能な状態のケース(URL直アクセス、リダイレクト、ブラウザ起動時のタブオープン、他の検索エンジン、たまたまタイミング的に拾えなかった、攻撃によるもの)
  • (not provided) 殆どは検索エンジンがhttpsで暗号化されているのが常だからキーワードがわからない状態です。GoogleならGoogleSearchConsole連動で明確にできますが他エンジンは連携していないので不明となります。
  • (other) Googleが一日のディメンジョンに格納できる量が限られているため、それを超えたものはotherで集計される。
  • (content targeting) Adsense埋め込みの場合
  • (remarketing / content targeting) AdSense広告由来のアクセスで、リマーケティングによる表示からのアクセス

タグ: , ,

Google Search Consoleの404エラーに潜む謎とセキュリティアタックの実態


Google Search Consoleの404エラーはSEO上重要なファクターです。Googleは404エラーは評価無視扱いとされ、色々な説がネットで流れていますが結果論から言ってしまうとエラーの割合が多いと順位が確実に下がります。つまり直接理由ではなくて間接的な要因から順位が下がってしまいます。ここには隠された謎があります。というのは通常404エラーは検索結果のリンク表示をクリックしたときに「ファイルがありません」というものを表すのですが、実はそれだけでは無いのです。ここをじっくり見ると攻撃の跡が見られます。つまり、隠されたページやバグを見つけようとして、あの手この手で存在していないURLを作り出してアクセスしてきていることがわかります。GSの管理画面でクロール>クロールエラー>URLエラーの項目を是非チェックして見てください。おかしいなと思うURLがあるはずです。ほぼそれが攻撃の形跡だと思います。

404エラーは一見すると無害のように思えて、有害の場合もある。

先に述べたように有りもしないページは勝手にアタックさせておけばと考えるのですが、意外と短い時間で連続アクセスされるとサイトによっては重くなる要因です。ページが重くなったら機会損失ですし、今は表示速度は評価の一つです。その他404エラーは間接的に色々なファクターを持っており、Googleがインデックスを刷新するタイミングを作る意味もあります。いい意味でコンテンツの切り替えがあって404エラーになってしまう場合もあります。これは健全な404エラーで全く問題ないのですが、ここにさらにページの生存期間が加わってくるとややこしいことに。

1ヶ月程度でネタが更新されてゆくサイトはページのURLが変わってしまうと損。

ページがきちんとGoogleに認識するまでの期間は意外と時間がかかります。私の感覚では更新ページが少なければ1日、2日で認識されるのもありますがページ数が多いと2週間から1ヶ月弱までかかる場合も多い。それで1ヶ月程度でネタが更新されてゆくともうお分かりでしょうが認識されず生涯を終えるページもあるわけです。

評価してもらうにはできるだけ長くインデックスにエージングしてもらう構造が必要。

つまり新しい記事ネタでもページURLは変わらずページBODYのみ定期的にダイナミックに変わるものが最も有利な構造と言えます。最初からデータベースでBODYコンテンツをダイナミックに作ればよいのでしょうが、図体のでかいサイトは簡単に変更できません。今はスクレイピングの技術やJavascriptの技術があるから置換したり局所的にはめ込みを更新するのは簡単なことです。私は実験で自分自身が持っている幾つかのサイトを完全ファイル構造を変えて刷新することをやってみましたがやはり全てのGoogle検索サーバが完全同期するまでには半年以上かかりました。その間は何度もGoogle Search Consoleの中で重複や404エラーの先祖返り評価を表示されることがあり、改めてGoogleの検索サーバの同期はものすごい時間がかかるので、ディレクトリ構造やファイル名をあんちょこにコロコロ変えるのは得策ではないとわかりました。

404エラーはゼロになる必要はないが、定期的にエラーをチェックしエラーの原因を掴みましょう

エラーはサイトの健康のバロメータであることはわかったかと思います。エラーが少ないにこしたことはありません。多いということはそれだけ無駄が潜んでいたり、セキュリティアタックを受けてたりと色々なことがわかります。セキュリティアタックなら攻撃パターンが分かれば対処は難しくありません。意外なところで便利な404エラーですね!皆さんも要チェック!

タグ: , , , , ,

Google検索のスマホでの検索結果でページャ表示が消えた!


Googleがまた検索エンジンの表示について新しい仕様に変えました。



今までは検索結果をページャで下部に1,2,34,…..というように表示していましたがダイナミックローディング方式に変わりました。Twitterや最近のニュースフィードアプリが採用しているスクロールしてゆくたびに記事を規定単位の数を再読込する方法です。



この方式に変わり検索結果の下部の仕様が大幅に変わりました。



広告掲載が上位のところは、以前よりも更に効果があがる一方、掲載順位が低いところは厳しくなるように思えます。



というのはページャの良いところはページの数字がみえるとユーザ的には見通しがたてられてアクセスします。しかしダイナミックローディングになると見通しがつかないため「もっと見る」をタップする機会が減るように思えます。下位の広告枠が見られる機会が減るような感じがしました。



面白いのは、検索候補ワードがずらりと並んでいることです。頻度の高い検索ワードを並べているのだと思いますがSEOの観点だと逆にこのワードで上位表示を狙うように努力、改善するというシチューエーションが増えることでしょう。



Googleさん的には、まだ試行の段階かもしれませんが大きな仕様変更はないのかもしれませんね。改善するとしたら下位の広告枠の表示機会が少なくならないようになにか工夫するのかもしれません。

タグ: , , ,

1 2 3 4