常にLINEができるサーバーに　LINEのインフラチームを形成する3つのDNA　「Speed」「Global」「Scale」

LINEインフラチームの“これまで”と“これから”

朴永熙氏：みなさん、こんにちは。LINE DEVELOPER DAYは、LINEのさまざまな技術経験を開発者のみなさんに共有することで、業界の発展に貢献しています。

この時間は、LINEサービスの成長とともにLINEのインフラストラクチャがどのように変化してきたのか、今後の課題はどのようなものがあるのか。これらについてお話ししたいと思います。

LINEのインフラストラクチャの経験をご覧いただいて、みなさん自身のインフラストラクチャに対する課題、そして課題へのすばらしい挑戦に役に立つと幸いです。

私はLINEのインフラストラクチャの担当執行役員の朴永熙と申します。2013年からITサービスセンターのセンター長を務めており、国内外のLINEのインフラ関連部門を総括しています。

COVID-19の世界に生きている今、IT技術とITサービスは私たちの生活にますます重要になっています。COVID-19以前と比べて、ますます多くのITサービスを利用されるようになり、それに従い、サーバーやネットワークなどのITインフラストラクチャの資源使用量も急激に増加しています。

LINEは、クリスマスや新年などの大きなイベント、突発的に発生する災害時など、トラフィックがふだんの3倍となる状況でも耐えられる仕組みを構築しています。

COVID-19の影響による大きなトラフィックの増加でも幸いにうまく対応ができていますが、私たちの準備が十分だったのか、よりよいサービス提供ができないか、改めて考えてみることにしました。

インフラチームのDNAを構成する三要素

LINEは2011年6月にサービスがオープンした後、2012年3月に2,000万ダウンロードを達成。そのあと、2013年5月に1億5,000万ユーザー登録、2014年4月に4億人のユーザーが登録しました。

エンジニアの観点から見ると、爆発的なサービスの成長に伴うトラフィックの処理準備をしなければいけない、厳しい時期が迫っていました。

2014年から現在まで、LINEサービスの主要4ヶ国である、日本、台湾、タイ、インドネシアのMonthly Active Userの数も約2倍になっています。これに合わせてLINEのインフラストラクチャの規模も大きく成長しました。

ネットワークが約6倍。CDN使用量は12倍。サーバーは5倍。ストレージは4倍。IDCは、日本の2ヶ所をはじめ、シンガポール、米国、ドイツ、韓国、台湾などで稼働しています。LINEのスタッフが勤務するオフィスの数も約3倍となっています。

このように、LINEのインフラストラクチャは、LINEサービスの成長に合わせて、短い時間でグローバルをカバーできるように大規模になっています。「Speed」「Global」「Scale」、この3つの単語がLINEのインフラストラクチャを作ったDNAだと言えます。

大量の障害が発生した時期の試行錯誤

それでは、LINEのメッセージのトラフィックが爆発的に増加した時期のインフラストラクチャの課題についてお話しします。

この時期は毎日、LINEのサービスでは大量の障害が発生していました。LINEのインフラストラクチャが直面した1つ目の課題は、障害状況を把握するための情報を準備することの難しさでした。みなさんも経験があると思いますが、社内に多くのシステムがあり、そのシステムにアクセスするには権限をもらわなければなりません。

LINEのインフラストラクチャでも数多くのシステムが特定のメンバーだけにアクセス可能な状態で作られており、インフラストラクチャの情報を得るためには、メールやメッセンジャーなど、さまざまなコミュニケーションツールを使って、その部署やメンバーに連絡をとる必要がありました。

サービスに問題があると気づいたとき、現状を把握するために、LINEのエンジニアたちはさまざまなことを同時に見ています。例えば「データベースは十分すばやく応答しているのか？」「処理に時間がかかるクエリはないか？」「IDC間のネットワークには問題ないか？」「特定キャリアの通信にはパケットロスは発生していないか？」。こういったことを気にします。

