CDP Advent Calendar 2013 の14日目です。主に動的なWeb/アプリケーションサーバの話ですが、AutoScaling時や障害発生時に影響なく処理を継続するにはセッションの保持方法に一工夫必要です。またログなどもローカルに保存すると後々面倒くさいです。その辺りを解決するには、サーバの状態（セッション・ログ・etc）を外出しするのが一番です。名前を付けるとしたら、「Stateless Serverパターン」です。昨今のImmutable Infrastructureの概念にも影響を受けています。
1 解決したい課題
AutoScalingを利用すると、負荷の増減に応じてサーバの増減が出来る。しかし、動的サーバの場合はセッションサーバを個々のサーバに保持していると、サーバが増減して別のサーバに振り分けられた場合セッション維持が出来ずに問題が生じる。また負荷が下がってサーバが減る際も、デフォルトのままであればログは消失してしまう。
2 クラウドでの解決/パターンの説明
セッション情報やログなどのをWeb/アプリケーションサーバ自身に保持するのではなく、専用のストアを用意して外部に保存する。外出しすることにより可用性・冗長性が高められる構成がとれ、耐障害性があがりAutoScalingや障害発生時に強い構成がとれる。
3 実装
4 構造
セッションストアとログストアを外出しする。セッションストアの外出しの実装方法はアプリケーションサーバによって異なるが、MemcacheやRedis、RDB/NoSQLに保存するなど色々な方法が存在する。AWSの場合、ElasticCacheやDynamoDBを利用すると、可用性の確保や負荷対策をほぼ自動で確保出来る。またログについてはFluentdのようなログ集約フレームワークを利用して、Amazon S3に保存するなどの方法がある。
5 利点
・AutoScalingやインスタンス障害が発生して別サーバに振り分けられても、セッションを維持出来る
・ログが消失しない
・サーバの増減が簡単
6 注意点
・セッションの同期方法は、アプリケーションサーバの実装により異なる。
・セッションが同期されるタイミングも、実装により異なる。（同期・非同期）
最後に
純粋にAWSのサービスの話というより、上モノのミドル・アプリとどう組み合わせるかがテーマです。その辺りまで含めるとCDPは無限に広がりますね。
See Also:
Statelessなサーバについて 〜クラウド時代のサーバの在り方
何故、fluentdなのか？
Immutable InfrastructureとChefと冪等性の話
