2014-10-24

構造化データを追加したらGoogleさんがいっぱいクロールしてくれた

構造化データってのはschema.orgとかmicrodataとかってやつです。
リッチスニペットと構造化データについて - ウェブマスターツールヘルプ
 schema.org に関するよくある質問 - ウェブマスターツールヘルプ

色々小難しいことが書いてますが、僕は「HTMLに機械が理解出来る意味を持たせる」って言う風に認識してます。

例えば記事があったとして「このHTMLは記事だよー」って教えてあげることが出来ます。

実装

<div class="article">
  <a href="/article/123">
    <h1>記事のタイトル</h1>
  </a>

  <div class="article-body">
    記事の中身
  </div>
</div>

とても簡単ですが、こんな感じの記事があった場合

<div class="article-link"  itemscope itemtype="http://schema.org/Article">
  <a href="/article/123" itemprop="url">
    <h1 itemprop="name">記事のタイトル</h1>
  </a>

  <div class="article-body" itemprop="articleBody">
    記事の中身
  </div>
</div>

こんな感じに追加します。

・itemscopeはスコープを定義します。divで定義しているので、このdivが閉じるまでがスコープです。
・itemtypeは何を表しているかを定義します。"http://schema.org/Article"を指定してるので記事であると言っています。
・itemscopeとitemtypeはセットで定義します。
・itempropはプロパティを定義します。リンクならurl、タイトルならname、記事の本文でアレばarticleBodyなどです。
詳しくはhttp://schema.org/を見てください。

どの位クロールしてくれたか

f:id:ichiy:20141024113444p:plain
定義する前は１日辺り１万ページくらいのクロールだったのが、記事とかリンクとかに構造化データを定義して２日目くらいに９万ページくらいになりました。
Googleさんにいっぱい見られてる・・・しゅごぉい・・・！

実際のページの数は２万ページも無いので、重複でクロールされまくってるわけです。
おすすめ記事とか関連記事とかで同じ記事へのリンクを構造化データで定義してるので当然といえば当然ですが。

この後ずっと毎日９万ページクロールされたのか？というとそんなわけなく、ほぼ元通りに落ち着きました。
f:id:ichiy:20141024121137p:plain

まとめ

実際クロールだけされてもインデックスされなきゃ意味ないんですがね。
僕はサービスを公開してから大分時間が経過した後、構造化データを追加したのでインデックス数などはほぼ変わりませんでした。
ですが、クローラーに「記事だよー」とか「関連リンクだよー」とか教えられるので、SEO的にはいいはずです。Googleさんも推奨してますし。。

何よりオープンしたてのサービスとかで、サイトマップ送ってもクロールしに来てくれないよーみたいな状況では有意かもしれません。

2014-09-29

yum updateしたらtwitteroauthがエラーになる

CentOSでtwitteroauthを利用してる方は注意が必要かも。

これを書いてる時点で最新？のnss (3.16.1-7.el6_5)にアップデートすると、twitteroauthがエラーになります。
twitteroauthに限った話しじゃ無いと思いますが、調べてないのでとりあえず。

経緯

TwitterからAPIで検索するという処理が突然死んでて、原因調査してました。
Twitterの仕様変更か？とか最近話題になったTwiccaが弾かれるなど、色々想像しましたが、
実際にエラーメッセージを取得して見ると全然関係ないエラーが出てました

Problem with the SSL CA cert (path? access rights?)

調べてみるとnssってのが原因らしい。

TwitterのOAuthが動かなくなった件。curl_error()でキャッチすると Problem with the SSL CA cert (path? ...) と出る。これはTwitterの仕様変更ではなく、サーバのnss更新が原因。証明書を更新すると解決する。
— =^_^= まぉー (@iso800cc) 2014, 9月 27

ことの始まりはBashの脆弱性です。
先週末にパッチが公開されてアップデートして安心！！って思ってたんですが、どうもまだ脆弱性が残ってたらしく、再びパッチが出てました。
そんでもっていつもどおり気にせず

