VISA International社が見出した、Dockerのオーバーレイネットワークの価値

こんにちは、クリエーションライン 株式会社の鈴木いっぺいです。
普段はロスアンゼレスに在住し、米国各地のオープンソース系のITベンダーとの付き合いを通して、日本とのパイプ作りに専念する毎日です。

今回のブログは、Docker MTAの導入事例を、ご紹介したいと思います。
DockerCon 2017やその後に数々のイベント通して、VISA International、MetLife、Northern Trustが同社でのDocker MTAの導入事例を発表しています。いずれも金融系の企業であることが特徴的ですが、一見ITに関しては手堅い印象の強い業界でなぜDockerの導入にそんなに積極的なのかを見ていきたいと思っています。

今回は、VISA International社の事例紹介を、スライドを通して解説したいと思います。登壇のビデオはこのリンクで公開されています。

VISAでのDocker導入事例

まずはDocker社のソリューションアーキテクトである、Mark Church氏の登壇。
Dockerが取り組んでいるネットワークに関わる課題について、VISA社の事例を通して紹介する、という内容です。

ネットワークの課題は分散している、ということで、それに伴う統合作業は時間がかかることが課題だ、と指摘しています。
一例として、VLANのプロビジョニングは労力がかかることを、図を通して強調しています。
見ての通り、ネットワーク管理者は、サブネット、IP管理、クラスター間での管理、などネットワーク固有の課題に取り組むことが重要なタスクになっています。

Dockerの登場でネットワークの管理がむしろ複雑になった、という意見も多いようです。

• コンテナがいっぱい増える、ということは、 管理対象となるIPアドレスやMACアドレスも増える、ということ
• コンテナのライフサイクル（数分、数秒）が短い
• マイクロサービスのようなアーキテクチャだと、コンテナ間の通信の量が急増、性能の要件も高い

ここでポイントになっているのは、従来のアーキテクチャ向けのネットワーク管理ツールではもはや通用しない、ということです。

Dockerのコンテナネットワーキングモデル

Docker V1.7の時はその対応として、Container Networking Modelを提唱していました。
これは、ネットワークを管理するネットワークドライバと、コンテナのスケジューリングを行うDocker側との間の「契約」関係のコンセプトです。
このコンセプトには、2つの重要なポイントがあります。

1. ユーザーアプリケーションをまず考える、というコンセプト
   アプリがサブネットやファイアウォール等のネットワーク固有の要件を意識せずにポータビリティ（クラウド／オンプレミス／ベアメタル／VMWare）を実現できること
2. プラグインのAPIのデザインを重要視
   異なるプラットホームの固有なネットワーク条件を統合できるように、プラグインアーキテクチャでその違いで吸収する方法

他にも3つ、重要な要件があります。

• スケーラブルでセキュアであることが重要
  ・アルゴリズムを駆使して、異なるネットワーク間のConvergenceを提供する必要があります。
  ・また、標準的にセキュリティーを保証することも重要です。
• OSに関係なく、ポータブルで統一された管理が必要
  ・ネットワークは環境に依存せず、ポータブルである必要性（Windows, Linux, Cloud, On-premise）があります。
• 使いやすい、ということが重要
  ・ネットワーク上のControl Plane, Data Planeに渡って、Certificationを統一的に管理します。

Dockerのネットワーク管理において、全てのアプリケーションとネットワークに関する情報を一つのファイルで管理することができます。

• 異なるTierを使うアプリが必要とする、異なるネットワークポリシーの管理
• オーバーレイ暗号化など、ネットワーク上で使う様々な機能やドライバーの管理
• アプリによって異なる、ingress/egressポリシーの管理

統合的に管理することによって、複数コンテナ、複数Tier、複数ノードのアプリを、自由に起動／停止することが可能になります。
その裏でDockerは、全てのコンポーネントでのIPテーブル、ロードバランス、等の管理を自動的に行います。

VISAでのDocker導入ストーリー

次は、VISA社のChief Systems Architectである、Sasi Kannappan氏が登壇し、VISAがプロダクション環境において、これらのDockerのネットワーク関連の機能をどのように活用しているのかを解説します。

VISAでは、2015年にDockerのスタディをスタートしてから、一年後の2016年にはコンテナ化されたアプリケーションをプロダクション開始しています。

最初に着手したアプリケーションは、

• グローバルなeコマースベンダー向けの決済トランザクション機能を提供するアプリ
• プロダクション開始からすでに6ヶ月が経過
• スタート時は100程度のコンテナで運用開始、現時点では800〜1000のコンテナをサポート
• 米国内の2箇所のデータセンタで運用、複数のクラスターをこの2つのリージョンで運用

金融業界では今新しいIT技術の導入は非常に活動的であり、上記のように一年以上かけてDockerを実導入するプロセスは比較的長くかかっている方。Dockerを採用したのが比較的ミッションクリティカルなアプリだったことがその理由の一つ。
VISAのIT運用ポリシーは非常に厳しい基準によって守られており、既存のコアシステムは20年間、一度もダウンすることなく常に稼働状態を維持し続けている。Dockerの技術の導入に関しても、この厳しい基準に準拠することが条件であり、それを達成するための時間をかけています。

