CNDO 2021、マイクロサービスへの取り組みをツールではなく手法からアプローチするセッションを紹介

CloudNative Days Spring 2021から、マイクロサービスを構築する際のアプローチの方法を解説するセッションを紹介する。これはヴイエムウェア株式会社のシニアプロダクトマネージャー濱平沙穂氏による15分の短いプレゼンテーションだ。

タイトルは「Microserviceの光と闇」

セッションのタイトルは「Microserviceの光と闇」というもので、企業がクラウドネイティブなシステムを構築する際の手法、始め方を解説している。よく見かけるような、ツールのハウツーとは一線を画す内容となった。

これからマイクロサービスを始めたい人に要点を解説

濱平氏はマイクロサービスを語る前に、従来のレガシーなシステム開発の手法における成果物であるモノリシックなシステムについて解説を行った。

モノリシックなシステムの特徴を解説

モノリシックなシステムは「とにかく作ってみる」という発想には「ちょうどいい！」もので、「ビジネスチャンスをソフトウェアで解決」するための手法と解説している。

従前のITシステムはどちらかと言えば、ビジネスチャンスを実現するための手段というよりも、ビジネスサイドからの要求に従って受け身で作らされているようなモノというのが、インターネットがプラットフォームになる前の姿だったと言えるだろう。具体例として、銀行のオンラインシステムや生産管理、会計システムなどが挙げられる。これらは膨大な設計書に従って何年もかけてシステムを開発し、ハードウェアのリース期間はずっと使い続けるというスタイルが一般的だった。その時のソフトウェアは論理的なパーツには分かれてはいるものの、複数のプロセスに分離してクラスターのような複数のコンピュータで実行するような形態をとらず、モノリシックで巨大な実行ファイルが稼働していたのが当たり前だった。

一方クラウドネイティブなシステムは、パブリッククラウドベンダーから始まったことからもわかるように、インターネットからの膨大なトラフィックを捌くため大量のハードウェアと細かい単位で更新が可能なソフトウェアで処理し、必要に応じてソフトもハードも増強したり、入れ替えたりできるようなシステムを一般企業でも実装できるように仕上げたものと言えるだろう。

レガシーなシステムはペットを育てるように扱い、クラウドネイティブなシステムは家畜のようにコンピュータを扱うとも言える。

技術的負債について解説

このスライドでは、技術的負債について、モノリシックなシステムが徐々に複雑さを増し、結果的にバグなどのトラブル時に大きな影響が出てしまうことを「技術的負債」として避けるべきポイントであると解説した。

その上でマイクロサービスについて、モノリシックなシステムの欠点、つまり技術的負債を払拭できる手法として紹介した。定義についてはChris Richardson氏の言葉を引用して解説している。Richardson氏はCloud Foundryの創始者で、Microservice Patternsという書籍の著者であるので、この定義は正統派と言える。またPivotalがCloud Foundryの開発をリードしていたという関係を知れば、元Pivotalのエンジニアだった濱平氏がRichardson氏の言葉を引用するのも当然だろう。

Richardson氏のマイクロサービスに関するプレゼンテーション：
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development

ここでは数値的な指標、つまりマイクロサービスのサイズやモジュールの個数といった数字にこだわるのではなく、ビジネスを実装できるかどうか、つまり「問題を解決できるマイクロサービスを実装するべきである」と強調した。

モノリシックなシステムの負債を解決する要素を解説

このスライドではモノリシックなシステムの欠点、つまり技術的負債を解決するための3つの要素を解説した。システムを分離分解して改修に対する影響を抑えるために、Domain Driven Design（DDD）が有効であること、モノリシックなシステムが持つ長期間に渡るシステム運用コストを低減するために、システムのスケールを常に見直す手法を取り入れること、そして大きな開発チームが全体を受け持つのではなく、機能を分解しそれぞれの機能別に開発チームを構成することを解説した。3つめのチーム構成については、次のスライドでさらなる解説を行った。

VMwareが推奨する小さな開発チームの例

