Michael Behrendt氏に聞く - IBMのイベント駆動プログラミングサービス Bluemix OpenWhiskに関するQ&A

IBMは，同社Bluemixプラットフォーム用のイベント駆動プログラミングサービスOpenWhiskを新たにリリースした。これによって同社は，サーバレスコンピューティングという新たなパラダイムをプレーする，数多くのベンダの一員に加わることになる。センサデータ通知など，外部イベントに対してユーザコードを実行するように設計されたこのサービスは，先月ラスベガスで開催された同社のInterConnect 2016カンファレンスで発表されていた。

Bluemixのアーキテクトのひとりで，今回のカンファレンスにも関与したMichael M Behrendt氏に，OpenWhiskとBluemixについての概要を聞いた。

InfoQ: 早速ですが，Bluemixプラットフォームのコンピューティングモデルについて，イベント駆動アプリケーションの面と，VMの面から説明して頂けますか？

Michael M Behrendt: Bluemixが提供するのは，幅を持ったコンピューティングモデルです。最も抽象化の低いレベルがVM，その次はコンテナとクラウドファンドリアプリ，そして最後が，最高の抽象化レベルとしてOpenWhiskによって実装されたイベント駆動のアプリケーションです。私個人の意見ですが，注意すべきなのは，‘よい’モデルや‘悪い’モデルというものはなく，それぞれのモデルが目的に適したスポットを持っている，という点です。VMからイベント駆動アプリに至るまで，ビルトインマネジメント(built-in management)がますます高度になって，開発者を退屈な作業から解放してくれるのはよいのですが，その一方で，コントロールの粒度が低くなり，プロセス実行をコントロールする上での柔軟性は失われて行きます。

次のレベルであるBluemixのコンテナサービスでは，基盤となっているOSを気にする必要なく，Dockerコンテナのプロビジョンが可能です。開発上で制限となるのは，コンテナホストのOSによる制約です。

Cloud Foundryアプリケーションは，その次に高い抽象化レベルに位置します。このレベルでは，開発者はアプリケーションのコードにのみ注目して，それをCloud Foundryにプッシュさえすれば，後のアプリケーションインスタンスのコンテナへのプロビジョニング，ロードバランシングレイヤの自動コンフィギュレーション，稼働状態管理といった作業はすべて，Cloud Foundryが処理してくれます。コンテナサービスと同じく，Cloud Foundyが使用するOSによる開発上の制約があります。また，アプリケーションの構造にも，特定の制約が存在します。

最後の抽象化レベルであるOpenWhiskでも，アプリケーションコードのみに注目すればよい点は同じですが，アプリケーションコードの構造に関する制約がさらに多くなります。OpenWhiskのメリットとしては，非常に詳細な実行モデルと本質的なスケーラビリティ，冗長性を独自に備えていること，などがあげられます。処理すべきイベントあるいはリクエストがない状態では，メモリ内で実行されるコードはまったくありません。イベントの数が増えるに従って，より多くのアクションが実行されるのです。このようなモデルにより，冗長性を確保するために複数のプロセスを実行する必要はなくなります。

InfoQ: BluemixはCloud Foundryをベースとしていますが，モデルは変更されています。これはベンダ中立性を損なうことになはりませんか？

Michael M Behrendt: そうではありません。先程述べたように，私たちが目標としているのは，目的に合った選択を行なう自由をユーザに提供することなのです。つまり，一方が他方に影響を与えない形で，OpenWhisk, Cloud Foundry, Dockerコンテナ, VMを使用できるということです。しかしながら，共通ID, 共通のルーティング層，共通のサービス利用といったように，いくつかの面ではモデル間に一貫性を提供しているのが実情です。

InfoQ: IBM Bluemix OpenWhiskについて，技術的に詳しく説明して頂くことは可能でしょうか？

Michael M Behrendt: OpenWhiskには，トリガ，ルール，アクションという，３つの重要な基本概念があります。トリガは，データベースの新レコード，githubへのコミット，モバイルが特定の地域(geofence)に入ったことなど，反応すべき状況の種類を表すものです。

アクションはOpenWhiskに登録する，コードのスニペット — 小さいものから大きなものまで — です。アクションはNode, Swift, あるいはJavaで記述するか，あるいは任意のバイナリを含むDockerコンテナで定義します。アクションが呼び出されると，対応するコードアーティファクトがコンテナに瞬時にデプロイされ，動作し，再び消去される仕組みです。実行されるアクションの数が多ければ，より多くのアクションのデプロイが行われるので，結果として本質的なスケーラビリティが得られます。OpenWhiskはそのようなアーティファクトの管理，インテリジェントなコンテナのキャッシング(デプロイ時間を最小化するために重要)といった処理を行ないます。アクションはhttp経由で直接起動することも，OpenWhiskを経由して，トリガの結果として，ルールによって関連付けられたアクションを起動することも可能です。トリガが起動すると，対応するアクションが直接呼び出されます。OpenWhiskの実装には，Scala, Kafka, Docker, その他にもさまざまなテクノロジやライブラリを使用しています。OpenWhisk自体のコアエンジンは，Scalaで実装されています。Kafkaはアクションを実行するコンテキスト内でOpenWhiskの内部メッセージとして，Dockerはアクションを分離された環境で実行するためのコンテナメカニズムとして，それぞれ使用しています。

