手段を目的化させない! マイクロサービスが必要な理由を改めて考える。

2020年10月22日に開催されたCTOmeetup。今回は新たにZoomウェビナーによる配信を実施し、よりわかりやすいディスカッションを目指しました。

テーマとなるのはマイクロサービス。マイクロサービス導入の必要性や成功の本質、ロードマップ、よくある落とし穴などについて、マイクロソフト・コーポレーションの寺田 佳央氏に対談形式でじっくり伺いました。

自社サービスのマイクロサービス化を検討している方が押さえておきたいポイントが満載です。

登壇者

寺田佳央
寺田 佳央氏|Microsoft Corporation Sr. Cloud Advocate

サン・マイクロシステムズ所属時から日本における Java の普及活動を行う。現在はマイクロソフト・コーポレーションに所属しクラウド・アドボケイトとして、Java on Azure の利用促進・啓蒙活動を実施中。2016 年 7 月、日本人で 2 人目となる Java Champion に就任し、日本 Java ユーザ・グループの幹事でもある。
田崎
田崎 雄大氏|株式会社サーキュレーション FLEXY部 マネージャー

新卒でSierとして某カード会社システムの運用開発を担当。 入社4年目以降は次世代システムへの切り替え、システムリリース後のバグ改修を担当(主な開発言語はJava)。 その後、縁あってHR系企業に入社し、前職の経験を生かしてIT領域のCA兼RAとして、採用・転職の支援。一貫してエンジニア採用に関わり続け、2000社以上の企業の採用に関わる。 得意領域はスタートアップ系企業、Web系企業など拡大期の支援をメインに求人作成、エンジニア向けイベントの企画、等を行う。

なぜ、マイクロサービスの導入が必要なのか?

各社の事例から見える3つの要因

株式会社サーキュレーション FLEXY部 マネージャー 田崎 雄大さん(以下、田崎):冒頭は、マイクロサービスの導入が必要とされる理由について私から簡単に触れ、その後寺田様とのセッションに移ります。

よくマイクロサービス導入のメリットとして挙げられるのは、一つはサービスごとに異なる技術を採用できる点です。言語やデータベースなどをサービスごとに使い分けることで、より強固なサービスを提供できます。

次が障害耐性、保守性の高さです。障害が起きた際に障害が発生している箇所の追求、リカバリーが早期にできるようになります。 最後がサービスのスケール、冗長化が容易である点です。例えばユーザーや会員数の増加に応じてサービス自体も分割していくことで、サービスのスケールが図れます。

そもそもマイクロサービスとは?

田崎:マイクロサービスとは対比的な存在に位置するのが、モノリシックなサービスです。これは複数のサービスの中身が全て結合されており、一つのデータベースで成り立っているようなサービスを指します。モノリスでは、先程挙げたようなマイクロサービスのメリットを享受できない環境が生まれがちです。

対してマイクロサービスは、それぞれのサービスやビジネスのロジックで全体を組み合わせ、データベースも分けて処理する考えが前提にあります。

マイクロサービス

マイクロサービスは2014年頃から提唱されはじめたソフトウェアアーキテクチャの一つであり、日本の名だたるベンチャー企業が導入し、事例を公開したことによって流行してきました。

一方、他社事例を参考にマイクロサービスを導入してみたものの失敗してしまった事例は数多く見受けられますし、私自身もいくつかご相談を受けた経験があります。失敗事例におけるマイクロサービス導入の理由を深堀りしてみると、以下のようなものでした。

・デプロイ時の障害や停止時間を減らしたい
・サーバー負荷を分散させたい
・ソースコードがスパゲティになっているので解きほぐしたい
・予測できない将来の改修に備えたい
・今風の技術を取り入れることで人材採用のセールスポイントにしたい

一見するとマイクロサービス導入のメリットと同じなのですが、本当にマイクロサービス化が解決手段なのかという疑問が残りますし、実際に失敗してしまっています。

そこで今回表題にもあるように、マイクロサービスという手段が目的化していないだろうか、という視点で寺田様とディスカッションできればと思っています。よろしくお願いします。

