「オンプレミスを踏襲したAWS活用」から「クラウドネイティブ」へ 1日10回のリリースを可能にさせた「NewsPicks」のアーキテクチャ改善ステップ：コンテナ化はCI/CDの導入を、CI/CDはオブザーバビリティの導入を楽にする

「＠IT Cloud Native Week 2024 冬」の基調講演に、ユーザベース NewsPicks事業 SRE Unit Leaderの安藤裕紀氏が登壇。AWSを利用しながらもオンプレミスを踏襲した構成となっていた同社で、クラウドネイティブなアーキテクチャへの改善の取り組みと、その過程で得られた知見を紹介した。

[ANDG CO., LTD.]

　「＠IT Cloud Native Week 2024 冬」に、ユーザベース NewsPicks事業 SRE Unit Leaderの安藤裕紀氏が登壇。「10年モノのサービス運用を楽にするクラウドネイティブなアーキテクチャ改善」と題し、「Amazon Web Services（AWS）」を利用しながらもオンプレミスを踏襲した仕組みになっていた同社で取り組んだクラウドネイティブなアーキテクチャへの改善と、その過程で得られた知見を紹介した。

サービス開始当初はAWSを利用しながらもオンプレミスを踏襲した仕組みに

ユーザベース NewsPicks事業 SRE Unit Leader 安藤裕紀氏

　ユーザベースが提供するソーシャル経済メディア「NewsPicks」は、さまざまな媒体のニュースをキュレーションする他、独自制作のコンテンツを掲載している。ユーザーがニュースにコメントできるSNS機能も有している。安藤氏は、SRE Unit Leaderとして、開発者体験の向上に取り組んでいる。

　NewsPicksは2013年9月にサービス提供を開始しており、そのときからAWSを活用していた。一方、クラウドネイティブという言葉が登場する以前からクラウドを活用していたこともあり、オンプレミスを踏襲した仕組みが多く存在していたという。

　「サービス開始当初はコンテナ技術が普及しておらず、マネージドサービスも新しい概念でした。そのため、NewsPicksでは主に『Amazon Elastic Compute Cloud（Amazon EC2）』を中心とした構成でサービスを運用していました。当時は、EC2インスタンスが100台以上稼働しており、それぞれのVM（仮想マシン）管理も必要でした。データベースには『Amazon Aurora』や『Amazon DynamoDB』、ストレージには『Amazon Simple Storage Service（Amazon S3）』などのマネージドサービスを活用することで、運用、管理負荷を軽減していました」（安藤氏）

（安藤氏の講演資料より）

高まる認知負荷と作業負荷、エンジニアのオーナーシップをどう維持するかも課題に

　ユーザベースでは、開発と運用を分けず、エンジニアがオーナーシップを持って開発から運用まで担当し、全て内製開発で常に改善を続けてユーザーに価値を届けるというカルチャーがある。そのため、エンジニアは企画段階から関わり、コーディング、ビルド、テスト、デプロイ、モニタリング、トラブルシューティングというフルサイクルで、課題解決に取り組んでいた。

　「開発者はデプロイと更新を何度も繰り返すことになりますが、100台以上のEC2インスタンスがある中で『どのインスタンスに何をデプロイすればよいのか』『ログを収集するためにはどうすればよいのか』といった具合に、インフラ構成に対する認知負荷と作業負荷が増大していました。インフラ設定を変更するため、SRE（Site Reliability Engineering）チームに依頼が必要で時間もかかるなど、サービスリリースまでのリードタイムを開発者自身がコントロールできない（オーナーシップを持てなくなる）という課題もありました。SREとしても、インフラの調査に時間がかかったり、VMの管理に手間がかかったり、開発環境の増設が簡単にできなかったりするなど運用負荷が高まっていました」（安藤氏）

　そこでユーザベースでは、クラウドネイティブの要素、技術を取り入れることで、課題解決の道を探っていったという。2021年にアーキテクチャ改善の第一歩として、アプリケーションのコンテナ化に取り組み、次にインフラをコード化するIaC（Infrastructure as Code）を実現。オブザーバビリティツールの導入、ログやメトリクスの収集による可観測性の向上、そして安全かつ高速なCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインの構築による堅牢（けんろう）な自動化にも取り組んだ。

コンテナ化とCI/CDで安全かつ高速なリリースが可能になり、開発者体験が大きく向上

　コンテナ化とCI/CDは、クラウドネイティブの技術を導入する指標としてCNCF（Cloud Native Computing Foundation）が定めている「Cloud Native Trail Map」において、1番目と2番目に位置付けられている。

　「EC2の時代は、複数のチームが開発していて、開発環境もチーム数以上に必要でした。本番環境と開発環境でAWSアカウントが分かれていて、『Dev環境1』のような形で独立して使える開発環境も用意していました。本番、プレビュー、開発でおよそ20の環境を管理していたため、開発環境と本番環境の同一性を完全に保証できないという課題や、もしバグがあるのに一斉展開した場合、全ユーザーが影響を受けてしまうというリスクもありました。毎回ビルドを挟むため、待ち時間も生じており、開発者体験も良くありませんでした。これらの課題を改善するために、アプリケーションのコンテナ化に取り組みました」

（安藤氏の講演資料より）

　コンテナオーケストレーションツールとしては「Amazon Elastic Container Service（Amazon ECS）」を採用し、IaCの取り組みには「AWS Cloud Development Kit（AWS CDK）」を活用したという。

