Tweet
Tweet

Slide 1

Slide 1 text

Well-Architectedな組織を 
 実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか - @JAWS DAYS 2 01 9 #jawsdays #jd 2 0 1 9 _e 株式会社サイバーエージェント 技術本部サービスリライアビリティグループ 柘植 翔太

Slide 2

Slide 2 text

名前 柘植 翔太 @shotaTsuge • 所属 株式会社サイバーエージェント 技術本部サービスリライアビリティグループ • ロール Senior Organizational Reliability Engineer • 好きなAWSサービス AWS Well-Architected Framework • コミュニティ活動 Japan AWS User Group（ 2 0 1 2 - 2 0 16 ）

Slide 3

Slide 3 text

名前 柘植 翔太 @shotaTsuge • 会社での経歴 20 1 4 / 0 4 - 2014 / 09 Software Engineer @ AmebaPigg 20 1 4 / 0 9 - 2018 / 03 Infrastructure Engineer - Ameba Pigg - Social Game Services - Curation Media Services - Streaming Services - Matching Services - AdTech Services - FinTech Services - And more … 20 1 8 / 0 4 - Senior Organizational Reliability Engineer

Slide 4

Slide 4 text

寄稿歴 • サイバーエージェント公式デベロッパーブログ https://developers.cyberagent.co.jp/blog/archives/ 19224 / • Software Design 201 9 年2⽉号 - SRE特集 - https://gihyo.jp/magazine/SD/archive/ 2 01 9 / 20 1 90 2 • AWS導⼊事例 https://aws.amazon.com/jp/solutions/case-studies/torte/

Slide 5

Slide 5 text

良かったらいいねして下さいw • サイバーエージェント公式デベロッパーブログ https://developers.cyberagent.co.jp/blog/archives/ 19224 /

Slide 6

Slide 6 text

本セッションの内容 • 本セッションで話すこと📢 - ⾃分が所属する横断的インフラ組織がどんな悩みを抱えながら歩んでいるのか - OREというロールをなぜ作ったのか、そもそもどういったロールなのか - なぜ、独⾃でWell-Architected Framework（CA W-A）を作っているのか - Well-Architected Frameworkにどんな可能性を感じているのか • 本セッションでの注意⚠ 技術的なことは話しません🙇 CA W-Aは、現時点では試作段階であり、本セッションにおける発⾔は、 所属するチームとしての⾒解であり、会社全体の意向ではありません🙏

Slide 7

Slide 7 text

登壇者からのお願い • 本セッションへのお気持ち 今⽇は、友達が欲しくて登壇しに来たので、優しく⾒守ってください🙏 
 同じように悩んでいる⼈いれば、 
 #jawsdays , #jd 20 1 9 _e のハッシュタグ付けてつぶやいてもいいし、 
 本セッションが終わった後に、登壇者に話しかけてくれると喜びます☺ 
 本セッションが終わった後に、より多くの様々な議論が⽣まれてくれれば幸いです🙏

Slide 8

Slide 8 text

1 .Introduction 所属する会社 / 組織について 2 .History of the Organization インフラ組織としての歩みと課題について 3 .Organizational Reliability Engineering ORE / AWS W-A / CA W-Aについて ORE / CA W-Aの今後について 4 .Summary 伝えたかったこと

Slide 9

Slide 9 text

Introduction

Slide 10

Slide 10 text

所属する会社について

Slide 11

Slide 11 text

所属する会社について • 株式会社サイバーエージェント 巷では、CAって呼ばれています • 従業員数（連結）は、約5,000⼈ • 事業について - メディア事業 - スタートアップ（新規）事業 - ゲーム事業 - インターネット広告事業 • 今年の春に、オフィス移転予定 グループ全体ではなく、⼀部事業部

Slide 12

Slide 12 text

所属する会社について • CAのエンジニア⽂化 与えられる裁量とそれに対する責任も⼤きい ネイティブエンジニアから、サーバサイドエンジニアへ転向するなども出来る CAグループ内での移動も出来るので、違う業種のサービスも関わることが出来る CAに興味ある⼈は、ZEHI !! https://www.wantedly.com/companies/cyberagent ⾃分のチームも絶賛募集中です！少しでも興味あるって⼈は気軽に声かけて下さい🙏 https://www.wantedly.com/projects/ 20 8 915

