LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


【Team & Project】OpenStackとKubernetesを用いたVerda Platformを開発しているチームを紹介します

LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズを開始します。

第一回目である今回は、インフラ領域を統括するITサービスセンターでPrivate Cloud「Verda」を企画・開発・運用するVerda室において、OpenStackとKubernetesを用いたVerda Platformを開発しているVerda Platform開発チームを紹介します。

Verda Platform開発チームのzoom会議の様子

Verdaは、LINEの共通インフラ基盤であるプライベートクラウドです。LINEでは、厳密なセキュリティポリシーとプライバシーポリシーがあるため、そのモデルに適用させるには既存クラウドでは難しく、セキュリティ、規模、プラットフォームの成熟性、コストを考慮して、社内でプライベートなクラウドプラットフォームを構築しました。
現在、LINEグループ内の全ての社員向けに提供されています。そしてプライベートクラウド自体は、60名ほどのインフラエンジニアによって、今でも追加開発が進められています。
そのVerda開発組織で、Verda Platform開発チームを率いるマネージャーの西脇雄基と、Platform開発チームのIaaSエリアをリードしている室井雅仁に話を聞きました。

―― まず、自己紹介をお願いします。

西脇:OpenStack、BaremetalなどのIaaS PlatformとIaaS上に構築されるContainer Platformの運用開発を担当しているVerda Platform開発チームでマネージャーとして働いています。

室井: Verda Platform開発チームには昨年の夏から所属し、現在はIaaSチームのテックリードとして働いています。私たちが利用しているOpenStackについては昔から関わっていた技術としてちょっと知っている人、チームとしては新人といったポジションです。

―― お二人がLINEに入った理由、働くやりがいなどを教えてください。

室井:私の場合は、チームの公用語が英語であることと、エンドユーザを向いたPlatform開発体制にとても興味がありました。そのPlatformのユーザは開発者ではなく、エンドユーザに対して価値を提供するために、Platformをどうするべきかという組織マインドを持っていたことが決め手になりました。

西脇: 私は、LINEはグローバルなサービスや開発拠点があり、エンジニアとして活躍しながら成長できる環境にとても魅力を感じました。手を上げれば、やれることがいくらでも増えていく文化です。そして、全てのインフラを1つの組織で提供するという組織体系や、様々な開発者に向けてPrivate Cloudとしてインフラ、開発環境、開発の効率化の仕組みを提供できるのはとても面白いと感じました。

室井:LINEという会社は、できる限り各個人がスペシャリストであれ、という会社方針とそれを後押しする組織文化があります。多種多様な人が働く中で、グローバル拠点を意識した社内文化や機能の設計、開発が必要なところもやりがいの一つですね。 特に私たちのチームは、バックオフィスの一つである社内プライベートクラウドの開発部署でありながら、社内のユーザと共に攻めの業務・機能開発が実施できるところはとても魅力的です。

西脇:そうですね。グローバルで仕事ができる環境ですし、技術的に興味深いものやインパクトの大きいものなど、解決すべき課題がいたるところに転がっているのでとても面白いです。その課題を解決していくことで様々な経験を積めて、その結果やれることがどんどん増えることが私のやりがいにつながっていると思います。

左からVerda Platform開発チームのマネージャーの西脇と、IaaSエリアをリードしている室井

―― チームの構成・役割などについて教えてください。

西脇:Verda Platform開発チームは、2020年4月現在、京都で働くメンバー2名を含め全16名のメンバーで構成され、Computing AbstractionグループとIaaSグループの大きく2つのグループに分かれて業務に取り組んでいます。
LINEにPrivate Cloudが導入されて約3年になりますが、導入される前に比べてサーバなどのインフラリソース調達のリードタイムが減り、社内開発者はインフラリソースを柔軟に作成・削除できようになりました。そして様々な社内サービス向けのインフラリソースが、多くの開発者によってPrivate Cloud上に作成されました。

