「COVID-19」「あけおめ」で増えるトラフィックにも対応　チケットシステムとIOCで急なインシデントからサーバーを守る

チケットシステムとIOCの導入

前編までで紹介した問題点を踏まえて、Server Operation v1では大きく2つの仕組みが取り入れられました。1つ目がチケットシステムです。Server Operation v1では、すべてのハードウェアインシデントの対応にチケットシステムを導入して、すべてのインシデントが、チケットベースで処理されるようになりました。

2つ目がIOCと呼ばれるシステムの導入です。詳しくは後ほど説明しますが、IOCはLINEが独自に設計・開発を行っているシステムです。サーバーのインシデントが発生したときに、どのような作業をする必要があるのかを、Operation Manualという形で事前に記述して、それらを集中的に管理するシステムです。

それでは、チケットシステムとIOCについて順番にお話ししていきます。まずチケットシステムからです。繰り返しにはなるのですが、LINEでは現在すべてのハードウェアインシデントがチケットベースで処理されるようになっています。

チケットにはハードウェアインシデントの内容をはじめ、サーバーのスペックや設置されているIDC Regionなど、さまざまな情報が集約されています。これによってチケットを見るだけで対象のサーバーでどんなインシデントが発生しているのか即座に把握できるようになっています。

また、チケットシステムを導入したことによって、コミュニケーションの部分に関しても改善されました。チケットシステムが導入される以前は、メールやさまざまなチャットツールにまたがってコミュニケーションが行われていたため、非常に非効率なものとなっていました。

チケットシステム導入後は、インシデントに関するコミュニケーションをすべてチケットのコメントに集約し、Developer、IDC Operator、System Engineer、それぞれのキューとなるステータスを用意しました。

これによってそれぞれの担当者は、自身の対応するキューをウォッチするだけで自分が今処理しないといけないインシデントを即座に確認・把握できて、円滑にインシデントの処理ができるようになりました。

また、コミュニケーションのログであったり、どのような対応をしたのかというようなログがチケットとして残り続けるため、過去のチケットをインシデント対応のナレッジとして蓄積できることも大きなメリットです。

このようにして、チケットシステムの導入により、各担当者間のコミュニケーションとインシデント対応を大幅に効率化させることができました。

LINEが独自に設計・開発した「Infra Operation Center」

続いてIOCの部分についてです。IOCは「Infra Operation Center」の略で、LINEが独自に設計・開発を行っているシステムです。

このIOCは、大きく2つの機能をもっています。1つ目の機能がサーバーのグルーピング機能です。その名のとおり、複数のサーバーを特定の条件ベース、例えばホストネームやサービスの種類などの条件ベースでグループ管理できます。

2つ目がOperation Manualを集中管理できる機能です。Operation Manualは、特定のインシデントが発生した際に、各担当者がどのような作業を行うべきなのかというのをマニュアル、いわゆる手順書のような形で記載したものです。

従来のServer Operation v0では、インシデントごとに毎回Developerとどのような対応を行うかを相談していましたが、IOCではサーバーグループごとにOperation Manualを事前に定義して、万が一インシデントが発生した際には、自動的にインシデントの対応が開始できるようになっています。

例えばIDC Operatorがアラートを受信した際に、「どんなアラートが発生したのか」や「どのサーバーのホストネームでアラートで発生したのか」を大まかに把握できます。

これらの情報をIOCへインプット情報として渡すと、IOCの内部ではインプットとして渡された情報の中から対象のサーバーに関する付加情報、メタデータを収集してきます。例えばインシデントを行おうとしている現在の時刻が12時であるというような情報であったり、サーバーの種類がハイパーバイザーであるというような情報です。

ではなぜこういう条件を考慮しないといけないのかというと、例えばサービスのピークタイムを避けてメンテナンスを実施する必要があるサーバーであったり、ハイパーバイザーの場合は当然ハイパーバイザー上のVMを考慮する必要があるなど、サーバーによってさまざまな条件が設定されている場合があるためです。

IOCでは、このような複雑な条件をシステム的にすべて処理して、自動的に判別できるように設計がされています。IDC Operatorは、IOCから返答された適切なマニュアルに沿って、インシデントの対応を即座に開始できるようになっています。

これによって、インシデントの対応方法の標準化を行うとともに、不要なコミュニケーションコストを削減してサーバーが運用できるような体制になりました。

「Incident-Initiator」と「Incident-Closure」

しかしながら、このような改善を行ったにもかかわらず、それ以上のサーバー台数の増加やサービスの増加によって、さらなる効率化と改善が求められるようになってきました。

Server Operation v1では、「アラートからのチケットを作成する」部分と、「サーバーを手動で確認して、正常であればチケットをクローズしてインシデント対応を終了させる」、この2ヶ所の部分が、IDC OperatorとSystem Engineerの手動作業に依存している状態でした。

