
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
提供:LINE株式会社
リンクをコピー
記事をブックマーク
松本幸大氏:このセッションでは、LINEが構築・運用を行っている数万台の物理サーバーについて、このような膨大な数のサーバーをどのように運用しているのかについて紹介したいと思います。
まず簡単に自己紹介させてください。私は松本といいます。2019年にLINEに新卒として入社しました。現在はLINEのSystem Development Teamでインフラエンジニアとしてサーバーの運用全般に携わりながら、運用の自動化を目的としたツールの開発や、それらに付随したモニタリングなどの社内システムにおける設計・開発・運用などを主に担当しています。
(スライドを示す)このセッションのアジェンダはこちらです。このセッションでは、主にLINEでどのようにして膨大な数のサーバーの運用を日々行っているかを紹介します。まずサーバー運用の話の前に、そのバックグラウンドとして、LINEのインフラがどのようなものなのかについて簡単にご紹介したいと思います。
次に日々、実際にどのようにサーバーを運用しているのかを紹介していきたいと思います。
次に「New Year / COVID-19」ということで、LINEが毎年経験しているNew Yearの対応と、昨今のCOVID-19によってLINEのサービスがどのような影響を受けたのか、それに対してどのように対応を行ったのかを、主にサーバーインフラの観点からお話ししたいと思います。
そして最後に「Next Step」、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が実際にどのような部分、タスクをこなしているのかというところを詳しく紹介します。大きく「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も、あくまでサーバーの情報・連絡先がまとまっているのみなので、例えばインシデントの内容が同じであっても、対応するエンジニアによって対応方法がバラついてしまうという、品質面での問題もありました。
LINE株式会社
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07