Slide 13

Slide 13 text

所属する組織について

Slide 14

Slide 14 text

所属する組織について • 技術本部とは 社内でメディア管轄と呼ばれているサイバーエージェントグループのメディア事業や 
 スタートアップ（新規）事業のサービスに対して横断的なサポートなどをしている組織 共通基盤や秋葉原ラボ、Private Cloudなども、この組織に属している

Slide 15

Slide 15 text

• メディア管轄のサービス（⼀部抜粋） 所属する組織について

Slide 16

Slide 16 text

所属する組織について • サービスリライアビリティグループとは メディア管轄のサービスのインフラ領域を横断的にサポートしているグループ Service Reliability Groupの頭⽂字を取って、SRGと呼ばれている 主に、既存サービスの改善や新規⽴ち上げなどを⾏なっている ⼗数⼈で、⼤⼩合わせて200弱のサービス‧システムをサポートしている💪 SRG内には、いくつかのチームがある

Slide 17

Slide 17 text

所属する組織について • メディア管轄とSRGの相関図

Slide 18

Slide 18 text

History of the Organization

Slide 19

Slide 19 text

インフラ組織としての歩みと課題

Slide 20

Slide 20 text

インフラ組織としての歩みと課題 • SRGの前⾝となるインフラ組織（〜2015年） 会社の歴史と共に、組織の形態を変えていた - 今のSRGのように横断組織の時もあれば、サービス付の時代もあった - 昔ながらのインフラ屋的なオンプレ時代 - ⾃前のオンプレミス環境 - サーバのラッキングやミドルウェアのセットアップをしていた - Private CloudやPublic Cloudへとシフト（2012年〜） - Private Cloud専属チームの結成 - Public Cloudの利⽤が徐々に拡⼤

Slide 21

Slide 21 text

インフラ組織としての歩みと課題 • SRGの前⾝となるインフラ組織（〜2015年） インフラチームの働き⽅も、以下のような責務に変わっていった - Provisioning - Infrastructure as a Code , Deploy pipeline - Scalability - Capacity Planning - Performance - DB/App Tuning , Stress Test - Monitoring - On-Call - Security

Slide 22

Slide 22 text

インフラ組織としての歩みと課題 • SRGとしての始まり（2015年〜） この頃、横断組織のインフラエンジニアとしてのアプローチにもどかしさを感じていた - もっとプロダクトに貢献できるんじゃないのか 信頼性を軸としたプロダクト貢献をする組織に変わるべく… SREを⽬指そうと、組織名をサービスリライアビリティグループに変更しました きっかけは、SREが流⾏り始めてたので、その流れに乗った感じです🏄

Slide 23

Slide 23 text

インフラ組織としての歩みと課題 • SREとしての活動を始める（2016年〜） Site Reliability Engineeringの哲学を学ぶ - Google SREとのディスカッション - Site Reliability Engineeringに関する書籍の輪読会 - Site Reliability Engineering - The Site Reliability Workbook - 以下の4つの分類を中⼼に学んでいった - Software Engineering - System Engineering - Overhead - Toil

Slide 24

Slide 24 text

インフラ組織としての歩みと課題 • SREとしての活動を始める（2016年〜） Site Reliability Engineeringの哲学を学ぶ 学んだことを元に、以下の取り組みなどを進めていきました - Toil撲滅運動（50%ルール） - Postmortem - Runbook - On-boardingプロセス - 障害対応フローの再設計（On-Callへ向けて） - SRGとしてのSREの再定義

Slide 25

Slide 25 text

インフラ組織としての歩みと課題 • SREやろうとしたけど（2017年〜） 結果どうだったのか SREに名前を変えただけ😇 - 横断組織で、メディア組織全体としての信頼性を担保するSREにはなれなかった - 直接的なサービスの信頼性向上という意味では、インフラエンジニアの時と変化がなかった 感じた課題 横断組織として網羅的なアプローチが難しい😥 - SRGのメンバーの10倍以上の多種多様なメディアサービス数 - サービス毎に技術スタックも異なる