マイクロサービス導入の成功の本質

マイクロサービス

田崎:最初にマイクロサービスの成功の本質として、3つの要素を挙げました。この中で特に一つ注目するとしたらどういう部分になるのでしょうか?

Microsoft Corporation Sr. Cloud Advocate 寺田 佳央さん(以下、寺田):この後いろいろとお話しさせていただきますが、マイクロサービスはやはり「ビジネスを成功させるために使うかどうか」だと思っています。会社において一番重要なのは、ビジネスをどんどん前へ進める、もしくは開発や運用をやりやすくしていくことです。その手段としてのマイクロサービスですから、「マイクロサービスを成功させよう」というよりは、「ビジネスを成功させよう」ということになります。

田崎:第一がビジネス課題、そして多面的なコスト把握や、組織環境とエンジニアの技術理解ということですね。今回はどういった点にフォーカスしてお話しいただけるのでしょうか?

寺田:課題解決のソリューションは決して一つではありません。そのときになぜマイクロサービスを利用するのか、という点をお伝えしたいです。

そしてマイクロサービスを導入するにしても、順序立てて行動しないと先には進めません。「課題解決のプロセスの先にあるのがマイクロサービスである」と考えたほうが良いかと思いますので、その視点でいろいろとご紹介します。

成功するマイクロサービス導入のロードマップ

導入の起点となる判断基準は新規かマイグレーションか

田崎:今回、寺田様にマイクロサービスのお話をしていただきたいとお伝えしたとき、「それは新規かマイグレーションか」というご質問をいただきました。つまり、ここがマイクロサービス導入における起点となるのだと思ったのですが、このあたりについて少し補足説明をいただけますか?

寺田:2014年頃から世界でマイクロサービスが登場して以来、私もいろいろな情報をキャッチアップして学びや経験を重ねてきました。

マイクロサービスには多様なデザインパターンが提供されていますし、具体的な成功例やベストプラクティスもグローバル規模で多数あるのですが、これらの多くが新規でマイクロサービスを構築した場合の事例です。既存のモノリシックなエンタープライズアプリケーションをマイクロサービス化した話ももちろんありますが、まだまだ少ないのが現状です。私の感覚では、少ないというよりも事例が出せない状態であり、ベストプラクティスも存在しないと言い切っていいと思っています。企業が現在置かれているシチュエーションや開発しているアプリケーションはそれぞれ全く異なっているので、そこに対するベストプラクティスは無いんです。

なので、私がマイクロサービスに関わるときは、新規かマイグレーションかとお伺いします。新規の場合は既にあるデザインパターンを適用したほうが良いのですが、マイグレーションに関しては今までの開発プロセスや運用方法全てをひっくるめて考えなければいけませんし、技術者のスキルも大きく影響します。

実際、あれだけ優秀なエンジニアを抱えているNetflixさんでさえ、既存のモノリスからマイクロサービスに移行するには5年もの年月がかかりました。マイグレーションは非常に難しいものと考えたほうがいいでしょう。

成功する導入選択ストーリー

田崎:難しいものであるという前提がありつつも、なんとかロードマップを引きたい、あるいはすでにマイクロサービス化が決まっているという場合に、正解に近づくためにどのようなことを考慮していけばいいのかを紐解いていきたいと思います。

マイクロサービス

まず、成功する導入選択ストーリーとして3つのステップを設定しました。成功の要因を深堀りする形になるかと思いますが、早速ステップ1からお話しいただけますか?

Step1.ビジネス課題の明確化

マイクロサービス

寺田:企業にとって重要なのは、売上や顧客数の拡大、さらにUXの向上や新規事業の創出、リードタイムの短縮などです。現在はデジタル・ディスラプションという、デジタルによって既存ビジネスが破壊されるという意味の言葉も出てきているように、企業にとって一番のリスクは現状に留まることにあると言えます。その場に立ち止まっていると、現在提供しているものよりもデジタルの力を使ったより便利な商品・サービスが提供された際に、ユーザーは一気にそちらに流れてしまうからです。

