#linedevday LINEが乗り越えてきた困難な課題 の参加レポ＠LINE DEVELOPER DAY 2016

LINE DEVELOPER DAY 2016に今年も参加してきたのでそのメモです。

LINEが乗り越えてきた困難な課題

LINE開発1室 那須利将様

• LINEがダウンした歴史と、乗り越えた方法の紹介です
• 今回紹介した以外にもHBaseやhadoopのノードがダウンとかもありました

障害の歴史

• 2011/12/18
  • Redisの拡張作業をしていて、マスターの拡張をしていた
  • Replication設定がONで投入したため、既存のデータがマスターで初期化されてしまった
  • 会員情報がなくなってしまった！
  • 統計用のDBとしてMySQLのデータとWebアプリのデータを用いて復旧しました
  • 復旧作業を完了して現在もサービスされています
• 2013/05/03
  • アクティブコネクションが増えてファイルディスクリプタが足りなくなってしまった
  • 1時間サービスが止まってしまった
• 2014/06/30
  • GCの設定をミスしてアプリケーションサーバをとめて、再起動してもサービスが帰ってこず、1時間サービスが止まってしまった
  • threathholdをきちんと監視していればよかった
  • リリース作業もドキュメント化して改善しています
• 2016/03/11
  • 今回お話する内容です

何が起こったか

• 1時間40分メッセージの送受信や通話機能が止まってしまった
• サーバーに味噌汁をこぼしたなどのデマが流れてました
  • 半年たった今もテレビ局から問い合わせ合ったりもしました
  • デマのリスクに気をつけましょう！
• 着せ替えのアプリの内部データを更新する作業を実施した結果、更新をトリガーにクラインとアプリとの通信がバーストしてしまった
  • メインの認証サーバが高負荷になってしまった
  • 同時に音声通話の一部のトークサーバも高負荷になった

システム背景

データ更新通知

• きせかえの画像が更新されたり、増えたりした場合はクライアントに保存されているデータの更新が必要になる
  • これらはCMSやバッチを通して、一つのきせかえデータにつき一つの更新通知をクライアントアプリにしてクラインとアプリから更新してもらうようにしている
  • 登録された共通データは通知するが、3時間の間に分散して全ユーザに通知する
  • 全ユーザの共通データを集中させないようにしている
  • 通知をうけとるとユーザは共通データの更新を実行する
  • しかし、通常の更新では認証を不要としている

データ更新の仕組み

• Universal Event Notification(UEN)はスタンプやおしらせなどに使われている
• 個別ユーザのデータ更新（未読データのバッチ処理など）を提供している
• なぜきせかえデータの更新作業が必要か
  • 2016/04/16に発表されたクリエイターズ着せ替えを配信するため
  • 着せ替えの既存のデータ構造の組み換えが必要だった
  • データ更新作業は1度だけではなく、前の日などにリスク分散のため何度もやっていた。
• 作業を開始したときは2000個もなかったのだが、作業していく間に2000個以上のデータが溜まっていった
  • 1つのきせかえにつき1つの通知をやる場合と、2000個以上のデータが一気に登録されたら通知をする場合がある
  • 2000個超えると1つずつ更新するより、一気に更新した方が通信量も減るのでいい
  • 2000個を超えるデータを更新するのは久々に起動したユーザになるので認証サーバの通信を必須としている

原因

• CMSサーバを通して2000個以上のきせかえデータを1件ずつ登録していった
  • 仕様として1件ずつしか登録できなかった
  • 通常1日10回、10人程度しかない全データ更新通知を全ユーザに通知した
  • 頻度が少ないので、時間分散する仕組みになっていない
  • 全データ更新通知を全ユーザに投げた結果、ほぼ全ユーザから同時にアクセスが認証サーバに殺到してバーストし、認証エラーになるようになってしまった
• まとめると、2000個以上データを登録し、全データ更新通知を全ユーザに通知し、配信分散をしないで通信を行ったことによって障害が発生した

