SRE on AWSのことはじめ / SRE on AWS

SRE on AWSのことはじめ〜スタートアップ協業におけるビジネスに寄り添ったSLO定義・計測に関する取り組み事例〜株式会社野村総合研究所新井雅也 JAWS-UG SRE支部 #1 LT

新井雅也 M a s a y a A R
A I msy78 2012年、野村総合研究所に入社。金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当。UI/UXデザインやスマホApp、サーバサイドAppなどフルスタックな守備範囲を持ちつつ、クラウドアーキテクチャの設計・開発が得意。 APN Ambassador, APN ALL AWS Certifications Engineer

本日の発表・スタートアップとの協業において、SREチーム立ち上げにおける SLO定義・計測に関する取り組みに関する事例を取り上げます。・原典（O’Reilly –Site Reliability Engineering）に真正面から向き合いつつも、どのような観点からビジネスに寄り添ったSLOを探っていったか、プロセスをご紹介します。・AWSにおいて、利用者（お客様）視点のSLOを定義するにあたり、知見につながる内容が少しでもあればあれば幸いです。
※SLOの定義に関するプロセスの一例であり、必ずしも正解ではない点は予めご了承ください。

クレジットカードスマホアプリ今回ご支援させていただいたお客様は金融系のスタートアップ企業。クレジットカード✕スマホアプリを主軸にしたFintechサービスであり、ビジネスのスキーム作りから一緒に参画。金融系スタートアップ金融系スタートアップと協業して新規ビジネス推進中 ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。 App-controlled なクレジットカードサービス

ユーザークレジットカードスマホアプリお店 (加盟店) 外部接続システム群 (ペイメント機能等) 金融系スタートアップサービス
プラットフォームコンビニ今回取り上げる事例のサービスユースケースの紹介 ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。スマホアプリのバックエンド機能はAWSにてシステムを構築。スマホアプリのバックエンド機能や管理者機能を提供 AWS

ユーザークレジットカードスマホアプリお店 (加盟店) 外部接続システム群 (ペイメント機能等) 数ステップで申し込み完了会員情報
登録与信審査反社チェック等カード配送スマホアプリから住所入力や本人確認書類をアップロードなど数ステップすることで申し込みが完了。審査が通過すれば、数日でクレジットカードが受け取れる。金融系スタートアップ会員申込登録会員申込 ④カード発行サービスプラットフォームコンビニ住所等本人確認書類 ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。 AWS ユースケースの業務：会員申込

ユーザークレジットカードスマホアプリお店 (加盟店) 外部接続システム群 (ペイメント機能等) 決済情報取得ポーリングで
情報取得カード利用金融系スタートアップ決済通知決済情報決済決済通知プッシュ通知サービスプラットフォームコンビニ ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。クレジットカードを利用してお店（加盟店）で商品を購入すると、外部システム側に決済情報が蓄積。 AWSで構成されたプラットフォームがその情報を取得し、利用者に決済の旨を通知。 AWS ユースケースの業務：決済決済処理自体はサービスプラットフォームを経由しない

ユーザークレジットカードコンビニスマホアプリお店 (加盟店) 外部接続システム群 (ペイメント機能等) 返済情報登録
金融系スタートアップ返済通知返済返済通知プッシュ通知返済情報連携サービスプラットフォーム ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。コンビニのATMで好きなタイミングに返済が可能。 QRコードを読み取り、金額をATMに投入すると、AWSサービスプラットフォームに蓄積され、スマホアプリに通知。 AWS ユースケースの業務：返済

ユーザースマホアプリ外部接続システム群 (ペイメント機能等) 金融系スタートアップ明細取得決済明細の確認コンビニ
キャッシュフロー情報連携サービスプラットフォーム ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。決済が確定後、利用明細情報（キャシュフロー情報）が外部システムからAWSサービスプラットフォームに連携。ユーザーはスマホアプリから各種明細を確認できる。 AWS ユースケースの業務：明細管理

スマホアプリサービスプラットフォーム AWS 会員申込決済返済明細管理その他サービス(機能)を成立させる前提としてのセキュリティ・信頼性・運用

スマホアプリサービスプラットフォーム AWS 会員申込決済返済明細管理その他セキュリティ
(PCIDSS準拠) 信頼性運用サービス(機能)を成立させる前提としてのセキュリティ・信頼性・運用

