20211109 JAWS-UG SRE keynotes

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon Web Services Japan
Manager, Solutions Architect
Yukitaka Ohmura
2021/11/09
Site Reliability Engineering on AWS
JAWS-UG SRE支部第1回

アジェンダ
1. Site Reliability Engineering (SRE) が実現すること
2. SRE を AWS 上で実現する際の考え方
3. JAWS-UG SRE 支部設立に寄せて
2

大村幸敬 (おおむらゆきたか)
Manager, Solutions Architect
• これからクラウドを使いはじめる
エンタープライズ企業をサポート
• Specialty: Cloud Operations & DevOps
• Baseline Environment on AWS (BLEA) メンテナ
https://github.com/aws-samples/baseline-environment-on-aws
好きなAWSのサービス：
AWS CLI, AWS CDK, SSM Incident Manager
3
本セッションの内容については AWS SA の Seigo Uchida (@spesnova) にもご協力いただいています
Twitter: @yktko

Site Reliability Engineering
が実現すること
4

Site Reliability Engineering (SRE) 再確認
• ”How Google Runs Production System”
• 以下の書籍から情報を得ています
• SRE サイトリライアビリティエンジニアリング
• サイトリライアビリティワークブック
• SREの探求
• Disclaimer
• 正確を期していますが不正確な部分があれば
フィードバックをお願いいたします
• この資料で記載する内容は特定企業の実態を表したものではありません
（Amazonに関するものは除く）
• SRE = Site Reliability Engineering
SREs = Site Reliability Engineers と表記します
5

Site Reliability Engineering (SRE)
ソフトウェアエンジニアリングと子供を持つこととの間には、次の共通点があ
ります。すなわち、誕生の前の労苦も苦痛で大変なものですが、じっさいには
誕生の後の労苦こそが、その努力の大部分を占めるものだということです。ソ
フトウェアエンジニアリングについては、誕生後に比べて誕生前についての議
論にはるかに多くの時間を費やすものの、システムのトータルコストの40-
90%は、そのシステムの誕生後に生じるものと推定されます。
…ソフトウェアのライフサイクル全体に焦点を当てる、もう一つの分野が見え
るはずです。この分野で使いこなさなければならないスキルは広範囲に及びま
すが、他の種類のエンジニアにはない固有の関心事項もあります。今日におけ
る私たちの答えは、Googleがサイトリライアビリティエンジニアリングと呼ぶ
分野です。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
https://www.amazon.co.jp/dp/4873117917
6

SREs の信条
• エンジニアリングへの継続的な注力の保証
• サービスのSLO*を下回ることなく、変更の速度の最大化を追求する
• モニタリング
• 緊急対応
• 変更管理
• 需要の予測とキャパシティプランニング
• プロビジョニング
• 効率とパフォーマンス
* SLO = Service Level Objective サービスレベル目標
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
https://www.amazon.co.jp/dp/4873117917
7

ところでこれは何でしょう？
“私たちは、自動化された運用およびビジネスプラクティスを所有する Systems
Development Engineer を募集しています。これには、問題の特定と解決、反復的なプロセ
スの自動化と改善、開発チームとの緊密な連携が含まれます。運用上の問題の優先順位付けを
推進し、サービスをサポートするための自動化設計とスケーリングの要件を推進します。主な
責任には、トラブルシューティング、運用上の問題の診断と修正、監視ソリューションの開発、
インフラストラクチャのメンテナンスと構成の実行、反復的な手動プロセスの自動化、インフ
ラストラクチャ要件に対応するツールの開発、更新、追跡、解決が含まれます。技術的な課題。
また、開発、現在のソフトウェアの更新/強化、サポートプロセスの自動化、およびシステム
の文書化に伴う作業も担当します。”
Basic Qualification (One of them):
• 3+ years of experience in Systems Administration, Network Administration, AWS
Cloud App development, DevOps or Site Reliability Engineering
8
https://www.amazon.jobs/jp/jobs/1511937/sr-system-development-engineer

Answer:
10
https://www.amazon.jobs/jp/jobs/1511937/sr-system-development-engineer
AWS のサービスチームが募集する
“Systems Development Engineer (SysDE)”

SREs at Amazon
• Systems Development Engineerという職種が
サービスチームの中にある
• 開発プロセスや運用上の課題をソフトウェアを使って解決する
• 求められているのは「SREの信条」そのもの
• 横串でプラットフォームだけを担当するのではない
• Amazonのサービスチーム (=Two pizza team) の編成
• Software Development Manager *1
• Software Development Engineer *n (多数)
• Systems Development Engineer *m (若干名)
• etc.
11

