17年間の技術負債にどう対処した？ 負債の可視化からAWS全面移行まで、事業を支えてきたAmebaシステム刷新プロジェクトを振り返る

サービス開始から17周年を迎えるAmeba。事業とともに肥大化したシステムはアカウント数200以上、VM数6000以上、リポジトリ数は800を超える。サイバーエージェントはこれらの老朽化した大規模システムをどう刷新し、技術課題を解決しているのか。3月24日に開催された「CyberAgent Developer Conference 2022」では、Amebaが抱える課題設計、事業戦略への転換、技術選定、効果検証など、その全体像との向き合い方について、Ameba開発責任者である岩永翔氏が語ってくれた。

• keyboard_arrow_down アメーバブログ誕生から17年。Amebaの歴史を振り返る
• keyboard_arrow_down この先10年気持ち良く開発できる状態に。Amebaシステムの刷新プロジェクトを立ち上げる
• keyboard_arrow_down AWS全面移行までの意思決定プロセス。実現可能性の精度を上げるためにしたこと
• keyboard_arrow_down 共通基盤AmebaPlatformはどのようにつくられたのか。検証から実装までの歩み

最初に語られたのはAmebaの歴史。Amebaはアメーバブログを中心とした様々なメディアサービスが集まるプラットフォームである。Ameba事業の歴史は古く、2004年のアメーバブログ誕生から、アメーバピグローンチ、事業のスマホシフトなど、現在に至るまで17年の歴史を重ねてきた。

「現在のサービスのフェーズとしては成熟期で、安定したプロダクト運用ができています。これからは、さらに盛り上げる再生期に入っていきたいと考えています」

17年の歴史を持ったプロダクトには古い機能やシステムが多く残っており、大きな技術負債を抱えている。プライベートクラウドやパブリッククラウドのアカウント数は200を超え、VMのカウンターは6000超、アプリケーションのリポジトリは800を超えていると、岩永氏は語る。

「成長期と比較して、今は縮小した組織として動いています。大人数でとにかく新規機能を立ち上げる時代から、プロダクトを少数精鋭で磨き上げる時代に入ってきました。一方で、これまで積み上げてきた膨大なシステムの保守も継続しているため、1人あたりが見る範囲やカバレッジがかなり重要になってきたと感じています」

ほかにも、これまでのチーム体制の変遷からも技術選定プロセスに統一性がなく煩雑だったこと、それらの煩雑な技術ドメインを現在はワンチームで見る認知負荷が高いことも課題として挙げる岩永氏。さらにAmebaのスマホシフトによりプロダクトを統合したことから、システム基盤が多重に存在しており、新規開発のハードルが高くなっていると明かす。

こうした技術課題を解決し、市場の変化、サービスや組織の変化に合わせてシステムの底上げを行い、市場が求めるスピードで開発できる組織をつくることを直近の目標に置いた。そこで、Amebaシステムの刷新プロジェクトが立ち上げられた。

システム刷新の技術戦略を立てるにあたり、まずはAmebaのビジョンを基に、技術戦略で目指すべき目標を定めた。そこから具体のプロジェクトに落としていく。

Amebaのビジョンは「100年愛されるメディアを創る」。それを踏まえて、事業が抱える課題に対してどうシステムでアプローチができるかを考えたと語る岩永氏。

「事業部長とPM、エンジニアの責任者で話し合い、『Amebaがこの先、10年開発を気持ちよくスムーズに続けられる状態を目指す』ことを状態目標にしました」

その状態目標を達成する成立条件を細かい粒度まで洗い出し、グルーピングしながらまとめていった。その結果、以下の3軸をミッションとして刷新プロジェクトを進めることとなった。

• ・Amebaが提供したい価値に沿ったサービスとシステムサイズになっている
• ・Amebaとして統合されたアーキテクチャを軸にシステムを再構築できている
• ・負債の可視化が仕組みとして機能し、事業判断の枠にあげられる状態になっている

