マイクロサービスアーキテクチャを再評価する - 影響、運用面での複雑性、代替案

原文(投稿日：2020/12/23)へのリンク

マイクロサービスの影響をテーマとするInfoQ LiveラウンドテーブルがWes Reisz氏の司会で行われ、運用上の複雑性、マイクロサービスモデルの代替などが話し合われました。参加者はLeif Beaton氏 (NGINXシニアソフトウェアアーキテクト)、Yan Cul氏 (AWSおよびサーバレスの独立系コンサルタント)、Nicky Wrightson氏(Skyscnannerプリンシパルエンジニア)です。

Peter Rodgers氏が2005年にWeb Service Edge Conferenceで行ったプレゼンテーションの中で、初めて"マイクロWebサービス"という用語を提案した時、それは当時の考え方に反するものでした。2005年はSOAPサービス指向アーキテクチャがピークを迎えた年でしたが、Rodgers氏はRESTfulサービスを主張したのです。プレゼンテーションの中で氏は、適切に設計されたマイクロWebサービスプラットフォームにより、"Unixライクなスケジューリングとパイプラインを採用したWebおよびRESTサービス"というアーキテクチャ概念と、柔軟性と単純性を提供するパイプラインを、サービス指向アーキテクチャの下で統合する方法について説明しました。

その後の6年間にわたるイノベーションと、この問題に対する思索の期間を経て、2011年5月に行われたソフトウェアアーキテクト向けワークショップにおいて、参加者の目の前にあるものを説明する用語として"マイクロサービス"が使用されたのです。翌年の春には、このアーキテクチャスタイルを説明する"マイクロサービス"という用語がコミュニティに定着しました。

James Lewis 、 Fred George 両氏はさまざまなプレゼンテーションを行いました。Adrian Cockcroft氏はNetflixでのシステム開発に積極的に採用して、それらを"細分化(fine-grained)サービス指向アーキテクチャ"と説明しました。

この分野での思想的リーダとしては、他にもSam Newman、Evan Bottcher、Martin Fowler、Graham Tackleyといった方々がいます。マイクロサービスと命名されるよりも前、極めて初期のプレゼンテーションのいくつかはQConで行われています。

マイクロサービスがその進歩する方向を見出したのは、DevOpsの導入に伴うものとしてでした。当時、チームによるシステム構築方法としてのDevOpsは、特に継続的にデプロイされるシステムにおいて人気を集めるようになってきていました。

ただしそこには、コストという問題があります。今回の記事ではこのコストと、マイクロサービスにトレードオフの価値があるか、という点に注目していきます。

Wes Reisz: マイクロサービスの定義として私が気に入っているのは、Adrian Cockcroft氏の"コンテキスト境界内の細分化されたサービス指向アーキテクチャ"というものです。みなさんはマイクロサービスをどのように定義しますか？

Wrighson: この問題には何年も頭を悩ませてきたような気がします。それというのも、マイクロサービスを始めた当初の3年間は、DDDとの関係が十分に理解できていなかったからです。当社のアーキテクトたちも同じで、結果として"ほぼ独立的にデプロイ可能な最小のコード片"という、とても具体的な解釈をしていました。それは間違いでした。ここで、コンテキスト境界という考え方に立ち戻って考えてみたいと思います。アイデアとしては同じではありませんが、ドメイン内のコンテキストについて述べているのは事実ですし、依存関係を外部に持たないというのも同じです。つまりは、完全に隔離されているのです。

Cul: コンテキスト境界については、私の意見もほぼ同じです。実際に私は、マイクロサービスとコンテキスト境界をよく同じ意味で使っています。ラムダ関数ならば、インフラストラクチャの観点から、マイクロサービスと思われるものすべてのチェックボックスにマークが付けられると思います。ひとつの関数がすべてを行うのではなく、もっと大きなマシンの小さな一部なのです。何らかの機能をするためには、すべてがパーフェクトに同期して動作しなければなりません。そのようにして実現される機能が、ビジネスの観点から望まれるものなのです。話を戻すと、マイクロサービスを考える時、私は、自己完結型の責任範囲ということを考えます。その範囲内であれば、ひとつのチームないし一人がすべてを所有し、検討し、移動し、好きなように構成を変更することができる、という意味です。外部に対しては、すべてをメッセージ経由して行わなくてはなりません。直接的な依存関係は最小限にすべきです。そうしなければ、強い結合が生じて、複雑な環境ではエラーの連鎖が発生することになるからです。

