みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします！ シルバーウィークの 5 連休、いかがお過ごしでしたか。どんどんと日が短くなり、1 年の残りを意識しはじめる季節になりましたね。 年末といえば、そのハイライトとなる AWS re:Invent 2026 が、いよいよ視界に入ってきました！今年は 11 月 30 日 (月) から 12 月 4 日 (金) までラスベガスで開催され、2,200 以上のセッションが予定されています。残りは 2 か月あまり。現地参加を検討されている方は、そろそろ社内の調整や渡航準備を動かし始めるタイミングですね。その判断材料として、AWS Startup ブログの連載 ラスベガス5日間で得たもの ── re:Invent に賭けたスタートアップのリアル をぜひご覧ください。技術のキャッチアップはもちろん、事業を動かす出会いやエンジニア採用にまで話が及んでいて、「現地でしか得られないもの」がとても具体的に語られています。記事は随時公開予定です。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年9月14日週の主要なアップデート 9/14(月) Gemma-4-31B-it-assistant および Gemma-4-31B-IT-NVFP4 モデルが Amazon SageMaker JumpStart で利用可能に Google DeepMind の Gemma-4-31B-it-assistant と NVIDIA の Gemma-4-31B-IT-NVFP4 が Amazon SageMaker JumpStart に追加されました。前者は Gemma 4 ファミリーのフラッグシップである 31B の dense モデルのアシスタント調整版で、テキストと画像の入力、256K トークンのコンテキストウィンドウ、140 以上の言語、ネイティブな関数呼び出し (function calling) に対応します。後者は NVIDIA ModelOpt で 4 ビット FP4 (NVFP4) に量子化した派生版で、メモリ使用量を約 18.5 GB (ベースモデル比 68% 削減) に抑え、約 2.5 倍高速な推論を実現しながら元モデルの 97〜99% の品質を維持します。SageMaker コンソールまたは SageMaker Python SDK から数クリックでデプロイできます。 Qwen3.6-35B-A3B-NVFP4 および Wan2.1-T2V-1.3B-Diffusers モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA が量子化した Qwen3.6-35B-A3B-NVFP4 と Alibaba の Wan2.1-T2V-1.3B-Diffusers の 2 つの基盤モデルが Amazon SageMaker JumpStart に追加されました。前者はエージェント型コーディング、マルチモーダル推論、長文コンテキスト理解に向けた Mixture-of-Experts (MoE) モデルで、NVFP4 量子化によりメモリ使用量を大幅に削減しています。後者は 1.3B パラメータのテキストから動画を生成するモデルで、8.19 GB の VRAM で動作します。いずれも SageMaker コンソールまたは SageMaker Python SDK から数クリックでデプロイできます。 9/15(火) Amazon Q Console から CloudTrail イベントを自然言語で分析 AWS CloudTrail が Amazon Q Console と統合され、自然言語で AWS アカウントのアクティビティを調査できるようになりました。SQL クエリの記述やログファイルの手動解析なしに、CloudTrail の設定確認、セキュリティ調査、運用トラブルシューティングを実行できます。Amazon Q Console はユーザーに代わって CloudTrail の証跡 (Trail)、関連する CloudWatch Logs ロググループ、CloudTrail Lake のイベントデータストアをクエリし、一般的なドキュメントではなく実際のアカウントアクティビティに基づいた回答を返します。Amazon Q Console がサポートされるすべての AWS 商用リージョンで利用できます。 AWS Direct Connect が専用接続の定額料金 (flat-rate pricing) を発表 AWS Direct Connect は、10 Gbps および 100 Gbps の専用接続 (Dedicated Connection) を対象とした定額料金モデルを発表しました。接続の帯域幅と、選択した地理的スコープに応じた月額固定料金を支払うことで、選択した料金ティアの範囲内であればデータ転送アウト (DTO) の課金が発生しません。地理的ティアは同一メトロからグローバルまでの 5 段階が用意されており、トラフィックのパターンに合った範囲を選べます。あわせて、冗長用の 2 本目のポートを追加料金なしで含む「ポートペア (port-pair)」という新しいプロビジョニング方式が導入されました。ポートペアの利用は推奨されていますが任意です。課金モードは接続ごとに設定でき、従量課金との切り替えも可能です。中国リージョンを除くすべての AWS 商用リージョンの Direct Connect ロケーションで利用できます。 9/16(水) Amazon Connect Talent が一般提供開始 Amazon Connect Talent は、AI エージェントが候補者の音声面接とスキル評価を代行する採用ソリューションで、今回一般提供を開始しました。Amazon が数十年にわたって蓄積してきた採用サイエンスに基づいて設計されており、構造化された AI 音声面接、コンピテンシーベースの評価、一貫した基準での候補者スコアリングを提供します。料金は候補者評価 1 件の完了につき 20 USD の従量課金で、シートライセンスや最低利用量のコミットメントはありません。初回利用のお客様は AWS 無料利用枠で最大 200 USD 相当のクレジットを利用できます。現時点ではバージニア北部リージョンとオレゴンリージョンのみで利用可能です。 Amazon Connect Customer がカスタムメトリクスの API による作成・管理・検索に対応 Amazon Connect Customer に、カスタムメトリクスをプログラムから管理するための 7 つの API (CreateMetric、DeleteMetric、DescribeMetric、ListMetrics、SearchMetrics、UpdateMetricContent、UpdateMetricMetadata) が追加されました。これまでコンソールでの手動作業が必要だったカスタムメトリクスの定義を、コードとして一元管理できるようになります。複数のインスタンスや環境にメトリクス定義を展開する際の定義のずれ (drift) を防ぎ、すべての変更は AWS CloudTrail に記録されます。Amazon Connect Customer が提供されるすべての AWS リージョンで利用できます。 Amazon ECS が Amazon S3 Files のサポートを Amazon EC2 起動タイプに拡張 Amazon ECS の EC2 起動タイプで実行するタスクから、Amazon S3 Files ボリュームをマウントできるようになりました。S3 Files は Amazon EFS 上に構築された共有ファイルシステムで、S3 バケット内のデータをコード変更なし、コピーやステージングなしに標準的なファイル操作で読み書きできます。これまで AWS Fargate と Amazon ECS Managed Instances で利用可能でしたが、今回の拡張によりAmazon ECS を含む 3 つの起動タイプすべてで同じ仕組みを使えるようになりました。すべての AWS 商用リージョンと AWS GovCloud (US) リージョンで利用できます。 9/17(木) Amazon Quick が個別シートの生成と画像からの分析構築に対応 Amazon Quick の Generate Analysis 機能が拡張され、ダッシュボード作成を効率化する 2 つの機能が追加されました。1 つ目の Generate Sheet は、開いている分析の中に自然言語の指示だけで単一のシートを追加する機能です。2 つ目は、既存ダッシュボードの画像 (他社 BI ツールのものを含む) をプロンプトに添付し、編集可能な分析として再構築する機能です。どちらも生成結果は通常の Amazon Quick の分析であり、公開ワークフロー、埋め込み、CI/CD パイプライン、手動編集とそのまま組み合わせて使えます。提供開始時点では Enterprise サブスクリプションの Author Pro ユーザーが対象で、Author ユーザーも、組織がアクセスを制限していない場合は 2026 年 12 月まで Amazon Quick Enterprise のプロモーションアクセスで利用できます。どちらの機能も、Amazon Quick が利用可能なすべての AWS リージョンで一般提供されています。 AWS Elastic Beanstalk が共有インフラストラクチャ上で複数のアプリケーションを実行する Cluster Mode を導入 AWS Elastic Beanstalk に新しいデプロイモード「Cluster Mode」が追加されました。従来の Standard Mode がアプリケーションごとに専用環境を作るのに対し、Cluster Mode は Amazon EKS を基盤とする、アカウント内のプールされたインフラストラクチャ上で複数のアプリケーションを実行します。ソースコード、Dockerfile、Amazon ECR のコンテナイメージのいずれかを渡すだけで、コンテナ化からプロビジョニング、運用まで Elastic Beanstalk が管理するため、Kubernetes の運用は Elastic Beanstalk 側に任せられます。追加料金はなく、EKS クラスターと EKS Auto Mode を含む消費リソース分のみ課金されます。Elastic Beanstalk が提供されるすべての AWS 商用リージョンで利用できます。 AWS Transfer Family が Network Load Balancer (NLB) 配下の SFTP サーバーで送信元 IP 保持をサポート AWS Transfer Family の SFTP サーバーが、PROXY protocol v2 (PPv2) によるクライアント送信元 IP の保持に対応しました。従来、VPC ホスト型エンドポイントの前段に NLB を配置すると、Transfer Family には NLB のプライベート IP しか見えず、ログ、イベント、カスタム ID プロバイダーの認証リクエストに実際のクライアント IP が記録されませんでした。本アップデートにより、NLB ターゲットグループの PPv2 と、サーバー側で SftpMode を PROXY_PROTOCOL_V2_ENFORCED に設定することを組み合わせて、クライアントの実 IP を IP ベースの認可、監査、コンプライアンス用途に利用できます。なお強制モードに切り替える際は、先に NLB ターゲットグループ側で PPv2 を有効化し、すべての接続で PPv2 ヘッダーが届いていることをログで確認してから切り替えてください。ヘッダーのない経路が残っていると、その接続は拒否されます。あわせて、VPC エンドポイントのセキュリティグループは信頼する NLB 経由の通信のみを許可するよう制限する必要があります。Transfer Family が利用可能なすべての AWS リージョンで利用できます。 9/18(金) AWS PrivateLink がネットワークセグメントへのアクセスを可能にする Tunnel Endpoint を発表 AWS PrivateLink に新しいタイプの VPC エンドポイントである Tunnel Endpoint が追加されました。CIDR 範囲 (ネットワークセグメント) を表す Resource Configuration を作成して AWS RAM で共有すると、共有を受けた側は Tunnel Endpoint を作成し、GENEVE カプセル化を使ってその CIDR 範囲内のリソースにプライベートにアクセスできます。従来はリソースを 1 つずつ Resource Configuration として登録する必要がありましたが、CIDR 単位での共有により、外部のベンダーなどに多数のリソースをまとめて共有できます。料金は Tunnel Endpoint の時間課金と、エンドポイントを通過したデータ処理量に応じた GB 単価の課金です。東京リージョン、大阪リージョンを含む 28 リージョンで利用できます。 新しい AgentCore Runtime が Amazon Bedrock AgentCore で利用可能に Amazon Bedrock AgentCore のサーバーレス microVM コンピュートである AgentCore Runtime の次世代バージョン (platformVersion V2) が利用可能になりました。V2 の主眼は、コンテナイメージのサイズや同時実行数に関係なくコールドスタート時間が一定になることです。エージェント環境を一度準備してスナップショットを取得し、新しいインスタンスはそこから復元する方式により、200 MB から 2 GB のコンテナイメージで P75 コールドスタート 1.9〜2.0 秒を達成しています (V1 は 5.4〜30 秒)。またエラスティックメモリ管理 (elastic memory management) により、セッション中に未使用となったメモリを回収し、ピークではなく実使用量に基づいて課金されます。事前プロビジョニング不要、ゼロスケール、ハードウェアレベルのセッション分離といったサーバーレスの特性はそのまま維持されます。バージニア北部、オハイオ、オレゴン、アイルランド、東京の 5 リージョンで利用でき、ランタイムの作成時と更新時に platformVersion を V2 に設定するだけで有効化できます。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供を開始しました。Moonshot AI によると、Kimi K3 は同社の最も高性能なモデルであり、オープンモデルとして初めて 2.8 兆パラメータに到達したモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを備え、大規模リポジトリをまたぐ長時間のコーディングセッション、スキャンページやスクリーンショットを含む複数ドキュメントの分析、長時間のエージェントワークフローに適しています。Moonshot AI によると、前世代の Kimi K2 と比較してスケーリング効率が約 2.5 倍向上しています。Bedrock 上のオープンウェイトモデルとして初めて明示的プロンプトキャッシュに対応し、キャッシュ読み取りは通常入力の 10 分の 1 の単価で課金されます。提供はクロスリージョン推論経由で、Amazon Bedrock が利用可能なすべての AWS リージョンから呼び出せます。US Geo 推論プロファイルとグローバル推論プロファイルが用意されており、東京リージョン、大阪リージョンからも利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

