Lightbendのエンタープライズアーキテクト、Kiki Carter氏がETEでInfoQに語った

Kiki Carter氏は、Lightbend社のエンタープライズアーキテクトであるが、2017年のEmerging Technologies for the Enterprise(ETE)カンファレンスで“Somm” Lagom: ワインのように熟成するシステムを構築するというプレゼンテーションをした。

“Somm”は同名の2012年の映画への参照である。これは4人のワインソムリエが“マスターソムリエ”試験合格に挑戦する話だ。Carter氏はソフトウェアアプリケーションをどのようによいワインのように熟成させるべきかという議論をするためにこの比喩を使った。エンタープライズ開発者が迅速なシステム構築の新時代に直面している、その挑戦について考察した。次のようなことを含む。

• 多すぎる選択肢と分析麻痺
• 一貫性のあるアーキテクチャ完全性の難しさ
• 必要とされるエキスパート
• 計画にない複雑性や無秩序

彼女はLagomを紹介した。Lightbend社の“自己主張がある”マイクロサービスフレームワークで、AkkaとPlayをベースにしており、Lagomがどのように今日のエンタープライズの挑戦に取り組んでいるかを論じている。Carter氏は“迅速な変更とはたいてい迅速な熟成を意味する”と主張した。要約すると、彼女は“変更のペースについていき、あなたが動くにつれてアーキテクチャ完全性を維持するために、アプリケーションレベルの上、システムレベルに抽象性を提供するフレームワークの利用を試してほしい”と主張したということである。

Carter氏はETEでInfoQにマイクロサービスやリアクティブシステム、ScalaとJava、そしてSMACK(Spark, Mesos, Akka, Cassandra, Kafka)スタックについての彼女の考えを語った。

InfoQ「Lightbend社に勤めてどのくらいですか、現在の職務は何でしょうか？」

Kiki Carter氏「昨年の7月にLightbendに入社しました。この夏で1年になります。Lightbendとは顧客そしてクライアントとして5年間いっしょに仕事をしました。

ここでは私はエンタープライズアーキテクトです。職務の多くは私たちのエンタープライズの大企業との交流に関連します。彼らが私たちの技術をより理解できるよう手助けしたり、新しい機能やソフトウェア製品を出した時に説明したり、それらを広めたり、こうした企業での利用と採用の数を増やしたりすることです。おそらく彼らは小さなプロジェクトで始めて利点を見てきて、それを拡大したくなりいくらか発展させました。私もまたそれを援助したいのです。私のチームがエンタープライズでリアクティブ技術を実際に成長させられるように。これが私の職務の本当の中核となることです。」

InfoQ「Bold RadiusはLightbendの近くでアプリケーションを開発しコンサルティングサービスを提供しています。OpsClarityはリアクティブシステムを監視するツールを開発しています。両方の企業が最近Lightbendによって買収されました。買収はLightbendがこれらの顧客にサービスを提供する方法にどんな影響を与えますか？」

Carter氏「いい質問です。Bold Radiusから始めます。この買収で起こる出来事の1つとして、私たちがより広い範囲の顧客にサービスができるようになることです。私たちはまだプロフェッショナルサービスに関することに限り同様のことをしている他のパートナーと協力しています。ご存知の通り、私たちはコンサルティング企業ではなく、このことが企業が私たちの技術を使用するだけでなく、私たちが外れて彼らが引き継げるように既存の組織内で知識を成長させられる助けとなります。全作業を露わにすること、“引き継ぎ”のスケッチとともに取り残すことよりも顧客とパートナーができるようにすることにより焦点を当てています。