Reisz: マイクロサービスが立ち上がってから8年ほどになりますが、そのテクノロジやアーリーアダプタ、アーリーマジョリティ、レイトマジョリティ、ラガード(laggard)などを考えた時、マイクロサービスは普及曲線のどの段階にあると思いますか？

Wrightson: 意外に思うのは、いつものように人々が飛びついていない、ということですね。キャズムは越えたのですが、いまだアーリーアダプタが大半を占めている状況です。他の人たちにまで広がるには、まだまだ苦労があるのではないかと思います。それはマイクロサービスのせいではなく、付随するものに原因があります。根本的かつ組織的な(organizational)シフトと、マインドシフトが必要なのです。オンプレミスに留まっている組織は、まだたくさんあります。彼らはクラウドやその関連テクノロジには見向きもしません。DevOpsや継続的デリバリなど考えてもいないのです。

さらにマイクロサービスには、もうひとつ、それが組織的な問題を解決するものであって、技術的問題を解決するものではない、という点もあります。マイクロサービスを推進する以前に、その組織的シフトに対して折り合いをつけなくてはなりません。極めて従来的な組織の中で、非常に複雑なモノリスを運用している人たちの多いことが、レイトアダプタを足止めしている理由だと思います。

Cul: いまだアーリーマジョリティのフェーズに留まっているという点については、同じ意見です。オンプレミス、あるいはモノリシックと呼ぶようなシステムから、直接サーバレスに移行しようとするカスタマたちとたくさん仕事をしてきました。彼らはまず、マイクロサービスや問題のドメインを分割する方法について学ばなくてはなりません。モニタリングやデバッグから可観測性の方向まで、マイクロサービスにはたくさんの課題が伴います。そういった企業の数が、私が数年前に思っていたよりもずっと多いのは事実です。最近では、あらゆる分野の企業と一緒に仕事をするようになりました。そのような点から、まだすべての人たちがマイクロサービスを導入している訳ではない、ということが分かったのです。

Reisz: Nicky、あなたの意見の中に、"組織的(organizational)"という言葉がありましたね。私が最初にマイクロサービスの考え方を理解しようとしていた頃、Martin Fowler氏のブログ記事を目にしたのですが、その中にあった、"マイクロサービスを実行し運用するには、この高さでなくてはならない"と説明された図が印象に残っています。そのバーの位置は、今はどの程度なのでしょうか？マイクロサービスを運用できるようになるには何をする必要があって、そのバーは以前よりも高くなったのでしょうか、それとも低くなったのでしょうか？

Wrightson: 先程も少し触れたように、組織的に見れば、マイクロサービスは個々の変更を迅速にデプロイ可能にするためにあるのだと思います。それが問題になるのは、企業がある程度の規模まで成長して、自律性の高い小規模チームや個人の存在が必要になった時です。どの程度の大きさの組織なのか、それはまだ分かりませんが、

いろいろな面において、状況はさらに複雑になってきている、と私は思います。それは、複雑な問題のひとつひとつに対して、シンプルなソリューション(マイクロサービス)がたくさんロールアウトされるからです。その問題に関連して12個のシンプルなソリューションがロールアウトされていれば、問題を解決するにはそれら12のプロダクトをすべて理解しなくてはなりません。そんなことが続いていくのです。そのために私たちは、たくさんのツールを投入しています。自分の状況を理解するために必要な理解の量は、このようにどんどん増えていくのです。バーは今でも同じような位置に留まっていると思いますが、見なければならないものの幅は、わずかに広がっているのです。

Cul: Nickyのツールについての意見には同意できます。ツールの観点から見てDevOpsエコシステムが今どこにあるのかということや、どのツールを使うのかという話題に熱中するのは、まったく好きではありませんし、悩み以外の何ものでもありません。先日、KubeConのプロモーションを見たのですが、そのうちの1分半は、Kubernetesクラスタの監視やコントロール、その他のオプションに使用するツール類の紹介でした。

Reisz: 選ばなくてはならない、ということですね。

