見出し画像

noteのエンジニアチームが2023年に向けて挑戦する、重要課題7選

noteは2014年のリリース当時から、サービスの根幹にある「クリエイターの街」を実現するために開発を続けてきました。昨年12月には会社が上場をし、クリエイターのための世界を創っていく大きな一歩を踏み出すことができました。

しかし、noteがミッションとして掲げている「だれもが創作をはじめ、続けられるようにする」を達成するためには、まだまだ立ち向かうべき課題が多く、実現できていない施策も山のようにあります。

今回の記事ではそんなnoteが抱えている課題の一部を公開いたします。クリエイターの街をテクノロジーで作り上げていく、noteエンジニアの想いを感じとっていただければと思います。

▼過去の課題まとめはこちら


1:大規模なRuby on Railsコードのリアーキテクチャによる品質向上とパフォーマンス改善

noteのサーバーサイドはRuby on Rails(以下、Rails)で開発しています。昨年はRails6への移行を完了。また、Packwerkによるパッケージ分割をコード全体の35%に実施、管理画面のRails Engine化、ディレクトリ構成のルールを制定、Rubocopの全適用など、生産性向上の施策を多数推進しました。

一方で、2022年末は2021年末と比較してコード行数が40%近く増加。開発者の仲間が増えて新規企画を進められるようになった反面、ドメイン間の依存関係やデータ構造の整理、コーディング規則などを洗練させ、負債や認知負荷を必要以上に増加させない仕組み化が引き続き重要です。

また、実行時のパフォーマンスを改善し表示速度を向上させていきます。2022年にはいくつかの主要APIに手を入れ高速化を達成しました。今期は引き続きAPIの改修に加え、YJITの導入により高速化されたRuby 3.2の導入やMySQL 8系へのアップグレードも企画しています。

そして、昨年に引き続き、今年もコミュニティへの支援に力を入れていきたいと思っております。

課題

  • 巨大なRailsコードベースと開発生産性の両立

  • データ量やトラフィックが増えてもパフォーマンスを低下させない事

  • ミドルウェアを更新し、基礎的な実行効率を上昇させる事

施策

  • モノレポ化

    • Packwerkを用いたコード分割

    • Rails Engineによるドメイン分割

  • サーバーサイドのCPU変更などによるパフォーマンス向上

  • RDSのバージョンアップ / 分割

  • CI/CDの移行検討

2:フロントエンドのリアーキテクチャ。デザインシステムとのさらなる連携

2021年末にフロントエンドのNuxt.jsへの移行が完了。大部分がNuxt+SSRで稼働し、安定期に入っていますが、複雑化するフロントエンド要件やパフォーマンス要件の充足、高い開発者体験の実現を達成するため、Next.js をベースとした第三世代への移行が進行中です。並行してRSCの技術検証も行なっています。

先行して、エディタ機能をProseMirror + Next.jsに完全移行しました。また、デザインシステムの拡充をReactベースで実施しデザイントークンの整備などを進めたことで、開発チーム内でのデザインの揺れが吸収される見込みです。

これらのフロントエンドのリアーキテクチャに今年は力を入れていく予定です。Nuxtへの移行の際と同様に、ビッグバンリリースを避けて少しづつ検証と実運用を繰り返していきます。また、monorepoへの集約による開発効率化も同時にチャレンジしていきます。

課題

  • 巨大なコードベース

    • ビルドや開発にかかる時間の肥大化

  • フロントエンド関連のリポジトリ数の増大

  • 開発人数が増えたことによるチーム間の連携

施策

  • Next.jsやSvelteを使ったアプリケーションの分割

  • Turborepoを用いたモノレポ化

  • デザインシステムのさらなる強化 / 連携

3:データに基づいた意思決定ができる組織。使われるデータ基盤へ

noteでは大量のデータを処理するデータ基盤へ継続的に投資を行っています。2022年はDWHとして新規採用したSnowflakeを軸としたアーキテクチャへ刷新。分析に用いるクエリの速度、処理量が大幅に向上しました。速度が向上したことにより、開発チームでのデータ活用を進めることができ、プロダクトや社内業務に関わる多くの意思決定の迅速化に寄与しました。

よりデータドリブンな企業になっていくためには、「使われるデータ基盤」を引き続き目指す必要があります。データに気軽に触れられるように基盤改善やBI環境を構築し、欲しいデータにすぐアクセスできるデータ基盤の構築を引き続き進めていきます。

また、分析業務だけでなくnoteのサービス内で大規模集計を要する機能をSnowflakeでの高速処理に置換していく予定です。2022年のまとめレポートの作成機能はその第一号でした。処理を高速化し、ユーザーの皆様に価値をデリバリーする速度を上げていきます。

課題

  • 過去に実装したアーキテクチャによる技術的負債

    • 作業的コストと金銭的コストの増加

  • データ活用の浸透

    • 分析用途だけでなく、アプリケーションでの活用

    • エンジニア以外の他部署でのデータ活用

施策

  • データをSnowflakeに集約し、サイロ化を防ぐ

  • Lookerを用いたデータ活用の強化

  • 新アーキテクチャへの移行

  • 集計バッチなど、Railsで行っている大規模データの集計などをデータ基盤で行うようにする