Slide 26

Slide 26 text

インフラ組織としての歩みと課題 • SREやろうとしたけど（2017年〜） 感じた課題 信頼性を担保することのメリットが分かりづらい - そもそも、誰に対しての信頼性なのか？🤔 - エンジニア層に対して？ - ビジネス層に対して？ - ユーザ層に対して？ 
 そもそも現状のリスクが可視化できていないし、優先度も共通認識されていない - 何がしたかったのか？ - 何でしたいのか？

Slide 27

Slide 27 text

インフラ組織としての歩みと課題 • もっと根本的な組織課題について考える（2017年〜） ⽬⽴ったやつが評価される - 本当に⼤事かもしれないけど、不満が⽣まれやすい それぞれが、⼤事なことやってると思ってる - 組織にとって⼤事なこと（優先度含め）が、定義されてないから評価されにくい - ⾃分ではそこが定義できない（マネージャとかに委ねたい） - 最悪、評価されないから退職リスクもあΔ😱 横断組織メリットがあるというが、誰もそのメリットが最⼤化できる組織にしていない - 横断組織とか⾔いつつ、狭い枠の中（所属する組織）でしか仕事してない - 結果メリット出せなくて、横断組織いらないってなりがち😱

Slide 28

Slide 28 text

インフラ組織としての歩みと課題 • 改めて、横断組織のメリットを考える（2017年〜） 横断組織としての強みは - インフラ視点として考えるなら、 - 多種多様なサービスに関わってるからこそのナレッジ - そのナレッジがあるから、サービス全体の信頼性を底上げできる - 我々がすべきなのは、System Architectureの信頼性に対してのアプローチなのでは 他にも⼤事なこと - そもそも事業会社だったら、サービスの成⻑視点で考えるべき - Service Architectureの信頼性を最⼤値を伸ばすアプローチ

Slide 29

Slide 29 text

インフラ組織としての歩みと課題 • ⾃分達の組織に適⽤する（2018年〜） Site Reliability Engineeringの哲学を、2つの属性にわける - System Architecture Reliability - 横断組織としてサービスの信頼性を担保するロール - 多種多様なメディアサービス全体の信頼性の底上げをする - Service Architecture Reliability - 特定サービスの専任としてのアプローチするロール - サービスの信頼性の最⼤値を伸ばす - もっと知りたいという⼈は、 Software Design 20 19 年2⽉号 - SRE特集 - を読んで下さい🙇 でも、現状のSRGの組織状態では、難しいとも感じた

Slide 30

Slide 30 text

インフラ組織としての歩みと課題 • 改めて、横断組織の強みとすべきことを考える（2018年〜） なぜ出来てないのか🤔 - ⽬標（ビジョン）の共有ができておらず、すべきことが可視化できてない - 雰囲気でなく、スコープや現状‧ニーズを共通認識持てるようにする必要がある - 可視化できてれば、必要なロールもわかるし、それを作ることもできる - 個⼈的には、インフラエンジニアとか SRE はロールが⼤きすぎる 
 - 組織間のコミュニケーションが⾜りていない - ⽬標（ビジョン）が明確じゃないから、コミュニケーションの壁も感じている - 結果、ナレッジの共有ができない🙅 これらのことを踏まえ、OREというロールを作ることにしました

Slide 31

Slide 31 text

Organizational 
 Reliability 
 Engineering

Slide 32

Slide 32 text

OREとは

Slide 33

Slide 33 text

OREとは • そもそも信頼性とは？ とりあえず、Wikipediaで調べてみた👀 なるほど、じゃあ⾃分達が考える必要がある信頼性って何なんだろうか？🤔

Slide 34

Slide 34 text

OREとは • 4つの信頼性の層 Corporation（会社） ← IR（Investor Relations） ⇅ Customer（顧客） ← CRE（Customer Reliability Engineering） ⇅ Cooperation（連携）← ORE（Organizational Reliability Engineering） ⇅ ↑横断組織だからͦ͜ͷඞཁੑ💪 Service（サービス） ← SRE（Site Reliability Engineering）

Slide 35

Slide 35 text

