SpringOne 2017 - 2日目 - カンファレンス、Spring、Reactor、WebFluxなどについて

サンフランシスコでのSpringOne Platform Conferenceに来ており、PivotalのPieter Humphrey氏とSimon Basle氏と話している。

InfoQ「ご一緒してくれてありがとう。何をやっているか少し話してもらえますか？」

Pieter氏「Springチームの製品マーケティングをしています。基本的にSpringエンジニアためのマーケティング人ですね。YouTubeチャンネルのコンテンツをまとめたりといったことをしています。」

Simon氏「私はソフトウェアエンジニアで、Reactorプロジェクトに取り組んでいます。」

InfoQ「このカンファレンスはとてもすばらしいです。よいコンテンツがたくさんありますし、訴えかけてくるものが多く、劇的に成長していますね。どうやってプレゼンタを見つけ、コンテンツを企画しているのですか？そして聴衆となりそうな人たちにどのように情報を知らせているのですか？」

Pieter氏「私たちのチャレンジはベンダのトピックとオープンソースの内容を結びつけることでした。そしてアプリケーションの開発トピックとともにインフラストラクチャの開発トピックを多く持ち込むことでした。歴史的に見て今まで同じカンファレンスでこれらすべてを見たことはありませんでした。そのため私たちが始めたとき、多くの方々にとって少し奇妙に思えたでしょう。開発カンファレンスまたはインフラストラクチャカンファレンス、どちらかであるということに人々は慣れていますが、一緒にしようとしてみると興味が異なる多くの方々が来て、彼らがうまく移動しないことも時々ありますが、コンテンツに対しとても二極化した反応を示す人々が来てくれます。そうした人たちは"私はこのことに関心はありません"、または"なぜこのことについてもっとないのか"と言うのです。全員を満足させるのは難しいです。ですがトレンドというのは私たちに役立つからこそ始まるものと思います。そこでは人々はインフラストラクチャとはコードであると気づいています。つまり時には彼らはそこに注意を払う必要があるのです。なのでアプリケーション開発インフラストラクチャやアジャイル、ケーススタディといった10のトラックを一緒にするのは難しくなくなってきています。すべてを1つのカンファレンスで一緒にしてしまうのです。最大のチャレンジは聴衆を引きつけ続けることにトライすることです。」

InfoQ「さて、よりDevOpsな世界になってきています。私が注目しているのは、DevOps専門のトラックがあったことです。これはCloudFoundryに新しいDevOpsでのCI/CD機能が入ったからだと思っているのですが？」

Pieter氏「そうです。でもCloudFoundryだけではなく、Kubernetesもとてもコンテナ管理中心のものです。CI/CDはとても適切なトピックで、実際私たちがこれらのプラットフォームについて話し始めたとき、人々がよいCI/CDのプラクティスを持っているだろうと少しは思いませんでしたか。私たちのプロダクトはある意味よいCI/CDプラクティスを持っていることに依存すると思います。これは大きなチャレンジです。」

InfoQ - CloudFoundryがDevOpsのパイプラインに役立つのか説明してもらえますか？

Pieter氏「Concourseで多少早く成功を得ることができました。Jenkinsサーバがステートフルで、設定をバージョン管理できなかったからです。開発者がConcourseについて私たちに話すことの中で、これはすばらしいことの1つです。パイプラインを持って行ってチェックインし、サーバそのものはステートレスなのでconcourseのワーカノードをどの時点であっても定義から再生成できます。かなり人気があることです。パイプラインをコードとして、インフラストラクチャをコードとして、今やすべてのものがコードです。」

InfoQ「しかしキーノートでは多くのDevOpsパイプラインをPivotal CloudFoundryの傘というべきものが処理する方法というものについて、共通のテーマを聞きました。こうしたことに対してPCFがどんな役割を果たすのか説明してもらえますか？」

