OpenStackベースの世界最大規模プライベートクラウド　LINE開発の根幹を支えるプラットフォーム「Verda」のSRE

プライベートクラウド「Verda」について

萬治渉氏（以下、萬治）：「Verda Reliability Engineeringチーム」の紹介を始めたいと思います。萬治渉と言います。よろしくお願いします。Verda Reliability Engineeringチームのマネージャーをしています。

5年くらい前に新卒でNTTに入って、OpenStackなどのプライベートクラウドや、あとはネットワーク機器の設定の自動化などの研究開発に携わったあと、LINEに入社して、Verda Reliability Engineeringチームの立ち上げメンバーとして、Verdaの監視方式の見直しや、アラート整理、オンコールの導入、あとはデプロイまわりの改善とかをやったあと、2021年の7月からチームのマネージャーになりました。

趣味は筋トレと散歩と書いてありますが、毎日雨が降っている日以外は2時間外を歩いて、公園のうんていで懸垂をして、家に帰ったらベンチを上げるという生活をしています。

まずはVerdaについてです。Verdaというのは、LINEの中で使われているプライベートクラウドプラットフォームです。いわゆるAWSやGCPに似たような機能が社内で開発されて、運用されています。Verdaの上では、ものすごい数のLINEサービス、ほぼすべてと言っていいくらいのLINEサービスが動いています。

規模はVMで7万4,000台、Baremetalで3万台、ハイパーバイザーが4,000台以上という感じで、僕が知っている限りでは世界最大規模のOpenStackベースのプライベートクラウドです。CERN（欧州原子核研究機構）が持ってるそれの規模を超えていると思っています。

Verdaは、さっき言ったVMやBaremetal以外にも、たくさんのクラウドサービスを社内のユーザーに提供しています。いろいろ書いてありますが、例えばオブジェクトストレージや、複数のVMからマウントできる共有ファイルシステム、NFSみたいなものですね。あとはMySQLやElasticsearchといったPaaSであったり。

ちょっと変わり種としては、herokuみたいにアプリケーションコンテナをそのまま動かすサービスやKubernetesのクラスタそのものをユーザーに払い出すサービスなんかもやっていたりします。下に書いてあるように、NATとかロードバランサーなどについては、LINE DEVELOPER DAY 2020で発表があったので、気になる方は見てみてください。

Verdaに関わる複数のチーム

Verdaは、開発領域によって複数のチームに分かれています。例えば、Verdaプラットフォーム開発IチームはOpenStackを使ったIaaSの部分の開発を担当していたり、Verdaプラットフォーム開発KチームはRancherを使ってユーザーにKubernetesのクラスタを払いだすような機能開発をしていたり、いろいろです。

Verda Reliability Engineeringチームは、すべてのサービスにまたがって信頼性の向上をしていくというチームなのですが、ここに書いてあるように、ものすごい幅広い技術領域に対して活動していかなきゃいけない。

それはさすがに無茶だということで、基本的にサービスのReliabilityに直接担保する責任はそれぞれの開発チームが持っていて、僕らはサポートであったり、あとはそれぞれのチームの活動の中で共通している部分を拾い出して、それをプラットフォームやツールとして展開したりする活動をしています。

ちなみにVerda開発者の総数は70人に満たないくらいで、これくらいの人数でこの規模のプライベートクラウドを運用していることは、けっこう自慢に思っていたりします。

VREは、Verda Reliability Engineeringチームの略です。チーム名がメチャクチャ長いので、みんなVREと呼んでいます。VREの役割について、一文で言うのであれば「LINEとVerdaの開発者の生産性をVerdaのReliabilityの向上によって上げていく」というのが僕らのミッションです。

この観点で、Verdaの中には2つのユニットが存在していて、1つがPlatform-wide SREと書いてあるもの。もう1つがInfra-managementと書いてあるものですね。1つ目のPlatform-wideはVerdaの内部で使われるアプリケーションプラットフォームの開発であったり、あとは便利なツールの開発。それから監視などの取りまとめみたいなことをメインにやっています。

一方Infra-managementチームは、Verdaが実際に使う物理的なインフラリソースであったり、データセンターのマネジメントであったり、そういうところの調達と効率化を通してVerdaの開発速度やサービスの展開速度を上げたり、Verdaの中のリソースマネジメントなどを主に担当しているユニットです。

今日紹介するのはPlatform-wide SRE Unitです。ユニットメンバーは僕とあともう1人、坂本さんの2人でユニットを組んでいます。ちょっと二人とも笑顔がないので、今度は笑っている写真を用意したいと思います。

この2人でどういう活動をしているかというと、さっき言ったように、Verdaの内部プラットフォームの開発、それからそれぞれのチームのReliability Engineeringの活動を効率化させるようなツールの開発。あとはユーザー観点から見たVerdaの信頼性を上げるために、いろいろな活動をやっています。

Platform-wide SRE Unit内での課題

ではさっきの2つの観点で、VREのPlatform-wide SRE Unitの中でどういう課題を認識しているかというと、ユーザー観点から見て、Verdaのドキュメントはまだ不十分だったり。またVerdaのドキュメントの場所、サイトがVerdaのサービスごとにいろいろ分散していたりするので、そういうのでユーザビリティを損ねているよね、という話であったり。

あとはログやメトリクスを保存するためのストレージが、今は各チームそれぞれがマネジメントしている状態になっていて、これは非効率だよねという話であったり、さらにはVerdaは今いろいろ複数の種類のVerdaサービスのAPIサーバーやDBのコネクタなどを1つのKubernetesのクラスタの上で運用しようとしていますが、そのKubernetesクラスタのユーザーポリシーがまだまだ明確じゃないし、それをマニュアルで管理するような状態になっているという問題があるよね、であったり。