このようにサービスに問題が発生しているとき、インフラストラクチャに問題があるかないかを把握するにはかなりの時間がかかります。インフラストラクチャチームでも対応を行いますが、その間、ほかの仕事をするのは難しいです。そして、このような状況は、サービスの数が増えてシステムが複雑になればなるほど、より頻繁に発生することになります。

「BE OPEN」の文化が可能にするチーム基盤

このような状況で、LINEのインフラストラクチャでは可能なかぎり多くのインフラ情報を、少数のメンバーだけではなく、サービスに関わるすべてのエンジニアにオープンすることが必要だと判断しました。

すべてのエンジニアがアクセス権限を申請する必要なく、インフラストラクチャの情報を自ら検索できるように、システム、ネットワーク、データベースに関する情報を整理し、必要な情報を得られるようにシステムを作りました。

そのシステムがIMCです。IMCはLINEのインフラストラクチャチームがLINEのすべてのエンジニアにオープンした、最初のインフラストラクチャシステムです。

このように情報に透明性をもたせることが、開発チームとインフラストラクチャチームの協業の始まりとなりました。透明性が組織に浸透すると、情報の格差がなくなって効率がよくなり、活発でよいコミュニケーションが生まれやすくなります。これはLINE開発組織がもつ文化の1つである「BE OPEN」につながっています。

LINEがもつサービスはメッセンジャーだけではありません。LINEがスマートポータルとして進化するために、「LINE NEWS」「LINE Pay」「LINE LIVE」「LINE MUSIC」など、さまざまなサービスが同時多発的に作られ始めました。サービスが増え、それに伴って開発組織が大きくなりグローバル化され、日本国内だけではなく海外でも同時多発的に開発プロジェクトが進められています。

今までのように、ワークフローを受けてインフラストラクチャを構築し、2〜3週間後に開発チームに渡す方法はもはや可能ではなくなりました。これまでの作業を自動化し、よりスムーズにインフラストラクチャを提供・管理できるようにするようにはどうしたらよいか、私たちは考えました。

LINEがクラウド方式を検討し始めた2015年時点では、幸いにOpenStackが十分利用可能なレベルになり、LINEのインフラストラクチャチームもIMCを通じて開発に自信がつきました。

すでにLINEの規模ではコスト面からパブリッククラウドを選択することはできませんでした。LINEではその時々によって要件が変わり続けるサービスが多く、適切にインフラを準備していくことが必要です。

プライベートクラウド「Verda」の役割

そしてLINEでは、インフラサービスを通じて根本レベルの解決をするために、独自のクラウドを作ることに決めました。

2015年に独自のクラウドを作り始めたとき、LINEのインフラ組織にはクラウド開発の専門家が1人もいませんでした。可能なかぎり自分たちで開発する領域を減らし、最小限の機能づくりをして、少しでも私たちの業務負担を減らすことができるものを作ることに集中しました。

内部システムとの連動はSSOのみで、OpenStackを最小限にカスタマイジングしながら、UIはOpenStackのHorizonそのままで、VMとベアメタルの機能だけを先にオープンしました。

オープンしたときは独自の名前もなくIaaSと呼んでいましたが、このIaaSは「Verda」という名前にリニューアルされ、現在は約60人規模でクラウド専門組織として開発と運営をしています。「Verda」は、エスペラント語で「緑」という意味です。LINEのクラウドだから緑ということですね。

現在のVerdaには、VM、ベアメタル以外にも、多くのインフラ、プラットフォームのさまざまなコンポーネントがサービスされています。

規模としては、VMが5万5,000台、Physical Machineが2万台、Hypervisorも2,000台以上で運営されています。

これが実際のVerdaの画面です。プロジェクトの管理、Computer、Network、Database、Contents Delivery、ミドルプラットフォーム、CI/CD、Code Quality、モニタリング、Audit、Deploymentなどのカテゴリのコンポーネントが、Verdaを通じてサービスされています。

（画面を操作して）これがVMのモニタリングをしながらリージョンを選択し、VMを生成する画面です。VerdaはLINEのすべてのエンジニアが使うシステムなので、UIも力を入れています。

このようにスピードを重視してインフラストラクチャを運営している状況でも、全体のリソースが効率的に使われるようにすることは、インフラストラクチャチームの重要な役割の1つです。

