サービスの信頼性と可用性を担保するSREが目指す「サイバーエージェント流ベストプラクティス」模索の道のり

技術・デザイン

当社には、特定の分野に抜きん出た知識とスキルを持ち、第一人者として実績を上げているエンジニアを選出する「Developer Experts制度」があります。2023年、SREのDeveloper Expertsに新たに選出されたのが柘植です。2014年に入社し、横断組織のSREとしてAmeba、AWA、タップル、CL、社内基盤など幅広いメディアサービス・システムへのSRE導入、信頼性向上や新規立ち上げなどに従事。近年は、横断的に展開できるSREプラクティスの開発だけでなく、SRE人材の採用、育成、連携強化やセキュリティリスク改善などへも取り組む柘植に、SRE組織設立までの背景やエンジニアとしてのキャリア観を聞きました。

Profile

  • 柘植 翔太
    メディア統括本部サービスリライアビリティグループ マネージャー / SRE
    2014年新卒入社。インフラエンジニア、SREとして、AMEBA、AWA、社内基盤など50以上のメディアサービス・システムへのSRE推進、リスク改善、サービス立ち上げを経験。現在は、横断SRE組織のマネージャーとして、SREのEnablementや人材育成へ注力している。

横断SREとして、サービスの信頼性と可用性を担保する

── 柘植さんの現在の役割をおしえてください

私は、メディア事業横断のSRE組織のマネージャーをしています。主にメディア事業を担当し「Ameba」「AWA」「タップル」「CL」「社内基盤」など様々なサービスやシステムへのSRE導入をしてきました。また、インターネット広告事業ゲーム・エンターテイメント事業とも連携しながら、横断的なSRE(Site Reliability Engineering)組織を構築する事を目指しています。
この活動を通して、SREに関する技術ナレッジを社内に浸透する事で、グループ全体の開発効率や信頼性の向上を目指しています。

── 現在の活動内容を教えてください。

サイバーエージェントには「リスクを最小限に抑えながらも、ビジネス目標を達成するために、最新のツールやテクノロジーを積極的に導入する」という技術カルチャーがあります。
そういった「攻め」を「守る」ために、サービスやプロダクトの信頼性や可用性を担保する役割を担っています。例えばクラウド環境におけるWell-Architectedやトラブルシューティングなどがそれにあたります。
そして、我々の活動が、よりプロダクトと密に連携するためにも、我々の活動を知ってもらう必要があります。そこで、サイバーエージェントグループのSREチームが日々向き合っている課題や取り組みについてまとめた「SRE Technology Map」を制作しました。
 

 SRE Technology Map
SRE Technology Map

── 現在の組織に至った経緯を教えてください

私は2014年に新卒入社し、当時の「アメーバピグ」にバックエンドエンジニアとして配属されました。その後、もともと興味のあったインフラエンジニアにチャレンジできるタイミングがあり、メディア事業を横断的にみているインフラ部門に異動しました。

その当時は、オンプレミス型サーバーが主流でしたので、データセンターでの物理サーバーのラッキングや、現地での保守メンテナンス等を行っていました。その後、既存サービスのプライベートクラウドへの移設や、パブリッククラウド環境での新規サービス立ち上げにも関わりました。

そんな中、徐々にインフラエンジニアのあり方も変わってきました。パブリック/プライベートクラウドの導入が増え、それまでは「サービスを動かすための基盤」としてオンプレミス型サーバーを提供してきたインフラエンジニアですが、クラウド環境のシェア拡大に伴い、変化対応が求められたからです。

具体的には、プロダクトに特化したプライベートクラウド開発や、サービスに寄り添ったセキュリティ対応など、より細分化された役割に分かれていきました。「自分たちがプロダクトや事業に対して、どのような価値を提供できるか?」を考えるようになった時期でもあります。

その後、Googleが「Google SRE」を提唱し話題になりました。インフラエンジニアとしてのあり方を模索していた我々も、インフラエンジニアの業務の枠組みにとらわれることなく、事業に深く関わり、直接的な貢献ができるようになりたいと思い、SREの思想に共感したことを覚えています。そして、これからSREとして活動していく思いで、組織名を今のサービスリライアビリティグループに変更しました。

