はじめに
この記事では、Railsのrouteファイルを確認した際に理解が難しかった部分について調べた内容をまとめます。特に、認証機能の設定、ルーティングの名前空間、モックページ、ELB（Elastic LoadBalancer）によるヘルスチェックについてまとめていきます。
device
devise_for :admin_users, controllers: {
sessions: 'admin_users/sessions',
passwords: 'admin_users/passwords',
confirmations: 'admin_users/confirmations',
}
DeviceというGemを利用することで、ユーザー認証に関するルートやコントローラを自動で生成してくれます。
device_for
たとえば、上のようにdevice_for を使うと、admin_usersというモデルに対応する認証機能を有効にできるようになるらしいです。
そして、controllersオプションを使うことで、特定のコントローラをカスタマイズすることができるみたいです。
device_scope
device_forで定義されたルートを拡張またはカスタマイズするための機能
独自のルートを設定し、特定のコントローラやアクションを呼び出すことが出来ます。
ルートファイルにおけるnamespace / scopeの役割
Rails.application.routes.draw do
namespace :admin do
# /admin/dashboard で Admin::DashboardController を呼び出す
get 'dashboard', to: 'dashboard#index'
# /admin/users で Admin::UsersController を呼び出す
resources :users, only: [:index, :show, :edit, :update]
end
end
namespace
ルートを名前空間でグループ化する
admin_usersやapiなど、名前空間ごとに整理されている
Rails.application.routes.draw do
# /public/products で ProductsController を呼び出す
scope '/public' do
resources :products, only: [:index, :show]
end
end
scopeとnamespaceの違い
- scopeの時は、URLが変わるがファイル構成は変わらない
- namespaceの時は、URLもファイル構成も変わる。クラス名も
「namespace名」::と変更
モックページ
# モック用のページ
get '/hello', to: 'hello#index'
モックページとは？
モックページとは実際のウェブサイトやアプリケーションのデザインや機能を再現した試作的なページのこと。主に開発や設計の初期段階で、完成のイメージや動作を確認するために作成される。モックページは最終的な製品がどのように見え、どのように動作するかを関係者間で共有し、フィードバックを得るために非常に重要な役割を果たす。
ELBヘルスチェック
# ELBヘルスチェック用
get '/elb', to: 'elb#index'
ELBヘルスチェックの目的
ヘルスチェックは、「サーバーがちゃんと元気に働いているか？」 を定期的に確認する仕組みのこと。サーバーが正常に稼働していない場合に、適切に対応することが出来る。
ELBはElastic Load Balancerの略で
ELBによるヘルスチェックはサーバー達に 「元気？」 と定期的にリクエストを送るイメージです。
正常に稼働していない場合は、トラフィックから外す。
トラフィックから外すというのは、ユーザーからのリクエストをそのサーバーに送らないようにすること。トラフィックとは、ITやネットワークの文脈で、ネットワーク上を流れるデータや通信のことを指します。もっと具体的に言うと、ユーザーが送信したリクエストや、サーバーから返されるレスポンスのことを指します。
ELBの役割はトラフィックの分散で、複数のサーバーにリクエストを分散させることで、サービスの高可用性を確保しています。
そもそもなぜ、サーバーが複数必要になるのかというと、
-
高可用性
- 1つのサーバーだけでは、故障した時にサービスが止まってしまう
- 複数のサーバーを用意しておけば、１つがダウンしても他のサーバーがカバーできるので、サービスを継続できる。
-
負荷分散
- 複数のサーバーにリクエストを分散させることで、負荷を分散し、処理の効率を上げる
-
スケーラビリティ
- 需要が増加した時に、簡単にサーバーの台数を増やして対応できる（スケールアウト）
- 需要が減れば、不要なサーバーを減らしてコストを削減できる
ELBとサーバーをレストランに例えると、ELBがホストで、サーバーがウェイター。
お客様（トラフィック）が来店すると、ホストは適切なウェイターに案内させます。
この時、忙しかったり、休憩中のウェイターにホストはお客さんを案内させたりはしません。
１人に負担を集中させるようなことはイメージできないと思いますが、これと似た考えです。