大規模ならではのバックエンド開発をABEMAで経験した話

WRITER: internship
このエントリーをはてなブックマークに追加

はじめに

はじめまして！

2024年2月7日〜2月29日の1ヶ月間「CA Tech JOB」というインターンシップに参加していた同志社大学大学院修士1年の小西 杏典です。（研究室行事や祝日等で実働10日間でした…）

私が配属された部署は、ABEMAのバックエンドチームです。

本稿では、私が本インターンシップに参加した背景や本インターンシップで使用した技術や経験したタスク内容などについて紹介させていただきます。

 

そもそもなぜ参加したのか

私は、個人開発や他企業でのアルバイト・インターンシップを通してバックエンドだけでなくフルサイクルで開発をしていました。ただ、自分の技術力を振り返った際に広く浅く技術に触れている感覚があり、専門性が必要だと感じていました。

そんな中、「CA.go 〜ABEMAのGoを活用したFIFA ワールドカップ生中継の舞台裏〜」にオンライン参加したときのことをふと思い出し、こんなレベルの高いバックエンドチームを1回見てみたいと思いました。

そして、人事の方との面談を通してABEMAでバックエンド開発をすることになりました！

 

参加する前に定めた目標

ABEMAでバックエンド開発ができることが決まり、10日間という極めて短い期間で何を学びたいのかを考えてみました。今まで参加したインターンシップの経験値から短い期間だと中途半端な理解で終えてしまうことが多かったため、これだけは学んで自分のものにしたいと目標を決めて取り組むよう意識しました。

 

Whyを突き詰めて根本から理解したい

  •  短い期間での開発となると既存コードをもとに書き換えてとりあえず実装を完了することが多かったため、根本から理解するようにする
  • 分からないことをそのままにするのではなく、積極的に社員の方に質問を投げかける（分かっていても質問することってためらいますよね…）

 

大規模でしか経験できないことにチャレンジしてみたい

  • どうやってABEMAのような大規模サービスを保守・運用しているのか気になっていたため、インフラ周りを触って知見を増やす
  • ユーザーから飛んでくる想像もできないほど莫大な数のリクエストを捌くバックエンドの工夫点を吸収する

 

使用技術

 Go言語

  • ABEMAのマイクロサービスにおけるバックエンドはほとんど全てGo言語で書かれており、今回のタスクでも使用しました

 

Kubernetes

  • Google Kubernetes Engine（Google Cloudが提供するフルマネージドなKubernetesプラットフォーム）がABEMAのマイクロサービスを支えています

 

Istio

  • マイクロサービス間の全てのネットワークトラフィックを管理するサービスメッシュであり、今回のタスクではサービス間の通信をIstioレベルで制御しました

 

 

タスク内容

主に行なったタスクは2つあり、以下の通りです。

 

  • ABEMAでは「Common Expression Language」を活用し、膨大なメディアデータをフィルタリングする機能をGo言語で実装しており、あるマイクロサービスのv2移行に伴う対応を行いました
  • マニフェストでIstioのVirtual ServiceにRetry設定を定義し、各Podのリクエスト滞留や5xx系エラーの低減を行いました

 

特に2つ目のタスクで行なった「各マイクロサービスのRetry設定」で学んだことが多かったため、より詳細に以下で述べます。

 

各マイクロサービスのRetry設定

本インターンシップで目標にしていた「Whyの突き詰め」と「大規模ならではの開発」を経験できたタスクであり、多くのことを学びました。

なぜRetry設定が必要か

前述しましたが、ABEMAのような膨大なリクエストを捌くサービスでは以下のような課題がありました。

 

あるマイクロサービスにあるリクエストが滞留してしまうとカスケード障害につながってしまう

  • 「一定時間でTimeoutさせる」必要あり

不定期に発生する5xx系エラーでリクエストが適切に捌けないときが稀にある

  • 「捌けなかったときにRetryさせる」必要あり

 

このような理由から本タスクに取り組むことになりました。

 

ここまで当たり前のようにIstioに触れてきましたが、ここで一度Istioとは何か簡単に説明しておきます。（私は本インターンシップで初めて触りました）

 

Istio

Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments.