3つのミッションに対し、どのようにアプローチしていくか。さらに詳しく説明された。

1. Amebaが提供したい価値に沿ったサービスとシステムサイズになっている

1つ目の課題としては、前述の膨大になったシステムと認知負荷の増加である。そして、Amebaが提供したい価値とシステムで提供している価値にズレが生じていることだ。

それらを解決するアプローチとしては、重複しているシステムの統廃合やID体系・認証認可の仕組みを一元化すること、スマートフォンプラットフォームの機能の撤廃が挙げられた。

2. Amebaとして統合されたアーキテクチャを軸にシステムを再構築できている

続いてのミッションは、まずバラバラで負荷が高かった技術選定をメディアの価値を合わせてシュリンクし、利用する技術を制限する。

さらに、デベロップメントとCI/CD、オペレーションの各レイヤーを共通化した基盤をつくり、開発フローを統合するベースをつくるというものだ。共通ライブラリやインフラ環境も用意する。

具体的なアプローチとしては複数存在していたGCPやオンプレミスなどをAWSに統合する。狙いとしては技術選定をあえて制限して開発フローを共通化し、AmebaPlatformと名付けた。既存システムはGoで再実装して移行した。

「新しくAmebaに参画するエンジニアの学習コストを軽減し、保守負担を軽減する。学習効率の向上と開発効率の向上、人材の流動性の向上などを狙っています」

3. 負債の可視化が仕組みとして機能し、事業判断の枠にあげられる状態になっている

このミッションの背景として、「大規模刷新を定期的にやるのはプロダクトとしては健全ではない。大規模刷新にはそれだけ大規模な投資判断とそれに伴うリスクが存在する」からだと岩永氏は語る。大規模刷新を推進していく上での不確実性や、事業の負債をきちんと見積り、小さい単位で返却できる状態が健全だと考えているからだ。

そのためには、事業を運営する側とエンジニア側が議論でき、かつ、計測可能な指標が必要となる。そこで、システムのケイパビリティと開発組織のケイパビリティの2軸で達成することを目標とし、継続的に維持できる状態を目指す。

システムのケイパビリティに関しては、システムのデリバリーパフォーマンスをFour Keys 指標で計測し、可視化している。開発組織のケイパビリティについては、Ameba固有の開発の重さに対して、バリューストリームマッピングで開発の重さを分析・可視化するアプローチに取り組んでいる。さらに基本的には、全員の工数やタスクをある程度見える化し、新規開発と運用の保守比率なども追っていく。

「それをエンジニアリングの裸感ではなく、数字として経営に上げられる状態に持っていく。健全なプロダクト運用ができるようにしていきたいと思います」

プロジェクトの立ち上げに関して、岩永氏は「事業が提供したい価値にアジャストするように、システムサイズを定め、シンプルにしていく。その後、今のシステムを共通基盤にマイグレーションして、技術の標準化と共通化を進めて、開発しやすいシステムへの全面移行を実施していく」とまとめた。その結果は、計測可能な指標で振り返ることを徹底していくという。

刷新プロジェクトを立ち上げ、実現可能性の精度を上げるためにやることのまとめとして、岩永氏は以下の3つを挙げた。

• ・事業目標から技術戦略や軸を作り、ゴール設定は適切な状態目標と計測可能指標で行う
• ・刷新における狙う的とその実行の意思決定までは事業責任者と共に歩み、一気に決める
• ・事業計画と並走した刷新計画で打ち手を考える

インフラをAWSへと全面移行するためには巨大な投資が必要。岩永氏は「エンジニア目線での理想論だけではなく、経営的な観点でも判断する必要がある」と強調する。

「それらを判断する観点としては、事業計画はどう捉えているか。今回の刷新に関わるコストがどれくらいで、刷新で得られる成果はどれくらいか、フラットに洗い出す。それらをオンプレミスをつくっているエンジニアの責任者も同席の元、役員はじめ事業責任者、PM、エンジニアで議論を重ねました」（岩永氏）

