【セッションレポート】AWSサーバーレスにおけるSimplexity 戦略（AWS-40） #AWSSummit

AWS Summit Japan 2025
#AWS
#イベントレポート
#サーバーレス
#アーキテクチャ
ぐっさん
2025.06.28
 はじめにこんにちは！

クラウド事業本部コンサルティング部のぐっさんです。
AWS Summit Japan 2025の2日目に発表されたAWS サーバーレスにおける Simplexity 戦略というセッションのレポート記事となります。
 セッションの概要セッションタイトル: AWS サーバーレスにおける Simplexity 戦略
日時: 2025年6月26日（木）13:50-14:30
レベル: 400（上級者向け）
テーマ: モダンアプリケーション(コンテナ・サーバーレス・DevOps)、アーキテクチャ
登壇者: 中村 達也（アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト）
現代のクラウドシステムにおいて、サーバーレスアーキテクチャは究極のシンプル化を約束する重要な選択肢として位置づけられている。しかし、皮肉にもシステムをシンプルにしようとすればするほど、予期せぬ複雑性を招き寄せるというパラドックスが存在する。ビジネスでは様々な複雑性を生み出す要素に直面するためである。これらの複雑性に対して、本戦略では AWS re:Invent 2024 で Dr. Werner Vogels （VP and CTO, Amazon.com） が提唱した Simplexity （Simplicity + Complexity） の概念に基づく実践的なアプローチをご紹介します。開発者はこれらのアプローチを活用することで、サーバーレスの利点を最大限に活かしながら、複雑性を適切に制御することが可能になります。
※セッションページより引用
 資料セッションの動画が公開されていましたのでぜひ！（要登録）
https://summitjapan.awslivestream.com/aws-40/live/
 「問い」あなたは複雑さとどう向きあい、

AWS サーバーレスで、

シンプルさを実現しますか︖
セッションの冒頭でこの問いが投げかけられました。

どう向き合っているだろうか・・・と考えながら続きに耳を傾けます。
 セッションで伝えたいこと伝えたいこととして、以下の項目が挙げられました。
Simplexity 戦略における複雑さとシンプルさ
あらゆるシステムは複雑である
AWS サーバーレスも複雑さに直⾯する
シンプルさをどう実現すれば良いか

AWS サーバーレス活⽤における 3 つの Simplexity 戦略
分割統治
⾵通しのいいアーキテクチャ
関⼼の分離
任せて放置せず
進化への対応
安全安⼼に、⽌まらない

 そもそも「Simplexity」とは「Simplexity」という言葉はあまり耳馴染みがないですが、昨年のre:InventのDr. Werner Vogelsによるキーノートで語られた言葉です。
Simplicity ( シンプルさ ) + Complexity ( 複雑さ ) が組み合わさった造語であり、

シンプルさの原則に基づいて複雑なシステムを設計・管理する考えです。
サーバレスでどのように複雑さに対処していくのかを見ていきます。
 Simplexity 戦略における複雑さとシンプルさ 概念について複雑さとシンプルさの言葉の意味
複雑さ: 要素の数とつながりの多さ
シンプルさ: 扱いやすい状態のこと
システム構築のフロー例

⽬的/実現したいことがある （ex. ECサイト、ゲーム...）


⽬的を実現するための構造やロジックを考える （ex. ドメイン、データフロー...）


⽬的を実現するために⽤いる技術を決める（ex. ネットワーク、ストレージ...）

複雑さとは、上記のようなシステム構築の決定プロセスにおける様々な要素と要素の繋がり、またその繋がりの多さのこと。

シンプルさとは、これらを扱いやすいようにすること。

扱いやすいようにする手段の一つとして以下のような技術が挙げられます。
分散アーキテクチャ
ドメイン駆動設計
コンテナ技術
生成AI
AWSサーバレス
 AWSの複雑さとの向き合い方の紹介Amazon CloudWatchの開発における複雑さへの直面
