5万台以上の物理サーバーをどのように管理するか　インフラ環境でインシデントが発生したときの仕組みづくり

本日のアジェンダ

松本幸大氏：このセッションでは、LINEが構築・運用を行っている数万台の物理サーバーについて、このような膨大な数のサーバーをどのように運用しているのかについて紹介したいと思います。

まず簡単に自己紹介させてください。私は松本といいます。2019年にLINEに新卒として入社しました。現在はLINEのSystem Development Teamでインフラエンジニアとしてサーバーの運用全般に携わりながら、運用の自動化を目的としたツールの開発や、それらに付随したモニタリングなどの社内システムにおける設計・開発・運用などを主に担当しています。

（スライドを示す）このセッションのアジェンダはこちらです。このセッションでは、主にLINEでどのようにして膨大な数のサーバーの運用を日々行っているかを紹介します。まずサーバー運用の話の前に、そのバックグラウンドとして、LINEのインフラがどのようなものなのかについて簡単にご紹介したいと思います。

次に日々、実際にどのようにサーバーを運用しているのかを紹介していきたいと思います。

次に「New Year / COVID-19」ということで、LINEが毎年経験しているNew Yearの対応と、昨今のCOVID-19によってLINEのサービスがどのような影響を受けたのか、それに対してどのように対応を行ったのかを、主にサーバーインフラの観点からお話ししたいと思います。

そして最後に「Next Step」、LINEが現在取り組んでいるサーバーの運用を改善する、さらに高度にサーバー運用を自動化するためのプロジェクトについて、簡単に紹介したいと思います。

物理サーバーで5万台以上のLINEのインフラ環境

最初に「LINE Infrastructure」ということで、LINEのインフラ概要についてお話をしていきます。

LINEでは現在、メッセンジャーをはじめ、「LINE MUSIC」や「LINEマンガ」など、さまざまなLINEファミリーサービスを展開しています。そして、これらのほとんどは、LINEが自社で構築運用しているオンプレミスのインフラ環境で、稼働している状態です。

また、「Verda」と呼ばれるOpenStackベースのプライベートクラウドサービスも運用していて、例えばメッセンジャーやLINE MUSICなど社内のデベロッパーがVerdaを通して必要なときに、より簡単にインフラリソースの利用を開始できるような仕組みが整えられています。

これらLINEのインフラ・スケールですが、LINEには現在大きく2種類のインフラ環境が存在しています。1つ目が先ほど紹介した「Verda」と呼ばれるOpenStackベースのインフラ環境。2つ目が、Verdaが登場する以前から構築と運用が行われていた「レガシー」と呼ばれる旧来のインフラ環境が存在します。

これらの2種類のインフラ環境を合わせると、そのスケールは物理サーバーで5万台以上、仮想サーバーで6.7万台以上。これらのサーバーから発生してくるユーザートラフィックは、ピーク時で3Tbpsを超えてきて、非常に大きなスケールになってきています。

（スライドを示す）こちらのデータは、LINEにおける直近6年間の物理サーバー台数の推移のデータです。LINEではこれまで新規サービスのリリースやサービスの利用者の増加に伴って、サーバーだけではなくネットワークなどさまざまなインフラの増強を繰り返してきました。

特にここでは、物理サーバーについて着目していますが、直近1年間で見ると、年に1万台ぐらいの規模で物理サーバーが増加しています。このようなペースで成長しているLINEのサーバー運用では、これまでにさまざまな問題がありました。

例えばサーバーの台数が増えれば、当然インシデントの件数も増加します。そのインシデントをどれだけ効率的に対応するかという部分や、インシデントの対応品質を標準化する部分の問題と、それらに対する改善を行ってきました。

サーバー運用における役割分担

ここからは、このような環境の中で、LINEのサーバーインフラが実際どのように運用されているのか、また、どのように改善されてきたのかを話していきたいと思います。

それでは、LINEのサーバーがどのような人たちによって運用されているのかを、それぞれのRole（役割）に分けてお話しします。

1つ目のRoleが、サーバーを実際に使用してサービス提供を行う「LINE Developer」です。LINEでは、現在さまざまなサービスを提供しているのですが、それぞれのサービスごとに担当する「Developer（開発者）」と呼ばれる方たちが存在しています。

それぞれのDeveloperは、例えばVerdaなどからサーバーの調達を行って、サーバーに対して必要なアプリケーションであったり必要なミドルウェアなどをデプロイすることによってLINEのサービスを提供しています。

2つ目のRoleが「IDC Operator」と「System Engineer」です。まずIDC Operatorからお話しします。IDC Operatorは、その名のとおりIDCに24時間365日体制で常駐して、サーバー運用を行う上でどうしても発生する、現地で作業を行う専門のチームです。ラックマウントをはじめ、サーバーのケーブルの結線作業など、サーバーに関するあらゆる作業を行っています。

2つ目のSystem Engineerは、LINEの所有している全サーバーに対して、OSとハードウェアのレイヤーに責任をもつ、サーバー専門のチームです。