OREとは • ミッション 組織的な信頼性向上のために頑張るエンジニア 組織全体としてのナレッジが最⼤化されサービスへ還元できている状態にする - 横断組織のインフラエンジニア だからこそ持っているナレッジを適切に提供する 事業部レベルでのシステムリスクが共通認識できている状態にする - サービスの抱える課題を優先度やスコープとそのメリットも含めて、可視化する - 組織間コミュニケーションを活発化させる🤝 サービス成⻑へつながる技術戦略が作れている状態にする - ⾃分達のバックグラウンド的には、System Architectureの視点がやりやすい

Slide 36

Slide 36 text

OREとは • 要は、こういうこと ⽬的が明確化されてて、それに向かってのアクションが取りやすい状況 課題の可視化 ↓ 共通認識（優先順位‧スコープ） ↓ アクションが取れる状態（ナレッジを適切に提供） ↓ サービス成⻑へコミットできる System Architectureって視点だと、 AWS Well-Architected Framework とか良さそうだと思い、試すことにしました

Slide 37

Slide 37 text

AWS W-Aについて

Slide 38

Slide 38 text

AWS W-A について • AWS Well-Architected Framework（AWS W-A）とは AWSをユーザ向けに10年以上に提供した上で得られた経験を元に、 
 提供してくれているシステム設計‧運⽤の “⼤局的な” 考え⽅とベストプラクティス集 AWS W-Aの構成要素のホワイトペーパーや確認質問集も定期的に更新されている AWSのソリューションアーキテクト（AWS W-A認定パートナー）も構成要素に含まれている 最近では、AWS Well-Architected Tool も発表され、セルフチェックをすることも可能に 2018/02時点では、⽇本語対応はされていません

Slide 39

Slide 39 text

AWS W-A について • ホワイトペーパーについて 5つの柱（ホワイトペーパーの構成） - 運⽤の優秀性 - セキュリティ - 信頼性 - パフォーマンス効率 - コスト最適化 ※ 2019/02時点 
 最近では… IoT や Serverless 向けのホワイトペーパーも出ている より詳しく知りたい⼈は、公式サイトを⾒てください

Slide 40

Slide 40 text

AWS W-A について • よくある誤解 AWS W-A をやればええ感じに出来ると思っている あくまで設計 “原則” なので、実装の詳細やアーキテクチャパターンは扱っていない AWS W-A は、銀の弾丸ではない🙅 監査（Audit）的な使い⽅が出来ると思っている 現状を知るのには使えるが、監査的な使い⽅は望ましくない AWS W-A をすれば OK ではなく、そこからどうやっていくかを⼀緒に考えることが⼤切 ガバナンスのインプットには使えると思っている（個⼈的⾒解） ⼀回やればOKだと思っている AWS W-A は定期的に実施する必要がある AWS W-A のフロー（チェック‧改善）を継続的にまわすことが重要

Slide 41

Slide 41 text

AWS W-A について • もっとAWS W-Aを知りたい⼈におすすめの資料 AWS Black Belt Online Seminar ＆ 公式ドキュメント（英語）

Slide 42

Slide 42 text

AWS W-A について • 実際に AWS W-A を試してみて AWS W-Aを試してみた、サービスの⼈からの意⾒👂 - 運⽤周りのヒントをもらったので、それをもとに改善していこうと思えた👍 - どういったセキュリティリスクがあるかを認識することができた👍 などのポジティブな意⾒をもらいつつも… ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、 弊社担当のソリューションアーキテクトによる実施の話になります。

Slide 43

Slide 43 text

AWS W-A について • 実際に AWS W-A を試してみて AWS W-Aを試してみた、サービスの⼈からの意⾒👂 - 複数項⽬からの選択式なので、項⽬によっては回答が難しい - 実際に課題は分かったけど、事業レベルでどう改善を進めていけば良いかわからない - 定期的にセルフチェックしたい という声も、多数ありました。 また、弊社ではAWS以外のプラットフォームも活⽤しているので、 同じ様なアプローチが出来ないかと思うようになり、 プラットフォームに依存しない Well-Architected Frameworkを作ることにしました。 ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、 弊社担当のソリューションアーキテクトによる実施の話になります。

Slide 44

Slide 44 text

CA W-Aについて

Slide 45

