こんにちは、サーバーワークス（SWX）の椿山です。
6月25日～26日に幕張メッセで開催された年に一度のお祭り「AWS Summit Japan 2025」ですが、 私も（数年ぶりに）Day2に行ってきましたので、その様子と特に面白かったセッションについて、前編・後編に分けてご紹介いたします。
後編は、「アーキテクチャ道場 2025 - 実践編！」のセッションレポートです。
※本記事は以下の前編の続きとなります。
目次（クリックすると展開されます）
セッションレポート②：アーキテクチャ道場 2025 - 実践編！
2つ目のセッションは、AWS Summitの人気セッション「アーキテクチャ道場」、今年のテーマは「実践編」。 ZOZO様、SBIセキュリティ・ソリューションズ様の具体的な事例を通して、優れたアーキテクチャを支える思考プロセスを学ぶ、非常に中身の濃いセッションでした。 本稿では、2つの事例から導き出された重要なポイントと、すべてのアーキテクトにとって指針となる「実践知」をご紹介します。
お題1：ZOZO様 - モダナイゼーションの過程で直面したボトルネックへの挑戦
2004年にオンプレミス・モノリシックで始まったZOZOTOWNは、スケーラビリティとアジリティを向上させるため、2017年よりクラウド移行とマイクロサービス化を軸とするモダナイゼーションに取り組んでいます。
依存関係の複雑さから一括移行は困難なため、採用されたのがストラングラーフィグパターンです。 まずAWS上にファサードを設置してユーザートラフィックを受け、そこから既存機能を一つずつ切り出してAWS上のマイクロサービスに移行していくという、段階的かつ安全なアプローチです。
この過程で課題となったのが「カート投入処理」。在庫引当を行うDBがオンプレミスに残っているため、セール時等にカート投入が集中すると、オンプレDBへの更新処理がボトルネックとなっていました。
解決のポイント：段階的な非同期化とデータ分離
この課題に対し、ZOZOTOWNは2つのフェーズでの解決策を講じました。
フェーズ1：更新処理の非同期化
カート投入リクエストを一旦FIFOキュー（Kinesis）で受け、ワーカーでオンプレDBのキャパシティに合わせて流量をコントロール。 更新処理の冪等性を担保させるために状態管理テーブルを作り、処理済みトランザクションをスキップ。 ユーザーにはカートイン時に画面で待たせることで、内部を非同期化してもユーザ体験を大きく損なわずに実用に耐えられるシステムにできたとのこと。フェーズ2：在庫データの論理的な分離
さらに、在庫数をAWS上のKVS（DynamoDB）に「論理在庫」として切り出し、オンプレDBへの更新負荷を根本的に低減。 オンプレの物理在庫とAWS上の論理在庫が異種間DBになるためトランザクションが利用できませんが、 オンプレの物理在庫との整合性は更新履歴をチェックして不整合を修正するバッチ処理で担保するという、現実的かつ効果的なアプローチでした。
この段階的な解決策により、最終的に5倍以上のリクエストにも安定稼働するシステムを実現したとのこと。 制約の中でいかにしてボトルネックを解消するか、非常に実践的な事例でした。
お題2：SBIセキュリティ・ソリューションズ様 - 勘定系システムの高信頼性クラウドアーキテクチャ
次に、地方銀行の新しい勘定系システムをクラウドで構築する事例。 勘定系ならではの極めて高い信頼性要件や、セッション維持・IP固定・外部システム側からの接続管理といった業界特有の通信要件をいかに満たすかがテーマでした。
特に厳格だったのがRTO（目標復旧時間）です。この要件に対し、障害のレベルに応じて最適な冗長構成を選択するという、非常に合理的な設計がなされていました。
解決のポイント：障害レベルに応じた「適材適所」な設計
ノード・AZ障害（RTO：1分）→ アクティブ・アクティブ構成
発生頻度が高く、即時復旧が求められるAZレベルの障害には、3つのAZにまたがるアクティブ・アクティブの冗長構成を採用。 AWS上のすべてのコンポーネントを自動復旧可能な構成とし、RTOへ最適化した設計です。
また、銀行店舗や外部システムとの接続部分は中間部分に「中継センター」を立てて、REST APIかつ名前解決による接続に変換させることで、 クラウドの弾力的な振る舞いとオンプレミスの状態が一定という考え方の違いを吸収させました。リージョン障害（RTO：1時間）→ アクティブ・パッシブ構成
発生頻度は低いものの、影響が甚大なリージョン障害には、アクティブ・パッシブ（ウォームスタンバイ）の構成を選択し、 切り替えの際に災対リージョン（大阪）の機能確認が行える最低限のリソースだけは確保。
オンプレ側（中継センタ）のファシリティ、物理ネットワーク、通信経路もすべて冗長化し、稼働リージョンの識別はDNS、通信経路の制御はBGPを利用して、柔軟かつ速やかに切り替えられる構成に。 これにより、RTOとコストをバランスさせています。
さらに印象的だったのが、オペレーション（障害時の対応フロー）の設計です。 ノード・AZ障害ではAWSレイヤーの障害はAWSサービスの標準機能でほぼ解決できるものの、アプリレイヤーの障害や依存サービス間の通信障害、AZ間の通信障害はAWSの機能だけでは難しく、細かい工夫が随所になされていました。
また、リージョン障害はビジネスインパクトが大きいため、その切り替えは最終判断に必ず人間を介在（ヒューマン・イン・ザ・ループ）させているとのこと。 ただし、判断材料の収集や復旧作業そのものは徹底的に自動化されており、判断を待たずに並行して準備を進めることで、サービス停止時間を最小化する工夫がなされていました。
AWS FIS（Fault Injection Simulator Service）を利用して本番環境でシステムメンテナンスを組んで切り替え訓練を実施（システムと人の運用を含む）し、RTOを満たすことを実際に検証する等、まさに「生きた実践事例」が紹介されていました。
すべての設計者に贈る、3つの「実践知」
この2つの事例を通して、現実世界の問題解決に共通する3つの「実践知」が抽出されました。
進化（＝変化＋適応）するアーキテクチャにする:
アーキテクチャは一度作って終わりではありません。マイクロサービス化で変化しやすくし、モニタリング結果からキューを分ける等、状況に適応させていくことが重要です。課題と制約を明確化し、解決すべき問題をシンプルに定義する:
現実の問題は曖昧で複雑です。何が本当に解決すべき課題なのか、どんな制約があるのかを見極め、シンプルに定義することが、良い設計の第一歩となります。アーキテクチャ設計は論理モデルから:
特定のAWSサービスありきで設計を始めるのではなく、 「何を解決したいのか（課題定義）」→「どう解決するか（論理モデル）」→「何を使って実装するか（物理モデル）」という順で考えることが、本質的な課題解決に繋がります。
感想
今回のお題はどちらも非常に実践的で、その解決策も示唆に富むものであり、とても参考になりました。
また、技術面（インフラ・アプリ）はもちろんのこと、サービス・運用面も含めた幅広い視点と高い視座から課題を整理してトレードオフを検討し、
豊富な知識と経験をもとに現実的な落とし所を見極めるソリューションアーキテクトという役割の重要性を再認識しました。
おわりに
数年ぶりのAWS Summit Japan、2日目だけでしたが現地で参加することが出来て、本当に良かったです！ セッション以外にも各ブースを駆け足で見て回ったのですが、 技術的な内容はもちろんのこと、これだけの規模の業界・業種、企業・団体や様々な人々（ビルダー？）が AWSに熱量を注いでより良いサービスを生み出そうとしている現実を目の当たりにして、大変刺激になりました。
来年のAWS Summit Japanもぜひ参加したいと思います。ここまでご覧いただきありがとうございました。
椿山 俊和 (記事一覧)
エンタープライズクラウド本部
2025年5月に40代後半で中途入社。AWS資格9冠。好きなAWSサービスはLambdaとCloudFormation。好きな飲み物はコーヒーとプレモルです。
