Rails でつくった FeedlyGraph を Sqale から DigitalOcean に移行した

はじめに

以前 Heroku から Sqale に移行した FeedlyGraph を DigitalOcean に移行したので、その経緯や作業を書く。

移行の経緯

Sqale のデプロイが今ひとつ理解しがたく、うまくいかなくなったことがきっかけ。
Sqale のウリはサーバー管理が不要であることで、Rails アプリは git デプロイできるようになっている。
が、ruby のバージョンを変更しようと検証してから、git デプロイがうまく動かなくなった。

その後は毎回手動で bundle install やアプリケーションの起動をしなければならなかった。
しかも bundle install すると、HDD 容量 5GB を超えるために古いバージョンの Gem を手動で消したり・・・といった具合。
これでは PaaS でもなんでもない。

アプリケーションとしての Rails 初心者である僕が、なおさらよくわかっていないインフラ周りをいじるのはしんどい。
加えて Sqale の仕組みを理解する余裕は到底なかった。

Sqale が悪いというわけではない。
正しい使い方をすればうまく動くのだと思う。
ただ自分にはわからなかった。
PaaS 全般に言えることだが、自分で管理もできる人がそのコストを委譲するために利用する、というのが正解なんだと思う。

あとはポジティブな理由がこんなところ

• DigitalOcean を使ってみたかった
• ギョームで使い始めた ansible を使いたかった

移行作業

ざっくり調べて、nginx + unicorn でホスティングするというのがスタンダードなやり方だというのがわかった。
それに沿った ansible の playbook の公開情報を探して、少しずつ試しながら構成を作っていった。
完成したのが以下。

github.com

GitHub で公開しているファイルでは、FeedlyGraph 独自の処理は除外してある。たとえば cron。

大体は hosts をいじれば事足りるはず。

参考資料

playbook 作成にあたって主にお世話になったサイトをまとめておく。

ansible の基本構成

• AnsibleでRailsをデプロイ - 12FF5B8
• 【ansible】ansibleでrails + nginx + postgresqlを構築してみた - のんびりSEの議事録

iptables 周辺

• はじめてでも爆速でCentOS6.6（さくらのVPS）をセキュアにセットアップする方法まとめ - 憂鬱な世界にネコパンチ！

トラブルシューティング

• Nginx で Rails の assets (css, js) にアクセスできない（403 forbidden が返る） - Qiita

検証

ついでに ab でパフォーマンス検証してみた。

以下、 ab -n 2000 -c 100 http://yourhost.com で行った結果。

Sqale

