事業責任者も必見! AWS Well-Architected Frameworkのビジネスへの活用

AWS Summit Tokyo 2019の登壇資料

Transcript

1. 事業責任者も必⾒！ AWS Well-Architected Frameworkの ビジネスへの有効活⽤ Shota Tsuge Senior Organizational Reliability Engineer CyberAgent, Inc H - Shonosuke Okada Organizational Reliability Engineer CyberAgent, Inc #AWSSummit
2. 名前 柘植 翔太 @shotaTsuge • 所属 株式会社サイバーエージェント 技術本部サービスリライアビリティグループ • ロール Senior Organizational Reliability Engineer • やってること メディア管轄のPublic Cloud活⽤サービスの System Architecture周りのサポート • 好きなAWSサービス AWS Well-Architected Framework
3. 本セッションの内容 • 本セッションで話すこと • Well-Architected Frameworkを、システムの移設や改善にどのように活⽤しているのか • なぜ、独⾃のWell-Architected Framework（CA W-A）を作っているのか • Well-Architected Frameworkに、どのような可能性を感じているのか
 • 本セッションでの注意 • CA W-Aは、現時点では会社全体に導⼊できているわけではないです • 本セッションにおける発⾔は、所属するチームでの⾒解であり、
 会社全体の意向ではありません
4. .Introduction .AWS Well-Architected Framework .CA Well-Architected Framework .Summary
5. Introduction
6. 所属する会社について
7. 所属する会社について • 株式会社サイバーエージェント • CAと略称で呼ばれることが多い • 従業員数（連結）は、約5,000⼈ • 事業について • メディア事業 • スタートアップ（新規）事業 • ゲーム事業 • インターネット広告事業
8. 所属する組織について
9. 所属する組織について • 技術本部 • 社内でメディア管轄と呼ばれているサイバーエージェントグループのメディア事業や
 スタートアップ（新規）事業のサービスに対して、横断的なサポートなどをしている組織 • Open SaaS Studio（汎⽤SaaS）や秋葉原ラボ、Private Cloudなども、この組織に属す
10. 所属する組織について • メディア管轄のサービス（⼀部抜粋）
11. 所属する組織について • サービスリライアビリティグループ • メディア管轄のサービスのインフラ領域を横断的にサポートしているグループ • Service Reliability Groupの頭⽂字をとって、SRGと呼ばれている • 主に、既存サービスの改善や新規サービスの⽴ち上げなどをサポート • ⼗数⼈で、⼤⼩合わせて200弱のサービス、システムをサポート
12. 所属する組織について • メディア管轄とSRGの相関図
13. 所属する組織について • メディア管轄とSRGの相関図
14. ASTROBOXについて
15. ASTROBOXについて • 株式会社ASTROBOX • サイバーエージェント100%⼦会社 • コーポレートビジョン • ⼈⽣の “ヨリドコロ” になる • 株式会社CAMとの共同運営サービス • Ameba 占い館 SATORI • Ameba 占い館 SATORI 電話占い 代表取締役社⻑：五藤尚也
16. ASTROBOXについて サービスビジョン 電話占いが悩んでいる⼈にとって
 ⼀般的な世の中にする サービス概要 電話で相談できる占いサービス サービスビジョン ⼈⽣の息抜きが
 できる場所になる サービス概要 デジタルコンテンツの 占いサービス
17. AWS Well-Architected
 Framework