LINEでは、すべてのサーバーにおける構築と運用を、すべてSystem Engineerという専門のチームが一元的に行っています。これによって、例えばOSであったりハードウェアであったりの、設定方法や運用の方法の標準化を行っています。System Engineerの担当範囲は、非常に多岐にわたるのですが、主にDeveloperへ安定的にサーバー提供を行うことをミッションとしています。

System Engineer のタスク

System Engineerが実際にどのような部分、タスクをこなしているのかというところを詳しく紹介します。大きく「Purchase」「Setup」「Operation」という部分に分けてお話ししますが、例えば「Purchase」のサーバーを購入するフェーズであれば、サーバー自体の選定、サーバーのパフォーマンステスト、あとはキャパシティマネジメントの部分も担当しています。

「キャパシティマネジメントって何だ？」と思うかもしれませんが、キャパシティマネジメントというのは、突発的なサーバーの需要が発生した際に、柔軟にそれらに対応できるようにするための取り組みです。

LINEでは、Developerからのサーバー要求があるたびに、その都度サーバーを調達するのではなくて、ある程度の中長期的なサーバーの需要予測や利用予測を立てて、自社である程度のサーバーの台数を在庫としてもって、それらに柔軟に対応できる取り組みを行っています。これが、キャパシティマネジメントと呼ばれる部分です。

サーバーを構築するフェーズであれば、OSやハードウェアのセットアップ、あとはそれらを自動的に行うOSのインストーラなどの開発もSystem Engineerが担当しています。また、現在ではほとんどが自動化されているのですが、運用のフェーズであれば、モニタリングや障害対応時のトラブルシューティングなども対応します。

これら3者をモニタリングの観点から見ると、System EngineerとIDC Operatorは、サーバーの中でも主にハードウェア関連のモニタリングを担当しています。ハードウェア関連のアラートが発生した際に、例えばディスクやメモリなどクリティカルなものが発生した際には、Developerからの問い合わせがなくても、自動的にそれらインシデントに対応開始するような仕組みになっています。

またDeveloperも、モニタリングを一切していないわけではなくて、アプリケーションやサービスの正常性モニタリングを行っていて、Developer側でサーバーの異常を検知した際には、IDC OperatorやSystem Engineerに問い合わせ、同様に対応する体制になっています。

これらモニタリングのスケールですが、サーバーだけで11.7万ホスト、1日あたりのsyslogの行数はだいたい20億行ぐらい、1月あたりのハードウェアインシデントの件数は、だいたい500件ぐらいになっています。このハードウェアインシデントは何の数字かというと、サーバーに対してなんらかの問題が発生して、それらになんらかの対応、例えばパーツを交換するみたいな対応をした件数です。

ハードウェアインシデントの初期の運用フロー

ここからは、このハードウェアインシデントの部分について、LINEではどのようにして対応しているのか、実際の運用フローについてお話をしたいと思います。LINEのサーバー運用改善の時系列に沿ってお話をしていきます。

初期のLINEサーバー運用では、主にメールとエクセルを使用した手動作業を前提とした運用を行っていました。例えば、IDC Operatorが24時間365日体制でモニタリングを実施していて、なんらかの異常を検知した際は、メールを使用してSystem Engineerにエスカレーションしていました。

すべてのインシデントはエクセルを使って管理されていて、「Operation Document」と呼ばれるサーバーの情報が集約されているドキュメントから、インシデントが発生するごとに毎回情報を探し、個別に対応を行っていました。

Operation Documentは何かというと、ホストネームのプレフィックスから、例えばそのサーバーがどのサービスで使用されているのか、そのサーバーを担当しているDeveloperは誰なのかというような情報がわかるようになっているものです。

Server Operation v0では、インシデントごとに対象のDeveloperを毎回探してきて、個別にコミュニケーションを取って、じゃあこのインシデントにどのような対応をするのかというのを毎回相談する、というようなフローをとっていました。しかしながら、このような運用フローはエンジニアによる手動の作業が前提とされていて、非常に非効率的なものとなっていました。

1つ目に、コミュニケーションコストが非常にかかるという部分です。インシデントが発生するごとに毎回Developerと調整する必要があって、非常にコミュニケーションコストがかかっていました。それに加えて、IDC OperatorとDeveloperが直接会話する手段がなく、間にいるSystem Engineerが伝言ゲームをする状態になってしまうこともありました。

また、インシデントを管理していたエクセルには、サーバーに関する最低限の情報しか記載されていないため、誰がそのインシデントに対応しているのか、誰がアサインされているのかといった部分がわからなくなってしまうことも、しばしばありました。

Operation Documentの部分に関しては、Not User-friendlyと（スライドに）書いていますが、このOperation Documentが単にサーバーの情報が羅列された1枚のドキュメントにすぎなかったので、サーバーの台数やサービスの種類が増えていくにつれて、毎回必要な情報を探すこと自体にも、大きなコストがかかるようになりました。

Operation Documentも、あくまでサーバーの情報・連絡先がまとまっているのみなので、例えばインシデントの内容が同じであっても、対応するエンジニアによって対応方法がバラついてしまうという、品質面での問題もありました。