満漢全席を食らえ!JAWS DAYS 2019レポート 第11回
独自のCA W-Aは組織間コミュニケーションにおいても有効
AWS Well-Architected FrameworkをアレンジしたCA SREチームの挑戦
2019年05月08日 10時30分更新
JAWS DAYS 2019に登壇したサイバーエージェントに入社した柘植 翔太さんのセッション。AWSが提供しているシステム設計・運用のベストプラクティス集「AWS Well-Architected Framework」を独自でアレンジし自分たちの組織に合わせたものを作るに至った背景やプロセスが語られた。
エンジニアに裁量を与えるサイバーエージェント、そのインフラ組織の変遷
学生時代からJAWS-UGに参加し、新卒でサイバーエージェントに入社した柘植 翔太さんは、アメーバピグのソフトウェアエンジニアとして半年間経験を積んだ後、インフラエンジニアとしてなど各種サービスに長く携わってきた。昨年から所属している技術本部サービスリライアリティグループでは、社内で「メディア管轄」と呼ばれているメディア事業や新規事業のサービス大小含め200弱のインフラを横断的にサポートしている。
メディア、スタートアップ(新規)、ゲーム、インターネット広告事業などを手掛けるサイバーエージェントには従業員5000人ほどが在籍しており、そのうち約2300人はエンジニアだ。チャレンジを推奨するカルチャーであり、エンジニアに与えられる裁量も責任も大きい。ネイティブエンジニアからサーバサイドエンジニアへ転向したり、グループ企業内での異動をしたりすることも可能だという。
サイバーエージェントのインフラ部隊は、オンプレミスがメインだった頃は自前のオンプレ環境でDBチューニングやサーバーのラッキング、ミドルウェアのセットアップなどを行なっていたが、クラウドへシフトするにあたりその働き方も変わっていった。
「もっとプロダクトに貢献していきたい」という話が社内で出始めたのは、2015年頃のことだ。ちょうどそのタイミングでGoogleが提唱したエンジニアの役割であるSRE(Site Reliability Engineering)という言葉が流行り始めていた。それはシステムの信頼性に重きを置いたもので、従来のインフラエンジニアとしての業務はもちろん、アプリケーションエンジニアの役割の一部を巻き取ることも含まれていた。柘植さんたちは、GoogleのSREチームとディスカッションをしたりSREについての本の輪読したりするなどしてSREについての知見を深め、2016年にはSREとしての活動を始める。
OREが実現すること、AWS Well-Architectedを試して見えたもの
しかし、SREとして活動するにあたっての壁は高かった。サイバーエージェントではエンジニアにも裁量が与えられており現場のエンジニアに任されている範囲は広く、サービスごとに技術スタックも違うため横断組織として網羅的なアプローチをするのは容易いことではない。「自分たちはSREとして、ただ名前を変えただけに過ぎないのでは?」という焦燥の中、改めて自分たちのあり方について考え直した。
横断組織としての強みは何かと考え浮かんだのは、多くのサービスに関わっているからこそのナレッジの存在だ。そのナレッジがあるからこそサービス全体の信頼性を底上げが可能となる。そしてそんな自分たちに期待されていることは、事業会社である以上サービスの成長視点を持って考えるべきであり、システムアーキテクチャそのものへの信頼性を伸ばすことが使命だと考えた。「ナレッジ」と「信頼性」、目指すものは見えてきたが、目標の共有や組織間のコミュニケーションなどの課題は多くあり、現状の組織のままでは難しいと感じた柘植さんは、「ORE(Organizational Reliability Engineering)」というロールを立ち上げることにしたのである。
OREのミッションは、「Organizational」の意味の通り組織的な信頼性向上であり、特にサイバーエージェントの場合、多種多様なサービスが存在し、それらに関わっているからこそのナレッジを共有することである。「サービスの抱える課題を可視化し、システムリスクの共通認識が持てている状態を作り、組織間のコミュニケーションを活性化させ、サービスの成長へとつながる技術戦略が作れている状態を目指す」(柘植さん)。ナレッジの最大化やサービスへの還元、組織間コミュニケーションなど担う責務は大きいが、サービスの成長への鍵を握る重要なエンジニアロールだ。
そしてシステムアーキテクチャを考えるにあたっては、「AWS Well-Architected Frameworkが良さそうだと思い、試すことにした」(柘植さん)。AWS Well-Architected(以下AWS W-A)とは、AWSが提供しているシステム設計・運用のベストプラクティス集である。構成要素のホワイトペーパーは5つの柱(運用の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化)からなり、IoTやサーバーレス向けのホワイトペーパーも用意されている。
このAWS W-Aを実際に試してみて、運用にあたっての改善ポイントや、セキュリティリスクなど自分たちのサービスの状態を知ることができたが、あくまでAWS W-Aは設計の原則であり、チェックにあたって回答が難しいものもあった。また、AWS以外のプラットフォームも使っていることなどから、柘植さんたちはプラットフォームに依存しない自分たちのWell-Architected Frameworkを作ることにしたのである。
CA Well-Architected Frameworkの誕生と導入
CA Well-Architected Framework(CA W-A)とは、柘植さんたちがAWS W-Aをベースに作成したプラットフォームに依存しない汎用的なフレームワークだ。質を落とさないよう考慮しつつ回答のハードルを下げるため、複数項目からの選択式ではなくYes/No形式にしたり、回答しづらい項目は削除した。また、回答の自動集計や解析、Slack通知など内製だからこそできるカスタマイズを行ない、レビュー結果の提案機能も実装し社内ナレッジの共有が適切に行われるよう工夫した。CA W-Aの実施フローは、まずサービスのコンディションを確認してから、OREとサービスの技術責任者にて2時間のレビュー会を実施する。最後は事業責任者及び技術責任者と課題の認識合わせを行なう。それにより見えた課題を実際に改善し、事業の成長に繋げていく。これを半年後また同じサイクルで繰り返していく、という流れだ。
最初のサービスコンディションチェックは、質問が記載されているヒアリングシートに回答してもらう形式だ。Googleスプレッドシートを活用し、Google AppScriptを使って集計や解析も行なわれる。簡易的なレビュー結果をSlackに通知させるカスタマイズも進めた。コンディションチェックの次は、レビュー会だ。レビューのレポートには、結果だけでなく改善案や参考資料も添付される。Googleドキュメントを使い、優先度が高い順に表示させるという工夫も行なっている。その後はCA W-Aのフローの中でもっとも重要な認識合わせになる。問題は何で、そのステークホルダーは誰なのか、明確にしておかなければ改善を実施することは難しくなる。改善にあたっては、独自で用意したベストプラクティス集やオペレーション周りの自動化ツールなど、様々なものを提供し、進めていくという。
柘植さんは「CA W-Aはコミュニケーションツールだと考えている」と語る。ただチェックするだけでなく、技術の側面から事業成長を促すためのコミュニケーションツール、それがCA W-Aなのである。今後も、前回のレビューとの比較や再集計などの機能追加や、提案内容の充実などを検討している。また、AWS Well-Architected ToolがオンプレミスやハイブリッドクラウドなどAWS以外でも使えるようになったこともあり、ロードマップ次第では統合も視野に入れている。さらには社内の内部監査室と連携し、監査などのガバナンスのインプット的な使い方ができないか、といった点も考えているという。壮大な計画とも言えるが、実際に働くエンジニアに寄り添いながら確実に一歩ずつ積み重ねてきたからこそ見えてきた未来だろう。
CA W-Aは「始まりに過ぎない」と柘植さんは断言する。横断的なアプローチであり、システム面でのアプローチという要素が強い。今後はさらに、サービスの信頼性を高めていくアプローチを実践していきたいと考えており、ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートするフレームワークも作っていく予定だ。そのために、自身が所属するチームのロールを適切に細分化することも検討している。
現在の組織で、ビジョンの明確にされておらず動きづらいと感じている人もいるだろう。多くの組織において、サービスの成長、そして会社の成長が目標であることは明白である。そのためにも、もっとコミュニケーションしていくことが必要であり、Well-Architected Frameworkは一つの手段として有効だ。「AWSを使ってサービス運用をしているのであれば、AWS W-Aを使わない理由はない」と柘植さんは言い切る。ビジョンが明確になれば、すべきことも見えてくる。それをベースにエンジニアの役割を考え、柘植さんはOREというロールを立ち上げた。今後もCA W-Aの、インフラ組織の、そしてOREというロールの挑戦は続いて行く。「Everyday is still Day One.」というAmazon.com CEOのジェフ・ベゾスの言葉を引用して、柘植さんのセッションは締めくくられた。
この連載の記事
-
第14回
デジタル
“いとみやび”な日本の働き方、私たちは、組織はどう変わっていくべきなのか? -
第13回
デジタル
私たちはなぜ、どんな風に技術書を書いたのか? -
第12回
デジタル
Infrastructure as Codeが目的化してない?ABEJAの村主さんが問う -
第10回
デジタル
危ないAWS環境の共通点はここ!ペンテスターが攻撃者視点で指摘する -
第9回
デジタル
Kubernetesに移行中のfreee、セキュリティとモニタリングを語る -
第8回
デジタル
運用に丸投げしてない? AWSでよりよいセキュリティライフを送るポイント -
第7回
デジタル
なにはともあれAWS Security Hubを有効にしてほしい -
第6回
デジタル
アプライアンスベンダーF5とNUTANIXがJAWS DAYSで語ったこと -
第5回
デジタル
オタク心をわしづかみにする虎の穴のAWS活用 -
第4回
デジタル
初心者がつまづきやすいCPUクレジットの落とし穴 - この連載の一覧へ