CLOSE

LINEのインフラ組織(ITSC)のご紹介・Verda室の紹介/Verda ネットワーク開発チームについて(全1記事)

2022.11.08

Brand Topics

PR

迅速なサービス開発になくてはならないプライベートクラウド 「Verda」を運営するネットワーク開発チームの取り組み

提供:LINE株式会社

LINEの大規模なインフラを支えるクラウドプラットフォームエンジニアが所属しているチームの役割、仕事内容、ふだんの働き方、現在の課題について取り組みの事例を交えてお話しする「LINE クラウドプラットフォームエンジニア採用説明会」。ここで登壇したのは、Verdaネットワーク開発チーム・マネージャーの市原氏。LINEのインフラ組織と、Verda Platform室・Verdaネットワーク開発チームを紹介しました。

市原裕史氏の自己紹介

市原裕史氏:私からは、はじめにLINEのインフラ組織全体の話を紹介していきたいと思います。

まず自己紹介ですが、私はLINEに2018年に入社しました。当時はソフトウェアエンジニアとして入りましたが、2021年7月にエンジニアリングマネージャーとしてネットワーク開発チームという組織をリードすることになり、今もマネージャーを続けています。

みなさんご存じのように、たくさんのサービスが今LINEから提供されていますが、それらのサービスはほぼすべて、私たちインフラ組織によって管理されているインフラで動いています。

インフラ組織の構成

このインフラの全体の組織は、今表示しているような構造になっていて、ITサービスセンターというのが日本側のインフラ組織です。これとは別に、韓国側にもITサービスという組織があり、そこにはほとんどクラウドに関するチームしかないのですが、総勢192名という、かなりの数で組織が運営されています。

このITサービスセンターの中には大きく4つの組織があり、1つが私が所属しているLINEのPrivate Cloud「Verda」を管理しているVerda Platform室です。

また、オフィスのネットワーク、データセンターからインターネットに出ていくネットワークまで、すべて管理しているネットワーク室。

ほかには、LINEのデータセンターのサーバーや、サーバーの上のカーネル、そのサーバーを動かすためのツールなどを管理してるシステム室。また、LINEのすべてのデータベースを管理しているデータベース室などが、このITサービスセンターの中に存在します。

LINEの全体のインフラの構成は、基本的にはMulti-RegionでMulti-AZ構成になっています。大きくは東京・大阪・シンガポールで運営されており、東京にはMulti-AZとして3 availability zonesを用意しています。

ネットワークデバイスは、全部合計するとすでに1万台以上存在しており、それを収容しているラック数も今3,700を超えるところまできています。

また、すでにRegionを拡大する計画が複数あり、これからどんどんとこのインフラの組織は拡大していくと考えています。

ニューイヤーイベントで通常の倍に増えるトラフィック

次に、LINEの中で特徴的な通信のトラフィックについて紹介させてください。LINEが一番使われるタイミングは、みなさんいつだと思いますか? それは、やはりニューイヤーイベントです。

やはり新年を迎えるに当たって、家族や友だちに対してLINEメッセージで「あけましておめでとう」とか「HAPPY NEW YEAR」という言葉を送ったり、スタンプを送ったり、そういうトラフィックが爆発的に増えます。

なので、LINEの社内ではこのLINEのニューイヤーイベントに対して3ヶ月以上前から入念に準備しています。(スライドを示して)今出している図は、私たちネットワーク開発チームが管理しているLoad Balancerクラスタの、ある1つのクラスタのトラフィックです。新年を迎える前に比べて新年を迎えた瞬間が、90Gbpsくらい一気に跳ねています。

つまり倍です。倍のトラフィックが、ニューイヤーイベントでいきなり発生します。ここまでがLINEのITサービスセンターに関する紹介でした。

プライベートクラウドプラットフォーム「Verda」

続いて、私たちPrivate Cloudの組織であるVerdaについて紹介させてください。Verdaとは何か? いわゆるPrivate Cloud Platformのことを、私たちはVerdaと呼んでいます。この上でほとんどすべてのLINEサービスが動いています。

私たちは大きく2つのVerdaクラスタを持っています。プロダクション用のVerdaと、LINEの開発者が自由に開発できる環境であるVerda Devという環境です。

Verdaのスケールを、このスライドで紹介します。LINE全体で見ると、フィジカルサーバーに関しては7万台以上、また、CDNを含めたピークユーザートラフィックは3Tbps以上です。

その中でVerdaが担っているBaremetalサーバーが4万5,000台以上。ハイパーバイザーが7,600台以上。その上で、バーチャルマシンがもうすぐ10万台を超えそうな状況です。このイベントの前に超えてくれていたら、ここで大きな数字が出せたのですが、まだ9万9,000台ということで、日々ここの台数は増え続けています。

