ステートレスという言葉の意味を自分なりに理解する。
ステートレスとステートフルの違い
IT用語辞典では、以下のような説明がされている。
ステートレスとは、システムが現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式。同じ入力に対する出力は常に同じになる。
https://e-words.jp/w/ステートレス.html
一方、システム内部に処理や通信によって変化する現在の状態を表すデータなどを保持しておき、入力とともに処理内容に反映させるような方式を「ステートフル」(stateful)という。入力が同じでも内部の状態の違いによって出力は異なる場合がある。
ステート(State)とは、状態という意味で、ステートレスは、「状態がない」ということになる。
たとえば、お店の注文を例にすると、ステートレスの場合は、以下にようになる。
(お客)コーヒーをください
(店員)ホット、アイスどちらでしょうか?
(お客)アイスコーヒーをください
(店員)サイズはどれにしましょうか?
(お客)Mサイズのアイスコーヒーをください
(店員)かしこまりました。
「コーヒー」、「アイス」というキーワードを連続で伝えることで、状態を保持せずやりとりが可能になる。
反対に、ステートフルの場合は、以下のようになる。
(お客)コーヒーをください
(店員)ホット、アイスどちらでしょうか?
(お客)アイスをください
(店員)サイズはどれにしましょうか?
(お客)Mサイズください
(店員)かしこまりました。Mサイズのアイスコーヒーですね。
ステートを保持するので、「コーヒー」、「アイス」というキーワードを連続で伝えなくても良い方式になる。
メリットとデメリット
メリット | デメリット | |
ステートレス | ・クライアントの状態に左右されないので、処理がシンプルになるサーバ資源がすぐに開放できる ・リクエスト情報が網羅されているので、複数サーバ構成でも影響がない | ・同じ情報を都度送信するため、送信データ量が多い、ネットワーク負荷の懸念 ・エラー時のハンドリングが面倒 |
ステートフル | ・やりとりが簡潔 ・同じ情報を都度送信しないため、送信データ量が少ない | ・複数サーバ構成の場合、状態保持がしにくい |
なぜ、調べようとしたのか
WebSocket アプリケーションを構築しようとしたのだが、
WebSocket アプリケーションは一般的に、コネクションをサーバ内で管理するため、複数サーバ構成にしようとすると、コネクションを複数サーバ間で共有しないといけなくて、厳しいということがわかった。
調査を進めていったところ、RedisのPub/Sub 機能を使うと複数サーバ構成がやりやすいことがわかったのだが、
Redisを使わないWebSocket アプリケーションはステートフル方式で、Redisを使ったWebSocket アプリケーションは、ステートレス方式になる意味が当初わかっていなかった。
そのため、ステートレスを調べることにした。
RedisのPub/Sub 機能を使うことで、コネクションをRedisサーバで管理できるので、複数サーバ構成がやりやすく、
Redis自体でも標準で、マスター・スレーブ型のレプリケーションによる冗長構成をとることが可能なので、コネクション管理がしやすいこともわかった。