こんにちは、約1年ぶりの記事になります、小林です。 昨年12月にラスベガスで行われた AWS re:Invent 2024に現地参加させていただきました。 そろそろ4か月経とうというところですが、個人的に最も印象深いセッションであったWerner博士のKeynoteの「複雑さへのアプローチ」の部分について紹介をさせていただこうと思います。
私自身リーダーとして業務整理から要件定義、アーキテクチャ設計まで携わっている中で参考になる部分が多い内容であったため、似たようなポジションの人の参考になればと思います。
Werner博士のKeynoteについて
Werner博士のKeynoteは毎年AWSのアップデートについての発表は少なめになっており、最新の技術トレンドやシステム開発におけるさまざまな課題、それに対するAWSのアプローチなど、エンジニアへのメッセージを提供する場として知られています。今回の re:Invent 2024 ではシステム開発における「複雑さ」をどのように扱うかについての話がありました。そのほか、分散データベースの設計についての話もあったのですが、そちらはこの記事では割愛させていただきます。
Werner博士のKeynoteは以下サイトで動画を視聴することができるため、全内容が気になる方はぜひ視聴してみてください。
https://www.youtube.com/watch?v=aim5x73crbM
また、余談ですがWerner博士は毎年 re:Invent の時期に技術の進化による未来のビジョンについて考察を行なっています。2025年以降の予測について以下の記事で公開されていますので、こちらも読んでみると面白いかと思います。
2025 tech predictions from Amazon CTO Werner Vogels: AI, energy efficiency, more
複雑さについてのWerner博士の話の要約
以下は翻訳ではなく、私がKeynoteを聴講した上で個人的に理解した内容や補足が入っています。抽象的な内容が多く含まれていたため、人によって解釈が異なる部分があるかと思います。あらかじめご了承ください。
「複雑さ」を管理することが重要
システム開発はその性質上、複雑さを伴います。技術の進化やビジネス要件の変化に対応するため、開発者は必然的に複雑なシステムやプロセスを設計しなければなりません。それをどう管理するかがプロジェクトの成功を左右します。
例えばKISSの原則という考え方があります。KISSの原則とは「Keep it simple stupid.」もしくは「Keep it simple, stupid.」の略で、システムやプロセスは可能な限りシンプルにするべきという考え方です。しかし、最初のシステムがシンプルでも、運用を続ける中で機能追加やスケールをすることで複雑性は増加していきます。これはビジネスが成功しているということであり、決して悪いことではありません。
またテスラーの複雑性保存の法則という考え方があります。これは複雑さを完全に取り除くことは難しく、ある部分から複雑さを取り除いても他の部分に移行するという考え方です。そのため、システムで全てのプロセスをシンプルにできるというわけではありません。
複雑さを管理するためには、その複雑さが意図した複雑さなのか、意図しない複雑さなのかを理解することが重要です。その上で複雑さをうまく管理して、なるべくシンプルに保ち続ける必要があります。
例として、S3では裏で複数のマイクロサービスが動いているが、複雑さをうまく管理してシンプルにしているという話がありました。 過去のS3ではオブジェクトを書き込んだ後、すぐにそのオブジェクトが使えないことがあり、ユーザ側で整合性を保つような実装が必要でした。これではユーザ側での開発が複雑になってしまうため、S3に強い一貫性を組み込むことでS3を使いやすくしたとのことです。
Simplexityと6つの教訓
Simplexityとは「複雑さ」と「シンプルさ」の間の関係性を示唆する造語とのことです。上述とおり、システムが拡大していくと複雑になることは避けられません。しかし、なるべくシンプルに保ち続けるために複雑さを管理する必要があります。そのバランスのことをSimplexityと呼んでいるようです。
また、Werner博士はこのSimplexityをうまくとるための方法として、AWSがこれまでのシステム開発で得た以下の6つの教訓について解説しました。
1. Make evolvability a requirement（進化性を要件にする)
将来的にアーキテクチャの変更が入ることを考慮し、なるべく柔軟な設計にしておこう、という教訓です。例として、S3は現在では裏で300以上のマイクロサービスが動いており、これまでにハードウェアの改修も行っていますが、ユーザはその影響を受けることなくシステムを利用できているとのことでした。
2. Break complexity into pieces(複雑さを細分化する)
複雑なシステムは管理が容易な小さな構成要素に分割する必要がある、という教訓です。例としてAmazon CloudWatchは最初はシンプルなサービスでしたが、時間の経過とともに複雑化していきました。そのため、疎結合な小さい構成要素に分割する対応をしたとのことです。
システムをどの程度の大きさで分割するべきか、については明確な答えはありませんが、新機能の追加が必要となったとき、機能を追加するのか新しくサービスを作るか、という観点で考えてみると良いと話されていました。
また、ゆでガエル理論についても紹介し、兆候を見逃すことでシステムはどんどん複雑化し、管理が困難になると発言していました。ゆでガエル理論とは、カエルを常温の水に入れたあと温めていっても温度の変化に慣れてしまうので逃げ出さず、最後は茹でられてしまうという話です。転じて、ゆっくりと変化が進むことで危険を察知するのが遅れ、手遅れになってしまうという意味です。
3. Align organization to architecture(組織をアーキテクチャに合わせる)
組織はシステムのアーキテクチャと同じくらい複雑になることを認識する必要がある、という教訓です。
複雑性に対応できる組織を作るために2つのポイントが紹介されました。1つ目は、うまくいっていることを怖がることです。「いつもそうしてきたから、今回もこうする」は危険であり、それでよいのか、常に考える必要があるとのことでした。
2つ目は、組織にオーナーシップを持たせるということです。そのためにはリーダーが指示を行うのではなく、チームに課題を連携し、メンバーと信頼関係を構築していく必要があるとのことでした。例として、S3チームは、メンバーがオーナーシップを持って自律的に動くことで成果を出しているとのことです。
4. Organize into cells(セルに整理する)
システムを小さいセルに分割することで、障害の影響範囲を最小限に抑えることができる、という教訓です。2つめの教訓である複雑さの細分化と似ているのかなと個人的には思ったのですが、そうではなくセルベースアーキテクチャのことを指しているようです。 セルベースアーキテクチャについてはAWSの公式ドキュメントで解説されています。
Cell design - Reducing the Scope of Impact with Cell-Based Architecture
5. Design predictable systems(予測可能なシステムを設計する)
システムの動作を予測可能にすることで、複雑さを軽減できるという教訓です。例として、ELBやRoute 53が挙げられました。設定変更がシステムに反映される仕組みとしてイベント駆動アーキテクチャがありますが、イベント駆動にしてしまうと設定変更が集中した時の負荷の予測が難しいとのことです。そのため、AWSではすべての設定をファイルに保存しておき、数秒間隔で定期的に設定ファイルを取得しに行くという構成にしているようです。そのため、負荷が一定になり予測可能となり、構成もシンプルになっているとのことでした。
6. Automate complexity(複雑さを自動化する)
高度な判断力を必要としないことを自動化する、という教訓です。大規模システムを管理するためには自動化が必要ですが、その際に何を自動化するかではなく、何を自動化しないかを考えるのが重要とのことでした。例としてGuardDutyの自動検知と連携など、セキュリティの自動化の話が挙げられました。
感想
長文になってしまったのですが、Werner博士がKeynoteで紹介した内容はどれもシステム開発を経験していたり、組織に属していれば心当たりのある内容なのではないでしょうか。
複雑性に対するアプローチということで最近またトレンドになっているDDD（ドメイン駆動設計）を思い浮かべた方もいるかもしれません。業務が追加されることでシステムの複雑性が上がることは避けられないこと、また複雑さをコントールすることが重要であることはDDDの序文でも同じく述べられています。DDDとWerner博士の述べた6つの教訓では複雑さに対するアプローチの手法は異なりますが、DDDは2003年に発表された内容なので、Werner博士はDDDを踏まえた上でAWSというメガサービスを開発する中で得た知見を言語化した手法を今回私たちに共有してくれたのかもしれません。
業務やシステム、組織の複雑性という課題は、これから先もエンジニアが考え続ける課題となりますが、定期的にWerner博士のメッセージを振り返り、現状でよいのか、よりよい方法がないか模索していければと思いました。