どのようにサーバーリソースを管理しているか

LINEは次のような方式でサーバーリソースのutilizationを管理しています。

まず、全サーバーの約15%が対象となるutilizationの基準のCPU、メモリ、ファイルシステム、ネットワークの使用量を基準で定義します。この基準で選別された15パーセントのサーバーを「Low usage server」と呼びます。

Low usage serverは、一時的なテスト用途、冗長化の用途、最小構成に必要、これからサービスに投入するなど、今すぐ措置が難しい状況もあります。

しかし、そのうちの一部は管理されておらず、返却ができるものもありますし、spec down、VM化、コンテナ化ができるものもあります。または、アプリケーションの構造変更によって返却されることもあります。LINEの場合、通常Low usage serverの20〜25パーセントが返却されています。

このLow usageのserverの割合が10パーセント未満になる場合は、再びLow usage serverの15パーセントになるようutilizationの基準を高めます。LINEでは1〜3のサイクルを1年に3回行い、この活動でサーバー全体のリソースの使用率は約10パーセント改善します。みなさんが同じような課題をもっていてまだチェックしていない場合、非常に効果があるのでぜひやってみてください。

そして本当に重要なのは、Low usage serverで残り続けるサーバーの対策です。これらのサーバーとこれらのサーバーの上で動いているアプリケーションには、今すぐにはできないとしても、技術的なチャレンジをしなければならないのです。

LINEのインフラストラクチャの成長過程において、インフラストラクチャの情報が社内に向けてオープンになり、デリバリや管理が自動化されています。そして、インフラストラクチャチームは、開発者がどのようにインフラストラクチャを使うのか、どのような機能が必要なのかに対して、開発者と話し合いながら開発者がインフラストラクチャに求めていることの理解を深めています。

プロジェクト「Plano」の目指すもの

そして、私たちはまだ問題があると認識しています。リソースの使用効率性の限界を超える方法はほかにないか。データセンターのサーバールームが古くなってリニューアルが必要な場合、開発者とインフラストラクチャチームが6ヶ月かけてmigration projectを行う必要が本当にあるか。LINEのインフラストラクチャはコードレベルでプログラミングされるようにすべての機能をAPIで提供しているが、使い勝手はいいか。

LINEの開発者たちは依然として、ロードバランサ、CDN、DNS、ACLなど、インフラストラクチャの技術を十分理解しなければなりません。インフラストラクチャの作業が発生するとき、関連する開発者たちは、インフラストラクチャのスケジュールに合わせてアプリケーションをほかのインフラストラクチャに移動させるなど、自分たちの時間を使わなければなりません。

開発者がインフラストラクチャの技術を理解するのではなく、インフラストラクチャの技術を向上することで技術が開発者の業務を理解し動作するレベルになれば、我々はより価値のあることに自分の時間を使うことができます。

そこで私たちはデータセンタースケールで全体のリソースを活用できるよう、そのインフラストラクチャの上で開発者たちの介入なしにアプリケーションがサーバールームを移動できるようにして、インフラストラクチャのAPIの十分な理解がなくても、宣言的に仕様できるインフラストラクチャを作るプロジェクトを立ち上げました。

このプロジェクトの名前は「Plano」といいます。スペイン語で「水平」という意味で、水平的な大きなプラットフォームを目指すという意味で名付けました。

これまではアプリケーションに合わせてカスタマイズしたインフラストラクチャを提供してきました。これはアプリケーションとインフラストラクチャが密結合されていて、柔軟性があまりありません。LINEには多数のサービスがあり、インフラストラクチャがアプリケーションにすべて合わせるのは難しく、効率性も悪いです。

そこでプロジェクト「Plano」では、このようにアプリケーションとインフラストラクチャの間にResource Abstractionのレイヤーを追加して、アプリケーションの使用効率を上げる仕組みを実現するようにしています。

これと合わせて、インフラストラクチャの側がアプリケーションのデプロイメントと運営の一部にまで責任の範囲を広げ、開発者がResource Abstractionをよく認識しなくてもインフラストラクチャを使えるようにしようとしています。

