どのツールを選択するかではなく何を解決するかが大事　マイクロサービスの“光”と“闇”

「マイクロサービスの光と闇」の概要

濱平紗穂氏（以下、濱平）：みなさんこんにちは。このセッションでは「マイクロサービスの光と闇」と題して、マイクロサービスを取り囲む実体、考慮しておくと有益なtipsを紹介したいと思います。さっそくですが、マイクロサービスの定義について、認識を合わせておきたいと思います。

マイクロサービスは実装戦略、ストラテジーの1つのツールだと考えています。ツールは、常に良い面と悪い面が同時に存在しています。そのため、選択時にこれらを理解する必要があります。そこで今回のスコープは、マイクロサービスを検討している、もしくはこれから挑戦しようとしている方、または実際に挑戦しているがうまくいっていない方に対して、「こういう視点は考慮していますか？」という問いかけをメインに進めます。

逆に具体的な技術選定や、マイクロサービス間はAPI通信でやり取りしますが、この管理手法などについては触れません。こういった内容を期待している方には物足りないと思うので、事前に理解してもらえればと思います。

マイクロサービスの前にモノリスとは？

それでは、簡単に自己紹介をします。私は現在、VMware Tanzu Labsというサービスの中で、プロダクトマネージャーとして働いています。Tanzu Labsの1つのサービス、Application Modernizationサービスでは、既存のアプリケーションをどうにかしたいと悩んているお客さんと1つのチームを組み、具体的にどんなことをすべきで、どこから始めればいいのかの問題解決をチーム一丸となって進めています。

本日は、私たちのサービスの中で大切している要素を紹介できればと思います。さっそくマイクロサービスの話に移っていきますが、まずその前に、モノリスについて考えてみたいと思います。モノリスを一言で表現すると、「とにかく作ってみるのにちょうどいいツール」です。

“とにかくまず作ってみる”という初期段階のタイミングでは、データベースは1つで、いくつかのアプリケーションをデプロイするような設計かもしれません。要件によってさまざまと思いますが、最初から好んで複雑に作る必要はありません。そのため、この状況下でモノリスであることに不満はないはずです。

しかし、そこから数年と時間が経過すると、システムは意図せず複雑化してしまう傾向があります。これはサービスとして提供した要素が増加し、ビジネスとして期待している要件と、システムのかたちがかけ離れてしまっていくと、顕著に技術的負債として浮かび上がってきます。

システムの複雑化によりソースコードの変更を恐れ、リリース頻度が低下してしまったり、密結合なシステムが故にトラブルの影響が広範囲に広がってしまったり。一部だけスケーリングを図ろうとするも、パターンを考慮せず設計していて、結果的に全体に対してスケーリングを図るため、コストがかかってしまうなどがあると思います。

ちなみにこれはモノリスというツールの問題というより、モノリスからスタートし、必要なポイントを考慮せずシステムが肥大化してしまった、技術負債といえます。

マイクロサービスは技術負債を抱えている中で定義されたもの

そういった技術負債を抱えている中で、新たなツールとして定義されたのが、マイクロサービスというツール、考え方です。クリス・リチャードソンが2020年に出版した日本語版『Microservices Patterns』という書籍の中で記載されている定義によると、「マイクロサービスはアプリケーションを個別にデプロイできる疎結合のサービスコレクションとして構成するものだ」とあります。

マイクロサービスの“マイクロ”という言葉でも、よく「具体的にどれぐらいのサイズが適当か」といったディスカッションを耳にしますが、ここでは定量的な決めごとではなく、抱えている問題を解決できるサイズであることが重要とされています。

技術負債と期待値

それでは改めて、現在の技術負債とその問題から解放された状態、期待値を考えてみたいと思います。まずはデプロイ、システム全体へ影響してしまい、リリース頻度が萎縮してしまっている。このような場合は、影響範囲を絞り込めている状態を期待値とします。CI/CDパイプラインで自動化するなど、いくつか回避策はありますが、1つの案としてそもそもシステム、デプロイ単位を分離することが挙げられます。

この場合、分けかたがビジネス要件にマッチしていなければ、影響範囲の絞り込みが結局困難になる可能性があることは言うまでもありません。この際に、DDD、ドメイン駆動設計の要素を取り入れることが有益だと考えます。

次に、システムのスケーリングにおいて自社で物理的なサーバーを運用しており、中長期的なロードマップをもとに、事前にリソースを手配しているような場合。本当に必要な時間帯、ピーク期間だけスケーリングできれば、その柔軟性によるコスト削減が図れます。これを可能にするのが、CloudNativeという選択です。

次に、チームのスケーリングも考えてみたいと思います。もしソースコードが1つで、100人の開発者がコードの全体に対して修正権限があり、それを一斉に触ったときに起こる開発プロセスのコンフリクトを考えると……ゾッとします。これが、100人規模を細かいチームとして分割させ、あるサブセットに対してそのチームが修正、管理できる権限があるとしたらどうでしょうか？

コンフリクトの恐怖からは解消されそうです。しかし、これはコンフリクトをなくすことがゴールではなく、素早く動くこと、開発を回すことが重要になります。つまり、分離されたチームぞれぞれが”自立したチーム”であることが求められます。ここまでで、期待値にたどり着くために考慮すべきことが出てきました。それらは新たに習得する必要があるもので、学習コストとも解釈できます。

学習コストへの取り組み：自立したチーム