では、私たちがVerdaでどういうサービスを提供しているか。今、Public Cloudでメジャーに使われているサービスをかなり網羅していると思います。

もちろん、有名なPublic Cloudほどはサービスはありませんが、このVerdaの上でLINEのデベロッパーが開発をして、開発したプロダクトをサービスとして運営できるだけのサービスを、私たちはVerdaで提供しています。

その例として、このVerdaのダッシュボードを今お見せしています。このように、Verdaのダッシュボード上でコンピュートリソースとしてサーバーを選べたり、コンテナリソースとして、KubernetesクラスタをVKSという名前で運営しています。そのほかにも、ネットワークであったり、データベース、ストレージなど、これらのサービスをあたかもパブリッククラウドのダッシュボードのように表示して、LINEの開発者たちに使ってもらっています。

ここに表示してあるものが主なサービスの一覧です。IaaSレイヤーと、このロゴマークはOpenStackのロゴマークですが、基本的にはオープンソースのIaaSコントローラーであるOpenStackをベースにして、IaaSは構築されています。

ストレージはCephを使い、一部のサービスである、Baremetalサーバー、LoadBalancer、NAT as a Serviceなどは私たちがプロプラエティに開発・提供しています。

また、そのIaaSの上ではマネージドサービスが動いており、DB系、Kubernetesの上にはさらにPaaSレイヤーがあり、Knativeを使ったFunction as a Service、CI/CDを提供しているサービスなど、いろいろなサービスをVerdaの上で提供しています。

Verda運営を支えるそれぞれのチーム

このVerdaを作るに当たり、非常にたくさんのチームが存在します。細かくは説明できませんが、例えば本日も発表に来ているPlatform Iチーム。これはOpenStackを管理しているIaaSチームです。

Kubernetesを管理しているPlatform Kチーム。あとは私が所属しているネットワーク開発チーム。ほかに例えばVerda Reliability Engineeringチームは、Verdaの上でReliabilityの責任を持っているチームです。

こういったように、たくさんのチームの中でVerdaは作られて運営されています。この発表の前に数えたのですが、総勢85名がVerdaのメンバーとして働いています。

Verdaは、すごく外国籍の方の割合が多く、オフィシャルランゲージがチームごとに異なっています。例えばですが、日本側のチームですが基本的に英語のみを扱うPlatform Iチーム、Kチーム。私のチームは日本語と英語両方を扱っていますが、基本的にミーティングでは英語を使っています。

韓国側だと、やはり韓国語のみのチームもたくさんありますが、コミュニケーションには特に困っていません。なぜならドキュメントはすべて英語で書いてあり、話す必要があれば、LINE社内に通訳の専門チームがあるので、気軽に通訳の人をミーティングにアサインして、コミュニケーションを助けてもらっています。

Verdaのテクニカルスタックをいくつかここに並べてみました。これに収まらない数の技術スタックを使ってVerdaは構築されています。

Private Cloudを運営する上で一番重要なのは「速度」

最後に、なぜPrivate CloudとしてVerdaを私たちが運営するのか。例えば、Public Cloudになぜしないのか? ということに関しては、ここに私の答えが書いてあります。

私たちはアプリケーションデベロッパーと一緒にコミュニケーションしながら、彼らが必要なインフラリソースを提供できます。

そこの速度感は、やはり普通にPublic Cloudを使っていては得られません。また、アプリケーションデベロッパーがインフラに関して何か困ったことがあった時の応答速度ですね。そういうものは、やはりPrivate Cloudを運営していく上で一番重要なポイントになると、私は考えています。Verdaの紹介は以上です。

ネットワーク開発を担う「NetDevチーム」

次に私がマネジメントをしているネットワーク開発チーム、通称NetDevチームに関して説明します。

NetDevチームは、LINEの中にあるITサービスセンターのさらに下にあるVerda Platform室という組織の中の1つのチームとしています。

Verdaでは、SDNデザインであったり、ネットワークファンクションサービスであったりを提供しています。先ほどのダッシュボードで言えば、ここの赤点線にあるものです。CDNは違いますが、DNS、LoadBalancer、Internet Gatewayは、私たちが提供しています。

「NetDevチーム」が提供しているプロダクトの紹介

私たちのプロダクトについて細かく紹介していきたいのですが、とても話が長くなってしまうので、概要と、プレゼンテーションのリンクをたくさん付けました。興味がある方は、そのリンクをたどって過去の発表を見てください。

今スライドに表示しているのは、私たちが作っているCLOS Network Contorollerに関してです。Private Cloudは、すべてCLOS Networkの上で構築されていますが、そのCLOS Networkを管理するツールを提供しています。