導入から今日まで「簡単にリソースの作成・削除ができること」と「リソース提供にかかるリードタイムを短縮すること」を中心に取り組んでいましたが、サポートするサービス・スケール・開発者が増えるにつれ、利用の幅が広がりました。その結果、必ずしも期待している使われ方をしなかったり、利用者がワークロードに合わせて自身でPrivate Cloud GUI/APIを利用してインフラを用意するなど、インフラリソースを余分に用意することが増えました。全社的に見ると余剰リソースが無視できなくなってきたというような別の課題が見えてきたのです。 サービスのスケールと提供するサービスのバリエーションが増えたため、Private Cloudのスケール課題や運用コストが高まってきました。

そこで現在私たちは、これらの課題を解決するために様々なミッションをチーム全体として持ち、Computing AbstractionグループとIaaSグループで分担して取り組んでいます。

Computing Abstractionグループでは、「仮想マシンや物理マシンではなく、Kubernetesなどの抽象化レイヤを軸としたPrivate Cloudをメインで提供し、ユーザがインフラリソースを直接的に意識しないクラウドを提供する」というミッションを軸に具体的に以下の取り組みを進め、現在Managed Kubernetes Serviceの運用開発を実施しています。

  • 抽象化を通して、良い意味でユーザのインフラ利用方法の自由度を減らし、予期しない使われ方のリスクを減らす
  • 抽象化を通して、私たち側である程度どのようなシステムが動いているのかわかるようになるため、それを意識しつつ抽象化の下回りのインフラリソースの利用効率改善をインフラチーム主導で進める
  • 抽象化された実行環境を前提に、CI/CDシステムを全社共通で整備し、現在開発者が純粋に開発すること以外に費やしているコストをできる限り下げる

IaaSグループでは、IaaSリソースは「抽象化レイヤーの下回りとして利用されるため大規模なスケールをサポートする」、「抽象化レイヤーから細かいリソースコントロール(Scheduling、ResourceのLimitなど)ができるようなインターフェースを提供する」というミッションを軸に、現在OpenStackやIn-houseのBaremetaコンポーネントの運用開発を実施しています。

なお、大規模スケールにおいて、様々なコンポーネントの運用を少人数で実施できるような、Private Cloudのコントロールプレーンの運用基盤を構築することも私たちチーム全体のミッションです。

これは私たちが担当しているOpenStackやIn-houseコンポーネントを、あくまでも複雑なMicro Service Architectureの実例として捉え、それらの運用コストを極力ゼロに近づけるための仕組み作りをComputing Abstractionグループ、IaaSグループで協力して実現することを目指しています。

チームについて話す西脇

―― チームメンバーを紹介してください。

西脇:Verda Platform開発チームは、ロシア、中国、台湾、アメリカ、フランス、インドなど様々な国からエンジニアが集まっているため、メンバーの国籍も様々です。そのため、チーム内の公用語には、英語を利用しています。 メンバーのバックグランドも様々で、OpenStackコミュニティのとあるコンポーネントのProject Team Leadを務めていた方、OSSのCore Reviewerの方、OSSコミュニティ活動を積極的に実施されていた方もいますし、海外のカンファレンスで積極的に発表されていた方など多彩なエンジニアが集まっています。

―― 利用技術・開発環境について教えてください。

西脇:私たちのチームの守備領域は、IaaSレイヤからPaaSレイヤ(Managed Kubernetes Service)と幅広いため、利用しているソフトウェアや技術は多岐に渡ります。IaaSレイヤの基本的な部分はOpenStackを使って実現しているのですが、利用しているOpenStackコンポーネントとその周辺技術が普段私たちが見ている技術スタックと言えます。

Verda Platform開発チームで利用している技術・開発環境

例えば、OpenStackではDNS関連の管理を実現するDesignateを利用したり、OpenStackやIn-houseコンポーネントをソフトウェアとして動作させるためのミドルウェアとして「Kubernetes(OpenStackをはじめとした、プライベートクラウドのコントロールプレーンプロセスの実行基盤)」を利用しています。

Kubernetes導入の背景には、「マイクロサービスとして開発されている私たちのサービスのコントロールプレーンプロセスの運用を少人数で実施できるようにする」ことや「1つのインターフェースで多岐にわたるソフトウェアを管理したい」といった、私たちのスケールならではの課題があります。
また、OpenStackやIaaS関連のIn-houseコンポーネントは周辺OSSをうまく活用することで各機能を実現しています。物理/VM同士をつなぐネットワーク技術として、BGP、SRv6を利用したClosネットワークやマルチテナントを実現するなど、それらの下回りとしては様々な技術やソフトウェアを活用しています。