あとはリリースマネジメントですね。それぞれのチームがそれぞれAnsibleであったり、進んでいるところだとArgoCDだったり、ちょっと厳しいところだと手動でデプロイしていたりしていますが、そういうところもやり方を統一していって、デプロイメント自体の信頼性を上げていったりなど、そういう課題を認識しています。

僕がマネージャーになったのが7月で、ユニットができたのもそれと同じ時期ですが、今取り組んでいるプロジェクトは、メトリクスストレージとログストレージの統一です。これの何が難しいかというと、それぞれのメトリクスストレージ、ログストレージでVerdaのサービスに依存して作ることが難しいという大きな問題があって。それを解消するために、社内でVerdaに致命的なほど依存していないプロダクトを使って、メトリクスストレージをそのプロダクトに任せています。

また、致命的ではないと言っても、Verdaにいくらか依存している部分があるので、その依存を外すためにどういう設計の見直しをすればいいかや、Verdaが求めるメトリクスの保持期間などをどう実現すればいいかという開発観点の話を、ストレージプロダクトを作っているチームとしていたりします。

あとは、ログストレージについては、残念ながら社内に完全に僕らの要件に適合するものがなかったので、Grafana LokiとAWSを組み合わせて、Verdaに致命的に依存しないかたちでログストレージを構築しようとしています。

さきほど言った2つのプロダクトが一段落したら、次にどういうのをやっていきたいかというと、優先度順というわけではありませんが、最初にやろうと思っているのは、一番上のドキュメントサイトの統一です。

今のほとんどのプロダクトは、社内のConfluenceではない場所にドキュメントのマスタを置いていますが、社内のVerdaユーザーのほとんどはConfluence上にある古いVerdaのドキュメントのトップページを参照しているような状態です。なので、そこをまずきちんと新しいサイトに統一して、そのサイトの中でもちゃんとテクニカルライティングを補助するような、いろいろな自動化機能であったりを実装しようというプロジェクトを企画しているところです。

あとはVerdaのサービスはけっこうサービス間でのマイクロサービス的な依存が多いのですが、その依存関係が完全にクリアになっているわけではないので、Verdaの中の依存関係をきっちり洗い出して、デプロイの時やOutageハンドリングの時に、適切に関係する開発チームに情報が届くように、情報整理をしましょうという話も進めようとしています。

最後に書いてあるデプロイメントの手段の統一ですが、これについては、明日開かれるCI/CD Conferenceのスポンサーセッションで具体的な取り組み方針や、あとその方針の要素技術、要素技術ごとのVerda内での導入事例などを発表する予定なので、興味がある方はCI/CD Conferenceにも来てください。

Verdaの技術スタック

テクニカルスタックは、ページを作るのを忘れていたので口頭で補足しますが、基本的にはPythonとGoでコードを書いています。Pythonは、簡単なWebサーバーとかを書く時に使ったりしていて、GoはKubernetesのオペレーターなどを書くのにゴリゴリ使っている感じです。

メトリクスまわりは、収集にはPrometheusを使っていて、Prometheusからさきほど言った中央のメトリクスストレージに書き込むかたちを取っています。ログストレージについては、今のところはElasticsearchを使っていますが、これもさっき言ったログストレージの統一プロジェクトで、アプリケーションログはGrafana Loki、監査ログについてはHBaseのクラスタにFluentdとKafkaを使って投入するようなモデルを作っているところです。

Verda開発に求める人材

そういう差し込みの話をしたところで、どういう人を求めているかという話に入りたいと思いますが、まずは行動面ですね。僕らのチームは、心理的安全性というか、そういうものをすごく大事にしているチームなので、心理的安全性について理解があった上で、それを実現しようと行動できる人というのを強く求めています。

あとは何か困った時とかに自分で抱え込まずに、まわりの人にちゃんとヘルプを出したり連絡したりできる人を求めています。3つ目はリーダーシップ。これもとても重要で、何か問題があったり決めきれないことがあった時に、どういう方針で動くべきかを今の情報できっちり判断して、前に進める人を求めています。

ただそういう行動をしたら、いくらか失敗は付きまとうと思いますが、その失敗は前向きなチャレンジとして受け止めるようにしています。あとはちゃんと学び続けて、アウトプットを出し続ける人ですね。

技術的な面でいうと、高い可用性を持つシステムはいったいどう作られているのについて、知識をきちんと持っている人。あとは僕らはクラウドを作っている側なので、すごい低レイヤーの技術領域についても深く理解して、トラブルシューティングができるようにしなきゃいけません。あとは、現代的なモニタリングの知識ですね。

例えば1つのPrometheusがすごい幅広い範囲であったり大量のメトリクスを収集する時に、それはいったいどういう問題を引き起こすのか、それを避けるためにはどういうデザインでメトリクスのデータフローを組まないといけないかについて、知識を持っている人がいるとすごく助かります。

CI/CDの話もそうです。どこのテストで何を担保するべきなのか。デプロイした時にどういう問題が起こり得て、それを事前に防ぐ仕組みと起こった時に被害を最小限にする、復旧を速くするためには、いったいどういう仕組みが必要なのかについて、いろいろ意見を持っている人が来てくれるとうれしいです。

最後にマイクロサービスアーキテクチャの知識ですね。あるプロダクト、サービスを作る時に、そのサービスがどういう機能を内部的に備えていて、それをどういう責任範囲に分解して、マイクロサービスとして開発、デプロイされるべきなのか。一番上のシステムデザインともちょっと被りますが、そういうところについて経験と知識がある方を強く求めています。

ということで、Verda Reliability Engineeringチームからの紹介は以上です。