LINEのプライベートクラウド「Verda」「Verda Dev」
山田英樹氏：Verda室Verda Reliability Engineeringチームの山田と申します。私からはVerda室全体と、VREチームで募集しているポジションについて説明をします。
先ほどから別のセッションで何度か説明がありましたが、「Verda」は、LINEの社内にあるプライベートクラウドです。AWSみたいなものですね。2種類のクラスターがあり、本番環境に使う「Verda」と、開発用に使う「Verda Dev」があります。多少、運用ポリシーなどは違いますが、どちらも同じコードベースで動いていて、ほぼ同じものです。
（スライドを示して）Verdaの持つ機能が、ここにいろいろと書かれています。一番下のIaaSの部分は、「OpenStack」を中心に構築されています。ストレージもそろっていて、ブロックストレージとオブジェクトストレージがあります。
ここには書いていませんが、共有ファイルシステムの提供もあります。もちろん、VMやロードバランサーを作ることができますし、ベアメタルサービスもあります。
このようなIaaSの部分を使った、もう少し高度なマネージドサービスとして、コンテナのランタイムを提供している「Kubernetes」があります。
データベースもほぼこのVerdaでプロビジョニングが自動化されており、「Redis」「MySQL」「Elasticsearch」があります。ほかには、ファンクションを実行する機構もあります。
（スライドを示して）これが、Verdaのダッシュボードのサンプル画面です。これはVMの一覧を表示しているところで、このようなかたちでホスト名、フレーバー、現在のステータスみたいなものが見られるようになっています。
Verdaの規模は仮想マシンで9万台以上
Verdaの規模ですが、現在LINEのインフラ全体のVMに関しては、ほとんどがVerdaになっています。ベアメタルに関しては比較の数字が今手元にありませんが、半分ぐらいVerdaになっていると思います。
数字で言うと、ハイパーバイザーが7,200台以上。Verdaで管理された物理マシンが4万5,000台以上。仮想マシンが9万台以上という規模になっています。
SRE的な活動を通じて開発者を助けるVREチーム
Verdaの組織では、このようなさまざまなサービスを、それぞれチームで分かれて担当しています。今回紹介するポジションが、その中のVREというチームです。
VREとは、Verda Reliability Engineeringの略です。いわゆるSRE的な活動を通じて、LINE社内のアプリケーション開発者とVerdaの内部の開発者を助けることがミッションになっています。
現在、このVREチームは大きく2つのユニットで活動をしています。上がいわゆる、SREみたいなものですね。モニタリング基盤、ログを記録する基盤、メトリクスを記録するための基盤、デプロイメントなど、共通のプラットフォームを提供しているところです。
Infra resource managementユニットの担当業務とスキルセット
今回紹介するのは、下のInfra resource managementのユニットです。ここでは、Verdaのサービスを載せている物理インフラを管理します。具体的には、ラック、物理サーバー、ネットワークなどを、先ほど紹介したシステム室やネットワーク室と協力しながら管理したり、増やしたり、構築を自動化するツールを開発したりしています。
このユニットの具体的な業務内容について。主にハイパーバイザーやVM全般を見ています。それに加えて、LINEの社内にあるほかのシステムとの連携ですね。認証のシステム、資産管理のシステムなど、さまざまなシステムがあり、その連携部分での信頼性向上に取り組んでいます。
必要なスキルセットですが、ハイパーバイザーを主に扱っているので、仮想化技術に関する知識が必要です。「VMware」というより、Linuxの仮想化の「QEMU」「KVM」など、それに加えてOpenStackの知識ですね。
トラブルシューティングもたくさんするので、Linuxのシステム管理に関する知識が必要ですし、ハイパーバイザーの調達をするにあたって、サーバーハードウェアの知識がある程度必要です。また、自動化をどんどん進めているので、Pythonやシェルスクリプト。プログラミングではありませんが、「Ansible」も書けると、なおよいと思います。
Infra resource managementユニットが担当した複数データセンター導入プロジェクト
もう少し具体的に最近の仕事の例を紹介したいと思います。
1つ目が、複数データセンターの導入です。いろいろ大変なところがありました。東京の近郊でいくつかデータセンターを建てて、それらを連携してサービスを構築しようというところです。サーバーの需要がどんどん増えている都合で、そもそもラックのスペースが足りていないので、こういった導入が進んでいます。
ここの中で、VREチームがどういうことをしたかを列挙してみました。地味なものからいろいろありますが、例えばハイパーバイザーのホスト名が、今までLINE全社で使っているホスト名の命名規則だと足りなくなってきたので、新しい規則を作って、これを使いましょうと決定をしました。
あとは、Verda内部の開発者向けですね。Verdaが複数データセンターに対応するために、内部コンポーネントをいろいろ開発しなきゃいけません。それを開発するためのテストをするステージング環境が必要なので、ステージング環境を構築しました。
データセンターを跨いだ場合、ネットワークの設定を新しく追加しなければいけなかったり、OpenStackに対してコンフィグをいろいろ入れなければいけなかったりしたので、そのあたりをネットワークチームと情報をやり取りして、必要なところは自動化を進めています。
また、データセンターが複数になったので、このデータセンターにはVMあるけれど、こっちのデータセンターにはVMが足りていないという状況が多発しています。VMの在庫を可視化するために、「Prometheus」と「Grafana」を使ったダッシュボードを作成して、管理側であるインフラチームが見られるようにしました。
ほかには、Verdaの内部での全体スケジュールの管理ですね。複数コンポーネントがそれぞれのチームで分かれていて、それぞれで対応して進めている状況なので、物理サーバーの納期も見つつ、こっちのUIの対応は完了しているか、Kubernetesサービスの対応は完了しているかと、1個1個チェックして進めていくプロジェクトマネジメント的なこともやっています。
日々行っているVMハンドリング
プロジェクト以外だと、Daily Operationがそれなりの割合であります。例の1つ目は、VMを大量に使いたいという案件について、ハンドリング、コンサルティングするところですね。
Verdaはクラウドなので、APIを叩けばインスタンスを作成できます。ただ、裏側にあるサーバーは有限なので、いきなり「高性能なVMが200台欲しいです」と言われた時に、「さすがにちょっと今は在庫がないです」みたいなことがあります。
そういう時に、在庫がどれだけあるのか、いつ頃増えるかなどを可視化する必要があります。そのためにダッシュボードを改良したり、たくさん来ている案件を取りまとめて、事業的にどこが重要で、どこから優先的に提供しなければいけないかを判断したりします。
実際にサーバーが欲しいと言っているのは、Verdaのユーザーで、LINE社内のアプリケーション開発者です。アプリケーション開発者たちが、今のインフラの状況がわかるように、ドキュメントを改良する仕事をしていました。
もう1つ挙げると、よくあるのが、謎VMの調査です。9万台以上のVMがあると言いましたが、9万台以上もあると、管理していた人が退職していたり、今の状況がわからなくなるVMも発生するんですね。
また、ほかの資産管理のシステムなどでは、認証のシステムとの間でデータの不整合が起こることがまれに発生します。
まれと言っても、9万台もあるので毎週、毎日のレベルで発生しています。その原因を突き止めて、修正する仕事もしています。
これにはいろいろな原因があって、既知のパターンの自動化はだいたい済んでいますが、それでもどんどん新しいパターンの不整合が発生しているので、日々調査することが必要です。
そのためには、OpenStackや、Linuxに関する知識、社内の事情や歴史的経緯も把握した上で、総合的なトラブルシューティングが必要になるポジションになっています。
VREチームからの説明はこれで終わりです。