Server Software:        ngx_openresty/1.2.6.6
Requests per second:    46.28 [#/sec] (mean)
Time per request:       2160.926 [ms] (mean)
Time per request:       21.609 [ms] (mean, across all concurrent requests)
Transfer rate:          295.76 [Kbytes/sec] received

DigitalOcean(nginx)

Server Software:        nginx/1.8.0
Requests per second:    120.99 [#/sec] (mean)
Time per request:       826.492 [ms] (mean)
Time per request:       8.265 [ms] (mean, across all concurrent requests)
Transfer rate:          766.74 [Kbytes/sec] received

マシンの性能自体は DigitalOcean に軍配が上がった。

DigitalOcean(WEBrick)

ついでに rails server で起動した場合も試してみた。

Server Software:        WEBrick/1.3.1
Requests per second:    87.30 [#/sec] (mean)
Time per request:       1145.541 [ms] (mean)
Time per request:       11.455 [ms] (mean, across all concurrent requests)
Transfer rate:          554.13 [Kbytes/sec] received

やはり nginx + unicorn のほうがリクエストをさばく能力は高い模様。

まとめ

Sqale は AWS の Tokyo リージョンを利用していると思われるため、レイテンシが有利。
それでも DigitalOcean はシンガポールを選べばそこまで遅いと感じることはなく、日本からの利用にも十分耐えられることがわかった。

また、ansible の playbook を作ったことで、ふと思い返していじるときでも、サーバーの見通しがつきやすくなった。
インフラをコード化するメリットはこういう面でもあると思う。

あとはコスト面。
サーバーの維持費が ¥940/month から $5/month になった。
やはり個人でサーバー持つには Windows はキツイ。Linux 一択だ。

最後にお詫び。
移行作業中に間違って Sqale にデプロイしてしまい、しばらくデータ取得が正しく行われていなかった模様。

利用者の方にはお詫び申し上げます。

入門Ansible

Rebuild.fm のゲスト出演回数ランキングを勝手に公開した

はじめに

僕が技術系 Podcast にハマるきっかけとなった Rebuild.fm 。
（もう広まってるけど）Rebuild.fm をより多くの人に触れてほしくて、ゲスト出演回数ランキングを勝手に公開してみた。

http://rebuildfmranking.herokuapp.com/

つくった感想

まだまだ Ruby も Rails も全然だけど、スクレイピングやキャッシュを学ぶきっかけになった。
前にも書いたけど、学習サイクルの好循環が生まれているなあと思う。

参考にした情報

• Chartkick
• Railsでmemcacheを使ってobjectをキャッシュ - Qiita
• Nokogiri を使った Rubyスクレイピング [初心者向けチュートリアル] - 酒と泪とRubyとRailsと

最後に

僕自身は英語のエピソード9以外は3,4回ずつ聴いているくらいの準ヘビーリスナーで、@naoya_ito さんよく出てるな〜と思ってたらその通りだった。
今後も楽しみに聴かせていただきます。
まだ聴いたことがない人はぜひ。

Rebuild

• Tatsuhiko Miyagawa
• ソフトウェア ハウトゥ
• ¥0
• 

追記（2014/12/16）公式にゲスト別のページができて、もういらなそうなので公開中止しました。

FeedlyGraph の不具合修正

気付いたら不具合が巻き起こってた。

5/22 の購読者数が取得できていない

Sqale の Ruby のバージョンが想定しているバージョンとは違っていたらしく、途中から動作が怪しくなっていた。
このへんを参考に Ruby のバージョンを変更した。

Sqale - Ruby 2.0 を使う方法 Mac 編

さすがにデータを改ざんするわけにもいかないのでそのまま。
利用している人は心の目で見てほしい。

ブログパーツ関連

ブログパーツで誤った FeedID を指定した場合、正しくデータが蓄積できない不具合。
FeedID が間違っているので、本来はブログパーツが動いているように見えてしまうこともおかしいので、その場合は表示しないことに。

正しい FeedID の取得の仕方については以前書いた記事かコチラ を参照。

最後に

別のサービスつくってるときに面倒だったけど、こういう問題を解決すると経験が積み上がるはず。
Sqale に乗り換えたのは間違いじゃなかった。

パーフェクトRuby (PERFECT SERIES 6)

VisualStudioOnline の ServiceHooks で Idobata 連携した

はじめに

Visual Studio Online updates – May 12 によって、ServiceHooks のプレビューが追加された。
そこで Idobata と連携してみた。

ServiceHooks について

連携できるサービスは画像のとおり。
めぼしいところだと Jenkins とWeb界隈で流行っている HipChat あたりか。
他は知らないものばかりけど、海外で流行っているんだろう。

汎用的なサービスを使いたい場合は Web Hooks を使う。

ビルド（デプロイ）以外にもタスク追加時や完了時のタイミングもフックできるようになっている。

URL や HTTP Header をカスタマイズできるようになっている。

Idobata 連携

いよいよ本題。

Idobata をそのまま連携するとうまくいかない。
VIsualStudioOnline から送信するリクエストを変更できないので、Idobata のフォーマットとマッチしないのが原因。

そこで、この違いを吸収するコードを書いた。
（注：ビルド時のメッセージにのみ対応）

kheiakiyama/webhook · GitHub

Heroku にデプロイすれば後述のURLを設定して使える。

http://○○.herokuapp.com/vso/idotaba/{idobata の Endpoint の id}

僕がデプロイしたやつは以下。

http://webhookpipe.herokuapp.com/vso/idotaba/{idobata の Endpoint の id}

（5/20 追記）現時点で動作していない模様。。。修正の時間がないため、後で直します。
（5/21 追記）直しました。

テストメッセージは以下のように表示される。

最後に

VSO からのメッセージにはなぜか Build の詳細を確認する URL が含まれていない。
せっかく IRC でリアルタイムな情報を流せるようになったのに、そこから VSO に遷移できないってのはなんかなあ。。

Heroku 上のサービスは気まぐれに更新したり削除したりするので、それでもいいという人だけご利用ください。
ちょっと使うだけなら無料枠内で済むので、自分でデプロイするのが吉。

開発ツール徹底攻略 (WEB+DB PRESS plus)

Rails で作ったサービスを Heroku から Sqale に乗り換えた話

先日公開した FeedlyGraph のホスティングを移行した。

乗り換えた経緯

Heroku の無料枠を超えたことがきっかけ。

アプリケーションは問題なかったが、問題は DB。
Postgress は 10k rows までが無料枠だった。
（よく確認してなかった。容量制限だろうと油断した）

サービスの性質上、Feedly購読者数のレコードが毎日ガンガン増えるため、1ヶ月足らずで突破していた。

Heroku の DB を有料で使うとすると、$9 / 10k rows か、$50 / month が候補。
流行ってないプライベートプロジェクトでそれほどのコストをかけるのはつらい。

少し気になっていた Sqale を調べてみると、月額940円で DBは2GBついてくる。
ということで Sqale に移行することに。

移行でやったこと

アプリケーションを修正

Gemfile を修正。

移行前（Heroku）

group :production, :staging do
  gem 'pg', '0.15.1'
  gem 'rails_12factor', '0.0.2'
end

移行後（Sqale）

group :production, :staging do
  gem 'mysql2'
end

database.yml を修正。

移行前（Heroku）
Rails 初期状態なのでカット。

移行後（Sqale）

production:
  adapter: mysql2
  encoding: utf8
  username: { username }
  password: { password }
  database: { database_host }
  host: mysql001.sqale.jp

DB の移行

Heroku 上の Postgres をエクスポート

pgAdmin3 を使って接続し、ローカルにエクスポートした。
pgAdmin: PostgreSQL administration and management tools

Sqale 上の mysql にインポート

Qiita の記事を参考にデータを加工。
PostgreSQLのデータをMySQLに移行する - Qiita

あとは ssh で Sqale 上のマシンに接続。
mysql で直接 SQLを読み込ませてインポート。

Cron

Heroku の Scheduler でやっていたタスクを Cron に移行した。
Sqale - Sqale の特長

NewRelic

特に変更なし。
Heroku 上でアドオン削除すると何か起きそうで不安だったけど、問題なし。

ドメイン

ドメインの割り当てを Heroku のサーバから Sqale のサーバに変更。
自宅からは 5分くらいで変わっていた。
2日くらいしたら Heroku を削除しても大丈夫なはず。

最後に

極力無料の範囲内でやるつもりだったけど、少しコストをかけてでもサービスを続けたほうが問題が起きて勉強になる気がするので続けてみる。
元は取れないだろうけど、お世話になることだし、Sqale の広告でも入れてみようか。

ペパボの教科書 インターネットサービスではじめる、あたらしい自分

僕が1週間でWebサービスを公開するまで

先日、FeedlyGraph を1週間で公開した。

photo credit: surfzone™ via photopin cc

公開までを振り返ってみる。

0日目

アイデア出し

僕は普段からこんなサービスが欲しいな〜というアイデアをメモに残すことにしている。
iCloud 便利。

今回はそこから規模感が合うものをチョイス。

1日目

アイデアの検証

問題を解決するサービスが世の中にあるかどうかを確認した。
今回は「Feedly の購読者数の推移を確認したい」が問題。

既にあった解決策に近いものは以下のとおり。

• Feedly Insight
• Feedly Subscribers Checker 2
• FeedlyやlivedoorReaderの購読者数をGrowthForecastにポストするRubyスクリプト作った

上から順に

• WordPress でないと使えない
• 今の購読者数しかわからない
• GrowthForecast の見た目が気に入らない

という理由でダメだったので、サービスを作ることが決定した。
この時点で「オシャレな UI で確認したい」ニーズがあることがわかった。

名前づけ

プログラミングに限らず、名前づけ大事。
サービス名がかぶると、ググラビリティが下がる。

僕が探そうとしたときの検索ワードが「Feedly 購読者 グラフ」や「Feedly 購読者 解析」だった。
ここから FeedlyGraph か FeedlyAnalytics が候補に。

FeedlyAnalytics を採用しなかったのは、「解析」とするといろんな問題を解決したくなり、結果として機能が増えてしまう気がしたため。

2日目

サービスのデザイン検討

僕自身がユーザだけど、もしかすると他の人も使うかもしれない。
万が一有名になったら少しくらい収益につながってほしいけど、シンプルな UI にしたい。
これらのことから収益面は考えないことにした。
その分、コストがかからない技術を採用する方針に決めた。

技術選択

言語

使い慣れた言語でやるよりも、少し前から Rails を勉強し始めたこともあり、何かプロダクトを作りたかったので Ruby on Rails に決定。

ホスティングサービス

いろいろあるので心配しなかった。
後回し。

ソースコード管理

少なくともサービス公開までは public なところに置きたくなかったので Bitbucket に。

これら以外はやりながら考えることにした。
必要ないときに余計なことをやらないのは大事。
やる気があるうちに次のタスクに進まないと飽きてしまう。

サイトのUI検討

なんかの記事で書いてあったように進めた。
（見つからないのでリンクはなし）

• いきなりコードを書くべきではない
• まずは紙に書こう
• 次に Illustrator
• 最後にコード

Illustrator は持ってないし僕には使えないので、丁寧に紙に書く程度にした。
書いたものはコチラ。

3〜6日目

プログラミング

ひたすらプログラミング。

この時点で Ruby に触れたのが通算 3日目 で、Rails で has_many の書き方すらわからない状態だったので時間がかかった。

たまにやるべきことから脱線してしまう（仕事でもありがち）ので、手書きのマインドマップでゆる〜くタスク管理し、今どこをやってるかを明確にした。
これによって1個のタスクに集中して順番に潰していくフローができた。

また、作業の全体量を見て、無理そうな要求は外した。
（2日目の紙デザインにあった、期間設定とか）

参考にしたサイト

• Ruby-Doc.org: Documenting the Ruby Language
• Ruby on Rails チュートリアル：実例を使って Rails を学ぼう
• The feedly Cloud API

本当はもっといっぱいあるけど紹介しきれないので割愛。
公式は大事。

7日目

ホスティング

Heroku と Sqale で迷い、無料な Heroku に。

Heroku にデプロイしてから Javascript が動かないなどの問題が何度か起きた。
このあたりを予測してなかったので、夕方公開するつもりが23時とかになってしまった。

SEO関係

• GoogleAnalytics の導入
• ドメインの取得、設定
• ウェブマスターツールの登録

サービス監視

NewRelic 様々。
Heroku はアクセスがないとスリープするので、定期的にアクセスさせる面でも NewRelic は便利。
ついでに Idobata と連携してみた。

スケジューラ

FeedlyGraph では定期的に購読者数を取得する必要がある。
Heroku の cron というべきサービスの Heroku Scheduler を導入。

公開

Heroku にデプロイした時点で公開は終わってるけど、ブログに書くまで が公開。

ふりかえり（8日目以降）

Keep

無事公開できたことは非常に嬉しい。
プライベートでサービスを作るなんて、しょせん自己満足でしかない。
この達成感とその後のアルコールのためにやっているようなものだ。

過去の蓄積が生きた

前にも書いたけど、rebuild.fm の知識が役立った。
今回は Rails4.0 の Toubolinks のあたり。

NewRelic は MicrosoftAzure で既に使っていたのでサクッと導入できた。

Problem

テストがほとんど書けなかった

流行りの RSpec を使ってテスト書いてたけど、トラブルシューティングに時間がかかりすぎて後回しにした。
大半はローカルサーバか Rails console を使って動作確認してた。

公開周りの作業がカツカツだった

プログラマーは実装を中心に考えてしまいがちだけど（僕だけ？）、公開するためにやらないといけないことはいろいろある。
そのあたりを舐めてはいけないと実感した。

最後に

僕は単に技術を勉強するより、何かを作る過程で技術を学ぶほうが性に合う。
今後もいろんなサービスを作りたい。

たった2日でできるRuby―Ruby2.0対応

10日でおぼえる Ruby on Rails入門教室

Ruby を始めて7日目、FeedlyGraph を公開しました

photo credit: AJC1 via photopin cc

このたび FeedlyGraph を公開しました。

経緯

はてなブログでは Feedly の購読者数がいつの間に増えたかがわかりません。
ググるとかなり惜しいサービスはありましたが、僕のニーズとマッチしなかったので自分で作ることにしました。

概要

FeedlyGraph は、Feedly の購読者数の推移を見える化するサービスです。
こんな感じ。

Feedly の API では過去の購読者数は取得できません。
今日から購読が始まったように見えるのはこのためです。

このブログも早速登録しました。
グラフの形は同じですが、数値が全然違いますね。

一度表示すれば、翌日以降のデータは自動的に蓄積されるようになっています。
（そのはずです・・・）

環境

Rails + Heroku というオーソドックスな構成？です。
Ruby歴2日で月曜から作り始めたので、いろいろとおかしなところがあるかもしれません。

今後の予定

• ふりかえり
• 運用関連の整備
• ソースコードの公開
• ブログパーツの作成

をするつもりです。
が、あくまでも予定です。

最後に

僕以外の方にニーズがあるかわかりませんが、もし利用された方がいれば、コメントや要望などいただけると励みになります。
その際は Twitter かブコメでお願いします。

追記：ふりかえりしました。

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

Webサービス開発徹底攻略 (WEB+DB PRESS plus)