Statelessなサーバについて　〜クラウド時代のサーバの在り方

　Immutable Infrastructure関連の記事を読んでいて、ここ最近AWS上でサーバを構築・運用する上でモヤモヤと感じていた事が一気に概念化されました。一番納得したのが、@stanakaさんの2014年のウェブシステムアーキテクチャです。その中のStatelessサーバのくだりです。

状態を持たない Stateless Server は、アプリケーションサーバーやリバースプロキシサーバー、キャッシュサーバー、ロードバランサーなどのことです。これらのサーバーは、本質的には状態を持つ必要がないため、いつ壊れてもよいし、再作成も容易にすることができます。そのため、負荷に応じて必要十分な数だけフレキシブルに増減させることが、もっとも効率的です。サーバーを増やしたり、減らしたり、設定を更新したり、切り戻したりするオペレーションコストをいかに減らすかが勝負どころです。

Statelessなサーバとは？

---

　AWS上でサーバを構築する上では、サーバをいかにステートレスな状態にするかが大きなポイントになります。Webやアプリケーションサーバにおけるステート（状態）とは何でしょう？極論すれば、セッション情報とログ情報だけです。
　以前、「何故、fluentdなのか？」というエントリーでクラウドになるとログを外出しにする必要があるよと書きました。AutoScalingでサーバは増減するので、ログを一箇所に集めておくべきですよと言う内容です。

　また、「アプリケーション・サーバのセッションの保存先の話」というエントリーで、セッション情報は外出しにしないとなぁと考えていました。

Statelessなサーバになると、何が嬉しいのか？

---

　サーバをStatelessにすると、何が嬉しいのでしょうか？最大のメリットは、サーバの増減が簡単になるということです。それの何が嬉しいかというと、AWSの場合ではAutoScalingを利用出来るということです。サーバに状態が無いのだから、増やそうが減らそうが問題はありません。システムの負荷に応じて、自由に増減する。インフラ・エンジニアの理想の世界ですね。

Statelessに出来ないサーバは？

---

　一方で、全てのサーバをステートレスに出来るかというと、そんな訳はありません。DBサーバであったり、ファイルサーバは依然ステートフルな状態です。ここをどう扱うか？実は、方式設計の最大の要です。DBサーバであれば、負荷を軽減出来るようにキャッシュ機構を導入したり、水平・垂直でのデータ分散やリードレプリカの導入などがあります。RDSのようなデータベースのPaaSや分散DBがもっと進化していくと、個々のサーバ単位で考えるとステートレスなDBサーバなどが実現するかもしれません。そんな時代を夢見ながら、今は手堅くキャパシティ・プランニングしていくのがステートフルなサーバの世界です。

まとめ

---

　卵が先か鶏が先かは解りませんが、Immutable Infrastructureという概念のお陰でProvisioning toolはまた一気に進化しようとしています。それと同じようにステートレス・ステートフルなサーバの在り方も、進化していくのではないかと思います。進化の先は、或いはサーバではなくPaaSやSaaSなのかもしれません。その辺りをしっかり見極めたいと思う今日この頃です。

See Also:
AutoScalingのインスタンスをどう扱うのか（デプロイ編）
Immutable InfrastructureとChefと冪等性の話
何故、fluentdなのか？
アプリケーション・サーバのセッションの保存先の話
AutoScalingやインスタンス障害に強い　〜Stateless Serverパターン〜

参照：
2014年のウェブシステムアーキテクチャ - stanaka's blog