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
500
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
250
VPC Block Public AccessとCloudFrontVPCオリジンによって何が変わるのか?
hatahata021
2
670
サーバレスを本気で理解したいあなたに贈る 「実践力を鍛えるBootcamp」の紹介
hatahata021
3
300
CloudFrontを使ってSPAなWebサイトを公開するときに気をつけること
hatahata021
1
2.5k
「AWSの薄い本」の紹介
hatahata021
1
160
ALBの新機能 Automatic Target Weightsとgray failuresについて考えてみる
hatahata021
0
910
re:Invent Workshop「Advanced Multi-AZ Resilience Patterns」をやってみた
hatahata021
1
260
Transfer Family for SFTPを使ってみよう
hatahata021
2
3.3k
VPCについてあらためて考えてみる
hatahata021
1
260
Other Decks in Technology
See All in Technology
第4回Snowflake 金融ユーザー会 Snowflake summit recap
tamaoki
1
300
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
380
MobileActOsaka_250704.pdf
akaitadaaki
0
170
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
2
190
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
CDK Vibe Coding Fes
tomoki10
0
220
United airlines®️ USA Contact Numbers: Complete 2025 Support Guide
unitedflyhelp
0
330
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
2
210
OSSのSNSツール「Misskey」をさわってみよう(右下ワイプで私のOSCの20年を振り返ります) / 20250705-osc2025-do
akkiesoft
0
170
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
衛星運用をソフトウェアエンジニアに依頼したときにできあがるもの
sankichi92
1
160
FOSS4G 2025 KANSAI QGISで点群データをいろいろしてみた
kou_kita
0
410
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
4 Signs Your Business is Dying
shpigford
184
22k
How GitHub (no longer) Works
holman
314
140k
Navigating Team Friction
lara
187
15k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
310
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
YesSQL, Process and Tooling at Scale
rocio
173
14k
A designer walks into a library…
pauljervisheath
207
24k
Optimizing for Happiness
mojombo
379
70k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
How to Ace a Technical Interview
jacobian
278
23k
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を称える一幕が ⚫皆さんも、どんどん各々の教訓をシェアしていきましょう!!