Cui: そのとおり。たくさんのテクノロジがあって、それらはマイクロサービスアーキテクチャの構築を支援するもののはずなのですが、実際には非常に複雑なものにして、習得を難しくしているだけなのです。それと同時に、開発するシステム自体も複雑になっていると思います。特にサーバレスでは、非常に興味深く、かつ複雑なイベント駆動システムをたくさん目にします。そういったシステムでは、API中心のマイクロサービスでさえ解決する必要のないような、SNSやKinesis、DynamoDBストリームなど、あらゆる種類の場所でのトレースに関連する重要な課題を数多く抱えているのです。そして今では、それを上手く処理できるようなツールがあります。より複雑な問題を解決するために、さらに複雑なソリューションが構築されるようになり、それによって可観測性に多くの関心が集まる、という状況は今も変わっていないと思います。

Reisz: Leif、あなたは、マイクロサービスを使うためには、どの程度のレベルが必要と思いますか？

Leif Beaton: どれ位のレベルになりたいか、によりますね。マイクロサービスの観点からアプリケーションを開発するという考え方は、従来のモノリシックなプロセスとは根本的に違います。その意味で、マイクロサービスの導入にはコストが必要なのです。 モノリスで可能なレベルよりも、事前にもう少し明確に定義しておく必要があります。スモールスタートアップの考え方で、まずはモノリシックなアプローチから始めて、その後どうなるかを見る、という方法も可能でしょう。マイクロサービスのアプローチは、ややスパゲッティスープ的になりやすい傾向もあるからです。マイクロサービスを利用するにはコングロマリットでなければならない、ということはありません。事前に計画して、アプリケーションのこの部分、この範囲、ということを決めておけば、企業の規模に関係なく、メリットがあります。ただし、モノリシックに留めるべきアプリケーションというものも存在する、という点は付け加えておきたいと思います。

Reisz: みなさんはマイクロサービスのいくつかの問題にぶつかり始めています。そのひとつは、Nickyの言うように、複雑性です。CNCF(Cloud Native Computing Foudation)の見解で言えば"モンスター"です。そこには数多くの、さまざまなが可能性あります。KubernetesのCNI(Container Network Interface)を例にすれば、Canal, Flannel, Weave, Cilium ... — コンテナネットワークだけでも、これだけの選択肢があるのです。複雑性がマイクロサービスにおけるひとつのファクタであることは間違いありませんが、その他には、どのような課題があるのでしょうか？

Beaton: 全体的なガバナンスも問題ですね。先ほど、監視やトレースといったものについて、いくつかの話題があったと思います。マイクロサービスへの移行において、そういったものが重要になるのは当然です。アプリケーション全体の通信が、メモリ内の関数呼び出しとして同じアプリケーション上で実行されるものではないからです。ここで言っているのは、ネットワークコールについてです。それも、システムにローカルである場合と、そうでない場合とがあります。アプリケーション全体を通じて、コミュニケーションを監視し、追跡し、トレースすることが絶対に必要です。それがなければ、目隠しをして、真っ暗な部屋で黒猫を探すようなものです。

Reisz: Nicky、あなたは組織の成熟度について話していましたね。マイクロサービスにおいて、組織の成熟度が課題になるのはなぜですか？

Wrightson: チームの自律性やオーナシップの所持を進めるものだと思うからです。マイクロサービスのセット、あるいはドメインの運用をする上でも、組織の成熟性は必要だと思います。それが可能であるということは、組織として、ドメインの目標をチームが所有できている、ということです。マイクロサービスならば、外部との依存関係を持っていないので、デプロイ可能かどうかを支払担当チームに確認する必要はなくなるのですが、これを受け入れるのは文化的に大変なのです。

Reisz: Yan、少し前にオーケストレーションについて話したとき、あなたがマイクロサービス環境で作業した頃のコミュニケーションに関する課題のことを教えてくれましたね。サービスのオーケストレーションに関わる問題について、少し話してくれますか？