Site Reliability Engineer を募集しているチームもあるが
Responsibilities (責任範囲)
• 反復的な手動プロセスを自動化し、インフラストラクチャ要件に対応するツールを開発する
• 監視ソリューションの開発、インフラストラクチャの保守と構成の実行
• サービスをサポートするための自動化設計とスケーリングの要件を推進します。
• 問題の特定と解決、反復プロセスの自動化と改善、開発チームとの緊密な連携
• 開発、現在のソフトウェアの更新/強化、サポートプロセスの自動化、およびシステムの文書化に協力する。
• 機能要件と技術要件を詳細なアーキテクチャ、設計、拡張可能なコードに変換する
• 複雑なシステムモジュールのコーディングとテスト、フレームワークの開発と活用で効果的かつ効率的になる
• アーキテクチャ、設計、コードレビューに参加し、高い開発基準を維持する
• 他のエンジニアを指導し、挑戦的な技術文化を定義し、急成長するチームの構築を支援する
12
https://www.amazon.jobs/jp/jobs/1760394/site-reliability-devops-engineer-aws-glue
実態はサービスチームに所属しており活動内容は Systems Development Engineer と同じ

Amazonのメカニズム
13

plan
code
Test&build
release
monitor
developers team operators team
Project life cycle(開発)
Maintainance(保守)
一般的な開発の流れ
14

伝統的なシステムでは開発と運用の間に壁がある。
そんな壁はぶん投げてしまえ。
忘れてしまってもいい。Amazonでは不要だ。
you build it, you run it
開発者も日々の運用に参加しなさい。
そうすればカスタマーのフィードバックが得られる。
これが、サービスの質を高めるのだ。
-- Werner Vogels in May 2006 / Amazon.com CTO
15

DevOps によって Project でなく Product にフォーカス
Product life cycle 全体を Service Teamが見る
service team
=Two-pizza team
16

Two-pizza team
• チームはビジネスKPIの責任を負う代わりに
サービスに関するすべての権限を持つ
• 開発チームがそのまま運用も行うことで
高品質・運用しやすいサービスを
開発するモチベーションになる
• ソフトウェア開発チームの人数を増やすと
開発速度は指数関数的に低下する
（ブルックスの法則）ため、チームは
Two-pizzaでランチを賄える程度のサイズに
維持する
17

Amazonにおけるサービス運用
• すべてをサービスチームが担当する
• 顧客ヒアリング/プロダクトデザイン/サービスKPIの達成
• 要求/設計/開発/テスト/インフラ構築/運用/運用改善/オンコール/採用
• チームのスピードを維持するためのTwo Pizzaサイズ
• Software Development Manager *1
• Software Development Engineer *n
• Two Pizza Teamで運用するために Self-service tools が必要
• チームメンバはソフトウェアで運用の課題に対処する
• 有用なツールはサービス化され社内に提供される ⇨ AWSもそのひとつ
• すべては、素早い改善の繰り返しでCustomerに価値を届け続けるため
18

Amazon S3を開発・運用する方法 - 巨大なマイクロサービスと組織
19
https://resources.awscloud.com/vidyard-all-players/aws-33-aws-summit-online-2020-720p-2
Amazonのサービス開発・運用の詳細については、
Vancouver で Systems Development Engineerとして活躍されている岩永さんの発表をご覧ください

では
Site Reliability Engineering とは？
20

Site Reliability Engineering は
• SREの考え方は、
システムの信頼性や運用効率をエンジニアリングで改善しよう
とする一連の活動を解説したもの
• 運用を実現するためのよい考え方だが
それだけが唯一の正解ではない
• 適したやりかたは組織によって違う
• 例）Amazon は You build it, you run it に基づき
サービスチームが自分たちのKPIのために
運用をソフトウェアで改善するモチベーションを持つ
そのためToilの仕組みや組織横断で活動するSREsはいない
21

体制による運用エンジニアリングの違い
22
サービスチームが全てのOwnershipを持つスタイル
(Amazonのような)
サービスチームとSREsで分業して運用するスタイル
（考えられる体制の一例）
Business KPI Business KPI
KPI: Error Budget
Service KPI
Dev
SREs/
SysDE
Business KPI Business KPI
KPI: Error Budget
SREs
Self Service Tool
APIによる運用機能の提供
オンコール対応や運用改善など業務の提供
Service Team Service Team
Service Team Service Team
組織の体制や、重視することによってやり方は無数に存在する

温故知新: 他のフレームワークも参考にする
24
ITIL
ITサービス運用の実体
Site Rliability
Engineering
COBIT
Well-Architected DevOps
ITガバナンス
ITマネジメント
ITセキュリティ
NIST CSF
NIST SP800-53
ISO27001
各種フレームワークは、複雑なITサービスの運用を写像して、理解しやすいよう体系化している（重複もある）

