Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

C636093440dd4a8be6416e83cb980979?s=47 iselegant
November 09, 2021

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

C636093440dd4a8be6416e83cb980979?s=128

iselegant

November 09, 2021
Tweet

More Decks by iselegant

Other Decks in Technology

Transcript

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

  2. 新井 雅也 M a s a y a A R

    A I msy78 2012年、野村総合研究所に入社。金融業界のお客様に向けたビジネス提案やシステム設計、 開発、運用を担当。UI/UXデザインやスマホApp、サーバサイドAppなどフルスタックな守備 範囲を持ちつつ、クラウドアーキテクチャの設計・開発が得意。 APN Ambassador, APN ALL AWS Certifications Engineer
  3. 本日の発表 ・スタートアップとの協業において、SREチーム立ち上げにおける SLO定義・計測に関する取り組みに関する事例を取り上げます。 ・原典(O’Reilly –Site Reliability Engineering)に真正面から向き合いつつも、 どのような観点からビジネスに寄り添ったSLOを探っていったか、プロセスをご紹介します。 ・AWSにおいて、利用者(お客様)視点のSLOを定義するにあたり、 知見につながる内容が少しでもあればあれば幸いです。

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

  5. ユーザー クレジットカード スマホアプリ お店 (加盟店) 外部接続システム群 (ペイメント機能等) 金融系 スタートアップ サービス

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

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

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

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

    キャッシュフロー 情報連携 サービス プラットフォーム ※お客様からは許可を頂いた上、本発表のテーマとして利⽤させていただいています。 決済が確定後、利用明細情報(キャシュフロー情報)が外部システムからAWSサービスプラットフォームに連携。 ユーザーはスマホアプリから各種明細を確認できる。 AWS ユースケースの業務:明細管理
  10. スマホアプリ サービス プラットフォーム AWS 会員申込 決済 返済 明細管理 その他 サービス(機能)を成立させる前提としてのセキュリティ・信頼性・運用

  11. スマホアプリ サービス プラットフォーム AWS 会員申込 決済 返済 明細管理 その他 セキュリティ

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

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

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

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

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

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

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

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

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

    4章 サービスレベル目標
  21. 信頼性を適切に保つためには・・・ 振る舞いの 計測と評価の方法 重要な振る舞いの 定義 + (SLIとSLOの定義)

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

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

    返済
  24. 重要な振る舞いを「利用者体験を脅かす兆候」として捉える スマホアプリ 外部接続システム (返済機能) サービス プラットフォーム AWS 入会処理がエラーになった、 クレカがアクティベートできない、etc ATMで処理が止まる、

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

    返済 可用性(稼働率) = 1- (5XXエラー数 / HTTPリクエスト総数) レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないように レイテンシのパーセンタイルも確認する SLIとして採用 入会処理がエラーになった、 クレカがアクティベートできない、etc ATMで処理が止まる、 処理がなかなか進まない
  26. サービス プラットフォーム AWS ・SLIが決まったので、利用者への体験を維持すべき目標値(SLO)を探索する。 可用性(稼働率) = 1- (5XXエラー数 / HTTPリクエスト総数)

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

    レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないように レイテンシのパーセンタイルも確認する 「利用者がサービスに期待している体験が損なわれている状態」を定義する 適切な SLO システム上のどの部分に? どんな値を?どのような根拠で? 適切な SLO
  28. 今回の事例では、次の2つのアプローチからSLOを探索してみることに。 AWSや関連システムに関するサービスレベルの前提を考察する プロダクトに対する利用者の期待を考察する(機能の重要度を俯瞰する)

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

  30. 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/
  31. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム (カード印刷関連)

    マイクロサービス別 各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケット バッチ用 AWS Step Functions 非同期処理 ブランド システム 加盟店 クレジット カード AWSの各サービスや外部接続システム毎にSLAが定められている
  32. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 外部接続システム (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が定められている
  33. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 外部接続システム (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から各業務パターンの信頼性を計算して確認 シンプルに扱うため、主要な機能(決済、返済、会員申込、明細管理・その他)にターゲットを絞る。
  34. AWSや他システムのSLAは、自分たちのSLO決定・見直しの案内役として捉える ・責任外のサービスレベルの概況をおさえた上で、信頼性の目標を判断することは、 システムとしての限界や、自分たちのシステムの立ち位置を把握することにおいても有益。 ・SLOを定める以前において、サービス選定やアーキテクチャを組む・見直す際の参考指標にもなる。 ※ミッションクリティカル系はxxxサービスだと冗長化前提で考える、な

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

  36. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム (カード印刷関連)

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

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

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

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

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

    マイクロサービス別 各API Amazon API Gateway NLB API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS バッチ用S3 バケット バッチ用 AWS Step Functions 非同期処理 ブランド システム 加盟店 クレジット カード 決済 返済 会員申込 明細管理・その他 プラットフォーム内における可用性の重要度は 返済 ≧ 会員申込 ≧ 明細管理・その他 プラットフォーム外の ため対象外 守るべきビジネス領域の重要度を俯瞰する
  42. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 外部接続システム (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として定義 返済以外は集約して シンプルな定義からはじめる
  43. サービス プラットフォーム AWS ・SLIが決まったので、利用者への体験を維持すべき目標値(SLO)を探索する。 可用性(稼働率) = 1- (5XXエラー数 / HTTPリクエスト総数)

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

    レイテンシ遵守率 = レイテンシ遵守リクエスト数 / HTTPリクエスト総数 ※瞬時的なレイテンシの急増を見逃さないように レイテンシのパーセンタイルも確認する 「利用者がサービスに期待している体験が損なわれている状態」を定義する スマホアプリ 外部接続システム (返済機能) 可用性(稼働率):99.9%以上 レイテンシ遵守率:90%以上 ※3秒以内 可用性(稼働率):99.99%以上 レイテンシ遵守率:90%以上 ※20秒以内(他シス通信含む)
  45. 信頼性を適切に保つためには・・・ 振る舞いの 計測と評価の方法 重要な振る舞いの 定義 + (SLIとSLOの定義) 次こちらから

  46. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム マイクロサービス別 各API Amazon API Gateway NLB

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

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

    API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS ログ用 S3バケット 非同期処理 Syntheticsは準備中。 現時点ではアクセスログから可用性を算出。 セキュリティ上の都合でSyntheticsが使えない。 アクセスログから可用性を算出。 まずは利用者に近いシステムコンポーネントで計測を心がける
  49. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム マイクロサービス別 各API Amazon API Gateway NLB

    API API ALB 決済系API 返済系API 申込系API 通知系API 外接連携API Amazon Aurora Amazon ECS ログ用 S3バケット 非同期処理 PCIDSS要件に関するダッシュボードとして採用。 SIEM用途だけでなく、 SREに関するSLI可視化としても利用している。 まずは利用者に近いシステムコンポーネントで計測を心がける
  50. None
  51. 各SLOには安全マージンを設定。 ・99.995以上à GREEN ・99.995%以下 à YELLOW ・99.99%以下à RED

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

  53. ・SLOを主軸としてSREの文化を醸成していくのが本番 ・理解してもらうために、まずはシンプルに始める ・最初から完璧を目指さず、見直しありきで。 ・ただ、SLOは「理にかなった強制機構」であるため、 少なくとも、ビジネスサイド含め関係者に説明できるようにしておく。 ・徐々に輪を広げる。 ・SREチーム → エンジニアリング各種チーム →

    ビジネスチーム ・チームや組織への理解を広げるのがSREの役割 ・今後はトイルの削減、オンコール体制の整備などのSREの要素を組織に適応し、見直すことを繰り返す。 最後に・・・まだSREへの旅は始まったばかり・・・
  54. Thank you for your attention.