Cul: その時は確か、ビジネスワークフローを実装する上で、オーケストレーションとコレオグラフィ(choreography)のどちらを使うのか、というような話をしたと思います。コレオグラフィは、特にイベント駆動がほぼ当然のものになっているサーバレスの世界ではごく一般的(the name of the game)なものになっています。明らかに問題なのは、イベント駆動アーキテクチャにおいてすべてをトレースし、すべてを監視するというのは困難である上、それに伴って発生するコストに見合う価値はない、という点です。"OK、ワークフローはこれで大丈夫だ"、と言えるような中心的なポイントはありません。そのようなソース管理はどこにもないからです。システムがどのように動作するのかということは、誰かのメンタルモデルの中にしかありません。

確かに、Step Functionsのように、オーケストレーションに関わる数多くの問題を解決し、さまざまな機能の実装、監視、デバッグ、トレースを簡単にしてくれるツールを使えば、ひとつのマイクロサービスのコンテキスト境界内にいる限り、オーケストレーションの問題はまったくありません。支払いのようなビジネスクリティカルなワークフローについては、Step Functionsのようなものを使って実際のワークフローをキャプチャして、ソース管理などすべてを確実なものにした方がよいでしょう。

Reisz: イベント駆動アーキテクチャの話が出たので、マイクロサービスとの関係について聞きたいと思います。話を戻して、イベント駆動とマイクロサービスについてもう少し話してもらえますか？

Cui: 初期のマイクロサービスに対する一般的な理解は、RESTful APIなどを通じて他のサービスを呼び出して、その応答を待つ、というものだったと思います。これはまさしく、リクエスト-レスポンスパターンです。間もなくして、この方法には実際には問題があることに気付きました。何らかの応答を待っていることで、他のことができなくなるからです — では、どうすればよいのか？おそらくは、自分で処理しようとするでしょう。障害の連鎖を回避するためには、他にしなければならないことがたくさんあるのです。

その一方で、同時に処理する必要のないこともたくさんあります。イベント駆動システムは、このような数多くのプロセス同期を廃止して、イベントバスやイベントキューなどで置き換えようというものです。自分のことを処理する代わりに、オーダを処理すればよいのです。例えば、割引コード(promo-code)システムに割引コードを生成するように依頼した上で、他のシステムにその処理を依頼する必要があるとしましょう。この場合ならば、一元化されたイベントバスに対して、"オーダが正常に終了した"というイベントを発行するだけでよいのです。そうすれば、そのイベントに関心のある支払いシステムや割引コードシステムが受信して、それぞれの処理をすることができます。

マイクロサービスとイベント駆動アーキテクチャの相性がよいのは、マイクロサービスが自己充足的かつ自己完結的であるべきだからです。従って、絶えず他システムからのAPIコールに対応し、他のAPIシステムを呼び出さなくてはなりません。これは、他のシステムとの結合性を強くすることになります。これに対して、それぞれがイベントを監視し、実行した結果をイベントとして発行するようにすれば、すべてのマイクロサービスはより自己完結的になり、結合性も弱くなります。さまざまなサービス間のコミュニケーションという意味において、マイクロサービス構築に適した方法なのです。

Reisz: 組織的な問題と複雑性に関する問題について話してきました。サービスに関しては、コレオグラフィやオーケストレーションに関わる問題もありました。これらすべての問題とすべての選択肢、マイクロサービスに関連するすべての複雑性について考えたとき、モノリスの開発が望ましい、という結論になるのでしょうか？

Beaton: モノリスのままであるべきモノリス、マイクロサービスに分解するべきではないモノリス、というものはありますね。その一方で、マイクロサービスには非常に多くのメリットがあるのも事実です。最も明確なのは、それぞれのコンポーネントが行うことの自由度が高く、スコープが狭い点です。品質管理もその分、容易になります。アプリケーション全体の品質管理もやりやすくなります。検索システムや支払いシステムなど、個々のサービスをアップデートしても、すべての完全な品質保証をする必要がないからです。問題のコンポーネントに労力を集中すればよいのです。

もっと分かりにくい、目に見えないようなメリットもあります。目前の問題に適したテクノロジや言語を自由に選択できるというのは、素晴らしいことです。モノリスの世界では考えられないような、数多くのテクノロジを組み合わせることができるのです。これは同時に、特定の問題解決に対して複数のツールや言語を選択肢として持つことができる、という意味でもありますから、当然の結果として、人材確保に関する問題も軽減されます。

