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

URL をコピー

ステートフル・アプリケーションとステートレス・アプリケーションの違いは、ステートフル・アプリケーションでは過去と現在の情報が保存されるのに対し、ステートレス・アプリケーションではそうではないことです。 

ネイティブ・アプリケーション導入における 8 つの考慮事項

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

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

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

ステートレス・アプリケーションの使用に役立つ API

Red Hat のリソース

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

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

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

  • スケーラビリティ:ステートレス・アプリケーションでは、各要求が独立しており、任意の利用可能なサーバーで処理できるため、一般にスケーラビリティが高くなります。ステートフル・アプリケーションでは、負荷分散とセッション管理のために、より複雑なメカニズムが必要になる場合があります。
  • フォールトトレランス:ステートレス・アプリケーションは、1 つのサーバーで障害が発生してもユーザーセッションに影響しないため、フォールトトレランスが高くなります。ステートフル・アプリケーションでは、セッション・レプリケーションやクラスタリングなどの追加の対策が講じられていない限り、サーバーが落ちるとセッションデータが失われる可能性があります。
  • リソース使用率:ステートレス・アプリケーションでは、セッションデータの保存と管理が不要なため、多くの場合、リソース使用率が低くなります。ステートフル・アプリケーションでは、セッション情報の処理と維持に、より多くのメモリーと処理能力が必要になる場合があります。
  • 開発の複雑さ:ステートレス・アプリケーションでは、複数の要求にわたって状態を管理する必要がないため、開発と保守が簡単になります。一方、ステートフル・アプリケーションでは、セッションデータと状態の管理を慎重に処理する必要があります。

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

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

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

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

ステートフルコンテナを使用するか、ステートレスコンテナを使用するかは、構築しているアプリケーションの種類や、必要な機能によって異なります。一時的な情報を迅速に取得することが必要な場合であれば、ステートレスがよいでしょう。しかし、アプリケーションがセッションをまたいだ情報の保存を必要とする場合は、おそらくステートフルを利用するのが適切です。

ステートフルでもステートレスでも、Red Hat にお任せください。エンタープライズ対応 Kubernetes プラットフォームである Red Hat OpenShift でのステートフルコンテナのオーケストレーション、Red Hat Integration によるアプリケーション開発用の統合環境の構築など、Red Hat の受賞歴のあるサポートと業界最大のパートナー・エコシステムが支援します。 

Red Hat OpenShift は、アプリケーションの開発とデプロイおよび運用プロセスのモダナイズを支援することでイノベーションの高速化を可能にする、セキュリティに重点を置いた統合ハイブリッドクラウド・アプリケーション・プラットフォームを提供します。また、アプリケーション・プラットフォームの実行場所や実行方法に制限はなく、柔軟に決定することができます。

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

当社のあらゆる製品がどのように The Open Source Way (オープンソースウェイ) でソリューションの構築、開発者の生産性向上、イノベーションの促進を支援するかをご覧ください。

クラウドでのステートフル・アプリケーションのコンテナ化について読む

ハブ

Red Hat 公式ブログ

Red Hat のお客様、パートナー、およびコミュニティのエコシステムに関する最新の情報を入手しましょう。

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

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

関連情報

プラットフォームエンジニアが Red Hat OpenShift を選ぶ理由

Red Hat OpenShift は、開発基盤の効果的な構築と管理を可能にするツールを提供し、プラットフォームエンジニアリングによる DevOps を支える協業プラットフォームです。

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

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

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

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

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

関連記事