現在大規模なデータを扱っているCloudWatchもSimplexityの考えをもとに取り組まれているサービス
サービスのリリース当初はフロントエンド、バックエンド（読み取り/書取りを行うのみ）のシンプル構成
サービス拡大に伴い、機能拡張がフロントエンドで行われた
フロントでの開発に伴う修正・変更の影響範囲が大きくなりテストやデプロイの工数増加=扱いづらい複雑な状態になった
どう対応したか？→3つの戦略
システムの細分化
大きなシステムを細かく分割すること

疎結合かつ⾼凝集度
疎結合: 分割した部品が少ない依存関係で繋がっている状態
⾼凝集度: 関連する機能や責務をまとめている状態

明確に定義されたAPI
分割した部品間がどのように連携するのか
データ形式や通信方式、エラー時の振る舞いを明確に定義

結果
元々あった大きなフロントは小さなサービスとなり、バックエンドには各種モジュールが全体で調和しながら構成されるように◎
 テスラーの法則ここでテスラーの法則の言葉が紹介されました。
複雑さは意図的に作られるものではなく、

意図的に消すこともできない。

ただし、

どこかに移動させることだけはできる。
AWSは、複雑さを移動させながらどのようにシンプルにしていくのかを、複雑さに向き合いながら考えているとのこと。

ふ、複雑・・・！
 複雑さの移動について「複雑さは避けられないが、移動させることはできる。」
複雑さの移動について
特定の課題を解決するためにテクノロジーによる解決を試みるが、そのテクノロジーが引き受ける領域（複雑さ）もあれば引き受けられない領域（複雑さ）も存在する。
引き受けられない領域がある場合は特定のテクノロジーから、その領域を引き受けられる別のテクノロジーに波及していく。
さらにテクノロジーの他に、複雑さの管理を行う人間の組織などの要素も絡んでくるために別の課題や手段に波及していく。
結果的にそれが開発/運用のオーバーヘッドに繋がったり最小権限の実現が難しくなるなど「意図しない複雑さ」を生み出す可能性がある。
このような複雑さを生まないために「戦略を持って」複雑さに対処していく必要がある。

 AWS サーバーレス活⽤における Simplexity 戦略戦略は以下の3つです。
分割統治 ⾵通しのいいアーキテクチャ
関⼼の分離 任せて放置せず
進化への対応 安⼼安全に、そして⽌まらない
 分割統治「分割統治という選択を通して⾵通しのいいアーキテクチャを目指す」
分割統治とは？
複雑な課題を小さな課題に「分割」し、それぞれで対処（「統治」）し複雑な課題を解決すること
日常の身近な例（とてもわかりやすかったです！）: 引越し
家の荷物を運ぶ課題
一気に運ぶのは大変なため部屋ごとに段ボールを分けて運び新居で再配置
もしくは荷物のサイズ毎に分けて運ぶ
我々は意識せずとも「分割統治」戦略を用いて様々な課題に対処していると言える
サーバーレスで分割統治という戦略を用いる場合の例
内容に応じて処理を分割し、それを実現する対処方法を組み立て全体のアーキテクチャを考える
このアーキテクチャ決定のプロセスが分割統治となる
どうすれば分割統治を用いて複雑な課題の解決がうまく出来るか？
効果的に実現するための問い
⽬的に沿って分割をしているか
分割のアプローチとしてレイヤー分割、機能単位の分割等と様々な選択肢があり、正解はない
多くのパターンが取れることにより、誤った選択を取る可能性がある（必要のないシステムでマイクロサービスを構成するなど）
重要なことは目的であり、処理のフローや要件に応じて「どこに複雑さが移動するのか」「何を実現したいか」判断することが大切

コミュニケーションがスムーズか
コミュニケーションとは、要素同士がどのように繋がるかという観点
API連携、イベントバス、キューイングなどの手法があるが各サービス間で無駄な連携がなく、インターフェース定義が明確になっていることを押さえることが必要

調和が取れているか
「ヴァーサ号の悲劇」「ブリュワーのCAP定理」をもとに、全てを満たすことは難しいことを示唆
分割統治を用いて複雑な課題に対処できるが、全てのアーキテクチャはトレードオフである
矛盾や偏りがなく、バランスが取れてシステム全体の調和が取れている状態を目指す


これらが「風通しの良いアーキテクチャ」

 関⼼の分離「関⼼の分離という選択を通して任せて放置せずという状態を目指す」
