Werner VogelsのKeynoteで語られた 6つの教訓とOps Ops JAWS #32

アジェンダ ⚫はじめに ⚫re:InventのKeynoteについて ⚫Werner先生のKeynoteで語られたこと ⚫最後に

アジェンダ ⚫はじめに ⚫re:InventのKeynoteについて ⚫Werner先生のKeynoteで語られたこと ⚫最後に

自己紹介 名前： 畠山 大治 業務： AWSパートナー企業でプリセールス 趣味： Perfumeを追いかける、読書、映画・アニメを見る 映画・アニメを見る、ギター（練習中） 好きなAWSサービス： VPC re:Invent参戦歴：re:Invent 2023は現地参戦、今年はお留守番 AWS Community Builders, 2024 Japan AWS Top Engineers OpsJAWSコアメンバー はたはた (@hatake_book)

アジェンダ ⚫はじめに ⚫re:InventのKeynoteについて ⚫Werner先生のKeynoteで語られたこと ⚫最後に

re:InventのKeynote 毎年5つのKeynote（基調講演）が行われる コンピュートやネットワークなどインフラ 関連のトピックやアップデートを取り上げ るKeynote Monday Night Live with Peter DeSantis AWS CEO Matt Garman Keynote その年のメイントピックや大きめのアップ デートを取り上げるKeynote

re:InventのKeynote 毎年5つのKeynote（基調講演）が行われる AI/ML関連のトピックやアップデートを取り上 げるKeynote （ここ最近はCEOのKeynoteにネタを取られがち） Dr. Swami Sivasubramanian Keynote AWS Partner Keynote with Dr. Ruba Borno パートナー戦略に関するトピックやアップ デートを取り上げるKeynote

re:InventのKeynote 毎年5つのKeynote（基調講演）が行われる 開発者向けのアップデート＆Werner先生のありがたい話が聞けるKeynote Dr. Werner Vogels Keynote

⚫ソフトウェア工学に関連する法則や言葉を取り上げつつ、AWSやAmazon.comで大事 にしていることについて話すのが毎年の傾向 ⚫今年のKeynoteの前半で語られた「6つの教訓」にOpsを絡めて自分なりに咀嚼してみ ました ⚫自分なりの解釈なので異論Welcome、優しく教えてください ⚫後半のAurora DSQLのDive Deepも面白かったので、興味がある方はぜひ見てください https://www.youtube.com/watch?v=aim5x73crbM Dr. Werner Vogels Keynote

アジェンダ ⚫はじめに ⚫re:InventのKeynoteについて ⚫Werner先生のKeynoteで語られたこと ⚫最後に

Simplexity ⚫「Simplicity（単純さ）」と「Complexity（複雑さ）」の間に起こりうる相補的な関 係を提案する言葉（参考：Wikipedia）

Simplexity ⚫「Simplicity（単純さ）」と「Complexity（複雑さ）」の間に起こりうる相補的な関 係を提案する言葉（参考：Wikipedia）

Simplexityとは要するに… ⚫サービスを拡大させるために追加機能をどんどんリリースすると、サービスの裏側は どんどん複雑になっていく ⚫これはサービスを拡大するためには不可避なことだが、複雑になりつつシンプルさを 保ち続けなければならない ⚫複雑さとシンプルさのバランスのことを「 Simplexity 」と表現

Lehman's laws of software evolution ⚫ソフトウェアが時間とともにどのように進化していくかを説明するためのフレーム ワークで、8つの法則が制定されている ⚫「メインフレームで考えられているが、その中でも以下の4つはクラウドや分散システ ムでも当てはまる」と紹介された ⚫Continuing Change（継続的な変化） ⚫Continuing Growth（継続的成長） ⚫Increasing Complexity（複雑さの増大） ⚫Declining Quality（質の低下） ⚫これらに対応してきた過程で、Amazon.comは6つの教訓を得てきた

Amazonが得た6つの教訓 ⚫Make evolvability a requirement：進化可能性を必須要件にする ⚫Break complexity into pieces：複雑さを分解する ⚫Align organization to architecture：組織をアーキテクチャに合わせる ⚫Organize into cells：セル単位で組織化する ⚫Design predictable systems：予測可能なシステムを設計する ⚫Automate complexity：複雑さを自動化する

教訓その1：Make evolvability a requirement ⚫「進化可能性を必須要件にする」 ⚫アーキテクチャを再検討する可能性を常に意識しておくべき ⚫複雑性を管理するために必要になる前提条件 ⚫AWSではソフトウェア的な改善だけでなく、根本から解決するためにハードウェア開 発の観点での改修も行っている

教訓その1とOpsのつながり 「進化可能性と保守性は明確に異なる」という言及があった 長期的な視点に立った戦略を立てて、シス テムの方向性を定める ⚫長期的で大域的な変化 ⚫根本的、機能的、構造的な強化 進化可能性 保守性 進化可能性をベースに置きつつ、短期的な 視点でサービスを改善していく ⚫短期的で局所的な変化 ⚫修正的、適応的、予防的な強化 進化可能性があってこその保守性

