ステートフルおよびステートレス アプリケーション: DevOps への影響

ステートフルとステートレスは、アプリケーションが有効期間の長いプロセスを管理する方法を定義する 2 つの異なるタイプのコンピューティング アーキテクチャです。本質的にステートレスなシステムもあれば、モデル化されたステートフルなシステムもあります。どちらのアプローチを選択しても、設計チームと運用チームがソリューションを構築して維持する方法に影響します。

この記事では、ステートフル アプリとステートレス アプリの違いと、それぞれをいつ使用できるかについて説明します。また、2 つのモデルが DevOps 実装の要件にどのように影響するかについても説明します。

状態とは

サービスの「状態」は、あるトランザクションまたはイベント中に記録され、別のトランザクションまたはイベント中に呼び出される永続的な情報です。状態の最も単純な例の 1 つはデータベース サーバーです。データベース サーバーは、安全に保管する必要がある保管データを管理します。あるセッションで保存されたレコードは、次のセッションで使用できる必要があります。

状態は、将来的に使用できるように慎重に管理する必要があります。外部システムは、以前のイベントを参照するために多くの情報を提供する必要はありません。支払いトランザクション番号などの単純な識別子により、サービスは、支払い金額や配送先住所など、アクションに関連付けられた他のデータを回復できます。

ステートレス アプリケーションとは

すべてのアプリケーションに状態があるわけではありません。一部のシステムは、長期間有効なデータを処理したり、パフォーマンスを向上させるためだけにデータをキャッシュしたりしません。以前に保存されたデータが失われた場合でも、それらは機能します。

ステートレス アプリケーションは、各イベントを個別に処理します。イベントは、アプリケーションが実行されている他のイベントやより大きなコンテキストを認識しません。この品質により、ステートレス システムの検討が簡素化されます。以前のアクティビティが現在の操作に影響するリスクはありません。

アプリケーションはステートフルですか、それともステートレスですか?

一部のアプリケーションでは、ステートフル モデルとステートレス モデルの境界があいまいになっています。アプローチする視点に応じて、同じシステムを状態の有無にかかわらず表示できます。

クライアント側の Web アプリケーションは、通常、サービス オペレーターの観点からステートレスと見なされます。それらは、他のコンポーネントから独立した静的 Web サーバーでホストできます。アプリケーションは、ユーザーのデバイスに保存された設定や最近のページ履歴など、使用中に状態を蓄積する場合があります。この形式の状態は、アプリケーションの展開には影響しないため、DevOps チームには関係ありません。

アプリケーションがデータを格納する方法を調べることで、アプリケーションにステートフルまたはステートレスのデプロイメント モデルが必要かどうかを判断できます。永続性がない場合、またはデータがユーザーのデバイスまたは Amazon S3 などの無関係なストレージ プロバイダーにのみ保存されている場合、状態はありません。アプリケーションは、ファイル システムの書き込みやその他の変更によって環境を直接変更し、それらの変更を無期限に保持する必要がある場合、状態を保持します。

コンテナーとクラウドを使用した状態

最新のアプリケーションは、多くの場合、クラウドにコンテナーとしてデプロイされます。コンテナーは、副作用なしで置き換えることができる一時的な機能単位として設計されています。これは、それらが主にステートレスな計算コンポーネントであることを意味します。

ただし、コンテナを使用してステートフル システムをカプセル化することはできます。永続ボリュームは、個々のコンテナー インスタンスより長持ちする耐久性のあるストレージをマウントする手段を提供します。従来の VM やベア メタル デプロイと比較すると、その違いは、コンテナーの状態を管理する内部の意図に帰着します。

ステートフル システムをコンテナ化するには、状態がどこで発生し、どのように保存されるかを予測する必要があります。ボリュームにマップされないため、任意のファイルシステム パスを単純に書き込むことはできません。ボリュームがないと、コンテナが停止または交換されるとデータが失われます。アプリケーションがマウントされたボリュームへのパスを一貫して書き込むようにするために、リファクタリング期間が必要になる場合があるため、事前にデータ ストレージ要件を決定する必要があります。

ステータスが DevOps に与える影響

DevOps プロセスは、ステートフル サービスとステートレス サービスのどちらを使用するかに応じて調整する必要があります。ステートレス デプロイ モデルは、より多くの余裕を提供します。状態への絶え間ないアクセスを心配することなく、新しいコンテナーを簡単に開始し、複数の分散ノードにわたってそれらをスケーリングできます。

ステートフル サービスには、より思慮深い管理アプローチが必要です。各アプリケーション インスタンスには、共有状態へのアクセス権を付与する必要があります。これにより、スケーリングの制限が課される場合があります。たとえば、複数のノードが同時に書き込みアクセスでボリュームをマウントできるKubernetes ディストリビューションはほとんどありません。

どちらのタイプのアプリケーションでも、問題が発生する前に問題を認識できるように、積極的な監視が必要です。これは、ステートフル ソリューションにとってより重要です。なぜなら、ストレージ要件を先取りし、ボリューム マウントがいつコンテナー スケジューリング オプションに影響するかを判断する必要があるからです。ステートフルな展開は、通常のバックアップ戦略でもサポートする必要があります。

この状態は、環境を正確に再現することを困難にすることで、DevOps プロセスも複雑にします。開発者のマシンではとらえどころのないまま、問題が本番環境に存在する可能性があります。これらの問題は、診断が難しい場合があります。開発者がサンドボックスで問題を再現できるように、環境を複製するメカニズムを提供することで、環境をより管理しやすくすることができます。

状態は常に複雑さとオーバーヘッドを追加します。ボリュームやデータベースなどの状態管理ソリューションを構成して提供する必要があるため、継続的インテグレーション パイプラインがより複雑になり、保守が難しくなります。状態は、ほとんどの主要なアプリケーションで避けられないため、システムをステートレスに保つために一生懸命努力することは、無駄なニシンになる可能性があります。ツールとトレーニングを使用して、ステートフル アプリケーションを DevOps ルーチンにシームレスに統合することをお勧めします。

概要

ステートフル アプリケーションとステートレス アプリケーションの区別は、DevOps の成功にとって重要です。DevOps の観点から見ると、ステートフル アプリケーションは、各インスタンスに永続的なデータ ストアへのアクセスを許可する必要があるため、展開と保守がより困難になります。

ステートレス アプリケーションは環境から完全に分離されているため、通常、クラウドでのコンテナー化とスケーリングが容易になります。ただし、真のステートレス システムは比較的まれであるため、通常はステートフル データ ストアと組み合わされます。ステートフル デプロイをサポートするツールを構築しながら、可能な場合はステートレス コンポーネントにリファクタリングすることは、通常、最適化された DevOps とシステムの機能要件とのバランスをとる最も効果的な方法です。