Pieter氏「マーケットで起きていることで私たちが見たことは、Kubernetesの牽引力が相当なものであるということです。私たちにはKubernetesより先行した、CloudFoundry内部に組み込まれているコンテナ管理システムがあります。実際何年もです。しかしマーケットの牽引力を大いに得ているこのようなものが現れたとき、無視はしづらいものです。そして多くの面で、今私たちがPivotal Application Service（PAS）と呼ぶものが、アプリケーションに対する優れた抽象化となっていたと思います。PKS(私たちが取り組んでいるKubernetesサービス)は実際コンテナに対する優れた抽象化となってきています。ここではほんの少しだけ制御が必要です。なのでバランスを取ることとなります。この背面板に、ほぼプラットフォームとしてのBoshがあります。異なるワークロードに対して2、3の異なるスイムレーンを置いています。開発者としてcf pushのようなよい自動化を単に求めているだけでステートレスなアプリケーションがあるなら、そこではひょっとするとサービス層と連携しているかもしれないですが、そうならやった！、PASはとてもよいでしょう。でも一度データベースを追加し始めたり、もしくはElastic Searchを実行したいと考えたり、違うレベルでTCPのトラフィックを制御する必要が出てきたり、独自ポートを定義したりすると、そう、Kubernetesはそうしたことによく合います。それから関数を実行したいとなり、次世代のワークロードが何であれ、私たちはBosh上にこれらすべてに対して異なるスイムレーンの作成を試みます。これは進化です。DiegoとElastic Runtimeを全ユースケースでフィットさせようとするのではなく、あるユースケースにはあるアプローチがよく合うのだと気付きましたし、ほかの新しいユースケースにはそれに対処する違う方法をいくつか思いつかなければならないでしょう。」

InfoQ「Reactor APIを見るといつも、素早く変化してより多くの領域をカバーし、より堅牢で成熟してきているように思えます。その構築に何が入り、新しい機能はどのように考え出すのか、それが有益かどうかどのように調査するのか、もし有益でなければどのように却下するのか、そしてどのようにそれらをコーディングするのですか？」

Simon氏(笑って)それをコーディングするのがもっとも難しい部分ですね！ユーザ数がより多くなるにつれて、人々はいつも新しいユースケースを私たちに持ってきます。"そんなオペレータがあればすばらしいものになりますよ。"といった感じで。コミュニティのフィードバックは歓迎です。ですが実際にはじめの一歩としてやることはこのニーズにフィットする既存のオペレータがあるかどうか確認することです。これがライブラリの本当の力で、こうした根本的な機能を持っているということです。これらを組み合わせて複雑な、非同期パイプラインを作れます。しかし時には誰かが"これはデバッグしづらい、できれば新しいオペレータの観点でいくつか解決策を提案してほしい"と言いますし、こうした提案や要望には意味があります。もちろんつねにライブラリへのバグ修正や改善、最適化があります。

またPivotalの従業員ではないですが、私たちにフィードバックをくれるコミッタたちがいます。David Karnok氏のように。彼はRxJavaを管理していますが、同時にReactorにも関わっています。彼は当初とても深く関わっていました。実際初期に使っていた元々のコラボレーションプロジェクトに関わっていました。これはリアクティブライブラリの次世代コンポーネントをすべて設計するためのものでした。そのため多くの作業をここにつぎ込みました。彼は今も非常にアクティブでチャンピオンの1人です。プルリクエストに彼の改善や技法についてのコメントが残っています。

しかしPivotalでよかったことはRxJavaにあるものすべてを入れなかったことです。そのためその歴史的な選択や設計上の選択のいくつかから逃れることができました。しかし両方のライブラリにはともに価値があり、Davidが今もReactorにコントリビュートしてくれていることは間違いなくよい兆候です。」

InfoQ「なぜ2つのリアクティブプロジェクトが必要なのですか？Springを使っているJava開発者は、なぜRxJava使うのでしょうか？」

