本ブログは 2024 年 10 月 17 日に公開された AWS Blog “ An unexpected discovery: Automated reasoning often makes systems more efficient and easier to maintain ” を翻訳したものです。 先日、 米国防高等研究計画局 (DARPA) を訪問した際にある傾向について話したところ、強い関心を持たれました。 Amazon Web Services (AWS) で過去 10 年にわたって自動推論を適用する中で、形式的検証されたコードは、置き換え前の未検証のコードよりもパフォーマンスが優れていることが多いことを確認しています。 これは、形式的検証の過程で行うバグ修正が、実行時パフォーマンスにもプラスの影響を与えることが多いためです。また、自動推論によってビルダーは自信を持ってさらなる最適化に取り組めるようになり、システムパフォーマンスがいっそう向上します。形式的検証されたコードは更新や変更、運用も容易であり、深夜のログ分析やデバッグの頻度も減ることがわかっています。この記事では、DARPA との議論で取り上げた 3 つの事例を紹介します。 自動推論: 基礎 AWS では、お客様にとってシンプルで直感的なサービスの構築に取り組んでいます。そのシンプルさの裏側には、毎秒数十億件のリクエストを処理する、広大で複雑な分散システムがあります。こうした複雑なシステムの正しさを検証することは大きな課題です。本番サービスは、新機能の追加、コンポーネントの再設計、セキュリティの強化、パフォーマンスの最適化に伴って常に進化し続けています。これらの変更の多くはそれ自体が複雑であり、AWS やお客様のセキュリティやレジリエンスに影響を与えることなく実施する必要があります。 設計レビュー、コード監査、ストレステスト、フォールトインジェクションは、いずれも日常的に使用しており、今後も使い続ける非常に重要なツールです。しかし、多くのケースで正しさの確認には、これらの手法だけでは不十分であることもわかっています。特に大規模でフォールトトレラントなアーキテクチャでは、巧妙なバグが検出をすり抜ける可能性があります。また、問題の中には実装上の欠陥ではなく、元のシステム設計自体に根本原因があるものもあります。サービスの規模と複雑さが増すにつれて、従来のテスト手法を数学とロジックに基づくより強力な手法で補完する必要が生じました。ここで人工知能 (AI) の一分野である 自動推論 が力を発揮します。 従来のテストが 特定の シナリオにおけるシステムの動作検証に重点を置くのに対し、自動推論は あらゆる シナリオにおけるシステムの動作をロジックで検証することを目指します。中程度の複雑さのシステムでさえ、発生しうるすべての状態とパラメータの組み合わせを再現するには、途方もない時間がかかります。自動推論を使えば、システムの正しさの論理的な証明を導出することで、同じ効果をすばやく効率的に達成できます。 自動推論を活用するには、ビルダーに異なるマインドセットが求められます。考えうるすべての入力シナリオとその問題点を洗い出そうとするのではなく、システムがどう動作 すべき かを定義し、正しく動作するために満たすべき条件を特定します。そして、数学的な証明を使ってその条件が真であることを検証します。つまり、このアプローチによってシステムの正しさを検証できるのです。 自動推論では、システムの仕様と実装を数学的に表現し、アルゴリズム的なアプローチで実装が仕様を満たすことを検証します。システムを数学的にエンコードし、形式的論理を用いて検証することで、システムの将来の動作に関する重要な問いに効率的かつ確実に答えることができます。システムは何ができるのか？何をするのか？何を絶対にしないのか？自動推論は、最も複雑で大規模な、さらには上限のないシステムについても、こうした問いに答えることができます。これは従来のテストだけでは網羅的に検証できないシナリオです。 自動推論によって完璧は達成できるのでしょうか？いいえ、できません。自動推論もまた、システムのコンポーネントが正しく動作することや、システムとその環境のモデルとの関係について、一定の仮定に依存しています。例えば、システムのモデルが、コンパイラやプロセッサなどの基盤コンポーネントにバグがないと誤って仮定している可能性があります (ただし、これらのコンポーネントも形式的検証することは可能です)。とはいえ、自動推論によって、従来のソフトウェア開発やテスト手法では得られない、より高い水準の正しさへの確信が得られるようになります。 開発の高速化 自動推論は、数学者や科学者だけのものではありません。 Amazon Simple Storage Service (Amazon S3) のエンジニアは、バグを防ぐために日々自動推論を活用しています。S3 のシンプルなインターフェイスの裏側には、400 兆個のオブジェクトとエクサバイト規模のデータを保持し、毎秒 1 億 5,000 万件を超えるリクエストを定常的に処理する、世界最大級かつ最も複雑な分散システムの 1 つがあります。S3 は多数のサブシステムで構成されており、それぞれが独立した分散システムであり、その多くは数万台のマシンで動作しています。お客様に大規模にご利用いただいている中でも、新機能は常に追加され続けています。 S3 の主要コンポーネントの 1 つが S3 インデックスサブシステムです。これは、高速なデータ検索を可能にするオブジェクトメタデータストアです。このコンポーネントには、非常に大規模で複雑なデータ構造と、精巧に最適化されたアルゴリズムが含まれています。S3 の規模ではアルゴリズムを人間が正確に実装するのは難しく、検索でエラーは許されません。変更を確信を持って行うには極めて慎重な対応と広範なテストが必要なため、新たな改善はおよそ四半期に 1 回のペースにとどまっていました。 S3 は 15 年にわたる経験の上に堅牢に構築され、十分にテストされたシステムです。しかし、S3 インデックスサブシステムには、長い間根本原因を特定できないバグが存在していました。システムはその例外から自動的に回復できたため、バグがシステムの動作に影響を与えることはありませんでした。それでも、この状態に満足してはいませんでした。 なぜこのバグは長期間残り続けたのでしょうか？S3 のような分散システムには多数のコンポーネントがあり、それぞれに固有のコーナーケースがあります。そして、複数のコーナーケースが同時に発生することもあります。300 を超えるマイクロサービスを持つ S3 では、これらのコーナーケースの組み合わせは膨大な数になります。バグが存在する証拠やその根本原因の推測があったとしても、開発者がコーナーケースを 1 つ 1 つ検討し尽くすことは不可能です。ましてや、コーナーケースのあらゆる組み合わせを検討することなど到底できません。 この複雑さがきっかけとなり、自動推論を使って潜在的な状態やそこに潜むエラーを探索する方法を検討しました。システムの形式的仕様を構築することで、バグを発見し、同種のバグがこれ以上存在しないことを証明できました。自動推論の活用により、年に 3～4 回だったアップデートと改善のリリースを、1～2 か月ごとに行えるようになりました。 コードの高速化 AWS Identity and Access Management (IAM) サービスの正しさは、お客様のワークロードのセキュリティの基盤です。数百万のお客様、数千のリソースタイプ、数百の AWS サービスにわたり、すべての API コール (つまり、AWS へのすべてのリクエスト) は IAM の認可エンジンによって処理されます。毎秒 12 億件を超えるリクエストです。これは AWS の中でも最もセキュリティ上重要で、最大規模にスケールされたソフトウェアの 1 つです。 AWS では、いかなる変更も本番環境に反映する前に、システムがセキュアかつ正しい状態を維持していることについて、極めて高い確信が求められます。自動推論を使うことで、あらゆる状況においてシステムが特定のセキュリティプロパティに準拠していることを証明できます。これを 証明可能なセキュリティ と呼んでいます。自動推論により、お客様に証明可能なセキュリティの保証を提供できるだけでなく、機能、セキュリティ、最適化を大規模に提供できるようになっています。 S3 と同様に、IAM も 15 年をかけて進化してきた、時間の試練を経た信頼性の高いシステムです。しかし、さらに水準を引き上げたいと考えました。既存の IAM 認可エンジンの動作を捉える形式的仕様を構築し、ポリシー評価の原則を証明可能な定理として定式化し、自動推論を使ってより効率的な新しい実装を構築しました。2024 年初めに、正しさが証明された新しい認可エンジンをデプロイしましたが、誰も気づきませんでした。自動推論により、AWS インフラストラクチャの中で最も重要なコンポーネントの 1 つである認可エンジンを、正しさが証明された同等の実装にシームレスに置き換えることができたのです。 仕様と証明が整ったことで、高い確信を持って安全かつ大胆にコードを最適化できるようになりました。IAM の膨大な規模では、わずか 1 マイクロ秒のパフォーマンス向上でさえ、お客様のエクスペリエンスの改善と AWS のコスト最適化に直結します。文字列マッチングの最適化、不要なメモリ割り当てや冗長な計算の削除、セキュリティの強化、スケーラビリティの向上を実現しました。変更のたびに証明を再実行し、システムが正しく動作し続けていることを確認しました。 最適化後の IAM 認可エンジンは、以前のバージョンと比較して 50% 高速になりました。自動推論がなければ、これほどインパクトのある最適化をこれほどの確信を持って実現することは到底できなかったでしょう。この取り組みの詳細については、こちらの AWS re:Inforce セッション をご覧ください。 デプロイの高速化 (とコードの高速化) オンラインで行われるトランザクションの大半は、暗号によって保護されています。例えば、RSA 暗号化アルゴリズムは 2 つの鍵を生成してデータを保護します。1 つはデータの暗号化用、もう 1 つは復号用です。これらの鍵により、安全なデータ伝送とデジタル署名が実現します。暗号においては、正しさとパフォーマンスの両方が不可欠です。暗号化アルゴリズムのバグは壊滅的な結果を招きかねません。 お客様がワークロードを AWS Graviton に移行するにつれて、 ARM 命令セット 向けに暗号を最適化するメリットは増しています。しかし、パフォーマンス向上のための暗号の最適化は複雑であり、変更した暗号化アルゴリズムが正しく動作しているかの検証は困難です。自動推論を導入する以前は、暗号ライブラリの最適化を本番環境にリリースするまでに、数か月にわたるレビューが必要になることも珍しくありませんでした。 ここで自動推論が威力を発揮しました。 Graviton で RSA を高速化し、形式的検証で正当性を証明し開発も加速しました 。 楕円曲線暗号に自動推論を適用 した場合にも、同様の成果が得られています。 好循環の形成 過去 10 年にわたり、AWS ではクラウドインフラストラクチャとサービスの正しさを証明するために、自動推論技術の適用を拡大してきました。正しさの検証だけでなく、セキュリティと信頼性の向上、設計上の欠陥の最小化にも、日常的にこれらの手法を活用しています。自動推論を使うことで、システムの精密でテスト可能なモデルを作成し、変更が安全であることをすばやく検証できます。また、本番環境に影響を与えることなく、変更が安全でないことを事前に把握することもできます。 インフラストラクチャに関する重要な問いに答え、データを露出させる可能性のある設定不備を検出できます。他の手法では発見できなかったであろう、目立たないが深刻なバグが本番環境に到達するのを防ぐことができます。モデル検査なしでは到底挑戦できなかったような、大胆なパフォーマンス最適化を実現できます。自動推論は、重要なシステムが期待どおりに動作することについて、厳密な数学的保証を提供します。 AWS は、この規模で自動推論を活用する 初めてかつ唯一のクラウドプロバイダー です。自動推論ツールの導入が広がるにつれ、ユーザビリティとスケーラビリティの向上に対するより大きな投資が正当化しやすくなります。ツールが使いやすく、強力になるほど、導入はさらに進みます。クラウドインフラストラクチャの正しさをより多く証明できるほど、セキュリティを最重視するお客様にとってクラウドの魅力は高まります。そして、この記事の事例が示すように、セキュリティの保証を高めるだけでなく、よりパフォーマンスの高いコードをお客様に迅速に提供し、最終的にはお客様に還元できるコスト削減も実現しています。 セキュリティ、コンプライアンス、可用性、耐久性、安全性といった重要な特性を、大規模なクラウドアーキテクチャに対して自動的に証明できる時代が始まりつつあると考えています。AI ハルシネーションの潜在的な問題の防止から、ハイパーバイザー、暗号、分散システムの分析に至るまで、確かな数学的推論を基盤に据え、構築するものを継続的に分析し続けていることが、Amazon ならではの強みです。 関連情報 Amazon Science ブログ で自動推論の詳細をご覧ください AWS が自動推論により 証明可能なセキュリティ を提供する方法をご覧ください AWS Automated Reasoning Group でのインターンシップにご興味がある方は、 お問い合わせください   この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。   Byron Cook Byron はユニバーシティカレッジロンドン (UCL) のコンピュータサイエンスの教授であり、英国王立工学アカデミーのフェローです。2015 年に Amazon Automated Reasoning Group を設立し、現在は AWS で Vice President 兼 Distinguished Scientist of Automated Reasoning を務めています。関心分野は、コンピュータおよびネットワークセキュリティ、プログラム解析と検証、プログラミング言語、定理証明、論理学、ハードウェア設計、オペレーティングシステム、生物学的システムです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

