re:Invent2024 CTO Keynoteからの学び

re:invent2024では、たくさんのセッションがあり、それぞれに学びがありました。その中でも、一番の注目であり内容も最も興味深かったCTO Dr. Werner Vogels Keynoteについて取り上げます。正確な日本語訳は、たくさん記事も出ているので他にお任せします。また、アーカイブ動画も英語字幕付きで公開されています。そのため、ここでは個人的に学びになったポイントを抜き出し、併せて日々仕事で私が考えていることと重ねて書いてみたいと思います。

KEY005 | Dr. Werner Vogels Keynote

• VP and CTO, Amazon.com
• 公式サイトの紹介文(翻訳)

 Amazon.com の VP 兼 CTO である Werner Vogels 博士が、ますます複雑化するシステムを管理する上で学んだ重要な教訓と戦略について語ります。
 基調講演では、大規模な分散システムを構築してきた Amazon の経験を基に、複雑性を受け入れるための基本原則を探ります。

---

複雑さを内包したシンプルの哲学

• Amazonに入社して20年間、CTOとしてどういう形でサービスを形作っていくか考えてきた。
• 物事は時間が経てば複雑になっていくが、シンプルであることを求めている。複雑なものをシンプルにする哲学でやってきた。
• 一輪車と三輪車の例。自転車は、1輪ではなく3輪で乗り方を学習する。つまり、自転車は複雑なパーツを含む状態がよい体験になる。
  

Change is constant

• 現実世界は常に変化している。ソフトウェアも進化させ続けないければならない。
• 進化可能性(Evolvability)にためには、変化に対応するため可観測性が必要である。
  
• 変化に気が付かない(観測できないと)ゆでガエルになってしまう
  

セキュリティファースト

• デザインするよりずっと長くオペレーションする。セキュリティ、コストコントロール、管理性に投資すべきだ。
  

• 最初にセキュリティのことを考えるべきだ。
  

複雑性を内包するコンセプトのAWSサービス/リソースによる実現

Cell-based arch

• 影響範囲を狭める設計。複雑性を押し込める。
• cellは管理できる最大単位がよい。
  

Event-driven arch

• 負荷分散を管理しなくて良いアーキテクチャ。複雑性を内包させることができる。

• 単純化が予測可能なシステムを実現する。

• S3に複雑性を内包させる
  

Health Check

• route53にヘルスチェックさせる方法

• 名前解決とヘルスチェックをシンプルに実現

DSQL

• RDS、メンテナンスの作業を低減した。
• Auroraの内部のコンポネートは中身は複数の機能で分かれており、それぞれ違った指標でスケールする。それが１つのコンポーネントになっている。
• 分散したストレージのどこにデータがあるかを調べるのが大きなボトルネックだった。
• リージョン毎のトラザクションは別々にローカルに処理し、Adjudicatorでぶつけるようにした。
  

時刻同期は基本的な機能になった

• 複数の書き込みトランザクションの実現は複雑だった。2フェーズコミットは、時間が使えなかったから(仕方なく)やっていたんだ。

• 30年で正確な時間同期が発明され、最近HW実装された。

• EC2に実装した。衛星を活用している。
  

• 1μs単位の正確性を確保できる。

• トランザクションの前後性を時間で保証できる。
  

自動化によるシンプル化

• 何を自動化するかではなく、何を自動化しないかだ。
  

• 自動化はスタンダードにすべきだ。

• 人間による決定だけを明確にし、それ以外は自動化する。

• 多くは人の作業を必要としているが、多くは自動化できる。

• Bedrock(生成AI)はそれを助けてくれる

キーワードによる振り返りと学び

世界は複雑で常に変動している。変化し続けること安定だ。 物事は必ず複雑化していく、常にシンプルを維持するように、変化する必要がある。

• この話は、分子生物学社の福岡伸一さんの著書に出てくる、宇宙の法則である「エントロピー増大の法則」（あらゆるものは秩序から無秩序に変化する。ex. 机の上が書類が散らばっていく)と生命は秩序を維持するためにエントロピー増大の法則に抗うために自分自身を壊して作り直している。この現象を動的平衡と呼んでいます。エントロピー増大の法則に負けて、動的平衡が止まる時がすなわち死ぬときです。

• コロナ禍のときに私はこの本を読んで、漠然と思っていた「変化こそ安定」が説明されたような気がしました。Dr. Wernerはシステムにおいても、壊し作り変えられることを哲学としているといます。

• 反対例を考えると、PoCだから、とりあえず通すので良いから、現時点の要件にないからと組み立ててしまうと、秩序あるシンプルが保てない。作り替えることができる仕組みにならないとということもあるでしょう。ですから、セキュリティファーストであり、デザイン時にオペレーションも考えなければならないと言ってると思います。

複雑性を内包したシンプル

• シンプルとは何かをそぎ落としたものではなく、複雑性を内包し、秩序立ったものと言っています。
• そのために人が理解できる単位にCellで分ける方法を提唱しています。ソフトウェアデザインパターンのカプセル化のことですね。人が理解できる単位にどうCell化するかというのが設計なのだ思いました。
• 1つで管理したくなる誘惑があるときもあると思います。そのときに複雑性を内包して分割できないか、考えるべきということです。ソフトウェアデザインパターンにあるように、こういった考え方はITにおいてスケールしやすいということも言えると思います。

私たちが作り出した技術はすべてが美しいわけではない。しかし、技術を使って実際に世界の最も難しい問題のいくつかを解決するのも私たちの責任だ。

• Keynoteの最後のメッセージが上記です。英語ですと、正確には以下です。

Technologis we created not enerything beatutiful.But it's alos our responsibility to acutually solve some of the world's hardest problems using tech technology.

• 私見ですが、複雑性を内包したシンプルな設計は、Dr. Wernerの美しい技術の自負だと感じました。しかしながら、ただ美しい設計を作るのではなく、その技術を使って問題解決をすることが私たちの責任だと言っています。
• 私もアーキテクトとして設計をするときに、美しい設計をしたいと考えています。美しいとは秩序立ったとも理解しています。Dr. Wernerの講演はそれがAWSのリソースとなった姿を披露していました。ヒントになりますね。
• Shizen Connectでは、ITを使って再生エネルギー100%の世界を作ることを目指しています。技術を使って問題解決をし、責務を果たしていきます。