Simon氏「2つは同じではありません。RxJavaは違う利用者を対象にしています。事実としてRxJavaは今もJava 6をサポートしていますし、これはAndroid開発者が熱烈に採用する主な理由の1つです。一方Androidは実際にはReactorのターゲットではありません。私たちはDavidとともに同じ場所におり、もしフロントエンドのAndroid開発をしているなら必ずRxJavaを使いますが、もしバックエンドのSpring開発をしているならReactorは完全にフィットします。しかし事実として両者はリアクティブストリーム仕様に結びついており、選択は自由です。Spring自身の内部では、配管はすべてReactorでなされていますが、もしRxJavaルートを選びFlowableを使いたいとしても何の問題もありません。」

InfoQ「あのFluxオペレータが必要だと私自身たびたび気づきます。Javaの全体的な美しさはその拡張性にありますので、関数が必要になればそれを書けます。Reactorを使って新しいFluxを生み出すカスタムコンポーネントを作成する、似たような方法はありますか？」

Simon氏「もう一度確認ですが、私たちの目標は必要なものを組み立てられるようオペレータのコアを十分に提供することです。しかしそこにないのであれば、組み立てるのは難しいでしょう。Reactorのソースコードを見るのであれば、未知の領域にいるということです。私たちが使っているパターンはかなり進んだもので、これがReactorとRxJavaからの全体的な価値の提案です。自分自身でこのオペレータを書く必要はないということです。新しいpublisherを実装する前に実際には多くのことを考えなければならないからです。私たちはリアクティブストリームの上にAPIを提供しています。そしてみなさんのためにオペレータを構築しています。しかしオペレータの組み合わせがなければ、つまり物事がより困難であるときは、Davidが作ったRxJava2用のWikiページがあります。ここで彼はそのパターンを説明していますが、これは難しく最終手段であるべきでしょう。必要なものに対する既存のオペレータが見つからなければ、問題を違う方法で考えるべきであるということなのかもしれません。おそらくオペレータの組み合わせ、もしくは第三のオプションとして命令的なプロセッサでしょう。しかし本当に身動きがとれないなら、新しいオペレータが必要なのかもしれません。私たちのイシュートラッカーにそれを追加すべきですね。

たとえば今日のプレゼンテーションで、最初のストリームが終了しても終了しないzipオペレータについて誰かが質問しました。ある種のleft-outerなzipです。これをする明確な方法はありません。なのでおそらく新しいオペレータの候補となるでしょう。」

InfoQ「必要な新しいオペレータを生み出すために古いものを組み合わせられるとき、あなたには最終形がわかっている感じがします。」

Simon氏「そうです、正しいオペレータと正しいアプローチを探すだけの問題ですが、命令プログラミングからの癖が正しい解決策を探る途中で出てくるかもしれないので注意してください。」

InfoQ「キーノートでSpring Web MVCとSpring WebFluxの相互運用性を強調しているように見えました。急な学習曲線の橋渡しをするすばらしい方法だと思いました。少しずつ物事を変えていくことができます。Web MVCのコントローラを書けて、そのあと戻り値の型をFluxに変えるだけでWebFluxのコントローラに変えられます。これは技術的な決定ですか、それともマーケティングの決定でしょうか？」

Simon氏「リアクティブプログラミングモデルに慣れていない人々にとってのよい開発者体験というものを提供しようとしていました。実際これは進化です。Fluxを返すMVCコントローラがあれば、フレームワークはそれをどう扱えばよいかわかっています。たとえ今もWeb MVCを使っていて、webクライアントを使っている場所があったとしても、たとえばFluxを返せば、Web MVCはそのFluxをサブスクライブできて、正しくやってくれるでしょう。開発者体験を簡単にするサービスでこうしたことはなされています。できるだけ少しずつそれをやるようにしたいのです。小さく始めて、Web MVCから進め、エンドポイントの1つの戻り値の型をListからFluxに変え、webクライアントとやり取りさせ始めます。それが役立っているなら、APIと連携させ始めます。それを超えて成長させる必要があるなら、WebFluxスタックに切り替えられますし、まったく新しい世界があなたを待っています。」

Pieter氏「そうです。なのでこれはマーケティングやエンジニアリングというより現実的な決定以外の何物でもありません。今ユーザがいる場所でユーザを迎えられるよう私たちにできるベストを尽くそうとしています。」

