Kubernetesパターン 第2版 ―クラウドネイティブアプリケーションのための再利用可能パターン

11章Stateless Service（ステートレスサービス）

Stateless Service（ステートレスサービス）パターンは、同一で短期間のみ動くレプリカから構成されるアプリケーションの作成と運用の方法を説明するものです。アプリケーションを迅速にスケールし、かつ可用性を高められる動的なクラウド環境に最適なのがこれらのアプリケーションです。

11.1　問題

マイクロサービスアーキテクチャスタイルは、全く新しいクラウドネイティブアプリケーションを実装するなら有力な選択肢になります。このアーキテクチャに影響力を持たせる原則には、1つのことだけを扱う、データの持ち方、うまくカプセル化されたデプロイの境界といったことが含まれます。通常このようなアプリケーションは、動的なクラウド環境においてKubernetesでアプリケーションを運用しやすくする原則であるThe Twelve Factor App（https://12factor.net/）にも従っています。

これらの原則に従うには、ビジネスドメインを理解し、サービス境界を明確にし、サービスの実装時にはドメイン駆動デザインを適用するか、類似の方法論を適用する必要があります。これ以外の原則も実装することで、サービスを短時間だけ動くものにすることもできるでしょう。つまり、サービスを作成し、スケールし、削除されると言う流れが副作用なく行えると言うことです。このような仕組みは、サービスがステートフルではなくステートレスな時には簡単に構築できます。

ステートレスなサービスは、サービスのやり取りをまたがってインスタンス内に一切のステート（state）の情報を保持しません。この本では、内部ストレージ（メモリや一時ファイルシステム）に、将来のリクエストを処理するのに必須な一切の情報をコンテナが保持しないなら、そのコンテナはステートレスであるとします。ステートレスなプロセスは、過去のリクエストについての知識や参照情報を保持しないので、各リクエストはゼロから始まっているように扱われます。もしプロセスがそのような情報を保存する必要があるなら、その情報はデータベース、メッセージキュー、マウントされたファイルシステム、あるいは他のインスタンスからアクセスできる別のデータストアに保存される必要があります。思考実験として、サービスのインスタンスが別のノードにデプロイされ、スティッキーセッション（クライアントとサービスインスタンス間の関係を固定しないこと）なしでインスタンスにリクエストをランダムに分散するロードバランサを考えてみるとよいでしょう。もしその構成においてサービスが目的を果たせるなら、それはステートレスサービスである可能性が高いです（あるいはデータグリッドのような、インスタンス間でステートを分散できる仕組みがある場合もあります）。 ...