OpsClarityを含めて、これは興味深い、コインのもう1つの面です。ここでは私たちは顧客に彼らの遠隔測定を可視化するよりよい方法さえ提供します。ご存知のとおり、非同期でリアクティブなアプリケーションと分散システムを監視することはありふれたものではありません。そして私たちがLightbendの監視とともに提供する遠隔測定は人々が少なくともこうしたアプリを監視する手助けに実際役立ってきました。しかしOpsClarityがもたらすものはこの監視の別のレベルです。それは人々が彼らのシステムの概観を得られるよう、とても美しく可視化したものをいくつか提供することです。視覚的な観点ではAIの観点と同様に異常検知に目印をつけることができ、これはOpsClarityに組み込まれています。私たちは実際にエンタープライズの運用チームがこのことから利益を得てより賢明な方法で使えるように、この遠隔操作を次のレベルに上げてきました。」

InfoQ「マイクロサービスはここ数年間ずっと興味深い話題となっています。エンタープライズ開発トレンドの2016年のレポートによると、(a) 本番でマイクロサービスを使っている、(b) マイクロサービスの利用を考えている、(c) 試験環境でマイクロサービスの実験をしている、(d) まったく興味がない、といった組織分布さえあるように思えます。また開発者にマイクロサービスの利用を警告するたくさんの文献もあります。“マイクロサービスの7つの大罪”といったものを含みます。メッセージとしては“マイクロサービスは注意して使おう”ぐらいです。Lightbendがこういった特定の関心事に取り組むためにできることはありますか？」

Carter氏「もちろんです。“マイクロサービスは注意して使おう”は正しい言葉である気がします。そうしないとき、あなたが経験することは、業界で私が考えていることが起こったのですが、巨大な反応でした。そこでは人々がマイクロサービスを使い、正しく使っていない時に発生する無秩序を経験し、それからたじろぎ、再び変化に抵抗します。しかし、その必要性で私たちが取り組まなければならないことは、アーキテクチャのベストプラクティスをコード化するためにシステム構築レベルで抽象化するフレームワークです。犯してしまったこうしたミスのいくつか、またはマイクロサービス構築において経験した問題のいくつかは、とくにマイクロサービスのために構築された私たちのフレームワーク、Lagomを使うことでこうしたベストプラクティス、デザインパターン、アーキテクチャの原則、根本的な技術や使っているツールでさえ“コード化”されています。これは単純にLagomのセマンティクスを使うことが正しい方法でマイクロサービスを書けると保証するといった方法です。これはLagomのすばらしいところです。技術的問題を解決しますが、他のアプリケーションやフレームワーク、ライブラリやツールの上の薄い抽象化です。これらを一緒にすることで、一貫した方法でこれらの問題が解決でき、アーキテクチャの完全性、それとともに技術的試算だけでなくシステム設計にも関わる何かを提供する能力を維持しています。これはまさにLagomの原則です。マイクロサービスを正しくすることと、無秩序を避ける手助けをすること、こうしたことを確実にやります。」

InfoQ「マイクロサービスはどのように使うべきだと考えますか？」

Carter氏「私はマイクロサービスはモノリスを分解するために使うべきであり、モノリスを分解することが目的ではなくクライアントやユーザにものごとをより早く提供することができるようになることが目的だと感じています。機能をより早く提供し、システムの耐障害性をより高め、分離性と時間とともにシステムを強くすることができるものを持つ必要があります。これは、時間とともに大きくなり、システムの生存期間内にうまく年をとるためです。現在では変化はすごく早く起こります。システムをすばやく変更し、すばやくシステムをビルドし、それを変更できるようにするということは、マイクロサービスが持つ領域となります。これらを一貫した方法で管理することは、システムが上品に熟成する手助けとなります。」

InfoQ「モノリスを分解することに関して、マイクロサービスを使って新しいアプリケーションを始めるべきであると言うのは正しいですか？」

Carter氏「そうですね、その通りですが、モノリスのパーツを再利用しますよね。マイクロサービスを使うためにそう言うつもりはなく、システムを焼き払う必要があり、そしてもう一度やり直すということです。Lagomを導入すると、そんな必要はありません。特定の技術的なコンポーネントによって分解するのではなく機能によって分解できます。もし機能で分解するなら、既存のコンポーネントを引き抜き、合成を使い、機能自身を簡潔に相互作用する能力とともに新しいサービスに入れるためにほかのものを追加するかもしれません。それも既存のモノリスの分解を継続したままで。」