InfoQ「すばらしい決断だと思います。リアクティブを使う際のもっとも困難な部分の1つは、学習のこぶを乗り越えることだと思います。これはまさに新しい言語です。なのでこのこぶを滑らかにするためにしたあらゆることというのは大いに評価されると思います。ある日にオブジェクトを扱っていて次にストリームを扱う、ゆえにこれは大きな認知の飛躍です。」

Pieter氏「そうです。また一方ですべてのものがリアクティブでなければならないと言わないように注意しています。いくつかの団体でこの罠に陥っている傾向があります。どちらかをする選択肢があり、すべてをある方法か、もしくは別のものかというように世界を見るべきではありません。」

InfoQ「気づいたのですが、カンファレンスではプロセスについての話を取り上げ、アジャイルに関する話があり、Vaughn Vernon氏がドメイン駆動設計について何かをしており、そしてDevOps専門のトラックが1つあります。」

Pieter氏「アーキテクチャの方法論の話をより多くしようとしています。私たちはPivotal Labsで、なのでアジャイルやテスト駆動開発、CI/CD、この種の概念について多く話します。プログラムでこの種のコンテンツや設計やアーキテクチャに関する話を多くしたいです。焦点は新しいツールであったことは何度もありましたし、開発者はより多く見たいと望んでいたことも何度もありましたから、私たちはこういったことに鋭い視点を保ち続けたいと思っています。」

InfoQ「参加者はどんな層でしょうか？」

Pieter氏「大部分が米国からです。60%が開発者、40%がその他、OpsやITマネジメント、エグゼクティブなどです。私たちはそういったグループにもコンテンツを用意しています。たとえばケーススタディや技術的な物語といったものです。」

InfoQ氏「SpringOne Platform Conferenceの未来はどんなものでしょう、2018年はどこで開催するか計画はありますか？」

Pieter氏「来年はワシントンDCで9月24日から27日、開催する予定です。東海岸、西海岸、東海岸中央部と順番にやりたいです。会場が抑えられるかで時期はたいてい変わりますが、年の最終四半期とするよう努力します。今年は3000人に完売しましたし、スポンサーもすべて埋まりました。モスコーンセンターにいるのですよ。文字通り去年の倍のサイズで、本当に伸びていますし、これはすごいことです。今後さらに背後にある管理は大きくなり、今後さらに背後にあるコミュニティは大きくなるように思えます。インフラストラクチャ-アズ-コードの動きが大きくなるのを見ながら、アプリケーション開発のことのために来たわけではない聞き手の部分も見ていくことになるでしょう。彼らはインフラストラクチャ開発に対して来ており、そういう人はより多くなるでしょう。」

InfoQ「SpringはJava自身と同じくらい、私のJava開発では重要なものです。こんなに積極的にSpringを使わずに1日を過ごすなんて想像できません。ほとんどのJava開発者もそう感じています。Pivotalが開発者の世界に対して提供していること、Springの管理をするというのはすごいサービスです。とてつもない仕事なのは明らかです。しかし、Pivotalにはどんな利益があるのですか？」

Pieter氏「そうですね、私たちもご飯を食べていく必要があります。人々は私たちを見て、このことを表に出して私たちが狂っていると言うかもしれません。しかし、私たちはアジャイルにやる方法やTDDをする方法、そしてそのプラットフォームに向けて開発する方法を教えることがとても多いのです。私たちの営利的な動きとして主なものはCloudFoundryやBoshプラットフォームを期待している人たちからのものです。アプリケーション開発から出てしまうと、すべてビルドし、すべて実行するようになります。ここが私たちが営利的な動きをしている場所です。なのでこれが戦略であり、私たちのプログラミングパラダイムに留まっていたいという開発者に十分な価値を提供できます。私たちのプラットフォーム上でこうしたアプリケーションを実行するのが本当に簡単になります。ガレージにいる2人にとっては私たちが提供できるものはすべて必要ないでしょうが、より大きな企業にとってはここにいくらか本物の価値があるのです。」