可用性とコストのリバランス:テレビ砲の過負荷へ対応した話と増強したリソースを適正化した話 by 下村 拓

SRE Kaigi 2025
採択
2025/01/26 11:20〜
ホール
セッション(30分)

可用性とコストのリバランス:テレビ砲の過負荷へ対応した話と増強したリソースを適正化した話

dondakeshimo 下村 拓 dondakeshimo
1

■ 発表カテゴリ

・Case Studies: 実際の導入事例や失敗談

■ 発表概要(400字程度)

トラフィック急増によるサーバーの可用性低下に対する応急対応と、その後の恒久対応およびコストの適正化について発表します。

弊社が開発している金融アプリBloomoは、リリース直後にテレビ番組WBSにて紹介いただけました。テレビの影響は我々の予想を遥かに超え、トラフィックの増加による過負荷でサーバーへ繋がりづらい状況が続いてしまいました。

インシデント対応後の安息も束の間で、今度はコストが問題となりました。インシデント対応としてリソースを増強した結果、コストが予算の数倍まで膨れ上がってしまったためです。しかしながら、リリース前に実施できていた負荷試験は部分的で、削れるリソースがどこにあるのかわからない状況でした。

本発表の前半では、インシデントの止血や追加の対応などについて、どのような状況だったかをお話しいたします。後半では肥大化したリソースとコストをなるだけ早く適正化するために実施した取り組みについて紹介いたします。

■ 発表の詳細(1000字程度)

弊社は金融アプリBloomoを開発しています。バックエンドは、お金を計算するGoで実装されたコンポーネントと、顧客周りを含めてお金以外の全てを処理するRuby on Railsで実装されたコンポーネントの大きく2つがGKE上で稼働しています。その他の背景として、インフラ経験豊富なメンバーが社内にいない中、手探りで整備を進めていたことも付け加えておきます。

アプリは2024年の5月にリリースされました。金融商品を扱うアプリのため、インシデントが一つ起こることの影響が非常に大きく、リスクを潰すために考えられる機能的なテストや試験的な運用は実施していたので、機能観点ではある程度の自信を持っていました。一方で、横断的関心事に関するテストの実施は部分的であり、その点に関しては不安を抱えつつも楽観的な想定を持ってリリースに臨んでいました。監視可視化についても最低限必要と思われるものを整備した状況で、それらを実際に閲覧できる人間は多くありませんでした。

リリース直後にテレビ番組WBSにてアプリを紹介していただける機会を得ました。テレビの影響は絶大で、想定を遥かに上回るトラフィックが押し寄せた結果、弊社アプリのサーバーは過負荷によってつながりにくい状態になってしまいました。横断的関心事に関するテストが疎かになっていたこと、テレビの影響を甘く見て特別な準備をしていなかったことなど反省点は枚挙にいとまがありません。メンバーがちょうど拠点である東京から離れ、ある人は大阪へ、ある人は沖縄へと旅立ってしまっていたため、むしろ対応が数時間でできたことは奇跡だったかもしれません。

リソース増強による復旧と監視周りの運用体制の整備をしてメディア露出を乗り越えた後は、増大したリソースによるコスト増加に対応する必要がありました。どこでコストが掛かっているのか、どこまでの事象に耐えられるサーバーにする必要があるのか、簡単にコストを下げられる箇所はどこか、大きくコストを下げられる箇所はどこかなど、ひたすら現状を整理していきました。その中で、SLOによるサービスレベルの擦り合わせを経営陣と行うことの重要性に気づきました。コストの抑制は喫緊度の高い課題であったためSLOを全面導入するには至らなかったものの、サービスレベルに焦点を合わせてタスクに取り組んみ始めてからスムーズに意思決定ができるようになりました。

振り返ってリリースまでに最低限準備しておかなけれなばならなかったことと、その後もレジリエンスの高いサービスを運用するためにやって良かったことなどを交えつつ、リリース前後の弊社インフラチームの死闘をお話しできればと考えています。

■ 対象聴衆とその人たちが得られるもの

対象聴衆は以下のような人たちを想定しています。

  • これからSREを企業に浸透させたい方
  • 新規でサービスを立ち上げる方
  • 初心者の失敗談を聞いてみたい方

得られるものは以下のとおりです。

  • 新規サービスをリリースする前のSRE観点で最低限の準備
  • トラフィックの増加が予想されるイベントへの対処方法
  • サービスレベルを軸にしたコストの適正化方法

■ なぜこのトピックについて話したいのか(モチベーション)

個人の経歴として、エンジニアを入社してからバックエンドエンジニアとして働いてきました。今もメインの業務内容はバックエンドの開発です。一方で、新卒で担当した業務がPrometheusへの移行であったり、チーム横断の生産性改善への取り組み担当を任せていただいたりと、バックエンドの中でもSREに近しいところで働いてきたと感じています。昨年に今のスタートアップ企業へ転職してからはより直接的にSREへ関わることになり、テレビによるインシデントを契機に今では業務の2~3割をインフラ領域へ割り当てています。

このインシデントから連なる一連の取り組みでSREの重要性や面白さを発見できたことが、今の自分の原動力となっています。聴衆の方々へ、具体的な知見と一緒にSREに対する情熱を共有することで、一緒にSREを盛り上げていきたいと思い、応募させていただきました。

また、実際の経験談特に失敗談は貴重なものだと感じています。自身の経験を共有することで、同様の課題に直面する可能性のある企業やエンジニアの助けになったり、業界全体のプラクティス向上へ貢献できればと考えています。