# yum update

と、やっていました。

NSSの脆弱性

このアップデートを実行した時に実は別にNSS脆弱性に関するパッチも公開されており、それも一緒にアップデートしたのが原因でした。

cURLを実行するときにCentOSではOpenSSLの代わりにnssを使っているようで、そのせいでアップデートするとエラーになったのでした。

ただ修正方法が分からず、結局このへんを見て yumでアンドゥしました。
しかしこれだと公開済みの脆弱性を思いっきり放置してる状態なので大変危険です。

~~対策方法がわかったら追記します。~~
追記（2014/09/29 17:52）：
とてつもなくあっけないオチですが、アパッチをリスタートしたら大丈夫でした。

一応手順としては

$ sudo yum update

を実行したあと

$ sudo service httpd restart

これだけで正常に動きました。ハイ。

ただ、AWSでエラーが出た状態と同じインスタンスを立ち上げてみたら同じ現象は再現出来ませんでした。
俺の３時間は一体何だったのか・・・。

2014-09-17

ネットワーク初心者が、さくらクラウドからAWSに移行した時のメモ

ネットワーク素人が、さくらクラウドで負荷分散構築した時のメモ１【準備編】 - なりせなるてず

この記事を4月に書いてからたった5ヶ月ですがAWSに半分移行しました。

AWSに移行するきっかけ

嬉しいことに自社サービスが順調に成長してて、アクティブユーザーがだいたい常時300以上、多い時は1500から3000位にまでアクセスが集まるようになったことです。
勿論さくらクラウドでも対応出来るんですが、瞬間的に通常時の5倍から10倍のアクセスを捌きつつ、通常時はサーバーを減らして安く抑えたいという要求を叶えるためにはさくらクラウドじゃムリだろうということになりました。
さくらクラウドはオートスケーリング対応してませんし、今のところその予定もなさそうなのでAWSの出番というわけです。

オートスケールに対応したクラウドサービスはAWS以外にもありますが、まぁAWS一択でしょう。

AWSのお勉強

AWSはオートスケール出来て凄い！くらいの知識しか無かったのでお勉強です

[AWSマイスターシリーズ]Amazon CloudWatch & Auto Scaling from Amazon Web Services Japan

これと

AWS上でのWebアプリケーションデプロイ from Amazon Web Services Japan

自分がしたいと思ってたことはほぼこの2つに概要からやり方まで書いてあり、非常に参考になりました。
ただ、AWSのコンソール画面はしょっちゅう変わってるので、AWSコンソールからオートスケーリングさせる設定は
AWS - 【AutoScalingをManagementConsoleから設定してみる】 - Qiita
こちらを参考にしました。

EC2のインスタンスを作るときにAmazon Linuxを選ぶと、スペックはしょぼいですが1年間無料で使えるプランがあるので色々テストできます。
クラウドサービス無料利用枠 | アマゾンウェブサービス（AWS 日本語）

サーバー構成

先ほどのスライドにありますが、こういう構築にしたほうがいいよ！ってのをほぼ丸パクリして構築しようと考えました。
f:id:ichiy:20140917183229p:plain

オートスケーリングを使う流れとしては、
1.EC2でwebサーバーとして機能するものを作る。起動時に自動で最新のプロジェクトがデプロイする仕組みを作っておく
2.EC2でwebサーバーが出来たら、インスタンスをstopして、AMIを作る
3.ロードバランサーを作る
4.オートスケーリングの設定を作る

こんな感じで作って移行してみたんですが、移行3時間で転送量がめちゃめちゃかかってやばい事が判明。
このまま行くと月額80万位かかる計算でした・・・(ﾟдﾟ;)
冷や汗が止まらなかったです。
急いで転送量がかからないさくらクラウドに画像を置くことにしました。

で、結局最終的にはこういう構築になりました。
f:id:ichiy:20140917183200p:plain