弊社でこの学習コストに対して、具体的にどのように取り組んでいるのか紹介していきたいと思います。まずは自立したチームについてです。私たちは、チームの人数は多くとも10人以下が理想だと考えています。これは、コミュニケーションコストを考慮した上での数値です。次に、さまざまな視点を考慮する利点に関して焦点を当てると、Balanced teamという1つのチームを作ることが有効だと考えています。

このチームのロールはPM、ビジネスを理解している人。デザイナー、ユーザーのニーズを理解している人。開発者、技術を理解している人で、バランスの取れた構成を取ります。このチームは、ある程度の決定権が委譲されていることが非常に理想的です。そうすることで自分たちがチームで学んだことを、わざわざ毎回上に確認して承認のスタンプラリーをするようなフェーズを通らず、すぐに次のアクションをチームで決められます。

学習コストへの取り組み：DDD要素の導入

続いてDDD要素を取り入れることに関してですが、これはビジネス要件とシステム要件をマッチさせるという点に関して、エリック・エヴァンスが提唱したDDD、ドメイン駆動設計を取り入れられます。今日のビジネス要件が、明日も同じかどうかは誰にもわかりません。完璧な設計は基本的に存在していないという前提で、今わかっているビジネスの理想から会話を始め、それをもとにどういう設計がフィットしていそうか検討していきます。

検討に何年もかけたものの、結果実現性が低かったケースを避けるために、私たちは鳥のように空を切るという意図を込め、“swiftメソッド”という名前を分析アクティビティにつけました。これは週単位で物事を動かしていきます。

アクティビティは、すべてポストイットで可視化されていきます。まずはどのようなイベントが存在しているかをビジネス視点で会話をし、その後、将来のビジョンや今の困っているポイントを「EVENT STORMING」というツールを利用して理解していきます。ここにはビジネス要件を理解しているメンバーが、必要になっていきます。

次のフェーズに移る前に、マイクロサービスになり得るサービス候補を定義します。候補としている理由は、実装フェーズで改めて「本当にデプロイ単位まで分離していくのか」をディスカッションする余白を残すためです。具体的には、あえてデプロイ単位を分離し、サービス間通信をAPIで処理するメリットはあるのか。また、データベースを分離するとデータの整合性の担保を取る必要が出てきますが、その複雑度をチームが処理しきれるかなどを考慮する必要があります。

そして次に、サービス候補などの情報をもとに、どんな設計が検討できるかを話し合います。このアクティビティを、私たちはBORISと呼んでいます。そして次のSNAPEというフェーズでは、BORISで描いた情報をもとに、実際にどんな要素、APIやデータベース、UIを実装していかなければならないのかを洗い出します。

実際に実装に着手するには、さらに優先順位づけ、技術の選択などが必要になりますが、ここで一番重要視しているのは、とにかく開始できそうなポイントを見つけることです。こうすると、考えるだけではなく、実際にアクションを起こせるようになります。

学習コストへの取り組み：CloudNative

次に、CloudNativeについて話したいと思います。CloudNativeというと、VMやKubernetesなど、ハードウェアのソフトウェア化を思い浮かべると思います。しかし、ここではCloudNativeが魅力的な背景、つまり柔軟な変化に素早く対応できる条件が整っていること、という意味で捉えていきたいと思います。

いくらCPUをいつでも変更できる、もしくはVMやPodsを作成、削除できる環境が整っていたとしても、それを操作する人がその速度、環境を最大限に活用できていなければ宝の持ち腐れです。そこで1つのアプローチとして、アジャイルという学びのサイクルを取り入れることでより開発を効率化し、CloudNative環境にマッチした迅速な動きを人が取れることになります。

私たちは“繰り返し”であるイテレーションの期間を1週間としています。図のように、1週間のスケジュールも決まっています。アジャイルでキーとなるポイントは、金曜日に行われるチームのフィードバックの時間です。こうして開発側のサイクルも早くなり、いざインフラ側への要望が出たときも、クラウド化によって物理的な障害がなくなり、このスピーディさが開発の後押しをしてくれます。

これらの取り組みにより、弊社は期待値にたどり着くための学習に対して、アプローチを取っていきます。

リファレンスとして紹介しますが、これが弊社の過去のイベント動画およびリンクです。我々が今お伝えしたBORIS、SNAPEなどの言葉が気になる方は、Tanzu Development Centerにアクセスをしてみてください。

マイクロサービスは単なるツールである

まとめです。このtipsは、通常何時間単位で語るトピックなので、この15分という枠の中ですべてを伝えることはできませんが、ここで伝えておきたいところ。繰り返しになりますが、マイクロサービスアーキテクチャは、単なるツールだということです。いくつかの利点、主に本日話したエンジニアリング組織のスケーリングと、重大な欠点があります。

これはシステムが複雑になるが故の、高度な技術的スキルが求められる点も指しています。どのツールを選択するかではなく、何を解決する必要があるのか、という視点が大切です。また、「ビジネス要件が頻繁に変わる、だから頻繁にリリースができる環境がほしい」ところから裏づけされているように、どんなロールの人であれ、今求められていることは、変化の激しいこの時代に対応できる、柔軟な視点です。

自己紹介でもお伝えしたとおり、弊社VMware Tanzu Labsでは、お客さんのApp Modernizationという挑戦に対して、そのお客さんとチームを組み、何がベストな選択なのかを一緒に考え、挑戦してきたメンバーが世界中に在籍しています。興味があれば直接私にDMをいただくか、もしくはVMware Tanzu Labsのサポートまで連絡してもらえればと思います。

本日のtipsが、少しでも参考になればうれしく思います。ご視聴ありがとうございました。