これは業種を問わずビジネスのさまざまな場面で起こり得ることなので、既存の企業は次のビジネスチャンスを生み出すために新たなチャレンジをしたり、他社に先んじた取り組みをしなければいけません。

田崎:今回はマイクロサービスというテクノロジーを主題としましたが、経営や事業の方向性といった部分がファーストステップになるんですね。

寺田:まずは、会社自体が新しいことにチャレンジしたい、変化したいと思っているのかどうかが大きな出発点です。チャレンジが重要だと考えているなら、たとえ失敗してもそれを乗り越えて成功させたいという気持ちを持ち続けられます。そういった思いが無いと、難題に直面したときに乗り越えられません。

Step2.コストバランスの設定

マイクロサービス

田崎:ビジネス課題を十分に議論した次のステップとして、コストバランスの設定を挙げさせていただきました。どういうところにどんなお金がかかるのかイメージがつかない場合もあると思いますが、このあたりはいかがでしょうか。

寺田:初期コストだけではなく、運用や教育コストなどをトータルで考える必要があります。コストに加えて大切なのが期間ですね。いつまでにどれだけの予算を投じるのか、期間とコストの両方を考えながら採用技術を選定しなければいけません。

仮にビジネス課題を達成すべき期間が完全にフィックスされている状態なら、今までチャレンジしたことのない開発手法はリスクになるので選ばないほうがいいと思います。それよりも、今技術者ができることで最短の方法を選ぶのをおすすめします。マイクロサービスはもちろんのこと、インフラに関しても例えば無理にKubernetesを選ばずとも、IaaSでもPaaSでもいいんです。なぜなら、次の段階で出てくるのが教育コストだからです。短期間のプロジェクトに教育コストはなかなかかけられませんから、今できる技術でやってくという判断になります。

サービスにとって何が重要なのか、初期費用だけでなく運用コスト、教育コストまで含めるのか、それらをどういう期間で見るのかによって、マイクロサービスができる・できないが決まるということです。

Step3.開発組織と技術

マイクロサービス

田崎:コストや期間の大体の見積もりが取れたところで技術や組織の話が出てくるということですが、ここで注意すべき点はありますか?

寺田:「内製or外注」という項目がありますが、私自身は内製が良くて外注が悪いとは全く思っていません。自分たちのビジネス戦略のために、自分たちが主導権を握った状態で自社の人員では足りない部分を外注するのであれば、なんら問題ありません。マイクロサービスに関しても、特定の部分だけを依頼することができるでしょう。ただし、全てを外注に丸投げするのは困難ですし、破綻します。

内製する場合は、TDDも含めてアジャイル的な開発体制にしている、ある程度の失敗をしても認めてもらえるような関係を上層部と築けているといった状態なら、かなりやりやすいと思います。一方、縦割りの組織で領域が分断されていたりすると、余計なプロセスや出戻りが発生してしまうでしょう。

企画や設計サイドが考えた案を実装側が作業しはじめたらやりづらいこともあります。その上で開発者からのフィードバックを受けてくれないといったことになると、会社として改善活動ができません。「何のために開発しているのか」という最初の段階に立ち返る必要があります。「企業のサービスをより良くしていく」というゴールに向かうのであれば、企画も開発も関係なく、開発プロセス全体をみんなで改善していくことができるはずです。

そのためにはエンジニア側のスキルが重要ですし、バリューストリームマッピングによって開発プロセスを見直し、リードタイムを短縮するといった取り組みが重要になります。

成功パターンの6つのステップ

田崎:ここまでお話しいただいた3つのステップがしっかり議論され尽くした上で、マイクロサービスが必要であるということになったら、ようやく採用技術の判断に入ります。このときどういうステップを踏むべきなのか、事前にお伺いしております。

マイクロサービス

疎結合化&コードのクリーン化

田崎:既存サービスをマイグレーションする際に、疎結合化やコードのクリーン化を最初にやるべきとしていただきましたが、これはどのような背景からですか?

寺田:本当にマイグレーションできるかどうか、ここである程度判断ができると思います。例えば既存のアプリケーションをマイクロサービスに移行する際のデザインパターンの一つには、「ストラングラーパターン」というものがあります。簡単に言うと、モノリシックなシステムから特定の機能だけを外に切り出してサービス化し、徐々に移行する方法です。