VISAが特に着目した4つの点について整理しています。

1. セキュリティー
   VISAは非常に厳しいセキュリティー要件でITを運用しています。全てのソフトウエアコンポーネントに対して細かいセキュリティーの要件があり、Dockerは当時、そのセキュリティーの要件を一部満足していませんでした。
2. インフラ
   パブリッククラウドは使わず、全てインフラはOn-Premiseで運用。Dockerを導入するメリットは、このOn-Premiseの環境上での運用をする上での価値を明確にすることが重要な要件でした。例えば、仮想化環境でDockerを運用することによるデメリット等が指摘され、インフラチーム側の十分な理解、最も効果的な導入方法については議論がかなり行われました。
3. 開発ツール（CI/CD系）
   ソフトウエアの開発ライフサイクル（SDLC）のそれぞれのステップにおいて、多数のDockerエコシステム系のCI/CDツールが存在し、それらの中で最適なものを選択するプロセスにも時間をかけました。
4. 運用ツール
   全体を管理するための運用ツールも同様に、どのような技術を採用すべきか、やはり評価選択に時間をかけました。

Dockerを導入する上で目指していたゴールは次の通りです。過去数年の間に、ネットワークトラフィックが倍増している状況が続いており、ITインフラのアーキテクチャの刷新が大きな課題になっていました。その対策として次のようなゴールを設定していました。

• マイクロサービスアーキテクチャへの移行
• 動的なスケーラビリティの確保
  ・クレジットカード業界はトラフィックの上下のフレが極端に大きい
• 運用タスクのシンプル化
  ・ハッカーの攻撃の高度化：パッチの付与のスピードが重要
  ・現状でも自動化はかなり実施しているがまだまだ足りない
• ロードバランサーへの依存度の削減：デバイス、プロキシ等
  ・図に示すように、LBに依存するのではなく、アプリ同士が負荷に対応して効果的に通信し合う環境が理想的

Dockerコンテナネットワーク第一世代

Dockerの初期的な導入は、まず図に示すように5つのポイントについてソリューションを導入する検討を行いました。

• スケジューリング
  ・UCP 1.0を使ってコンテナの運用管理を実施
• サービスレジストレーション
  ・GliderlabsのRegistratorを採用してサービスレジストレーションを行った。
• サービスディスカバリー
  ・Consulを採用しそのサービスディスカバリーを実施する方法を採用
• ロードバランシング
  ・アプリ同士のコミュニケーションにはConsulテンプレートとかHAプロキシは採用せず、ConsulのDNSインタフェースを使いロードバランスIPを取得する方法をとった。
• コネクティビティ
  ・オーバーレイネットワークではなく、Docker Bridge Driverを採用。Docker v1.1当時は、後者の方が品質は良かったと判断

Dockerを導入した当初のアーキテクチャが図に示されています。

• 全てのホストにConsul AgentとRegistratorが搭載されていて、サービスのディスカバリーがホスト毎で行われています。
• 独自のLifecycle Managementのコンポーネントを開発し、サービスのライフサイクル管理を行う機能を提供しています。
• 新規のサービスが生成されると、アプリのコンテナが立ち上げられ、RegistratorがDocker eventを検知してConsul Agentに登録した後、Consul Serverは各々のConsul Agentから情報を収集します。

アプリ同士が会話したいときは、Consulの提供するDNSサーバのAPIを経由してリソースが空いているアプリを探します。（図においては、Application 1が異なるホストで稼働しているApplication 2とつながるプロセスでこのAPIを使います）

この最初のシステム構成で起きた問題を整理します

• 複数のコンポーネントを管理する必要が発生（各々のホストにあるConsul Agent, Registratorを全て管理する必要がある）
• システム障害が起きた時に、各々のホストで稼働しているConsulのコンポーネントをすぐに復帰させる必要があります。そのため、各々のホストのRegistratorとConsul Agentの健康状態を把握するコードを個別に開発しました。
• Consulには一時的な障害に対応するためのキャッシングメカニズムも存在するが、総合的にこれらの管理を行うためのシステムは複雑なものになり、トラブルシュートの工数増大、エンハンスの難しさを増大させています。

Dockerコンテナネットワーク第二世代

Docker側が次世代のネットワーク管理システムを解説しています。
第一世代のConsulをベースとしたサービス登録とディスカバリーの管理手法は昔から行われているものですが、昨今のマイクロサービス系アプリではこの機能は、分散されているアプリを運用するために必須の機能になっているため、Dockerでは、この機能をコンテナ運用向けにDocker Engineの基本機能として開発し、Docker Engineのポータビリティに組み込むための開発を行いました。

