OpenShiftとContrail Networkingのコラボレーション ～クラウドネイティブ時代に求められるアプリケーションインフラの特徴～　

目次 Table of Contents

1. はじめに
2. クラウドネイティブ時代に求められるアプリケーションインフラ
3. ハイパフォーマンスでスケーラブルなアプリケーションインフラの動作検証
4. まとめ

1.はじめに

みなさま、クラウドネイティブしていますか！？ NADPの兼田です。

今回は企業がDXを進めるためのサービスに求められる特性と、その特性の実現方法について実機検証を行える機会があったので、検証内容をお知らせします。

つまり、そんなに開発の話は盛り込めませんでした！

本検証に当たっては、当チームの武器であるRed Hat OpenShiftに加えて、柔軟なネットワークを提供するためのJuniper Networks社製 Contrail Networkingを組み合わせております。

また、Juniper Networks 安村様にも多大なご支援を頂いたため、この場をお借りして御礼申し上げます。

本記事では、”アプリケーションインフラ”が指す対象を、コンテナ技術が用いられたコンテナオーケストレーションプラットフォームと定義して話を進めます。

2.クラウドネイティブ時代に求められるアプリケーションインフラ

クラウド技術の台頭により、アプリケーションのアーキテクチャはどんどん柔軟な形に変化してきました。

モノリシックからマイクロサービスへ、という説明は皆様も至る所でご覧になられていると思います。

また、独立したマイクロなコンポーネントをつなぎ合わせるために、サービスメッシュと呼ばれる考え方も発展し、それぞれのPodをどのようにつなぎ合わせていくか、という視点でサービスの設計をする機会が増えてきました。

同時に、マルチクラウドでのサービス提供にはインフラ側の観点を設計に盛り込むことが必要です。

一例として、ネットワークの分野では通信のフロー制御・フロー監視・バランシングといったところに配慮が求められます。

この考え方は、”サービスメッシュ”とよく似た名前で、”サービスチェイニング”と名付けられています。

以前までのアプリケーションインフラは、サービスを構成するアプリケーションは物理/仮想サーバ上で動作し、ネットワーク側で細かく振り分けを実施するというのが一般的でした。

一方、モダンなアプリケーションインフラではアプリケーションを細分化し、大艦巨砲主義的なサーバサイジングを好みません。

なぜならば、モダンな開発プロセスではDevOpsをはじめとした「すぐ作ってすぐ動かす」姿勢が前提となっており、個々のコンポーネントを細かく分け、スピード感をもってサービスを作り上げることが求められているからです。

当然、アジャイルなデプロイが向いていない特性のアプリケーションも存在しますが、システムの全てを旧来のやり方で作っていては、時代に取り残されてしまうでしょう。

そのため、DXの実現には不連続なステップで飛び飛び実施するのではなく、既存のアプリケーション資産を連続的に少しずつモダナイズしていくことが重要です。

そして、改修頻度が多くない等、旧来のアーキテクチャが有効とされる部分についてはそのまま残しておく、という判断も必要です。

これらの選択/設計/実装/運用をマルチクラウド環境において実施するためには、アプリケーションそのものの見直しをインフラのレイヤから一気通貫で行う必要があり、この複雑さは多くの企業でアプリケーションのモダナイズに踏み出しづらい要因となっていることでしょう。

特にハイパースケーラーなシステムで、サービスの一部はマイクロサービスとして提供され、残りの部分はモノリシックに提供されているような状態を想定したとき、それらの繋ぎこみやセキュアな通信経路の確保に最適なアプリケーションインフラには、どのような機能が求められるのでしょうか。

1点目として、まずは通信フローの制御が簡単に提供できる必要があります。

サービスメッシュとサービスチェイニングの両方を同時に実現することで、フローはOSI参照モデル上のL4レイヤ上を複雑に行き来するようになります。

そのような通信フローを旧来の通り人手管理で実施していては、インフラ運用の煩雑さと俗人化からは脱却できず、アプリケーション領域とインフラ領域の分断が解決されないことになります。

2点目として、モダンなアーキテクチャと旧来のアーキテクチャの相互接続が簡単である必要があります。

