朝日新聞デジタルWEB版で開発サイクルを高速化していく話【朝デジ システム刷新STORY2】

今回のテックブログは、朝日新聞デジタルのシステム刷新プロジェクトにおける「システム再構築」と「開発サイクル高速化」のお話です。様々な課題を抱えたシステムを、どのように早く・安心して・継続的にサービス改善できる環境へと生まれ変わらせたのか？「PLASMA」プロジェクトメンバーの中村さんに、その取り組みを紹介してもらいます。

はじめに

こんにちは、朝デジ事業センター・プラズマチームの中村です。

今回は、WEB版朝日新聞デジタル（以後、朝デジ）のシステムをどのように再構築して開発サイクルの高速化に取り組んでいるのか、執筆したいと思います。

プラズマプロジェクトの概要やアジャイル（スクラム）開発についてはチームリーダーの西島さんが記事にしているのでご覧ください。

従来の開発フローの課題感

従来の朝デジシステムは、以下のような課題を抱えていました。 

リリースしにくいシステム構成
    - コードのバージョン管理がされていない
    - 技術スタックが古いものになっていた
    - システムの拡張性が低く他のシステムとの連携が取りにくい

テスト・デザイン確認のフローが確立されていない
    - 自動テスト環境が整っていない
    - デザイナーと開発者、運用者が議論できる環境が整っていない

このような課題を解決できるように、早く・安心して・継続的にサービス改善できる環境を構築することを目的にシステム構成の変更と継続的インテグレーション（CI）と継続的デリバリー（CD）環境を構築しました。

具体的にどのような取り組みをしたのか説明していきます。

システム構成について

今までシステムの拡張性に課題を持っていたため、一枚岩だったシステムをサービスごとに分割してサービスごとにシステム開発できるように設計しました。これは、よくマイクロサービスアーキテクチャと呼ばれています。

このマイクロサービスアーキテクチャによく共通する特徴として、提唱者のジェームス・ルイスとマーティン・ファウラーは以下の特徴を挙げています。

・サービスによるコンポーネント化
・ビジネス機能を中心に編成
・分散統治
・分散型データ管理
・インフラストラクチャの自動化
・失敗のための設計
　　　　　　　出典：Microservices (James Lewis, Martin Fowler)
　　　　　　　https://martinfowler.com/articles/microservices.html

特徴に完全にそぐわない部分もありますが朝デジシステムでの対応関係をまとめてみました。

・サービスによるコンポーネント化
朝デジのWEBフロントシステムをフロントエンド・バックエンド・認証/DBと大きく３つのサービスにコンポーネント化しました。

・ビジネス機能を中心に編成
開発者だけでなくデザイナーや運用者も含めた部門の枠を超えたチーム構成で朝日新聞デジタルを編成しています。

・分散統治
フロントエンド・バックエンド・認証/DBと各サービスで独立した開発言語とCI/CD環境を用意しています。
それぞれのソースはGitHubで見える化して参照可能です。

・分散型データ管理
プラズマチームの範疇を超えるのですが社内の別チームで記事情報APIや認証機能の見直しを行なっており、サービス間で連携しやすい管理方法に移行しています。

・インフラストラクチャの自動化
サービスごとにCI/CD環境を用意しました。どのような仕組みで自動化しているかは次のセクションで詳しく紹介します。

・失敗のための設計
こちらはまだ対応できていないです。サービスごとのエラー情報の見える化や社内向けにシステムの障害情報をダッシュボードにまとめるなどは今後の課題にして取り組む予定です。　

このマイクロサービスアーキテクチャを採用することで、各サービスごとに独立して開発することができるようになりました。
将来的には朝日新聞デジタル全体（WEB・アプリ含めて）のシステムで最適なコンポーネントの分割ができると良いなと考えています・・・

フロントエンドは Node.js と Express でコンテナを構築し、バックエンドはGo言語でgRPCコンテナを構築しています。コンテナ間のやりとりはProtocol Buffersで定義しています。

gRPCサーバーを本番運用する際にはまった点や負荷試験を実施した知見などは今後ブログで発信していきます！

CI/CD環境の改善

テスト・デザイン確認のフローが確立されていない課題を解決するために、日々の開発や社内で協業がしやすくなる継続的インテグレーション（CI）と継続的デリバリー（CD）環境を用意しました。

 CIを実行するツールにはGitHub Actionsを利用しています。GitHubのプルリクエストを出した際に自動でリント・テスト・Storybookビルドを実施して結果をGitHubで確認しながら開発しています。

以下はGitHub Actionsのワークフローの例になります。

また、課題を感じていたデザイナーさんとの協業にはStorybookを利用しています。

Storybook: Frontend workshop for UI development

これによって様々なケース（状態）でのコンポーネントの変化が確認可能になりデザインが想定通り表現できているかを開発者からデザイナーさんにすぐに提示することができるようになりました。

CDを実行するツールにはAWS CodeDeployを利用しています。Blue/Greenデプロイというリリース方法をとり安全にリリースできるような仕組みづくりをしました。

リリースが開始したら新タスク（Green環境①）を作成して全体の10%のトラフィックをGreen環境にルーティングします。特定の時間が経過したら旧タスク（Blue環境②）に流している残り90%のトラフィックを新タスクに振り分けます。
デプロイから一定の時間は旧タスク（Blue環境②）が稼働しているので即時にロールバックが可能になっています。
この取り組みにより、リリースに心理的な余裕が生まれリリースハードルが下がりました。

取り組みの成果の振り返りと課題

ここまで朝デジの開発サイクルを高速化するためにシステム構成とCI/CD環境をどのように変更しているのかを紹介してきました。
取り組みによって生じた３つの成果と課題をまとめました。

リリース回数

システムをフロントエンド・バックエンドで並行開発して安全にリリースすることが可能になったため、本番環境へのリリースを週3回以上は実施できるようになりました。
現在は1日1回以上、本番環境にリリースすることを目標に日々開発しています。

デザイナー・運用者との協業

Storybookを利用することでデザイナーさんとのコミュニケーションがとりやすくなりました。今回のブログでは触れられなかったのですが、プルリクエストごとに開発環境のコンテナを作成できる仕組みを構築して全体のデザイン確認をできるようにしたのですが、その点は非常に喜んでもらえたので嬉しかったです。
今後は、運用者との協業面で分析基盤の充実に取り組んでいく予定です。

開発者体験の向上

自動テストや安全なデプロイ環境が整うことで開発者が安心して継続的なリリースが可能になりました。
技術スタックを標準的なWEBの技術に刷新することができたためプロジェクトへの参加障壁が低くなり、社内や社外の優秀な人材を集めやすくなりました。
今後も社内のテスト文化普及や組織全体での技術の共有・向上を継続して行いたいです。

終わりに

ここまで長文にお付き合いいただきありがとうございました。

早く・安心して・継続的にサービス改善できる環境を構築することは、システム開発のはじめの１歩だと考えています（リプレイスは大変でしたが・・・）。
今後は、技術的にもよりチャレンジングな取り組みをして、朝日新聞デジタルWEB版を楽しんでいただけるように改善していきたいです。

 

最後に、朝日新聞社では、朝日新聞デジタルを一緒に開発していくエンジニアを募集しています。ご興味のある方は Wantedly から気軽にお声がけください！

株式会社朝日新聞社の会社情報 - Wantedly