4:noteに必要な機械学習システムを仕組み化し、幅広いクリエイターに価値を提供

昨年はホームタイムラインを一新し、クリエイターがより作品を多くの人に届けられるようになりました。ユーザー属性のデータ分類を適切に行ったことで、レコメンドの強化も行うことができました。また、ABテストのプロセス整理やツール開発を行ったことで、開発チームの機能開発における意思決定が定量的にできるようになりました。

今期ではさらにML基盤の構築を強化し、レコメンド精度の向上も行っていく予定です。また、検索基盤との連携も強化し、クリエイターの作品をさらに多くの人に届けるようにしていきます。

課題

  • おもしろい記事を発見できる仕組みや出面が少ない

  • コンテンツ数とユーザー数の増加による多様化

施策

  • ユーザの状況に合わせたホームタイムラインのレコメンドパターン追加

  • MLを活用したレコメンドの精度向上

  • 検索基盤の移行 / 検索基盤を軸にしたコンテンツマネジメントの仕組みの構築

    • 社内ツールも検索基盤に移行し扱いやすくする

5:アプリの体験向上。開発速度を加速させる基盤開発への注力

 iOS / Androidともに負債改修には尽力しており、2022年にはそれぞれのチームでObjective-CとJavaのコードをゼロにすることができました。また、モバイル開発メンバーの増加や専任のバックエンドエンジニアやデザイナー、PMがチームに加わったことで、開発に割けるリソースが増大しました。

将来的なさらなるモバイル開発の躍進につなげるためにも、今期は基盤開発に注力し、開発者体験を向上させていきたいと思っております。

課題

  • iOS

    • コードの肥大化によるビルド速度の悪化、Xcodeの性能低下

    • コードやアーキテクチャの複雑化による開発者体験の低下

  • Android

    • 様々な機能追加によって役割が曖昧なコードが増加

    • 過去から残っている技術的負債

施策

  • iOS

    • マルチモジュール化

    • XcodeGenからSwift Package Managerへの切り替え

    • Storyboard / xibファイルをコードでのレイアウトへ刷新

  • Android

    • 不要なコードの削除、ファイルの統一

    • 全画面のアーキテクチャの刷新

    • JetpackComposeのサポート

6:柔軟かつスケーラブルなインフラの構築を目指したEKSへの移行

noteのインフラを徐々にコンテナベースでの稼働に切り替えて、Kubernetesの基盤に載せ替えていく長期プロジェクト。2022年から引き続き今年も推進していきます。

2022年にはバッチ処理の一部やステージング環境、noteのサブシステムの一つである検索基盤をEKSでの稼働に切り替えました。少しづつ運用ノウハウを蓄積し、2023年中に大部分のサービスをコンテナでの運用に切り替えていく予定です。ユースケースに応じてECSも併用して利用しています。

また、載せ替えるだけでなく、コンテナ基盤のアジリティを活かしたインフラ構築施策や、新規機能、疎結合化を展開していきます。そのため、アプリケーションサイドのエンジニアやDevOpsエンジニアとの連携の機会が増える見込みです。

課題

  • EC2上で動作するモノリシックなサービス

  • デプロイメントが複雑化している

  • 独自ドメインのSSL証明書管理プロセスの安定性

施策

  • WebアプリケーションをEKS(Kubernetes)上で安定稼働させる

  • コンテナを用いたデプロイパイプラインを整備し、安定的なアプリケーションのリリースサイクルを実現する

  • 独自ドメイン機能を提供するインフラサービスの刷新

7:早期に不具合を発見でき、分析による再発防止する品質保証の仕組み構築

昨年に立ち上げたQAチームはテスト技術、運用整備、文化醸成など様々なアプローチからnoteの品質向上の施策を企画し、実施してきました。テストカバレッジ向上、E2Eテストの効率化とコスト削減、障害対応フローの確立、ポストモーテム会の定期実施、リリースフロー整備など、スピード感を持って推進しました。

QAチームはゼロイチを終えて今年さらなる飛躍を遂げるフェーズに来ています。今年は不具合の分析や仕様段階でのバグ発見、そのための品質指標の定量化など、さらに一歩進んだ施策に取り組み、本番リリース前の問題発見に重点的に取り組んでいきます。

noteのQAに関する種々の試みとその結果は、定期的にnoteでも発信をしていく予定です。

課題

  • 不具合が発生した際に原因と解決策が分類されておらず、Next Actionsに繋がらない

  • 開発者毎のテストの粒度・考え方が異なるため品質が属人化している

  • 不具合がE2Eテスト時に発覚して、修正に多くのコストがかかる

施策

  • シフトレフトの実現

    • 仕様検討段階からQAチームが加わり、不具合になりそうな箇所を事前に発見する

  • 内部品質の強化

    • 単体テスト・結合テスト・E2Eテストなどを型化して、エンジニアの意識を揃える

    • 発生した不具合を分析し、note全体の不具合パターンを可視化し、不具合発生の抑制に利用する

  • 社内外への積極的な発信を行い、全社員の品質意識の向上及び品質文化の醸成を行う


▼技術記事がさらに読みたい方はこちら


みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!