18. システム移設にあたり抱えていた課題
19. システム移設にあたり抱えていた課題 • 技術責任者からの相談 • 移設の期限が既に決まっている • 移設先は、AWSを考えているが初めてなので⼼配 • ネットワーク、セキュリティとかの設計が難しい • システム構成の悩み • AutoScaling機能を活⽤したい • e.g. 某有名占い師のTV出演による急激なアクセス増加時 • 潜在的なシステムリスクを可視化できていない • インフラチームへの依存 • 開発チームでのインフラ作業が⾏えていない • データベースなどは、マネージドサービスを使いたい • 社内外に、ナレッジが沢⼭あると嬉しい 技術責任者：酒井⼩枝
20. システム移設にあたり抱えていた課題 • 技術責任者への提案 • AWSについての学習 • 潜在的なリスクの可視化 • AWS Well-Architected Frameworkの導⼊を提案
21. AWS Well-Architected Frameworkとは
22. AWS Well-Architected Frameworkとは • AWS W-Aと表記されることが多い • 10年以上に渡り、AWSをユーザー向けに提供した上で得られた経験を元に、
 提供してくれているシステム設計‧運⽤の “⼤局的な” 考え⽅と
 ベストプラクティス集 • AWS W-Aの構成要素 • ホワイトペーパーや確認質問集も定期的に更新されている • AWSのソリューションアーキテクト（AWS W-A認定パートナー）も含まれる
23. AWS Well-Architected Frameworkとは • 最近では、AWS Well-Architected Toolも発表され、セルフチェック可能に • 2019/05時点では、⽇本語対応はされていない • 初期導⼊時は、AWSのソリューションアーキテクト同席での実施をオススメ
24. AWS Well-Architected Frameworkとは • ホワイトペーパーについて • 5つの柱（ホワイトペーパーの構成） • 運⽤の優秀性 • セキュリティ • 信頼性 • パフォーマンス効率 • コスト最適化
 
 
 • 最近では、IoTやServerless向けのホワイトペーパーも出ている • より詳しく知りたい⼈は、公式サイトをみてください • https://aws.amazon.com/jp/architecture/well-architected/
25. AWS Well-Architected Frameworkとは • よくある誤解 • AWS W-Aを銀の弾丸だと思っている • あくまで設計 “原則” なので、実装の詳細やアーキテクチャパターンは扱っていない • 銀の弾丸ではないが、システム（サービス）の健康診断として使える • Audit（監査）的な使い⽅ができると思っている • 現状把握には使えるが、監査的な使い⽅は望ましくない • AWS W-Aをするのが重要でなく、そこからどう改善に取り組むのかを⼀緒に考えることが⼤切 • ガバナンスのインプットには使うことは出来る
 • 試しに、1回実施してみたが良くならない • 定期的に実施する必要があり、チェックと改善フローを継続的に回すことが重要
26. AWS Well-Architected Frameworkとは • Deep Diveしたい⼈へオススメの資料 • AWS Black Belt Online Seminar & 公式ドキュメント（英語） http://bit.ly/ EJvLbV https://wa.aws.amazon.com/
27. 導⼊フロー
28. 導⼊フロー • 現状のシステム構成を整理（移設前のシステム構成図） 社内 社外 ユーザー Private Cloud Database Servers Application/API Servers Admin Servers Other Servers Mon Proxy Server 外部連携 Private Cloud 共通基盤 （画像/認証/課⾦） キャリア連携
 パートナーAPI 他社システム SaaS
29. 導⼊フロー • 事前に確認質問集へ記⼊
30. 導⼊フロー • AWSのソリューションアーキテクト同席で、レビュー会実施
31. 導⼊フロー • 現状のシステム状態の分析（Review Report）
32. 導⼊フロー • Review Reportを元に、システム改善（移設）計画を⽴てる • このステップが、AWS W-Aで⼀番重要であり、以下を明確にする必要がある • 何が問題なのか • 問題に対しての利害関係者は誰なのか • 問題箇所の技術領域に詳しいのは誰なのか • 問題箇所を解決する上で誰が責任者になるのか • 特に、何が問題なのかと責任者が明確になっていないと、改善着⼿は難しい
33. 導⼊フロー • システム改善（移設）を元に実施（移設後のシステム構成図） SaaS 外部連携 Private Cloud 共通基盤 （画像/認証/課⾦） キャリア連携
 パートナーAPI 他社システム VPC 社内 社外 ユーザー Application Servers API Servers Admin Servers Databases