温故知新: ITIL (IT Infrastructure Library)
• ITライフサイクル全体の管理領域の定義が参考になる
• 従来の考え方とのすり合わせに使える
• クラウド前提の継続的開発・運用とは合わなくなってきた部分もある
25
参考: SmartStage
https://smart-stage.jp/topics/itsm_keyword_relate/p2/

閑話: Site Reliability Engineers ?
• SREs = Site Reliability Enginnering を行う人
• ≠Site Reliability Engineerの仕事をする人
• 信頼性（など）をエンジニアリングで改善することが仕事であって、
やるべき作業が先にあるのではない
• ≒ “Don’t just do agile, Be agile”
26

Site Reliability Engineering を
AWS 上で実現する際の考え方
27

Site Reliability Engineering on AWS
• AWS上の信頼性と運用のベストプラクティス
• AWS Well-Architected Framework
• アーキテクチャによる高信頼性確保のナレッジ
• Amazon Builder’s Library
• Amazon の開発スタイル（参考として）
• マイクロサービスアーキテクチャ
• Two-Pizza Team (Ownership & DevOps)
• Self service tools
• Guardrails
28

AWS Well-Architected Framework
システム設計・運用の”大局的な”考え方とベストプラクティス集
29
https://wa.aws.amazon.com/index.ja.html
セキュリティ信頼性
パフォーマンス
効率
コスト最適化
運用上の優秀性
(Operational Excellence)

Operational Excellence の原則
30
運用をコードとして実行する
⼩規模かつ可逆的な変更を頻繁に行う
運用手順を定期的に改善する
障害を予想する
運用上のすべての障害から学ぶ
https://wa.aws.amazon.com/wat.pillar.operationalExcellence.ja.html

Operational Excellence の質問
31
https://wa.aws.amazon.com/wat.pillar.operationalExcellence.ja.html
組織
• OPS 1: 優先順位はどのように決定すればよいでしょうか?
• OPS 2: ビジネスの成果をサポートするために、組織をどのように構築しますか?
• OPS 3: 組織の文化はビジネスの成果をどのようにサポートしますか?
準備
• OPS 4: どのようにワークロードを設計して、その状態を理解できるようにするのですか?
• OPS 5: どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?
• OPS 6: どのようにデプロイのリスクを軽減しますか?
• OPS 7: ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか?
運用
• OPS 8: ワークロードの正常性をどのように把握しますか?
• OPS 9: オペレーションの正常性をどのように把握しますか?
• OP 10: ワークロードと運用イベントはどのように管理しますか?
進化
• OPS 11: オペレーションを進化させる方法

Operational Excellence ベストプラクティスと実装例
32
https://wa.aws.amazon.com/wat.question.OPS_7.ja.html

Builder’s Library
可用性
• Cell Architecture
• Shuffle Sharding
• 静的安定性
デプロイメント
• Secure Hands-off Deployment
Postmortem
• Correction of Errors
(COE)
33
https://aws.amazon.com/jp/builders-library/
Amazonのソフトウェアの構築・運用方法を解説したライブラリ

Builders Library の例: 静的安定性
34
https://aws.amazon.com/jp/blogs/news/jpmne-mediaawsstudymeeting2021-7/

もっと具体的に（SRE本より）
• 6章 Observability - CloudWatch
• 7章 Automation - EventBridge/SSM/Lambda
• 8章 Release Engineering
- Code Series
• 11章 OnCall/Incident Management
- SSM Incident Manager
ここから先は皆さんのアイディアを伺わせてください！
35

JAWS-UG SRE 支部設立に寄せて
40

言霊は大事…だが
• 運用の課題をエンジニアリングで解決することに
“SRE”という名前がついた
• SRE本によって、これまで必要でありながら、
複雑で注目されていなかった領域にフォーカスが当たった
• “SREs” という目標ができて、エンジニアが
モチベーションを持って活動できるようになった
• 2009年ごろから「インフラエンジニア」という言葉が
現れてきて2011年ウェブオペレーション本が出た時と似てる
41

…でも言葉に縛られない
• 目的はサービスを利用するお客様へ価値を提供すること
• Toilにかける時間をルール通り守ることでも
「Site Reliability Engineeringをする」ことでも
「Site Reliability Engineerになる」ことでもない
• 組織の数だけ運用がある
あなたの組織に合った Site Reliability Engineering を
• そして JAWS-UG で Discussion しよう！
42

Happy Site Reliability Engineering !
ご質問はお気軽にTwitterへどうぞ → @yktko

20211109 JAWS-UG SRE keynotes

More Related Content

What's hot (20)

Similar to 20211109 JAWS-UG SRE keynotes (20)

More from Amazon Web Services Japan (20)

20211109 JAWS-UG SRE keynotes