.entry .entry-content .table-of-contents > li > ul { display: none; } はじめに こんにちは、カート決済部カート決済基盤ブロックの林です。普段はZOZOTOWN内のカート機能や決済機能の開発、保守運用、リプレイスを担当しています。 ZOZOTOWNの購入フローは、セッションに強く依存したロジックが長年の改修により肥大化し、機能改善や保守の際の調査・改修コストが増大していました。この課題を解決するため、私たちのチームは2024年5月から約2年にわたる段階的なリプレイスプロジェクトを進めています。 ミッションクリティカルな購入フローを無停止で移行するため、私たちは3つのフェーズに分けた段階的なアプローチを採用しました。本記事では、その実践的な進め方と、実際に直面した課題について紹介します。 なお、同じチームの多田と三浦が、このリプレイスにおけるアーキテクチャ選択（モジュラモノリス）の背景と設計について別の記事で紹介していますので、併せてご覧ください。 techblog.zozo.com 目次 はじめに 目次 背景・課題 セッションに依存したロジックの肥大化 サービス無停止でのリプレイス要件 新システムの構成とセッション問題の解決 既存システムの問題点 新システムの構成 Shopping BFF + Redisによる解決 リプレイス戦略の全体像 なぜ段階的なアプローチを選んだか 3つのフェーズに分けたアプローチ フェーズの関係性 現在の進捗状況 フェーズ1：一部機能の比較フェーズ 比較対象の選定 並行稼働の仕組み 比較・検証方法 フェーズ1で得られた知見 フェーズ2：段階的な入れ替えフェーズ 入れ替え順序の工夫 切り替えの仕組み 二重開発の最小化 フェーズ2の成果 フェーズ3：全体リプレイス n％リリースによる段階的な移行 n％リリースの設計方針 各段階での検証項目 全体リプレイスにおける課題 課題への対応策 今回の課題と今後の改善点 今後の展望 まとめ 背景・課題 セッションに依存したロジックの肥大化 ZOZOTOWNの購入フローは、Classic ASP（以下、ASP）で実装されており、長年の改修によりセッション情報がいたるところで更新される構造になっていました。この結果、ロジック間の依存関係が複雑化し、機能改善や保守の際の調査コストが増大するとともに、部分的な入れ替えも困難な状態でした。 サービス無停止でのリプレイス要件 ZOZOTOWNの購入フローは、ECサイトの中核をなすミッションクリティカルな領域のため、サービスを停止できません。さらに、リプレイス期間中であっても、新規機能の追加や運用改善は継続的に発生し、それらは既存ロジック側とリプレイス側のどちらにも反映する必要がありました。 その結果、移行にあたっては以下の制約を考慮する必要がありました。 ビッグバン切替の回避 ：一括での全面切り替えはリスクが高すぎる 二重開発の不可避 ：新旧両システムを並走する以上、修正は両方に入れる必要がある 段階的検証の必須化 ：各段階で十分に検証しながら、慎重に移行を進める必要がある これらの課題に対し、私たちは新システムの構築と段階的な移行戦略により解決を図りました。 新システムの構成とセッション問題の解決 既存システムの問題点 既存のASPシステムでは、購入フロー内のいたるところでセッション情報が更新される構造になっており、以下の問題がありました。 1. セッション更新の分散 どのタイミングで何が更新されるか追跡困難 機能改善時の影響範囲を特定しづらい デバッグやトラブルシューティングに時間がかかる 2. 部分的な入れ替えの困難さ セッション情報と密結合しているため、機能単位での切り出しが難しい 段階的なリプレイスを阻害する要因 3. 保守性の低下 新規メンバーがシステムを理解するのに時間がかかる セッション構造の変更が困難 新システムの構成 これらの問題を解決するため、責務を明確に分離した構成を採用しました。 既存システム（リプレイス前） ASP すべてのロジックとセッション管理が密結合 新システム（リプレイス後） 画面層（以下、Shopping BFF） ユーザーの入力値や購入フロー内の一時的な状態を管理 セッションで管理していた情報を専用のRedisで管理（購入フローに閉じた情報のみ） Java/Spring Boot ビジネスロジック層（以下、Shopping API） ビジネスロジックの中核を担う カート、注文、決済などのドメインロジックを実装 Java/Spring Boot、モジュラモノリス構成 Shopping BFF + Redisによる解決 新システムでは、Shopping BFFで状態管理を集約する構成にしました。 設計方針 購入フローに閉じた情報のみをBFFで管理 他のサービスと共有する必要のないデータ 注文プロセス中のみ必要な一時的な状態 Redisでの永続化 ZOZOTOWN共通のセッションではなく専用のRedisで管理 TTL（Time To Live）を設定し、不要なデータは自動削除 メリット 管理箇所の集約 ：BFFに状態管理を集中させた結果、見通しが向上 独立性の確保 ：各ドメイン（カート、注文、決済）の状態が明確に分離 状態管理をShopping BFFに集約し、ビジネスロジックをShopping APIに分離したことで、状態とロジックの責務を明確に切り分けました。これにより、セッション依存による密結合は解消され、機能単位での段階的な入れ替えが可能になりました。あわせて、システム全体の見通しと保守性が向上しました。 リプレイス戦略の全体像 なぜ段階的なアプローチを選んだか 段階的なアプローチを採用した理由は以下の通りです。 リスクの分散 ：機能を小さく区切って検証し、問題発生時の影響範囲を限定する 二重開発の最小化 ：新実装へ移行した範囲は旧実装への改修を減らせるため、早期リリースで並行開発の期間を短縮する 継続的なフィードバック ：各フェーズで得られた知見を次のフェーズへ反映する チームのモチベーション維持 ：小さな成功体験を積み重ね、長期プロジェクトでも前進感を保つ 3つのフェーズに分けたアプローチ これらの理由から、私たちは以下の3つのフェーズに分けてリプレイスを進めてきました。 フェーズ1：一部機能の比較フェーズ 既存ロジック（ASP）と新ロジックを並行稼働 結果を比較・検証し、差分を解消 フェーズ2：段階的な入れ替えフェーズ 比較で問題ないことを確認した機能から順次切り替え 二重開発の負担を最小化 フェーズ3：全体リプレイス 画面を含めた購入フロー全体を新システムに移行 n％リリースで段階的にトラフィックを切り替え フェーズ1とフェーズ2を機能単位で繰り返し、重要機能の切り替えが完了した段階でフェーズ3を実施します。 フェーズの関係性 フェーズ1・2ではビジネスロジック層のリプレイスを先行して進め、フェーズ3では画面層のリプレイスを実施する計画です。ビジネスロジック層を先に安定化させることで、画面リプレイス時には既に検証済みのAPIを使用できる体制を整えています。 現在の進捗状況 2026年2月時点で、フェーズ1・2は既にリリースが完了しており、本番環境で稼働しています。フェーズ3については開発が完了し、現在はリリースに向けた最終準備を進めている段階です。 次の章から、各フェーズの詳細について説明します。 フェーズ1：一部機能の比較フェーズ 比較対象の選定 リスクを最小限に抑えるため、 読み取り系の機能 を比較対象としました。具体的には以下の機能です。 お届け先一覧の取得 支払い方法一覧の取得 配送日時の指定一覧の取得 これらの機能を選んだ理由は以下の通りです。 読み取り専用 ：データの更新を伴わないため、万が一の不具合でもユーザーへの影響が限定的 検証が容易 ：結果の比較が容易で、差分の原因を特定しやすい 段階的な複雑化 ：条件が少ないお届け先一覧から始め、徐々にロジックが複雑な機能へと比較対象を拡大 即時停止が可能 ：比較モードを停止するだけで対応可能 並行稼働の仕組み 既存のASPから新しいShopping APIを呼び出す形で並行稼働を実現しました。以下がその仕組みです。 この仕組みの重要なポイントは以下の通りです。 フラグによる制御 ：対象機能を柔軟に切り替えられ、トラフィックの切り替えも即座に実施できる ASP側での比較 ：両方の結果をASP側で受け取り、差分をチェックする ユーザーへの影響なし ：ユーザーには常にASPの結果を返すため、体験に影響を与えない 比較情報の保存 ：各種情報をJSONで保存し、集計・分析できる 負荷の考慮 ：比較は一部サーバーに限定して実施する 比較・検証方法 保存した比較情報を定期的にチェックし、以下の観点で検証しました。 一致率の確認 ：どの程度の割合で結果が一致しているか 差分の原因分析 ：不一致の場合、どのようなケースで発生しているか 優先度の判断 ：ビジネスへの影響度から修正の優先順位を決定 特に重要だったのは、差分が発生した際の 根本原因の特定 です。多くの場合、以下のような原因がありました。 ASP側のロジックの暗黙的な仕様（ドキュメント化されていない挙動） データベースの参照タイミングによる差異 購入フローはミッションクリティカルな領域のため、これらの差分を1つずつ解消し、 100％一致するまで比較を継続 しました。 フェーズ1で得られた知見 比較フェーズを経て、以下の知見が得られました。 暗黙知の可視化 ：長年のシステムに埋もれていた仕様が明らかになった テストケースの充実 ：差分から得られた知見をテストケースに反映できた 段階的移行の有効性 ：小さく始めるアプローチが、リスク管理に有効であることが明らかになった 次のフェーズでは、この比較で問題ないことを確認した機能から、実際に切り替えを進めていきます。 フェーズ2：段階的な入れ替えフェーズ 入れ替え順序の工夫 比較フェーズで十分に検証した機能から、段階的に切り替えを進めました。具体的な順序の例と、その選定理由をいくつか紹介します。 順序 機能 特徴 1 お届け先一覧の取得 条件が少なく、ロジックがシンプル 2 支払い方法一覧の取得 決済方法の選択可否の判定ロジックが複雑 3 配送日時の指定一覧の取得 在庫や配送条件との連携が必要 この順序で進めた理由は以下の通りです。 リスクの段階的な増加 ：シンプルな機能から複雑な機能へ段階的に広げる 経験の蓄積 ：各段階で得られた知見を次に活かす 影響範囲の管理 ：問題発生時にトラフィックの切り替えをしやすい順序にする 切り替えの仕組み 比較フェーズで差分がないことを確認した機能については、以下のように切り替えました。 重要な変更点は以下の通りです。 比較処理を廃止 ：検証済みのため、比較情報の保存は不要 API結果を直接返す ：Shopping APIの結果をそのままユーザーに返す 旧ロジックの保守を停止 ：切り替え済み機能はASP側を保守対象から除外 二重開発の最小化 このフェーズでは、 二重開発を最小化 できたことが大きな効果でした。 段階的リプレイスのメリット： 切り替え済みの機能に対する新規追加や修正は、新ロジック（Shopping API）のみに実施する 旧ロジック（ASP）への反映が不要になり、開発工数を削減できる ビッグバンリリースとの比較： ビッグバンの場合、切り替え完了まで旧ロジックにも改修が必要になる 開発期間中は変更を二重に実装する必要がある 一方、段階的リプレイスでは、切り替え済み範囲が増えるたびにこの期間を短縮できる 例えば、新しい決済方法の追加が必要になった場合の修正範囲は以下の通りになります。 段階的リプレイス（API層移行済み） ：Shopping APIのみ修正 ビッグバンでのリプレイス ：ASPとShopping APIの両方を修正 このように、切り替え済みの機能については旧ロジックへの反映が不要になり、長期プロジェクトにおける開発負担を大きく軽減できました。 フェーズ2の成果 フェーズ2を通じて以下の成果を得ました。 対象機能の完全移行 ：読み取り系の主要機能をすべて新システムに移行 開発工数の削減 ：二重開発の期間を最小化し、チームの生産性が向上 品質の向上 ：段階的な検証により、問題を早期に発見・修正 次のフェーズでは、画面を含めた購入フロー全体を新システムに移行します。 フェーズ3：全体リプレイス フェーズ3では、画面を含めた購入フロー全体を新システムに移行する計画で進めています。 n％リリースによる段階的な移行 全体リプレイスでは、トラフィックを段階的に切り替える n％リリース を採用する計画です。同一ユーザーが途中で旧フロー・新フローを行き来しないよう、ユーザー単位で一度割り当てた割合を保持する形でルーティングする設計としています。 n％リリースの設計方針 段階的な切り替えにおいて、以下の方針で進める計画です。 段階 目的 検証期間 備考 1％ 本番環境での動作確認と想定外の問題の早期発見 長期 注文から発送完了まで問題なく処理されることを検証 20％ 1％で得られた知見を反映し、より大きなトラフィックでの検証 短期 問題がなければ次の段階へ 50％ 本番に近い負荷での最終検証 中期 大規模なトラフィックでの安定性を確認 100％ すべてのトラフィックを新システムに移行 - 万が一の問題に備え、即座にロールバックできる体制を維持 各段階での検証項目 各n％段階で、以下の項目を重点的に監視する計画です。 機能的な正常性 注文完了率 決済成功率 エラーログの監視 パフォーマンス レスポンスタイム スループット データベースの負荷 問題が発見された場合は、即座に前の割合に戻す体制を整えています。 全体リプレイスにおける課題 フェーズ3では、フェーズ1・2とは異なる課題に直面しています。 1. 機能改修とのコンフリクト 画面を含む全面リプレイスのため、リリースまで約1年半の開発期間が必要になる その間、既存システム（ASP）にも新規機能や改善が継続的に追加される 新旧両方のシステムに同じ変更を反映する 二重開発 が発生する 具体例としては以下が挙げられます。 新しい決済方法の追加 ユーザーインタフェースの改善 バグ修正や運用改善 これらをASPとShopping BFF/Shopping APIのすべてに実装する必要があり、工数が増加しています。 2. モチベーションの維持 長期にわたる開発により、チームのモチベーション維持が課題 「いつ終わるのか」という不安感 同じ機能を二重に実装する徒労感 課題への対応策 これらの課題に対し、以下のように対応しました。 1. フェーズ2の成果を活用 API層はフェーズ2で既に移行済みのため、Shopping APIへの修正のみで対応できる範囲が拡大 BFF層のみの修正で済むケースも多く、完全な二重開発を避けられた 2. 優先度の明確化 新規機能の開発は、極力リプレイスのリリース後に行う 緊急性の高い修正のみ二重開発で対応 今回の課題と今後の改善点 長期にわたるリプレイスプロジェクトにおいて、チームのモチベーション維持が課題として浮上しました。約1年半の開発期間中、同じ機能を二重に実装する必要があり、「いつ終わるのか」という不安感や徒労感がチームに蓄積しやすい状況でした。 今回の経験を踏まえると、次に同様のプロジェクトに取り組む際には、以下の点をあらかじめ検討しておくべきだと感じました。 プロジェクト初期段階でのマイルストーン設計 ：長期プロジェクトでも前進感を保てるよう、細かいマイルストーンを設定 定期的な成果の可視化 ：各段階での成果を可視化し、チーム全体で進捗を共有する仕組みの構築 チームメンバーのケア体制 ：長期プロジェクトにおけるメンバーの心理的負担に配慮した体制づくり 今後の展望 リプレイスプロジェクトの完了後も、以下のような継続的な改善と発展を計画しています。 新システムでの運用安定化と監視体制の強化 リリース完了後は、新システムの安定稼働を最優先とし、監視体制の強化に取り組みます。具体的には、パフォーマンスメトリクスの継続的な収集・分析や、エラー検知の精度向上、アラート体制の整備などを進めていきます。また、運用ノウハウの蓄積と共有により、障害発生時の迅速な対応体制を構築します。 モジュラモノリスからマイクロサービスへの段階的な移行検討 現在のモジュラモノリス構成は、開発効率とシステムの見通しの良さを両立できていますが、将来的にはマイクロサービスへの移行も視野に入れています。ただし、マイクロサービス化はトレードオフを伴うため、ビジネス要件やチーム体制、技術的な成熟度を考慮しながら、慎重に検討を進める方針です。 さらなるパフォーマンス改善と開発体験の向上 新システムへの移行により開発効率は向上しましたが、さらなる改善の余地があります。レスポンスタイムの最適化やデータベースクエリのチューニング、開発ツールの整備など、継続的な改善を通じて、より快適な開発体験とユーザー体験を実現していきます。 得られた知見を他のシステムのリプレイスにも適用 本プロジェクトで得られた段階的リプレイスの手法や、並行稼働による検証のノウハウ、長期プロジェクトにおけるチーム運営の知見は、社内の他システムのリプレイスにも適用可能です。これらの知見を共有し、組織全体の技術力向上に貢献していきます。 まとめ 本記事では、ZOZOTOWNの購入フローにおける段階的リプレイスの実践について紹介しました。 セッションに強く依存した既存システムを、3つのフェーズに分けて段階的にリプレイスしています。 一部機能の比較フェーズ ：並行稼働により、リスクを抑えながら新旧ロジックの差分を解消 段階的な入れ替えフェーズ ：検証済みの機能から順次切り替え、二重開発の期間を最小化 全体リプレイス （進行中）：n％リリースにより、画面を含む購入フロー全体を安全に移行する計画 また、Shopping BFF + Redisの構成により、セッション依存の問題を解消し、システムの見通しと保守性の向上を実現しています。 大規模ECにおける段階的リプレイスを検討している方や、ミッションクリティカルなシステムの無停止移行に取り組んでいる方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに   こんにちは！愛知工業大学大学院修士1年の杉原充稀です。   202 ...