このスライドでプロダクトマネージャー、デザイナー、デベロッパーによってチームは構成されるべきと説明しているが、「プロジェクトマネージャー」ではなく開発するソフトウェアに責任を持つ「プロダクトマネージャー」が必須であるというのは注目すべきポイントだ。Pivotal Labsでも推奨されていた小さなチームが短いサイクルで開発とレビューを繰り返すやり方は、筆者が2015年にサンフランシスコのPivotal Labsを訪問した際の記事を参照して欲しい。

参考：Pivotal Lab、ソフト開発にはプロジェクトマネージャーではなくプロダクトマネージャーが必要

ここからマイクロサービスをビジネスの問題を解決するための手段として実装するための手法を解説した。

ビジネス要件から概念設計する手法を解説

このスライドでは抽象的過ぎると言うことで、次のスライドではVMware Tanzu Labが利用するさまざまなメソドロジーを紹介した。

EVENT-STORMING、BORIS、SNAPEを列挙して解説

唐突に英単語によるメソドロジーが現れたが、これらはVMwareのTanzu Labsが利用するシステム設計／開発のための手法であるという。過去30年に及ぶ経験から開発された手法や演習だと記述されているのは、1989年にPivotal Labsが創業されたことを意図しているのだろう。VMwareがPivotalを買収してブランディングをTanzuに統一して以来、Pivotalの名称を見ることは少なくなったが、ここではPivotal Labsのアジャイル開発の知見が引き継がれていることがわかる。

以下のページではEvent-Storming、BORISについては説明のページがあるが、SNAPEについては各ページでもSNAPとして使われているだけで理解が難しい。登壇者の濱平氏に質問したところ、SNAPは各作業の中でPost-itに記入された情報を指し、SNAPEはそれをグループで行う作業を指すという。SNAPEのEはEnhanced（強化）であり、SNAPそのものは「Snap Not Analysis Paralysis（分析麻痺にはならない）」という造語だという。

参考（Tanzu Labsのメソドロジー）：Tanzu Practices

この例ではUber Eatsのようなビジネスを想定して分析を行っている、Event-Stormingで現状とあるべき未来を分析し、それをBorisというプロセスでサブシステムと情報の経路、外部のシステムとの関わりに図解し、SNAPEで種類ごとにグループ化するという3つの段階を解説している。Pivotal Labsの知見を1枚のスライドで説明するのは非常に困難だが、敢えて3つだけに集中して簡単に説明を行ったとも言える。目新しい英単語と略語が続々登場するため、短時間で理解するのは難しいだろうが、VMwareのサイトには詳細な解説が存在するので参照して欲しい。現時点では日本語による解説がないのは非常に残念である。ちなみにBorisは作成される図が蜘蛛の巣に見えることから、The Whoのヒットソングである「Boris the Spider」から取られたという。

アジャイル開発を推進するスケジュール例を紹介

このスライドでは、アジャイル開発をペアプログラミングによって短いサイクルで繰り返す手法を紹介している。「Pivotal Labsと言えばペアプログラミング」と言われるように、少人数のチームがペアプログラミングによって対話しながら開発する方法は有名だ。Tanzuにおいてもその伝統は続いていると思われる。

まとめ

最後にまとめとして、マイクロサービスアーキテクチャーはツールであり、利点もあるが重大な欠点があると明記されている。しかし今回のセッションでは欠点について語られてはおらず、まとめとしては消化不良と言える。Pivotal Labsが持つ知見をマイクロサービス開発に応用したいという気持ちは伝わるものの、膨大な分析手法や演習方法を15分で語るには時間が足らなかったという印象だ。Pivotalの買収によってPivotal Labs改めTanzu Labsが潤沢なVMwareの資源を使える状態になったことによる良い影響、つまり日本語によるこれらのメソドロジーに関する情報の提供を期待したい。

Pivotal Labsのメソドロジーについては2019年にデンバーで行われた「Explore DDD Conference」でのShaun Anderson氏による動画を参照されたい。Anderson氏はPivotalからVMwareに移ったシニアソリューションアーキテクトだ。ここではメインフレームユーザーである金融機関が、マイクロサービスを開発する際のさまざまな分析手法が紹介されている。Borisの命名の由来もここで解説されている。

動画：Shaun Anderson - Talk Session: Swift Method: EventStorming, Boris the Spider and Other Techniques