「あけおめLINE」による過負荷障害をどう防ぐ？ LINE SREが語る“安定稼働”の裏側：2021年の障害を教訓に
2022年3月12日、大規模サービスを展開する国内IT企業6社が「6社合同SRE勉強会」をオンラインで開催した。LINEでSREを務める加藤俊弥氏は大量アクセスが発生する「元日」に過負荷による障害を起こさないため、SREとして取り組んだ「準備」「検知」「対処」を紹介した。
ITサービスがビジネスの根幹となる中、ITサービスを迅速に開発してユーザーに提供することが求められている。一方で、快適にサービスを利用できる状態を確保しつづけなければ、ビジネスへの悪影響につながりかねない。
そこで注目されているのが、ソフトウェアエンジニアリングのアプローチで、サービスの信頼性を制御し、ユーザーの期待に応える「SRE」（Site Reliability Engineering）の取り組みだ。
日本で大規模なITサービスを運営するLINE、メルカリ、クックパッド、ディー・エヌ・エー、サイバーエージェント、リクルートの6社は、2022年3月12日に「6社合同SRE勉強会」をオンラインで開催した。本勉強会では、各社でサービス運用に関わるエンジニアが自社でのSREに関連した取り組みを紹介すると同時に、他社のエンジニアとの質疑応答を通じて知見が共有された。本稿ではLINEでSREを務める加藤俊弥氏が講演した内容をお届けする。
1年に1回の「あけおめLINE」――LINEスタンプのアクセス数は通常時の約9倍
日本をはじめ、主にアジア圏の国々でコミュニケーションサービスとして高い人気を誇る「LINE」。LINEには「LINEスタンプ」と呼ばれる機能がある。特に日本においては、元日の午前0時に新年のあいさつとしてLINEスタンプを送信する通称「あけおめLINE」と呼ばれる習慣があり、0時ちょうどに大量アクセス（スパイク）が発生する。1分前の23時59分のアクセス数と比較すると約9倍に上るという。
2021年の元日はスパイクによる過負荷に耐え切れず、サービスに障害が発生してしまった。LINEスタンプのチームでは、2021年の障害を教訓に準備と体制づくりを進め、2022年の元日は、大きな障害なしにあけおめLINEによるスパイクを乗り切った。加藤氏は過負荷による障害を防ぐ準備と対応をどのように進めたのか紹介した。
加藤氏はまず、発表の前提として、LINEのシステム構成や組織を紹介した。LINEスタンプのシステムはアプリケーションのマイクロサービス化を進めており、現在50を超えるマイクロサービスで構成されているという。同社では、全社横断の開発運用部隊とは別に、サービスごとに企画、運営、デザイン、サーバサイド開発、クライアント開発、フロントエンド開発、QAなどのメンバーがチームとして組織されている。加藤氏はLINEスタンプおよび関連機能のサーバサイド開発チームとしてSREの役割を担っているという。
「LINEスタンプが提供する機能は、主にスタンプの『提供者向け』のものと『利用者向け』のものの2つに分けられ、さらにドメインごとにサービスが分離されている」（加藤氏）
普段からのパフォーマンス向上を目的にした設計は、リアクティブプログラミングを実現するJavaライブラリ「RxJava」とマイクロサービスフレームワーク「Armeria」によるノンブロッキング実装だ。特定の処理が遅延しても他のAPIが影響を受けにくくしている他、システム間通信を実現するための「Thrift RPC」およびクライアントサイドロードバランシングの導入、ローカルおよびリモートでの多段キャッシュなどがある。
サービス全体の負荷が高まった場合、動的にAPIの呼び出し数を制限する「Throttling」は特定のAPIに対するリクエストの成功／失敗の割合をゲートウェイサーバで設定しているという。これは「個別のマイクロサービスに対して安易にThrottlingを実施すると、他のマイクロサービスへの影響による連鎖障害リスクが高まるため」（加藤氏）だとする。
事前の対策が難しい「過負荷」に立ち向かう
ここからは、あけおめLINE固有の対策が紹介された。あけおめLINEによるスパイクは、時間をトリガーに発生する。これは、日本のあけおめLINEの次は台湾で、台湾の次はタイと各国の時差により1時間ごとにスパイクが発生することを意味する。加えてスパイク前後の数時間は、キャンペーン施策などスタンプの売り上げが急増するタイミングでもあり、障害対策の重要性はビジネスの観点でもますます高くなる。
あけおめLINEは1年に1回しか発生しないイベントなので、1年間に実装された新機能のパフォーマンスに関するデータが蓄積されていないことや、リアーキテクチャや実装方法の変更が負荷にどのような影響を及ぼすのかが見えづらく、事前に予測を立てるのは難しいという。
2021年の元日に発生した過負荷による障害の原因は、そうした新機能の追加にあった。具体的には、スタンプキーボードに実装された「送信しようとしているスタンプの作者による最新スタンプの表示」のデータがキャッシュされておらず、アクセスがあるたびに検索エンジン「Elasticsearch」を呼び出していた。
通常時のアクセス数で問題は発生しなかったが、あけおめLINEによるスパイクでバーストし、過負荷に陥ったという。現在は、データが取得できなかった場合でも、スタンプ送信には影響が出ないよう改善されている。
2022年のあけおめLINEに向けては、2021年に発生した上記のような障害対策に加えて、アクセス数の実績に基づく予測や、監視および対処の体制づくりなどにも今まで以上に取り組んだという。
統計的手法を活用してアクセス数を予測
第一に「予防」として重点的に取り組んだのは、2021年に障害のあったElasticsearchに対する過剰なアクセス数を減らすことだ。キャッシュの追加やクライアントサイドのコード変更に加えて、Elasticsearch自体をデュアルクラスタ構成にすることでアクセス集中時の負荷を下げられるようにした。あけおめLINEは、時間が限定されたイベントなので、終了次第、サーバをスケールインすることでリソースコストも軽減できるよう考慮したという。
また2021年の元日に起きた障害では、Elasticsearchだけでなく、ゲートウェイサーバでも過負荷が発生していたことをログから突き止め、JVMアプリケーションのプロファイルを取得できる「async-profiler」を使ってボトルネックも分析した。結果、原因がJWT（JSON Web Tokens）のlocal verificationであったことが分かったため、セッションストアを利用したremote verificationへ変更するなど対処したという。
「特に、2021年に発生した障害の要因となっていた部分には、慎重に対応した」（加藤氏）
「予防」における次のポイントは、あけおめLINEで発生するアクセス数の予測だ。「予測のために利用できる、信頼性が高いデータを十分に蓄積することが難しい」という課題に対処するため、LINEでは「CAGR（年平均成長率）」と「通常時のアクセス数の前年比」という2種類の指標を併用した。
前者のCAGRは、最低2年分の過去の元日におけるデータをもとに算出し、後者は過去2年の10月第2水曜日のアクセス数の比率を、前年の元日のアクセス数に掛けて算出する。それらを比較した際の「最大値」を予測値としたという。
「予測の目的は“正確に予測する”ことではなく、“サービスの過負荷による障害を防ぐ”こと。そのため、両者のうち大きい値を予測値として利用した。アクセス需要データが不十分なサービスは、予測精度に対する自信の程度なども加味しながら、安全マージンを取る形で調整した」（加藤氏）
システム全体のボトルネックは「確認するのではなく、デザインする」という方針で対応したという。具体的には、スケールアウトで線形にパフォーマンスを向上できる「CPUリソース」がボトルネックとなるよう、各マイクロサービスのCPU利用状況を統計的手法でチェックし、必要なサービスを調査したという。
利用状況のチェックは、各マイクロサービスの「リクエスト数増加量」を「CPU利用率増加量」で割った値に対し、外れ値の検定手法である「スミルノフ・グラブス検定」を実施。他のサービスと比較し、リクエスト増加率に対するCPU利用率の増加が極端に大きいサービスを発見するという方法を採用した。
「外れ値として発見されたサービスに対し、ヒープメモリをスケールアップして、頻繁なガベージコレクションによるCPU利用率の増加が起こらないよう対応した。結果、対応した場合に想定されていた100VM（仮想マシン）以上の増設を回避できた」（加藤氏）
準備に手間と時間がかかる重要なサービスの負荷試験には、通常時のユーザーアクセスを利用した。サーバをスケールインし、負荷を特定のノードに偏らせてエラー率やレイテンシを確認するという方法だ。この試験の結果に基づき「CPUの利用率が70％以上になっていれば問題なしと判断した」という。
「LINEでは、モノリシックなサービスからマイクロサービスへの移行作業を進めているが、その過程で、元のサービスから切り出したマイクロサービスへの転送プロキシを設定する。このプロキシがその後も残されたままになるケースがあり、無駄なトラフィックの原因になっていることもあった」（加藤氏）
問題になっていそうなコードを読んだり、コードオーナーに直接状況を聞いたりなどして、対応可能な部分を特定していったという。しかし、この地道な対応によって、対応しなかった場合に想定された250VM以上の増設を回避できたとする。
事前の「ワークショップ」でビジネス判断を含めた対処方法を検討
大量アクセスが発生する元日に備えた「検知」体制の構築も紹介された。
サービス状況を監視するために待機する人員は「スタンプ関連」「LINE STORE関連」「画像配信関連」といったサービスのコンテキストごとに配置し、1回の過負荷で全待機人員の稼働が奪われないように考慮した。また監視用ダッシュボードは、サービスのコンテキストを意識し、互いに影響を与えやすいマイクロサービスを、ダッシュボード上でも近くに配置するように工夫したという。
ダッシュボードの設計に当たっては、全社向けに提供されている「Prometheus」に過大な負荷をかけずに、安定して監視できるように「Grafana」のパネル機能をサービスごとに利用した。不要なグラフのパネルを閉じることで、GrafanaからPrometheusにクエリが発行されないよう工夫した。
過負荷が発生してしまった際の対処方法を記載した「Playbook」も事前に準備した。ダッシュボード上のグラフでは「予測したアクセス数」「安定して処理できるアクセス数」の目安と、実際のアクセス数がリアルタイムで確認できるようになっている。これらの指標を超えたアクセス数になった場合の対処方法をPlaybookにまとめておくことで、現場の待機メンバーが即座に適切な対応ができるようにしておいた。
待機メンバーが状況に応じて実施する「対処」については、ステークホルダーを集めた「ワークショップ」で、事前にシミュレーションしたり、「Load shedding」（特定サービスへの一時的なアクセス制限）の方針を決めたりしたという。
ワークショップでは、開発環境を利用して「サービスに過負荷が発生した」との想定で、APIへのアクセスを制限して、動作を確認した。アクセス数が多いAPIから順に確認し、それがユーザーにどのように影響を与えるかを吟味し、Load sheddingの優先度を決めていったという。ここで決定した優先度と対応は、前出のPlaybook上に記述され、過負荷発生時には、各現場の担当者が自分の判断でハンドリングできるようにしていたそうだ。
サービス全体の信頼性を高める取り組みとして評価
今回の取り組みでは、SRE担当者だけでなく、各分野の開発担当者などからも協力が得られたことで、比較的短い期間と少ない人員で対応できたという。
加藤氏は良かった点として「Load sheddingのためのワークショップ」「統計的手法を活用したチューニング余地のあるマイクロサービス検出」「Elasticsearchのデュアルクラスタ化」の3点を挙げた。
「SREとして担当していると『ここまで準備したのだから、障害は起こらないはずだ』という正常性バイアスに捕らわれがちになる。ステークホルダーを集めてシミュレーションすることで、バイアスの影響を受けずに障害時の対処を検討できた点で有意義だった。あけおめLINEを契機に始めた対策だったが、それ以外でも役立つ取り組みだったと感じている。2023年以降のあけおめLINEもユーザーの信頼を損なわない形で乗り越えられるように準備したい」（加藤氏）
本勉強会では、各担当者の発表後に「Ask the Speaker」として、発表者と他企業のSRE担当者による対談の時間が設けられた。発表中に視聴者から寄せられた質問に対する回答なども、この時間で行われた。このセッションでは、リクルートでエンジニアリングマネージャーを務める近藤健司氏がAsk the Speakerを担当した。
「マイクロサービス化の過程で残されがちなプロキシを取り除くことによる無駄なトラフィックの削減が興味深かった。そもそもプロキシの問題点を発見できたことにすごみがある」と言う近藤氏に対し、加藤氏は「これは『マイクロサービス化あるある』でもある。作業の過程でプロキシ化まで進むと、そこで満足してしまいがち。タイミングを見てプロキシの整理はしておくべきだ。LINEの場合はあけおめLINEの予測値ベースで、増設が必要になるサーバ数を算出した。特定のサービスであまりにも増設数が多くなる場合、コードオーナーにチューニングの余地がないかどうかを相談した。まずは見積もってみて、コスト面で大きな影響がなければ、そのままにしておくという選択肢もある」とした。
「ノード当たりのリクエスト数が、当初に設定していたしきい値を超えた場合の対処は、どのように決めていったのか」という参加者の質問に対し「LINEはバックグラウンドでの同期処理は多いが『レコメンド』の内容が多少古くても表示されていればユーザーへの影響は低減できると考えていた。もし、過負荷が起きた場合には、ユーザーに与える影響が小さいサービスから、優先的にThrottlingしていくように決めていった」と回答した。
最後に近藤氏はLINEでの取り組みに対して「ワークショップという形式を採るのは非常に良いと思う」と評価した。それを受けて加藤氏は「実際には、30〜40人のサービス関係者をZoomに集め、APIのアクセス順にThrottlingしながら、ビジネス判断を含む優先順位付けを進めた。大掛かりに聞こえるかもしれないが、準備を含めてかかった時間は2日程度。好評だったこともあり、今後も半期や四半期ごとに開催したいと思っている。今後はカオスエンジニアリングを本番でやるような、ちょっと攻めたことにもチャレンジしていきたい」と述べ、セッションを締めくくった。
Copyright © ITmedia, Inc. All Rights Reserved.