Wrightson: この問題に正解あるいは不正解というものはないと思います。いずれか一方を選択する必要があるとは思いません。実際に企業には、それぞれに合った、さまざまな方法で運営されるさまざまな領域があるはずです。結局は組織的な要因に戻るのではないでしょうか。迅速なデプロイは可能でしょうか？迅速なイテレーションは可能でしょうか？美しいマイクロサービスの世界が完成しても、実際の目標である継続的デプロイメントや継続的デリバリが実現できない場合もあります。それがモノリシックなアプリケーションよりも短期間で実現できると思っていると、そのような状況になることが少なくありません。相互の間にコントラクトが存在し、メッセージを可能な限り活用すれば、モノリスとマイクロサービスの共存は可能です。マイクロサービスへの移行に対して何を期待するのかを、よく検討する必要があると思います。人は新しいものに目が行きがちですが、マイクロサービスの一番深い部分に両足を踏み込んだ結果、作業時間の95パーセントをインフラストラクチャの開発に取られて、機能開発が5パーセントしかできなくなった事例もありました。方針を変えるだけなら簡単なのです。

Reisz: Sam Newman氏だったと思うのですが、"続行不能になるまでモノリスを開発するべきだ"というようなことを言っていました。つまり、必要になった時に始めればよい、ということです。理由もなく、複雑なものを取り入れる必要はありません。Yan、あなたはどう思いますか？

Cui: 仕事に適したツールを選択せよ、ということでしょうね。マイクロサービスにせよ、何にせよ — 単なるツールなのです。どんなツールにもトレードオフがあり、長所と短所があります。自分たちのスペックと天秤にかけて、短所に時間を掛ける価値があるかどうかを見極めるのです。迅速に行動したい大企業ならば、あるチームが別のチームに課す可能性のある失敗の数は少なくしたいと思うでしょうから、おそらくはマイクロサービスが適しています。チームを分離することが可能なので、ひとつのサービスのダウンが企業システム全体をダウンさせる事態を回避できるからです。あるいは、相互に分離することで、より多くの人たちがシステムで作業できるようになります。

システムに従事するスタッフが2人なら、マイクロサービスについて考えもしないでしょうし、将来的に考えることもないでしょう。組織規模が大きくなるまで、すべての作業をモノリシックに行って、すべてをモノリシックにデプロイすればよいのです。最初の部分でNickyが、マイクロサービスで解決できるのは組織的問題であって、技術的な問題ではない、と言いました。スケールアップが必要ならばマイクロサービスを使わなくてはならない、とよく言われますが、そうではありません。Supercellなどを見ると、同社の開発するゲームには、どれにも1日あたり1億以上のアクティブユーザがいますが、すべてひとつのJARから起動されています。すべてがひとつのサービス、ひとつのJAR、なのです。モノリスでも間違いなくスケールアップできるのです。実際のところ、モノリスをスケールアップする方法を知らなければ、マイクロサービスをスケールアップする方法も分からないでしょう。適切な場所で使えば、マイクロサービスは素晴らしいツールなのです。

Reisz: これまでマイクロサービスとモノリスという両極端について話してきましたが、その中間というものもあります。次はモジュラモノリス(modular monolith)について議論しましょう。モジュラモノリスは、例えば、複数のJARをひとつにまとめた形式を取ります。Yan、モジュラモノリスのような中間的存在についてはどう思いますか？自然な発展形なのか、あるいは直接マイクロサービスへ移行するべきなのでしょうか？

Cul: 私はこれまで、多数のユーザを抱えるゲーム用に、大規模なバックエンドをたくさん開発してきました。すべてモノリスでしたが、同時に、コアレベルでは適切なモジュール化が行われていました。ここで語るべきは、モジュール化(modularization)だと思います。モジュール化の実現にはさまざまなレベルがあります。全体を同時に変更しなければならないのであれば、デプロイ可能なパーツに分割する必要はありません。マイクロサービスの話をしてきましたが、もし何かを変える場合に、その中の3つを必ず変更して、すべて同時にデプロイしなければならないのであれば、その3つは本当は独立していない、ということになります。純粋な形式のマイクロサービスでなければならない、つまり共有データベースを一切持たず、すべてが独立的にデプロイ可能でなければならない、という理由はどこにもないと思っています。現実的には、越えなくてはならないハードルがたくさんあります。

