マイクロサービスが必要な理由とは？ 導入ロードマップやよくある落とし穴
※本記事は2020年10月に公開された内容です。
2020年10月22日に開催されたCTOmeetup。今回は新たにZoomウェビナーによる配信を実施し、よりわかりやすいディスカッションを目指しました。
テーマとなるのはマイクロサービス。マイクロサービス導入の必要性や成功の本質、ロードマップ、よくある落とし穴などについて、マイクロソフト・コーポレーションの寺田 佳央氏に対談形式でじっくり伺いました。自社サービスのマイクロサービス化を検討している方が押さえておきたいポイントが満載です。
目次
登壇者
なぜ、マイクロサービスの導入が必要なのか？
各社の事例から見える３つの要因
株式会社サーキュレーション FLEXY部 マネージャー 田崎 雄大さん（以下、田崎）：冒頭は、マイクロサービスの導入が必要とされる理由について私から簡単に触れ、その後寺田様とのセッションに移ります。
よくマイクロサービス導入のメリットとして挙げられるのは、一つはサービスごとに異なる技術を採用できる点です。言語やデータベースなどをサービスごとに使い分けることで、より強固なサービスを提供できます。
次が障害耐性、保守性の高さです。障害が起きた際に障害が発生している箇所の追求、リカバリーが早期にできるようになります。最後がサービスのスケール、冗長化が容易である点です。例えばユーザーや会員数の増加に応じてサービス自体も分割していくことで、サービスのスケールが図れます。
そもそもマイクロサービスとは？
田崎：マイクロサービスとは対比的な存在に位置するのが、モノリシックなサービスです。これは複数のサービスの中身が全て結合されており、一つのデータベースで成り立っているようなサービスを指します。モノリスでは、先程挙げたようなマイクロサービスのメリットを享受できない環境が生まれがちです。
対してマイクロサービスは、それぞれのサービスやビジネスのロジックで全体を組み合わせ、データベースも分けて処理する考えが前提にあります。
マイクロサービスは2014年頃から提唱されはじめたソフトウェアアーキテクチャの一つであり、日本の名だたるベンチャー企業が導入し、事例を公開したことによって流行してきました。
一方、他社事例を参考にマイクロサービスを導入してみたものの失敗してしまった事例は数多く見受けられますし、私自身もいくつかご相談を受けた経験があります。失敗事例におけるマイクロサービス導入の理由を深堀りしてみると、以下のようなものでした。
- デプロイ時の障害や停止時間を減らしたい
- サーバー負荷を分散させたい
- ソースコードがスパゲティになっているので解きほぐしたい
- 予測できない将来の改修に備えたい
- 今風の技術を取り入れることで人材採用のセールスポイントにしたい
一見するとマイクロサービス導入のメリットと同じなのですが、本当にマイクロサービス化が解決手段なのかという疑問が残りますし、実際に失敗してしまっています。
そこで今回表題にもあるように、マイクロサービスという手段が目的化していないだろうか、という視点で寺田様とディスカッションできればと思っています。よろしくお願いします。
マイクロサービス導入の成功の本質
田崎：最初にマイクロサービスの成功の本質として、3つの要素を挙げました。この中で特に一つ注目するとしたらどういう部分になるのでしょうか？
Microsoft Corporation Sr. Cloud Advocate 寺田 佳央さん（以下、寺田）：この後いろいろとお話しさせていただきますが、マイクロサービスはやはり「ビジネスを成功させるために使うかどうか」だと思っています。会社において一番重要なのは、ビジネスをどんどん前へ進める、もしくは開発や運用をやりやすくしていくことです。その手段としてのマイクロサービスですから、「マイクロサービスを成功させよう」というよりは、「ビジネスを成功させよう」ということになります。
田崎：第一がビジネス課題、そして多面的なコスト把握や、組織環境とエンジニアの技術理解ということですね。今回はどういった点にフォーカスしてお話しいただけるのでしょうか？
寺田：課題解決のソリューションは決して一つではありません。そのときになぜマイクロサービスを利用するのか、という点をお伝えしたいです。
そしてマイクロサービスを導入するにしても、順序立てて行動しないと先には進めません。「課題解決のプロセスの先にあるのがマイクロサービスである」と考えたほうが良いかと思いますので、その視点でいろいろとご紹介します。
成功するマイクロサービス導入のロードマップ
導入の起点となる判断基準は新規かマイグレーションか
田崎：今回、寺田様にマイクロサービスのお話をしていただきたいとお伝えしたとき、「それは新規かマイグレーションか」というご質問をいただきました。つまり、ここがマイクロサービス導入における起点となるのだと思ったのですが、このあたりについて少し補足説明をいただけますか？
寺田：2014年頃から世界でマイクロサービスが登場して以来、私もいろいろな情報をキャッチアップして学びや経験を重ねてきました。
マイクロサービスには多様なデザインパターンが提供されていますし、具体的な成功例やベストプラクティスもグローバル規模で多数あるのですが、これらの多くが新規でマイクロサービスを構築した場合の事例です。既存のモノリシックなエンタープライズアプリケーションをマイクロサービス化した話ももちろんありますが、まだまだ少ないのが現状です。私の感覚では、少ないというよりも事例が出せない状態であり、ベストプラクティスも存在しないと言い切っていいと思っています。企業が現在置かれているシチュエーションや開発しているアプリケーションはそれぞれ全く異なっているので、そこに対するベストプラクティスは無いんです。
なので、私がマイクロサービスに関わるときは、新規かマイグレーションかとお伺いします。新規の場合は既にあるデザインパターンを適用したほうが良いのですが、マイグレーションに関しては今までの開発プロセスや運用方法全てをひっくるめて考えなければいけませんし、技術者のスキルも大きく影響します。
実際、あれだけ優秀なエンジニアを抱えているNetflixさんでさえ、既存のモノリスからマイクロサービスに移行するには5年もの年月がかかりました。マイグレーションは非常に難しいものと考えたほうがいいでしょう。
成功する導入選択ストーリー
田崎：難しいものであるという前提がありつつも、なんとかロードマップを引きたい、あるいはすでにマイクロサービス化が決まっているという場合に、正解に近づくためにどのようなことを考慮していけばいいのかを紐解いていきたいと思います。
まず、成功する導入選択ストーリーとして３つのステップを設定しました。成功の要因を深堀りする形になるかと思いますが、早速ステップ１からお話しいただけますか？
Step１．ビジネス課題の明確化
寺田：企業にとって重要なのは、売上や顧客数の拡大、さらにUXの向上や新規事業の創出、リードタイムの短縮などです。現在はデジタル・ディスラプションという、デジタルによって既存ビジネスが破壊されるという意味の言葉も出てきているように、企業にとって一番のリスクは現状に留まることにあると言えます。その場に立ち止まっていると、現在提供しているものよりもデジタルの力を使ったより便利な商品・サービスが提供された際に、ユーザーは一気にそちらに流れてしまうからです。
これは業種を問わずビジネスのさまざまな場面で起こり得ることなので、既存の企業は次のビジネスチャンスを生み出すために新たなチャレンジをしたり、他社に先んじた取り組みをしなければいけません。
田崎：今回はマイクロサービスというテクノロジーを主題としましたが、経営や事業の方向性といった部分がファーストステップになるんですね。
寺田：まずは、会社自体が新しいことにチャレンジしたい、変化したいと思っているのかどうかが大きな出発点です。チャレンジが重要だと考えているなら、たとえ失敗してもそれを乗り越えて成功させたいという気持ちを持ち続けられます。そういった思いが無いと、難題に直面したときに乗り越えられません。
Step2．コストバランスの設定
田崎：ビジネス課題を十分に議論した次のステップとして、コストバランスの設定を挙げさせていただきました。どういうところにどんなお金がかかるのかイメージがつかない場合もあると思いますが、このあたりはいかがでしょうか。
寺田：初期コストだけではなく、運用や教育コストなどをトータルで考える必要があります。コストに加えて大切なのが期間ですね。いつまでにどれだけの予算を投じるのか、期間とコストの両方を考えながら採用技術を選定しなければいけません。
仮にビジネス課題を達成すべき期間が完全にフィックスされている状態なら、今までチャレンジしたことのない開発手法はリスクになるので選ばないほうがいいと思います。それよりも、今技術者ができることで最短の方法を選ぶのをおすすめします。マイクロサービスはもちろんのこと、インフラに関しても例えば無理にKubernetesを選ばずとも、IaaSでもPaaSでもいいんです。なぜなら、次の段階で出てくるのが教育コストだからです。短期間のプロジェクトに教育コストはなかなかかけられませんから、今できる技術でやってくという判断になります。
サービスにとって何が重要なのか、初期費用だけでなく運用コスト、教育コストまで含めるのか、それらをどういう期間で見るのかによって、マイクロサービスができる・できないが決まるということです。
Step3．開発組織と技術
田崎：コストや期間の大体の見積もりが取れたところで技術や組織の話が出てくるということですが、ここで注意すべき点はありますか？
寺田：「内製or外注」という項目がありますが、私自身は内製が良くて外注が悪いとは全く思っていません。自分たちのビジネス戦略のために、自分たちが主導権を握った状態で自社の人員では足りない部分を外注するのであれば、なんら問題ありません。マイクロサービスに関しても、特定の部分だけを依頼することができるでしょう。ただし、全てを外注に丸投げするのは困難ですし、破綻します。
内製する場合は、TDDも含めてアジャイル的な開発体制にしている、ある程度の失敗をしても認めてもらえるような関係を上層部と築けているといった状態なら、かなりやりやすいと思います。一方、縦割りの組織で領域が分断されていたりすると、余計なプロセスや出戻りが発生してしまうでしょう。
企画や設計サイドが考えた案を実装側が作業しはじめたらやりづらいこともあります。その上で開発者からのフィードバックを受けてくれないといったことになると、会社として改善活動ができません。「何のために開発しているのか」という最初の段階に立ち返る必要があります。「企業のサービスをより良くしていく」というゴールに向かうのであれば、企画も開発も関係なく、開発プロセス全体をみんなで改善していくことができるはずです。
そのためにはエンジニア側のスキルが重要ですし、バリューストリームマッピングによって開発プロセスを見直し、リードタイムを短縮するといった取り組みが重要になります。
成功パターンの６つのステップ
田崎：ここまでお話しいただいた3つのステップがしっかり議論され尽くした上で、マイクロサービスが必要であるということになったら、ようやく採用技術の判断に入ります。このときどういうステップを踏むべきなのか、事前にお伺いしております。
疎結合化＆コードのクリーン化
田崎：既存サービスをマイグレーションする際に、疎結合化やコードのクリーン化を最初にやるべきとしていただきましたが、これはどのような背景からですか？
寺田：本当にマイグレーションできるかどうか、ここである程度判断ができると思います。例えば既存のアプリケーションをマイクロサービスに移行する際のデザインパターンの一つには、「ストラングラーパターン」というものがあります。簡単に言うと、モノリシックなシステムから特定の機能だけを外に切り出してサービス化し、徐々に移行する方法です。
ストラングラーパターンでマイクロサービス移行できるかどうかは、現在のアプリケーションの作りに大きく依存します。綺麗にモジュール化されており、サービスが疎結合な状態で実装されている場合は、かなり移行しやすいでしょう。 ですが、そもそもモノリスが綺麗に作られておらず、モジュールを一つ取り出したらどんな影響が出るかわからないとなると、相当難しくなります。開発者は「ストラングラーパターンは諦めて、ゼロから作り直したほうが早いかもしれない」と上層部に訴えたほうがいいかもしれません。
問題なく動いているシステムをゼロから作り直すのは二度手間ですし、上層部にとってはビジネス価値を見出すことができません。そこで、ここでもやはりビジネス的な課題に立ち戻り、何のためにマイクロサービスにすることにしたのか考え直す必要が出てきます。サービスに機能追加など変更を加えたいからこそマイクロサービスにするわけですから、全てを綺麗にマイクロサービスに移行するのではなく、より変更が加わりやすい部分をモノリスから見つけ出しましょう。そこを切り出すために苦労しなければいけません。例えばセッション情報が共有されていたら、まずセッション情報を外に出してVMを２つに分け、それぞれがきちんと動くようにする。そういった最初のステップから考えなければならなくなるので、疎結合化やコードのクリーン化は非常に重要です。
TDD：実装方法やアジャイルの導入
田崎：2点目を重視しているのはどのような理由からですか？
寺田：このあたりは当たり前のことなのですが、テストをやるにしても自動化すべきです。マイクロサービスをやっていくにしても、リーン・スタートアップ的な考えで小さなものを作っていち早く世の中に提供し、フィードバックを受けて改善するというサイクルを回していく必要があります。そのためにはきちんとどのフェーズにどの機能を実装するのかを明確にしていくアジャイル開発によって、スプリントを回すのが大前提になります。
田崎：運用の面で、今までと違う開発スタイルになったときに変えていかなければならない部分ということですね。
Infrastructure as a Code
田崎：3点目はいかがですか？
寺田：このあたりはみなさん言わずともわかっていらっしゃると思いますが、今までインフラは人の手を介してシステム構築をしていました。人の手が加われば加わるほどミスが生まれますから、開発環境やステージング環境、本番環境のいずれにしても、いち早く同じインフラを作れるようにしておくのが重要です。
12 Factor App
田崎：12 Factor Appについて全てはとても説明できないので、あえて挙げるべきポイントがあればご説明いただけますか？
寺田：クラウドネイティブ化するのが非常に重要なポイントです。ここで言いたいのはクラウドが一番いいということではなく、変化に強いサービスを作っていくべきだということです。
ほかにも12 Factor Appにある要素は大事なことばかりですが、一つピックアップしたいのが「並行性」です。これは、今まで動いていたサービスをどんどんスケールアウトしたいと思ったときに、より簡単にスケールアウトできるように作っておくべきだという話です。マイクロサービス同士でパフォーマンスを出そうと思ったら、開発者側は実は低レベルなことをきちんと理解しておかなければいけません。
例えば、プログラムを書く上で一番簡単なのは同期的なアプリケーションですが、それでは長時間待たなければならないので非同期化し、複数のスレッドで動かします。リソースのスレッドプールがいっぱいになってしまう場合は、スレッドプールで処理を待ち続ける部分にノンブロッキングを実装する。このように、プログラムレベルでの改善ポイントは非常に多くあります。ノンブロッキングというとリアクティブという言葉が出てくると思いますが、これは簡単に言えば非同期かつノンブロッキングで実装し、バックプレッシャーと呼ばれる負荷に耐えられるシステムを作ろうということです。
プログラムの実装レベルでもパフォーマンスが必要な部分はしっかりと考えて作らないと、単純にサービスを分割して呼び出し合っていたらパンパンになってしまい、呼び出し側まで倒れてしまうということもあり得ます。
田崎：ありがとうございます。ここまでの流れの中でさらにDevOpsが登場し、開発者のみならずビジネスを巻き込んだ後にようやくマイクロサービスにたどり着くのだと理解しております。
マイクロサービス導入でよくある落とし穴
田崎：いろいろなステップを踏む中で陥りやすい、マイクロサービス導入の落とし穴についてもお話しいただければと思います。1はここまでのお話である程度イメージがつきますが、2と3についてはいかがでしょうか。
寺田：他社事例の中に、ノウハウとして自社でも活用できる部分はもちろんあるかと思います。しかし、個々の企業でやっていたことを自社でも同じようにやろうとすると、ほとんどのケースで失敗するのではないでしょうか。成功した企業には成功に到る要因となった人材や開発プロセスがあったからこそ成功したわけで、自社に全く同じものがあるわけではないからです。
特に私は、マイグレーションにおいては本当に必要な部分だけを移行すればいいと考えていますし、そもそもマイクロサービスは公開されているデザインパターンに固執しないことが重要です。例えば、マイクロサービスではよく１サービス１データベースのような形で作りましょうと言われます。しかし、既存のモノリシックなアプリケーションにおいて、何万というテーブルやカラムがあり、どのアプリケーションからどう参照されているのかもわからない状態では上手くいきません。そういう場合、私はデータベースやカラムの参照なんかには触らずに、サービスの実装部分だけ外に出すようにします。
方法論を知っておくことも綺麗なシステムを作ることも重要ではありますが、そこにこだわりすぎると立ち行かなくなってしまうので、自分たちにとって今何が必要で、そのために何ができるのかを考えるのが良いと思います。
田崎：他社事例というのはあくまで一つの参考であり、そこを目指すと本質からズレてしまう。さらに他社事例を参考にできるだけの技術力や経験が会社の中にあるのかというのも、見なければいけないポイントですね。
CTO meetup総括
田崎：最後に私から総括させていただきます。寺田様から再三言っていただいたように、マイクロサービス導入の第一の目的はビジネス課題の解決です。導入プロセスでは当然つらいこともありますから、目的を見失わないよう、立ち戻る場所としてのビジネス課題を組織のメンバー全員が押さえておくべきでしょう。
2点目は、目指すべき目標に対して必要なコストを把握してきちんと折り込むこと。最後が、組織環境とエンジニアの技術理解です。目的やコストをしっかり設定したとしても、それが果たして現状の組織でできるのか、技術理解はあるのかどうかを判断すべきです。不足しているなら外部から知見を借りる、協力会社に頼るといった手法も考えられるでしょう。
以上でセッションは終了させていただきますが、寺田様から最後に伝えたいことはありますか？
田崎：ビジネスの成功のためにマイクロサービスがあるとお話しさせていただきましたが、だからマイクロサービスをやればいいとは全く考えていません。Kubernetesなんかも流行っていますが、マイクロサービスやKubernetesはいずれもビジネス成功のための手段です。本当に重要なのは、ビジネスを成功するために何を使うのが最適を考えることです。ぜひ一つずつ改善を積み重ね、ビジネスを成功させていただければうれしく思います。
また、Microsoftでは、テクノロジーに関するオンデマンドのウェビナーをいろいろとご用意しています。初心者の方が取り組んでいただけるようなコンテンツを提供しておりますので、ぜひ会社の同僚や後輩、技術者の方々に紹介して、Azureのテクノロジーをキャッチアップしていただけたら幸いです。本日はありがとうございました。
企画/編集: FLEXY編集部（加来）
マイクロサービス関連記事のご紹介
ここからはマイクロサービス関連の記事をご紹介します。
マイクロサービスアーキテクチャの特徴
こちらの記事ではマイクロサービスアーキテクチャとは？という基礎的な部分から、メリットやデメリットなどの解説までしています。
マイクロサービスの成功と失敗事例
こちらの記事ではマイクロサービスの導入目的は？という基本に立ち返りながら、成功に必要な要素や運用上の課題とその克服の仕方などをまとめて解説しています。
まとめ
今回は、マイクロサービス導入の必要性や成功の本質、ロードマップ、よくある落とし穴などについて、マイクロソフト・コーポレーションの寺田 佳央氏に伺いました。お話の中にもありましたように、ぜひ一つずつ改善を積み重ね、ビジネスを成功させていただければ幸いです。
■FLEXYのご紹介
FLEXYは、エンジニア、技術顧問、CTO、デザイナーの方向けに案件をご紹介するサービスです。
リモートワークや週1-5日、高単価案件など、ご希望に合った案件をご紹介いたしますので、是非お気軽にご相談ください。
