ステートフルとステートレス

URL をコピー

ステートとは、ある特定の時点におけるアプリケーション (またはその他のさまざまなもの) の調子や品質、つまり、その状態のことです。あるものがステートフルかステートレスかは、別の何かとの通信の状態が記録される期間と、その情報をどのように保存する必要があるかによって決まります。ステートフル・アプリケーションでは、ユーザー、システム、コンポーネントなどとのやり取りに関する状態やコンテキストが保持されます。状態は永続的なストレージ・ソリューションに保存されるため、アプリケーションの再起動後も維持されています。ステートフル・アプリケーションとステートレス・アプリケーションの主な違いは、ステートフル・アプリケーションでは過去と現在の情報が保存されるのに対し、ステートレス・アプリケーションではそうではないことです。

Red Hat OpenShift でアプリケーションを変革する

ステートフルなアプリケーションやプロセスではその状態が保持され、すでに確立されている情報やプロセスをインターネット経由で保存し、記録し、繰り返し利用することができます。ステートフル・アプリケーションの場合、サーバーは各セッションまたはやり取りの状態を追跡し、ユーザーの過去の要求に基づいてその情報を維持します。それらのセッションは何度でも繰り返し利用できます。例としては、オンラインバンキングや E メールなどがあります。アプリケーションは以前のトランザクションのコンテキストに基づいて実行され、現在のトランザクションは、以前のトランザクション中に生じたことに影響を受ける可能性があります。そのため、ステートフル・アプリケーションは、毎回同じサーバーを使用してユーザーの要求を処理します。

ステートフルなトランザクションでは、中断された場合もコンテキストと履歴が保存されているため、中断したところから再開できます。ステートフル・アプリケーションは、ウィンドウの場所、ユーザー設定、最近のアクティビティなどを追跡します。ステートフル・トランザクションは、同じ人と定期的かつ継続して行う会話と考えることができます。

ステートフル・アプリケーションのユースケース

  • ユーザー中心のアプリケーション:ソーシャルメディアや電子商取引 Web サイトなどのユーザー中心のアプリケーションは、ログインしているユーザーのセッション (ユーザーの好みやショッピングカート内のアイテムなど) を追跡します。
  • IoT システム:IoT (モノのインターネット) システムは、データの送信、受信、分析をフィードバックループで継続的に行うことで機能しています。デバイスは、家庭用のサーモスタットのように、過去のデータまたはリアルタイムのデータに基づいて、時間の経過とともに変化する状態に対応します。
  • AI/ML モデルのトレーニング:人工知能および機械学習 (AI/ML) のトレーニングモデルは、データから学習し、そのデータを記憶します。学習と記憶の状態が維持されることで、モデルは最大限の能力を発揮できます。

ステートフル・アプリケーションが RAG により ML モデルとどのように関連しているかを学ぶ

Red Hat のリソース

ステートレスなアプリケーションやプロセスでは、ユーザーとの以前のやり取りに関する情報は保持されません。過去のトランザクションに関する知識は保存されず、参照されることもありません。トランザクションは常に、初めて発生したものであるかのようにゼロから行われます。ステートレス・アプリケーションは 1 つのサービスあるいは機能を提供するもので、コンテンツ配信ネットワーク (CDN)、Web、またはプリントサーバーを使用して、短期的な要求を処理します。

ステートレス・トランザクションの一例としては、思い浮かんだ疑問の答えを探すために行うオンライン検索が挙げられます。検索するときは、検索エンジンに質問を入力して Enter キーを押します。トランザクションが誤って中断されたり、クローズしたりした場合は、新しいトランザクションを開始するだけです。ステートレス・トランザクションは自動販売機のようなものです。つまり、単一の要求に対する単一の応答です。