個人的には、少なくとも現時点では、中間的な立場にいることに賛成します。自分のアーキテクチャで実現したい特性について理解さえしていれば、そのための最善な方法を選べばよいのです。そこにワンステップで到達できるかも知れませんし、いくつかの中間点を通ることになるかも知れません。現実的な決断を下すべきです。そうでなければ、技術的な判断から何も得られず、まさしくウサギの穴に落ちることになると思います。

Wrightson: 私は設計を行う上で実用主義を信奉しているのですが、美しいエンジニアリング作業をしたいという欲望の中において、私たちは時に、それを見失うことがあるように思うのです。自らがマイクロサービスを書いているという認識のない技術者も見かけます。大学を卒業したばかりの、私よりもずっと年の若い人たちが、マイクロサービスを開発しているという意識を持たないまま、複雑な分散システムを開発しているのです。彼らがマイクロサービスを書く方法は、モジュール方式の小型モノリスであるマイクロサービスから始まって、扱い難くなった時点で分離する、というやり方です。それもひとつの方法でしょう。モジュラモノリスで同じような試みをしているのを見たこともありますが、プルリクエストが積み重なってしまい、リリースサイクルが1か月になってしまうという問題を抱えていました。これではどちらの目標も達成できず、最終的には両方の悪い面で終わることになります。

Reisz: Yanの言うように、仕事に合ったツールを使うことが必要です。スパイク的なトラフィックの多いアプリケーションを開発している、としましょう。マイクロサービスの世界でミリ秒単位のスケーリングに対処するには、どうすればよいのでしょう？

Beaton: まさに究極の目標(Holy Grail)ですね。現在、私たちが目指しているのはただひとつ、超低レイテンシの実現です。私たちの顧客は医療からフィンテックやトレーディングまで、超低レイテンシが極めて重要なすべての産業に及んでいます。サービスが立ち上がって停止するという観点から、この問題にはどうやって対処すればよいのでしょうか？コンフィギュレーション可能なデータプレーンを用意して、あらゆるインテリジェンスをそこに組み込む必要があります。システムが稼働しているということだけでなく、システム内のアプリケーションが予測可能かつタイムリに応答できること、それ以外の場合には速やかにフェーズアウト可能であること、を判断できなくてはなりません。モノリスとマイクロサービスの併用に関する議論でも話しましたが、テクノロジの併用をしたいのであれば、非常にフレキシブルなデータプレーンを用意することが重要です。おそらくはトライアングルパターンを導入して、モノリスをマイクロサービスに分解した上で対象の責務を引き継ぐ、というようなことを行う必要があるでしょう。

Reisz: Nicky、Skyscannerでは数千のマイクロサービスを運用しているそうですね。レイテンシについてはどうですか？

Wrightson: 違うエリアでバランスを取っています。ひとつのエリアが悪くなったようならば、すぐに別のエリアに送信できるようにしているのです。現在はKubernetesへ移行していますが、それまではECS上で運用していました。短時間でスケールアップするのは容易ではないのですが、全体としてロードを処理するに十分なレジリエンスを備えることを目標にしています。システムの全項目に対するロードテストも定期的に行っています。当社は旅行業なので、スパイクも非常に特殊ですし、発生するトラフィックパターンも独特です。コンテンツを扱っていた時とは大きく異なりますが、常にロードテストを行うことで、ある程度の理解はできています。他のリージョンにもレジリエンスがあります。

Reisz: モノリスの分解に関する話題は、さまざまな講演や論文などの読み物で取り上げられていますが、それらの中では、ベロシティの問題やチームが相互に足を踏み合うような状況が、モノリスを分解してマイクロサービスに移行するためのサインであると言われています。一方で、例えばistioのistiodのように、モノリシックアーキテクチャに復帰する動きも見えています。モノリスに立ち戻る時であることを示すサインというのは、果たして存在するのでしょうか？