画像をNFSでさくらクラウドのファイルサーバーにアップロードして、画像のURLをさくらクラウド側にしアクセスさせるようにしました。
webサーバーはオートスケーリング出来るAWSを使い、画像は転送量でお金がかからないさくらクラウドにして、両者のいいとこ取りを実現しました。

戸惑ったこと

移行するにあたって色々ハマった事があったのでメモ

RDSはUTC固定

RDSのタイムゾーンはUTC固定で基本的には変更できません。
色々変更する方法はあるっぽいですが、定期メンテナンス時に落ちるとかいう人て怖いのでやってません。

RDSのストレージは追加出来るけど減らすことは出来ない

作ったあとでこんなに容量要らないやと思い容量の変更をしようと思ったのですが、追加することは出来ても削除することは出来ませんでした。

CentOSが色々入ってない

vimとかwgetとか、あと色々サービス群が入ってませんでした。
さくらクラウドのCentOSには初期から色々サービスが入っててすぐ使えるので便利でした。
ただその反面初期から起動してるサービスはそのままにしてると、かなりの確率でDDosなどの踏み台にされるので対応しなければならず面倒です。
当然といえば当然ですが、AWSのCentOSは余計なサービスは入っておらず軽量です。

topコマンドで見れるCPU使用率があてにならない

ApacheBenchで負荷テストをしてる時、同時接続数をいくら増やしても40%位を限度にそれ以上CPU使用率が上がりませんでした。
Amazon EC2 インスタンスの負荷測定 : まだプログラマーですが何か？
こういう理由があるみたいです。

ELBはIPアドレスがない

ELBにはIPアドレスが無く、EIPを使っても設定することが出来ません。
つまりAレコードでDNSを設定することが出来ず、CNAMEしか無理ということです。

不勉強で知らなかったのですが、CNAMEはサブドメインしか指定することが出来ないので、
「www.example.com」みたいなアドレスで良ければいいのですが、「example.com」みたいなURLでアクセスさせることが出来ません。

これを解決するにはRoute53を使うしかありません。よく出来てますね・・・。
営業でも簡単！Route 53の基本設定 « サーバーワークスエンジニアブログ
上記を見て設定しました。

オートスケーリンググループの設定を変えると突然EC2が死ぬことがある

AMIを更新してオートスケーリンググループも変更したりするんですが、それをやると数時間後（タイミングは不明）で突然EC2群が死んで、新しいAMIで立ち上がります。
検索しても出てこない現象なので詳細は不明です。

よく出てくる意味分からなかった単語

AMI

Amazon Machine Imageの略。
インスタンスを作るときのひな形。
ApacheやPHPなど必要なものをインストールしておいて、オートスケーリングするときになどにこのひな形を元にインスタンスを自動追加出来る。

ELB

Elastic Load Balancingの略。
ロードバランサです。ただし普通のロードバランサと違い、ロードバランサ自体がスケールアップ出来る。

EBS

Elastic Block Storeの略。
ストレージのこと。
起動中のEC2にストレージを追加できたりする。

AZ

Availability Zoneの略。
データセンターの中で、電源などが物理的に分かれている場所の事らしいです。
Multi-AZは別々のAZにEC2やRDSを配置することで、天災時などで万が一どちらかの電源が落ちたりしても別のAZにはアクセスでき、耐障害性に優れているということみたいです。

IOPS

I/O per Secondの略。
HDDなどのディスクが1秒間に出来るI/O処理の数のことらしい。
この数値が高いほど性能がいいということ。100IOPSだったら1秒間に100回トランザクション処理が出来る（多分）

さくらクラウド vs AWS

さくらクラウドが有利だと思う点

1. さくらのほうが１インスタンスに対しての費用対スペックがいいです。
例えば社内向けのコミュニケーションツールみたいに、ある程度アクセスする人数やPVがわかっている状態ではさくらクラウドで構築したほうが安上がりになると思います。