まずは、全てのDocker EngineにDNSサーバを内蔵し、常に稼働している状態にしました。また、ホスト上のコンテナにもそれぞれDNSリスナーを搭載し、DNSサーバにリクエストを送る仕組みになっています。

• このような仕組みをDocker Engineに持たせることにより、各々のコンテナが生成されると同時にDNSアドレスが設定され、外部のアプリに対してIPアドレスが見えるようになります。これはホスト内部のコンテナ同士のみならず、外部のDNSサーバに対しても開示されます。
• また、Swarmを通して複数のホスト上で複数のコンテナを運用する際にも、Docker Network Control Planeが自動的に生成され、アプリ同士のサービスディスカバリーが保証されます。
• 全てのコンテナはDNSサービスエントリと対応するIPアドレスを与えられ、さらに全てのコンテナには仮想IPが与えられ、Docker Engineがその負荷分散を行います。
• さらに、Docker Engineはそれぞれのコンテナの稼働状況を管理するヘルスチェック機能も提供し、もし任意のサービスがダウンした場合、その情報がロードバランサーに報告され、負荷分散の対象から外れます。

このエンハンスを通して実装した第2世代のコンテナネットワークのイメージを示します。

• スケジューリング
  UCP 2.0を採用
• サービスレジストレーション
  Docker Engineに内蔵されるサービスレジストレーション機能を採用
• サービスディスカバリー
  同様にDocker Engineを採用
• ロードバランシング
  Swarmの提供する仮想IPアドレス、負荷分散、ヘルスチェック機能を採用
• コネクティビティ
  Dockerの提供するオーバーレイネットワークインフラに移行

新たなアーキテクチャにおいては、従来使用していたConsul AgentとRegistratorを使わず、管理する工数を削減することに成功。また、アプリケーションは生成時に自動的に仮想IPアドレスを与えられるので、これを元にサービスディスカバリーを行うことが容易になりました。

負荷分散の管理においても、システム構成が非常にシンプルになりました。
この絵においては、Application 1がApplication 2と会話しようとした時に、Docker Engineの提供する仮想IP（VIP）を参照して、最もavailableなノード上のApplication 2とつながるべく、Docker Engineのロードバランサーが機能してくれる仕組みになります。

ライフサイクル管理においても、従来はConsulのConsul Watchという機能を使って各々のサービスの健康状態を監視していましたが、第2世代ではDocker Engine自体がアプリケーションの健康状態を把握し、サービスが一つ落ちた場合は、新規のサービスを立ち上げる工程を自動的に行うことを保証します。

図の場合は、Application 2の同時稼働インスタンス数を「2つ」と設定してあって、真ん中のWorker Nodeで障害が起きたApplication 2のインスタンスの代わりに新規のインスタンスを同じWorker Nodeで立ち上げる状態を示しています。

従来は、ホスト毎にスタティックなポートを設定しなければいけなかった状況も、Dockerのオーバーレイネットワークを採用することによって、自動化させることに成功しました。これはかなりの工数の削減に繋がっています。

まとめ

結果的に、次のようなメリットを得ることができました。

• コンポーネントの数が削減
  厳密にはホスト上の機能は同じだが、トラブルシュートする対象のコンポーネントが少なくなるため（Consulの分が減る）運用がかなり楽に
  より運用が可視化された
• サービスディスカバリー向けに独自開発したコードがなくなった
  メンテナンス労力の削減
• 新規の機能が追加
  Docker Engineの提供するVIPによるロードバランシング
  ヘルスチェック機能によるインスタンスの自動回復

まとめ：

• VISAでは、従来からネットワークに関して抱いていた課題については明確に理解していた、という背景があったからこそDockerの提供するオーバーレイネットワークを中心とした機能の価値を見いだすことができた、と言えます。
• 導入当初のDockerはそのネットワークに関する要求に十分に答えることができなかったのは事実ですが、やはり何が足りなかったのかが明確であったこととそれを補填する独自開発能力（Consulによるサービスディスカバリー）を持っていたからこそ、導入に踏み切った、と言えます。
• VISAの抱えていた課題は決して固有なものではなく、どのエンタープライズでも直面する問題であり、マイクロサービス化のみならず、社内IT資産のクラウド移行を行うだけのレベルでも発生する課題です。その際に、あまりカスタマイズされた実装をするのではなく、常にベストプラクティスが何なのかを見極めることが、長期的な視野で重要である、と言えます。
• ただし、コンテナ運用固有のネットワークの問題は存在し、それについてはまだ市場でのベストプラクティス手法が確立されていない状況ではあります。この辺の問題は、今後も様々な企業での導入ソリューションを参考にすることが重要だと感じます。

次回のブログでは、Metlife社のユースケースについて解説をします。

関連リンク

DockerCon 2017のキーポイント
DockerCon 2017で発表された、Northern Trust社のDocker MTA 導入事例
MetLife社のDocker MTA導入事例(前編)
MetLife社のDocker MTA導入事例(後編)
Dockerの製品ページ