ストラングラーパターンでマイクロサービス移行できるかどうかは、現在のアプリケーションの作りに大きく依存します。綺麗にモジュール化されており、サービスが疎結合な状態で実装されている場合は、かなり移行しやすいでしょう。 ですが、そもそもモノリスが綺麗に作られておらず、モジュールを一つ取り出したらどんな影響が出るかわからないとなると、相当難しくなります。開発者は「ストラングラーパターンは諦めて、ゼロから作り直したほうが早いかもしれない」と上層部に訴えたほうがいいかもしれません。

問題なく動いているシステムをゼロから作り直すのは二度手間ですし、上層部にとってはビジネス価値を見出すことができません。そこで、ここでもやはりビジネス的な課題に立ち戻り、何のためにマイクロサービスにすることにしたのか考え直す必要が出てきます。 サービスに機能追加など変更を加えたいからこそマイクロサービスにするわけですから、全てを綺麗にマイクロサービスに移行するのではなく、より変更が加わりやすい部分をモノリスから見つけ出しましょう。そこを切り出すために苦労しなければいけません。例えばセッション情報が共有されていたら、まずセッション情報を外に出してVMを2つに分け、それぞれがきちんと動くようにする。そういった最初のステップから考えなければならなくなるので、疎結合化やコードのクリーン化は非常に重要です。

TDD:実装方法やアジャイルの導入

田崎:2点目を重視しているのはどのような理由からですか?

寺田:このあたりは当たり前のことなのですが、テストをやるにしても自動化すべきです。マイクロサービスをやっていくにしても、リーン・スタートアップ的な考えで小さなものを作っていち早く世の中に提供し、フィードバックを受けて改善するというサイクルを回していく必要があります。そのためにはきちんとどのフェーズにどの機能を実装するのかを明確にしていくアジャイル開発によって、スプリントを回すのが大前提になります。

田崎:運用の面で、今までと違う開発スタイルになったときに変えていかなければならない部分ということですね。

Infrastructure as a Code

田崎:3点目はいかがですか?

寺田:このあたりはみなさん言わずともわかっていらっしゃると思いますが、今までインフラは人の手を介してシステム構築をしていました。人の手が加われば加わるほどミスが生まれますから、開発環境やステージング環境、本番環境のいずれにしても、いち早く同じインフラを作れるようにしておくのが重要です。

12 Factor App

田崎:12 Factor Appについて全てはとても説明できないので、あえて挙げるべきポイントがあればご説明いただけますか?

マイクロサービス

寺田:クラウドネイティブ化するのが非常に重要なポイントです。ここで言いたいのはクラウドが一番いいということではなく、変化に強いサービスを作っていくべきだということです。

ほかにも12 Factor Appにある要素は大事なことばかりですが、一つピックアップしたいのが「並行性」です。これは、今まで動いていたサービスをどんどんスケールアウトしたいと思ったときに、より簡単にスケールアウトできるように作っておくべきだという話です。マイクロサービス同士でパフォーマンスを出そうと思ったら、開発者側は実は低レベルなことをきちんと理解しておかなければいけません。

例えば、プログラムを書く上で一番簡単なのは同期的なアプリケーションですが、それでは長時間待たなければならないので非同期化し、複数のスレッドで動かします。リソースのスレッドプールがいっぱいになってしまう場合は、スレッドプールで処理を待ち続ける部分にノンブロッキングを実装する。このように、プログラムレベルでの改善ポイントは非常に多くあります。ノンブロッキングというとリアクティブという言葉が出てくると思いますが、これは簡単に言えば非同期かつノンブロッキングで実装し、バックプレッシャーと呼ばれる負荷に耐えられるシステムを作ろうということです。

プログラムの実装レベルでもパフォーマンスが必要な部分はしっかりと考えて作らないと、単純にサービスを分割して呼び出し合っていたらパンパンになってしまい、呼び出し側まで倒れてしまうということもあり得ます。

