LINEが求める価値
イ・スアン氏：LINE Platform Engineering 3センターのイ・スアンと申します。本セッションでは、3つの内容を紹介したいと思います。1つ目はLINE PlatformがなぜReliabilityを重要視しているのか、2つ目は問題が発生した時に対応するプロセス。最後に、このすべてを支える開発者文化を紹介したいと思います。
発表を始める前に、LINE PlatformのServerについて紹介します。LINE PlatformのServerは、LINEアプリが生まれた時から存在したプラットフォームです。次のようなラインナップに必要な機能を担当しています。このプラットフォームは、100人あまりの多国籍メンバーが、共通の開発文化のもとで発展させています。
発表者の私も、LINE PlatformのServer組織の黎明期から一緒でした。組織を代表して、ここ10年間で発展させてきたプラクティスと文化を紹介いたします。
「Life on LINE」とは、LINEが求めるビジョンになります。LINEはユーザーの生活にも必須のサービスになりました。ユーザーの生活インフラとして、LINEは信頼性のあるサービスを提供しなければなりません。Reliabilityとは、ユーザーの期待に応えることです。ユーザーの期待に応えるためのReliabilityは、LINE PlatformのServerが求めるべき重要な価値として考えています。これを達成するために、障害を徹底して管理しようと考えています。
ユーザーが直接的に経験する問題や、内部システムが期待したとおりに動作しないことをOutage、障害と言います。2021年、LINE PlatformのServerの障害件数を集計すると、このようになります。障害がランダムに発生していることがわかります。2月、5月には障害がなかったのですが、8月には何があったのか、障害が多かったんですね。
やはり障害はつきものです。LINEが作られてから10年が経ちましたが、過去のグラフを見ても、似たようなかたちになると思います。我々は、障害は避けられない、と考えています。ですので、障害を恐れるのではなくて、障害を通じてプラットフォームの信頼性をより改善する貴重な糧にするのが、LINEの開発文化になります。
LINE PlatformのServerの障害対応プロセス
それでは、LINE PlatformのServerはどうのように障害に対応して障害から学ぶのか、その体系を紹介します。LINE PlatformのServerの障害対応プロセスを要約すると、以下ようになります。
問題が検出されたら、担当者に迅速に連絡をします。そのあと担当者は、問題の分類と発信をし、同時に修正を行います。これが、障害対応の重要段階になります。障害が解決したら、問題状況に関してまとめて共有します。ステークホルダーが集まって結果をレビューして、改善点を議論します。
各段階を詳細に紹介します。障害は、モニタリングを通じて自動検出された際、迅速にシステム担当者がその障害について把握しなければなりません。もし障害を検知する担当者以外の別の誰かが不具合を確認した場合、本人自らがシステム担当者に連絡をして、それに対応できるようにしなければなりません。そのために、連絡ポイントを管理しています。責任者と報告チャンネルを簡単に確認できます。
そのあと障害分類段階になります。障害に対して影響度を簡単にコミュニケーションしたり、自己分類の管理のための用途としてレベルを付与しています。障害レベルの明確な分類基準をプロダクトごとに持っています。障害発生時には、障害レベルの情報が共有されます。事後に内容はアップデートされたりします。
右側は、我々が実際に使っている障害レベルを指定するための表です。この基準の表は、ユーザーに機能を提供するサービスプラットフォームで使っています。DAUという、LINEで使っているユーザーの数を表す指標ですが、数字をもとに、影響するユーザー数をカバレッジで分類します。
問題が生じた機能の種類とステータスを基準に、深刻度を決めます。この2つの情報を基盤に入れてレベルを決めます。障害の発生に対して、迅速な伝播、発信と拡張の体系を作るのが重要です。LINE Platformはお互いに綿密な関係を持っているのですが、障害の状況を伝播するために、特定のチャンネルを通じて内容を発信します。このチャンネルを通じて、障害情報が拡張されます。
共有チャンネルを通じて、関連するサーバーの担当者は追加の影響度を確認します。また顧客対応部署では、問題を認識して顧客対応ができるように準備します。作成しやすく理解しやすくするために、我々はテンプレートを基盤にして、共有内容を管理しています。右側の項目は、実際に我々が使っている共有テンプレートになります。
障害復旧は、障害対応の重要過程です。障害の種類や影響によって、対応方法が違います。迅速に問題の影響度を減らす方法で対応します。また原因の把握も行います。障害に関連する部署のリーダーが、障害対応の総責任を取ります。リーダーの指示に従ってメンバーは対応をして、対応状況をリーダーに報告します。障害処理が長引く場合には、追加の状況を発信するのもリーダーの責任です。リーダーがすべてできない場合は、共有を担当する担当者も指定できます。
障害対応のあと、1勤務日以内に一次報告をするのが原則です。報告書が作成されたら、特定のメーリングリストを通じて内容を共有します。報告の内容は、テンプレートで整理されています。右側に書かれている内容を参考にください。
テンプレートの内容は次のようになっています。非開発部署でも内容を理解できるように、障害に関する要約情報を記述します。そのあと開発者が詳細な情報を確認するために、サービスのステータスや対応、履歴などを記述します。
障害に対して、次の3つの観点で点検をします。改善が必要な内容を記述します。1番目の観点は再発を防止するもの。2番目は障害を速く検出するようにする改善の観点、3点目は障害対応そのものの観点です。
各改善項目はアクションアイテムのかたちで登録されています。これは、開発チケットで登録されて管理されています。
障害の振り返りは、障害復旧のあと5勤務日以内に設定されます。できるだけ多くの人々を招待して参加を促しています。さまざまなフィードバックをやり取りしながら、追加の改善点を導き出します。そのあと、報告書の内容を確定して障害対応を終わります。
ここまでで、障害対応プロセスを紹介しました。このプロセスはある程度強制力があり、振り返ってみると、ちゃんと守れていると思っています。開発者文化に基づいているプロセスなので、維持できるのだと考えています。
Reliabilityに関連する開発者文化
Reliabilityに関連する開発者文化を紹介します。Reliabilityを保証する一番簡単な方法は、開発初期段階からそれを考慮することです。なのでLINEは、黎明期から同僚からの厳しいコードレビュー文化が形成されていて、現在も維持されています。コードレビューは、GitHubが最初に導入された時に定着した開発文化の1つだと覚えています。
レビュアーに役立つためのデザイン文書を提供して、その文書をレビューするプロセスを経て、内容を確認する文化が形成されています。最初はテストコードが多くなかったのですが、今はテストコードなしではコードレビューがパスしにくい開発者文化構築されています。
追加でシステムによっては、ユニットテストとともに、インテグレーションテストのかたちのEnd to Endテストも管理しています。こうテストケースを通じて、コードレベルに発生し得る問題を予防しています。これは障害再発防止策として、頻繁にテストコードに言及したのも原因ではないかと考えています。
問題状況を検出するモニタリング条件
LINE PlatformのServerは、問題状況を検出するさまざまなモニタリング条件があります。特定条件に達したら開発者にアラームが届きます。この時、誰かがアラームに反応して対応しなければなりません。こういうアラームに関して、開発者間で巡回して対応することをOn-Call Dutyを言います。我々はこの制度を通じて、アラームに対して一番適切に対応できる開発者が、常時対応できるシステムを運営しています。アラームを通じて確認された、小さい問題が大きい障害に拡大されるまえに防止しています。
障害の振り返りにおけるすべてのアクションアイテムは、チケットとして管理されると言いました。開発者は、障害チケットも他の開発作業と同じく対応します。こういう種類のチケットは、簡単に技術負債になることがあります。なぜなら、障害対応が終わったら、みんなの関心度が低くなるからです。そして同じような原因で障害がまた発生したら、その時に処理されていなかったチケットはまた注目を浴びることになります。
こういう経験を通じて、Outageチケットをちゃんと管理する重要性を認識しました。このため我々は、OKRという方法を使っています。組織の共通OKRとして、障害チケットを解決しようという目標を設定しました。この伝播と実行に関しては、OKRのcascadingを使っています。各チーム内で組織の共通の目標につながるように、チームの状況に合わせた目標を再定義します。
こういうプロセスを経て、Outageチケットを解決するのが共通の価値だということを、再認識できるようになります。
それから実行のためには、チームの状況に合わせて方法を議論します。チームでどうするのか決めて実行しています。先ほど説明した障害対応のチケットに関しては、現在管理ステータスを共有します。
2021年1月から9月まで、242個のアクションアイテムがチケットとして登録されました。現在は83％のチケットが解決済みか進行中の状態です。他の開発業務の負担がある状態でも、我々はこの数字が意味のある結果だと考えています。
対応プロセスの実例
先ほど紹介しました対応プロセスの実例を紹介します。8月4日ごろ障害共有チャンネルに共有された件になります。これに関連する障害報告書の内容の一部を紹介します。
障害報告書の情報には、障害に関する要約情報が記述されています。左側に障害対応の分類情報、右側に障害対応の影響度の情報が要約されてまとめられています。
内容を見てみると、API Requestを仲介するプロキシサーバーの設定ミスにより、バックエンドサーバーが再起動された時、リクエストコントロールが正常的に行われなかったのが問題でした。これにより、サーバーの再起動が発生した時、再起動されたサーバーが不安定に動作したのが問題だった、という内容が記述されています。
障害報告書の次の部分は、詳細の内容を記述しています。見てみると、問題が発生した時点でログの発生量、それから失敗したAPIのステータスを表すさまざまなメトリクスを記述して、詳細な影響範囲を書きます。また影響されたユーザー数や失敗したAPIの数や種類などが記述され、状況を確認できます。
障害の発生と復旧に関連する詳細な情報をタイムラインに書きます。できるだけ詳しく書きます。実際のタイムラインには多くの情報がありますが、障害に関連する情報を一部抜粋してきました。見てみると、障害の原因になった変更が発生した時点、問題が発生した時点、それから認識されて障害の問題の解決を始めた時点、復旧が完了した時点が書いてあります。
実際の障害報告書には、より詳しい処置事項が書いてあります。最後に障害の再発防止のためのアクションアイテムがまとめられています。実際の障害報告書には、各項目が業務用のJIRAチケットとして登録されています。すべてのチケットが実行可能でなければならないのですね。
内容を見てみると、このようになっています。障害防止のためにプロキシサーバーにヘルスチェック機能をオンにするように書いてあります。障害探知・改善の観点では、今回の障害ではアラームで問題が確認されましたが、障害があったのにアラームが発生しないことを確認して、それを補強する必要があることが記述されています。
また障害対応の観点では、障害の復元のプロセスについても詳細を記述して障害対応として改善するべきの内容を把握して、それを改善するようにとまとめられています。このように、我々は障害を通じて改善策を導き出して持続的に発展させています。
10年間で得た教訓
10年間で得た教訓を説明します。1番目は「プロセスは壊れやすい」ということです。なぜならプロセスは解釈の余地なく、すぐに実行可能なかたちで整理されないとダメだからです。プロセスに関連する周りの状況は、変化が生じる可能性があります。変化が生じたら、その変化に合わせて、プロセスを引き続きアップデートしないとダメです。変化されたプロセスに対しては、プロセスが影響する人々が知らないと、プロセスは活用されません。
2番目は「プロセスは文化の基盤である」ということです。プロセスは最低限の装置でした。プロセスがいくらちゃんと整理されていても、組織がそれを認めて実行しないと何の意味もありません。
最後に、すべての問題は自律的に解決できなかったということです。Outageチケット解決は、みんなが共感する重要な意思でしたが、実際に進捗が難しかったのですね。ですので、現況を目に見えるかたちにして、定期的に進捗をチェックしながらどうすれば解決できるのかも議論しました。それから変化をリードしました。これは簡単ではなかったので、我々は今もチャレンジしているところです。
ユーザーの期待するLife on LINEが行えるように
最後に今日説明した内容をまとめてみます。LINE Platformの組織は、ユーザーの期待するLife on LINEが行えるように、Reliabilityを重要な価値として運営しています。このため、問題状況に備えるプロセスを明確にしています。また自主的に発展する開発者文化は、開発および運営段階でReliabilityを保証できるようにしています。
これを通じて、障害を恐れるのではなく、障害を通じてプラットフォーム内製を高めるための貴重な経験にしています。Reliabilityは、LINE PlatformのServerの変わらない重要な価値になると考えています。我々はプロセスと文化を持続的に育てて発展させていきます。本セッションを通じて、LINE PlatformのServerに対するみなさまの信頼が高まってほしいです。ご清聴ありがとうございました。
