【プログラミング全般】「ステートレス」と「ステートフル」の違い

主にWebの分野で出てくる言葉ですが、「ステートレス」と「ステートフル」と言う単語があります。どちらか一方が優れた概念というわけではなくどちらの長所短所を覚えておいて使い分けをすることが求められます。

ちなみに、昨今のマイクロサービス化の流れの中でステートフルよりもステートレスで作る動きが盛んになっています。

ステートレス

状態を持たないこと（以前のやりとりを覚えていないこと）。Webで言えばリクエストとレスポンスの1回のやり取りで完結します。

メリット

• サーバー資源をすぐに解放できる。
• 覚えておく必要がないのでサーバー負荷がかからないのでスケールもしやすいです。

デメリット

• 認証などのサーバに負荷がかかる処理も実行されるのでパフォーマンスが低下します。
• サーバー側でデータを保持しない分、ステートフルに比べたらクライアントからもらうデータ量は増えやすくなり通信量が増えやすくなります。

ステートレスな設計思想や、サービス

トークン認証

クライアントサイドにセッションを保持しサーバーで状態を保持しないのでステートレスなやりとりになります。トークン認証だとセッションを用いた普通の認証に比べてストレートレスな方式と言えます。

Lambda

AWSのサーバーレスな実行環境を提供するマネージドサービスです。セッション状態を保持できません。

ステートフル

サーバーはクライアントの状態（セッション情報）を持つこと。（以前のやりとりを覚えていること）、クライアント側はCookieにセッションIDを保持するのが一般的です。

メリット

すでに認証したことをサーバーが覚えているためやりとりする通信量が減ります。

デメリット

• 1つのサーバーに1人のユーザーの場合は負荷はないが、1つのサーバーに対して複数のユーザーがいる場合に負荷が大きくなる。（HTTPのセッション状態であればサーバーのメモリを使用して記憶しているのでメモリ消費量を食います。）
• サーバーが一つのリクエストに対してつきっきりになってしまうのでその情報を他のサーバーに引き継ぐことができずサーバーをスケールすることが難しくなります。

ステートフルな設計思想の概念、サービス

FTP、TCP、SSH

FTPはファイル転送プロトコル、TCPはサイトの閲覧やメール、SSHはサーバーへの接続手段として使われるプロトコルです。

ECS on Fargate

Fargateを使う場合は、RailsのPumaのようにアプリケーションサーバーでセッションの状態を持たせます。

近年の動向

マイクロサービスなどのアプリケーション設計思想がトレンドになってきておりアプリケーション間を疎結合にすることが求められる時代になってきています。

なので、どちらかといえばステートフルよりもステートレスな疎結合なアプリケーション設計が求められる時代になりつつあります。

もちろん、いまだにステートフルな実装をしたアプリケーションはたくさんあるのでどちらも使えるようにしておくことが重要です。