Q&A
> こちらの記事では、ステートレス及びステートフルのメリット、デメリットについて以下のように記載されていました
当該記事は、「プロトコル単位」でのステートフル/ステートレスの話です。HTTPで構築することが前提のWebサービスでの話ではないのですが、それは承知していますか？
ステートレス、及びステートフルについて調べていたのですが、少々疑問があり質問させて貰いました。
こちらの記事では、ステートレス及びステートフルのメリット、デメリットについて以下のように記載されていました
**ステートフル** ステートフルなやり取りではサーバーはクライアントのセッション状態を保持している。 メリット ・やり取りが完結に済む ・それによりネットワークの帯域を節約できる デメリット ・クライアントの状態を都度把握しておかなければいけないのでクライアントが増えると負荷も増える ・サーバーを複数台設置する場合にはそれぞれのサーバー間でクライアントの状態を同期しなければいけない ・これらの理由によりスケールアウトには向かない **ステートレス** ステートレスなやり取りではサーバーはクライアントのセッション情報を保持しない。 メリット ・クライアントのリクエストは状態に依存せず、常にリソースに対する操作に必要十分な情報となる ・よってサーバーが増えてもそのままのリクエストでいつも同じリソースに対する操作ができる ・このためスケールアウトに向いている ・また処理がクライアントの状態に依らないので処理がシンプルになる デメリット ・やり取りが冗長になりがちである ・リソースへの操作が必要になる度にそのやり取りを繰り返す必要がある ・これによりネットワークの帯域を消費し、処理も遅くなる ・サーバーが状態を保持していないのでエラーが起きたときのハンドリングが複雑になりがちである
これらの情報を踏まえ何点かお聞きしたいことがあります。
仮に、認証機能を必要とする会員サイトでは、リクエストを送信する度に認証情報を付加しなければならない為、スケールアウトを必要としない小規模のサイトでは採用するメリットはあまりないのでしょうか?
また、逆にTwitterなどの大規模サービスでは、スケールアウトが必須かと思いますが、基本的にRESTfulAPIでのステートレスな手法を採用するのが、当然との認識であっていますでしょうか...?
どなたか、こちら２点の疑問点につきまして、ご助言の程頂けましたら幸いです。
なるほど。こちら、少々勘違いしていたかもしれません
ステートレス、ステートフルというのはREST APIで使用されるものだと思っていました。
質問者さん、その後無言ですか、追加の質問に回答したのでそれに対するフィードバックを書きましょう。解決したならクローズしてください。役に立たなかったならどこがダメだったか書くと望む回答により近いものが出てくるかも。とにかく無言で放置は NG です。
ちょっと仕事で返せなかったです。今、返信します！
解決したならクローズしてください。
JSESSIONIDなど原始的なランダム文字列のセッションID＋複数のREST APIサーバでは共有DBが必須です。この方法はもう廃れたと言っていいでしょう。
一歩進んでセッションの情報を持たせた文字列をHMACで暗号化することもよく行われています。認証サーバとREST APIサーバ間で共有された秘密鍵で復号化すれば平文が取り出せます。これならセッション維持のための共有DBは不要ですね（もちろん他の用途でDBは必要でしょうけれど）。小規模で自社のシステムで完結しているならこの方法でも十分でしょう。
ところで最近はOAuth2で他社が認証を行い、自社のREST APIサービスを提供することが多くなりました。認証とリソース(REST API)の分離などと言うこともあります。この場合秘密鍵を共有することができません。そこで公開二重鍵暗号を使う方法が提案されました。認証サーバが秘密鍵でセッション情報を暗号化し、REST APIサーバは公開鍵で検証するわけです。これで改竄は不可能になります。平文のデータ形式の標準化が課題となり、JWT(JSONウェブトークン）ができました。詳しくはWIkipediaで読んでみてください。セッションに紐づけられた属性情報の保持を認証サーバーからJWTに移すのがミソです。そのため一般にJWTは1キロバイト程度の大きさになります。REST APIサーバはトークンを見るだけで最低限の属性情報も得ることができるわけです。
回答1件
0
ベストアンサー
こちらの記事では、ステートレス及びステートフルのメリット、デメリットについて以下のように記載されていました
質問者さんが参考にした「こちらの記事」ではセッションのことしか述べてませんが、セッションはステートレスである Web アプリのステートを保つ一つの方法というだけで、他にもいろいろ手段はあります。
なので、「ステートフル」＝「セッション利用」ということではないです。
ステートを保つには、もともと HTTP 通信になら普通に利用できるクッキー、クエリ文字列、隠しフィールドなどの他に、アプリのフレームワークに備わった機能もあります。
例えば ASP.NET Core では以下の記事のような方法が使えます。
ASP.NET Core でのセッションと状態の管理
https://docs.microsoft.com/ja-jp/aspnet/core/fundamentals/app-state?view=aspnetcore-5.0
質問者さんの言うセッションはフレームワークに備わった機能で、必要に応じてサーバー側でユーザー固有の情報を保持しておき、クライアントにはユーザー固有のセッションクッキーを発行し、次回ユーザーがアクセスしてきた時送信されてくるクッキーを使ってユーザーを識別して、サーバーにあるセッション情報を取得して利用するというものです。（フレームワークによって多少実装は異なるかもしれません）
それから、ユーザー認証にセッションは使わないフレームワークもあります。ASP.NET がそうです。独自にセッションを使う認証方式を実装することはできますが、普通はセッションは使いません。
上記のこと、特に「ステートフル」≠「セッション利用」、必ずしもセッションをユーザー認証に使うわけではない・・・ということ踏まえてもらったうえで・・・
仮に、認証機能を必要とする会員サイトでは、リクエストを送信する度に認証情報を付加しなければならない為、スケールアウトを必要としない小規模のサイトでは採用するメリットはあまりないのでしょうか? また、逆にTwitterなどの大規模サービスでは、スケールアウトが必須かと思いますが、基本的にRESTfulAPIでのステートレスな手法を採用するのが、当然との認識であっていますでしょうか...?
質問者さんの言う「スケールアウト」＝「システムを構成するサーバーの台数を増やすことで、システムの処理能力を高める」ということですよね？
であれば、それとセッション利用は関係ないと思います。セッションを使う場合「リクエストを送信する度に認証情報」はセッションクッキーなので、サーバー側が小規模・大規模とは関係ないはずです。（Web ファームでセッション情報をどこに保持するかという話もあるかもしれませんが、それはまた別な話）
「大規模サービス」＝「RESTfulAPI」＝「ステートレス」というのは何かの思い違いです。
「大規模サービス」でもユーザー認証は必要でしょうから、ユーザー認証にセッションを使っていれば「RESTfulAPIでのステートレスな手法を採用するのが、当然」ということはないです。
投稿2021/10/14 01:36
編集2021/10/14 06:26退会済みユーザー
総合スコア0
ご回答ありがとうございます。
大変ご丁寧にご解説頂き、助かりました。
ただ、一点分からないのは、こちら https://qiita.com/mtakehara21/items/efcbbc3ba58a62c10eb6
記事などでデメリットとして、「送信するデータ量が多くなることによるパフォーマンスの低下」と挙げられていたのですが、セッションを使用した認証にもデータをリクエストの際に、セッション情報を送信する為、あまりパフォーマンスの部分で部分で差異はないのではないかと思っています。
こちら、パフォーマンス低下の主な原因というのは、どのようなものが原因になってきているのでしょうか...？
> こちら、パフォーマンス低下の主な原因というのは、どのようなものが原因になってきているのでしょうか...？
参考にした記事の話ですか？ その記事を書いた人がステートとセッションの意味を分かって書いているのか疑問ですが・・・
ステートを保つには、回答にも書きましようにクッキー、クエリ文字列、隠しフィールドなども使えます。セッションはその手段の一つに過ぎないと認識してください。「ステートフル」＝「セッション利用」ではないのです。
で、ステートを保つためにセッションを使うという話になった場合の話として、
> こちら、パフォーマンス低下の主な原因というのは、どのようなものが原因になってきているのでしょうか...？
クライアント側で保持して送信するのはセッションクッキーだけです。その程度で「送信するデータ量が多くなることによるパフォーマンスの低下」は考えなくても良いと思います。
サーバー側ではメモリなり DB なりにユーザー固有の情報を保持しておく必要がありますが、当然そのためのリソースは消費するわけで、大きなデータを保持したりすればサーバーのメモリとか DB に悪影響はあるでしょうし、シリアライズ/デシリアライズが必要な場合はそのためのオーバーヘッドもパフォーマンス低下の原因になり得ます。
なので、できればセッションは使わないか、使う場合でも必要最小限にとどめる必要はあります。
参考にされた記事はハンバーガー店の話も分かり難いし、見ない方が良いのでは？
ご返信ありがとうございます。
返信遅くなって申し訳ないです！
認証の部分に関しまして、セッションを使用したケースの方がスケールアウトしづらいが、処理が早い、REST APIを使用した方が、データを多くサーバー側へ送る為、処理が遅いといった勘違いがあったのですが、２つのケースに関していうと、あまり変わらないということですね。
詳細に教えて頂き、助かりました。
ありがとうございました。
認証、セッション、RESTful、ステートフル/ステートレス、認証クッキー、ベアラトークン、スケールアウト等々が具体的にどういうことか整理できてないままゴッチャに考えているような気がするのですが。
認証は、よくある Web サイト（ここ Teratail も）ではクッキーベースが多いですが、Web API (RESTful 含む）ではセキュリティ上ベアラトークンベースにすることが多いようです。
クッキーベースの認証にはセッションを使うことがあるようですが、トークンベースでセッションを使うことはないはずです。
そのあたりが整理できてないからいろいろ誤解しているような気がするのですが・・・
ありがとうございます！
トークン認証が採用されているサイトってあまりないのですかね...?
クッキーベースは確かに多い気がします。
今、トークンについて調べているのですが、少々複雑ですね...
ここら辺は、ある程度理解できるまでは調べる必要がありそうですね...
あなたの回答
tips
プレビュー