刷新に向けて、Amebaで現存する200以上のアカウント全ての移行計画を立てて、そのコストを試算した。これは前段に挙げたシステムのシュリンク、新しい基盤に載せる刷新があり・なしのパターン、AWSに全面移行があり・なしのパターン全てで算出している。

コスト試算の観点としては、インフラの固定費をAWS、GCP、プライベートクラウドなど全て洗い出した。刷新途中と刷新後の開発人件費・運用人件費も試算し、意思決定の材料にした。

また、基本的にはAWSに移行することによってマネージドのメリットを享受できると考えているものの、現行のプライベートクラウドで実現した場合のコストも試算した。

「具体的にはAmebaが求めるマネージドのメリットに対してDesignDocsを作成し、オンプレミスに携わるエンジニアと議論を重ね、自作マネージドをつくる場合の実現要件・実現手法・開発や維持コストを試算。主にComputeとDatabeseを中心に議論を進めて、判断の材料にしました」（岩永氏）

試算の結果、現状新規の開発より運用保守に割く時間の方が多いことがわかった。さらに試算の過程において、半年にわたったコスト構造のテコ入れを実施し、既存のインフラ構成、アプリ構成、開発体制を見直した。そこから、AWS移行によって保守比率やインフラベース費が削減できるといった見通しが得られ、AWSに全面移行する意思決定が行われたのである。

最後にこれまで2年を費やし、進められてきたAmebaシステム刷新プロジェクト全体の歩みが紹介された。

その中でも、AmebaPlatformをAWSに移行するにあたって、どのように共通基盤をつくってきたのかがピックアップされた。

まず実施したのは、初期コンセプトの検証。Kubernetes (K8s)で集約したり、AuthZ認可の統合をしたりなどをどう実現できるか、各自コンセプトを持ち寄り検証した。

初期コンセプトができたら、ビジョンとミッション、それらを達成する目標とそれぞれのプロジェクトの進め方を決める。

「そのとき最初にやったのは、Amebaプラットフォームおよび移行先の認可基盤と移行用GatewayのMVPリリース。MVPをリリースする目的は、AmebaPlatformを早く実装して開発者に使ってもらい、早くフィードバックを得ることです。既存のデータセンターからAWSに移行する効率化のために、新規実装に必要な共通機構の提供を行いました」（岩永氏）

MVPをリリースした後の新規開発案件に関しては、全てAmebaPlatform上で実装してもらうようにし、フィードバックと追加実装するサイクルを繰り返す。フィードバックされた情報をもとに、より良い開発体験と開発効率向上に向けた改善が行われることが追加実装の目的だ。実際に、これまで負荷試験環境やObservabillty、ログ基盤の実装が行われている。

「AmebaPlatformは、AWS上でEKSを利用して構築されたkubernetes Cluster群と、それを利用するためのテンプレートや統一されたCI/CDなどの仕組み、それらの共通機構を指しています」（岩永氏）

AmebaPlatformの現況についても紹介された。現在、27マイクロサービスが移行して稼働しており、本番リリース済みサービスは23個。マイグレーションで実装中のアプリケーションについては、Four Keys指標のリードタイムにおいて、刷新前後で7倍程度の改善が出ている。初速は好調のようである。

刷新でFour Keys指標に改善が見られたものの、foukeysのパフォーマンス分類でいうと、まだハイパフォーマーなので改善の余地はあると岩永氏。計測のカバレッジや運用工数比率の削減など、システムの並行稼動も多いため、まだまだ改善は続くと語っている。

「ブログ本体のシステム刷新はまだ始まったばかり。まだ最低限の機能しか起動していないので、刷新プロジェクトと並行して、課題を潰すためのプロダクティビティに向き合い続けていきたいと思います」

最後に岩永氏は、Amebaが達成したい「100年愛されるメディアを創る」を、システムで後押ししたいと宣言し、セッションを締めた。

セッション動画

文：馬場美由紀