この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、中川です。
2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。 本記事は「事業責任者も必見！AWS Well-Architected Frameworkのビジネスへの有効活用」についてレポートします。
セッション概要
スピーカー（敬称略）：
・ 柘植 翔太（株式会社サイバーエージェント 技術本部・サービスリライアビリティグループ）
・ 岡田 翔乃介（株式会社サイバーエージェント 技術本部・サービスリライアビリティグループ）
セッション名：事業責任者も必見！AWS Well-Architected Frameworkのビジネスへの有効活用
本セッションでは、株式会社ASTROBOXが提供するサービスである「Ameba占い館SATORI」の事例を元に、プライベートクラウドで運用していたシステムを AWS へ移設する際、どのように AWS Well-Architected Framework を活用したのかについてお話しします。 また、私たちが独自に作っている CA Well-Architected Framework についてもお話しする予定です。
セッションレポート
以下、セッションレポートになります。
なお、Well-Architected Frameworkは、W-Aの略称を使用させていただきます。
1. Introduction
- 所属する会社について
- 株式会社サーバーエージェント
- 所属する組織について
- 技術本部
- 社内でメディア管轄と呼ばれているサイバーエージェントグループのメディアやグループを横断的にサポート
- サービスリライアビリティグループ
- メディア管轄のサービスのインフラ領域を横断的にサポート
- メディア管轄とSRGの総管轄
- ASTROBOXはAmeba関連サービス
- 技術本部
- ASTROBOXについて
- サイバーエージェント100%出資子会社
- SATORI、SATORI電話占い
2. Well-Architected Framework
- システム移設にあたり抱えていた課題
- 移設の期限がすでに決まっている
- システム構成の悩み
- インフラチームへの依存
- 技術者への提案
- AWSについての学習
- 潜在的なリスクの可視化
- W-Aを提案
- AWS Well-Architected Frameworkとは
- システム設計・運用の大曲的な考え方とベストプラクティス集
- 最近では、AWS Well-Architected Framework Toolも発表され、セルフチェック可能に
- ホワイトペーパーについて
- 5つの柱によって構成
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 最近では、IoTやサーバーレス向けのホワイトペーパーも
- 5つの柱によって構成
- よくある誤解
- AWS W-Aを銀の弾丸だとおもっている
- あくまで設計の原則
- システムの健康診断として使える
- 監査的な使い方ができると思っている
- 監査的な使い方は望ましくない
- どう改善に取り組むかを一緒に考えることが重要
- 試しに1回実行してみたが良くならない
- 定期的に実施し、チェックと改善のフローを継続的に回すことが重要
- AWS W-Aを銀の弾丸だとおもっている
- 導入フロー
- 現状のシステム構成を整理
- 事前に確認質問集へ記入
- 今はAWS W-A Toolを活用するといい
- AWSのSA同席で、レビュー会を実施
- 可能な限り技術責任者、決裁権をもつエンジニアが同席するといい
- 現状のシステム状態の分析
- Review Reportを元に、システム改善（移設）計画を立てる
- このステップがW-Aで一番重要
- 何が問題なのか
- 問題に対して利害関係者は誰何か
- 問題箇所の技術領域に詳しいのは誰か
- 問題箇所を解決する上で誰が責任者か
- このステップがW-Aで一番重要
- システム改善（移設）を元に実施
- 継続的なシステム改善について
- Enginieering Budgetという考え方
- サービスの売上変動に応じてエンジニアリング予算を確保
- 新しいツールを導入しやすくする
- エンジニアのコストも可視化して、事業成長できるように
- サービスの売上変動に応じてエンジニアリング予算を確保
- Enginieering Budgetという考え方
- 導入サービスの技術責任者からの声
- ポジティブな意見
- 運用周りのヒントを貰えたので、それをもとに改善していこうと思った
- どういったセキュリティリスクがあるのかを認識することができて
- 運用中のサービスをはじめてAWSに移設したが、安心して取り組めた
- その他の意見
- 項目によっては回答が難しい
- 課題はわかったが、事業レベルでどう取り組むべきか
- 定期的にセルフチェックしたい
- ポジティブな意見
3. CA Well-Architected Framework
- CA Well-Architected Framework とは
- AWS W-Aを元に作成した、プラットフォームに依存しない汎用的なフレームワーク
- Yes/Noだけで判別できるように
- 質問数を可能な限り少なく
- 内製だからできるカスタマイズ
- Google Apps Scriptでレビュー結果の自動集計・解析やSlack通知を実施するBot
- サービスを見つめ直すためのライフサイクル
- 学習
- 測定
- コミュニケーション
- 改善/事業貢献
- 開発者視点のメリット
- より迅速にかつ低リスク
- 体系的に
- 導入コストが低い
- 事業者視点のメリット
- どの事業でも提供することができる
- サービスの信頼性も向上する
- リスクを可視化することができる
- CA W-Aの実施フロー
- CONDITION REVIEW
- 事前にサービスのコンディションチェック
- REVIEW REPORT
- OREとサービスのジグつ責任者でレビュー
- DISCUSSION & PLANNING
- 技術責任者と事業責任者
- IMPROVEMENT
- CONDITION REVIEW
- CONDITION REVIEW
- Googleスプレッドシートでコンディションの質問集を管理
- カスタマイズしたSlackボタンからSlackにレビュー結果を連携
- REVIEW REPORT
- Googleドキュメントを利用
- すべての項目に関してSuggetionを用意
- 詳細結果、改善案や事例etc
- DISCUSSION & PLANNING
- 2回にわけて実施
- 事業と技術から優先度を話す
- IMPROVEMENT
- 改善フロー
- 合意が取れた解決すべき課題を改善
- 改善事例として、社内外へ公開
- 半期後に改善率チェック
- CA W-Aはチェックシートではない
- チェックした後のコミュニケーションに価値がある
- 改善フロー
- SATORIの進捗
- 今はIMPROVEMENT
- レビュー結果
- 優先して改善していく項目（CriticalIssue）に焦点を当てることに
- 以下のように分類
- 6月中に完了予定
- 今期中に実施
- 前2つが完了したら実施
- 技術責任者からのFB
- どういうことに影響がでそうかまでまとめてきてくれたのでわかりやすかった
- 事業責任者からのFB
- エンジニア以外も理解をしやすい内容であった
- CA W-Aの今後について
- 4つに導入
- さらに2つに導入予定
- 2019年下半期にやるべきこと
- 自動で前回と光っく
- 情報の最大化
- AWS W-A Toolと統合
- 母国語の形成
- On-boardingの整備と公開
4. Summary
- AWS W-Aの可能性
- 体系的にAWSについて学べる
- AWSを活用しているサービスであればAWS W-Aを試さない理由はない
- プロダクトの成長をお手伝いするために CA W-Aを作りました
- 事業視点と技術視点の双方から自サービスを見つめ直し、根本的な課題をクリアにするための道具
- チェックシートではないし、監査として使用するものではない
さいごに
AWS Well-Architected Frameworkとサイバーエージェント社で使用しているCA Well-Architected Frameworkの活用事例について、話していただきました。
W-Aをチェックシートとして終わりにするのではなく、定期的にW-Aを回すことが重要であり、そのために組織として改善できる環境作りも大事だと思いました。
18