34. 継続的なシステム改善に向けて
35. 継続的なシステム改善に向けて • Engineering Budgetという考え⽅ • サービスの売上変動に応じてエンジニアリング予算を確保 https://developers.cyberagent.co.jp/blog/archives/ /
36. 導⼊サービスの技術責任者からの声
37. 導⼊サービスの技術責任者からの声 • ポジティブな意⾒ • 運⽤周りのヒントを貰えたので、それを元に改善
 していこうと思えた👍 • どういったセキュリティリスクがあるのかを、
 認識することが出来た👍 • 運⽤中のサービスを初めてAWS上へ移設したが、
 安⼼して取り組むことが出来た👍 技術責任者：酒井⼩枝
38. 導⼊サービスの技術責任者からの声 • その他意⾒ • 複数項⽬からの選択式なので、項⽬によっては
 回答が難しい • 実際に課題は分かったが、事業レベルでどう改善に
 取り組んでいけば良いかが難しかった • 定期的にセルフチェックしたい 技術責任者：酒井⼩枝
39. CA Well-Architected Framework
40. 名前 岡⽥ 翔乃介 @rm_rf_slant • 所属 - 株式会社サイバーエージェント - 技術本部サービスリライアビリティグループ • ロール - Organizational Reliability Engineer • やってること - エンジニアチームリーダー - Public Cloud 活⽤サービスの System Architecture 周辺をサポート (兼任) • 好きなAWSサービス AWS Well-Architected Framework
41. CA W-A について
42. • CA Well-Architected Framework（CA W-A）とは - AWS W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク - 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤ - 使ってもらえないと意味がないため、回答⾃体が重荷にならないようにしている - 可能な限り質を落とさず、網羅的に項⽬を設定 - 質問数を可能な限り少なく - オリジナルの質問数から⼤幅に削減 - 内製だからできるカスタマイズ - Google Apps Script でレビュー結果の⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意 - ヒアリングシートの管理 & 運⽤を⾃動化 - Review Report（レビュー結果）の Suggestion - 社内ナレッジを適切に共有することが可能になる - 詳細は後ほどご紹介します💡 CA W-A について
43. • ５つの柱 - Security - 21 項⽬ - Reliability - 18 項⽬ - Performance - 16 項⽬ - Cost Optimization - 8 項⽬ - Operations - 14 項⽬ CA W-A について
44. • ５つの柱 - Security - 21 項⽬ - Reliability - 18 項⽬ - Performance - 16 項⽬ - Cost Optimization - 8 項⽬ - Operations - 14 項⽬ CA W-A について 全75項⽬で⾃サービスのシステム状態を紐解く
45. 学習 Condition Review 測定 Condition Review Review Report 改善/事業貢献 Improvement コミュニケーション Discussion & Planning CA W-A について
46. 学習 Condition Review 測定 Condition Review Review Report 改善/事業貢献 Improvement コミュニケーション Discussion & Planning CA W-A について
47. 学習 Condition Review 測定 Condition Review Review Report 改善/事業貢献 Improvement コミュニケーション Discussion & Planning CA W-A について ⾃サービスの今を⾒つめ直すための新たなサイクルを⽣み出す
48. • 開発者視点のメリット - いかなる開発者でもより迅速に、且つ低リスクでアプリケーションを構築できるようになる - CA としてのシステム設計/運⽤を体系的に学ぶことができる - 他のサービスが技術的課題をどのように解決しているのか知ることができる - 導⼊コストが低い • 事業者視点のメリット - 安全で効率的なアプリケーション環境を、どの事業でも提供することが可能になる - 相対的に提供しているサービスの信頼性も向上する - 5つの観点から⾃サービスのシステム状態を解剖し、リスクを可視化することができる CA W-A について
49. CA W-Aの実施フロー
50. CA W-A の実施フロー CONDITION REVIEW 事前にサービスの コンディションチェック START REVIEW REPORT ORE とサービスの技術責任者で 2時間レビュー会を実施 DISCUSSION & PLANNING 事業責任者 & 技術責任者と 課題の認識合わせ
51. CA W-A の実施フロー IMPROVEMENT 浮上した課題を改善し互い に事業を成⻑させていく 半年後に から再度実施
52. CA W-A の実施フロー IMPROVEMENT 浮上した課題を改善し互い に事業を成⻑させていく 半年後に から再度実施
53. CA W-A の実施フロー CONDITION REVIEW
54. CONDITION REVIEW GOOGLE SHEETS スプレッドシート GAS Google Apps Script SLACK API レビュー結果 を Slack 通知
55. - 「ヒアリングシート」と呼ばれる CA W-A の⼼臓 - [サービス担当者] アクセス権限は対象サービス に関わっている社員であれば複数⼈追加しても 問題ない CONDITION REVIEW - ORE Bot がレビュー結果を⾃動集計 & 解析 - [ORE] ヒアリングシートの Template をコピー して4つの設定を追加すればすぐに使⽤可能 となる - [サービス担当者] 各項⽬にチェックするだけ！ - 「Pillar Results」を任意の Slack チャンネル に通知 - [ORE] ボタン1つでレビュー結果の Slack 通知が可能
56. - 「ヒアリングシート」と呼ばれる CA W-A の⼼臓 - [サービス担当者] アクセス権限は対象サービス に関わっている社員であれば複数⼈追加しても 問題ない CONDITION REVIEW - ORE Bot がレビュー結果を⾃動集計 & 解析 - [ORE] ヒアリングシートの Template をコピー して4つの設定を追加すればすぐに使⽤可能 となる - [サービス担当者] 各項⽬にチェックするだけ！ - 「Pillar Results」を任意の Slack チャンネル に通知 - [ORE] ボタン1つでレビュー結果の Slack 通知が可能
57. CONDITION REVIEW サービス名 サービスやアプリケーションの 名称を記⼊ (無い場合は、開発コードを記⼊) アカウントID 使⽤しているプラットフォーム のアカウントIDを記⼊ (AWS, GCP or PrivateCloud) アーキテクチャ図 URLを記⼊
58. CONDITION REVIEW 観点 質問に対する勘所や、判断材料 となる⼀例を紹介 優先度 ⾼: 優先的に改善したい項⽬ 中: 改善を推奨する項⽬ 低: 改善するとより良い項⽬ ご回答 対応済みの項⽬にチェック
59. CONDITION REVIEW SLACK ボタン - 「ヘルプ」メニューの横に 「Slack」メニューを配置 - レビュー会実施後、最終ジャッジ が終わったタイミングでクリック - 回答が⾃動集計 & 解析され、任 意の Slack チャンネルにレビュー 結果が通知される
60. CONDITION REVIEW SLACK ボタン - 「ヘルプ」メニューの横に 「Slack」メニューを配置 - レビュー会実施後、最終ジャッジ が終わったタイミングでクリック - 回答が⾃動集計 & 解析され、任 意の Slack チャンネルにレビュー 結果が通知される ポ チ ッ
61. CONDITION REVIEW
62. CONDITION REVIEW Review Report へのリンク
63. CA W-A の実施フロー REVIEW REPORT
64. REVIEW REPORT - Google ドキュメントを利⽤ - Master ドキュメントに全ての項⽬に対して の Suggestion (改善案や事例 etc ) を管理 - CA W-A 実施者は Master Page をコピー し、チェック済みの項⽬をマスクするだけ でレポートが完成する
65. REVIEW REPORT
66. REVIEW REPORT 全体的な結果
67. REVIEW REPORT 詳細結果
68. REVIEW REPORT 改善案や事例 etc
69. CA W-A の実施フロー DISCUSSION & PLANNING
70. DISCUSSION Review Report を起点に現状について 事業責任者と共通認識を形成する
71. PLANNING 事業と技術の双⽅から優先度を照らし合 わせ、合意できる改善計画を策定する
72. CA W-A の実施フロー IMPROVEMENT
73. IMPROVEMENT • 改善フロー - 合意が取れた解決すべき課題を改善 - 場合によっては ORE も協⼒ - 改善事例として、社内外へ公開 - 社内 - Slack - 社外 - 公式ブログ - 半期後に改善率チェック 4⽉ 10⽉ 優先的に改善したい項⽬ 改善を推奨する項⽬ 改善するとより良い項⽬
74. IMPROVEMENT • 改善フロー - 合意が取れた解決すべき課題を改善 - 場合によっては ORE も協⼒ - 改善事例として、社内外へ公開 - 社内 - Slack - 社外 - 公式ブログ - 半期後に改善率チェック 4⽉ 10⽉ 優先的に改善したい項⽬ 改善を推奨する項⽬ 改善するとより良い項⽬ 🎉
75. IMPROVEMENT CA W-A = チェックシート？
76. IMPROVEMENT CA W-A = チェックシート？
77. IMPROVEMENT CA W-A = コミュニケーションツール
78. IMPROVEMENT CA W-A = コミュニケーションツール 技術から事業成⻑を促すためのコミュニケーションツール
79. SATORI の進捗
80. SATORI の進捗 CONDITION REVIEW REVIEW REPORT DISCUSSION & PLANNING IMPROVEMENT
81. SATORI の進捗 CONDITION REVIEW REVIEW REPORT DISCUSSION & PLANNING IMPROVEMENT 今ここ！
82. CA W-A のレビュー結果
83. CA W-A のレビュー結果
84. CA W-A のレビュー結果 優先的に改善したい項⽬の数 改善を推奨する項⽬の数 改善するとより良い項⽬の数
85. CA W-A のレビュー結果 / / /
86. CA W-A のレビュー結果 / / / 協議の結果、今回はここに 焦点を当てて改善していくことに なりました！
87. 現在の状況
88. 現在の状況 NO. 障害時に有⽤なログを蓄積できていますか？ NO. 障害時に有⽤なログを分析に使っていますか？ NO. 障害時にサービスレベルがダウンした状態でサービスが継続できる     仕組みはありますか？ NO. パフォーマンスが劣化した際に、通知されるようになっていますか？ NO. 障害レベルによってのアクションが定義されていますか？ NO. 障害時にエスカレーションするプロセスが定義されていますか？
89. 現在の状況 NO. 障害時にサービスレベルがダウンした状態でサービスが継続できる     仕組みはありますか？ NO. 障害レベルによってのアクションが定義されていますか？ NO. 障害時にエスカレーションするプロセスが定義されていますか？ 6⽉中に完了予定 NO. パフォーマンスが劣化した際に、通知されるようになっていますか？ 今期中に実施
90. 現在の状況 先ほどご紹介した4つの項⽬が全て 対応完了したタイミングで実施するかジャッジ NO. 障害時に有⽤なログを蓄積できていますか？ NO. 障害時に有⽤なログを分析に使っていますか？
91. 各視点からのFB
92. 技術責任者からのFB • 緊急度のレベル分けはAWSのW-Aでも可能だったけど、 どういうことに影響が出そうかみたいなところまで まとめてきてくれたので、わかりやすいと思いました • 課題の洗い出しまでじゃなくて、計画を⽴てるところまで ⼊ってきてくれるところや課題に対してのアプローチ⽅法ま で相談できるのが助かります！ • 予め課題が明確になってるので、今期どこまでできそうか‧ やるべきなのか計画が⽴てやすいと思いました 技術責任者：酒井⼩枝
93. 技術責任者からのFB • 緊急度のレベル分けはAWSのW-Aでも可能だったけど、 どういうことに影響が出そうかみたいなところまで まとめてきてくれたので、わかりやすいと思いました • 課題の洗い出しまでじゃなくて、計画を⽴てるところまで ⼊ってきてくれるところや課題に対してのアプローチ⽅法ま で相談できるのが助かります！ • 予め課題が明確になってるので、今期どこまでできそうか‧ やるべきなのか計画が⽴てやすいと思いました 技術責任者：酒井⼩枝
94. 事業責任者からのFB • 説明資料も簡潔でエンジニア職以外のメンバーにも 理解しやすい内容になっていました！ • 事業責任者として、このような取り組みに メリットを感じます • 常⽇頃からユーザーへの寄り添いが求められますし、 職種問わず品質に向き合うのは⼤事なことなので、 横断でこういった取り組みを実施していただける ことは⼤変ありがたいです 代表取締役社⻑：五藤尚也
95. 事業責任者からのFB • 説明資料も簡潔でエンジニア職以外のメンバーにも 理解しやすい内容になっていました！ • 事業責任者として、このような取り組みに メリットを感じます • 常⽇頃からユーザーへの寄り添いが求められますし、 職種問わず品質に向き合うのは⼤事なことなので、 横断でこういった取り組みを実施していただける ことは⼤変ありがたいです 代表取締役社⻑：五藤尚也
96. その他にも… AWS以外のプラットフォームでも 実施できるのは嬉しい 現状のサービスが抱えている 潜在的なリスクの可視化ができる 現状課題に対して、事業部全体で 共通認識を持てる 事業部にとって何をすればいいのか を考える時の資料として活⽤できる 社内に存在するナレッジを活⽤で きるようにする 知らなかったことを知れたり、 それによる議論が⽣まれる
97. その他にも… AWS以外のプラットフォームでも 実施できるのは嬉しい 現状のサービスが抱えている 潜在的なリスクの可視化ができる 現状課題に対して、事業部全体で 共通認識を持てる 事業部にとって何をすればいいのか を考える時の資料として活⽤できる 社内に存在するナレッジを活⽤で きるようにする 知らなかったことを知れたり、 それによる議論が⽣まれる たくさんのポジティブなFBをいただきました🎉
98. CA W-Aの今後について
99. CA W-A の今後について サービスに導⼊済み🎉
100. CA W-A の今後について + サービス導⼊予定
101. CA W-A の今後について Review Report まで完了 % % Discussion & Planning 着⼿
102. CA W-A の今後について Review Report まで完了 % % Discussion & Planning 着⼿ % ⤴
103. CA W-A の今後について Review Report まで完了 % % Discussion & Planning 着⼿ % ⤴ 2⼈で完遂するのは少し⼤変 😑
104. CA W-A の今後について 2019年度下半期 ⽬標 CA W-A の導⼊(運⽤)コストを削減 CA W-A を導⼊できるメンバーを増やす
105. CA W-A の今後について AWS W-A Tool のロードマップによっては、統合するかも 提案できる情報の最⼤化 ⾃動で前回のレビュー結果と⽐較し、再集計までしてくれる機能の追加 2019年度下半期 やるべきこと ⺟国語の形成 On-boarding の整備と公開
106. CA W-A の今後について AWS W-A Tool のロードマップによっては、統合するかも 提案できる情報の最⼤化 ⾃動で前回のレビュー結果と⽐較し、再集計までしてくれる機能の追加 ⺟国語の形成 On-boarding の整備と公開 CA W-A の導⼊(運⽤)コストを削減 CA W-A を導⼊できるメンバーを増やす 2019年度下半期 やるべきこと
107. Summary
108. Summary • AWS W-Aの可能性 - 体系的にAWSについて学ぶことができる - AWSを活⽤しているサービスであれば、AWS W-Aを試さない理由はない • プロダクトの成⻑をお⼿伝いするために CA W-A を作りました - サービスや事業の成⻑速度を、システムを理由に落とさないための1つの⼿段です☝ - 事業視点と技術(システム)視点の双⽅から⾃サービスを⾒つめ直し、根本的な課題をクリアに するための道具です🔧 - CA W-A = ただのチェックシートではないし、監査として使⽤するものでもないです！❌
109. Summary ORE について興味がおありの⽅は以下のスライドもご覧ください🙇 https://speakerdeck.com/cyberagentdevelopers/well-architected https://www.slideshare.net/ShotaTsuge /wellarchitected-ca-wa-jaws-days-
110. Thank you! Shota Tsuge Twitter: @shotaTsuge Shonosuke Okada Twitter: @rm_rf_slant