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
400
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
140
VPC Block Public AccessとCloudFrontVPCオリジンによって何が変わるのか?
hatahata021
2
380
サーバレスを本気で理解したいあなたに贈る 「実践力を鍛えるBootcamp」の紹介
hatahata021
2
210
CloudFrontを使ってSPAなWebサイトを公開するときに気をつけること
hatahata021
1
1.8k
「AWSの薄い本」の紹介
hatahata021
1
110
ALBの新機能 Automatic Target Weightsとgray failuresについて考えてみる
hatahata021
0
800
re:Invent Workshop「Advanced Multi-AZ Resilience Patterns」をやってみた
hatahata021
1
230
Transfer Family for SFTPを使ってみよう
hatahata021
2
2.1k
VPCについてあらためて考えてみる
hatahata021
1
230
Other Decks in Technology
See All in Technology
プロダクトエンジニア 360°フィードバックを実施した話
hacomono
PRO
0
120
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
510
ソフトウェアエンジニアと仕事するときに知っておいたほうが良いこと / Key points for working with software engineers
pinkumohikan
1
130
Share my, our lessons from the road to re:Invent
naospon
0
110
深層学習と古典的画像アルゴリズムを組み合わせた類似画像検索内製化
shutotakahashi
1
260
2/18/25: Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
0
150
EDRの検知の仕組みと検知回避について
chayakonanaika
2
530
クラウドサービス事業者におけるOSS
tagomoris
3
950
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
1.2k
php-conference-nagoya-2025
fuwasegu
0
110
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
18
7.1k
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
100
Featured
See All Featured
Embracing the Ebb and Flow
colly
84
4.6k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Statistics for Hackers
jakevdp
797
220k
Being A Developer After 40
akosma
89
590k
GitHub's CSS Performance
jonrohan
1030
460k
Practical Orchestrator
shlominoach
186
10k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
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を称える一幕が ⚫皆さんも、どんどん各々の教訓をシェアしていきましょう!!