現代のプラットフォームでは、サービスのエントリポイントにはIngressやRouteといったリソースを利用しますが、Serviceの内部が隠蔽されているということと、フラットで柔軟なネットワークであることとは、一部矛盾が発生します。

理想的なマイクロサービスアーキテクチャでは基盤側の要請を切り離して設計を進めることが出来ますが、過渡期のシステムにおいては一部のServiceに対しては透過的なネットワークを接続することで、インフラ側の要請を柔軟に受け入れることが求められます。

これは、Kubernetesのネットワーク要件(※1)に記載された内容を見るとわかりやすいのですが、素のKubernetesでは、インフラ側が期待するような、アンダーレイを直接繋ぎこめる設計にすることが難しいです。

(私はNADP事業にJoinする前はインフラの提案/設計を行っていたので、インフラ側の気持ちを思い出しながらこの記事を書いています。)

感覚としては、旧来の設計ではネットワークは ”面”で提供していたのに、モダンな設計では ”点”でしかネットワークを提供できず、システム全体に統一されたネットワークポリシーを適用するのが難しい、といったイメージでしょうか。

上記2点は、インフラ側全般に要請される機能のため、プラットフォームと統合されたソフトウェアデファインドなネットワークによって提供される機能でなければなりません。

(ネットワーク以外の領域では、Nutanix AHVをOpenShiftのベースに用いることで、様々な課題を解決可能です(※2)。)

幸いにも、当社はネットワーク分野においてはJuniper Networks社との強固なタッグが構築できており、Contrail Networking(以下、Contrail) との組み合わせで、通信フローの細やかな制御、クラスタ境界をまたぐ透過的なネットワークが利用できるようになるのか、検証を行うことが出来ました。

1. 通信フローの細やかな制御を行う サービスチェイニング
2. クラスタ境界をまたぐための データセンタゲートウェイ(DCGW)
   の2機能がどういったものか、検証結果を交えながらご説明いたします。

尚、検証バージョンにつきましては、最新版のCN2(※3)は間に合わず、旧バージョンでの実施となっていることをご了承ください。

3.ハイパフォーマンスでスケーラブルなアプリケーションインフラの動作検証

動作検証に当たっては、社内検証環境を使用し、OpenShiftと同時にContrailをデプロイする、という手段をとる必要があります。

Juniper Networks社から手順に関するドキュメントが公開(※4)されているため、基本的には手順に従って実行を行います。

弊社環境では各ノードをNutanix上に配置して検証を行いましたが、ハイパーバイザはESXiではうまく動作せず、AHVを利用する必要がありました。

3.1 サービスチェイニング

これまでに述べた通り、サービスの細分(マイクロサービス)化はアプリケーションモダナイズの大きなカギとなります。

しかし、モノリシックな実装では1ホスト内で完結していた通信フローが、Pod & ノード間を行き来するような形となるため、クラスタの外側から通信フローの制御を行う仕組みを作りこむ需要が生まれました。

OpenShiftではサービスメッシュを行うためのIstioが標準で利用可能ですが、ネットワーク観点での負荷分散やフローコントロールに関しては、ネットワークベンダが取り扱うソリューションを組み合わせることで様々な恩恵が得られるようになります。

Contrailでは、仮想化されたネットワーク機能をサービスに紐づけることで、サービスチェイニングを実現することが出来ます。

この機能は、外向けのサービスに対して、Podを通るたびにFWを通過させるなどといった形でセキュアなサービス提供を実現することができ、特にクラウドプロバイダにとってはとても便利な機能です。

以下が検証構成となります。cSRXはJuniper Networks社によって提供されるコンテナ化されたFWソリューションとなります。

この構成では、2台のCentOS Podが行う通信をcSRXに通し、フロー制御を行う、といった例の検証パターンとなります。

OpenShift/Kubernetesでは、名前空間毎にServiceというリソースを用いてネットワークを分離する仕組みが実装されています。

Contrailを組み合わせることで、OpenShift/Kubernetes コントロールプレーン上に存在する仮想ルータが名前空間毎の経路情報を持ち、ノード間で経路広報を行うようになります。

仮想ルータは一般的なルータ同様、ルーティングテーブルをインスタンス毎に分離して持っているため、名前空間の中でもさらにネットワーク分離を行う形で通信を可能にします。