InfoQ「今後5年でSMACKスタックがソフトウェア開発でより重要になるということについてはどう思われますか？」

Carter氏「いい質問です。それより早く重要になるとさえ考えています。今後5年で他の何かが出てくるでしょうが、少なくとも今はSMACKスタックが多く使われるものとして見ています。データの効率的利用として見つけたことが理由です。豊富なデータと膨大な量を扱うことができ、それでも早く動作します。Lightbendでは“ビッグデータ”とは言いません。“迅速なデータ”と言います。システムに存在するデータをベースにしてシステムに対する洞察を得て、古くなる前にすばやくそれらに作用することができる、そのようなことです。現在ではデータはあっという間に古くなります。もし出す広告やレコメンドについてすばやく決定する必要があるなら、現実的な時間でそれができる必要があります。SMACKスタックはそれを可能にしてくれます。それを見る方法は、今後5年でスタックが発展させていくでしょう。たとえばKafkaの台頭はすぐでした。おそらく将来分散、コミットログの事業で他のプレーヤが出て来るでしょう。Cheramiを考え出したUberのような人々、または似たようなことを見ています。しかしKafkaと同じではありません。思うに起こっていることとはスタックは今かなりユビキタスだということです。人々が一緒にそれを引っ張ってきたからです。こうしたことは現場ではもっともよいことですが、時が経つにつれ進化し、スタックに入っていく人はもっと多くなると思います。Sparkは長期間とどまると思いますが、Flinkとbeamもまた目立ってくると見ています。この迅速なデータ空間は将来唯一成長するものです。同時に、問題に対処する技術が爆発的に増えるでしょう。そして同時にそれをいくつかに退け“私たちはこれらの上に標準化します”と言うでしょう。」

InfoQ「リアクティブプログラミング/リアクティブシステムは今後5年でどのように進化すると思いますか？」

Carter氏「この領域では明確なシフトがあると見ています。1つわかることは、もう一度言いますが、少なくともリアクティブプログラミング領域では対処するためのギャップがあります。多くの場合、リアクティブプログラミングについて人々が話すとき、非同期コミュニケーションやおそらく非同期I/O、ノンブロッキングコミュニケーションにフォーカスを当てています。しかしリアクティブシステムやリアクティブプログラミングについてLightbendでの意味で話すとき、それよりも多くのことがあります。人々がこの情報のビジョンを考える方法であるリアクティブマニフェストを見るとき、システム構築の際には絶対に避けられれない耐障害性と伸縮性もまた扱います。モノリスを構築する場合にリアクティブプログラミングをするだけなら少しの間それを無視できるかもしれません。リアクティブなモノリスでしょうか。しかし一度システムを一緒に組み合わせれば、正確には相互に結合され協働する必要があるシステムなら、実際にシステムレベルで耐障害性とレジリエンス、伸縮性が必要です。このことで、たとえば単純なコンテナや仮想マシン、まはたレジリエンスを得たと言っている何かを使ったきめが粗い災害復旧型の解決策には依存しない、ということを私は意味しています。 しかし外部のコンテナや仮想マシン、クラウドプラットフォームに依存する前にアプリケーションレイヤでレジリエンスがより多い、少ないというのは少し違います。」

InfoQ「Scalaで構築されたアプリケーションが関数型プログラミングが入ったJava 8が出て以来減っていると何かで読みました。アプリケーションをScalaとJavaのどちらで構築するか考えている開発者に何か伝えることはありますか？」

Carter氏「実際にはJava 8が出現したことで人々がScalaを使う理由が減ったわけではないでしょう。同時にほかのことも周辺で起こっています。おそらくScalaを使っていたがGoを試したりJavaScriptフレームワークをもっと使うことに決めたという人もいるでしょう。彼らは必ずしも出来事に関わっているわけではありません。現場にいる、ラムダの関数型プログラミングを推し進めてきた多くのプレーヤが来て慣れた言語でそれを試す余地を与えたのだと思います。

