ステートフルなサービスとは? 記憶がインスタンスに宿るとき

ステートフルなサービスは、リクエストをまたいで永続し再起動を生き延びるべきデータを保持するため、そのインスタンスは自由に交換できません。

一部のサービスは本当に物事を覚えていなければなりません。データベース、cache、message broker、データを保存するあらゆるものです。これらのステートフルなサービスは、保持するデータこそが要点であるため、ステートレスなものと違って気軽に落として置き換えることはできません。システムのどの部分がステートフルかを知ることが、慎重なスケーリングとデプロイの作業がどこで必要かを教えてくれます。

永続すべき状態

ステートフルなサービスは、失われては困るデータ (データベースの行、ブローカーのメッセージ、永続的なcacheのエントリ) を所有します。インスタンスは特定のデータを保持するため識別性が重要であり、インスタンスを匿名で使い捨て可能なものとして扱うことはできません。

より難しい理由

スケーリングにはレプリケーション、sharding、あるいはパーティショニングが必要です。
インスタンスには識別性があるため、自由に入れ替えられません。
フェイルオーバーはデータを保全または復旧しなければなりません。
デプロイは、扱いを誤るとデータ損失のリスクを伴います。

状態を集約する

一般的な設計は、ほとんどのサービスをステートレスに保ち、状態を少数のよく管理されたステートフルなシステムに押し込めます。そうすることで、難しい問題 (バックアップ、レプリケーション、慎重なアップグレード) が、あちこちに散らばるのではなく、少数の場所に収まります。

CI/CDの課題

ステートフルなサービスのデプロイは、しばしばスキーマ移行、データ互換性、順序を伴います。移行はrollingデプロイ中に旧コードと新コードの両方で機能しなければなりません。悪い移行はプロセスをクラッシュさせるだけでなくデータを破壊しうるため、パイプラインは移行を慎重に実行し検証します。

実際のデータストアでテストする

ステートフルなロジックは、CIでservice containerとして立ち上げ、実行ごとにシードして片付ける、実際のデータストアのインスタンスに対してテストするのが最善です。モックは、本番のバグを引き起こすストレージ固有の振る舞いを取りこぼします。

CIでデータストアを起動する

テスト実行ごとにデータベースやブローカーを起動すると、起動時間が加わります。ウォームなマネージドrunner (Latchkeyが提供するもの) はそのコストを吸収し、ステートフルな統合テストを素早いままに保ちます。

重要なポイント

ステートフルなサービスは、永続し再起動を生き延びるべきデータを保持します。
そのインスタンスには識別性があるため、スケーリングとデプロイははるかに繊細です。
状態を少数のマネージドなシステムに集約することで、難しい問題を封じ込められます。