2. ドキュメントやコンソールが日本語
AWSのように頻繁にコンソール画面が変わることが無いのでドキュメントやブログで見た情報のまま使えることが多いです

3. 転送量がかからない
標準的なWebサービスをAWSで運用する時、最もお金がかかるのが画像などの転送量だと思います。
ここにお金がかからないのは相当デカイです。

AWSが有利だと思う点

1. セキュリティグループ
これのお陰でiptablesとか書かなくてもいいし、余程変な設定にしない限りセキュリティの穴になることもないのかなぁと思います。

2. オートスケーリング
これがさくらクラウドからAWSに移行した決め手です

3. 起動中のインスタンスにストレージ追加出来る
見積もってたより多くのストレージが必要になった時、サーバーを止めること無くストレージを追加出来るのでサービスに影響なく進められます

4. 圧倒的な多機能
何がなんだか分からないサービスがいっぱいあります

おわりに

移行する前はAWSに移行したら全部解決できるみたいな幻想があったんですが、勿論実際にはそんなことはなく、さくらクラウドのほうが優れている部分も多く、工夫次第でどうにかなるなぁと思いました。

2014-08-27

FuelPHPで全てのコントローラーにフィルタをかける

全部のコントローラーで決まった処理、例えば認証処理とかを行いたい場合、Symfonyみたいな全部のコントローラーにかかるフィルタが欲しいところですが、用意されてないようです（見つけられてないだけかも）

なので今までずっと、それぞれのコントローラーにbefore(),after()メソッドを書いていたんですが公式ドキュメントをちゃんと読んだら解決できました。

ベースコントローラー

コントローラ - 概要 - FuelPHP ドキュメント

<?php
class Controller_Public extends Controller_Template
{
  public function before()
  {
    parent::before();

    // 認証処理などの共通処理を記述
  }

  public function after($response)
  {
    $response = parent::after($response); 

    // アクション実行後に行いたい共通処理を記述
    return $response;
  }
}

こんな感じで共通処理だけを記述したベースとなるコントローラーを作成します。
そして共通処理を行いたいコントローラーに継承させます。

<?php
class Controller_Top extends Controller_Public
{
  public function before()
  {
    parent::before();
  }

  public function after($response)
  {
    $response = parent::after($response); 
    return $response;
  }

  public function action_index()
  {
     // 処理
  }
}

Controller_Publicを継承することで、毎回before()メソッドなどに処理を書かなくてよくなります。
今回はベースコントローラーをController_Templateを継承して作成しましたが、Controller_HybridでやればTemplateもRestも対応できます。

ちゃんとドキュメント読まなきゃダメですね

2014-08-08

FuelPHPで画像圧縮と圧縮率

webページの表示速度を上げるうえで必ずネックになる画像。
圧縮するとどのくらい変わるものなのか調査してみました。

FuelPHPで画像圧縮

いつもどおりFuelPHPです

$filepath = 'image.jpg';
Image::forge(array('quality' => 90))->load($filepath)->output();

Image::forgeメソッドに配列でqualityキーと値を渡します。
qualityが90%になるように？圧縮してくれます。

圧縮率

元画像が307KBでした。
クオリティ90%で110KB
80%で75KB
70%で60KB
60%で51KB
50%で45KB
40%で39KB
30%で33KB
20%で25KB
10%で17KB

と、なりました。
90%の時点で約3分の1にまで小さくなるでの非常に有効ですね。

勿論画像自体も汚くなるのですが、僕の見た限りでは70%くらいまでは余裕で使えるなーという感じでした。
参考画像を上げれなくて申し訳ないです。

圧縮の不思議

JPGは圧縮すると素直に容量も小さくなったのですが、PNGは圧縮すると逆に容量が大きくなりました。
またGIFはほぼ変わりませんでした。

GDのせいなのか、はたまたPNG,GIFのアルゴリズムのせいなのかは分かりません。
webで使われてるのは圧倒的にJPGが多いので、JPGだけ圧縮するようにして対応してます。

という話

技術ブログにしたい