Wrightson: Financial Timesにいた頃、単にDDDを正しく実践できていないのではないかという理由で、多数のサービスをメッシュ構成にする作業を行ったことがあります。これは一例に過ぎないかも知れませんが、他のサイトで、何らかの形の変更を全体にロールアウトするために、大変な労力を払っていたのを見たこともあります。ひとつのチームが89のサービスをサポートしているとしましょう。そのチームが機能のロールアウトを続ける一方で、それら個々にセキュリティパッチがあったとすれば、実際のビジネス運用よりもセキュリティパッチのロールアウトに多くの時間を取られることになります。新たな機能開発よりもコードのメンテナンスに時間を割くべきだという、これが本当のサインだと思うのです。もう一度考え直す必要があります。それこそが、私にとって最大のサインなのです。

Beaton: Nickyが少し前に言った、斬新な観念の方がよいはずだというような考え方が、誤った行動を取る大きな原因のひとつである、ということを改めて強調したいと思います。必ずしもそうではありません。事実を言ってしまえば、そのようなことはほとんどないのです。それが真であったとしても、一般論として、新たなテクノロジを導入するためには、それが単に新しいものであるということ以上の理由が必要です。それでもまだ十分ではありません。それがあなたの問題を解決するものであるなら — 私も当然、それに便乗します。単にそれがバージョン2.0であるというような理由で導入しようとすれば、それだけでは十分ではないのです。

Reisz: そろそろ最後のまとめに入りましょう。最初の意見はLeifでしたね。真新しいというだけでは、それを使用するための十分な理由にはならない、ということです。現実の問題を解決できるものでなくてはなりません。Nicky、最後に言いたいことは？

Wrightson: この問題に正解というものはない、と思いますね。価値のあるケースというものは常にあります。マイクロサービスを実践する上で素晴らしい点は、そのメリットを自分たちが活用できるかどうかを試すという範囲内であれば、テストドライブを行う費用が安価であることです。組織的、文化的なコストは軽視できません。

Reisz: Yanも同じ意見でしたが、技術的な問題ではなく組織的問題を解決するためのマイクロサービス、という指摘が印象に残っています。Yan、これについて最後に説明してくれますか？

Cul: テクノロジ自体ではなく、望ましいビジネス成果を常に目標にするべきです。テクノロジが重要でないとは言いたくありませんが、私たちが何かを行う理由はそれではなく、ビジネス価値を創造することにあります。そこを出発点として、最大のビジネス価値を創造するために何をするべきかを、逆算して決める必要があります。

著者らについて

Wes Reisz氏はVMwareのプラットフォームアーキテクトで、以前はSection(エッジコンピューティングプラットフォーム)のテクノロジ担当VPを務めていました。QConサンフランシスコ支部の代表でもあります。VMware以前は、英語圏のQConカンファレンス全体のプロダクトオーナ、HP Enterprise Systemsのプリンシパルアーキテクトの職とともに、ルイビル大学(カージナルス頑張れ！)の非常勤教授として教壇に立っていました。職務の他には、The InfoQ Podcastのホストのひとりでもあります。

Leif Beaton氏はNGINXのシニアソリューションアーキテクトで、アイルランドのコーク在住です。氏は20年にわたってIT業務に従事し、開発の他にセキュリティ、ネットワーキング、ハードウェアおよびソフトウェアアーキテクチャを含む多彩なバックグラウンドを構築してきました。NGINXではカスタマと日々対話して、彼らの要件を現代的アーキテクチャへと転換する作業を支援しています。

Yan Cul氏は経験豊富なエンジニアで、2009年からAWSに関わっています。銀行やEコマースからスポーツのストリーミング、モバイルゲームに至るまで、さまざまな産業でアーキテクトおよび開発リーダとして従事してきました。サーバレスに関するMediumの記事や、自身のブログであるtheburningmonk.comでも知られています。氏の開発成果の一部は、AWSによる白書"Serverless Well Architected"でも取り上げられました。氏は自身がプロフェッショナルとして使用したプログラミング言語として、C#、F#、Node.js、Elangなどを挙げています。

Nicky Wrightson氏は、以前はFinancial Timesで、現在はSkyscannerで、大規模なクラウドネイティブアーキテクチャの提供を数多く経験しています。そのような大規模分散システムを開発する中で、氏は、操作性を第一級の関心事として、熱意を持って進めてきました。現在はSkyscannerのデータプラットフォームに従事しています。その規模の大きさは、操作性、費用効果、保守性といった目標とは別に、通常とはまったく違う、解決すべき一連の問題のあることを意味しています。