サービスメッシュ時代のAPIマネージメントのあり方を3Scaleに訊いた

Red Hat Summit 2018における中心的なプロダクトは明らかにOpenShiftだったが、同様に注目を集めたオープンソースソフトウェアとして、サービスメッシュのIstioなどが挙げられる。Istioが注目される理由のひとつは、コンテナでアプリケーションをパッケージしたとしてもモノリシックなままでは変化に対応できないからだ。アプリケーションを細分化して複数のコンテナをオーケストレーションするやり方をさらに進めると、「マイクロサービス」という発想になり、それをネットワーク化するサービスメッシュに行き着くということだろう。Linkerd、Conduit、Istioなど、多くのオープンソースソフトウェアがこの分野でしのぎを削っている。中国のTencentも、Tarsというマイクロサービスのためのプラットフォームをオープンソース化、HuaweiもServiceCombというソフトウェアをApache Software Foundationに寄贈してインキュベーションが始まっている。

3scaleのSteven Willmott氏

Red Hat Summit 2018にて、マイクロサービスと外部サービスの間をつなぐAPIゲートウェイなどとして利用されるAPIマネージメントのソフトウェア、3Scaleの責任者であるSteven Willmott氏にインタビューを行った。3Scaleは、Red Hatが2016年に買収したAPIマネージメントのソリューションである。Willmott氏には2017年1月にもインタビューを行っており、それ以来の再会となった。

久しぶりですね。APIマネージメントのビジネスの調子はどうでしょう？

ビジネスは好調です。プロダクトももうすぐ新しいバージョンがリリースされますし、これまでクローズドだったソースコードをRed Hatのスタイルに合わせて全てオープンソースにすることも、夏ぐらいに実現する予定です。

それはこれまでクローズドだったソースコードをオープンソースにするという意味ですね。

そうです。これでやっとRed Hatの中のファーストクラスシティズン（第一級市民）になれます（笑）。

IT業界ではコンテナからマイクロサービス、サービスメッシュに興味が向かっていますが、3Scaleの計画は？

マイクロサービスもサービスメッシュも非常に重要だと考えていますので、3Scaleのチームも他のRed Hatのエンジニアも、サービスメッシュのオープンソースプロジェクトであるIstioに大きな貢献を行っています。少しマイクロサービス自体を振り返って考えてみると、初期のマイクロサービス自体は大きなシステムをとにかく細かなプロセスで構成することに専念していたと言えます。それによって、プロセスのアイソレーション（隔離）がなされました。ところがそれだけを行った結果、小さなユニットにプロセスを分解することで、複雑な仕組みの部分がそのユニットの間の部分に発生してしまいました。そして、それを処理するライブラリーの複雑化を招き、APIゲートウェイ自体が大きなものになってしまいました。

この問題を避けるために、3ScaleはNGINXを利用しています。我々の顧客の中にはシステムの中に数百というNGINXをゲートウェイとして使っているケースがあります。このように大規模になれば、軽量のサーバーを利用するメリットが生まれます。またコンテナとしてアプリケーションが利用される場合は、Istioが使っているEnvoyを利用してサービスメッシュを構成するわけですが、その場合にはEnvoyに対してAPI proxyとして動作するように開発を行っています。現在のIstioはプラガブルな構造にはなっていませんが、将来的には様々なモジュールをプラグインとして利用できるようになると思いますので、3Scaleのソリューションもそれに向かって進んでいると言えます。

その場合、モノリシックなアプリケーションであるNGINXのゲートウェイ、コンテナによるIstioで構成されたアプリケーションは、Envoyをサポートする形式になるわけですね。

その予定で開発を行っています。

サービスメッシュの分野ではIstioが注目されていますが、他にもLinkerdやConduitなどがあります。3Scaleとしてはこれらもサポートする予定ですか？

そうできるのが理想ですが、実際にはIstioを最優先でサポートすることになるでしょうね。我々もそれほどリソースが大きいわけではありませんから。

リソースの話になったので、日本語化などについても教えてください

3Scaleの日本語化の前に、まずサポートエンジニアを用意するところから始めています。すでにレッドハットの日本法人に、サポートエンジニアがアサインされています。プロダクトそのもののエバンジェリストに関しては、グローバルでは専任者がいますが、日本やアジアにおいてはこれからというところですね。ただ、ニーズがあるのはわかっていますので、日本でもAPIマネージメントに関するMeetupやセミナーなどを計画しています。

OpenShiftとの連携が予定に入っていると思いますが、OpenShiftそのものに統合されるという計画はないのでしょうか？

OpenShiftとの連携は非常に重要だと思っていますが、別のプロダクトとしてそのまま発展していくと思います。理由としては、顧客は何もかもがセットになったプロダクトを好まないということが挙げられます。企業によって、コンテナオーケストレーションはOpenShiftで、APIマネージメントはまだ要らないというところもあるでしょうし、まずAPIマネージメントだけ使いたいという顧客もいると思います。そのためOpenShiftと3scaleは、別のプロダクトラインのまま進化していくと思います。その場合、コンテナレジストリーと連携することで、コンテナの中のAPIをどうやって自動的に検出するか、などについて開発を続けていく予定です。

新しいリリースについてもう少し教えてください。

オンプレミスのバージョンについて、マルチテナントの環境で使えるようになるというのは大きな意味があると思います。テレコムオペレータやインターネットサービスを行っている企業にとっては、価値のある機能拡張ですね。あと価格のモデルについても、コール数ではなくて実行するサーバーのコア数によって課金が変わるモデルを導入しました。これは変動するコール数ではなく、ある程度固定的にコストを計算したいというニーズによって生まれたものです。バージョン2.2もうすぐリリースされ、7月には全ての3scaleプロダクトがオープンソースソフトウェアとして公開されます。今年の大きなマイルストーンはその2つですね。

インタビュー後、日本でのAPIマネージメントの認知状況について反対に質問されるほど、日本市場については大きな期待を抱いていることが伺えたインタビューであった。