InfoQ: OpenWhiskはオープンソースなのでしょうか？Java開発者がOpenWhiskを使用することは可能ですか？

Michael M Behrendt: はい，OpenWhiskは完全なオープンソースです。Apache 2ライセンスの下でgithubで公開されていますし，外部からのプルリクエストもすでに受け取っています(誰でも参加大歓迎です:-))。現時点ではNodeとSwiftをサポートしていますが，Javaサポートも開発中です(編集者記:Javaサポートはすでに提供中)し，将来的には他の言語もサポートする予定です。しかもOpenWhiskは，アクションとしてDockerコンテナの実行もサポートしていますから，開発者の自由度はさらに高くなります。実質的には，Dockerコンテナ内で動作するバイナリはすべて，アクションとしてサポートされることになります。

InfoQ: 想定しているユーザはどのようなものでしょう？スタートアップか，あるいは企業でしょうか？

Michael M Behrendt:　Bluemixは基本的に，既存のワークロードあるいは新しい画期的なワークロードの開発と実行，運用を望む，すべての人々を対象としています。これはスタートアップと企業の間で共通の要件だと思います。これらの場所での開発者の行動と開発状況，使用中あるいは使用を希望するテクノロジを見てください — すべてにおいて共通であることが分かります。

それ以外にも，企業特有のニーズがあると思っています。企業であれば，コンプライアンスやデータロケーション上の理由から，アプリケーションの稼働する場所に関する自由度が必要です。これに対応して当社では，別のデプロイメントモデルであるBluemix DedicatedとBluemix Localを用意しています。 さらに企業では，既存のアプリケーションやデータにアクセスしたいという要求のあることが一般的です。Bluemixに備えられた一連のインテグレーション機能は，この目的で用意されたものです。

InfoQ: DockerなどのコンテナとPaaS(Platform as a Service)について質問したいのですが，この２つは排他的なものでしょうか，あるいは相互補完するものなのでしょうか？

Michael M Behrendt: 最下位のレベルについて言えば，必要なものならば何でもパッケージングして実行可能なコンテナは，非常に汎用性のある方法だと言えます。既存のソフトウェアやシステム，プロトコルといったものであれば，クラスタ内のような内部的な利用でも，外部的な利用であっても，ほとんどの目的に対応するからです。個人的には，コア要素としてのコンテナ上に，ロードバランシングや稼働管理などの事前統合された機能を追加し，Twelve-Factorのような原則を念頭に置いた特定のアプリケーションアーキテクチャを備えたものがPaaSであると考えています。ですから，PaaSでコンテナそのものを使用することが可能であるように，事前統合された機能のメリットを最大限活用することも可能です。その場合は自分のコードだけに注目すればよい反面，詳細なコントロールの実行は諦めなくてはなりません。最終的にはビルトインマネジメントとコントロールとのトレードオフということになるのですが，個人的には，普遍的に正しい，あるいは完全な間違いだ，という解は存在せず，実行するワークロードによって異なるのではないかと思っています。

技術的な面で言えば，ソフトウェア産業全般として，‘生’のコンテナからPaaSにわたるイベント駆動コンピューティングが，ユーザにとって可能な限りシームレスであることが望まれると思います。今はまだ，さまざまな領域にあまりにも多くの技術サイロが残っている状態で，コミュニティとしての私たちを必要以上に非効率にしていると同時に，ユーザの選択や採用を難しくしています。

InfoQ: 最後に，IBM Interconnectについて少し説明してください。アーキテクトや開発者，あるいはDevOpsの観点から見て，最も大きな成果は何でしょう？Bluemixの今後の予定についてもお願いします。

Michael M Behrendt: 私としては，IBMが既存ワークロードのクラウドへの移行に加えて，新たなアプリケーション開発をサポートするイノベーションにも目を向けたことが最大の成果だと思っています。例えば，VMwareとのパートナシップとConnectの発表は既存のワークロードのサポートに関するものですが，OpenWhiskの発表やサーバサイドSwiftに関連してAppleと共同で進めている開発では，より新しいアプリケーションに重点を置いています。

今後暫くは私たちが長らく追求してきた技術的戦略に従って，Bluemixの開発を続けていくつもりです。私たちはこれからも，コンピューティングモデルとデータや分析，統合，認知，モバイル，などのサービスについて，最も広範かつ一貫性のある選択肢を提供することに力を注いでいきます。さらに私たちは，それらをオープンな方法で提供するとともに，パブリック，専用，ローカルという３つの統合デリバリモデルをユーザに提供します。

Michael M Behrendt氏のプレゼンテーションや他のプレゼンテーションは，InterconnectのWebサイトからダウンロードできる。