Slide 45 text

CA W-A について • CA Well-Architected Framework（CA W-A）とは - AWS W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク - 質を落とさないようにしつつ、回答のハードルを下げる - 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤ - 回答しづらい項⽬は削除するなど、質問数を可能な限り削減 - 内製だからできるカスタマイズ - Google App Script で⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意 - ヒアリングシートの管理 & 運⽤を⾃動化 - Review Report（レビュー結果）の Suggestion - 社内ナレッジを適切に共有することが可能

Slide 46

Slide 46 text

CA W-A について • ⼤枠は、AWS W-Aと同じ5つの柱 合計75の項⽬を回答することにより、現状のサービスの状態を紐解く - Security - Reliability - Performance - Cost Optimization - Operations

Slide 47

Slide 47 text

CA W-A について • サービスの今を⾒つめ直すための新たなライフサイクルを⽣み出す 学習 Condition Review 測定 Condition Review 改善/事業貢献 Improvement コミュニケーション Review Report Discussion & Planning 1 2 3 4

Slide 48

Slide 48 text

CA W-A について • 実際に、CA W-Aを試してみたサービスからの声 - AWS以外のプラットフォームでも⾏えるのは嬉しい - 現状のサービスが抱えている潜在的なリスクの可視化ができる - 現状課題に対して、事業部全体で共通認識を持てる - 事業部にとって何をすればいいのかを考えるときの資料として活⽤できる - 社内に存在するナレッジを活⽤できるようになる - 知らなかったことを知れたり、それによる議論などが⽣まれる🗣

Slide 49

Slide 49 text

CA W-Aの実施フロー

Slide 50

Slide 50 text

CA W-A の実施フロー CONDITION REVIEW 事前にサービスの コンディションチェック 01 START REVIEW REPORT ORE とサービスの技術責任者で 2時間レビュー会を実施 02 DISCUSSION & PLANNING 事業責任者 & 技術責任者と 課題の認識合わせ 03

Slide 51

Slide 51 text

CA W-A の実施フロー IMPROVEMENT 浮上した課題を実際に改善し、 互いに事業を成⻑させていく 04 半年後に 01 から再度実施

Slide 52

Slide 52 text

CA W-A の実施フロー 01 CONDITION REVIEW

Slide 53

Slide 53 text

CONDITION REVIEW • ヒアリングシートについて サービスのコンディションをチェックする質問集✍ 権限管理や運⽤のしやすさを考慮し、Googleスプレッドシートで管理 Google App Scriptを使って、レビュー結果の⾃動集計や解析もしている

Slide 54

Slide 54 text

CONDITION REVIEW • ヒアリングシートについて スプレッドシートをカスタマイズし、簡易的なレビュー結果をSlackへ通知 ポ チ ッ

Slide 55

Slide 55 text

CA W-A の実施フロー 02 REVIEW REPORT

Slide 56

Slide 56 text

REVIEW REPORT • Googleドキュメントを利⽤している - Overall Result（全体的な結果） - 各優先度の合計数を表⽰ - Pillar Results（詳細結果） - ⼤枠毎に優先度の数を表⽰ - Suggestion（改善案 or 参考資料） - 優先度が⾼い順に表⽰ - 現在、試⾏錯誤を繰り返しています

Slide 57

Slide 57 text

CA W-A の実施フロー 03 DISCUSSION & PLANNING

Slide 58

Slide 58 text

DISCUSSION＆PLANNING • CA W-Aフローの中でこのステップが⼀番重要になる 責任者との現状を理解した上での改善計画を⽴てるためには、 以下を明確にしないといけない - 何が問題なのか - 問題に対しての利害関係者は誰なのか - 問題箇所の技術領域に詳しいのは誰なのか - 問題を解決する上で誰が責任者になるのか 特に、 何が問題なのか と 責任者 が明確になっていないと、 次のステップの Improvement（改善） を着⼿することは⾮常に難しい

Slide 59

Slide 59 text

CA W-A の実施フロー 04 IMPROVEMENT

Slide 60

Slide 60 text