関⼼の分離とは？
関⼼ごとを分離することでシンプルに複雑さを扱うことができるという考え
日常の身近な例（とてもわかりやすかったです2！）: 洗濯
テクノロジー（洗濯機）が洗濯をするという複雑さを引き受ける
我々はボタンを押すことで複雑さを「管理」できる
洗濯機は乾燥まではしてくれない
別のテクノロジー（乾燥機）を使用して乾燥を代替していく必要がある
我々は、そのテクノロジーがどのような複雑さを引き受けるのか、それをどう管理するのかを理解することが重要
サーバーレスの場合
Lambda: スケーリング機能によってコンピューティングリソースの同時実行管理を引き受ける
我々: 同時実行数を決め、複雑さを管理
SQS: 非同期処理がある場合に代替する
サーバーレスがどのような考えで関心ごとを分離しているのかを理解する
どうすれば適切に関心の分離が出来るか？
効果的に実現するための問い
適切に任せられているか
サービスの特徴や自分が何をコントロールできるかを理解し目的に応じて各サービスに任せる

任せる ≠ 何もしない
任せると言っても何もしないわけではない
責任を持ち、任せた関心ごとについて適宜状況を把握し改善を行うことが必要
オブザーバビリティ、レジリエンス、同期/非同期呼び出しの管理など

使いこなす⼒を持っているか
サービス理解、アーキテクチャパターン、最新情報のキャッチアップなど
過去の経験にとらわれず、新たな機能に対してトライアンドエラーを繰り返す


「任せて放置せず」

 進化への対応「進化への対応を通して安全安⼼に、そして⽌まらない状態を目指す」
リーマンのソフトウェア進化の法則
システムは継続的な変化、成長が必要（変化・成長がないと関わる人の満足度低下に繋がる）
何もしなければ進化に伴い複雑さは増加し品質が低下する
つまり進化への対処が必要
将来を考慮した機能
将来の進化の可能性を考慮したテクノロジーは人やプロセスにも波及
対応するにあたり管理者のスキルや組織体制があるか、プロセス定義がなされているかなどのバランスを見る
多くの場合過剰投資となる
どのように進化への対応に備える？
対応するための問い
安全な⼿法が確⽴されているか
サーバーレスの進化は、既存のサービスの設定変更またはサービス追加対応をすることで、影響範囲を抑制しやすい
例: 既存のLambda→DynamoDBの構成で新規イベントデータ送信を外部へ行う場合
Lambdaを変更するのではなくDynamoDB Streams→EventBridge Pipes→EventBridgeへイベントを送付
影響範囲が明確に分離しているため安全に対応しやすい（安全に進化できる）


安⼼して進化できる状態か
テクノロジーだけでなく人やプロセスも進化への対応ができるようにする
組織のチームの構成や役割の分割などの戦略が適切か

⽌まらない⽂化はあるか
進化への対応は⼈、プロセス、テクノロジーが三位⼀体
⾮難がない事後検証（ヒューマンエラーは出発点と捉え、進化するためのきっかけと考える）
継続的なフィードバックループを⾏い、進化に対応する


「安全安⼼、そして⽌まらない」

 まとめ複雑さは避けられず移動させるだけだが、管理はできる
サーバーレス活⽤における 3 つの Simplexity 戦略
分割統治
関⼼の分離
進化への対応

 最後に特定の目的を果たすために問題解決を行うと、その目的を果たすための別の課題が浮上して徐々に複雑化していくことは日々の業務や生活の中でも直面することが多々あります。

それがテクノロジーによる領域のみでなく、人間や組織の関与が避けられず技術以外の予期せぬ複雑さが生まれることも身にしみて感じます。
あなたは複雑さとどう向きあい、

AWS サーバーレスで、

シンプルさを実現しますか︖
冒頭の問いに対して
複雑な問題を目的に沿った適切な粒度でバランスを取りながら分割し
それを解決する手法を理解した上で選択/管理し
より安全な方法で変更や機能追加に対応できるようなサービスの新技術を臆さずに取り入れる
このような答えを持ち帰り、戦略を持ってシステムの設計を考えることの大切さを学べたセッションでした！