信頼性をプロダクトの基本的な「機能」として位置づけ・適切な信頼性の維持はビジネスを成功させる上での大前提・信頼性が最重要の機能の１つである、という点はスタートアップ・エンプラ関係ない・運用含め、全てソフトウェア・エンジニアリングのプラクティスが応用できる・サービスプラットフォームは全てクラウド x SaaSベース・運用と信頼性の維持をソフトウェア・エンジニアリングで実現するために、SREの考え方がマッチしそう・原典を参考にしつつも、組織としてのあるべき姿に「SREの考え方を」アジャストしていくことを基本姿勢に。

「そもそも、どうやって組織にSREを導入する？」？

引用: Google Cloud Day: Digital’21 | SREの基本と組織への導入〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 https://services.google.com/fh/files/events/d3-infra-01.pdf

引用: Google Cloud Day: Digital’21 | SREの基本と組織への導入〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 https://services.google.com/fh/files/events/d3-infra-01.pdf まずはここから今日のテーマ

SREやSLOの前に、そもそも信頼性とは・・・

ある条件・期間で障害を発生させずに、システムが求められる機能を果たすことができる能力・確率 SREやSLOの前に、そもそも信頼性とは・・・

信頼性を適切に保つためには・・・

言うまでもないことですが、サービスを適切に管理するには、サービスの中で特に重要な振る舞いがどういうことかということと、そういった振る舞いの計測と評価の方法を理解しなければなりません。引用: O’Reilly | SRE サイトリライアビリティエンジニアリング -
4章サービスレベル目標

信頼性を適切に保つためには・・・振る舞いの計測と評価の方法重要な振る舞いの定義＋ (SLIとSLOの定義)

信頼性を適切に保つためには・・・振る舞いの計測と評価の方法重要な振る舞いの定義＋まずこちらから (SLIとSLOの定義)

重要な振る舞いを「利用者体験を脅かす兆候」として捉える・まずは、兆候を把握するために必要なサービスの指標（SLI）を探るところから。スマホアプリ外部接続システム (返済機能) サービスプラットフォーム AWS ユーザー会員申込
返済

重要な振る舞いを「利用者体験を脅かす兆候」として捉えるスマホアプリ外部接続システム (返済機能) サービスプラットフォーム AWS 入会処理がエラーになった、クレカがアクティベートできない、etc ATMで処理が止まる、
処理がなかなか進まない・まずは、兆候を把握するために必要なサービスの指標（SLI）を探るところから。ユーザー会員申込返済

重要な振る舞いを「利用者体験を脅かす兆候」として捉えるスマホアプリ外部接続システム (返済機能) サービスプラットフォーム AWS ・まずは、兆候を把握するために必要なサービスの指標（SLI）を探るところから。ユーザー会員申込
返済可用性(稼働率) = 1- (5XXエラー数 / HTTPリクエスト総数) レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないようにレイテンシのパーセンタイルも確認する SLIとして採用入会処理がエラーになった、クレカがアクティベートできない、etc ATMで処理が止まる、処理がなかなか進まない

サービスプラットフォーム AWS ・SLIが決まったので、利用者への体験を維持すべき目標値（SLO）を探索する。可用性(稼働率) = 1- (5XXエラー数 / HTTPリクエスト総数)
レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないようにレイテンシのパーセンタイルも確認する「利用者がサービスに期待している体験が損なわれている状態」を定義する適切な SLO 適切な SLO

レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないようにレイテンシのパーセンタイルも確認する「利用者がサービスに期待している体験が損なわれている状態」を定義する適切な SLO システム上のどの部分に？どんな値を？どのような根拠で？適切な SLO

今回の事例では、次の2つのアプローチからSLOを探索してみることに。 AWSや関連システムに関するサービスレベルの前提を考察するプロダクトに対する利用者の期待を考察する（機能の重要度を俯瞰する）

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/

スマホアプリ外部接続システム (返済機能) サービスプラットフォーム外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム (カード印刷関連)
マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード AWSの各サービスや外部接続システム毎にSLAが定められている

マイクロサービス別各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が定められている

マイクロサービス別各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から各業務パターンの信頼性を計算して確認シンプルに扱うため、主要な機能（決済、返済、会員申込、明細管理・その他）にターゲットを絞る。

AWSや他システムのSLAは、自分たちのSLO決定・見直しの案内役として捉える・責任外のサービスレベルの概況をおさえた上で、信頼性の目標を判断することは、システムとしての限界や、自分たちのシステムの立ち位置を把握することにおいても有益。・SLOを定める以前において、サービス選定やアーキテクチャを組む・見直す際の参考指標にもなる。 ※ミッションクリティカル系はxxxサービスだと冗長化前提で考える、な