チケットを作成する部分については、主にIDC Operatorが担当していたのですが、複数人での運用を行っていたため、対応者によってチケット作成の品質が異なるなど、追加の問題もありました。サーバーの台数が増加するにつれて、当然インシデントの件数も増えてきますし、そのためサーバー運用を行う上で、この2ヶ所が次第にボトルネックになるようになってきました。

これらのボトルネックを改善するために、Server Operation v2では「Incident-Initiator」「Incident-Closure」という2つのシステムを新たに導入しました。これらは、両方ともLINE独自のシステムですが、名前からもなんとなく推測できるように、Initiatorがチケットを作成するシステム、Closureがチケットをクローズするシステムです。

順に説明していきます。まずIncident-Initiatorからです。Incident-Initiatorはアラートからのチケット作成を自動化してくれるシステムです。

非常にシンプルなシステムで、例えば複数のアラートシステムからイベントを受け取り、アラートが発生した際に、その内容を分析するとともに、サーバーが設置されているIDC regionなどの情報からそのインシデントを対応しないといけない適切な担当者を判断。チケットを作成する動作を行います。これによって、アラートが発生後すぐにチケットが作成されて、インシデントの対応がすぐ開始されるようになっています。

続いてIncident-Closureです。Incident-Closureは、先ほどもお話ししたように、チケットをクローズさせるシステムです。Incident-Closureはチケットがオープンな状態になっているサーバーのハードウェア情報を定期的にウォッチ、チェックしていて、サーバーのステータスが改善されている場合には、自動的にはチケットのクローズを行って、インシデント対応を終了させます。

Server Operation v1では、この部分をSystem Engineerがすべて手動で行っていたのですが、このIncident-Closureの導入によって、この部分のオペレーションコストをかなり削減できました。

自動処理で対応を終了するIncident-Closure

実際に、Incident-Closureがどのようなフローで使用されているのかを簡単に説明します。サーバーでインシデントが発生すると、IDC Operatorが一通りの対応を行います。そのあとIncident-Closureがサーバーの復旧状態を確認し、問題がなければそのままチケットをクローズして、対応を終了するという流れになっています。

万が一ステータスが改善していないようなイレギュラーなケースが発生した場合には、System Engineerに追加のエスカレーションが自動的に行われ、追加の対応が実施されるようになっています。

Incident-Closureは、このようなかたちでチケットのコメント欄にサーバーのステータスを記載すると同時に、例えばDeveloperに対してインシデントが改善したという内容や、必要であれば「サービスインをしてください」という連絡を行うようになっています。

初期のIncident-Closureでは、対応可能なチケット数が非常に限定的だったのですが、継続的にアップデートが実施されて、現在ではマルチベンダーな環境でCPU、メモリ、ディスク、ファン、PSUといった、一通りのハードウェア情報を自動的にチェックできるようになっています。

以上のような改善をたどって、現在のLINEのサーバー運用のライフサイクルは、このようになっています。過去の運用方法では、インシデント対応のほとんどがエンジニアによるマニュアルまたは手動の作業に依存していましたが、現在では一般的なインシデントに関しては、現地でのトラブルシューティングを除いて、ほとんどが自動的に処理されるようになっています。

アラートから、Incident-Initiatorがチケットを作成して、IOCのOperation Manualに沿ってインシデントの対応が開始され、Incident-Closureによってサーバーの正常性を確認後、チケットがクローズされて、インシデント対応が終了されるという流れです。

（スライドを示す）こちらは、特にインシデント対応の自動化に大きく貢献したIncident-Closureによって、どの程度のインシデントが自動的に処理されているのかというデータです。

Incident-Closureが導入された2019年9月ごろは、まだ対応可能なチケット数も非常に限定的だったのですが、アップデートを重ねた結果、現在では8割以上のインシデントが、パーツ交換などの物理的な作業を除いて、自動的に処理されるようになっています。

ここまでがLINEのサーバー運用についてのお話です。LINEではこのようにして、数万台という膨大な数のサーバー運用を日々行っています。しかしながら、現在の運用は完成されたものではなく、これからもさらなる運用の改善と効率化を図っていく予定です。

New Year対応

ではここから少し話の内容を変えて、New YearとCOVID-19ということで、LINEがどのようにしてこれらに対応してきたのかをサーバーインフラの観点からお話ししていきたいと思います。

そもそもの話にはなるのですが、サーバーのコンピューティングリソースの利用率は、常に一定なものではありません。例えば新年などのイベント時や、昨今のCOVID-19みたいな社会情勢によって、サービスの利用率は大幅に変動しますし、それに伴ってサービスから要求されているようなサーバーのコンピューティングリソースも大幅に変動してきます。

このような状況に対応できるようにするのも、System Engineerの役割になります。特にこのキャパシティマネジメントという部分で、サーバー運用のセクションでもお話をしましたが、LINEでは社内でのサーバー利用予測などから中長期的な利用予測とサーバーの在庫管理を自社で独自に行ってきました。