教訓その2：Break complexity into pieces ⚫「複雑さを分解する」 ⚫システムが複雑になっても管理できるためには、複雑さを細分化する必要がある ⚫細分化することで小さな警告サインに気づくことができる ⚫「小さな警告サインを無視してはいけない」

教訓その2：Break complexity into pieces ⚫「分解する粒度はどれくらいがいいのか？」に対する明確な答えはない ⚫ただし、新しい機能を追加するときに既存のものを拡張するのか、新しく作るのかと いう観点で考えてみると良い ⚫「拡張」は手軽に素早くできるが、拡張しすぎると複雑になりすぎる ⚫「追加」は複雑性を抑えることができるが、サービス全体が大きくなってしまう ⚫サービス全体が大きくなることは、エンジニアのメンタルモデルに対して高い負荷となる サービスの成長に伴う複雑性にどう対処するのか？ 次の教訓「Align organization to architecture」につながる

教訓その3：Align organization to architecture ⚫「組織をアーキテクチャに合わせる」 ⚫複雑性に対応するための組織の対応方針で重要なこと2つ ⚫順調にシステムが稼働している時こそ、少し怖がるべき ⚫ そのために質問することを組織内で推奨する ⚫ 「いつもそうしてきたから、今回もこうする」は危険なサイン ⚫ そういう時こそ危機感を持ち、もっと疑問を持って質問した方がいいかもしれない ⚫組織にオーナーシップを持たせ、エンジニアにサービスを気に入ってもらう ⚫ 「Two Pizza チーム」にオーナーシップを持たせる

教訓その2, 3とOpsのつながり ⚫DevOpsの考え方に通じるものを感じた ⚫開発チームと保守チームが分断されていると… ⚫開発チームがどんどん「拡張」をしてしまい、保守チームの業務がどんどん複雑になる ⚫システムの稼働状況を開発チームが把握しておらず、危険なサインに気づけない ⚫保守チームでオーナーシップを持ってもらうことが難しい ⚫「You build it, you run it」の思想で組織をデザインすることが重要だと感じた ⚫仮に開発と保守でチームが別になっていても、緊密な連携は必須なはず

教訓その4：Organize into cells ⚫「セル単位で組織化する」 ⚫より小さい構成要素に分解し、影響 範囲を狭める ⚫Cell-Based Architectureを採用する ⚫複雑性が増すため、管理性を意識して 投資しておくことが重要 ⚫Q. セルはどれくらいの大きさにするべきなのか？ ⚫A. 最大のワークロードに耐えうる大きさ、最小限の処理ができる大きさ、この中間が 最適である

教訓その4とOpsのつながり ⚫Cell-Based Architectureでの管理性を向上させるためには、オブザーバビリティが重要になって くると感じた ⚫Cell-Based Architectureやマイクロサービスはコンポーネント数が多く、それぞれがピタゴラ スイッチのように連動している ⚫全体で何が起きているのか、どこで不具合が起きているのか、を正確に把握することは複雑な システムを極力シンプルに管理することに通じるのではないか

教訓その5：Design predictable systems ⚫「予測可能なシステムを設計する」 ⚫アーキテクチャにおける不確実性を取り除く ⚫ELBやRoute 53で、設定変更を行ってから反映されるまでの設計に活かされている ⚫設定変更をトリガーとし、イベント駆動で設定変更を反映すると負荷が予測不可能になる ⚫負荷を予測できるように、ELBやRoute 53側から定期的に設定ファイルを取得しに行く設計 「constant work」にしている

教訓その5とOpsのつながり ⚫「不確実性を取り除く」は、運用計画や運用設計にそのまま当てはめることができる 考え方だと感じた ⚫考慮したい不確実性、例えば… ⚫メンバーの急な異動や退職によって生じる属人化 ⚫サービスのサポート終了、仕様変更 ⚫不確実性を排除する or 対応できる体制にしておくことで、はじめて運用が継続的に回 り始めるのでは

教訓その6：Automate complexity ⚫「複雑さを自動化する」 ⚫大事なのは「何を自動化しないのか？」 ⚫高度な判断力を必要とするか否か、という判断軸で自動化を考える ⚫高度な判断力が必要ないものはすべて自動化する

教訓その6とOpsのつながり ⚫高度な判断力を必要としない運用作業「トイル（Toil）」の排除 ⚫トイル（Toil）とは： 「手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比 例して増加する、といった特徴を持つ作業」 （引用： https://sre.google/sre-book/eliminating-toil/ ） ⚫トイルを排除するために自動化することは、保守性の向上だけではなくシステム全体 が複雑になることを防ぐことにもつながるのでは？

アジェンダ ⚫はじめに ⚫re:InventのKeynoteについて ⚫Werner先生のKeynoteで語られたこと ⚫最後に

最後に ⚫6つの教訓の紹介の最後に「Share your lessons！」 ⚫AWS Heroを称える一幕が ⚫皆さんも、どんどん各々の教訓をシェアしていきましょう！！