PaaSレイヤに関しては、Rancherを用いて複数のKubernetesクラスタの管理を実現しているため、Kubernetesを使うための技術、Kubernetesを構成する技術、Rancher(クラスタの管理技術)に関わる周辺技術が普段私たちが見ている技術領域になります。
また、ここではRancherと紹介していますが、Rancherをそのまま使うのではなく、Rancherのクラスタのマネジメント機能に絞って、私たちのスケールとPrivate Cloudに合うように追加開発をしています。
そのためRancherというよりは、クラスタをマネジメントする実装としてKubernetesのCustomer Controllerを作っています。「そのベースがRancherである」という方が正しく私たちの現在の状況を説明しています。KubernetesもOpenStackと同じく、Linuxにかねてから存在する機能や、OSSを駆使してContainerの管理を実現しているため、Container同士が仮想IPで通信することを実現するNetfilterやconntrack、Containerが他のContainerと干渉しないようにアイソレーションを実現するLinux namespaceなど、これらの下回りも私たちが普段意識している技術領域です。

―― 今のチーム課題を教えてください。

室井:IaaS チームでは、大きく分けると「IaaS としての新機能の開発から実環境へのデリバリーまでにかかるコストの増加」と「エラー発生時の故障箇所切り分けの難しさ」の2つの課題があると感じています。

まず、1つ目の「デリバリーにかかるコストの増加」とは、IaaSが機能、規模の両面で拡大した事で、機能開発そのものよりもその他の部分で時間がかかってしまうという課題です。 私たちが開発しているIaaSレイヤは、ユーザ向けのサービスが動作しているVMを直接管理するとともに、前述のPaaSレイヤであるKubernetes の他に、Verdaクラウドとして開発者に提供しているManaged Kafka, Managed MySQLなどのサービスの下回りとしても動作しています。そのため、IaaSレイヤで新機能の追加や開発を行うと、その影響範囲はVerdaクラウド全体に影響してきます。そうすると、新機能の実装自体は簡単だとしても、実装前の周辺機能での影響調査とその対応、QA対象の増加、新機能デプロイの時期合わせなど、実際の開発に関係する範囲がIaaSレイヤを超える事がよくあります。先日、Verdaクラウド利用時のaudit logを取得できるようにする変更を加えた時には、当たり前ですが、ほぼすべてのサービスのQAをAPI、 GUIの両方で一から実施する必要がありました。

2つ目の「切り分けの難しさ」は、先に紹介したIaaSレイヤはPaaSレイヤの下回りを担っている事に起因する課題です。VerdaクラウドではIaaSを含めてすべてMicro Service Architectureで開発、運用しています。そのため各サービス間は関係がないように思われますが、IaaSレイヤでは全ての起点になるサービスを保有しているため、殆どの操作はIaaSレイヤを経由することになります。具体的には、Maganed MySQLインスタンス作成時にはVMの作成が必要になりますし、各サービスの認証ではOpenStackのKeystoneがすべての起点となっています。そうすると、何かしらのエラーが起こった際に、エラーの解析時にはどうしてもIaaSレイヤのサポートが必要になってきてしまいます。

―― 課題解決に向けた取り組みを教えてください。

室井:先ほど述べた課題は、なにか一つ新しい技術を取り入れれば万事解決というような課題ではなく、IaaSやPaaSレイヤも含めたクラウドの規模拡大や関連組織の増加とともに発生する一般的な課題だと考えています。そのため、課題の解決に役立つ技術の目利きや内製開発に加えて、組織文化の変革といった活動をチーム横断で行っています。

「デリバリーのコスト増加という課題」の解決に向けた取り組みとしては、IaaSチームではVerdaクラウドのKubernetesを利用して、宣言的なデプロイやロールバックの実現や、CustomResourceやOperatorの開発による運用作業の as Code化を行っています。ただ、これだけでは「開発・ステージングへのリリース → QA → 本番環境へのリリース → QA」といった新機能のデリバリー全体で考えると、個別の最適化に留まってしまっています。そこで、開発から本番環境のQAまで一気通貫でデリバリーを早くするように、テストの自動化はもちろんのこと、リリースとQAをつなぐパイプラインの開発や自動テストが難しいビジネスロジックの as Service化によるQA自動化の実現といった活動をQAチームと協力して実施しています。