ステートレス・アプリケーションのユースケース

  • REST API:REST アプリケーション・プログラミング・インターフェース (API) は、リソースの状態を表現したものをリクエスト元またはエンドポイントに転送します。各 API リクエストは個々に独立しており、サーバーは以前のリクエストに関する情報を保持しません。
  • マイクロサービス:マイクロサービスは、1 つのアプリケーション内の各コア機能をそれぞれ分離することを可能にします。そのためマイクロサービスは、ステートレス・アプリケーションとステートフル・アプリケーションのどちらにも適しています。
  • サーバーレス・アーキテクチャ:サーバーレス・アーキテクチャは、以前のアクションのコンテキストを保持せず、イベントに個別に対応するように設計されているため、状態を維持する必要がありません。サーバーレス・アーキテクチャは、即座に開始できる非同期のステートレス・アプリケーションに最適です。

API がアプリケーションの促進に役立つ仕組みを学ぶ

ステートフルとステートレスの主な違いは、アプリケーションがユーザーとの通信の現在の状態に関する情報を保持するか、各要求を個別の分離したトランザクションとして扱うかです。ただし、次のような明確な相違点もあります。

状態の保持

ステートフル・アプリケーションは通常、やり取りに関する情報を、データベースまたは分散型メモリーに保存します。ステートレス・アプリケーションはやり取りに関する情報を保存しないため、トランザクションは毎回ゼロからの開始となります。

セッション依存性

ステートフル・アプリケーションでは、各リクエストは、以前のやり取りやトランザクションからのデータやコンテキストに依存します。ステートレス・アプリケーションでは、各リクエストが新規として処理されるため、セッションの独立性が高く、アプリケーションはリクエストを処理するために必要な情報をすべて保持していなければなりません。

ストレージ依存性

ステートフル・アプリケーションは、永続的なストレージ (データベースや分散型ファイルシステムなど) を必要とします。ステートフル・アプリケーションは、基盤となるストレージ・ソリューションに依存し、インスタンス間でデータを同期化するための仕組みが必要です。

リソース使用量

ステートレス・アプリケーションでは、セッションデータの保存と管理が不要なため、多くの場合、リソース使用量が低くなります。ステートフル・アプリケーションはストレージへの依存性が高いため、セッション情報の処理と維持に、より多くのメモリーと処理能力が必要になる場合があります。

スケーラビリティ

ステートレス・アプリケーションでは、各要求が独立しており、負荷分散を使用して任意の利用可能なサーバーで処理できるため、一般にスケーラビリティが高くなります。ステートフル・アプリケーションは、インスタンスが密に結合しているため、スケーリングがそれだけ難しくなります。状態の管理、負荷分散、セッションの管理を行うために、Kubernetes 内に特定のインスタンスや pod が必要になる場合もあります。

フォールトトレランス

ステートレス・アプリケーションは、1 つのサーバーで障害が発生してもユーザーセッションに影響しないため、フォールトトレランスが高くなります。ステートフル・アプリケーションでは、セッションのレプリケーションやクラスタリングなどの追加の対策が講じられていない限り、サーバーが故障するとセッションデータが失われる可能性があります。

開発の複雑さ

ステートレス・アプリケーションでは、複数の要求にわたって状態を管理する必要がないため、開発と保守が比較的容易です。一方、ステートフル・アプリケーションでは、セッションデータや状態を慎重に取り扱う必要があります。

私たちが日常的に使用するアプリケーションの大部分はステートフルですが、テクノロジーの進歩に伴い、マイクロサービスコンテナによって、クラウドでのアプリケーションの構築とデプロイが容易になっています。

クラウド・コンピューティングとマイクロサービスの人気が高まるにつれ、(ステートフルかステートレスかにかかわらず) アプリケーションのコンテナ化も同様に増加しています。コンテナは、ライブラリや依存関係とともにパッケージ化された、アプリケーションコード一式です。コンテナ化されたアプリケーションは、デスクトップ、従来の IT インフラストラクチャ、クラウド上など、どのような環境にも簡単に移動して実行できます。

コンテナには元々ポータブルで柔軟という性質があるため、ステートレスなものとして構築されました。しかし、コンテナの使用が広がると、既存のステートフル・アプリケーションのコンテナ化 (コンテナから実行することを目的とした再設計と再パッケージ化) が始まりました。これにより、ステートフル・アプリケーションはコンテナのメリットである柔軟性とスピード、さらには、ステートフル性に伴うストレージとコンテキストを備えるようになりました。

