はじめに
前回「マイクロサービスが開発・運用コストの削減にどう貢献するか考えてみた件」という記事を投稿させていただき、多くの方に読んでいただけたようで大変うれしく思います。
先の記事ではマイクロサービス化のモチベーションの一つとして、コストダウンに貢献できるのか？について、マイクロサービスの文脈で活用する技術と併せて整理しました。
次に、私の記事の内容を受け @atsuo0o が 「デジタルトランスフォーメーションにおけるシステムの俊敏性とは？を考える」 でDXの課題とその進め方について整理しました。
これまでの記事を読んでいただいた方は、自分たちに必要な技術やそのモチベーションについてご理解いただけたのではないかと思います。
しかしながら、まだ一歩を踏み出すには不安がある！という方に向け、気になる点をまとめた記事を書いてみました。同じような悩みを持つ誰かに届けば幸いです。
よくお問い合わせをいただく質問10連発
社内でマイクロサービス導入の議論をする際、かなりの確率で出てくる質問を10個選んでご紹介します。
Q1. マイクロサービスとサービス指向アーキテクチャって何が違うの？
「10年ほど前にバズったサービス指向アーキテクチャ(以降SOAと略)が今は消え去り、マイクロサービスもそれと同じじゃないの？」って言いたいのだろうな・・・という心の声が聞こえてきそうですが(笑) そんなことはさておき、答えを言えば「アーキテクチャが解決する課題は同じだが、活用する技術(設計手法やミドルウェア)が異なる」という事になりそうです。
では早速WikipediaでSOAの条件をチェックしてみましょう。
- 業務上の一処理に相当する単位でソフトウェアが構成されていること。SOAにおけるサービスとは、その構成単位のことである。プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会する」などの単位で一つのサービスとすることが求められる。どの程度の規模（粒度）を一つのサービスとするのが良いかについては様々な議論がある。
- オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従った呼び出し、応答が可能であること。その技術的基盤として、Webサービスの使用が事実上必須となっている（Webサービスについては後述）。
- サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。この段階にいたるまでには、先の二つの条件が必須となる。さらに、サービスを単位として業務処理の流れを記述する技術や、その記述通りにシステム連携を実行する技術も必要となる。
これってSOAをマイクロサービスに置き換えても意味が通りますよね？(笑)
SOAの概要には以下の記載もあり、マイクロサービスもビジネス環境の変化に素早く対応できるアーキテクチャなので、概念や解決したかった課題は同じと考えてよさそうです。
業務処理の変化をシステムの変更に素早く反映させたいという需要に応えうるものとして、2004年頃からIT業界において注目を集めている。
もう少しググってこちらの記事を見つけたので、違いが何かを理解したいと思います。
ではマイクロサービスとSOAの違いは何か？ ざっくり言うと、「複雑さ」が違います。
(中略)
このように、複雑過ぎて大企業でなければ実装できないようなXML WebサービスやSOAへの反発から、シンプルなRESTful Webサービスの考え方が生まれてきた経緯があり、マイクロサービスもまた、この流れの延長にある考え方と言えます。
なんとなくわかりかけてきました。
例えばサービス間連携の実装手段に着目して比較すると以下のような差がありますよね。
- SOA・・・ESB(エンタープライズサービスバス)でサービス間をつなぐ
- マイクロサービス・・・Restful APIやRPCなどの同期型リクエスト/レスポンス、またはメッセージキューを介した軽量な非同期メッセージングでサービス間をつなぐ
単に技術の置き換えのようにも見えますが、WikipediaのESBの欠点を読むに、当時のシス技の方々やエンジニアにとってESBの導入は非常に敷居が高かったのだろうな。。。と察することができます。
一方マイクロサービスはDocker/Kubernetes/Kafkaなど、デジタル先進企業が開発したOSSを活用することでコスト面含めた導入のハードルが大幅に下がり、クラウドサービスの助けを借りればスケーラビリティも実現でき、先行事例などで開発の知見が公開され実装しやすくなっている(≒複雑さの緩和)。というのがSOAとの大きな違いじゃないかと思います。
上記に加え、ネットワークの速度が(10年前に比べて)向上したというのも、普及を促す条件につながっていると思います。
つまり、SOAと目指す方向性がほぼ同じマイクロサービスが、時代の変化により受け入れられる条件が整ってきたと言い換えることもできます。
実装面の複雑さが緩和されている事の証明というわけではないですが、こちらのサンプルコードを動かしてみることをオススメします。
※ Linux PCにJDK/gradle/docker/docker-composeがインストール済みで、操作方法を理解している必要があります
git cloneしていくつかのコマンドを叩くだけで、10～20分程度であなたのLinux PC上にマイクロサービスアプリの一式を起動することができます。
それくらいお手軽に動かすことができるということです。
ESBを使ったSOAの情報システムの場合、まずはこちらの製品を導入する時点でお手軽感がなくなると思います。
Q2. マイクロサービスに向いている情報システムって何？
ざっくり言えば「ある程度規模が大きいシステム」という事になると思います。
あまりに規模が小さい(機能も少ない)システムの場合、分割して得られる効果が薄いという事です。
「マイクロサービスに向いている」をもう少し拡大解釈して「マイクロサービスを採用する意義がある」という意味でとらえると、「経営に大きく関わるビジネス環境の変化に素早く柔軟に追従したい情報システム」が向いてるということになります。
具体例があればもう少しわかりやすいと思いますので、ここ最近急成長しているQRコード決済サービスであるPayPayの事例記事を引用します。
PayPayの心臓部である「ペイメントコアシステム」はマイクロサービスを採用しているとのことです。採用の理由はいろいろあるようですが、整理すると以下のような話になるようです(※印は私の妄想を含めた意訳なので、気になる方は原文を参照ください)。
- 決済処理のそれぞれの部分を独立して動かすことができる
※ 他サービスに依存せず、決済処理の部分部分を独立して開発できる - 開発スピードとリリースが早くなる
※ 疎結合が保たれており独立して開発できるので、他のチームとの調整に無駄な時間をかけずにリリースすることができる - 一部のマイクロサービスを他のサービスに影響が出ないよう更新できる
※ API互換を守ってリリースする限りは、他サービスに影響が出ないようにできる - 一部のマイクロサービスを捨てて、部分的に作り直すことができる
※ サービスが提供するAPIを維持して中身を作り直せば、中身がスパゲッティになったサービスを丸ごと捨ててリファクタリングする事も可能 - 新しいマイクロサービスをどんどん追加して、新しい機能もどんどん提供できるようになる
※ サービス間を非同期メッセージングでつなぐことで、疎結合を保ったままどんどん機能を拡張できる
要約すれば早いサイクルでシステムの更新(バグ修正、機能追加など)を効率的にしたいので、マイクロサービスを採用したと言っていると思います。
QRコード決済サービスは強力な他社競合サービスに打ち勝つ必要があり、決済サービスが利用できる実店舗も大幅に増えている状況で、PayPayはマイクロサービスを活用して上手くビジネスの拡大につなげているのことがお分かりいただけると思います。
Q3. マイクロサービスに向いていない情報システムって何？
Q2の答えの逆の条件を想定していただければと思います。
- 規模が小さくて単機能である
- 作った後のアップデートサイクルが長い(1年に1回程度とかそういうレベル)
- リリース後の仕様変更が頻繁に発生しない
Q4. マイクロサービス導入の検討は何から始めたらいいですか？
一言でいうのは難しいですが、どんなシステムを作りたいのか、そのキーとなる情報を整理するところからになると思います。つまりマイクロサービスアーキテクチャを採用した情報システムを作ることで「どのようなビジネス的なリターンを得るのか？」を検討するということになります。
DX時代の情報システムは、既存業務を単純に情報システムで置換するだけにとどまらず、システム内で得られるデータで新たな価値を生み出すところまで想定して企画をする必要があります。
このような検討は今後の事業戦略や組織編制なども絡んでくる話になりますので、経営層も含めた検討が必要です。
ざっくり言ってしまえば以下のような検討が必要なようです。
- 現在のビジネス課題は何か？
- ビジネス課題を解決をするための手段の検討
- 最終的なゴールにたどり着くまでの計画を立てる
まずは上記の視点で整理を行い、マイクロサービスを当てはめ、狙った効果が得られるのか？を評価する必要がありそうです。
※いわゆるIT戦略策定というやつですね
こちらの記事でもマイクロサービス導入の初期検討について言及していますので合わせてご確認ください。
経営層からトップダウンで落ちてくる事案に関しては上記のパターンとなりますが、一方でボトムアップ的な検討のアプローチもあると思います。
(というか、海外のマイクロサービス成功事例では、こちらのパターンの方が多いと思われます)
例えば、システムのスループットが上がらずシステムの利用者の増加に耐えられないといった課題があり、原因を特定したらモノリシックなシステムの一部処理の負荷が高くボトルネックとなっていた。という話はよくある話だと思います。
このように現場サイドでシステムの改善ポイントが把握できている場合、現場から経営層へシステムの改善を提案していく流れはスモールスタートでアプローチしやすい方法です。
初めからシステムを丸ごとマイクロサービスを志向せず、既存のモノリシックなシステムの一部を外部に括りだし、モダンなマイクロサービスとして段階的に移行するアプローチは、「ストラングラーパターン」という手法として知られています。
Q5. サービスを分割して得られるメリットは何ですか？
サーバーアプリケーションの運用をする場合、これまでのようなモノリシックなシステムでのデプロイや問題発生時の調査のナレッジがあるのに対し、お世話をするサービスが増えたら運用が余計面倒になるんだけど大丈夫？というご意見の裏返しで使われる質問だと理解しています(笑)
答えは「ビジネス環境の変化に素早く追従できる」が最大のメリットだと理解しています。この目的に共感ができないのであれば、マイクロサービスを導入する意味はないと思います。
もう少し具体的に言いますと、以下のようになります。
- 機能が分割されることで、部分的な差し替えが可能
- システムの一部を部分的にスケールアウト可能
- バグ修正時などシステム無停止でアップデート可能
- システムアップデートの影響範囲把握がしやすくなる
- システムアップデートに問題があった場合、簡単に切り戻しが可能
- システム障害の影響が局所的になる(可能性が高い)
Q6. サービスが増えて運用が面倒になるのはものすごいデメリットでは？
もし数十～数百のサービスを全て人力で運用する場合、この疑問を持たれた方が想定したようにめちゃくちゃ大変になると思います。
ですが、マイクロサービスの導入と併せて利用することになるであろう様々なツールを活用した場合、(新しいツールの学習コストはかかりますが)従来と同程度の手間で運用できるくらいに洗練されてきているように思います。
少なくともアプリのデプロイに関しては、CI/CDツールによる自動化でどんどん人力運用が少なくなっていくでしょうし、監視/デバッグ/性能分析などは、AWSがCloudWatch Container InsightやX-Rayで監視/デバッグ/分析ツールをリリースしたり、現在進行形でどんどん便利になっていくと私は見ています。
現在は過渡期で各社バラバラな感じですが、いずれはKubernetesのエコシステムで各社共通になってくれれば一番うれしいですが・・・。
Q7. サービスの分割粒度ってだいたいどのくらいになるの？
先行されている企業の事例紹介は多くあれ、具体的にどのくらいの粒度で分割されているか？という事例の紹介が少ないように思います。
いろいろググっていたらこちらの記事を見つけましたのでご紹介します。
このECサイトのサンプル事例は主にデータドリブンな分割になっているようですが、Orderサービスなどはドメイン駆動設計による分割だと理解しています。
こちらの記事では以下のように言われています。
Microserviceにおけるサービスは単一の責任を持ち、明確で簡潔な役割を持つシステム全体のうちの1コンポーネント。
「単一の責任を持っている」というのが重要かと思います。マイクロサービスにあれこれ責任を持たせすぎると、それはモノリス化の始まりになります。
また、マイクロサービスひとつの規模を推し量る材料として、「ひとつのマイクロサービスに携わる開発チームの目安」としては「ピザ2枚分で足りる人数」がよいとされています。
法律ではないので厳密に合わせる必要もありませんが、このくらいの規模感で分割すれば上手くいく可能性が高いと思われます。
Q8. マイクロサービスって学習コストが高いんでしょ？
これもよく聞く話でして、学習コストが高いという事でマイクロサービスの導入に二の足を踏むプロジェクトは多いと思いますし、実際に学習コストは高いと思いますので計画的に身に着ける必要があります。
役割毎に何を学習するのかを明確にすると以下のようなイメージです。
システムのオーナー・・・開発チームと一体となった開発スタイルの受け入れ
開発チーム・・・新しいツールや設計手法の確立
それぞれ覚えることはたくさんありますが、開発チームが覚えるべきことは前回の記事で整理したので、今回は開発スタイル(文化)のお話をします。
マイクロサービスの開発では各マイクロサービス毎に開発チームを割り当て、アジャイルで開発を回す事が多いと思われます。
このようなスタイルでは、チームの中に業務がわかるプロダクトオーナーの存在が不可欠です。
これまでは仕様書ベースのやり取りでシステムのゴールを共有するウォーターフォール型の開発スタイルでしたが、マイクロサービスの開発(+アジャイル開発)では開発者とプロダクトオーナーが「実際に動くシステム」を見ながら開発を進めるスタイルに変える必要があると思います。こうすることで、最小限の構成から必要な機能を吟味し(≒無駄なものを作らず)、開発のスピード感を維持すると言ったことが実現できます。
新しい開発スタイルを受け入れることによって、学習コストに見合ったビジネス的なリターンを得る形がDXの文脈では重要だと思います。
もちろんマイクロサービス群の一部が変化が少ないことがわかっている場合、部分的にウォーターフォールを採用するケースもありえます。
Q9. マイクロサービスの開発を簡単にするためのフレームワークってありますか？
私の理解ではマイクロサービス構築のためのアプリケーション層のフレームワークとして、普及期にあるものはまだないという理解です。
MS社がマイクロサービス開発を容易にする「Dapr」をオープンソースで公開したのはつい最近ですし、これから徐々にハイレベルなフレームワークが出てきてしのぎを削るようになると思われます。
また、マイクロサービスを支えるインフラ層についてはAzure Service FabricやAWS Fargateなどがあり、IaaSなどのインフラの管理が隠蔽され、マイクロサービス導入障壁を下げることができ、アプリ開発者はサービスの開発に集中できるとされています。
ですが、あくまでサービスの実行環境の構築簡易化にとどまるため、マイクロサービス特有のサービス間を連携させるための設計については、アプリケーション開発者がケアする必要があります。
このようなインフラの採用にあたっては、情報システムの運用などがクラウドベンダー独自仕様となり、クラウドベンダーをまたいで移行するときの移行コストに跳ね返る可能性がある点にご注意ください。
Q10. マイクロサービスは必ずクラウド上で運用しなければならないのか？
現行の基幹システムがオンプレミスで構築されていて、アーキテクチャの刷新とともにクラウドへの移行という流れに乗る必要があるのか？を想定したご質問でした。
結論から言えば、必ずクラウド上でなくてはならないわけではなく、オンプレミスでも動かすことは可能ですし、クラウドへの移行はコスト試算をしたうえで段階的に行うことになると想定します。
意味があるかどうかは別として、以下の条件でアプリを開発していれば、クラウドであろうが、オンプレミスであろうが、どちらでも動かすことは可能です。
- 業務アプリはDockerコンテナとしてパッケージングする
- コンテナオーケストレーション基盤としてKubernetesを利用する
- メッセージキューやRDBなどがオンプレミス上に構築できる
- CPUがインテルアーキテクチャである
ですが、オンプレミスの場合は、以下の点にご注意ください。
- ハードウェアリソースを簡単に拡張することができないので、情報システムの利用者が増加した場合のスケーリングが簡単にはできない
- 実行基盤で使われるKubernetesなどのアップデートが自己管理になるため、運用時のOSSバージョンアップなどのコスト面の配慮が必要
オンプレミスかクラウドかの選択はゼロ/イチではなく、ハイブリッド構成という選択肢もありますので、適材適所で選んでコストの最適化をすべきだと思います。
さいごに
私もマイクロサービス関連の記事を読みまくってて思うのですが、文章で伝わりにくいことも実践をしてわかることの方が大きいと感じています。またマイクロサービス自体「なんでもできる万能アーキテクチャ」ではなく向き不向きもあります。
単にマイクロサービス化することが目的になってしまうと、苦労した割に効果が得られないことにもつながります。
今回の10の質問以外にも不安を感じるところはあると思いますが、適用して効果が出そうだと思ったら、マイクロサービスの実践を通し、エンジニアとしての新しい技術や知見を身に着けビジネスに生かしていくことをオススメします。
参考記事
- 「南波先生のSOAってそういうことだったのね講座」連載一覧：EnterpriseZine（エンタープライズジン）
- 「マイクロサービス」のメリットをざっくり言うと「変化に対応しやすい」こと──ただしファウラー氏は“使い過ぎ”を警告 | さくらのナレッジ
- PayPayはなぜマイクロサービスアーキテクチャを採用したのか？ 決済プラットフォームの構成と狙いを解説 - ログミーTech
- 今さらながら、エンタープライズ・アーキテクチャ（EA）を学んでいる - Muranaga's View
- デジタル時代に改めて脚光浴びる「EA」、その理由と活用指針を米Gartnerに聞く | IT Leaders
- ストラングラーパターン：段階的なシステム移行 - VELTRA Engineering - Medium
- ECにおけるマイクロサービス分割を考察する - dskst's diary
- 単純なデータ ドリブン CRUD マイクロサービスの作成 | Microsoft Docs
- マイクロサービスの粒度 - Qiita
- ハイブリッドクラウドの需要は続くも、オンプレミスも再評価 今後は“クラウド＆オンプレ＆ハイブリッド”を視野に――IDC調べ - ITmedia エンタープライズ
- ドメイン駆動設計の正しい歩き方