このように、時代の流れに合わせて組織や役割を試行錯誤しながら、現在の組織形態に落ち着いていったと言えます。

この経緯については「CyberAgent Developer Conference 2023」でも発表しています。

データで見るサイバーエージェントグループのSREと横断的なSRE推進の取り組み【CADC2023】

変わり続ける技術トレンドだからこそ「変化対応力」が問われる

── インフラエンジニアと聞くと、「ずっと仕事がある。サービスの浮き沈みに影響しない。安定している。」という印象を持っていましたが、実際はまったく逆の印象を受けました。エンジニアとしての存在意義や、プロダクトへの貢献を常に考え、組織もあり方も変え続ける必要があったのですね。

「インフラエンジニア」という役割やロールにとらわれると、エンジニアとしての本質を見失ってしまう気がします。重要なのは「どんな課題を技術で解決するか?」だと思います。プロダクトやサービスの課題が前提として存在し、その解決のためにエンジニアがソリューションを提供し、それを推進/実現するために組織や役割があると言えます。サイバーエージェントが大切にしている「変化対応力」とはまさにこの事です。

── エンジニアの観点で注目すべきプロダクトの課題とは何でしょうか?

例えば、オンプレミス型インフラの時代では、信頼性や高可用性の確保、ハードウェアのコスト削減、サービス要件を満たすためのパフォーマンスチューニングなどがありました。しかし、時代とともにハードウェアの性能も向上し、カリカリにチューニングしなくても、クラウド環境で充分なサービス要件を満たせる時代に変わりました。時流に沿って、課題そのものも大きく変わったケースと言えます。

── では、クラウド環境が主流になった今では、どんな課題が生じていますか?

以前は、インフラ領域をインフラエンジニアが担当していましたが、現在はバックエンドエンジニアが関わるケースが多いです。

アプリケーションエンジニアがインフラを管理できるようになると、開発速度も向上します。その一方、各プロダクトで似たような機能を開発して「車輪の再発明」が頻発していたり、担当するエンジニアの習熟度によって、パフォーマンスにバラツキが発生したり、潜在的なリスクに気づかないまま開発が進んでいるなどのケースもあり得ます。

こういった課題に対して我々は、SREの思想をベースに、技術的な全体最適化が起きるようにサポートしています。ナレッジやリソースをどのように流動的に管理できるかが、横断組織の重要な役割だと思っています。
 

── ナレッジの伝播や技術的リソースの全体最適化で、具体的にとりくんでいる事を教えてください。

例えば、「SRE成熟度評価」という施策を推進しています。「SRE成熟度評価」とは、事業部全体を俯瞰しデータ化するために、能力成熟度モデル統合をベースに作成したものです。また、サービス信頼性の欠陥を参考に必要な項目をリスト化して、評価をより簡単にするために、極力シンプルにしました。
背景として、サイバーエージェントグループ全てのプロダクトを、我々がサポートすることはリソース的にも現実的ではありません。そこで、全体を俯瞰するためのデータや指標をそろえ、パフォーマンス向上やリスク管理における堅牢性の均一化を図るため「SRE成熟度評価」を開発しました。

── サイバーエージェントのような事業が多岐にわたる会社の場合、どこまでベストプラクティスが適用できるものでしょうか?

とても難しい質問ですが「ある会社やプロダクトでのベストプラクティスが、別の会社や別のプロダクトにおけるベストプラクティスにならない可能性」があります。なぜなら、同じ会社内であっても、その開発体制、事業規模、開発環境、エンジニアのスキルセット、想定されるトラフィックなどが全く異なるからです。

サイバーエージェントグループにおける、多岐にわたるプロダクトやサービスをフォローする中で、どのような技術的アプローチが事業を成功に導いたのか、あるいは技術的な負債の蓄積に至ったのかのナレッジを蓄積しています。「SRE Technology Map」や「SRE成熟度評価」を制作しているのもそのためです。

サイバーエージェントでは「これがベストプラクティスなので、このやり方さえすれば正解」というソリューションはカルチャー的に馴染まない気がします。

