Verda 1/2:CloudNative/OpenStack Days 2019-Tokyoパネルセッションレポート

このエントリは英語の記事をベースに翻訳したものです、英語版はこちら

アジアを中心に大規模なユーザー数を抱えるコミュニケーションアプリ「LINE」の内部バックエンドで、インフラを管理するために、がどのようなシステムが使われているか気になったことはありませんか?もしあるなら、今こそ、LINEのインフラ管理を知るチャンスです。
LINEは、最近行われたCloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019(https://eventregist.com/e/cndt-osdt2019)で、Verdaと呼ばれるLINE独自のOpenStackクラウドの全貌を紹介するパネルを展示しました。
この記事では、そのパネルで説明したLINEでOpenStackをどのように使ってプライベートクラウドを構築/提供しているのかを、改めて詳しく紹介します。

では、始めましょう!

これから2つの記事で、Verdaのエコシステム全体を簡潔に説明していきます。すでにご存じの内容がある場合は、興味がある部分だけピックアップして読んでください。
記事の構成:

  1. Verda 1/2:Cloud Native/OpenStack Days 2019-Tokyoパネルセッションレポート
    →LINEのOpenStack「Verda」の全貌
  2. Verda 2/2:Cloud Native/OpenStack Days 2019-Tokyoパネルセッションレポート
    →プライベートクラウドユーザーの要件を満たすLINEのネットワーク設計

この記事では、LINEのOpenStack「Verda」の全貌に焦点を絞り、LINEが持つOpenStackエコシステム全体を紹介していきます。

1. LINEのOpenStack「Verda」の概要

ここでは、パネルの以下の部分について説明します。

どのクラウドも最初は非常に小さな規模で始まります。LINEもそうでした。LINEのOpenStackの旅は、2016年にOpenStackの「Mitaka」(https://www.openstack.org/software/mitaka/)がリリースされたときに始まりました。当初は1つのリージョンと少数のハイパーバイザーしかありませんでした。時は過ぎ、今では本番クラスタに3つのリージョン、合計860のハイパーバイザーがあり、開発クラスタには600のハイパーバイザーがあります。
また、マルチテナントを実現した新しいセミパブリッククラウドも最近導入されました。今では「Verda」として、目的の異なる3つのOpenStackクラスタを開発/提供しています。

プライベートクラウドにOpenStackを使用するにあたってのLINEの基本方針

1. ユーザーのアクセスを制限することで、単純なプライベートクラウドを提供する

現在のところ、Verdaの主なユーザーは、OpenStackの運用方法や使い方をあまり知らない人も含めた、LINE社内のアプリケーション開発者です。
そのため、あえて提供する機能を制限し、ユーザーがプライベートクラウドを利用する際に、操作に迷わないように設計しています。

  • 制限されたネットワークのみを提供する

Linux Bridgeベースのハイパーバイザーが使われている古いリージョンでは、OpenStackでVM(Virtual Machine)を作成するために、そのVMが使うネットワークを提供する必要があります。
つまりユーザーは、ネットワークの各種設定に注意する必要があります。たとえば、ネットワークの割り当てに失敗したためにVMが作成できなかった場合は、ユーザーは他のネットワークを割り当ててVMが作成できるか試す必要があります。
LINEでは、そのような下位レベルのネットワークの詳細でユーザーが悩む必要がないように、ネットワーク割り当ての部分は、できる限りプライベートクラウドで適切なものが選択されるようにしたいと考えました。
ユーザーは、PublicとPrivateの2つのネットワークしか見えないようになっています。これらのネットワークは、OpenStackのNovaを経由して、ハイパーバイザーが実際に使用している下位ネットワークと置き換える仕組みです。
なお、新しいリージョンに対しては、このネットワーク抽象化を必要としないCLOSベースのBGPネットワークを採用しました。これについては2つ目の記事で説明しています。

  • 共有イメージのみを提供する

ユーザーが、VMイメージの複雑な管理をしなくても済むようにしました。
具体的には、ユーザーは、プライベートクラウド運用者が管理しているVMイメージのみを使用できるようにしました。イメージ内のセキュリティ上の設定や、VMアクセスのための設定などは、プライベートクラウド運用者が継続的にメンテナンスします。このようなVMイメージを、私たちは「ゴールデンイメージ」と呼んでいます。

  • 一時ストレージをVMに提供する

OpenStack Cinderが提供するブロックストレージのボリュームを、永続ストレージ向けのセカンドデバイスとして提供しています。

  • より簡単なダッシュボードを提供する

LINEのサービスでは、OpenStackをベースにして、機能のを制限したり、カスタマイズをしたりしているため、OpenStack標準のダッシュボードHorizonは、使いにくくなってしまいました。
また、ユーザーのが、がネットワークやセキュリティグループに対して関するによって誤った設定変更を行ったために発生する障害を防ぎたいと考えました。
そこで、社内で独自に開発したダッシュボードを提供しました。このダッシュボードの機能は、運用や使用が簡単なものに制限しています。

ダッシュボードを開発するために、プライベートクラウド専用のGUIチームも設けていることから、私たちの本気度を推測していただけると思います。

  • 共有DNSゾーンを提供する

Neutronが提供するネットワークをプロジェクト間で共有することは、非常によく起こります。このため、ゾーンの機能は類似している必要があります。OpenStack「Verda」では、OpenStackではまだサポートされていない共有DNSゾーンを提供しています。OpenStack Designateをカスタマイズして特定のゾーンに「共有」マークを付与できるようにしました。共有マークを付与したゾーンは、異なるプロジェクト間で利用できます。
なお、Designateのレコードセットは、各プロジェクトで所有されています。

2. 特定の操作向けの承認プロセス

既存のクラウドに広範囲に影響を与える可能性がある一部の機能は、ユーザーが直接実行できないようにしました。たとえば、プロジェクトの作成や割り当ての申請などのOpenStackの機能が該当します。

このような機能を実行するためには、LINEが内部開発した承認システムに担当者がリクエストを送信し、そのリクエストが承認される必要があります。リクエストが承認されると、実際のOpenStackサービスにそのリクエストが送られ、API呼び出しが行われる仕組みです。LINEでは、このような仕組みを、OpenStackコンポーネントのカスタマイズを必要に応じて行うことで実現しました。

3. レガシーシステムをOpenStackに統合する

OpenStackへ移行する前は、LINE社内のアプリケーション開発者は、全社で利用できるシステム(レガシーシステム)を使用して、サーバーのステータスの確認や監視、サーバーへのログインを行っていました。

こうしたレガシーシステムを、Knative(https://cloud.google.com/knative/)でサポートされるFaaS(Function as a Service)を用いてOpenStackと統合しました。
FaaSを使うと、cronやVM作成などの各種イベントでトリガーされるあらゆるタイプの機能を、プライベートクラウド運用者が登録できるようになります。FaaSでは、oslo.messagingが提供するnotificationエコシステムを通じて、ポート作成やVM作成などのOpenStack内のリソース変更イベントを扱えます。LINEでは、レガシーシステムをOpenStackに統合する際、このFaaSを大いに活用しました。

FaaSを活用するアプローチでは、OpenStackのアップストリームコードをきれいに維持できます。そのため、この種のカスタマイズでは、積極的にFaaSを利用すると良いでしょう。
レガシーシステムを利用していたときは、これまでユーザーは、サーバーへのログイン時にSSHキーを利用せず、Kerberos認証のみを使っていました。現在では、OpenStack Keystoneと当社のクラウドイメージをカスタマイズすることで、同じユーザーエクスペリエンスを維持しています。

4. アクセス制御を、ユーザータイプに基づく制御のみに制限する

LINEでは、さまざまなユーザーがVerdaを使用します。ユーザーをLINEの社員か、LINEのパートナー企業の社員か、というように所属でユーザータイプを定義しました。そして、ユーザータイプに基づいて、アクセスを制御したり、ロールの割り当てを制御したりします。

たとえば、LINEの社員は、プロジェクトのAdminになることができますが、パートナー企業の社員ユーザーは、Adminになることができません。(LINEのパートナー企業の社員など)

5. 社員IDとKeystoneを会社管理のシステムから同期する

LINEが全社で利用しているユーザー管理システムから、ユーザー情報を同期してSSO(シングルサインオン)を実現しています。そのため、ユーザーは社内システムから「Verda」にアクセスするたびに、ログインする必要はありません。

6. VMにVM名でアクセス可能にする

VM名をクラウド全体で一意にしているため、ユーザーはVMにVM名でアクセスできます。これは、一意のDNSレコードをDesignateに作成するのに役立ちます。

LINEのOpenStack:「Verda」のエコシステム

上の図は、本番クラスタのエコシステムを示しています。現在のところ、本番環境には3つのOpenStackリージョンがあります。

「Verda」のエコシステム内でのコンポーネントには次の3つのロールがあります。

  1. グローバルコンポーネント
  2. リージョンベースのコンポーネント
  3. 運用コンポーネント

1. グローバルコンポーネント(Global Components)

グローバルコンポーネントとは、デプロイした全OpenStackリージョン間で共有されるコンポーネントです。下記のコンポーネントはグローバルにデプロイされます。

  1. Keystone
  2. Designate
  3. Approval
  4. FaaS(Knative)

グローバルコンポーネントは、高可用性を提供しなければならないため、私たちは、一部のコンポーネントを、DR(Disaster Recovery。災害復旧)リージョンとして機能する別のリージョンに、レプリケートしました。
上図のとおり、DR MainリージョンにはKeystoneとDesignateがあります。これらを、DRリージョンとして機能するDR Standbyリージョンにレプリケートします。各リージョンの前にはハードウェアロードバランサーを設置しています。

2. リージョンベースのコンポーネント(Regional Components)

各リージョンには、目的とするサービス用途があります。Verdaでサービスをオンデマンドで提供するために、サービスを提供するリソースをリージョンごとに用意しています。
以下のコンポーネントを、リージョンごとに用意しました。

  • Nova
    • VMをオンデマンドで提供
  • Neutron 
    • 同じリージョンのVMにネットワークを提供
  • Glance 
    • 同じリージョンのVMにクラウドイメージを提供
  • Cinder 
    • VMの永続ボリュームを提供
  • Mysql(https://www.mysql.com/
    • リージョン内のサービスで、データを保持するためのデータベースサービスを提供 
  • RabbitMQ(https://www.rabbitmq.com/
    • 現在のところ3つの異なるRabbitMQクラスタがあり、それぞれに3つのデータノードと2つの追加管理ノードがあります。
    • データノードと管理ノードを分離するために、RabbitMQ管理プラグインを使用しています。これは、他の全ノードの統計をRabbitMQクラスタと分離するために大量のメモリが使用されていて、これが原因でノードがクラッシュしていることに気が付いたためです。
    • OpenStackクライアントは、RabbitMQリクエストに対処するRabbitMQデータノードにのみ接続します。管理ノードの目的は、監視と運用のみです。
    • Verdaでは、NovaとNeutronが最もよく使われるサービスです。これらがRabbitMQに大量のトラフィックを発生させていることが分かったため、それぞれに以下のように別々のRabbitMQクラスタを作成しました。
      • Nova用クラスタ:
        • 3つのデータノード
        • 統計データベースをホストする2つの管理ノード(Neutronクラスタと共有され、コンテナと一緒にデプロイされるNeutron用クラスタ:
        • 3つのデータノード
        • 統計データベースをホストする2つの管理ノード(Novaクラスタと共有され、コンテナと一緒にデプロイされる)その他のサービス用クラスタ:
        • 3つのデータノード
        • 統計データベースをホストする2つの管理ノード
    • RabbitMQRabbitMQデータノードは、L4ハードウェアロードバランサーの背後に配置しています。これにより、接続がすべてのRabbitMQデータノード間で分散されます。なお、RabbitMQメッセージをリージョン間で転送するために、RabbitMQシャベルプラグインを活用しています。

3. 運用コンポーネント(Operation Tools)

以下の運用コンポーネントを使用しています。

  • 監視ツール
    • Prometheus
    • Grafana
    • Elasticsearch
  • Back office(VBO:Verda Back Office):ベアメタルサーバーなどのサーバーの実際の統計を監視するレガシーツール
  • Workflow Monitoring(Ogenki):ユーザーが頻繁に実施するオペレーションを模倣し、オペレーションを実行するかどうかを監視(例:VM作成、SSHログインなど)するツール
  • Ansible for Deploy(Kraken):通常のデプロイや、実際のクラウド状態とAnsible内の構成との整合性を監視するためのツール

マルチリージョンデプロイ

Keystoneカタログは、各リージョンのサービス検出に使用されます。つまり、Keystoneカタログを確認すると、どのサービスをどのリージョンで使用できるかを把握できます。

終わりに

本記事をお読みいただきありがとうございました。2回目2つ目のブログ記事では、LINEが提供している3種類のネットワークについて説明します。

Related Post