11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。ヘッダを用いてセッション情報をリクエストに紐付けることが一般的です。付与されたリクエストを送ってきたクライアントをそのユーザーのものとして処理することになります。マイクロサービスアーキテクチャでは各サービスが独立してリクエストを処理する形になるため、セッション情報をいかに共有するかが課題となります。パターンあれこれというわけで、いくつか典型的な設計方針を集めてみたのでそれらの概要を紹介していきます。SSOそれぞれのマイクロサービスにサービス全体の認証を行うマイクロサービスを一つおき、その他のサービスには独立にセッションストアを持たせ、クライアントはそれぞれのマイクロサービスに対し個別に認証を行うパターンです。クライアントが直接マイクロサービスとやりとりする場合向けの設計だと思います。管理しなければなりません。認証を行うサービスにログイン検証の負荷が集中するのも難点です。中央集権型1の独立型と似ていますが、セッションストアを共通化したパターンがこちらです。用いてセッション情報をストアから読み出します。リボークも容易になるため、セキュリティインシデント時の対処もしやすいです。セッションストアは多くのサービスからのリクエストを受けるため、高い可用性が求められます。・ストアを使用せず、クライアントから送られるリクエストそのものにセッション情報を埋め込むパターンです。