しかし、ナレッジをベースに類型化することは可能なので、事業規模や開発体制によって、インフラ構築や開発環境の最適化と再現性が実現できると、新規事業の立ち上げが迅速になり、その後の運用も円滑に行われることが期待できるのではと考えています。

時代の波を超えて自己成長できるエンジニアの素養

── 現在、バックエンドエンジニアやインフラエンジニア、SREを目指している学生に、キャリアアップのためのアドバイスがあればお願いします。

最近は、学生時代からSREを目指すエンジニア志望の方も増えてきていて、正直嬉しい限りです。ただ、前にも述べた通り「SRE」というロール自体、時代の流れで変わっていく可能性があります。少なくとも、我々が所属する組織が求められている役割は、数年後には別の形になっている可能性が高いです。

「インフラエンジニア」や「SRE」など、職種名やロールというカテゴリーはわかりやすく、それを目指す気持ちも理解できます。しかし、ロール名や職種名は、組織内で行っている業務内容を、周囲がわかりやすくするためにつけた便宜上の名前に過ぎません。そこに捕らわれ過ぎてしまうと「私はSREなので、SREとして評価される仕事しかやりません」となってしまい、チャレンジできるチャンスを逃してしまうばかりか、もっと大局的な技術やビジネストレンドの波に取り残されてしまう可能性すらあります。

重要なのは「どのような課題を技術で解決したいのか?」「どのようなアプリケーションを開発して、どんなインパクトを生み出したいのか?」という点だと思っています。

学生であれば「自分が好きな技術や得意なスキルをベースに、どんなエンジニアになって、どんな分野で社会貢献したいか?」を考えることから始めると良いかもしれません。

例えば、自分が面白いと思うサービスや日常的に使っているアプリケーションを模倣してモック開発してみる事をおすすめします。サイバーエージェントの新卒研修でとりいれている課題でもありますが、アプリケーションを1つ完成させる過程で、様々なことを習得できるのでおすすめです。例えば、クライアントアプリがサーバーとどのようにデータ通信しているのか、データベースはどのような構造でデータを保持しているのかを、高負荷がかかった時にサーバーはどのように冗長化しているのかを網羅的に知ることができます。

その過程で、パブリッククラウドやWebフロント、ネイティブアプリ開発など、自分が好きな技術分野が絞れるようになり、技術的にも更に深く掘り下げられるようになってくるはずです。

すると、初めは見様見真似で模倣していた技術やフレームワークやアーキテクチャも、次第に自分なりの根拠で説明できるようになってくると思います。そういった開発経験を積み重ねることで、技術的なトレンドの流れに左右されない普遍的な素養が身につくと思います。

また、業務のエンジニアリングでは、技術選定の根拠を明確にすることや、運用やスケールを考慮した際に、なぜその技術が効果的かを説明できる事が求められます。そんな時「このビジネス課題に対してこの技術でいきましょう」と自信を持って言えるエンジニアは頼もしいです。

サイバーエージェントではそんな若手エンジニアが多数活躍しています。そういった方々と一緒に働ける事を楽しみにしています。
 

この記事をシェア

オフィシャルブログを見る

記事ランキング

目指すのは、1,000名以上の技術者のハブになること。オフライン交流イベント「reCAver」運営の想い

技術・デザイン

サイバーエージェントには、各事業領域で蓄積された技術的知見を積極的に共有し、所属組織や職種を超えた技術者同士の交流促進を目的とする様々な取り組みがあります。その1つ、全社横断の技術者向けオフライン交流イベント「reCAver(リカバー)」は、コロナ禍で激減した技術者同士のリアルな交流を促進するため、若手エンジニアの提案によってスタートした取り組みです。誰でも気軽に参加できるイベントを目指して、職種や年次に関わらず興味を持てる技術トピックを毎回選定し、これまで全6回開催してきました。

「reCAver」を提案した運営チームリーダーの上岡と、第1回開催時から運営を担う川谷、高川に、開催のきっかけや継続的に開催するためのコツを聞きました。

Page Top