Ruby On Railsをサーバに構築するまでの流れ(共有・VPS・専用・クラウドサーバからの選定編)
- はじめに
- サーバとは何か
- サーバ運用の種類と4種類のクラウドサーバ
- サーバの選定
- おわりに
はじめに
筆者がシステム開発をする際によく用いられているRuby on Rails(以下Rails)をサーバに構築する手順をお話します。
サーバでRailsを動かすというドキュメントは検索したら沢山ありますが、諸々の部分を端折って説明されているものがほとんどです。
またOSに違いがあった場合や言語のバージョンによって違いがある為他者が用意したドキュメント通りにはいかないケースがあります。
ですので根本的な役割を知っていくことが今後の為に重要でこれまでに行ってきた構築作業の整理にもなりますので、 今回はなるべく事細かに説明させて頂きます。
まずRailsをサーバ上で動かすという要件を満たすために必要なものがいくつかありますが、まずはサーバから考えていきます。
サーバとは何か
まずサーバとは何かを理解していきましょう。 サーバは英語です。綴りはServer。言葉の意味としては提供する(人/モノ)という意味です。 つまり何か欲しいというリクエストがあったらそれに答えてくれる機能があります。 様々な〇〇サーバといわれるサーバがありますが、機能としては〇〇を提供するというのが基本的機能になります。 webページを提供するのはwebサーバ、メールを提供するのはメールサーバ。ビールを提供するビールサーバもあります。 Railsを動かすためにはwebサーバ、アプリケーションサーバ、データベースサーバが必要になります。 それらを同じサーバ内に構築する場合と、webサーバ、アプリケーション、データベース等を別にサーバを構築して連携させていくパターンがありますが、アクセス数や処理の求められる速さ等の要件によって構築方法は変わってきます。
サーバ運用の種類と4種類のクラウドサーバ
サーバを自ら構築するというケースは昨今では殆どありません。 理由を一言でいいますとコストが高くなるためです。サーバを構築するにはネットワーク・サーバ・セキュリティ、最近では仮想化技術など専門的知識を有するインフラ整備の人員が必要になるからです。このように自社内に物理的にサーバを保有していくことを「オンプレミス」といいます。 サーバは一般家庭のPCと違い、常に動作していないと意味が無い為使用しているパーツも高耐久の仕様となっています。 オンプレミスと対照的なのが「クラウド」といいます。 クラウドとはデータを自社では持たずに他者が保有するサーバに領域をレンタルしてネットワーク越しに利用することを指します。 各々メリット・デメリットがあります。 オンプレミス環境では侵入検知システム等の構築等カスタマイズが自由な為社内システムとの独自連携や高セキュリティなサーバ構築が可能ですが、物理的・構築時間のコストが高いです。 クラウド環境はオンプレミスと比較して物理的コストが一切かからず、ある程度のセキュリティ設定がされていたりと構築・保守コストが抑えられるというメリットがあります。 ECサイトの構築やセキュリティ要件がかなり高く求められている、または巨大なサービスである等の条件が無い限りは殆どのケースでクラウドを選択されているでしょう。 今回はクラウドでサーバのレンタルを選択します。 しかしそこでサーバの話が終わるわけではありません。 レンタルサーバにもまた用途によって分けられているのです。以下の4つが大きな分類になります。
1.共有サーバ
一言でいうとシェアハウスのように、1つのサーバにスペースを借りていく形です。低価格なのが特徴ですが、権限が限られた一般ユーザーとして借りている為カスタマイズ幅が狭いです。 webサーバソフトウェア、PHPなどのプログラミング言語を使う準備が整っており専門的知識が無くとも始めるのには良いです。
2.VPSサーバ
こちらも共有スペースとして利用するサーバですが、共有サーバとの違いは仮想環境で1つ1つが割り当てられているため、root権限が提供されており、OSの構築やカスタマイズが自由にできます。プログラミング言語などは自分で用意しなければなりません。
3.専用サーバ
1台の物理的なサーバを1ユーザーで専有できる契約です。 こちらもroot権限がありますが、コストはVPSと比較しても高く、初期費用・月額料金共に数万円掛かる場合もあります。
4.クラウドサーバ
VPSサーバと同じく仮想領域を割り当てられており、root権限を持っている為拡張性は高いです。 VPSとの違いは必要なサービスのみを選択することが出来、金額もその分変わってきます。 多くのサービスが従量課金で拡張しており、コストは高くなります。有名なところでAmazonが提供するAWS、Googleが提供するGCPなど。 今回の目的はRailsをサーバに配置してwebシステムとして公開することです。 RailsとはそもそもがRubyというプログラミング言語のフレームワークの1つです。 Railsが動くにはRubyが必要で共有サーバの殆どはRuby単体では使えますが、root権限が無い為フレームワーク導入が出来ず今回の選択肢には入りません。 ですので2から4のサーバが要件を満たすものとなります。
サーバの選定の3つの基準
サーバを選ぶのに必要な要件は「止まらずに動くか」「快適に動くか」です。
サイトを表示するまでの時間が遅いとページを続けて見る気になりませんし、止まっていたらそもそも見れなくなってしまいます。
Googleの検索順位を上げるための基準として検索キーワードが入っているのかの他にも、ページ表示速度が重要になります。
また数日間もページが公開出来ていないと場合によっては検索順位が下がるというケースもあるようです。
止まらずに快適に動くというのは当たり前ですが重要であり、それらを満たすためには主に以下3つの基準があります。
- 回線速度が十分か
- データ転送制限の有無
- サーバに使われているPCのスペックは十分か
止まらずに動くことと言いましたが、サーバがダウンしないという事を指します。
ダウンしている間はアクセスが出来なくなり、ECシステム等であれば購入が出来ない等の機会損失になる為これは防ぎたいです。
レンタルして使用するサーバには提供している回線の速度がありほとんどのレンタルサーバは1Gbps程度はありますのでこちらは心配ありませんが、2つ目のデータ転送転送量の制限については借りるサーバの記載を確認した方が良いと思われます。 共有サーバのほとんどは1日の転送量に制限があります。
ブラウザからAというページを1人が見た場合そのAのhtmlページやそれに含まれる画像ファイル容量が1MBとしたら1MBの転送量を使うことになります。
プログラムを介さない常に同じコンテンツ(静的ページ)であったら上のような計算が成り立つのですが、システムが絡むコンテンツ(動的なコンテンツ)の場合はまた変わってきます。 サーバに使われているPCのスペックは用途によって重要視する点が異なります。
例えばファイルサーバやメールサーバであったら主な用途はファイルの共有やメールの処理などのデータの読み書きです。
したがって最も欲しいスペックはハードディスクの容量、そしてハードディスクの読み書き速度(I/O応対時間)になります。
webやアプリケーション用途ではハードディスクのスペックよりもCPUやメモリ処理の方が重要になります。
したがって、アプリケーションの配置はファイル・メールサーバと比較してさほどHDDや重要ではなく、CPUやメモリを見る必要があります。
しかし、これは単機能のサーバとしての選定基準でありデータベースとweb、アプリケーション等すべて単機能の場合になります。
アクセス数が多いことが想定される等、規模の大きなシステム構築となる場合は各機能のサーバを連携させたものを並列化してロードバランサーというアクセスを一度一手に受け入れて、バランスを見て振り分ける機能を用いる必要が出てきます。またさらにアクセスが多く、負荷が高いとなればロードバランサーの予備を常にスタンバイさせておく(冗長化)ことや必要なサーバの台数を増やす(スケールアップ)やサーバ自体のCPUの高性能化やメモリの増量(スケールアウト)等、ケースバイケースでどのように負荷に応対するかも変わってきます。
システムの場合、そのような負荷に対策を講じる為にシステム構築後に負荷テストを行いそのテスト結果によって対応策を決めます。
負荷テストには想定されるユーザー数とそのユーザー数がシステムの一連の処理の流れを優先度で決めて行い、例えばデータベースへのアクセスに時間を要するといった場合にはデータベースサーバの性能をスケールアウトさせる等サービスのボトルネックに対して具体的に何をしたら良いかが分かる為のテストになります。
おわりに
システムをサーバ上に構築する為のサーバについて説明させて頂きました。
サーバを選ぶのに大切なのは「誰が(何人が)」「どういった目的で」「何を使うか」これらを見て最適なものを選ぶことですが、選ぶためには選択肢を知る必要があります。
今回でサーバの種類やそれらの向き不向き等の理解がすすめば幸いです。 まだまだ私自身深い理解をしていないので、これからもインフラ知識を深める必要があります。