今回の事例では、次の2つのアプローチからSLOを探索してみることに。 AWSや関連システムに関するサービスレベルの前提を考察するプロダクトに対する利用者の期待を考察する（機能の重要度を俯瞰する）

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード守るべきビジネス領域の重要度を俯瞰するシンプルに扱うため、主要な機能（決済、返済、会員申込、明細管理・その他）にターゲットを絞る。

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード決済返済会員申込明細管理・その他守るべきビジネス領域の重要度を俯瞰する

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード決済返済会員申込明細管理・その他最重要機能であり、使えないとクレジットカードサービスとして成立しないプラットフォーム外のため対象外守るべきビジネス領域の重要度を俯瞰する他システム側の元帳更新が発生するため、ある程度のレイテンシは許容

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード決済返済会員申込明細管理・その他アプリ利用直後に利用できないと離脱につながる。極度な低可用性は避けたい。守るべきビジネス領域の重要度を俯瞰する

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード決済返済会員申込明細管理・その他上記と比較すると、若干の許容は可能。ただ、会員申込と同じ入り口を通る。守るべきビジネス領域の重要度を俯瞰する

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード決済返済会員申込明細管理・その他プラットフォーム内における可用性の重要度は返済 ≧ 会員申込 ≧ 明細管理・その他プラットフォーム外のため対象外守るべきビジネス領域の重要度を俯瞰する

マイクロサービス別各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケットバッチ用 AWS Step Functions 非同期処理ブランドシステム加盟店クレジットカード決済返済会員申込明細管理・その他プラットフォーム内における可用性の重要度は返済 ≧ 会員申込 ≧ 明細管理・その他守るべきビジネス領域の重要度を俯瞰する SLOとして定義 SLO対象外 SLOとして定義返済以外は集約してシンプルな定義からはじめる

レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないようにレイテンシのパーセンタイルも確認する「利用者がサービスに期待している体験が損なわれている状態」を定義するシステム上のどの部分に？どんな値を？どのような根拠で？適切な SLO 適切な SLO

レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないようにレイテンシのパーセンタイルも確認する「利用者がサービスに期待している体験が損なわれている状態」を定義するスマホアプリ外部接続システム (返済機能) 可用性(稼働率)：99.9%以上レイテンシ遵守率：90%以上 ※3秒以内可用性(稼働率)：99.99%以上レイテンシ遵守率：90%以上 ※20秒以内(他シス通信含む)

信頼性を適切に保つためには・・・振る舞いの計測と評価の方法重要な振る舞いの定義＋ (SLIとSLOの定義) 次こちらから

スマホアプリ外部接続システム (返済機能) サービスプラットフォームマイクロサービス別各API Amazon API Gateway NLB
API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS ログ用 S3バケット非同期処理まずは利用者に近いシステムコンポーネントで計測を心がける

API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS ログ用 S3バケット非同期処理クライアントに近いコンポーネントのログでSLOを計測する。バックエンドの情報が全てログに乗るので、シンプルに網羅できる。まずは利用者に近いシステムコンポーネントで計測を心がける

API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS ログ用 S3バケット非同期処理 Syntheticsは準備中。現時点ではアクセスログから可用性を算出。セキュリティ上の都合でSyntheticsが使えない。アクセスログから可用性を算出。まずは利用者に近いシステムコンポーネントで計測を心がける

API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS ログ用 S3バケット非同期処理 PCIDSS要件に関するダッシュボードとして採用。 SIEM用途だけでなく、 SREに関するSLI可視化としても利用している。まずは利用者に近いシステムコンポーネントで計測を心がける

各SLOには安全マージンを設定。・99.995以上à GREEN ・99.995%以下 à YELLOW ・99.99%以下à RED

ファーストステップとしてSLOの計測は達成

・SLOを主軸としてSREの文化を醸成していくのが本番・理解してもらうために、まずはシンプルに始める・最初から完璧を目指さず、見直しありきで。・ただ、SLOは「理にかなった強制機構」であるため、少なくとも、ビジネスサイド含め関係者に説明できるようにしておく。・徐々に輪を広げる。・SREチーム → エンジニアリング各種チーム →
ビジネスチーム・チームや組織への理解を広げるのがSREの役割・今後はトイルの削減、オンコール体制の整備などのSREの要素を組織に適応し、見直すことを繰り返す。最後に・・・まだSREへの旅は始まったばかり・・・

Thank you for your attention.

SRE on AWSのことはじめ / SRE on AWS

SRE on AWSのことはじめ / SRE on AWS

More Decks by iselegant

Other Decks in Technology

Featured

Transcript