この仕組みはCNI(Container Network Interface)という標準化された機能を利用しており、Podから見たServiceネットワークに対しては不可視な機能となります。

すなわちPod側はネットワークの構成を意識するPodから見たServiceネットワークに対しては不可視な機能となります。

一方でネットワークについては、分離されたルーティングテーブル毎に運用を行うことが出来るため、運用の煩雑さが少なくなります。

本ケースではFWによるフロー制御をお題とした検証を行いましたが、FWをLBに変更すれば、大規模なフローに対しての振り分けも自由にできるようになります。

マイクロサービス(=Pod)毎に、それぞれの特性に求められるネットワーク機能を提供することが可能になります。

Kubernetes/OpenShift単独であれば名前空間に対するIngress/Routeがアプリケーションへの唯一のエントリポイントでしたが、Contrailを使用することによって、NFVを名前空間内での通信に関与させることが出来るようになりました。

3.2 データセンタゲートウェイ

Contrailは先ほどご紹介したようにOpenShiftの名前空間内部に対して通信の管理を行うことが出来ます。

これはOpenShiftのCNIを利用して、クラスタネットワークのオーバレイ/アンダーレイ両方の通信に介在するからこそ提供できる機能となります。

この特徴を応用することで、オーバレイ/アンダーレイの境界を跨ぐ透過的なネットワークを実現することが可能です。

Juniper Networks安村様の言葉を借りると「コンテナに対してもVMのようにネットワークを提供できる」、魔法のような機能となります。

Kubernetesはサービス内のPodに対して、NATなしでの通信を要請します。

そのためにカプセル化やVxLANといった技術を用いてPod同士の通信を隠蔽せざるを得ないため、ノード外からの通信制御を難しいものにしています。

(OpenShiftも、標準で用いられるCNIのOpenShift SDNではOpen vSwitchを利用したVxLANによるカプセル化を行っています。(※5))

そのためクラスタ外からPodへのアクセスは、Ingress/Routeを使用したL4以上の通信が用いられています。

Contrailは、ノードに存在するvRouterと、外部のルータとの間で、BGP peerを張ることで、クラスタ外のホストに対してもクラスタ内の経路を広報/カプセル化を行い、オーバレイとしてMPLS over GREを用いて、疑似的にIPドメインの延伸を可能とします。

これがまさに「コンテナに対してもVMのようにネットワークを提供できる」ための、魔法の杖として動作します。

DCGW機能の検証ケースでは、Podが直接サービスを提供する外部ホストにアクセスするような構成をとりました。

これはNATなしのフラットなネットワークになっていることを確認するためのものです。

一例として、「コンテナ化に向いていないDBインスタンスをクラスタ外に出し、Podの出すDBへクエリを直抜けさせる」といったケースも同様の構成となります。

この機能は既存のネットワーク技術と組み合わせることも可能です。OpenShift単体では分界点を設けることが難しい、マルチテナントでのサービス提供を行うために、MPLSラベルやVxLANを利用してテナント毎にネットワークを分離することが可能となります。

VMを用いたシステムではもう珍しくない技術ですが、ContrailはコンテナにおいてもNATなしの通信を可能にします。

4.まとめ

今回は視野を少し広げて、クラウドネイティブな時代にアプリケーションインフラへ求められる要件を、金融業界以外も含めて洗い出し、技術的な検証を行ってみたという記事になります。

すでにCSPの企業様ではKubernetesをカスタマイズして意図するインフラをくみ上げる、ということは実現されつつありますが、エンタープライズでのインフラにおいても同程度に柔軟なインフラが求められていく時代です。

エンジニアとしては、どんな技術の組み合わせで本記事の内容が構築できるのか、把握するのは簡単ですが、これらの組み合わせを実証するためにサポート回答を頂きながら検証を進められたことに、喜びと感謝、そして驚きを感じております。

本文中ではあえて「魔法のよう」という文言を入れ込んでみましたが、そんな魔法が現実になる世界も、近いうちに来ると思っています。

多種多様なお客様と、その課題に対して「魔法のよう」に解決できた、という体験をしていただけるよう、引き続き技術的な深堀を進めてまいります。

———————————————————————————-