もし誰かが私にJavaかScalaを決める際に質問してきたら、この決定はビジネス目標によると答えます。会社の目標は何ですか？チームの目標は？ビジネスの目標は？たとえば、もし大量のデータを扱っているならSparkを使っているかもしれませんし、実在するデータの一貫性を必要とする環境で働いているでしょう。不変構造とともに働くならScalaはとてもぴったりです。デフォルトでそうだからです。一方Javaでは、データ構造を不変にするためには異なることをする必要があります。Javaはたとえばラムダといったものを与えてくれるかもしれません。それは関数型の機能すべて、副作用がない、不変でないデータ構造は持てないといったものを得られるという保証には実際なりません。この場合命令プログラミングに慣れている、もしくはふさわしい場所で新しいオブジェクトを作りよりも変更可能なオブジェクトに慣れている開発者チームでは実行したくないでしょう。1つの方法でしかJavaを使っていない人々にとってこれはパラダイムシフトとなります。それからJavaコーディングの習慣に対して変更しなければならないことを理解することなく関数型の方法でJavaを使うことを決定します。一方もしScalaを使っていれば、これはすでに終わっています。実際には目標が何であるかに依存します。もし大いに並列に動作し、本当によいデータ完全性を持つシステムを作ることに注意を向けるなら、不変性を中心的な性質に持つ言語に注目するよう提案するでしょう。

これは単に1つの例です。しかし人々の究極の目標に関する優先順位リストを検討していきたいです。何かに投資をするのはつねによいことです。たとえ先行投資であっても、トレーニングや学習において、最終目標にとって重要なことに投資するのです。もしScalaの学習に、それが今後特定のパターンをより簡単に実装する手助けとなるという理由で投資するのなら、それはよい投資です。しかしJavaをすでに知っているけれど、アプリケーションとともにある期間が続くにつれて今後これらのパターンの実装があなたにとって難しいこととなると言うのは、あなたが考えなければならないトレードオフとなります。」

InfoQ「興味深いです。おもしろいことにどちらの言語もJVMへコンパイルします。」

Carter氏「もし人々が実際に揺れているなら、一番簡単に行えることをしましょう。了見を狭くしてはいけません。システムの進化に広い心を持ち続けましょう。ScalaとJavaですばらしいことは、あなたが言ったように、JVMへコンパイルすることは、一方に歩き出してもどこでも変えられるということです。よく相互運用できるのでバイトコードレベルでは何も失いません。」

InfoQ「あなた自身のことや仕事、何か他に見逃しているかもしれないことで読者に知ってもらいたいことはありますか？」

Carter氏「私は旅行が好きでたくさんの国に行きました。上からの眺めやスカイダイビング中の景色も好きです。高所恐怖症なんですけどね。自分が怖いと感じることをします。最終目標を達成するには他に方法がないからです。美しい上からの眺めを見るにはスカイダイビングをする以外に私には他に方法がありません。なので高所恐怖症だからそれはできないとは言えません。“変化を好まない”モードに入っているアーキテクチャ組織で働いているとそうしたことを目にするのですが、それはおかしいことです。最終目標を達成するためには他に方法はありません。挑戦してみてそれをする必要があります。

ほかに、私は社会福祉も好きです。私にとってもう1つの生活です。人身売買を防ぐ組織で働くことが好きです。家族に売られてしまったり誘拐されたりした少女たちを助ける手助けをする救助組織で働いています。情熱を傾けているもう1つのことです。こうした問題をいくつか解決するために、技術の相互作用と私たちが構築できるものを見ていきます。」

編集者注

Michael Redlich氏は2008年からETEの活発な参加者で、出席し、スピーカーをし、直近では2013年からETEの運営委員会メンバーです。