Slide 1
Slide 1 text
SRE on AWSのことはじめ
〜スタートアップ協業におけるビジネスに寄り添ったSLO定義・計測に関する取り組み事例〜
株式会社野村総合研究所
新井雅也
JAWS-UG SRE支部 #1 LT
Slide 2
Slide 2 text
新井 雅也
M a s a y a A R A I
msy78
2012年、野村総合研究所に入社。金融業界のお客様に向けたビジネス提案やシステム設計、
開発、運用を担当。UI/UXデザインやスマホApp、サーバサイドAppなどフルスタックな守備
範囲を持ちつつ、クラウドアーキテクチャの設計・開発が得意。
APN Ambassador, APN ALL AWS Certifications Engineer
Slide 3
Slide 3 text
本日の発表
・スタートアップとの協業において、SREチーム立ち上げにおける
SLO定義・計測に関する取り組みに関する事例を取り上げます。
・原典（O’Reilly –Site Reliability Engineering）に真正面から向き合いつつも、
どのような観点からビジネスに寄り添ったSLOを探っていったか、プロセスをご紹介します。
・AWSにおいて、利用者（お客様）視点のSLOを定義するにあたり、
知見につながる内容が少しでもあればあれば幸いです。
※SLOの定義に関するプロセスの一例であり、必ずしも正解ではない点は予めご了承ください。
Slide 4
Slide 4 text
クレジットカード
スマホアプリ
今回ご支援させていただいたお客様は金融系のスタートアップ企業。
クレジットカード✕スマホアプリを主軸にしたFintechサービスであり、ビジネスのスキーム作りから一緒に参画。
金融系
スタートアップ
金融系スタートアップと協業して新規ビジネス推進中
※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。
App-controlled なクレジットカードサービス
Slide 5
Slide 5 text
ユーザー クレジットカード
スマホアプリ
お店
(加盟店)
外部接続システム群
(ペイメント機能等)
金融系
スタートアップ
サービス
プラットフォーム
コンビニ
今回取り上げる事例のサービスユースケースの紹介
※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。
スマホアプリのバックエンド機能はAWSにてシステムを構築。
スマホアプリの
バックエンド機能や
管理者機能を提供
AWS
Slide 6
Slide 6 text
ユーザー クレジットカード
スマホアプリ
お店
(加盟店)
外部接続システム群
(ペイメント機能等)
数ステップで
申し込み完了
会員情報
登録
与信審査
反社チェック等
カード配送
スマホアプリから住所入力や本人確認書類をアップロードなど数ステップすることで申し込みが完了。
審査が通過すれば、数日でクレジットカードが受け取れる。
金融系
スタートアップ
会員申込登録
会員申込
④カード発行
サービス
プラットフォーム
コンビニ
住所等 本人確認書類
※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。
AWS
ユースケースの業務：会員申込
Slide 7
Slide 7 text
ユーザー クレジットカード
スマホアプリ
お店
(加盟店)
外部接続システム群
(ペイメント機能等)
決済情報
取得
ポーリングで
情報取得
カード利用
金融系
スタートアップ
決済通知
決済
情報
決済
決済通知
プッシュ
通知
サービス
プラットフォーム
コンビニ
※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。
クレジットカードを利用してお店（加盟店）で商品を購入すると、外部システム側に決済情報が蓄積。
AWSで構成されたプラットフォームがその情報を取得し、利用者に決済の旨を通知。
AWS
ユースケースの業務：決済
決済処理自体は
サービスプラットフォームを経由しない
Slide 8
Slide 8 text
ユーザー クレジットカード
コンビニ
スマホアプリ
お店
(加盟店)
外部接続システム群
(ペイメント機能等)
返済情報
登録
金融系
スタートアップ
返済通知
返済
返済通知
プッシュ
通知
返済情報
連携
サービス
プラットフォーム
※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。
コンビニのATMで好きなタイミングに返済が可能。
QRコードを読み取り、金額をATMに投入すると、AWSサービスプラットフォームに蓄積され、スマホアプリに通知。
AWS
ユースケースの業務：返済
Slide 9
Slide 9 text
ユーザー
スマホアプリ
外部接続システム群
(ペイメント機能等)
金融系
スタートアップ
明細取得
決済明細の
確認
コンビニ
キャッシュフロー
情報連携
サービス
プラットフォーム
※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。
決済が確定後、利用明細情報（キャシュフロー情報）が外部システムからAWSサービスプラットフォームに連携。
ユーザーはスマホアプリから各種明細を確認できる。
AWS
ユースケースの業務：明細管理
Slide 10
Slide 10 text
スマホアプリ
サービス
プラットフォーム
AWS
会員申込 決済 返済 明細管理 その他
サービス(機能)を成立させる前提としてのセキュリティ・信頼性・運用
Slide 11
Slide 11 text
スマホアプリ
サービス
プラットフォーム
AWS
会員申込 決済 返済 明細管理 その他
セキュリティ (PCIDSS準拠)
信頼性
運用
サービス(機能)を成立させる前提としてのセキュリティ・信頼性・運用
Slide 12
Slide 12 text
信頼性をプロダクトの基本的な「機能」として位置づけ
・適切な信頼性の維持はビジネスを成功させる上での大前提
・信頼性が最重要の機能の１つである、という点はスタートアップ・エンプラ関係ない
・運用含め、全てソフトウェア・エンジニアリングのプラクティスが応用できる
・サービスプラットフォームは全てクラウド x SaaSベース
・運用と信頼性の維持をソフトウェア・エンジニアリングで実現するために、SREの考え方がマッチしそう
・原典を参考にしつつも、組織としてのあるべき姿に「SREの考え方を」アジャストしていくことを基本姿勢に。
Slide 13
Slide 13 text
「そもそも、どうやって組織にSREを導入する？」
？
Slide 14
Slide 14 text
引用: Google Cloud Day: Digital’21 | SREの基本と組織への導入〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜
https://services.google.com/fh/files/events/d3-infra-01.pdf
Slide 15
Slide 15 text
引用: Google Cloud Day: Digital’21 | SREの基本と組織への導入〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜
https://services.google.com/fh/files/events/d3-infra-01.pdf
まずはここから
今日のテーマ
Slide 16
Slide 16 text
SREやSLOの前に、そもそも信頼性とは・・・
Slide 17
Slide 17 text
ある条件・期間で障害を発生させずに、
システムが求められる機能を果たすことができる能力・確率
SREやSLOの前に、そもそも信頼性とは・・・
Slide 18
Slide 18 text
信頼性を適切に保つためには・・・
Slide 19
Slide 19 text
言うまでもないことですが、サービスを適切に管理す
るには、サービスの中で特に重要な振る舞いがどうい
うことかということと、そういった振る舞いの計測と
評価の方法を理解しなければなりません。
引用: O’Reilly | SRE サイトリライアビリティエンジニアリング - 4章 サービスレベル目標
Slide 20
Slide 20 text
言うまでもないことですが、サービスを適切に管理す
るには、サービスの中で特に重要な振る舞いがどうい
うことかということと、そういった振る舞いの計測と
評価の方法を理解しなければなりません。
引用: O’Reilly | SRE サイトリライアビリティエンジニアリング - 4章 サービスレベル目標
Slide 21
Slide 21 text
信頼性を適切に保つためには・・・
振る舞いの
計測と評価の方法
重要な振る舞いの
定義
＋
(SLIとSLOの定義)
Slide 22
Slide 22 text
信頼性を適切に保つためには・・・
振る舞いの
計測と評価の方法
重要な振る舞いの
定義
＋
まずこちらから
(SLIとSLOの定義)
Slide 23
Slide 23 text
重要な振る舞いを「利用者体験を脅かす兆候」として捉える
・まずは、兆候を把握するために必要なサービスの指標（SLI）を探るところから。
スマホアプリ
外部接続システム
(返済機能)
サービス
プラットフォーム
AWS
ユーザー
会員申込
返済
Slide 24
Slide 24 text
重要な振る舞いを「利用者体験を脅かす兆候」として捉える
スマホアプリ
外部接続システム
(返済機能)
サービス
プラットフォーム
AWS
入会処理がエラーになった、
クレカがアクティベートできない、etc
ATMで処理が止まる、
処理がなかなか進まない
・まずは、兆候を把握するために必要なサービスの指標（SLI）を探るところから。
ユーザー
会員申込
返済
Slide 25
Slide 25 text
重要な振る舞いを「利用者体験を脅かす兆候」として捉える
スマホアプリ
外部接続システム
(返済機能)
サービス
プラットフォーム
AWS
・まずは、兆候を把握するために必要なサービスの指標（SLI）を探るところから。
ユーザー
会員申込
返済
可用性(稼働率)
= 1- (5XXエラー数 / HTTPリクエスト総数)
レイテンシ遵守率
= レイテンシ遵守リクエスト数
/ HTTPリクエスト総数
※瞬時的なレイテンシの急増を見逃さないように
レイテンシのパーセンタイルも確認する
SLIとして採用
入会処理がエラーになった、
クレカがアクティベートできない、etc
ATMで処理が止まる、
処理がなかなか進まない
Slide 26
Slide 26 text
サービス
プラットフォーム
AWS
・SLIが決まったので、利用者への体験を維持すべき目標値（SLO）を探索する。
可用性(稼働率)
= 1- (5XXエラー数 / HTTPリクエスト総数)
レイテンシ遵守率
= レイテンシ遵守リクエスト数
/ HTTPリクエスト総数
※瞬時的なレイテンシの急増を見逃さないように
レイテンシのパーセンタイルも確認する
「利用者がサービスに期待している体験が損なわれている状態」を定義する
適切な
SLO
適切な
SLO
Slide 27
Slide 27 text
サービス
プラットフォーム
AWS
・SLIが決まったので、利用者への体験を維持すべき目標値（SLO）を探索する。
可用性(稼働率)
= 1- (5XXエラー数 / HTTPリクエスト総数)
レイテンシ遵守率
= レイテンシ遵守リクエスト数
/ HTTPリクエスト総数
※瞬時的なレイテンシの急増を見逃さないように
レイテンシのパーセンタイルも確認する
「利用者がサービスに期待している体験が損なわれている状態」を定義する
適切な
SLO
システム上のどの部分に？
どんな値を？どのような根拠で？
適切な
SLO
Slide 28
Slide 28 text
今回の事例では、次の2つのアプローチからSLOを探索してみることに。
AWSや関連システムに関するサービスレベルの前提を考察する
プロダクトに対する利用者の期待を考察する（機能の重要度を俯瞰する）
Slide 29
Slide 29 text
今回の事例では、次の2つのアプローチからSLOを探索してみることに。
AWSや関連システムに関するサービスレベルの前提を考察する
プロダクトに対する利用者の期待を考察する（機能の重要度を俯瞰する）
Slide 30
Slide 30 text
AWSの各サービスや外部接続システム毎にSLAが定められている
AWS will use commercially reasonable efforts to make each Included Service available for each
AWS region with a Monthly Uptime Percentage of at least 99.99%, in each case during any
monthly billing cycle (the “Region-Level SLA”).
全てのサービスではないが、AWSでは商業的にサービスレベルの目標を定めている
引用：https://aws.amazon.com/compute/sla/
参考：https://aws.amazon.com/legal/service-level-agreements/
Slide 31
Slide 31 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
AWSの各サービスや外部接続システム毎にSLAが定められている
Slide 32
Slide 32 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
99.95%
99.99%
99.99%
API GatewayのSLA：
ELBのSLA：
FargateのSLA：
AuroraのSLA：99.99%
SLA：99.XX%
SLA：99.XX%
SLA：99.XX%
LambdaのSLA：99.95%
ブランド
システム
加盟店
クレジット
カード
AWSの各サービスや外部接続システム毎にSLAが定められている
Slide 33
Slide 33 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
99.85%
99.55%
99.60%
対象外
SLAから各業務パターンの信頼性を計算して確認
シンプルに扱うため、主要な機能（決済、返済、会員申込、明細管理・その他）にターゲットを絞る。
Slide 34
Slide 34 text
AWSや他システムのSLAは、自分たちのSLO決定・見直しの案内役として捉える
・責任外のサービスレベルの概況をおさえた上で、信頼性の目標を判断することは、
システムとしての限界や、自分たちのシステムの立ち位置を把握することにおいても有益。
・SLOを定める以前において、サービス選定やアーキテクチャを組む・見直す際の参考指標にもなる。
※ミッションクリティカル系はxxxサービスだと冗長化前提で考える、な
Slide 35
Slide 35 text
今回の事例では、次の2つのアプローチからSLOを探索してみることに。
AWSや関連システムに関するサービスレベルの前提を考察する
プロダクトに対する利用者の期待を考察する（機能の重要度を俯瞰する）
Slide 36
Slide 36 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
守るべきビジネス領域の重要度を俯瞰する
シンプルに扱うため、主要な機能（決済、返済、会員申込、明細管理・その他）にターゲットを絞る。
Slide 37
Slide 37 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
守るべきビジネス領域の重要度を俯瞰する
Slide 38
Slide 38 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
最重要機能であり、使えないとク
レジットカードサービスとして成
立しない
プラットフォーム外の
ため対象外
守るべきビジネス領域の重要度を俯瞰する
他システム側の元帳更新が
発生するため、
ある程度のレイテンシは許容
Slide 39
Slide 39 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
アプリ利用直後に利用できないと
離脱につながる。
極度な低可用性は避けたい。
守るべきビジネス領域の重要度を俯瞰する
Slide 40
Slide 40 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
上記と比較すると、若干の許容は可能。
ただ、会員申込と同じ入り口を通る。
守るべきビジネス領域の重要度を俯瞰する
Slide 41
Slide 41 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
プラットフォーム内における可用性の重要度は 返済 ≧ 会員申込 ≧ 明細管理・その他
プラットフォーム外の
ため対象外
守るべきビジネス領域の重要度を俯瞰する
Slide 42
Slide 42 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
外部接続システム
(eKYC機能)
外部接続システム
(ペイメント関連)
外部接続システム
(カード印刷関連)
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
バッチ用S3
バケット
バッチ用
AWS Step
Functions
非同期処理
ブランド
システム
加盟店
クレジット
カード
決済 返済 会員申込 明細管理・その他
プラットフォーム内における可用性の重要度は 返済 ≧ 会員申込 ≧ 明細管理・その他
守るべきビジネス領域の重要度を俯瞰する
SLOとして定義
SLO対象外
SLOとして定義
返済以外は集約して
シンプルな定義からはじめる
Slide 43
Slide 43 text
サービス
プラットフォーム
AWS
・SLIが決まったので、利用者への体験を維持すべき目標値（SLO）を探索する。
可用性(稼働率)
= 1- (5XXエラー数 / HTTPリクエスト総数)
レイテンシ遵守率
= レイテンシ遵守リクエスト数
/ HTTPリクエスト総数
※瞬時的なレイテンシの急増を見逃さないように
レイテンシのパーセンタイルも確認する
「利用者がサービスに期待している体験が損なわれている状態」を定義する
システム上のどの部分に？
どんな値を？どのような根拠で？
適切な
SLO
適切な
SLO
Slide 44
Slide 44 text
サービス
プラットフォーム
AWS
・SLIが決まったので、利用者への体験を維持すべき目標値（SLO）を探索する。
可用性(稼働率)
= 1- (5XXエラー数 / HTTPリクエスト総数)
レイテンシ遵守率
= レイテンシ遵守リクエスト数
/ HTTPリクエスト総数
※瞬時的なレイテンシの急増を見逃さないように
レイテンシのパーセンタイルも確認する
「利用者がサービスに期待している体験が損なわれている状態」を定義する
スマホアプリ
外部接続システム
(返済機能)
可用性(稼働率)：99.9%以上
レイテンシ遵守率：90%以上
※3秒以内
可用性(稼働率)：99.99%以上
レイテンシ遵守率：90%以上
※20秒以内(他シス通信含む)
Slide 45
Slide 45 text
信頼性を適切に保つためには・・・
振る舞いの
計測と評価の方法
重要な振る舞いの
定義
＋
(SLIとSLOの定義)
次こちらから
Slide 46
Slide 46 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
ログ用
S3バケット
非同期処理
まずは利用者に近いシステムコンポーネントで計測を心がける
Slide 47
Slide 47 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
ログ用
S3バケット
非同期処理
クライアントに近い
コンポーネントのログでSLOを計測する。
バックエンドの情報が全てログに乗るので、
シンプルに網羅できる。
まずは利用者に近いシステムコンポーネントで計測を心がける
Slide 48
Slide 48 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
ログ用
S3バケット
非同期処理
Syntheticsは準備中。
現時点ではアクセスログから可用性を算出。
セキュリティ上の都合でSyntheticsが使えない。
アクセスログから可用性を算出。
まずは利用者に近いシステムコンポーネントで計測を心がける
Slide 49
Slide 49 text
スマホアプリ
外部接続システム
(返済機能)
サービスプラットフォーム
マイクロサービス別
各API
Amazon
API Gateway
NLB
API
API
ALB
決済系API
返済系API
申込系API
通知系API
外接連携API
Amazon Aurora
Amazon ECS
ログ用
S3バケット
非同期処理 PCIDSS要件に関するダッシュボードとして採用。
SIEM用途だけでなく、
SREに関するSLI可視化としても利用している。
まずは利用者に近いシステムコンポーネントで計測を心がける
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
各SLOには安全マージンを設定。
・99.995以上à GREEN
・99.995%以下 à YELLOW
・99.99%以下à RED
Slide 52
Slide 52 text
ファーストステップとしてSLOの計測は達成
Slide 53
Slide 53 text
・SLOを主軸としてSREの文化を醸成していくのが本番
・理解してもらうために、まずはシンプルに始める
・最初から完璧を目指さず、見直しありきで。
・ただ、SLOは「理にかなった強制機構」であるため、
少なくとも、ビジネスサイド含め関係者に説明できるようにしておく。
・徐々に輪を広げる。
・SREチーム → エンジニアリング各種チーム → ビジネスチーム
・チームや組織への理解を広げるのがSREの役割
・今後はトイルの削減、オンコール体制の整備などのSREの要素を組織に適応し、見直すことを繰り返す。
最後に・・・まだSREへの旅は始まったばかり・・・
Slide 54
Slide 54 text
Thank you for your attention.