少人数の開発を止めないようにするには、計測によって、障害を早期発見・対処することが重要
セッションの冒頭で、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はドキュメントとサポートが充実しており、ユーザーコミュニティも活発なため、迷うことなく導入ができたのだ。
ダッシュボードとデータの活用において加我氏は、クライアントからバックエンドインフラまで幅広くカバーできるダッシュボードを整備して対応した。リニューアル後は、クライアントのクラッシュ情報やネットワークエラー情報を調査し、状況をできるだけわかりやすく、社内に共有するといった活動も進めている。将来的には自動化も念頭に置いて運用をしていく。
役割分担とデータの把握で、個人が自律的に共通のゴールを目指す状態に
加我氏の説明のあと、バックエンドのリードエンジニアである株式会社TVer サービス事業本部 技術開発部の内海 恵介氏が登壇し、少人数でも開発を失敗しにくくするためにNew Relicを活用した手法について説明した。
TVerでは、大規模なリニューアルを前に、開発段階からNew Relicを使い、リリース後の運用監視などへスムーズに移行することに成功した。リリースの2カ月前には、エラーハンドリングや例外処理などたくさんの想定外のバグが出ていた。そこでAPMのErrors InBoxなどを使ってAPI単位でのバグの洗い出し、リクエスト情報の精査を行った。
「NRQL（New Relicクエリ言語）を利用して、モバイルイベントのリクエストエラーなどの情報を合わせると、バグ報告者の端末を特定し、そのときのリクエストやユーザーデータの状態を詳細に確認することができ、再現するための情報がすぐ手に入る状態だったことは、バグ潰しにとても役立ちました」（内海氏）
バグ潰しが一段落したリリース1カ月前には、負荷試験によるボトルネック調査を入念に行った。New Relicでは、平均や最大値だけでなく、パーセンタイルの指標をとらえることができ、全体を俯瞰してボトルネックの要因を探ることができた。
リリースの2週間前には、全体的なバグボトルネックを解消し、あとは要求性能を満たすためのパフォーマンスチューニングの段階となった。応答に10ミリ秒以上かかる遅いAPIを洗い出すなど、分析とチューニングによって全体的なパフォーマンスを劇的に改善することに成功した。
New Relic以外で工夫したことについて内海氏は、アフリカのことわざである「早く行きたければ1人で行け、遠くまで行きたければみんなで行け」を挙げ、スピード感を落とさずにリリースを迎えるためにあえてチームでなく、個々のメンバーが自律的にゴールを目指すことを選択したと説明した。
「バックエンド、インフラ、SREとそれぞれが1名のチームだったので、それぞれがそれぞれの最速で目的地に向かって早く行くための土壌はできていました。それらを阻害しないために責務を明確化して分解することはとても重要でした。最終的なゴールやミッションを明確に共有することを意識し、それぞれがゴールに対して最適な判断をその場でできる環境を維持することも努力してきました」（内海氏）
内海氏は続いて、TVerのサービスにおけるパフォーマンスチューニングや負荷対策を紹介した。24時間365日常に大量のアクセスがある同サービスでは、たびたびアクセススパイクが生じる。テレビでの野球中継を地上波で行っていたが、延長のためTVerで続きを放映する、番組が終了した直後にほかの番組を探す行動が見られるなど、10倍以上のトラフィックが訪れる。内海氏は、このような瞬間はバックエンドエンジニアの腕の見せ所だという。
SREである加我氏がダッシュボードを整備したおかげで、負荷試験やシミュレーションテストなどで各種指標がどんな動きをするかをパターンごとに認識できたため、その後の運用のイメージがつかめた。内海氏は負荷試験やそこで挙がった課題の対処に対策に集中することができた。
メトリクスを日々常に確認して話し合うことで、プロダクト改善やトラブル対応につなげる
リリース後は、運用してみて初めてわかることの連続で、ここでも横断的に可視化したメトリクスの恩恵を得られた。内海氏は「安定して稼働している状態や、ユーザーが殺到している状態、外部要因でアクセスが増えている状態、また、一部サーバーリソースなどの不安定な状態など、さまざまなシミュレーションを事前に実施し、ダッシュボードを見ていたので、リリース後も安心を得られる状態になっていました」と説明した。
フロントエンドからバックエンドまで横断的なダッシュボードであるため、サーバーだけではなく、アプリデバイスごとの挙動差分にもすぐ気づくことができた。例えば、iOSアプリだけ特定のページ内で止まるAPIの呼び出し回数が非常に多いなどをすぐに捉え、非常に早いサイクルで改善することができた。また、サービス開始当初は多めのリソースを用意していたが、これも1カ月ほどでリソースを縮退しても安定稼働できるよう調整できた。
TVerのチームでは、リリース後からすぐにダッシュボードを眺める会を行っていました。前日の番組表やイベントと照らし合わせて、話し合い、新たなメトリクスをSREに依頼するような動きも見られ、常に改善に努める体制が出来上がっている。内海氏は「普段のメトリクスを感覚として持っておく訓練にもなります。そして、ちょっとしたトラブルや障害時にどういう挙動になるかの知見の集積などができるので、ぜひこれらは皆さんのチームでもやってみてください」とアドバイスした。
また内海氏は、責務を明快に分離することによって、正しく任す／任されることが自然できるようになり、本来の事象と乖離したレポーティングなどの問題を解消できるとし、チームにスピード感を出す場合には非常に重要だと述べた。
少人数だからこそ、コミュニケーションのロスを最小限に抑え、無事にリリースを迎えることができた。その後TVerには優秀なメンバーが続々と入社しているとし、内海氏は最後に「次はみんなで速く、遠くに行ける技術組織にしていきたいと考えています。TVerの技術組織は、やっと今から始まります。これからどんどん大きくして、そしてみんなが正しく頼り合える組織にしたいと思っています。興味がある人はお声がけください。TVerでテレビの未来を一緒に作っていきましょう」と呼びかけた。
