Herokuデプロイ環境基礎勉強

HerokuでRailsアプリケーションを走らせる際の基本的な技術について調べて見ました。ざくっと言えばHerokuはサーバ管理などの知識が（ほぼ）無くても、ウェブアプリケーションを作ったから公開したいと思えば簡単にできるプラットフォームですよね。背景技術に詳しくなれば高度なカスタマイズも可能なのでしょう。

Stackのレベルから調べようと思い、HerokuのCeladon Cedarの項目を読み始めたのですが、出だしの文章が

Celedon Cedar is Heroku’s most recent runtime stack and is a flexible, polyglot environment with robust introspection and erosion-resistance capabilities. [cont.]

何のことやら…。Celadon Stackとか、データベースのプランがRoninとか、名前からサービスの内容が全然連想できないところも絶望的ですね…。気を取り直して地道に一語ずつ拾っていきます。

(Runtime) Stackはアプリケーションをアップロードすると、多くの言語を勝手に認識してデプロイに必要な環境（WEBRickやThinのようなHTTPリクエストをさばくdaemonとMRIのようなインタープリターを乗っけて動かす環境）を構築してくれる基礎のようです。私はMRI1.9.2を使用しているCeladon Cedar stackを作成し、ThinにHTTPリクエストをさばいてもらい、Railsアプリケーションを動かしています。

もう一つ分かりにくかったのがDynoという概念です。Process Modelという概念によりプロセス単位でスケーリングができる様に設計されているようで、その１プロセスを1 Dynoと呼んでいるようです。Web Dynoを増やせば同時にさばけるリクエストの量が増え、リクエストをさばくことにリソースが制限されるサイト（静的コンテンツをキャッシュに保存しておいて提供するサービスがメインのサイトなど）に関してはWeb Dynoの増減がスケーリングで考える重要な項目になってくるのでしょう。一方でWorker Dynoはcpuを消費する例えばオンラインシューティングゲームなどのサーバ運営でスケーリングを考える必要がある項目でしょう。いずれのDynoも自分の経験としてまだどれぐらいのアクセスで1プロセスを増やさなければいけないという感覚が掴めていないのは残念ですが…。ちなみにHerokuのプロセススケーリングを自動で管理してくれるHero Scalingという外部サービスもあるようです。

今回はHerokuデプロイ環境の本当に初歩の部分にしかたどり着きませんでしたが、今まであまり関与してこなかったインフラ系の知識もアプリケーションの開発や運営手法と共に車の両輪のように学んでいきたいと思います。ウェブマーケティングの知識を得る必要もありますし、課題は多いですね…。