「切り分けの難しさ」という課題では、IaaSレイヤの大半を担っているOpenStackとVerdaクラウド全体の見える化といった取り組みを行っています。システムの見える化というと、システムの監視やメトリックス取得、といった事が思い浮かべられます。基本的な監視やメトリックス取得はすでに実施した上での課題なので、OpenStack内部構造に踏み込んだメトリックスの取得やOpenStackで利用しているrequest-idという機能を活用したVerda全体で個別リクエストのトレーシング機能の開発といった取り組みを行っています。
また、こちらの見える化の活動の一部は、OpenStackコミュニティとも連携してアップストリーム活動を実施しています。Verdaクラウドは世界有数の規模であるため、この規模で顕著化するパフォーマンスやスケールの技術的問題が出てきています。これらを社内だけでなくOSSコミュニティとして解決することで、OpenStack業界全体での技術的課題の解決を実施しています。

チームの課題解決に向けた取り組みについて話す室井

―― 今後のロードマップを教えてください。

室井:IaaSグループでは「今の10倍のスケールでも新規機能の開発運用できる最強のIaaS基盤」を目指して進んでいこうと考えています。具体的には、スケールというとハイパーバイザの数やVMの数ばかりが出てきますが、ユーザの数、IaaSの上で動いているPaaSレイヤのas Service数が10倍になっても、今と同じかもっと簡単にIaaSの新機能のリリースや運用ができる基盤と文化を目指しています。「インフラは規模が大きくなると変更しづらくなる」と一般的に言われているので、ここを打ち破っていきたいと思います。Verdaクラウドが始まって3年が経ち、Infrastructure as a Serviceの旧来のInfrastructureに相当する部分の多くがas Service化が進みました。これによってクラウドの規模も世界有数のスケールになり前述のような課題も出てきています。まだまだ取り組みも道半ばなのですが、次のような事を一つ一つ実現していく予定です。

  • KubernetesのOperatorなどを活用した「作業する運用」から「開発する運用」への切り替え
  • ビジネスロジックのas Service化の範囲をOpenStack以外のVerdaクラウドのサービスにも適用
  • IaaSで取り組んでいる開発のデリバリー機能自体の社内への展開(Software Delivery as a Serviceのようなもの)

また、様々なリソースをas Service化した事によってIaaSのユーザ側での新たなる課題も出てきているため、Computing Abstructionグループと協力をしながら「旧来のインフラリソースでは手動やスクリプトで実施していた作業の複雑化・煩雑化の解消」、「IPによるDBのACL設定など、旧来のインフラリソースの仕組みを前提としたアプリケーションが、クラウドネイティブなインフラと相性が非常に悪い」というようないくつかのR&D的な対応を進めて行く予定です。

西脇:Computing Abstractionグループでは、「ユーザがインフラリソースを直接的に意識しないクラウドを提供する」を実現するための最初のステップとして、まずは社内開発者にKubernetesなどServerを直接意識しないアプリケーション開発、運用に慣れてもらうために、運用を気にせず利用することができるManagedなKubernetesを2019年10月にProduction環境で提供開始したところです。そのため、まだまだこれからが本番!という感じですが、現在、Short TermとLong Termの2つの方向性で検討、開発を進めています。

Short Term

現在サービス開発チームごとに提供しているKubernetesクラスタの利便性を上げ、カバーできるユースケースを増やすための活動として、次のような取り組みを計画しています。

  • 仮想マシンだけでなく、物理マシンのサポート
  • Load balancerやPersistent Volumeなどその他のPrivate Cloudコンポーネントとの連携強化
  • 複数Regionのサポート(Kubernetes Workerの複数Regionサポート、Kubernetes C-planeのRegion故障対策のサポート)
  • 大規模クラスタ(1000Node以上)サポートに向けた検討材料の洗い出しとサポートに向けた実装
  • Kubernetes上での開発プロセスの標準化(Monitoring、CI/CD、Auditing)