田崎:ありがとうございます。ここまでの流れの中でさらにDevOpsが登場し、開発者のみならずビジネスを巻き込んだ後にようやくマイクロサービスにたどり着くのだと理解しております。

マイクロサービス導入でよくある落とし穴

マイクロサービス

田崎:いろいろなステップを踏む中で陥りやすい、マイクロサービス導入の落とし穴についてもお話しいただければと思います。1はここまでのお話である程度イメージがつきますが、2と3についてはいかがでしょうか。

寺田:他社事例の中に、ノウハウとして自社でも活用できる部分はもちろんあるかと思います。しかし、個々の企業でやっていたことを自社でも同じようにやろうとすると、ほとんどのケースで失敗するのではないでしょうか。成功した企業には成功に到る要因となった人材や開発プロセスがあったからこそ成功したわけで、自社に全く同じものがあるわけではないからです。

特に私は、マイグレーションにおいては本当に必要な部分だけを移行すればいいと考えていますし、そもそもマイクロサービスは公開されているデザインパターンに固執しないことが重要です。例えば、マイクロサービスではよく1サービス1データベースのような形で作りましょうと言われます。しかし、既存のモノリシックなアプリケーションにおいて、何万というテーブルやカラムがあり、どのアプリケーションからどう参照されているのかもわからない状態では上手くいきません。そういう場合、私はデータベースやカラムの参照なんかには触らずに、サービスの実装部分だけ外に出すようにします。

方法論を知っておくことも綺麗なシステムを作ることも重要ではありますが、そこにこだわりすぎると立ち行かなくなってしまうので、自分たちにとって今何が必要で、そのために何ができるのかを考えるのが良いと思います。

田崎:他社事例というのはあくまで一つの参考であり、そこを目指すと本質からズレてしまう。さらに他社事例を参考にできるだけの技術力や経験が会社の中にあるのかというのも、見なければいけないポイントですね。

総括

マイクロサービス

田崎:最後に私から総括させていただきます。寺田様から再三言っていただいたように、マイクロサービス導入の第一の目的はビジネス課題の解決です。導入プロセスでは当然つらいこともありますから、目的を見失わないよう、立ち戻る場所としてのビジネス課題を組織のメンバー全員が押さえておくべきでしょう。

2点目は、目指すべき目標に対して必要なコストを把握してきちんと折り込むこと。最後が、組織環境とエンジニアの技術理解です。目的やコストをしっかり設定したとしても、それが果たして現状の組織でできるのか、技術理解はあるのかどうかを判断すべきです。不足しているなら外部から知見を借りる、協力会社に頼るといった手法も考えられるでしょう。

以上でセッションは終了させていただきますが、寺田様から最後に伝えたいことはありますか?

田崎:ビジネスの成功のためにマイクロサービスがあるとお話しさせていただきましたが、だからマイクロサービスをやればいいとは全く考えていません。Kubernetesなんかも流行っていますが、マイクロサービスやKubernetesはいずれもビジネス成功のための手段です。本当に重要なのは、ビジネスを成功するために何を使うのが最適を考えることです。ぜひ一つずつ改善を積み重ね、ビジネスを成功させていただければうれしく思います。

また、Microsoftでは、テクノロジーに関するオンデマンドのウェビナーをいろいろとご用意しています。初心者の方が取り組んでいただけるようなコンテンツを提供しておりますので、ぜひ会社の同僚や後輩、技術者の方々に紹介して、Azureのテクノロジーをキャッチアップしていただけたら幸いです。本日はありがとうございました。


企画/編集: FLEXY編集部(加来)


この記事を書いた人
FLEXY編集部
FLEXY編集部
ハイスキルIT人材への案件紹介サービス
FLEXYメディアは、テックメディアとしてテクノロジーの推進に役立つコンテンツを提供しています。FLEXYメディアを運営するのは、ITに関連するプロシェアリングサービスを提供するFLEXY。経営課題をITで解決するためのCTOや技術顧問のご紹介、ハイスペックエンジニアやクリエイターと企業をマッチングしています。【FLEXYのサービス詳細】求人を募集している法人様向け/お仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

FLEXYでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)