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

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

この記事は、Verda 1/2:CloudNative/OpenStack Days 2019-Tokyoパネルセッションレポートの続きです。前の記事では、Verdaのエコシステム全体について説明しました。この記事では、ネットワーク側の課題をその経緯とともに説明し、Verda内で行われた最適化と改善内容を紹介します。

Verdaのネットワーク設計

ここでは、Verdaのデータセンターネットワークの下記の3つの推移を確認します。

  1. アップストリームソリューションLinux BridgeでサポートされるL2ベースのネットワーク
  2. L3のみのフラットネットワーク:LINEで独自開発したプラグイン
  3. L3ベースのオーバーレイネットワーク:LINEで独自開発したプラグイン

1. アップストリームソリューションLinux BridgeでサポートされるL2ベースのネットワーク

本構成の動機と課題

ラック間で大規模L2ネットワークを維持することには、BUMトラフィック(https://en.wikipedia.org/wiki/Broadcast,_unknown-unicast_and_multicast_traffic)の扱いなどの問題や課題がありました。そこで、プライベートクラウド内のL2ドメインを小さくするために、各ラックごとにL2ネットワークのプロビジョニングを行いました。
OpenStack Novaでは、VM(Virutual Machine)起動リクエスト時に、VMが使用する実際のネットワークを提供する必要があるため、ラックごとの下位ネットワークすべてがユーザーに公開されることになりました。これは、「1つのNeutronネットワークが1つのL2ネットワークを表す」という概念からくる制約です。ネットワークの割り当てが原因で特定のラックでVM障害が発生すると、ユーザーは別のラックのネットワークで再試行しなければならず、これがエンドユーザーの観点からは複雑さを非常に高めていました。

本構成のポイント

1つのプライベートクラウドで複数の小規模L2を実現できますが、この場合、複数のネットワークがエンドユーザーに公開されることになり、ユーザーが混乱することが考えられます。

この問題を解決するために、ネットワークを抽象化し、ユーザーに見える共有ネットワークのみをユーザーに提供しました。しかし、この共有ネットワークは、どのVMも使用しません。
L2ネットワークはネットワークラックごとに存在するため、VM起動リクエストでユーザーが要求したネットワークを、VMの起動が予定されているハイパーバイザーが使用する下位ネットワークに置き換えました。
OpenStack NeutronのLinux Bridgeエージェントを各ハイパーバイザーで使用し、NeutronのMetadataエージェントとDHCPエージェントを同じネットワークラックの2つのコンピュートノードに配置しました。

本構成の問題

この設計は最初の数ヵ月はうまく機能しました。しかししばらくすると、ToR(トップオブラック)スイッチからアグリゲーションスイッチまでのアップリンク帯域幅に制限があるため、問題が起こり始めました。異なるネットワークラックに配置されているVM間に大量のEast-Westトラフィックが発生するたびに、ToRがボトルネックとなり、スループットが大幅に低下したのです。このため、私たちの次の課題は、ノンブロッキングネットワーク、より細かなトラフィック管理、ポータブルIPアドレスなどを実現することでした。

この設計では、Novaの一部の機能も制限され、たとえばユーザーは同じラックでサイズ変更、移行、または避難しかできませんでした。
ネットワークを共有していたため、全テナントが同じネットワークを使うことになりました。また、ネットワークの観点からはマルチテナントがサポートされていませんでした。

2. L3のみのフラットネットワーク:LINEで独自開発したプラグイン

本構成の動機

L2ベースのネットワーク設計では、Nova機能が制限されたり、スループットが低下したり、という問題に直面しました。このため、RFC 7938で推奨されるBGPベースのCLOSネットワーク概念を用いた新しいネットワーク設計を導入することに決定しました。

本構成のポイント

上の図のとおり、L2ネットワークをハイパーバイザーレベルで終端しました。
VMのすべての内部通信に/32ルーティングを使用しています。ネットワークノードは不要です。ただし、アップストリームソリューションであるNeutronのLinux BridgeエージェントもOVSエージェントも、/32ルーティングのみではVMの内部通信をサポートしません。

このため、LINEのエンジニアは、以下で構成される新しいNeutron L2 Isolateプラグインを開発しました。 

  • L2 Isolate Mechanism Driver(ML2プラグイン)
  • Routed Type Driver(ML2プラグイン)
  • L2 Isolate Agent

L2 Isolate Agent環境では、ネットワークノードは必要ありません。この環境では、コンピュートノードがL2ネットワークを終端します。つまり、L2に到達するためにVMを必要とするサービスは、各コンピュートノードによって提供される必要があります。このため、Metadataエージェントはネットワークノードからコンピュートノードに移され、DHCPサービスは各コンピュートノード上で実行されているL2 Isolate Agentが起動/管理しているdnsmasqで提供されます。

共通のLinux BridgeエージェントとL2分離エージェントとの違い
VMの通信
  • 新しいTAPデバイスがNovaコンピュートで作成されると、新しいNeutron L2 Isolate Agentがそれを検出し、検出されたTAPに対してVMのIP /32ルートとプロキシARPを構成します。

このためVMは、同じハイパーバイザー上の他のVMと、ブリッジなしで直接通信できます。VMが別のハイパーバイザー上の他のVMと通信できるようにするために、BPGを伝達するFRRルーティングデーモンを使用して、VMのIP /32の経路をToRスイッチに広報します。

  • DHCPをVMに提供するために、各ハイパーバイザーは図のようにdnsmasqを実行します。
  • VMへのメタデータアクセスを可能にするために、各ハイパーバイザーは図のようにプロキシメタデータサービスを実行します。

本構成の問題

L3のみのフラットネットワークではネットワークをテナントごとにサポートできないため、この設計ではマルチテナントがサポートされませんでした。

このネットワーク設計の詳細については、私の同僚が書いたブログをご覧ください。https://engineering.linecorp.com/en/blog/openstack-summit-vancouver-2018-recap-2-2/

3. L3ベースのオーバーレイネットワーク:LINEで独自開発したプラグイン

本構成の動機

以前のLINEのプライベートクラウドは、LINE社内の開発者のみが使用していました。このため、単一テナントのように設計されていました。もちろん、Keystoneの観点からはマルチテナントサポートを使用していましたが、ネットワークの観点からはフラットでした。

しかし最近では、この設計により、私たちだけでは対応できない事例が増えてきました。たとえば、ある部門では開発を外注に依頼しています。そして、他社が開発したソフトウェアをLINEのフラットネットワークで実行すると、他社がLINEのクラウド内のどこにでもアクセスできてしまいます。これは危険な状況です。この状況を回避するために、ネットワークアーキテクチャを再考することになりました。

本構成のポイント

新しいNeutronエージェントを開発しました。このエージェントは、SRv6(セグメントルーティングIPv6)で強化されたL3ベースのオーバーレイネットワークをサポートします。SRv6を利用するとは、テナントを確実に分離できるため、利用することにしました。
BGPを使ってアンダーレイネットワークのIPv6到達性を確保し、ハイパーバイザー、VRF(仮想ルーティング機能)が通信できるようにしました。
各テナントは各ハイパーバイザー上に、専用ネットワークと専用VRF(仮想ルーティング機能)を保持しています。これにより、同じネットワーク内のVMに対するカプセル化ルールをハイパーバイザーが構成できます。これは、デブロイされているハイパーバイザーを問わずに実行されるため、同じテナントのVM間で通信が可能になります。
カプセル化ルールにより、ハイパーバイザーは、同じハイパーバイザーに常駐しているVMが送信したパケットを送信/転送する宛先と、その方法を把握できます。なお、他のテナントのVMとの通信を行うためのトラフィックは、ネットワークノードを通過します。

このネットワーク設計の詳細については、私の同僚が行った活動をご覧ください。https://www.janog.gr.jp/meeting/janog44/program/srv6

Verda内で行われた様々な最適化と改善内容について

運用の観点からの改善

Prometheus、Grafana、Elasticsearchなどのツールを使用した基本的な監視を行っています。また、既存の監視システムの他に、より高度な監視/運用システムも採用しています。ここでは、その一部を紹介します。

1. 実際の環境にあるものとAnsibleが定義したものとの違いを監視

クラウドの規模が拡大するにつれて、全サーバーを管理することは難しくなりました。特に、サーバー設定にホットフィックスを行った後に、Ansibleの設定ファイルの更新を忘れがちになりました。この場合、Ansibleの次の実行時に、ホットフィックスを行った内容がオーバーライドされ、元に戻ってしまいます。
この問題を解消するために、Ansibleのリファクタリングを行い、Ansibleが定期的(毎朝)にdry-runモードで実行され、変更内容に矛盾がないことを確認するようにしました。

2. ワークフローの監視

クラウドの範囲が広がって相互作用するサービスが増えると、このVerdaのエコシステム全体の中で特定の障害を追跡してデバッグすることが非常に難しくなりました。
そこで、障害の根本原因を見つけるために、ユーザーの操作をテストケースとして特定の下位操作へと分類し、ユーザーに問題が発生していないことを定期的に確認するようにしました。

3. バックオフィス向けWebアプリケーション

LINEのサービス規模が大きくなるにつれて、リソースや作成者の検索、ハイパーバイザーの無効化などの毎日の業務の負担が増えています。
このため、毎日の業務をWebアプリケーションとして自動化して誰でも実行できるようにするVerda Back Office(VBO)ツールを作成しました。

開発者の観点からの改善

運用スクリプト

LINEでは多数の運用スクリプトを管理しています。クラウドの規模が大きくなるにつれて、各種スクリプトの管理に予期せぬ問題が生じることがあります。
このため、KnativeをベースとするVerda FaaS(Function as a Service)を活用しました。すでに、すべての運用スクリプトをFaaSに移行済みで、運用スクリプトを機能として管理できるようになりました。

OpenStackのカスタマイズの管理

以前は、OpenStackコンポーネントをカスタマイズするたびに、そのコンポーネントのレポジトリをフォークし、カスタマイズのコミットをその上部に追加していました。
しかしクラウドが大きくなり、必要なカスタマイズが増えるにつれて、これが負担になってきました。また、以前行ったカスタマイズのバグを見つけた場合に、すべてのカスタマイズを記録することや、バグの修正をコミットとして上部に追加することが非常に難しくなりました。
そこで、レポジトリをフォークするのではなく、Gitのタグとコミットを使うことにしました。OpenStackコンポーネントの特定のタグを複製し、独自のカスタマイズパッチをその上部に適用するようにしました。コミットではなくパッチを管理するほうがはるかに簡単でした。

Verdaの今後の活動に関する詳細

規模の拡大に対する運用の向上

OpenStackのコンテナ化

OpenStackサービスのコンテナ化と、それを管理するためのKubernetesの導入を進めています。

RPC統計/RPCメッセージのトレース

OpenStackのパフォーマンスを向上させるために、RabbitMQメッセージをトレースしています。LINEでは、各種のRPC指標を明確に把握することが、パフォーマンスを向上させるために有効であることを発見しました。

Fakeエージェントに基づくベンチマークシミュレーター

Fake NeutronエージェントとNovaドライバを活用することで、クラウドの規模のベンチマーク評価をすることを目指しています。

SideCarコンテナの使用

プライベートクラウドを標準化するために、SideCarコンテナの概念を活用する予定です。

追加のお知らせ

私の同僚2人がCloudNative/OpenStack Days Tokyo 2019イベントでプレゼンテーションを行いました。是非チェックしてください。

LINEのDesignateに関するプレゼンテーション

LINEのKubernetes CNIに関するプレゼンテーション

終わりに

LINEがCloudNative/OpenStack Days Tokyoイベントで独自のパネルを設置するのは今回が初めてでした。LINEは、プライベートクラウドを引き続き改善し、このようなパネルをさらに多くのイベントやカンファレンスで展示するよう努めてまいります。
Verdaのエコシステムとネットワーク設計全体を説明する2つの記事をお読みいただき、ありがとうございました。のVerdaの概要をご理解いただけたら幸いです。

Related Post