Long Term

Short Termで課題となっている次のような内容を解決することを目的に、いくつか抜本的にDCレベルでアーキテクチャの再考をしています。

  • 1サービス1クラスタを前提にクラスタを提供していることによる、リソースの無駄遣い
  • クラスタごとにKubernetes C-plane をDeployしないといけない(2020年4月時点で400近いクラスタが作成されている)
  • Kubernetesクラスタをまたいでリソースの有効活用をすることができないというデザイン上の課題
  • クラスタのマネジメントコスト、クラスタ準備のリードタイム
  • 利用開始の際、API1つでクラスタの作成は可能だが、クラスタの構築からする必要があるため、構築までに時間がかかる
  • クラスタのCapacity管理、クラスタ上でのリソース展開をクラスタごとにユーザが実施する必要がある

これらの課題に対して、現在次のような方向性でアーキテクチャの再考をするような長期間プロジェクトも同時並行で進めています。長期プロジェクトの中では下記のような検討と要素技術検証が行われています。

  • 1サービス1クラスタといった形で適宜クラスタの構築をするのではなく、あらかじめ構築されている1つのクラスタで複数のサービスをカバーできるようにするための要素技術検証
    (注:ここでいう1クラスタは、必ずしも1つのKubernetes Cplaneだけで構成されている必要はなく、1つのInterfaceで複数のクラスタが管理されていればそれは1つのクラスタとします)
    • 物理サーバ35,000台以上(Scaleの観点)、複数のRegion、Location(Failure Domain、Latencyの観点)でKubernetesを構成する際のDeployment Design
    • 複数のクラスタを協調させるための仕組みの検討
    • 1つのクラスタに複数のサービスが動くため、NW観点での最適なアイソレーション、セキュリティのアイソレーション、予期せぬリソースの干渉を防ぐためのQOS制御
  • 1つのクラスタ(インターフェース)上で、アプリケーションの開発、テスト、リリースをするためのCI/CD環境の整備し、カバーするサービスのカバレッジをあげる

(注:現段階では、Kubernetesをある程度前提に検討をしていますが、このプロジェクトの結果、「部分的にKubernetesを使い、全機能をそのままでは使わない」という結果もある程度想定しています。)

Long Termの方はかなり抽象的ですが、短期的に必要であり且つ求められている既存のソリューションベースのものだけでなく、既存のソリューションに固執せず本質に戻って本当に必要なものを技術的に整理し、要素技術検証から導入までを実施するような長期的な目線も持ち、今後開発を進めていく予定です。

―― 最後に、Verdaプラットフォーム開発 チームに興味を持ってくれた人にメッセージをお願いします。

室井: Verda Platformチームのメンバーは、技術的にも様々なバックグラウンドを持った方が集まっています。OpenStackに詳しい人、ネットワークに詳しい人、コーディングがとても上手い人など、様々なメンバーで普段から業務を行っています。IaaSレイヤは関連する技術領域は多岐に渡るため、色々な領域で技術的にもチャレンジをすることができます。なので「私〇〇は詳しくないから」ではなく「○○は私に任せろー!!」という意気込みの方を探しています。

西脇: Verda Platformチームは、IaaSレイヤーからPaaSレイヤーと幅広い範囲の責任を持っているチームです。LINEが持っているサーバの数やサービスの種類、開発拠点や開発者人数のスケールだからこそ出てくる課題は多岐に渡ります。これらの課題に対して幅広い技術を扱うチームならではの観点で、本質的な解決策を検討・実装することができるのは私たちのチームの1つの強みだと思います。
このようなスケール、LINEのシチュエーションに対して、ベストフィットする既存ソリューションはなかなか見つかりません。これらの課題に対して、本質的に何が必要なのか運用、仮想化、ネットワーク、アプリケーションのCI/CDなど多岐にわたるレイヤーから、「これらを自分たちで一串に検討して本質的な解決策やソリューションを築き上げたい!」というチャレンジ精神に溢れている方にぜひ来ていただきたいと思います!!

Verdaプラットフォーム開発チームではメンバーを募集しています。