「Plano」はすべてを実現するためには3年かかる長いプロジェクトで、Infrastructure Orchestrate、CI/CDパイプライン、リソーススケジュールなどの領域でさまざまなサブプロジェクトが進んでいます。「Plano」の進捗は次回のLINE DEVELOPER DAYでもっと共有できるようがんばります。

常にLINEのメッセージが送信できる仕組み

LINEのメッセンジャーはコミュニケーションの社会的なインフラとして認識されているため、個人情報の保護、サービス継続性、インターネット社会の貢献など、さまざまな役割をもっています。

中でもこれからとくに力を入れていきたいと考えているBCP/DRとIPv6についてお話しします。今のLINEは1つのIDC全体が動作できない状況でも、text messagingが止まらないようになっています。そして、この「常にtext messagingが可能である」という言葉をLINEのBCP/DRの水準として定義しています。

このようにシンプルで明快な文章を実現するために、関西に日本国内で2番目となるIDCを構築し始め、関東と関西の間に大規模なネットワークを連結して数千台のDR用サーバーを用意しました。そして、Active/Standbyでデータシンクができるようにアプリケーションを修正して、IDC間のデータシンクをし始めました。

第1IDCに集中していたシステムの中から、フェイルオーバー作業中に必要なSSL VPN、DNS、NTP、Kerberos、JIRA、Wiki、Gitなどは、第2IDCでActiveで動くようにしました。このようにしてフェイルオーバー作業手順が簡単になり、作業時間を短縮することができます。

そして、Active/Active方式が可能なアーキテクチャのMessage Frontは、通常は第1IDCに接続して動作しながら、設定を変えると第2IDCのMessage Backendに接続されるようにしています。

その次にしなければならないことは何でしょうか？　第2IDCでスタンバイしているサーバーのコストが心配です。スタンバイサーバーたちには、緊急時には中断しても問題がないデータ分析業務を任せることにしました。

「Zero time, all messaging」を掲げて

2年間かけて進めたこのプロジェクトは2018年に完成しました。大変でしたが、よくできたと思います。しかし、現在DRレベルにはまだ改善することがあります。

第2IDCのmessage backendをStandbyからActiveにするフェイルオーバーにかかる時間が3時間かかってしまいます。その上、フェイルオーバー以降、元のサービスの状態にフェイルバックするにはかなり長い時間がかかります。おそらくフェイルバックには数ヶ月かかるかもしれません。

我々は再びDRのレベルを定義しています。それが「Zero time, all messaging」です。LINEのメッセージングを構成するすべてのコンポーネントがMulti IDCでActiveとして動作することによって、フェイルバックが短い時間にできるアーキテクチャとして設計を進めています。

このようにLINEは社会のインフラとしてもっと高いレベルのBCP/DRの水準を目指しており、「Zero time, all messaging」が完成するには時間がかかりますが、またみなさんにLINE DEVELOPER DAYで共有できるよう努力します。

国内のインターネットに接続できる35パーセント以上の端末がIPv6を通じてコンテンツを消費しており、IPv6端末がますます増えています。

みなさんのスマホに入っているLINEのアプリではIPv6をサポートしていますが、LINEのサーバー側ではIPv4となっています。キャリアのDNS64・NAT64技術を通じて、IPv6端末からIPv4のサービスに接続する方式になっているのです。

この方式はキャリアの負担が重いままですし、通信の段階も増えるので、技術面ではよいアーキテクチャではありません。サーバーサイドのIPv6への転換はインターネットの方針にも合わせることになるので、LINEは2年前からサーバーサイドIPv6をするプロジェクトを進めてきました。

LINEは来年2021年からサーバーサイドのIPv6を提供するようにします。ご期待ください。

本日はLINEサービスの成長とともに発展してきたLINEのインフラストラクチャの重要ないくつかの経験を共有しました。LINEのインフラストラクチャの経験が少しでもみなさんのこれからのすばらしい挑戦に役に立つと幸いです。

以上で私の発表を終わります。ありがとうございました。