すべてのリソースはKubernetesの上で管理されており、すべてのCLOSスイッチの情報がetcdに格納しています。各スイッチにデプロイされているエージェントが、そのetcdをウォッチして、自分に必要な変更をプルして、自分が乗っているスイッチに対してコンフィグレーションするというモデルになっています。

次に、LoadBalancer as a Serviceについて紹介します。私たちはLoadBalancer as a Serviceもすべて自前で作成しています。例えばL4 LBは、XDPを使って提供していて、TLSターミネーションを司るプロキシサーバーであるL7 LBは、Kubernetesの上でHAproxyで実現しています。

次にDNS as a Serviceですが、大きく2つ、DNS AuthサーバーとDNS Cacheサーバー、両方とも私たちのチームが提供しています。

次にInternet Gatewayと呼んでいる、インターネットにアクセスする時のNAT Gateway Serviceです。こちらもすべてKubernetesの上に乗っていて、各NATサーバーはNFVサービスとしてVMで提供されていますが、そこで動いているエージェントがKubernetes上から引っ張ってきた情報をetcd経由で取得して、NATサーバーにNATの情報や、ルーティングのコンフィグレーションを設定して、各ユーザーのサーバーに対してNATのソリューションを提供しています。

次にPrivate Network機能です。これはいわゆるAWSのVPCのような機能で、LINEの中で複数のオーバーレイのネットワークを作れる機能です。

これは、OpenStackのNeutronをカスタマイズして構築しています。セットで利用されるNFVサービスは、すべてKubernetes上のCRDやカスタムコントローラー、いわゆるKubernetesオペレーターですべて構築されています。以上が私たちネットワーク開発チームが開発・運営しているプロダクトです。

「NetDevチーム」メンバーの働き方

次に私のチームのアーキテクチャと、どう仕事をしているかを簡単に説明します。

チームの中で扱っているプロダクトごとに、まずプロダクトオーナーを決めています。基本的にはプロダクトの責任を持つエンジニアとして、このプロダクトをリードしてもらっています。

それとは別に、例えば中長期的、短期的にでもやらなければいけないゴールを定めていて、それを私たちはタスクフォースと呼んでいます。

2週間のスプリントの中で、2名で構成されるタスクフォースを作ります。その2名はその2週間、その開発のみに集中します。

あらゆるミーティングには呼ばれない、あらゆるノティフィケーションも飛んでこない環境を作って、開発に集中してもらうというルールを定めています。

それ以外のメンバーは、タスクフォース以外のコモンワークと呼ばれている開発タスクやオペレーションタスクを日々そのスプリントの中で実施しています。

私自身はこのようなスケジュールで働いておらず、もちろんたくさんミーティングが入っていますが、私のチームのあるエンジニアの1日の働き方と、それを1週間に延ばした時にどういうふうに働いているか、一例として載せています。

デイリーミーティング、ウィークリーミーティングをチームでやります。基本的には、デベロップメントに集中してもらいますが、例えばですが、CSと呼んでいるカスタマーサポートの時間が私たちには存在します。

LoadBalancer、NAT Serviceなど、ユーザーが使っていてイシューが出たり、ユーザーがなにかしら問題を抱えた時に、それを解決するためのユーザーとのやり取りをする時間になっています。

また、基本的にはみんな裁量労働で働いていて、金曜日はノーミーティングデーです。早く終わったりすることは比較的自由にできますし、いつ働き始めてもいいし、いつ働き終わってもいいというかたちで、私のチームは運営しています。

求める人物像

どういう方がネットワーク開発チームに入ってきてほしいか。ネットワークという名前を付けていますが、ネットワークスキルは必須ではありません。私たちが要求するのは、やはりソフトウェアエンジニアリングのスキルです。

システムのアーキテクトやデザインができるとなお良いですし、自律的に働いている方を探しています。

また、私たちのサービスはほとんどKubernetesの上に乗っているので、やはりKubernetesのスキルも必要です。また、English Speakerがチームにいるので、英語のコミュニケーション能力もスキルとして欲しいと思ってます。

巨大なクラウドインフラの開発のナレッジを吸収しながら先行的なチャレンジができる

最後に、私たちのチームに来るとどういうことができるのか。LINEの莫大なトラフィックに触れます。日本でも有数の巨大なクラウドインフラの開発のナレッジを勉強できると思います。

また、SDN、NFVの分野でLINEはかなり先行していると思うので、先行的なチャレンジもできます。ほかにもプロフェッショナルなソフトウェアインフラエンジニアがたくさんいるので、そういった方々と一緒に仕事ができるのもメリットだと考えています。

最後に、今私のチームが開いているポジションについて、このリンクでたどってみてください。では、ネットワーク開発チームからの紹介は以上です。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

LINE株式会社

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 海外拠点がサイバー攻撃者に狙われやすい“4つの理由” 実例からひもとく「EDR」+「SOC」の効果と特徴

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!