復旧対応

• 認証機能の負荷が減るように、認証リクエストが発行されないようにした
  • 1：UENのデータを変えて、全データ更新が発生しないようにデータを変えた
  • 2：LEGYのリクエストグルーピングを更新した。（iphone向け、android向けなどのグルーピングされたストリーミング単位）
  • 3：認証APIのリクエストをスロットリングできるようにし、アドホックにやるように変えた
• 対応の結果、障害発生から1時間40分後に復旧しました
• まとめると、全データ更新通知を止める、リクエストの制限、認証別のリクエストを作って対応した

対応策

• 1日十件であろうと、時間分散配信するようにする
• UENの登録上限数を設定する（1日100件）
• 認証サーバにCircuit Breakerを導入した
  • サーキットブレーカーはリモートアクセスの失敗などをカウントして、しきい値を超えたら全アクセスを遮断する仕組み
• 機能毎にサーバグループを分けた
  • 音声通話サービス専用のサーバ構成に替えた
• 着せ替えのUENの仕組みも2000個もデータ通知を送らないように1件で行えるように更新通知を行うようにした

総務省への検討と報告会

• 通話機能を提供しているLINEは電気通信事業者にあたるので総務省に報告の義務があった
• 緊急通報を取扱合わない時間が1時間で10万ユーザあると報告する義務がある
  • 事後報告の有効活用をして、安心安全の向上に取り組んでいる
• 総務省のホームページにも上がってます

学んだこと

• 複合的に原因が絡んで音声通話などができなくなるようになったということは、microservicesがうまくできていないということになる
• サービスのきせかえは登録の良し悪しを判断しないので、自衛のために大量登録ができないようにしたり、リクエストの予測制限ができないのでサーキットブレーカーをいれたり、Armeriaを入れることでそれぞれの処理をトークサーバでブロックしない構造にできるようにしたりした

QA

• issueをすべて片付けるのにどれくらい時間がかかったか
  • まだ解決してないのもあるが、今話したのは解決している
• 過負荷時のサーキットブレーカーの発動について、発動してしまうと全体の動作にも影響があると思うが、各コンポーネントのリスクの評価と管理はしているのか
  • microservicesがとまるリスクはあるが、機能として、メッセージ送受信はできてもいいだろうということで、着せ替えの配信は停止してもいいと考えている
• 他の機能のリスク管理はどうしているか？
  • リリースする際にmicroservices単体でやるわけではなく、各担当にドキュメント化して共有してリリースしております
• 障害を見つけるのは大変だと思うが、障害を発見するまでどういう感じだったか
  • まず普段モニタリングをしているが、リクエストバーストするほどリクエスト来ているということでアラートが上がった
  • このリクエストを見たら全データ更新通知のリクエストが来ているのがわかった
  • なぜ登録されたのかをみたら、きせかえデータの更新をしていることがわかり、担当者に連絡したら判明した
  • 大体LINEのグループで話をして解決しています
• LINEの連絡のトラブルはLINEでやるのか？
  • メッセージングできないとhipcahtを使ったりしています
  • 社内のツールとしてメッセンジャー機能を使ってそれも使っています
• microservicesを分けて作る際に、着せ替えのデータ更新も連絡せずにやるのか、何が起きるかを見通してやるのか？
  • 大体はきせかえで懸念点を把握されると思うが、まず予測をたてて共有しないといけないと判断されたら共有してみんなでモニタリングしてやっている
  • 今回は認識がなかったため、障害が発生してしまった
• プロセスの見直しもあるのか？
  • 障害報告会をやって、何が起きたか、何が改善できるかを話し合って、プロセスの改善の話もあります

@mogmetの所感

障害の原因や解決などのお話はなかなか参考になることが多く、またわかり易く説明してくれたので、楽しいセッションでした。

障害が発生したときの原因追求はなかなか大変なものがありますが、1個ずつ原因を探って見つけるのも一つの必要なインフラエンジニアのスキルだなと感じました。