はじめに
AWSが年に一回開催する超大型イベント「re:Invent」ではKeynote（基調講演）が5つ行われます。
そのうち、4日目の朝に行われるWerner VogelsさんのKeynoteは開発者向けの内容になっています。
ソフトウェア工学に関連する法則や言葉を取り上げつつ、AWSやAmazonで大事にしてきた技術的な観点での教訓などが話されます。
毎年非常に示唆に富んだ内容で、エンジニアから根強い人気を持つKeynoteです。
2024年のre:Inventでは、Amazonが大事にしてきた「6つの教訓」について話されていました。
この記事では、その内容を簡単にまとめて記載していきます。
なお、OpsJAWS Meetup32で似た内容を話していますので、ご興味があればそちらも併せてご覧いただけると幸いです。
（この記事の中でも、登壇資料からところどころ抜粋しています）
また、このKeynoteの後半ではre:Invent 2024で発表されたAurora DSQLについてDive Deepして説明されていました。
そちらもとても面白い内容になっていますので、ご興味があれば合わせてご覧ください。
6つの教訓のベースとなるキーワード「Simplexity」
6つの教訓について話される前に、システムの複雑性とシンプルさの相関関係を示す「Simplexity」という概念について話されました。
Wikipediaなどを見ると小難しい概念のように思えます。
ざっくりとまとめると、システムが拡大していくと複雑になることは避けられないが、なるべくシンプルに保ち続けるために複雑さを管理する必要がある、ということです。
実際にAWSのサービスで考えると、S3の裏側では非常に複雑で複数のマイクロサービスが動いているが、複雑さをうまく管理しているという話がありました。
その一例として、S3の強い整合性の実装について紹介されていました。
過去のS3では、バケットを作った後すぐにバケットを使えないことがあり、ユーザー側で整合性を保つように実装をしていました。
しかし、この部分の実装をユーザーにゆだねるとシステム全体が複雑になるため、S3のサービスの中に強い一貫性を組み込んでしまった。
こうすることで、ユーザーからしてもS3を使いやすくなったと。
このように、複雑性をうまく管理してなるべくシンプルに保つことが重要であると述べられていました。
加えて、複雑性はコンポーネントの数の多さとは関係しないという補足もありました。
例えば、一輪車はシンプルな構造で小回りが利きやすいが、乗ることが難しい。一方で、三輪車は乗るのが簡単だが小回りは効きにくい。
このように考えると、乗りやすさと小回りの効きやすさのどっちも兼ね備えているのが自転車である。
全体的な観点から考えると一番使いやすくてシンプルだが、一方で構成されるコンポーネントは一番多い。
このような考え方はシステムにも当てはめることができるため、「複雑さ＝コンポーネントの数の多さ」と考えるべきではないと話されていました。
Lehman's laws of software evolution
6つの教訓に関連する考え方として、Lehman's laws of software evolution（リーマンの法則）というものも紹介されました
これは、時間が経過するにつれてソフトウェアがどのように進化していくのかを考える時に使えるフレームワークです。
メインフレームを元に考えられている8つの放送が定義されていますが、その中でも一部はクラウドや分散システムでも当てはまると紹介されました。
この進化に対してAmazonが対応していく中で学んできた教訓、それが今回の記事の主題である「6つの教訓」です。
ここから、「6つの教訓」についてそれぞれ説明していきます。
教訓その1：Make evolvability a requirement（進化可能性を必須要件にする）
これは「アーキテクチャを再検討する可能性を常に意識しておく」という教訓です。
複雑性を管理するために欠かすことができない前提条件であると紹介されていました。
この例教訓の例として、再びS3が登場しました。
S3はリリース当時から追加機能がどんどん増えていて、今では裏で動いているマイクロサービスが約300にも及んでいる。
しかし、ユーザーはこの増加の影響を全く受けることなくS3を使うことができている。
この裏側では、ソフトウェア的な改善だけではなく、根本のハードウェアの改修も行っていると話されていました。
進化可能性を考慮したからこそ今のS3がある、そのようなAmazonの思いが伝わる一例でした
また、進化可能性は保守性とは明確に異なるとの言及もありました。
Keynoteの言葉をそのまま使うと、それぞれ以下のような観点におい違いがあると述べられていました。
- 進化可能性
- 長期的で大域的な変化のことで、根本的、機能的、構造的な強化のこと
- 保守性
- 短期的で局所的な変化のことで、修正的、適応的、予防的な強化のこと
進化可能性で全体的な方向性を定めたうえで、その方向性に従って保守性を考える、そのような話がされていました。
教訓その2：Break complexity into pieces（複雑さを分解する）
これは、システムが複雑になっても管理しやすい状態を保つためには、複雑さを細分化する必要があるという教訓です。
細分化することで小さな警告サインに気づくことができ、より複雑になることを防ぐことができる。もしも小さな警告サインに気づけずにいると、システムはより複雑かつ管理困難になると話されていました。
この教訓の例として、CloudWatchが取り上げられていました。
CloudWatchも最初はシンプルなシステムだったが、機能拡充するにつれてフロントエンドがどんどん複雑になっていった。
しかしこれは「メガサービス」というアンチパターンなので、機能のコア部分をフロントエンドから分離させる対応をしたと話されていました。
このように分解させておくと、将来的に機能性の向上が容易になるだけではなく、ライブラリやプログラムの観点でも改善が可能であると述べられていました。
では、それぞれのシステムはどれくらいの大きさにとどめておくべきなのか？
これに対する明確な答えはないと話されていましたが、新しい機能を追加するときに、拡張するか新しく作るかという観点で考えてみると良いと述べられていました。
- 拡張は素早くできるが、拡張しすぎるとメガサービスになってしまう
- 追加すると複雑性の分解が可能になる
一方で分解を進めていくとある問題に直面します。
それは、サービス全体がどんどん大きくなり、その大きさがエンジニアのメンタルモデル対する高い負荷になってしまうということです。
では複雑性にたいして組織がどのように対応していくのか？
その答えが次の教訓「Align organization to architecture」につながります。
教訓その3：Align organization to architecture（組織をアーキテクチャに合わせる）
教訓その3では、複雑性に対応するための組織の対応方針について話されていました。
この教訓については、S3の開発チームのエンジニアの方から話がありました。
ここでは、組織の対応方針には大事なことが2つあると紹介されていました。
一つ目は、順調に行ってるときこと少し怖がるべき、そのために質問することを推奨するということです。
「いつもそうしてきたから、今回もこうする」は危険なサインであり、常に少し危機感を持つことが大事。もっと疑問に持って質問することで、警告に気づいて対応することができると話されていました。
二つ目は、組織にオーナーシップを持たせ、エンジニアにサービスを気に入ってもらうということです。
そのために組織のリーダーたちがすべきことは、チームに対してすべきことを指示することではない。課題とその重要性を説明し、チームメンバーを信頼し、構築するもののオーナーシップを与えることだと話されていました。
教訓その4：Organize into cells（セル単位で組織化する）
これは、セルベースアーキテクチャのようにシステムを小さい構成要素に分解し、障害発生時の影響範囲を狭めるべきという教訓です。
セルベースアーキテクチャを考える時に、「セルはどれくらいの大きさにするべきか？」という疑問があります。
これについては、最大のワークロードに耐えうる大きさ、最小限の処理ができる大きさ、この中間が最適であると話されていました。
セルベースアーキテクチャについての詳細は公式ドキュメントに記載されていると紹介がありました。セルベースアーキテクチャについて話すと長くなってしまうので、詳細な説明は割愛させていただきます。
興味がある方は、せひ公式ドキュメント読んでみてください。
教訓その5：Design predictable systems（予測可能なシステムを設計する）
これは、システムから不確実性を取り除くという教訓です。
この教訓が生かされている例として、ELBとRoute 53が紹介されていました。
設定変更を行ってから反映されるまでの仕組みにおいて、一般的によく考えられるのはイベント駆動アーキテクチャである。しかし、イベント駆動アーキテクチャにしてしまうと、設定変更が集中した時の負荷が予測不可能になる。
そのため、AWSではこの構成は採用しておらず、もっとシンプルな構成にしていると紹介されていました。
具体的には、全ての設定内容はファイルに保存しておき、設定変更があったら設定ファイルをまず最初に更新する。そして、ELBから数秒間隔で定期的に設定ファイルを取得しに行くという構成になっている。
こうすると負荷が予測可能になり、構成もシンプルになると話されていました。
Route 53で設定変更が反映されるプロセスも類似の構成になっており、このような考え方をAmazonでは「constant work」と呼んでいるとのことでした。
constant workについてはWernerさんのブログも紹介されていましたので、興味がある方はぜひご覧ください
教訓その6：Automate complexity（複雑さを自動化する）
これは、高度は判断力を必要としないものはすべて自動化するという教訓です。
ここで語られていた「何を自動化するのではなく、何を自動化しないのか考えるべき」という発言が個人的にかなり刺さりました。
なんでも自動化するのではなく、「高度な判断力を必要とするかどうか」という軸に従って考える。高度な判断力が必要ではないものはすべて自動化する。そのような指針に立って自動化を進めることを推奨されていました。
また、AWSが自動化に特に力をいれている分野はセキュリティであるという話もされていました。
AWSでは全員がセキュリティエンジニアであり、何よりも一番最初にセキュリティの設計から始めているという話がされていました。
加えて、AWSでの自動脅威検知機能についても「高度な判断力を必要としないことを自動化する」を言う考え方に基づいて設計されていると話されていました。
完全に自動化されたプロセスによって悪意あるアクセスを検知し、その情報をGuardDutyに連携しているとのことでした。
Share your lessons
この6つの教訓について話された後に、「Share your lessons（教訓を共有しよう）」というメッセージとともにAWS Heroを称える一幕がありました。
ここではAmazonの教訓を話してきたが、皆さんの中にも教訓があるはず。それをどんどん共有して他の人たちを支援してほしい。そんなWernerさんからのお願いが最後に語られていました。
JAWSのようなコミュニティやユーザーによるアウトプット、フィードバックを非常に重要視しているAWSらしさあふれる締め方だなと感じました。
まとめ
以上、教訓6つのまとめについてそれぞれ説明をしてきました。
- 進化可能性を必須条件にする
- 複雑さを細分化する
- 組織をアーキテクチャに合わせて調整する
- セルに整理する
- 予測可能なシステムを設計する
- 複雑さを自動化する
このKeynoteで語られた内容は抽象的なので、おそらく人によって理解や解釈が異なったりする部分があると思います。
「こういう考え方もあると思う」という気づきがあれば、ぜひSNSやコメントで共有してください。
もちろん、「この部分に共感した！」という感想もWelcomeです！
気づきや教訓をどんどん共有して、AWSコミュニティを盛り上げていきましょう！
Share your lessons！！
参考
文章で読みたい方はこちらのブログをご覧いただくと良いかと思います。
Keynoteの内容がすべて日本語で文字起こしされているので、文章派の方にはうってつけの記事になっていると思います。