Verdaの中身とチーム構成
山田英樹氏：私からはVerda室の紹介と、私たちのVREチームの募集中のポジションについて説明したいと思います。
「Verdaとは何か？」ですが、LINE内にあるプライベートクラウドです。これの上で、LINEが提供している、かなりの数のサービスがホストされています。
Verdaの中身がどうなっているかですが、AWSやGCPみたいなものをイメージしてもらえればいいと思います。中身はOpenStackというOSSを中心に作られています。VM、ベアメタルを中心として、Kubernetesやストレージ系のサービスだったり。あとMySQLやRedisをプロビジョニングするサービスもあります。
Verdaのチーム構成ですが、基本的にそれぞれのプロダクトに対してチームがあります。今回はそれらのチームを横断的に見て、信頼性向上に関する活動を行う、SREのチームの紹介になります。
VREチームとインフラマネジメントユニットの活動紹介
VerdaのSREチームは、“VRE”という名前で活動しています。VREチームの役割としては、LINEの開発者の人たちと、Verdaを作っている人たちを支援することで、それを通じて信頼性向上をしていくところをミッションにしています。
現在2つのユニットで活動していて、共通的なCI/CDやデプロイメントの基盤、モニタリングの基盤を作成しているようなプラットフォームSREチーム。そして今回紹介する、インフラ管理を行っているチームの2つに分かれて活動をしています。
私たちインフラマネジメントユニットの紹介です。どんなことをしているか。けっこう広い範囲なので、一言で言うとHypervisorやVMに関すること全般という感じです。
VMはHypervisorと呼ばれる物理マシンの上で動作します。そのHypervisorの残り容量をモニタリングして必要に応じて増設することをしています。また、どんどん新しいCPUなども出てきて、古いサーバーは保守も切れて撤退しなければいけないことになるので、そのライフサイクルの管理やチューニング、管理コスト低減をさせるための自動化・標準化など、さまざまなことをやっています。
雑用係と言うとちょっと聞こえは悪いかもしれませんが、それ以外のVerda内で発生するような非定型のオペレーションや、トラブルシューティングなども担当しています。例えば、LinuxのCentOSが7.8から7.9になった時に、これまで問題なく動いていた標準ツールが動かなくなってしまうようなことが発生します。その時にトラブルシューティングをして、修正したり。
システムデベロップメントチームのほうで、社内の資産管理のシステムを作っているなどの話もありましたが、そのあたりと、Verdaのシステムの連携をする部分の面倒を見たりしています。
また、OpenStackやベアメタルに関するシステムのトラブルシューティングや、自動的に処理できないようなリクエストが来た場合のマニュアルオペレーションをしたりをしています。
Verdaのインフラ管理の課題
このVerdaのインフラ管理に関する課題です。Verdaの利用者からはいろいろなリクエストがあります。大きなリソースのサーバー、VMを使いたいとか。例えばデータベースで使う場合は、メモリが大容量でディスクも大容量、I/O性能が高いVMが欲しいとか。
非常にコアなサービスで使うために、処理の遅延があるとサービスの品質低下になってしまうので、サーバーを専有して使いたいとか。ある特定のラックに固めてサーバーを置きたいとか。例えば何かのプロモーションを打ったり、バズったりでサービスの利用者が急に増えたから、今すぐサーバーを増設したいとか。そういった、さまざまな要求があります。
こういったものに応えていきますが、課題はいろいろあります。ベアメタルサーバーを使うと、大きなリソースが使えて安定的に運用できる一方で、データセンターのラックの1ユニット、ないしは2ユニットを完全に占有してしまうし、運用もVMと比べるとちょっと手間がかかります。そのためインフラチームとしては、できるだけVMを使ってほしいジレンマがあります。
また、クラウド系の知識がある方は知っているかもしれませんが、VMにはNoisy neighborという問題があり、同じ物理マシン上で動いている、隣にいるVMがたくさんCPU使っている時や、ディスクの書き込みをたくさんしている時にその影響を受けて、安定した性能が出ないようなことが起きたりします。
あとキャパシティの問題としては、スペースが限られているし、実際に足りないとなりサーバーを注文しても、納品まで数ヶ月かかります。「明日増設したい」というクラウドの要求に「ちょっと数ヶ月待ってください」とはなかなか言いづらいわけです。
運用をよくするための2つの取り組み
こういったところで、どうやって運用をよくしていくかということで、最近あった具体的な取り組みを2つ紹介したいと思います。
1つ目がRich VMというものです。通常VMでは1つのマシン上に10台、20台動かして使うものですが、こちらはPM、物理マシンを使ってサービス開発していたチームに向けて、できるだけ安定した性能、低遅延を提供するために、1台の物理サーバー上で、たかだか4台ぐらいのVMが動くように設計したものです。
リソースのサイズをチューニングしたり、Hypervisor上のQEMUの設定やカーネルパラメーターなどを、密度ではなくて性能重視になるようにチューニングをしたり、いろいろな工夫をしています。
リリースして半年ぐらい運用をしていますが、いろいろ課題が発生しています。1つ目は、「やはりベアメタルがいい」「物理マシンがいい」と言う開発者が非常に多くて、そういう人たちにどうやって利用促進していくかという難しさ。
あとは普通のVMであれば10台、20台載るので、多少VMスペックがバラついたとしても全体としてはうまくならされて収まりますが、物理サーバー上で2台、4台しか載らない設計だと、偏りがキャパシティ全体に影響するようなことが起きたりしていました。こちらは順次取り組み中の内容です。
もう1つの最近のトピックとしては、キャパシティ管理がすごく難しくなっている状況があります。Rich VMもそうですし、ほかにもMySQLのデータベースとか、Redis専用とか、必要とする性能の特性が異なるVMがたくさんあり、それぞれ別のグループで管理しています。
また、LINEはデータセンターをどんどん増設していて、ネットワークなどの仕様もどんどん新しくしているので、それぞれのデータセンター間で同じ在庫を共有できません。旧データセンター、新しいデータセンター、古いデータセンターの部屋を新しい仕様に改造した新データセンターなど、どんどん増えていきます。
このグループ数とデータセンター数という組み合わせで、何十というグループができてしまって、それぞれのキャパシティ管理をしなければいけない。一言でキャパシティ管理と言っても、実際には物理サーバーの発注、管理など、いろいろ構築したりも含まれるので、非常に煩雑になっている状況です。
これを解決しようとしている、Hypervisorの標準化や高密度化。あと古いデータセンターの環境をどんどん廃棄していくために、マイグレーションを促進していくような機能検討をしたりしています。
スライドは読み上げませんが、ほかにも取り組みがあります。必要なスキルとしては、仮想化に関する知識や、プログラミングできる方をお待ちしています。よろしくお願いします。