　「Kubernetesのようなオープンソースのコンテナオーケストレーションツールを導入したわけではないため、提供される機能しか使えない、カスタマイズできないというデメリットもあります。しかし、スケーリングやデプロイの運用要件については必要十分だと判断し、Amazon ECSを採用しました」（安藤氏）

　AWS CDKによるIaCの取り組みにより、開発者自身がインフラの変更を加えられるようになった他、開発者が使い慣れているTypeScriptでインフラのコードを変更したりユニットテストを追加したりできるようになった。また、SREチームも、インフラを横展開することが容易になり、開発者体験とインフラ品質の向上に貢献できたという。

　ECSサービスを複数用意し、リリース時には1台のみを更新して一部トラフィックのみを新バージョンに切り替えるリリース方法の改善や、CI/CDワークフローの進行状況を「Slack」で共有する仕組みを追加したことで、開発者間でリリース状況が可視化されたり、問題発生時にはロールバックもSlack上で容易に実施したりできるようになったという。

（安藤氏の講演資料より）

　「AWSの責任共有モデルでは、AWSが提供するコンテナサービスを活用すると、OSより下のレイヤーをAWSに任せられるため、SREはアプリケーションに近いコアの運用業務に注力できるようにもなりました」（安藤氏）

　その他にも、サーバを順次入れ替える際のパフォーマンス低下を防ぐため、ECSのデプロイメントサーキットブレーカーやオートスケーリンググループを設定したり、デプロイ時のビルド待ち時間を解消するため、Gitへのプッシュをトリガにコンテナイメージをビルドしたりする仕組みを導入。開発環境と本番環境で同一のコンテナイメージを使うことで環境差分を最小限に抑えることもできたという。

（安藤氏の講演資料より）

　「これらの取り組みにより、安全性と開発速度を向上できました。サービスへの負荷集中を気にせず、日中の好きなタイミングで本番環境にデプロイできる体制を構築できましたし、入社間もないメンバーでも配属初月から本番リリース対応ができるようになりました」（安藤氏）

オブザーバビリティの取り組みで、ユーザーの満足度向上にも寄与

　コンテナ化とCI/CDパイプラインの整備により、デプロイの安全性と速度が飛躍的に向上した結果、NewsPicksでは月200回、営業日を20日と仮定した場合、1日10回ものリリースが可能になった。

　「70人のエンジニア組織において、本番サービスに1日10回もリリースできるのは、かなりの高頻度です。一方、変更頻度と障害発生率には、相関関係があります。デプロイ回数を増やすのと同じペースで、トラブルシューティングの効率化が求められます。そこで次のステップとして進めたのが、オブザーバビリティです」（安藤氏）

　コンテナ化の大きな恩恵として、オブザーバビリティの取り組みにおいて重要なログやメトリクスの収集が容易になる点も挙げられる。「Fluentd」などのデータ収集ツールを使えば、各コンテナのログを「Amazon CloudWatch」に簡単に集約できる。これにより、サービスの利用状況や、ユーザーが不便を感じているポイントを素早くキャッチできるようになる。ただし、膨大なログの中から有用な情報を見極めるには、適切な目標設定も必要になる。

　そこで重要なのが、「SLO（Service Level Objective：サービスレベル目標）」だ。SLOは、Googleが提唱するサービス運用の方法論「Site Reliability Engineering」の中核を成す概念だ。満足度の高いサービス提供に必要な目標値を定めるものだ。

　「SLOを決めるには、まずユーザーにとって最も重要な体験である『クリティカルユーザージャーニー（CUJ）』を特定する必要があります。次にそのCUJを実現できているかどうかを計測するための『SLI（Service Level Indicator：サービスレベル指標）』を考えます。最後に、その指標を使ってSLOを設定します。SREは機能開発をしているわけではないため、漠然とした理解の上でCUJを設定し、アクセスログをベースにSLIを計測し、可用性やレイテンシのSLOを設定しました」（安藤氏）

（安藤氏の講演資料より）

　当初は、社内のデータ基盤として活用していた「Amazon Redshift」にアクセスログを集約し、BI（ビジネスインテリジェンス）ツールの「Metabase」を使用して可視化していたという。だが、ログの分析に時間がかかったり、SLO違反時の原因特定が難しかったりする課題も浮き彫りになったため、アプリケーションパフォーマンスモニタリングに特化した「New Relic APM（Application Performance Monitoring）」を導入した。

（安藤氏の講演資料より）

　「New Relicに移行したことで、SLOに違反したエンドポイントとデプロイとの関連付けもできるようになり『エラー率が上がったデプロイをした人は誰々さん』と特定できるようになりました。開発者自身でもNew Relicを活用できるよう、New Relicのライセンスを購入したり、トレーニングにも取り組んだりしました。また開発チームごとのミッションに応じて必要なAPIエンドポイントを自らモニタリングできるセルフサービスの仕組みも構築しました」（安藤氏）

（安藤氏の講演資料より）

　安藤氏は「2年かけて、インフラ環境の課題を順番に解決していきました。結果的に、CNCFのCloud Native Trail Mapと同じ順番になっていたこともあり、スムーズにクラウドネイティブ技術の導入を進められたのではないでしょうか」と振り返った上で「コンテナ化を進めていくことがCI/CDの導入を楽にしますし、コンテナとCI/CDを整備することでオブザーバビリティの導入を楽にします。まず、コンテナ化は、自信を持って進めてよいでしょう。頑張り過ぎずに、クラウドネイティブで事業課題の解決を楽しんでいきましょう」と講演を締めくくった。