IMPROVEMENT • どうやって改善を進めるのか Review Report の Suggestion が重要になる 組織として持っているナレッジ（ベストプラクティスやモジュールの提供など）を 効率的に提供する為に、複数サービスでのCA W-Aレビューの結果をもとに、 傾向的に早く提供した⽅が良いものから準備を進めている どういった Suggestion をしてるのか - ベストプラクティス集 - ECS, CI/CD … - Terraform の共通モジュール - Ansible の共通 Playbook - オペレーション周りの⾃動化ツール - and more …

Slide 61

Slide 61 text

IMPROVEMENT • CA W-Aとは何なのか？ CA W-Aは、コミュニケーションツールだと考えています🤝 ただ、チェックするのが⽬的ではなく 技術から事業成⻑を促すためのコミュニケーションツール💪 として考えています CA W-Aについて、もっと詳しく知りたいという⼈は、 CA BASE CAMPという社内カンファレンスに登壇した資料を後⽇アップ予定なので、 是⾮それを⾒てください🙏

Slide 62

Slide 62 text

CA W-Aの今後について

Slide 63

Slide 63 text

CA W-A の今後について ⾃動で前回のレビュー結果と⽐較し、再集計までしてくれる機能の追加 提案できる情報の最⼤化 AWS W-A Tool のロードマップによっては、統合も検討

Slide 64

Slide 64 text

CA W-A の今後について • AWS W-A Toolが、AWS以外でも使えるように㊗

Slide 65

Slide 65 text

OREの今後について

Slide 66

Slide 66 text

OREの今後について • CA W-Aは、始まりに過ぎない 横断的なアプローチなので、 System Architecture Reliability の要素が⼤きい • 我々がやるべきことは、まだ沢⼭ある サービスの信頼性の最⼤値を伸ばす、 Service Architecture Reliability 的な アプローチをいかに実践していくかが⼤事 ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートする為のフレームワークも作成予定 そのために、SRGに所属するインフラエンジニア を適切なロールに細分化することも 
 考えています。

Slide 67

Slide 67 text

OREの今後について • 今更ですがOREの⽬指すビジョンについて 我々は、Curiosity をテーマに掲げています - 好奇⼼が湧く（ワクワクする）ことが出来る組織を⽬指そう！ - その組織を⽬指している⾃分達も、好奇⼼をもって取り組もう！

Slide 68

Slide 68 text

Summary

Slide 69

Slide 69 text

伝えたかったこと

Slide 70

Slide 70 text

伝えたかったこと • ⽬標（ビジョン）明確化しましょう！ 明確化されてないと、アクション取りづらくないですか？ 多くの組織における⽬標は、サービス成⻑させて、会社も成⻑させることじゃないかと そのために、もっとコミュニケーションしていきましょう🗣 Well-Architected Frameworkは、⼀つの⼿段として使えるもの🙆 分散されているナレッジの蓄積や共有を適切に⾏うこともできる AWSでサービス運⽤してるなら、AWS W-Aは使わない理由はない • すべきことをベースにロール（役割）も考えてほしい 本当に必要なロールは何なのか？🤔 ないなら、⾃分達で宣⾔してもいい🙆 だから、ORE作りました💪

Slide 71

Slide 71 text

伝えたかったこと • ワクワクして働ける場を作ろう！ 結局はこれのために、組織について議論するのでは… みんなが納得いく評価制度を作るのは難しいけど、そんな環境は作れるはず そしたら、⼈事に⾔われなくても、リファラル採⽤やりますよね🙆 • AWS系のカンファレンスなので… フィードバックとか、フューチャーリクエストどんどん投げましょ🗣 それで、もっとディスカッションしていきましょ！ ⾃分達も AWS W-A 含め何かしらの形で、今後もコントリビュートしていくお気持ちです！

Slide 72

Slide 72 text

最後に

Slide 73

Slide 73 text

Special Thanks • JAWS DAYS 2019 Stu ff 🙇 本当に感謝しかないです🙌 • ORE Team Shonosuke Okada（@rm_rf_slant） • AWS Well-Architected Team and Japan AWS Team いつも⼤変お世話になってます🙌

Slide 74

Slide 74 text

Every day is still Day One :) - 我々のチャレンジは続く -

Slide 75

Slide 75 text

ご静聴ありがとうございました🙇