ステートレスとは何か

» Permanent link | |

RestWiki をたまに見直すと新たな発見があって面白い。

たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。

RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。

ステートフルサーバとステートレスサーバはどう違うのか。

まずは、ステートフルの例:

• 客: こんにちは
• 店員: いらっしゃいませ。○○バーガーへようこそ
• 客: ハンバーガーセットをお願いします
• 店員: サイドメニューは何になさいますか?
• 客: ポテトで
• 店員: ドリンクは何になさいますか?
• 客: ジンジャーエールで
• 店員: +50円でドリンクをLサイズにできますがいかがですか?
• 客: Mでいいです
• 店員: 以上でよろしいですか?
• 客: はい
• 店員: かしこまりました

これはいたって普通の会話に見える。では、ステートレスな場合はどうなのか。

• 客: こんにちは
• 店員: いらっしゃいませ。○○バーガーへようこそ
• 客: ハンバーガーセットをお願いします
• 店員: サイドメニューは何になさいますか?
• 客: ハンバーガーセットをポテトでお願いします
• 店員: ドリンクは何になさいますか?
• 客: ハンバーガーセットをポテトとジンジャーエールでお願いします
• 店員: +50円でドリンクをLサイズにできますがいかがですか?
• 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
• 店員: 以上でよろしいですか?
• 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
• 店員: かしこまりました

これは明らかに冗長であほらしいのだけれど、サーバがステートレスというのはこういうことである。

ステートフルの例では、2回目以降の対話では、客(クライアント)はそれまでの前提(ハンバーガーセットを頼んでいること)は 繰り返さなくてもよかった。なぜか。それは店員(サーバ)が客(クライアント)の注文状態を覚えていたからである。 この店員(サーバ)は「この客(クライアント)はハンバーガーセットをポテトで頼んでいる」ということを覚えている。 これをアプリケーション状態、あるいはセッション状態と呼ぶ。 次にドリンクの種類を聞いたときに店員(サーバ)は自分で覚えている客(クライアント)のアプリケーション状態を 「この客はハンバーガーセットをポテトとジンジャーエールで頼んでいる」と更新する。

ファーストフード店の店員であれば、ステートフルな実装は当たり前なのだが、Web サーバは異なる。 それはスケーラビリティの問題である。 店員(サーバ)が一人の客(クライアント)をずっと相手にしていると、その間別の客に対応することができない。 店が込んできたら(アクセスが集中したら)、店員を増員して(Webサーバを増設して)対応する。 普通の店舗では、ひとつのレジで一人の店員がずっと同じ客を受け付けるのだが、 Web の場合は複数の Web サーバ(比較的少数)で複数のクライアント(比較的多数)を同時に受け付ける。 ここで、ステートレスサーバであれば、以下のように、各インタラクションで別々の店員(サーバ)が 客(クライアント)の注文(リクエスト)に応答(レスポンス)することが可能になる。

• 客: こんにちは
• 店員1: いらっしゃいませ。○○バーガーへようこそ
• 客: ハンバーガーセットをお願いします
• 店員2: サイドメニューは何になさいますか?
• 客: ハンバーガーセットをポテトでお願いします
• 店員3: ドリンクは何になさいますか?
• 客: ハンバーガーセットをポテトとジンジャーエールでお願いします
• 店員4: +50円でドリンクをLサイズにできますがいかがですか?
• 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
• 店員5: 以上でよろしいですか?
• 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
• 店員6: かしこまりました

ステートレスサーバというのは一見冗長なように見えるが、 スケーラビリティの観点から見ると、理に適っているものである。

合わせて読みたい: A Web-Centric Approach to State Transition