はじめに こんにちは、EC基盤開発本部SRE部カート決済SREブロックの金田です。テックリードとして、ZOZOTOWNのカート決済機能のリプレイスや運用を担当しています。 カート決済SREブロックでは、Slackを起点としたChatOpsで運用作業の自動化に取り組んでいます。以前の記事で紹介したAWS Chatbotベースの基盤を約2年運用する中で、アクセス制御とツール追加コストの課題が見えてきました。本記事ではその課題と、Argo Eventsを軸にChatOps基盤を再構築した取り組みを紹介します。 目次 はじめに 目次 背景・課題 課題1: アクセス制御が粗い 課題2: ツール追加のハードルが高い 新基盤の要件 新しいChatOps基盤の全体像 Slackの制約と信頼チェーンによる認可 制約1: Workflowの投稿からは実行者が分からない 制約2: 3秒ルールとリトライ 制約3: 署名検証には生のリクエストボディが必要 制約4: Request URLはSlack Appごとに1つ 信頼チェーンで実行者を特定する Gatekeeperによる認可、承認、監査の一元化 SSMポリシーによる宣言的な認可 危険な操作への承認フロー 許可も記録する構造化監査ログ なぜArgo Eventsなのか Argo Eventsを本番運用に載せる設計判断 EventBusは高可用性をあえて求めない 監視の組み込み Sensorはルーティングだけ、実行権限はexecuteだけ K8s Jobによるツール実行機構 PodTemplateでツールのJob定義を配布する マルチテナント設計とツール追加の体験 共通の入口と、テナントごとの実行スタック ツールに渡す標準ペイロード ツール追加はSSMポリシーとマニフェストだけ 導入の効果 まとめ 背景・課題 カート決済SREブロックでは、過熱商品（発売開始時などにアクセスが急激に集中する人気商品）の登録などの運用作業をSlackから実行できるようにしています。従来の基盤は「Slack Workflow → AWS Chatbot → AWS Lambda」という構成でした。非エンジニアでもSlack Workflowのフォームに入力するだけで運用ツールを実行できます。構成の詳細や、コマンドラインツールをLambda関数化した工夫は以下の記事で紹介しています。 techblog.zozo.com 本記事は、この構成を約2年運用した先の話です。ツールと利用者が増え、この先さらに運用業務のツール化を進めるにあたって、次の2つの課題が無視できなくなりました。 課題1: アクセス制御が粗い AWS Chatbotのアクセス制御は、チャネルに紐付くIAMロールとガードレールポリシーが基本です。前回の記事でも当時できる範囲の制御を紹介しましたが、次の要素は仕組みとして実現できませんでした。 「どのチャネルで、誰が、どのコマンドを」実行できるかという、コマンド単位かつユーザー単位の認可 削除などの危険な操作に対する、実行前の承認フロー 「誰が何を実行し、なぜ許可されたのか」を機械的に追跡できる監査ログ 実行したコマンドはSlackのメッセージとして残ります。しかし、それは人が目視で追える履歴であって、拒否された実行や許可の判断根拠まで含めて検索や集計ができる監査ログではありません。運用ツールの中にはデータを書き換える操作も含まれるため、利用者が増えるほどこの粗さがリスクになっていきました。 課題2: ツール追加のハードルが高い AWS Chatbotから実行できるのはLambdaをはじめとするAWSリソースの操作だけです。運用ツールをChatOpsに載せるには、1コマンドで完結するような簡単な処理でも、ツールごとにLambda関数を実装する必要がありました。これが新しいツールを導入する際の障壁になっていました。 さらに、カート決済SREブロックの運用ツールにはEKS上のJobとして動かしたいものもあります。コンテナイメージとして完成しているツールでも、ChatOpsに載せるためだけにLambdaへ移植するのは本末転倒です。実行形態がLambdaに縛られていることが、この障壁をさらに高くしていました。 新基盤の要件 課題を整理して、新しいChatOps基盤に求める要件を次のように定めました。 分類 要件 認可 コマンド、ユーザー、チャネルの単位で実行可否を制御できる 承認 危険な操作は、権限を持つ承認者の承認を経てから実行される 監査 許可も拒否も、すべての実行判断が構造化ログとして残る 実行形態 K8s JobとLambdaのどちらでもツールを実装できる UX 非エンジニアは従来と同じSlack Workflowのフォームから実行できる 拡張性 ツールの追加や利用チームの拡大時に、基盤側の変更が不要である 新しいChatOps基盤の全体像 この要件を満たすために構築した、新基盤の全体像を示します。 図の中心は、EKSの手前に置いた Gatekeeper Lambda です。認証、認可、承認、監査を一手に担う関門です。その先のEKSでは、 Argo Events が認可済みのイベントを受けてツールを起動します。 1リクエストの流れを追うと次のようになります。 利用者がSlack Workflowのフォームに入力して送信すると、WorkflowがBotとして所定のチャネルにコマンドを投稿する Slack AppがEvents APIでこの投稿を受け取り、API Gateway経由でGatekeeper Lambdaに配送する Gatekeeperが署名検証、実行者の特定、ポリシー評価を済ませ、許可した場合のみペイロードを正規化してEKSのinternal ALBへ転送する ALBの先にいるArgo EventsのWebhook EventSourceがイベントを受け、EventBusへ流す Sensorがイベントの種別と承認要否を見てK8s Jobを作成する。承認が必要なコマンドは承認リクエストを投稿するJob（dispatch）へ、それ以外は実行を担うJob（execute）へ振り分ける ツール本体がK8s JobまたはLambdaとして実行され、結果をSlackのスレッドに通知する この流れはWorkflow経由のものです。エンジニア向けには、Botへの直接メンションとSlash Commandの経路もあり、いずれも同じAPI GatewayとGatekeeperを通ります。本記事では、非エンジニアも使うWorkflow経由を軸に説明します。 設計の方針は次の通りです。認証、認可、承認、監査は、実行基盤であるEKSの手前のGatekeeperで一元化します。EKS側はArgo Eventsでイベントを受けて実行に専念します。Slackとの接点は単一のSlack Appに集約し、ツールを追加してもSlack App、API Gateway、Gatekeeperには手を入れない構造にします。 この分担により、Argo Events以降には「誰が何を実行するか」が確定した正規化済みイベントだけを流します。SlackプロトコルとのやりとりはGatekeeperで完結しているため、EventSourceはSlackの署名を検証する必要がありません。Gatekeeperと共有するBearerトークンで、Gatekeeper自身を認証するだけで済みます。 Slackの制約と信頼チェーンによる認可 設計で最初に向き合ったのは、Slackプラットフォーム特有の制約です。 制約1: Workflowの投稿からは実行者が分からない Slack Workflowが投稿したメッセージの送信者は、実行した人ではなくWorkflowのBotです。Events APIで受け取るイベントの user フィールドを見ても、そこにいるのはBotであって「フォームに入力した人」ではありません。コマンド単位かつユーザー単位の認可には実行者の特定が必須なので、これは基盤の成立に関わる制約です。 制約2: 3秒ルールとリトライ SlackのEvents APIは、3秒以内に応答がなければ配送失敗とみなしてリトライします。Gatekeeperの中で重い処理はできません。そこで、EKSへの転送タイムアウトを2秒に設定し、認可判断と転送だけを行って即座に応答を返す構造にしました。また、リトライによる同一イベントの再配送に備えて、Gatekeeperで重複を排除しています。 制約3: 署名検証には生のリクエストボディが必要 Slackのリクエスト署名は、タイムスタンプとリクエストボディを連結した文字列から計算されます。リクエストの認証は API GatewayのLambda Authorizer へ分離するのが定石ですが、Authorizerにはリクエストボディが渡されません。つまりSlackの署名検証はAuthorizerでは実現できません。そのため認証を分離せず、署名検証から認可までをGatekeeperという1つのLambdaに集めています。 制約4: Request URLはSlack Appごとに1つ SlackがAppへリクエストを届ける先のURL（Request URL）は、機能ごとにApp全体で1つです。Events API、Slash Commands、Interactivity（承認ボタン）のいずれも、テナント別に別のURLを設定できません。そこで全テナント共通の単一エンドポイント POST /chatops ですべてを受け、どのチームのコマンドかの解決はGatekeeperがchannel-mapで行う構造にしました。経路ごとにペイロードの形式は異なりますが、Gatekeeperがパースして同じ正規化ペイロードに変換します。 一方、環境の軸では同じ制約に悩まされます。dev、stg、prdでURLを分けられないため、Slack Appは環境別に作ります。Appの複製にはApp Manifestが使え、設定ファイルをリポジトリ管理すればレビューも可能です。さらに、Slash Commandの名前はワークスペース内でグローバルです。そのためdevとstgのコマンド名には環境サフィックスを付け（例： /example-tool-dev ）、Gatekeeperがコマンドの解釈時にサフィックスを除去します。 つまり「単一Slack App」とは、同一環境内のテナント間で1つという意味です。テナント軸は1つのAppに集約し、環境軸はAppごとに分離します。この線引き自体が、Slackプラットフォームの制約から導かれた設計です。 信頼チェーンで実行者を特定する 制約1で挙げた「実行者が分からない」問題への答えが、信頼チェーンです。 Workflowのフォームには実行者を示す入力欄があり、投稿されるメッセージ本文に実行者のユーザーIDが埋め込まれます。ただし、本文に書かれた実行者を無条件に信じると、任意のユーザーが他人になりすませてしまいます。そこで「本文中の実行者情報を信頼してよい条件」を、次の連鎖として構成しました。 Slackの署名検証により、イベントがSlackから来たことを保証する イベントの bot_id が、事前に登録した「信頼できるWorkflow」のものと完全一致することを確認する 要求されたコマンドが、そのWorkflowに許可されたコマンドの範囲内であることを確認する ここまで通って初めて、本文中の実行者情報を「Workflowのフォームが埋め込んだ値」として信頼する bot_id はWorkflowごとに払い出される識別子で、そのWorkflow以外は同じ bot_id で投稿できません。人間が手打ちで偽装したメッセージは投稿者が人間のuser_idになるため、Bot投稿とは必ず区別できます。実行者の情報は、Workflowのテンプレートに埋め込んだ「このワークフローを開始した人」という変数でSlackが自動的に挿入します。フォームの入力者はこの値を偽装できません。そしてWorkflowの編集コラボレーターを管理者に限定することで、テンプレート自体の改変も防いでいます。この運用条件までを含めて、実行者情報の信頼が成立します。 一方、Botを経由しない人間の直接メンションでは、イベントの user をそのまま実行者として使います。この経路では本文中の実行者情報を信頼しません。経路によって、何を信頼するかを切り替えています。 この認可はfail-closedに設計しています。 bot_id が未登録なら拒否、Workflowに許可されていないコマンドなら拒否、実行者情報が取れなければ拒否です。拒否はすべて理由コード（ untrusted_bot 、 requester_missing など）付きでログに残します。 なお、移行にあたって既存のSlack Workflowは作り直さず、投稿先の差し替えで対応しました。Workflowを作り直すと bot_id が変わってしまうためです。 bot_id を登録制にする設計は、こうした運用上の注意点とセットになります。 Gatekeeperによる認可、承認、監査の一元化 信頼チェーンで実行者が特定できたら、次はポリシー評価です。Gatekeeperが1つのリクエストに対して行う処理は、順に次の通りです。 Slack署名の検証と、リトライによる重複リクエストの排除 チャネルIDからのテナント解決 信頼チェーンによる実行者の特定 ポリシー評価（チャネル、コマンド、ユーザー、グループ、Workflow） 承認要否の判定と、正規化ペイロードのEKSへの転送 1〜3はここまでに説明した通りです。残るは4と5、すなわちポリシーによる認可と承認フロー、そしてその記録です。 SSMポリシーによる宣言的な認可 認可のルールはAWS Systems Manager Parameter Store（以下、SSM）に置いています。構造は2段階です。 1つ目は /chatops/channel-map で、SlackのチャネルIDからテナント（チーム）とチャネルラベルを解決します。チャネルIDという環境依存の値を持つのはこのマップだけで、各ツールのポリシーはラベルだけを参照します。 { " C0123456789 ": { " tenant ": " zozo-cart ", " label ": " ops " } } 2つ目は /chatops/policy/{テナント}/{ツール} で、ツールごとに次を宣言します。 コマンドごとの許可チャネル（ラベル）と、許可ユーザーおよび許可グループ（SlackのUser Groupを利用） コマンドごとの承認要否と承認者 ツールの実行形態（K8s JobまたはLambda）と失敗時の連絡先 { " invoke ": { " type ": " k8s-job " } , " failure_contact ": " <!subteam^S0AAAAAAA> ", " commands ": { " info ": { " allowed_channels ": [ " ops " ] , " allowed_users ": " * " } , " update ": { " allowed_channels ": [ " ops " ] , " allowed_groups ": [ " S0BBBBBBB " ]} , " delete ": { " allowed_channels ": [ " ops " ] , " allowed_groups ": [ " S0BBBBBBB " ] , " requires_approval ": true , " approver_groups ": [ " S0CCCCCCC " ] , " allow_self_approval ": false } } , " trusted_workflows ": [ { " bot_id ": " B0XXXXXXXXX ", " allowed_commands ": [ " update " ]} ] } コマンドのキーは、ツールが実際に受け付けるサブコマンド名と一致させます。ツール側も宣言にないコマンドを拒否するため、ずれているとGatekeeperの認可を通ったコマンドさえツールが弾いてしまいます。信頼チェーンで使うWorkflowの bot_id も、このポリシーの trusted_workflows で登録します。 ユーザー単位の認可は、個人ID（ allowed_users ）とSlack User Group（ allowed_groups ）のORで判定します。メンバーの異動のたびにポリシーを書き換えずに済むよう、基本はUser Groupで宣言し、GatekeeperがSlack APIでメンバーを展開して判定します。この展開に失敗した場合は、許可側に倒さず拒否します（fail-close）。判断材料が欠けた状態で通すと、認可そのものが形骸化するためです。 ポリシーの追加や変更はSSMパラメータの更新だけで済み、Gatekeeperのデプロイは不要です。ただし、誰でも更新できるわけではありません。ポリシーはCloudFormationで管理し、変更にはPRレビューを必須にしています。信頼チェーンの起点になる trusted_workflows への bot_id の登録も、このレビューを通ります。認可ルールを書き換える手段が野放しでは、認可の仕組み全体が意味を失うためです。 GatekeeperはSSMとSlack APIのスロットリングを避けるため、ポリシーとUser Groupを5分間キャッシュします。変更の反映が最大5分遅れることは、運用上許容できるトレードオフと判断しました。この遅延は、緊急のアクセス権限の剥奪でも同じだけ発生します。即時に止める必要があれば、Lambdaの実行環境を入れ替えてキャッシュごと破棄できます。 危険な操作への承認フロー ポリシーで承認が必要と宣言されたコマンドは、即座には実行されません。まずdispatch Jobが、実行内容と承認ボタンを含むメッセージをSlackに投稿します。承認者がボタンを押すと、そのコールバックが再びGatekeeperに届きます。Gatekeeperは押した人がポリシー上の承認者であることを検証し、DynamoDBを使ったワンショット制御で同じ承認が二度実行されないことを保証してから、実行イベントをEKSへ転送します。 承認の細部もポリシーで宣言できます。承認には有効期限（ approval_ttl_minutes ）があり、期限を過ぎた承認リクエストは失効します。実行を依頼した本人による自己承認を許すかどうか（ allow_self_approval ）も制御でき、危険な操作では自己承認を禁止しています。 承認のコールバックも入口はコマンド投稿と同じGatekeeperです。認可の判断ロジックが1か所に集まっているため、「承認ボタンを押せる人の検証が漏れる」といった抜け道が生まれにくい構造になっています。 許可も記録する構造化監査ログ Gatekeeperは、拒否だけでなく許可した実行も構造化ログとして記録します。テナント、チャネル、コマンド、実行者、経路（Workflow経由または直接メンション）、判断結果と理由コードがワンレコードに収まっています。そのため「先月このコマンドを実行したのは誰か」「特定ユーザーの実行が拒否された理由は何か」をログ検索だけで答えられます。 { " event ": " chatops_allowed ", " team ": " zozo-cart ", " channel_id ": " C0123456789 ", " command ": " example-tool update ", " user_id ": " U001 ", " via ": " workflow/B0XXXXXXXXX " } { " event ": " chatops_denied ", " team ": " zozo-cart ", " channel_id ": " C0123456789 ", " command ": " example-tool delete ", " user_id ": " U003 ", " reason ": " user_not_allowed " } 拒否ログだけでは監査になりません。インシデント調査で本当に知りたいのは「誰が実行できたのか」だからです。許可の記録を含めて初めて、実行の全体像を後から再構成できます。 もう1つの設計点は網羅性です。Gatekeeperのすべてのレスポンス経路は、許可、拒否、リトライ破棄、転送失敗といったいずれかのイベント種別で必ずログに残ります。「ログに現れない実行」は構造上存在しないという性質が、監査ログとして信頼するための前提です。 なぜArgo Eventsなのか 入口の関門はこれで揃いました。次はEKS側、受け取ったイベントを実行する基盤です。Argo Eventsは、Kubernetes上でイベント駆動の処理を実現するためのツールです。次の3つのコンポーネントで構成されます。 EventSource : Webhookなどでイベントを受信してEventBusへ流す EventBus : イベントを配送するメッセージバス（NATS JetStreamを使用） Sensor : イベントをフィルタし、条件に合致したらトリガー（K8s Jobの作成など）を発火する 採用の決め手は次の3点です。 イベントを受けてK8s Jobを起動する仕組みを、自作せずに宣言的なマニフェストで実現できる EventSource、EventBus、SensorがすべてKubernetesリソースなので、既存のGitOps（Flux）の管理に乗る ZOZOではArgo WorkflowsのCronWorkflowを運用済みで、Argoエコシステムの運用知見がある これに加えて、他チームの案件でArgo Events自体の導入がすでに決まっており、クラスタにはコントローラも導入済みでした。技術的な適合とは別の要素ですが、この状況も採用を後押ししました。 Argo Eventsを本番運用に載せる設計判断 そのArgo Eventsを本番の実行基盤として運用するうえで、設計判断がいくつかありました。 EventBusは高可用性をあえて求めない EventBusはNATS JetStreamで構成しています。ストリームには300秒の重複排除窓を設定しており、再送があってもJobが二重に走らない構造です。Slackのリトライは手前のGatekeeperで破棄済みのため、この窓が受け持つのはArgo Events内部の再配送だけです。 レプリカ数は、本番も含めて1にしています。運用コマンドの実行基盤は、決済のようなミッションクリティカルなデータパスではありません。EventBusが短時間止まっても、利用者がコマンドを打ち直せば回復できます。 むしろ判断が要ったのは永続化です。JetStreamはPersistentVolumeへの永続化を構成できますが、この基盤では設定せずemptyDirのまま使っています。EventBusを通るのは、EventSourceが受けてからSensorがJobを作るまでのごく短命なイベントだけです。承認待ちのような長寿命の状態はDynamoDB側が持つため、JetStreamには残りません。そしてPVを付けても「EventBusの再起動中に届いたコマンド」は受けられないので、取りこぼしはゼロにならず、EBSのアタッチを挟むぶん復帰はかえって遅くなります。どちらの失敗でも受付通知が返らないため、利用者は気付いて再実行できます。それなら復帰が速い構成を選ぶ、という判断です。 PodDisruptionBudgetはクラスタポリシーが存在を要求するため置いていますが、 minAvailable: 0 でevictionを妨げない値にしています。単一レプリカで止まることを受け入れる方針を、PDBの値でも一貫させています。 なお、これはテナント単位の判断です。EventBusを含むArgo Eventsのリソース一式はテナントごとに独立しているため、高い可用性が必要なチームは、自分のテナントだけレプリカ数や永続化を引き上げられます。 監視の組み込み EventBus、EventSource、SensorはいずれもPrometheus形式のメトリクスを公開しています。このメトリクスをDatadogのAutodiscoveryアノテーションでスクレイプして、NATSとArgo Eventsの状態を既存の監視基盤に載せています。イベントの滞留や配送失敗を、他のサービスと同じダッシュボードとアラートの体系で扱えます。 Sensorはルーティングだけ、実行権限はexecuteだけ Sensorのフィルタは、イベント種別と承認要否によるルーティングだけです。承認が必要なコマンドは承認リクエストを投稿するdispatch Jobへ、承認不要なコマンドと承認済みのコールバックは実行を担うexecute Jobへ振り分けます。認可はGatekeeperで完結済みなので、Sensorに認可のロジックはありません。 実行（Lambda invokeとK8s Jobの作成）をexecute Jobに一本化しているのは、実行権限を1か所に集約するためです。Lambdaを呼べるIAMロールとJobを作れるRBACは、execute JobのServiceAccountだけに与えます。承認リクエストを投稿するだけのdispatch Jobは、実行権限を一切持ちません。なお、dispatchとexecuteは2つのサブコマンドを持つ1つのバイナリで、ペイロードの型とSlack通知の実装を共有しています。 K8s Jobによるツール実行機構 PodTemplateでツールのJob定義を配布する ツールをK8s Jobとして実行するには、「どんなPodを起動するか」の定義が必要です。この定義を v1 PodTemplate リソースとしてテナントのnamespaceに配布し、実行時にexecute Jobが PodTemplate を読んでJobを組み立てる方式にしました。 検討のポイントは、このテンプレートをどこに置いておくかでした。テンプレートもGitOps（Flux）の管理に乗せたいので、Kubernetesのオブジェクトとしてクラスタ上に置けるリソースが優先候補になります。素直に kind: Job のマニフェストを置く案が最初に浮かびますが、Jobは作成された時点で1回実行されるリソースなので、配布と同時に動いてしまい成立しません。 suspend: true のCronJobなら起動せずに置いておけます。ただし、suspendの解除ミスで意図せず動いてしまう危うさが残ります。PodTemplateは単体では何も実行しないKubernetesネイティブのリソースで、スキーマ検証も効きます。「実行されないテンプレート」という意図を、運用ルールではなく構造で表現できます。 Jobレベルの設定はテンプレート側に持たせず、実行機構側で決めています。リトライはさせず（ backoffLimit: 0 ）、完了したJobは1時間で自動削除します（ ttlSecondsAfterFinished: 3600 ）。例外は実行時間の上限（ activeDeadlineSeconds ）で、これはツールごとに変えたい値です。ただしPodTemplateが持てるのはPodのspecだけで、Jobレベルのフィールドは書けません。そこで、この値はPodTemplateのannotationで宣言してもらい、実行機構がJobを組み立てる際に読み取って反映する形にしました。テナントが管理するのはPodの中身だけ、Jobとしての振る舞いは基盤が統一する、という責務の線引きです。 テナントが配布するPodTemplateのマニフェストは、次のような形です（抜粋）。 apiVersion : v1 kind : PodTemplate metadata : name : zozo-cart-chatops-template-example-tool annotations : # JobレベルのactiveDeadlineSeconds（実行機構がJob specに設定する） chatops.zozo.com/job-active-deadline-seconds : "900" template : metadata : labels : app : zozo-cart-chatops-tool spec : restartPolicy : Never containers : - name : example-tool image : example-tool:<tag> # イメージのフルURIはoverlayのpatchが与える command : - example-tool - chatops env : - name : TOOL_ENV value : "" # 環境名もoverlayのpatchが与える # DB認証などのシークレットはsecretKeyRefで注入する なお、マニフェストにシークレットの生の値は置きません。実体はAWS Secrets Managerにあり、それをExternal SecretsがKubernetes Secretへ同期し、Podは secretKeyRef で参照します。 実行機構がPodTemplateからJobを組み立てる部分の実装は、次のような形です。 // Jobレベルの機構ポリシー。ツールによらず共通の値のため固定する const ( jobBackoffLimit int32 = 0 // リトライは利用者の再実行に任せる jobTTLSecondsAfterFinished int32 = 3600 // 完了したJobの掃除 ) // ツール別に調整するJobレベルの実行時間上限（テンプレートのannotationで宣言する） const activeDeadlineAnnotation = "chatops.zozo.com/job-active-deadline-seconds" template, err := client.CoreV1().PodTemplates(namespace).Get(ctx, templateName, metav1.GetOptions{}) // ...（annotationから実行時間上限を読み取り、Pod specを検証する） job := &batchv1.Job{ ObjectMeta: metav1.ObjectMeta{ GenerateName: "chatops-" + tool + "-" , }, Spec: batchv1.JobSpec{ BackoffLimit: ptr.To(jobBackoffLimit), TTLSecondsAfterFinished: ptr.To(jobTTLSecondsAfterFinished), ActiveDeadlineSeconds: ptr.To(activeDeadline), // annotation由来 Template: corev1.PodTemplateSpec{ ObjectMeta: podMeta, Spec: *template.Template.Spec.DeepCopy(), }, }, } マルチテナント設計とツール追加の体験 共通の入口と、テナントごとの実行スタック この仕組みは、カート決済SREブロック専用ではなく、社内の複数チームで使える共通基盤として設計しています。Slack App、API Gateway、Gatekeeperは全テナント共通です。一方、EKS側のEventSource、EventBus、Sensor、Jobの一式は、テナントのnamespaceごとに独立しています。Gatekeeperがchannel-mapで解決したテナントに応じて転送先を切り替えるため、あるテナントのイベントが他のテナントの実行スタックに流れることはありません。 ツールに渡す標準ペイロード 実行機構からツールへは、次の形の標準ペイロードを渡します。 { " kind ": " chatops-tool ", " tool ": " example-tool ", " command ": " update ", " args ": [ " ... " ] , " requester ": " U12345678 ", " channel ": " C12345678 ", " team ": " zozo-cart ", " ts ": " 1756... " } 引数（ args ）の解釈はツール自身が行います。基盤側がツールごとの引数仕様を知る構造にすると、ツールを追加するたびに基盤へ変更が波及するためです。ツールはこのペイロードを受け取れる形にさえなっていれば、K8s JobでもLambdaでも構いません。 Lambdaツールの場合は、実行機構のJobがこのペイロードを渡してLambda関数をinvokeします。旧基盤から移行したLambdaツールは、関数やIAMロール、VPC設定をそのまま維持して、標準ペイロードを受理する改修だけでトリガー経路を差し替えられました。実行形態の自由とは、新しいツールの選択肢が増えることだけでなく、既存のLambda資産を作り直さずに済むことでもあります。 ツール追加はSSMポリシーとマニフェストだけ 新しいツールをChatOpsに追加する手順は次の2つだけです。 SSMに /chatops/policy/{テナント}/{ツール} のポリシーを追加する（コマンド、許可、承認、実行形態の宣言） K8s Jobツールの場合は PodTemplate のマニフェストを追加する。Lambdaツールの場合は標準ペイロードを受理するようにする Slack App、API Gateway、Gatekeeperのコードやリソースには一切手を入れません。従来はツールごとにLambdaの新設が必須でしたが、今はコンテナイメージとして動くツールならPodTemplateを書くだけでChatOpsに載ります。 導入の効果 移行によって、冒頭の課題は次のように解消されました。 コマンド、ユーザー、チャネルの単位の認可と、危険操作への承認フローが基盤の機能として動いている 許可を含むすべての実行判断が構造化ログとして残り、監査とインシデント調査で使える状態になった 非エンジニアの利用者は、従来と同じWorkflowフォームのUXのまま移行できた ツールの実行形態がK8s JobとLambdaの2択になり、追加コストが下がった まとめ 本記事では、AWS Chatbotで運用していたChatOps基盤を、Argo EventsとGatekeeper Lambdaを軸にした構成へ再構築した事例を紹介しました。実行者を直接特定できないWorkflow経由の投稿に対しては、信頼チェーンで認可を成立させました。この信頼チェーンと、実行基盤の手前での認可、承認、監査の一元化が設計の要点です。Slackを入口とした運用基盤の構築や、Argo Eventsの本番運用を検討している方の参考になれば幸いです。今後は実行時権限のさらなる最小化など、基盤の堅牢化を進めていきたいと考えています。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに こんにちは、EC基盤開発本部SRE部でテックリードを務めている杉山です。 ZOZOでは、長年運用してきた基幹システムを新しいアーキテクチャへリプレイスする取り組みを進めています。新システムではAPIにJava、フロントエンド＋BFFにReact（TypeScript / Node.js）を採用し、インフラはKubernetes上に構築しています。 2025年11月に開催されたファインディ株式会社主催の「アーキテクチャConference 2025」では、「巨大モノリスのリプレイス──機能整理とハイブリッドアーキテクチャで挑んだ再構築戦略」と題して発表しました。基幹システムの課題と、アーキテクチャの方向性を紹介した内容です。 findy-tools.io その中で、基幹フロントエンドリプレイスについても触れています。既存システムと新システムを共存させながら、Kubernetes上で機能ごとにパスルーティングし、段階的に置き換えていく構想です。 しかし、当時このアーキテクチャはまだ「予定」でした。実現するためには、既存システムが長年抱えてきたある制約を取り除く必要があったためです。 それが、Webサーバーがユーザーセッションを保持する「ステートフル」な構成です。 本記事では、既存システムのIISが保持していたセッションをRedisへオフロードし、Webサーバーをステートレス化するまでの取り組みを紹介します。それによって基幹システムの段階的なフロントエンドリプレイスを進められるようになった背景にも触れます。 目次 はじめに 目次 基幹フロントエンドリプレイスの構想 新アーキテクチャを用意するだけでは移行できない 段階的リプレイスを阻んだIISセッション 認証だけではないIISセッションへの依存 認証をOIDC化するだけでは解決できない リプレイスの前に「状態」を切り離す IISセッションをRedisへオフロードする Before / After 独自フレームワークを変更した理由 セッションIDの引き回し シリアライズ方式と互換性 更新タイミングとエラー時のロールバック セッション期限管理の設計 Redis障害時の考え方 Redis Clusterの障害対策とキー設計 段階的な切り替えとフォールバック ステートレス化によって何が変わったのか いよいよ基幹フロントエンドのリプレイスへ まとめ 基幹フロントエンドリプレイスの構想 まず、ZOZOの基幹システムとリプレイスの背景について簡単に紹介します。 既存の基幹システムはClassic ASP（VBScript）/ IISを中心に構築され、長年にわたって機能追加を続けてきました。ZOZOは自社で倉庫を持っており、基幹システムには事業部が利用する業務機能だけでなく、ECサイトで取り扱う商品の物流機能も含まれています。非常に巨大なシステムで、長期間の運用によってモノリス化が進み、保守性・拡張性の低下や技術的負債の蓄積が課題となっています。 そこで現在、既存システムを新しいアーキテクチャへリプレイスする取り組みを進めています。 ただし、巨大な基幹システムを一度にすべて置き換えることは現実的ではありません。 ドメイン分離が容易な部分のマイクロサービス化やデータベースアクセス部分のマイクロサービスAPI化は進んでいますが、基幹システムのメインのフロントエンドのリプレイスはまだこれからです。 既存システムと新システムを一定の期間共存させ、機能単位で徐々に切り替えていく方針を考えました。 具体的には、次のような構成を目指しています。 Kubernetes基盤上にIngress + Istioによるルーティングの仕組みを構築し、URLのパスなどに応じてリクエストを振り分けます。これにより、既存システムを稼働させたまま一部の機能から置き換えていく、いわゆるストラングラーパターンによる段階的なリプレイスを目指しました。 「アーキテクチャConference 2025」でこの構想を紹介した2025年11月時点では、まだ「ステートレス化後のフロントアーキテクチャ（予定）」という位置づけでした。 では、なぜすぐにこの構成へ移行できなかったのでしょうか。 新アーキテクチャを用意するだけでは移行できない 構成図だけを見ると、新システムをKubernetes上に構築し、Ingressなどでパスルーティングすれば、既存システムから少しずつ移行できるように思えるかもしれません。 しかし、実際の既存システムには大きな制約がありました。 Webサーバー自身が状態を持っていた ことです。 既存システムでは、IISのセッション管理やサーバー上の作業用データファイルなど、動作に必要な状態をWebサーバー内部に保持していました。このような構成では、リクエストを処理するサーバーを自由に切り替えられません。 例えば、あるユーザーからの最初のリクエストをWebサーバーAが処理し、そのサーバーのメモリ上にセッションを作成したとします。次のリクエストがWebサーバーBへ送られると、WebサーバーBにはそのセッションが存在しません。 これは単純なスケールアウトだけでなく、Kubernetesへの移行でも問題になります。KubernetesではPodが作成・削除されることを前提としており、特定のWebサーバーやPodのローカルな状態に依存しない、ステートレスなアプリケーションが扱いやすい構成となります。 そして今回、もう1つ大きな問題となったのが 段階的リプレイス でした。 段階的リプレイスを阻んだIISセッション 今回目指しているのは、既存システムをあるタイミングですべて停止し、新システムへ一斉に切り替えるリプレイスではありません。既存システムと新システムを共存させながら、ページや機能単位で少しずつ移行していく、ストラングラーパターンによる段階的なリプレイスです。 この構成を実現するうえで、大きな壁となったのが、既存システムのIISセッションへの依存でした。 認証だけではないIISセッションへの依存 既存の基幹システムでは、IISのインメモリセッションをさまざまな用途で利用しています。代表的なものがユーザーの認証情報ですが、セッションの用途は認証だけではありません。 基幹システムには、複数の画面を遷移しながら1つの業務を完了する機能が数多く存在します。その過程で入力・選択した情報など、画面をまたいで引き継ぐ必要がある一時的なデータの保持にもセッションを利用しています。 そのため、既存システムの画面遷移は、同じIISセッションを継続して参照できることを前提としていました。 ここで、ページ単位の段階的なリプレイスを考えてみます。 既存画面（Classic ASP / IIS） ↓ 新画面（新システム） ↓ 既存画面（Classic ASP / IIS） IngressやIstioを利用すれば、URLのパスに応じてリクエストを振り分けること自体は可能です。しかし、ルーティングだけを切り替えても、画面間で利用しているセッション情報まで引き継げるわけではありません。 例えば、既存画面で保持した認証情報や一時データを後続の画面で必要とする場合を考えます。遷移先がKubernetes上の新システムになると、IISのメモリ上に保持していたセッションをそのまま参照できません。 つまり、ログイン状態の維持だけが問題ではありません。既存システムにおける 画面間の状態の引き継ぎそのものが、IISのインメモリセッションに依存している ことが、段階的リプレイスの障壁でした。 認証をOIDC化するだけでは解決できない この問題に対して、認証方式そのものを変更するアプローチも考えられます。例えば認証をOIDC（OpenID Connect）化し、ID Tokenを利用する構成に変更したとします。認証情報を特定のIISサーバーのインメモリセッションに依存させず、新旧システムの双方でユーザーを識別できるようになります。 認証だけが課題であれば、この方法で解決できる可能性があります。しかし今回の基幹システムでは、OIDC化だけでは要件を満たせません。既存システムがIISセッションに保持しているのは認証情報だけではないこと、そして拠点専用のサーバー構成を脱却しALBによるロードバランシングを実現することも目的としていたためです。 仮にOIDC化によって「誰がログインしているのか」を新旧双方で識別できるようになったとします。それでも、画面で入力・選択した情報など、画面間で引き継いでいる業務上の一時データまでID Tokenで引き継げるわけではありません。 例えば、既存画面でセッションに保存した情報を、次の新システムの画面で必要とするケースを考えます。 既存画面 │ │ 認証情報 │ ＋ │ 画面間で引き継ぐ業務データ ↓ IIS Session │ × │ 新画面（新システム） 認証方式だけを切り替えても、この「×」は残ります。 つまり、今回解決する必要があったのは、認証をステートレスにすることだけではありませんでした。必要だったのは、認証情報や画面間で引き継ぐ一時データを含め、 既存WebアプリケーションがIISに保持している状態そのものを、特定のWebサーバーから切り離すこと でした。 リプレイスの前に「状態」を切り離す このままでは、Kubernetes上に新しいアプリケーションを構築しても、ページ単位の段階的な置き換えは実現できません。 言い換えると、セッションの保存場所という既存システムの実装上の制約が、リプレイスできる単位まで制約していました。 そこで、新システムへの移行を本格化する前に、まず特定のIISサーバーに閉じていたセッションを外部へ切り離すことにしました。認証情報だけでなく、画面をまたいで利用される状態もWebサーバーの外部で管理します。これにより、既存システムと新システムが共存しながら、ページ・機能単位で段階的に移行できる状態を作ります。 そのために採用したのが、IISのインメモリセッションをRedisへオフロードする 「セッションオフロード」 という手法です。 次章では、このセッションオフロードをどのような構成で実現したのかを紹介します。 IISセッションをRedisへオフロードする 目指したのは、Webサーバー自身がユーザーセッションを保持しない構成です。そこで、これまでIISのインメモリに保持していたセッションを、外部のRedisへオフロードすることにしました。 Before / After ポイントは、単純にRedisを追加することではありません。既存アプリケーションから見たセッションの扱いを大きく変えずに、セッションの保存先だけをWebサーバーのメモリから外部へ移す必要があります。 ZOZOの既存基幹システムでは独自フレームワークを利用しています。今回、この独自フレームワークをバージョンアップして、セッションの読み書きをRedisへオフロードできる仕組みを導入しました。これによって、Webサーバー自身はユーザー固有のセッションを保持せず、必要なセッション情報を外部から取得する構成へ変更します。 サーバー内部に保持していたデータファイルも、読み書き先をファイルサーバーへ移行しました。 Webサーバーとセッションのライフサイクルを分離することが、この取り組みの重要なポイントです。 独自フレームワークを変更した理由 既存の基幹システムでは、Classic ASPの各ページから直接IISのSessionオブジェクトを操作するのではなく、独自フレームワークを通じてセッションを読み書きしています。このフレームワークが、セッションへのアクセスを一元的に管理する役割を担っています。 この構成であったことが、今回のセッションオフロードを実現するうえで大きな助けとなりました。 アプリケーションを1つずつ改修して保存先を変更するアプローチでは、膨大な画面数を持つ基幹システムにおいて現実的な工数で対応しきれません。しかし、セッションへのアクセスがフレームワーク層に集約されていたため、そのレイヤーでRedisへの読み書きを吸収すれば、個々のアプリケーションコードを変更せずにセッションの保存先を切り替えられます。 つまり、フレームワーク側を変更することで、 既存アプリケーションへの変更を最小限に抑えながら、セッション管理だけを差し替える ことが可能になりました。 セッションIDの引き回し 新旧システム間でセッションを共有するためには、同一ユーザーのリクエストに対して同じセッションIDでRedisにアクセスする必要があります。 セッションIDはCookieを通じてクライアントに保持させます。リクエストごとにCookieから取得したセッションIDをキーとしてRedisからセッション情報を取得します。この仕組みにより、振り分け先がIIS上の既存システムでもKubernetes上の新システムでも、同じセッションを参照できます。 シリアライズ方式と互換性 IISのインメモリセッションでは、VBScript固有のオブジェクト形式でデータが保持されています。Redisへオフロードするにあたっては、このデータをシリアライズ可能な形式に変換する必要があります。 フレームワーク層でシリアライズ・デシリアライズ処理を実装し、既存のセッションデータとの互換性を維持しながらRedisへの永続化を実現しました。シリアライズフォーマットにはJSONを採用し、VBScript固有の型情報も保持するスキーマ設計としています。これにより、新システム側でも同じフォーマットで正しくデータを読み書きできます。 更新タイミングとエラー時のロールバック セッションデータのRedisへの更新タイミングも、重要な設計ポイントです。 今回は、スクリプトの実行開始時にセッションデータをまとめて取得し、処理中はインメモリで扱い、実行完了時にまとめてRedisへ書き戻す方式を採用しました。この方式には、スクリプト処理中のセッションアクセスを高速化できること、そしてエラー発生時のロールバックを兼ねられることという2つの利点があります。 処理の途中でエラーが発生した場合、Redisへの更新は実行されません。つまり、セッションが中途半端に更新された状態を防ぐことで、セッションデータの自動ロールバックを実現しています。 仮に、スクリプト実行中に都度Redisを更新する方式にすると、エラー発生時点で一部だけ更新が反映された状態となり、ロールバックが難しくなります。更新タイミングをまとめることで、この問題を回避しています。 セッション期限管理の設計 IISのインメモリセッションには、一定時間アクセスがなければ自動的に破棄されるタイムアウトの仕組みがあります。既存システムでは、セッション破棄時にSession_OnEndイベントで業務処理を実行していました。Redisへオフロードするにあたり、このセッション終了時の処理をどう再現するかが課題となりました。 RedisにはKeyspace Notificationsという仕組みがあり、キーの期限切れを検知した際にexpiredイベントを通知できます。ただし、このイベントはTTL満了時刻ちょうどではなく、Redisがキーの期限切れを検知・削除した時点で発行されるため、通知タイミングや時刻の厳密さは保証されません。また、Keyspace Notificationsは永続キューではなく、購読者が停止している間のイベントを後から取得する仕組みもありません。したがって、取りこぼしが許容されない業務処理のトリガーには適さないと判断しました。 そこで、別途、期限管理のサブシステムを稼働させる方式を採用しています。このサブシステムがセッションの期限切れを能動的に検知し、従来Session_OnEndで実行していた業務処理を代替したうえでセッションを削除します。定期スキャンによって確実に処理を実行でき、イベントの取りこぼしがないため安定性に優れます。 この仕組みは、ZOZOTOWNでのセッションオフロード時の仕様を踏襲したものです。 Redis障害時の考え方 セッションの保存先をRedisに一本化することで、Redis障害がシステム全体に影響するリスクが生まれます。 この点については、Amazon ElastiCache for Redisのクラスタモードを採用し、3AZにまたがるレプリケーショングループによる自動フェールオーバー構成としています。さらに、1シャードの障害影響を局所化するために複数シャード構成を採用しました。特定のシャードに障害が発生しても、影響を受けるのはそのシャードに割り当てられたセッションのみです。たとえば、1シャード構成では1ノード障害の影響が100%に及びますが、5シャード構成であればハッシュスロットが均等に分散していると仮定して1ノード障害の影響は20%にとどまります。実際にはハッシュスロット分散の偏りによって上下し、ここはランニングコストと可用性のバランスになります。そのうえで、SLOで定義した可用性や試験で計測したMTTRなども考慮して、最終的なシャード数を決定しました。 Redis Clusterの障害対策とキー設計 Redis Clusterでは、キーのハッシュ値に基づいてデータが各シャードに分散されます。しかし、1つのセッションに関連する複数のキーが異なるシャードに散ると、以下の問題が生じます。 複数シャードをまたいだ読み書きによるレイテンシー悪化。 multi-key commandは同一hash slot内のキーに制限されるため、別slotのキーにはCROSSSLOTエラーが発生する。 single-slot operationの方がパフォーマンスに優れる。 シャード障害時に、同一セッションのキーの一部だけが取得できず、データ不整合を引き起こす。 Redis Clusterには「ハッシュタグ」という仕組みがあります。キーに {...} パターンを含めると、波括弧内の文字列のみをもとにハッシュスロットが計算されます。これにより、同じハッシュタグを持つキーは必ず同一シャードに配置されます。 今回のセッション管理では、1ユーザーの複数のキーにセッションIDをハッシュタグとして埋め込む設計を採用しました。 機能によってHash・String・List・Setなど適したRedisのデータ型が異なるため、セッションを1つのキーにまとめず、ユーザーの認証情報とは別に機能や画面の単位でキーを分けています。これらのキーが別シャードに散らないよう、セッションIDをハッシュタグとして共通で埋め込んでいます。 例： data:{session-id}:<FEATURE_KEY_1> # Hash data:{session-id}:<FEATURE_KEY_2> # String data:{session-id}:<FEATURE_KEY_3> # List data:{session-id}:<FEATURE_KEY_4> # Set このキー設計により、同一ユーザーのセッションに属するすべてのデータが同じシャードに格納されます。これにより、前述の問題を回避しつつ、Redis Clusterによるシャーディングの恩恵を受けられる構成としました。 参考： Redis Cluster Specification - Hash tags 段階的な切り替えとフォールバック セッションオフロードの適用は、全拠点を一斉に切り替えるのではなく、段階的に進めています。 まず、セッションオフロードに対応した環境を構築し、全倉庫拠点での動作確認を事前に実施しました。その後、影響度が小さい拠点から順にアクセス先をセッションオフロード環境へ切り替え、ロングランで安定稼働を確認しながら対象拠点を広げていく方式を採用しています。 問題が発生した場合は、影響のあるユーザー単位で旧ドメインへ切り戻すフォールバックを用意しています。拠点全体を巻き戻す必要がなく、影響範囲を限定した復旧が可能です。 2026年9月現在、この段階的な切り替えを進行中です。 ステートレス化によって何が変わったのか セッションオフロードで得られた一番大きな変化は、「Redisを使えるようになったこと」ではありません。 Webサーバーとユーザーセッションの紐付きを切り離せたこと です。 これまでWebサーバーの中にあった状態を外部へ移しました。その結果、リクエストをどのWebサーバーが処理するかと、ユーザーがどのセッションを利用するかを分離して考えられるようになりました。 これによって、アーキテクチャ上の選択肢が大きく広がります。 特定のWebサーバーにユーザーを固定する前提がなくなる。 ALBによるリクエストの均等な負荷分散が可能になる。 Webサーバーの増減や入れ替えと、ユーザーセッションのライフサイクルを分離できる。 Podが入れ替わることを前提とするKubernetesへの移行にも対応しやすくなる。 従来のステートフルな構成では、拠点ごとに接続先のWebサーバーが固定されていました。「アーキテクチャConference 2025」でもこの点を課題として紹介しています。セッションがサーバーに紐付いているため、リクエストを別のサーバーへ振り分けられず負荷が偏りやすい構造でした。ステートレス化によってこの制約がなくなり、ALBで均等にリクエストを分散できるようになりました。 しかし、今回の基幹リプレイスにおいて最も重要なのは、その先です。既存システムと新システムをまたいだ、段階的なフロントエンドリプレイスを進めるための前提条件が整いました。 これまで、 Webサーバー ＝ アプリケーション ＋ ユーザーの状態 だったものを、 Webサーバー ＝ アプリケーション Redis ＝ ユーザーの状態 へ分離したことで、フロントエンドのルーティングとセッション管理を独立して考えられるようになります。 これは単なるインフラ変更ではなく、基幹システムをどの単位で、どの順番でリプレイスできるかを変えるための アーキテクチャ変更 です。 いよいよ基幹フロントエンドのリプレイスへ ここで、2025年11月の「アーキテクチャConference 2025」で紹介した構成に戻ります。 当時紹介したのは、Kubernetes基盤上にIngress + Istioを配置し、ストラングラーパターンによって既存システムと新システムを共存させる構成でした。そして、機能ごとのパスルーティングによって、既存のClassic ASPから新しいアプリケーションへ段階的に切り替えていくことを予定していました。 当時はまだ「予定」だったこのアーキテクチャに対して、今回のセッションオフロードによって、その前提となるステートレス化を進めることができました。 巨大な基幹システムのリプレイスでは、新しいシステムを作ることだけが課題になるわけではありません。既存システムが長年の運用の中で持つようになった前提や制約を1つずつ解きほぐし、新旧システムが共存できる状態を作ることも、段階的なリプレイスには必要です。 今回取り組んだセッションオフロードは、そのための1つのステップでした。Webサーバーから状態を切り離したことで、既存システムを稼働させたまま、新アーキテクチャへページ・機能単位で移行していくための土台が整いました。 まとめ 本記事では、ZOZOの基幹システムにおけるWebサーバーのステートレス化について紹介しました。 2025年11月の「アーキテクチャConference 2025」では、基幹システムのリプレイスを進めるうえで「ステートフル」であることを課題として挙げました。あわせて、IISセッションをRedisへオフロードする方針と、Kubernetes上での段階的なフロントエンドリプレイス構想を紹介しました。 その構想を実現するため、既存システムで利用している独自フレームワークをバージョンアップし、IISのインメモリに保持していたユーザーセッションをRedisへオフロードしました。 今回の取り組みで重要だったのは、Redis導入そのものではありません。既存システムから「状態」という制約を切り離し、リプレイスの自由度を上げることでした。 長年稼働してきた基幹システムを、一度にすべて刷新できません。だからこそ、新しいアーキテクチャを作るだけではなく、既存システムを少しずつ「置き換えられる状態」に変えていくことが重要だと考えています。 2025年に「予定」として紹介していた基幹フロントエンドの新しいアーキテクチャは、今回のステートレス化によって実現に向けた準備が整いました。ここから、基幹フロントエンドの段階的なリプレイスを進めていきます。 ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com