少人数の開発を止めないようにするには、計測によって、障害を早期発見・対処することが重要
セッションの冒頭で、New Relic株式会社 技術統括 コンサルティング部 ソリューションコンサルタント 古垣 智裕氏は、少数組織で大きなサービスを開発するためのポイントを共有した。古垣氏は「重要なことは、開発とSREが自律的に協業して高速にサービスを開発すること」だとし、だからこそ少しのつまずきがリリースの延期や品質の犠牲につながると指摘した。開発を妨げる要因をいかに早期に発見・対処していくことが重要となるのだ。
では、リアルタイムに障害を発見して対処するにはどのようなアプローチがあるのだろうか。古垣氏は「ズバリ申し上げると、データを活用することで、障害物に対応できるようになります」と話す。プロダクトのありとあらゆるところから、客観的かつリアルタイムなデータを計測し、障害物を発見し対応できる基盤を作ることが重要だ。
責務の整理、導入する機能の取捨選択、ダッシュボードの整理がポイント
古垣氏の概要説明のあと、株式会社TVerのサービス事業本部 技術開発部 リードエンジニアでSREの加我 貴志氏が登壇し、SREから見たNew Relicを利用したTVerのサービスリニューアル事例を紹介した。
TVerは、民放公式のテレビ配信サービスで、毎週約500番組の見逃し配信のほか、過去のコンテンツの配信、地上波の同時配信、ライブ配信などを提供している。2022年7月にはアプリのダウンロードは5000万件に届く勢いで、月間動画再生数が2億5300万件となる大規模サービスとなっている。再生端末はPCやスマートフォンだけでなく、25％程度がコネクテッドTVによるものだ。
TVerではクラウドプラットフォームを利用しており、主要ワークロードはAWSにあり、データ分析はGCPという使い分けをしている。プログラミング言語にGoを採用しソースコード管理とCI/CDにはGitLabを使っている。インフラでは目的に応じたグループにてアカウントを管理しており、耐障害性に優れたマイクロサービスを採用している。TVerのWebサービス、会員情報の管理、テレビ番組との連動、各種視聴データの集計などのサービスがそれぞれ連動して動いている。
TVerのWebサービスは全てAWS上に構築されており、通常のWebリクエスト、静的コンテンツの配信、番組の配信といった用途に応じて、トラフィックを処理している。多様なクライアントに対応しており、バックエンドは大量のトラフィックをさばく必要があるため、NGINXとGoを採用したバックエンドを構築した。加我氏は、「そして、フロントエンドとバックエンドのデータを全てNew Relicに集約し、各種モニタリングやアラートに活用しています」と付け加えた。
2022年4月に実施したTVerのサービスリニューアルでは、TVer IDという仕組みを導入することで、ユーザーの利便性を向上した。その開発に伴い、それまで外部の協力会社に構築運用を依頼していたインフラの内製化を行い、それにあわせてバックエンドの刷新を行った。さらにAmazon CloudWatchだったモニタリング環境をNew Relicに移行したのだ。
加我氏は、New Relicへの移行に際し行ったことが3つあるとし「一つは責務の整理、二つ目は、導入する機能の取捨選択、三つ目はダッシュボードとデータの活用です」と説明した。
責務の整理については、加我氏が入社する前に話が遡る。New Relicの導入はバックエンドのエンジニアが進めており、リニューアル期限まで残り3カ月と迫った2021年12月末、メンバーの多忙さによってNew Relicのフル活用という理想からはかけ離れた状態となっていた。そこで2022年1月に加我氏が入社し、オブザーバービリティやモニタリングの担当を引き継いだ。
加我氏は、「TVerは少人数の技術組織なので、1人で全てやろうとする気持ちもわかります。しかし今回は、あえて責任を分担することで、リニューアルと信頼性の両方を実現することができました。結果的に他のエンジニアは目の前にある優先度の高いタスクに集中できる環境となりました」と振り返った。
導入する機能の取捨選択については、New Relicの豊富な機能によってMELT（Metrics、Event、Logs、Traces）の全てを満たし、特にエラー調査のために、リクエスト単位で詳細な情報を得られるAPM（Application Performance Monitoring ）を導入したいと考えていた。
ところが、リリースまで残り2カ月というところでGoに対応したNew Relicのエージェント導入が困難であることがわかり、New Relicの担当者のアドバイスもあって、必要最小限な箇所だけに導入することとした。
加我氏は「最低限でも十分すぎるくらい必要なメトリクスを取得することができています。最小限の労力で最大の効果を得ることができました」と述べた。New Relicはドキュメントとサポートが充実しており、ユーザーコミュニティも活発なため、迷うことなく導入ができたのだ。
ダッシュボードとデータの活用において加我氏は、クライアントからバックエンドインフラまで幅広くカバーできるダッシュボードを整備して対応した。リニューアル後は、クライアントのクラッシュ情報やネットワークエラー情報を調査し、状況をできるだけわかりやすく、社内に共有するといった活動も進めている。将来的には自動化も念頭に置いて運用をしていく。
