Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
WernerVogelsのKeynoteで語られた6つの教訓とOps
Search
da-hatakeyama
December 11, 2024
Technology
2
490
WernerVogelsのKeynoteで語られた6つの教訓とOps
「OpsJAWS Meetup32 re:Invent 2024 Ops系アップデート振り返り」での登壇資料です
https://opsjaws.connpass.com/event/336277/
da-hatakeyama
December 11, 2024
Tweet
Share
More Decks by da-hatakeyama
See All by da-hatakeyama
VPC Block Public Accessを触ってみて気づいた色々な勘所
hatahata021
2
230
VPC Block Public AccessとCloudFrontVPCオリジンによって何が変わるのか?
hatahata021
2
630
サーバレスを本気で理解したいあなたに贈る 「実践力を鍛えるBootcamp」の紹介
hatahata021
2
280
CloudFrontを使ってSPAなWebサイトを公開するときに気をつけること
hatahata021
1
2.4k
「AWSの薄い本」の紹介
hatahata021
1
150
ALBの新機能 Automatic Target Weightsとgray failuresについて考えてみる
hatahata021
0
900
re:Invent Workshop「Advanced Multi-AZ Resilience Patterns」をやってみた
hatahata021
1
260
Transfer Family for SFTPを使ってみよう
hatahata021
2
3.2k
VPCについてあらためて考えてみる
hatahata021
1
260
Other Decks in Technology
See All in Technology
「実体」で築く共通認識: 開発現場のコミュニケーション最適化 / Let's Get on the Same Page with Concrete Artifacts: Optimization of Communication in dev teams
kazizi55
0
140
Workflows から Agents へ ~ 生成 AI アプリの成長過程とアプローチ~
belongadmin
3
160
開発効率と信頼性を両立する Ubieのプラットフォームエンジニアリング
teru0x1
0
140
キャディでのApache Iceberg, Trino採用事例 -Apache Iceberg and Trino Usecase in CADDi--
caddi_eng
0
140
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
230
Kotlinで学ぶ 代数的データ型
ysknsid25
5
1.1k
原則から考える保守しやすいComposable関数設計
moriatsushi
3
430
Devin(Deep) Wiki/Searchの活用で変わる開発の世界観/devin-wiki-search-impact
tomoki10
0
330
VCpp Link and Library - C++ breaktime 2025 Summer
harukasao
0
180
Perk アプリの技術選定とリリースから1年弱経ってのふりかえり
stomk
0
100
API の仕様から紐解く「MCP 入門」 ~MCP の「コンテキスト」って何だ?~
cdataj
0
160
「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの 考え方・育て方 / Cursor Rules for Coding Styles, Domain Knowledges and Operations
yuitosato
6
1.8k
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Building an army of robots
kneath
306
45k
The World Runs on Bad Software
bkeepers
PRO
68
11k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
480
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
4 Signs Your Business is Dying
shpigford
184
22k
BBQ
matthewcrist
89
9.7k
GraphQLとの向き合い方2022年版
quramy
46
14k
Writing Fast Ruby
sferik
628
61k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Six Lessons from altMBA
skipperchong
28
3.8k
Transcript
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を称える一幕が ⚫皆さんも、どんどん各々の教訓をシェアしていきましょう!!