(by https://istio.io/)

 

公式が述べている通り、Kubernetesを拡張して各マイクロサービス間のトラフィック管理や監視などを行ってくれるサービスメッシュです。

Istioは大別するとService間のトラフィックを制御するData PlaneとそのData Planeの設定を管理するControl Planeで構成されています。

(by https://istio.io/latest/docs/ops/deployment/architecture/)

 

上図から、Service間の通信は必ずIstio Proxy（ABEMAではSidecarパターンを採用）を経由して通信を行っていることが分かります。

つまり、このSidecarで動くIstio Proxyに対して設定を施すことでリクエストを制御することができます。

具体的には、今回のタスクではIstioの「Virtual Service」を利用してRetry設定を行いました。

 

Virtual Service

「Ingress Gateway」が受け付けたトラフィックのルーティング設定はVirtual Serviceで管理します。例えば、HTTPではリクエストメソッドやリクエストヘッダなどでルーティング設定を変更することができます。

 

実装設計

前提として、ABEMAでは「Prometheus」で計測したメトリクスを「Grafana」で可視化しています。

そこで、Grafanaで可視化しているメトリクスをもとにどうRetryt設定を行うかを設計しました。

 

全マイクロサービスの全RPCを対象にするか

    • 課金が発生するRPCは決済途中でRetryさせるのはインシデントに繋がる可能性が高いのでやめる

 

1つ1つのRPCのメトリクスを確認する必要があるので、効果の大きいマイクロサービスやRPCに設定する

  • ユーザーがよく利用する主要マイクロサービス
  • RPS（Requests Per Second）が100を超えるRPC

 

RetryごとのTimeoutの時間をどのように設定するか

  • ToB用 or ToC用
  • 99.9 PercentileのRequest Durationが500ms未満 or 500ms以上のように

 

バッチ処理や外部APIの呼び出しのような処理時間が不安定なRPCはどうするか

  • 処理途中で不本意なRetryが発火してしまうと処理が適切に終了しないので基本的には設定しない（例外あり）

 

 

実装

ABEMAでは「Kustomize」を利用して環境に依存しないベースとなる設定はまとめておき、環境依存の設定は上書きするようにしています。

そのため、本タスクの実装は至ってシンプルであり、ベースの設定に加えてVirtual Serviceの設定を以下の様に実装するだけでした。

 

Retry設定だけでなくトラフィックポリシーを付与したい場合は、「Destination Rule」を活用することで実現できます（サーキットブレーカーの設定もDestination Ruleで行うことができます）。

 

学んだこと

  • 「とりあえず実装」をやめて設計から入ることでレビューをもらうことができ考慮漏れや実装し直しを低減することができる
  • 気になったところはそのまま放っておかず、Whyを突き詰めることで技術の根本理解につながり、ただ利用するだけでなく応用することができる
  • 大規模サービスならではの開発を経験し、local環境とdev環境で入念なチェックと起こりうる障害の予測がどれだけ重要であるか再確認した
    （local環境でplanを実行することなくCI結果やGrafanaのメトリクスを過信してdev環境を一時的に止めてしまいました）
  • 隙間時間にABEMAバックエンドのソースコードを読む時間を作ることで、個人開発であまり意識していなかったキャッシュ戦略やGraceful Shutdownのテクニックを知ることができた

 

さいごに

まずは10日間という本当に短い時間、ABEMAのバックエンドチームの皆様ありがとうございました。

本インターンシップに参加した背景にもあった通り、本当にレベルの高い環境であることを再確認できましたし、チームとして支え合っている印象を受けました。技術に対する熱量・学ぶ姿勢が圧倒的で「もっと高みを目指さないといけない」と刺激になりました。

実は技術以外の面でもたくさんサポートしていただきました！

例えば就職活動での考え方だったり、今後のキャリアだったりの話をランチ時間に忖度なしで自分に向き合って話してくださったことに感謝しています。

これから本インターンシップに参加を考えている or 参加が確定している方には是非「これだけは学びたい」や「ここに挑戦したい」ということを決めておくと大きく自己成長できると思います。

日本音響学会 第151回(2024年春季)研究発表会 参加報告
次の記事
Airflow x Cloud Batchによるデータ分析自動化の舞台裏
前の記事