このため、極めてステートレス的なふるまいをするステートフル・アプリケーション、あるいはその逆も見られるようになってきました。たとえば、ステートレスで長期のストレージを必要としないが、Cookie を使用して同じクライアントによる要求をサーバーが追跡できるアプリケーションを作ることもできます。

コンテナの人気が高まるにつれ、さまざまな企業がデータストレージ、KubernetesStatefulSets を使用してステートレスコンテナとステートフルコンテナの両方を管理する方法を提供するようになりました。ステートフル性は今やコンテナストレージの主要部分であり、ステートフルコンテナを使うかどうかというよりも、いつ使うかがポイントとなっています。

ステートフル・アプリケーションでもステートレス・アプリケーションでも、Red Hat にお任せください。ハイブリッドクラウド・アプリケーション・プラットフォームである Red Hat® OpenShift® 上でのステートフルコンテナのオーケストレーションであれ、Red Hat Application Foundations によるアプリケーション開発用の統合環境の構築であれ、Red Hat の受賞歴のあるサポートパートナー・エコシステムがお客様を支援します。

Red Hat OpenShift は、アプリケーションの開発とデプロイおよび運用プロセスのモダナイズを支援することでイノベーションの高速化を可能にする、セキュリティに重点を置いた統合ハイブリッドクラウド・アプリケーション・プラットフォームを提供します。Red Hat OpenShift は、Kubernetes StatefulSets のような、ステートフル・アプリケーションをサポートする機能を備えています。また Red Hat OpenShift Data Foundation を使用すると、ソフトウェア・デファインド・ストレージを提供し、永続ボリュームのプロビジョニングを支援するストレージ・ソリューションにより、ステートフルデータを管理できます。さらに、Red Hat OpenShift はステートフル・アプリケーションを DevOps のワークフローに統合します。Red Hat OpenShift PipelinesCI/CD パイプラインの各ステップを実行するように設計されており、ステートレスなワークロードに加えて、ステートフルなワークロードのテストとデプロイメントもサポート可能です。

Red Hat Application Foundations は、サービス構成とオーケストレーション、アプリケーションの接続性とデータ変換、リアルタイムのメッセージ・ストリーミング変更データの取得、そして API 管理機能を提供します。これらはすべてクラウドネイティブのプラットフォームおよびツールチェーンと結合して、先進的なアプリケーション開発の全領域をサポートします。

Red Hat OpenShift と Red Hat Application Foundations を併用すると、クラウドネイティブ・アプリケーションを開発および提供するための理想的なプラットフォームが実現します。お客様のニーズが何であれ、当社の製品群は The Open Source Way (オープンソースウェイ) により、ソリューションの構築、開発者の生産性向上、イノベーションの促進を支援できます。

Red Hat OpenShift がアプリケーションをサポートする仕組みを学ぶ

Red Hat OpenShift Virtualization を導入すべき 15 の理由

Red Hat OpenShift Virtualization は単一のプラットフォームで仮想マシンとコンテナを実行し、IT 運用を統合および単純化できます。その詳細をご覧ください。

すべての Red Hat 製品のトライアル

Red Hat の無料トライアルは、Red Hat 製品をハンズオンでお試しいただける無料体験版です。認定の取得に向けた準備をしたり、製品が組織に適しているかどうかを評価したりするのに役立ちます。

関連情報

アプリケーションの移行とは

アプリケーションの移行とは、アプリケーションをある環境から別の環境へと移すことでワークロードを改善できるプロセスのことです。

SDK (ソフトウェア開発キット) とは | Red Hat

SDK はソフトウェア開発キット (Software Development Kit) の略称で、プラグラムや API、開発ドキュメント等を含む、アプリケーション開発に必要なツール一式を指します。

IDE (統合開発環境) とは?をわかりやすく解説 | Red Hat

IDE (統合開発環境) とは、アプリケーション開発に必要な機能 (エディター、コンパイラー、デバッガー等) を 1 つの GUI で使えるようにまとめたプログラミング環境です。

アプリケーションの開発と提供リソース

関連記事