チームを巻き込みエラーと向き合う技術 by maru

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
SREの現場では、障害を防ぐだけではなく、避けられないエラーや過負荷にどう向き合うかが重要です。多数のクライアントが多様なサービスとリアルタイムに通信するLINEでは、停止か稼働かの二択ではなく、段階的に劣化しながら体験を守る「グレースフル」な設計を重視しています。

1. 障害の連鎖を防ぎ、全体影響を局所化する サーキットブレイカー
2. リトライや瞬間的な高負荷を適応的に抑制する アダプティブレイトリミッター
3. 新規データを優先して体験を守る コンテキストアウェアなロードシェディング
4. 鮮度が求められる情報のための クライアント側エラーハンドリング
5. 安全に進めるための カナリーリリースとトラフィック制御
6. 開発段階から健全性を確認する カジュアルな負荷試験

これらを通じて「なめらかに劣化しても信頼性を維持する」LINEの実践を共有します。

■ 発表の詳細（1000字程度）

本発表では、LINEにおけるSRE実践を「なぜその仕様に至ったか」という議論の経緯も交えながら紹介します。

まずは、 障害の連鎖を防ぐサーキットブレイカー 。複数サービスと連携する際、上流が応答せずタイムアウトすると、アプリ全体の表示が遅延する課題がありました。異常を検知すると一定時間リクエストを遮断する仕組みを導入し、障害の連鎖を防いでいます。

次に、 上流サービスを守るアダプティブレイトリミッター 。リトライや瞬間的なアクセス集中で想定外の負荷が生じ、上流をダウンさせる恐れがあります。単純なRPS上限設定では柔軟性に欠けるため、上流から返されるエラー率や種類に応じて制御を動的に調整する仕組みを導入しました。

続いて、 過負荷時の体験を守るロードシェディング 。LINEアプリは多くをキャッシュするため、過負荷時には全リクエストを処理する必要はありません。リフレッシュ要求を後回しにし、新規コンテンツ取得を優先する「コンテキストアウェア」な仕組みによって、限られたリソースでもユーザー体験を守ります。

一方で古い情報が表示されるリスクも生じます。そこで、 応答不能時のエラーハンドリング として、鮮度が重要な情報に対してはクライアント側で追加の仕組みを実装。サーバー側に依存しないアプローチで、ユーザーが古い情報から誤った判断をしにくくしました。

さらに、 カナリーリリースとトラフィック制御 。一般的な10%先行リリースでは、単純なラウンドロビンだと不具合が全ユーザーに影響する恐れがあります。そこで影響範囲を明確に制御できる仕組みを取り入れ、安全にリリースできるようにしました。

最後に、 開発段階から健全性を確認するカジュアルな負荷試験 。従来のQAは機能検証が中心で、高負荷時の問題を事前に見つけにくい課題がありました。そのため、開発段階から簡易に負荷試験を実施できる環境を整備し、非機能要件の健全性を自然にチェックできる文化を育てています。

これらの取り組みを通じて、どのように「想定外を前提とする」設計を実現し、議論を経て現場に落とし込んできたかをお話しします。実例と背景を交えて紹介することで、皆さんの現場でも応用できるヒントを持ち帰っていただけるはずです。

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

本発表は、ユーザー視点での信頼性向上を目指すSWEやSREを対象としています。クライアントサイドとサーバーサイドといった境界を越え、どのようにしてエンドツーエンドの信頼性を確保できるのか。その具体的な事例を持ち帰り、自らの現場に活かしていただけます。

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

開発の現場では、エラー発生時の挙動に十分な配慮がなされないことが少なくありません。特にスケジュールに余裕がない場合や、再現の難しい障害への備えは後回しになりがちです。私自身も日々、優先度の判断に悩みながら、今取り組むべきことと後に回すことを天秤にかけつつ、チームと共にさまざまなプラクティスを導入してきました。
同じような課題に直面しているSREの方も多いと考えています。本発表を通じて、そうした悩みを共有し、実践のヒントを提供できれば幸いです。