では、このような観点からNew YearとCOVID-19でどのような施策を行ったのかというところを簡単にご紹介したいと思います。

まずはLINEが毎年経験しているNew Year対応からです。年明けのタイミングでは、「あけおめ」の挨拶をする人も多く、各国で大量のメッセージが送信されて、通常時の数倍以上のユーザートラフィックが発生してきます。

また、LINEの場合、各国の時差によって、トラフィックの波が断続的にやってきます。ユーザー人口の多い日本もそうなのですが、例えば台湾なんかでは、新年の挨拶でビデオメッセージを送り合うような文化もあって、その際にも大きなトラフィックのスパイクが発生してきます。

このような状況に対応するために、LINEでは数ヶ月前からNew Yearに向けた準備を行っています。対象の部署と入念に打ち合わせを行い、サーバーの増設が必要な場合にはサーバーの増設を実施して、万全な体制でNew Yearを迎えられるようにしています。過去には、New Yearの対応だけで2,800台以上の物理サーバーを新規で調達して増設したこともありました。

またある年には、新年とleap second、いわゆるうるう秒の対応が重なって、サーバーの時刻のズレが発生した結果、メッセンジャーのサービスに大きな障害が発生したこともありました。そのため、現在LINEで開発されているモニタリングシステムでは、ミリセカンドオーダーの時刻監視が行えるような体制を整えています。

COVID-19の影響によるサービス利用率増加

続いてCOVID-19についてです。COVID-19による外出自粛が叫ばれる中、LINEでもサービスの利用率が増加しました。特にLINEの音声通話（VoIP）を利用したグループ通話のトラフィックが大幅に増加しました。

さまざまなSNSで、「LINE 飲み会」がトレンド入りし、特に週末にかかるタイミングでは、最大で通常時の7.5倍までトラフィックが増加しました。当時のLINEのグループ通話サービスのキャパシティは、4月に入ってからの緊急事態宣言後の急激な利用者増加に耐えられるものではありませんでした。

そのためLINEでは、この急激なサービス利用者に対応するため、緊急のサーバー増設を実施しました。最終的には、グループ通話のみで650台以上の物理サーバーを新規で増設しました。

また、COVID-19がもたらしたのは、単なるサービスの利用者増加だけではありませんでした。サーバーは非常に多くのパーツから構成されていますが、COVID-19の影響によって、サーバーのサプライチェーンにも大きな混乱が発生しました。

最初にサーバーを構成するパーツの調達が難しくなって、サーバー自体の調達にも大きな影響が発生している状態に陥りました。また、サーバー自体を輸送する手段、例えば航空便の削減など、輸送手段にも大きな問題が発生してきました。その結果、サーバー調達に通常時の数倍以上の時間がかかるような状態になりました。

しかしながら、LINEでは以前からサーバーのキャパシティマネジメントと自社による在庫管理を実施していたため、グループ通話のような緊急のサーバー増設にも対応できました。ただ、グループ通話の対応によって、非常に多くのサーバーを緊急増設として使用したので、再度利用予測を見直すと同時に、納期遅延の影響を踏まえたサーバーのキャパシティマネジメントなどの管理の強化も実施しました。

このようにして、LINEではCOVID-19下でも安定的なサービス提供ができましたが、非常にギリギリの状態であったのは言うまでもありません。

ここまでがLINEにおけるNew YearとCOVID-19における対応方法のお話です。最後に「Next Step」ということで、現在取り組んでいるプロジェクトについて簡単に紹介して終わりにしたいと思います。

LINEが現在取り組んでいる「ZTP」

先ほどのCOVID-19で、サーバーの緊急増設を実施したという話をしましたが、現在のLINEのサーバー運用では、サーバーの構築を実施する段階でその大半をIDC Operatorの手動作業に頼り切っている状態です。そのため、COVID-19の際にサーバーを増設した際にも、そのセットアップ作業に数日の日数がかかりました。

これらを効率的に行うように、LINEが現在取り組んでいるプロジェクトが、「ZTP」プロジェクトです。ZTP、ご存じの方も多いと思うのですが、「Zero Touch Provisioning」の略です。ZTPというのは、主にネットワーク機器などの自動構築や自動設定などに使われることが多かった仕組みですが、LINEではこのスキームをサーバー構築全体に適用する取り組みを現在行っています。

サーバーを構築する際には、データベースの資産情報の登録であったり、例えばハードウェアの設定・OSのインストールなどさまざまなステップが存在するのですが、これらのステップをすべてPXEブートを使用したZTPシステムで自動的に行おうとしています。これによって、IDC Operatorがサーバーの構築時に、現地でラックマウントとケーブルの結線などを行うのみで、そのあとはZTPシステムが自動的にサーバー構築できるようになります。

このようにして今後はサーバーの構築時の作業についても自動化を進めて、さらなるサーバー運用の効率化と安定的なサーバー運用を行っていきたいと考えています。

以上で私のセッションは終わりです。ありがとうございました。