こんにちは、AmebaLIFE事業本部の菅原です。
おかげさまでAmebaはサービスローンチから20周年という記念すべき年を迎えました。
20年となるとインターネットサービスでもかなりの老舗のサービスになります。20年と言われると内部はレガシーの塊だと思われてしまっても仕方ないですが、実際の開発ではそういうわけでもなく比較的モダンな開発環境が揃っている現場でもあります。
今回はそんなAmebaのフロントエンド技術スタックの現在地をお伝えできればと思います。
Amebaのフロントエンド技術スタック
現在Amebaでは以下のような技術スタックで概ね構成されています。
- フロントエンド
- React
- Next.js
- Storybook
- TypeScript
- バックエンド
- Node.js
- Express
- テスト
- Vitest
- Autify
- インフラ
- fastly
- Amazon Elastic Kubernetes Service (Amazon EKS)
- AWS Lambda
- Amazon S3
- 監視
- Datadog
- SpeedCurve
- その他
- rspack
- vite
- turborepo
- ESLint
- prettier
Amebaのフロントエンドエンジニアは、インフラ基盤やデータベースの管理はしませんがそれ以外のところでブラウザ上で配信されるものの全てに責任を負っています。 ほぼすべてのUIはReactコンポーネントで実装されており、スタイルの実装においてはCSSフレームワークの利用は無く、内製のSpindleコンポーネントやCSSをそのまま書いていることが多いです。 配信するコンテンツのパフォーマンスをfastlyのCDNを用いたキャッシュを活用したコンテンツ配信、パフォーマンスモニタリングなどを利用して、品質の向上に力を注いでいます。 また、開発環境面では rspack や vite など随所に導入しておりビルド速度などの生産性向上に意欲的に取り組んでいます。
デザインシステム
Spindle（スピンドル）は”Amebaらしさ”を一貫してユーザーに届けるための仕組みです。”Amebaらしさ”がユーザーに届き、共感が生まれることで、サービスの信頼へとつながります。 https://spindle.ameba.design/
Spindleを軸としたUI開発が行われており、汎用的なUIデザインはSpindleのコンポーネントとして実装・公開されています。 Amebaはブログを始め、数多くのドメインを展開しています。デザインシステムによってAmebaが提供するサービスがドメインやチーム、開発者をまたいでも一貫して品質が高く、統一された意匠をユーザーに届けることができるようになっています。 フロントエンドエンジニアは、@openameba/spindle-ui で提供されたコンポーネントを活用して多くの機能の実装を日々行っています。
Figmaの活用
Figma Dev Modeはもちろんのこと、コンポーネントライブラリ(spindle-ui)に合わせたコード生成や細かいプロパティごとの単位の調整したCSSの出力するFigma Pluginも内製しております。 またデザインに関するコミュニケーションもFigmaのコメント上でフロントエンドｘデザイナーの連携も活発に取れています。 このようにUI開発においては最大限Figmaを活用しています。
システム運用
オンプレからの完全脱却
Amazon Elastic Kubernetes Service (Amazon EKS) の採用により、オンプレミスの環境から脱却したモダンなインフラ構成を構築しました。 オンプレ時代はコンポーネントごとにインフラの構成が違ったりしてキャッチアップにコストが掛かっていたのをこのタイミングで既存のアプリケーションはもちろんですが、新規でアプリケーションを構築する場合もAmebaで提供するサービスはAmeba内で標準化されたプラットフォームをもとに配信されるようになりました。 また、インフラ環境はコードですべて管理されており、AWSリソースにはterraformをKubernatesのマニフェストに対してもフロントエンドエンジニアが容易にメンテナンス可能になっており、インフラの細かな最適化も簡単に行えるようになっています。 これらによって、これまでの歴史で積み重なった多種多様なアプリケーションのデプロイフローやインフラ環境が統一され、どのシステムに対しても環境差異による認知負荷を削減し、ストレスフリーで運用しやすい環境を築き上げることができました。
モニタリング
システムの監視にはDatadogを利用しています。 システムメトリクスを網羅的に見るDashboardも整備されており、新規コンポーネントが生まれた際も簡単にモニタリング開始できるようになっています。
他にも、インシデントマネジメントもDatadogを活用しています。お問い合わせや監視アラートがなった場合はSlack上でうまくDatadogのIncident Managementとが連携され、コミュニケーションのログやポストモーテムまでスムーズに障害のハンドリングができるようになっています。 SpeedCurveも利用しており、Core Web Vitalsを軸にしたメトリクスの監視やモニタリング値からの改善と改善結果のフィードバックにつなげています。
CI/CDワークフロー
長い歴史上 Circle CI や Jenkins などさまざまなCI/CDツールが使われてきましたが、昨今 GitHub Actions の登場と開発コード管理には GitHub を用いているのも相まって CI/CDワークフローには GitHub Actionsを全面的に採用するようになりました。 インフラ環境の標準化により CD のワークフローも統一され、開発メンバーのだれもが簡単で安全にオペレーションを行えたり、新規プロジェクトを立ち上げる場合も横展開すれば容易に環境構築ができるようになっています。 また、多くのリポジトリではトランクベースでの開発が採用されており、ブランチマージまでのリードタイムが最小になるべく運用されています。 これを実現するためにテストの自動化も重要視しており、最新のプロジェクトではUnit Testのカバレッジでは90%を超える水準で運用されていたり、そこまで高くなくとも70%前後のカバレッジをコミットラインとして運用することによって、デプロイの信頼性を保証した運用ができるようになっています。 テストカバレッジは Coveralls と連携され、モニタリングしやすく運用しています。
チャレンジ環境
システムの規模も数も大きい Ameba ですが、その分チャレンジングにできるissueを作りやすく、技術者としては自分の技術力を活かせる機会に恵まれています。 事業開発をメインでは行いながらもシステムに対してのコミットへの裁量は大きく渡されており、技術的チャレンジに対して歓迎する文化も根付いている組織風土になっています。内定者のうちから大きな成果を上げてくれているのには非常に助かっており、この場を借りて感謝をお伝えします。
最近導入した新しい技術 / 行ったチャレンジ
- レガシー環境からモダンな環境への技術刻新
- webpack → rspack への挑戦
- アクセシビリティーの継続的改善
- 要求整理から実装まで手がける内定者バイトのメルマガ改善
- CodeRabbitによるAIを活用したレビュー
次のチャレンジ
開発比率でいうと80%くらいはモダンな環境で開発できていますが、まだまだレガシーなコードや開発環境は存在しています。それらを問題解決しながら、新しい構築に移行していくことが重要だと考えていますがまだ道半ばな状況でもあります。故にチャレンジしたいことは絶えず、ここに今年やっていきたい挑戦のいくつかを特別に公開してみましょう。
故きを温ねて新しきを知る
Amebaでの開発をしていると温故知新という言葉がよく脳裏によぎります。 20年という歴史の中で、様々な人やシステムが残してくれた資産は、今使っていただいているユーザーに多くの価値を提供しているだけでなく、今開発しているわたしたちエンジニアにとっても多くの学びを自分自身の経験としてもたらしてくれています。 その時々に行った技術選定、あるいは技術に限らない意思決定の産物を今いるわたしたちが見て、背景を考察して、次の意思決定につなげるというプロセスが、技術組織の成長に多大な影響を与えていると日頃から感じています。 今ある技術が最新であれ明日にはもう劣化を始めています。とくにフロントエンドは移り変わりが早いため顕著に打撃を受けてしまいます。 そんな取り巻く環境の中でもわたしたちAmebaのエンジニアは絶えず良いプロダクトを提供し続けるためにも、現状うまく行っているアーキテクチャに甘んじず常に新しい可能性を模索し続け、今チーム内で標準化された技術も常に変化を加え続けていきAmeba標準を進化させ続けています。