経済ニュースプラットフォーム「NewsPicks」で NewsPicks Stage. （以降Stage.）プロダクトを開発している西です。昨年11月より Stage. の開発チームに携わっておりまして、振り返りの意味もこめて簡単にですが開発基盤と開発手法の紹介をしようと思います。
Stage. について
NewsPicks Stage. （https://newspicks-stage.com） は経済・ビジネス情報に特化した動画配信サービスです。スポンサー企業と共同で業界の課題等をテーマに、主に大企業の意思決定者層向けの番組を制作して独自のプラットフォームで配信を行っています。動画をライブ配信するシステムがある一方で視聴者から了承を得た情報を収集し、スポンサー企業に提供するためのリード獲得システムも持ち合わせています。
Stage. プロダクトチームについて
Stage. プロダクトチーム（以降 Stage. チーム）は現状、NewsPicks（https://newspicks.com） とは別の基盤で動いています。エンジニアの数は4人未満で、PdMとデザイナーが1人ずつという少人数で動画配信システムやリード獲得システムを開発・運用しています。
開発基盤の話
インフラ構成図
ざっくりですが以下の通りです。
リアルタイムでライブ配信を行うために AWS Elemental MediaLive と AWS Elemental MediaPackage を使っていたりオンデマンド配信のために動画を AWS Elemental MediaConvert でエンコードして Amazon Cloudfront から配信したりしています。
Web アプリや API は Amazon Elastic Kubernetes Service (以降 EKS) 上で動いています。
Terraform でインフラや分析基盤は IaC 化されている
ステージング環境や本番環境はほぼ全て Terraform によって Infrastructure as Code（以降 IaC） 化されています。
他にも分析基盤である Snowflake のテーブル定義も Terraform で管理しています。
よって、新しく Join するメンバーはコードを追うことでインフラや分析用テーブルの全体像を把握することができます。
コンピューティングリソースは EKS で動いている
前述した通り、Web アプリや API のようなコンピューティングリソースは EKS 上で動いています。
EKS 上にマイクロサービスを構築しており内容は以下の図の通りです。
マイクロサービスのインフラレイヤーにおける以下の課題を解決する目的で Istio を利用したサービスメッシュの実装をしています。
- 各システムがどのような通信経路と流量でアクセスを許可するかしないのかをどうするか
- システムの一部で障害が起きているかどうかをどうやって知るか
- 障害が起きている場合にインフラレベルでの動作などをどうするか etc...
リリースサイクルを加速させるための CI/CD や E2E 基盤
Stage. チームはリリースまでのリードタイムを短くするためにトランクベース開発を実施しています。ローカルでコミットしたものはすぐに main ブランチにマージされ、GitHub Actions 上の CI/CD パイプラインでビルドやテスト、ステージング環境へのデプロイがされます。
ローカル環境や CI 環境の構築には Skaffold を利用しています。各マイクロサービスの Kubernetes 環境を準備することが非常に楽にできるようになるうえに、CI 上でも実行できるのでローカルで行っていたテストが簡単に再現できます。
E2E には Gauge や Playtest2、WireMock を利用していて、機能追加をするときはまず E2E を書くことになっています。
Argo CD を用いてステージング環境やプロダクション環境にデプロイしている
前述した通りローカル環境や CI 環境の構築には Skaffold を利用しています。CD（継続的デリバリ）時にはローカル環境で利用していた Helm チャートや値をステージングや本番環境用に調整し、 Helm テンプレートを通して連結させて Kubernetes のマニフェストファイルとして出力しています。その後に Argo CD がマニフェストファイルを読んでステージングや本番環境をデプロイします。
ステージング環境や本番環境のデバッグについて
Stage. アプリの挙動やパフォーマンスなどは DataDog で監視しています。EKS 上でマイクロサービスが動いており、それぞれのサービスでスパンを収集しています。スパンを収集することで分散トレーシングを利用することができ、DataDog の管理画面からエラーの特定をするのに捗っています。
分散トレージングについて
マイクロサービスは複数のサービス同士がAPIで連携していることで成り立っています。1つのリクエストだけでも複数のマイクロサービスが実行されることが常です。1つのリクエスト起因で始まった処理が複数のマイクロサービスを経て帰ってくるまでの経路やイベントを視覚的に追跡できるようにする仕組みが分散トレーシングです。これを使うことでエラーの追跡やパフォーマンス上のボトルネック調査などをマイクロサービス上でも実現できます。
開発手法の話
XP の実践とペアプログラミング
Stage. チームは XP（エクストリームプログラミング）を実践しています。チームでソフトウェアを極限まで早く作って早くリリースするためにはどのようにすればよいか日々振り返り、修正を積み重ねながら開発をしています。
「開発サイクルの改善スピードやチーム1人ひとりの学習機会の創出を加速させる上で必要なものに積極的なフィードバックとその場での疑問の表明は重要である」と思わされるのにペアプログラミングは役立っています。
ペアで開発しているとジュニアにとってはシニアの1つひとつの行動は新鮮なものが多く学びになります。そしてペアプロはおおよそ成長を促したい相手の手を動かすように設計されているので、次にどのように行動すべきか常に考えさせられ、間違えてもすぐにフィードバックをもらうことができたり、難しい課題も一緒になって考える時間を作ることができたりします。
開発をしているとプロダクトの構造について気になることが出てくると思います。ペアプロならその場で疑問を表明することで理解がすぐに深まる場面がとても多いです。なぜなら、お互いに同じ画面を見ていることもあって、ある程度お互いの中で理解しているコンテキストの差分が求めやすいからだと思います。（「これってAだと思ってたんですけどA'だったんですね！」というダッシュの部分を求めやすい（わかりづらいかも。。））
ユーザベースにおける XP の実践は以下の記事が詳しいので見てみてください！（NewsPicks では Stage. だけの体験です）
TDD の実践
Stage. プロダクトチームは必ずテストから書きます。
TDD を意識していて落ちるテストをまずコミットして main ブランチにマージし、そこから実装に移ります。
テストが仕様書であるとも言えるくらいにたくさんのテストが存在しており、リファクタリングや機能追加は安心して行えます。
TDD の実践やペアプロの詳細は以下のブログが詳しいです！（弊社のB2B SaaSであるスピーダのプロダクトチームと Stage. プロダクトチームは基盤や手法がよく似ています）
CDC について
Consumer-Driven Contract Testing (CDC) とは、マイクロサービスにおけるAPIの利用者側（Consumer）が利用先サービスに対してリクエストするオブジェクトのインターフェースを契約（Contract）として定義して、互換性が損なわれていないかをテストする手法です。
Stage. チームのマイクロサービス群には様々な Consumer から参照されているAPIが存在しており、そのインタフェースを壊さないためにも CDC の手法を通して保護しています。
以下は例です。
# GET /api/v1/publishedPrograms の CDC ## 配信予定の番組一覧の取得 -- success consumer: stage-web-bff * URL"/api/v1/publishedPrograms?limit=5"にGETリクエストを送る * レスポンスステータスコードが"200"である * レスポンスのJSONの"$[0].programId"が文字列の"11b28619-1861-4d34-b2de-bede9ea343eb"である * レスポンスのJSONの"$[1].programId"が文字列の"22b28619-1861-4d34-b2de-bede9ea343eb"である * レスポンスのJSONの"$[2].programId"が文字列の"33b28619-1861-4d34-b2de-bede9ea343eb"である
例では stage-api に含まれているCDCテストの1つで、Consumer として stage-web-bff が存在し、その Consumer が /api/v1/publishedPrograms?limit=5 をリクエストした場合はステータス 200 でレスポンスに programId をキーに持つオブジェクトが入っている配列が返ってくることが契約として示されています。これにより bff の実装を CDC に違反するインタフェースにうっかり変えてしまってもテストが落ちるので、Consumer が困るようなことは防ぐことができます。
CDC の詳細はメンバーが書いた以下の記事が詳しいのでぜひご覧ください！
まとめ
本記事では、NewsPicks Stage. プロダクトチームの開発基盤と手法について簡単に紹介しました。少人数のチームである Stage. では、リアルタイム配信を支えるインフラ構成や、Terraform を用いた IaC、CI/CD の実践により迅速なリリースを実現しています。また、XP や TDD の導入によって、開発の質を高めつつメンバー間の知識共有を促進しています。
これらの取り組みを通じて、Stage. は技術的な側面だけでなく、チームの成長や開発文化を醸成する環境を整え、より良いプロダクトを提供することに努めています。今後も引き続き、開発基盤や手法の改善に取り組んでいきます。
