SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

これなら分かる! エンジニアが知っておきたいIT業界用語

これなら分かる! マイクロサービス(入門編)~モノリスと比較した特徴、利点と課題


  • X ポスト
  • このエントリーをはてなブックマークに追加

マイクロサービスの課題

 ここまで、モノリスと比較してマイクロサービスが持つたくさんの利点を紹介してきました。ですが、もちろん良いことだけではなく、その構造が持つ明確な課題も存在します。3つの観点(通信、組織、構造)でまとめましたので、順に見ていきましょう。

課題(1)通信

 マイクロサービスはモノリスと比較し、一般にパフォーマンスが出にくい構造となっています。これは、異なる場所に配置された機能を通信により組み合わせるという仕組みから、避けられない特性と言えます。

 また、性能向上のため、各機能間は非同期通信とし、機能をまたがったトランザクション保証はしない(後続機能の処理完了を待たずにレスポンスを返す)のが基本です。よって、ユーザーに正常終了としてレスポンスを返した後に、実は後続処理がエラーとなっていた、というようなケースも、通常運用の範囲として設計を行います。その場合は後続機能が復旧後、時間差で帳尻を合わせるのがセオリーですが、このやり方は扱う業務の特性によって致命的になるケースがあります。例えば個人ユーザー向けの決済処理のような、再試行が難しい業務がそれです。このような場合はマイクロサービスではなく、トランザクション保証が容易なモノリスの方が一般に適していると言えます。

図10:課題(1)通信
図10:課題(1)通信

課題(2)組織

 マイクロサービスに関する解説では、しばしば「コンウェイの法則」について説明されます。コンウェイの法則とは「システムを設計するあらゆる組織は、必ず自らの組織のコミュニケーション構造に倣った構造の設計を生み出してしまう」という法則です。つまり、マイクロサービスを適用したアプリケーションを作るには、我々自体が個々の機能と同じように独立し、完結した組織でなければならないということを意味します。しかし現実として、業務における要員配置はスキル特性や企業の育成戦略などによって決められる場合が多く、必ずしもマイクロサービスというアーキテクチャ設計にあわせた柔軟な体制を作れるとは限りません。

 また、開発言語や製品を機能ごとに最適化できるのがマイクロサービスの利点でしたが、それはつまり、チームごとに独自文化が形成されることになるとも言えます。それは、あるチームで得たスキルがよそには通用しにくくなってしまい、企業戦略として要員のローテーションをしたくとも叶わないという事態にもつながるでしょう。また、あるチームが得たノウハウを共有することで組織全体の成長を狙っても、その内容が他チームの開発には意味を成さないというケースも出てきます。つまり、”人”や”知見”という重要資源の活用効率が低くなる懸念があるのです。

図11:課題(2)組織
図11:課題(2)組織

課題(3)アプリケーション構造

 マイクロサービスの適用により機能間の境界が明確になるため、影響範囲の局所化という点で保守開発が容易になることは、先に記したとおりです。しかしその一方で、モノリスとはまた違った難しさを持っています。

 マイクロサービスの利点を生かすには、機能の境界を適切に設定することが必須となります。本来一つの機能とすべきであった範囲を誤って分けてしまえば機能間の通信が大量に発生する要因となりますし、分けるべきであった機能を一つにしてしまえば保守性や再利用性などマイクロサービスのメリットとして挙げた項目を満たすことができません。適切な境界設定を行うには、業務の全体を見渡せるアーキテクトの存在が求められます。

 また、機能の独立性を高めたことにより独自発展が進みすぎてしまい、各機能で得られるユーザー体験がちぐはぐになってしまう可能性もあります。同一ユーザーが複数の画面を基に行う一連の業務の中で、使う機能によって表示内容や操作感が全く別のシステムのように異なってしまうとしたら、ユーザーにとって使いやすいとは言えません。

 さらに、ユーザー体験だけでなくシステムの開発においても、チームの独立性を高めたことで情報共有がなされず、知らぬ間に色々なチームが同種の実装を生み出してしまうなど、全体効率化がなされないケースもあります。

図12:課題(3)構造
図12:課題(3)構造

まとめ:マイクロサービスとは

 マイクロサービスとは、「複数の独立した機能を組み合わせることで、一つの処理を実現するアーキテクチャ」であると説明しました。単一機能で処理を実現するモノリスと異なり、別のマシンに配置される機能を組み合わせるというところが特徴です。多くの利点があり大手企業を含めたさまざまな開発現場で流行していますが、その構造には明確な課題も存在します。つまり、マイクロサービスとは「金のハンマー(=あらゆるシステムにおける最適解)」ではないということです。特性を理解し、自分たちの求めるアプリケーションに適しているかを見極めた上での選択が求められます。

次回について(活用編)

 今回の入門編でマイクロサービスの定義、構造、特徴までを理解することができました。次回は活用編として、マイクロサービスの適用に際しあわせて理解が必要となるインフラ技術や開発手法についての解説を行います。実際に活用を予定している開発者の方々はもちろん、技術者とのコミュニケーションや意思決定に向けて更に知識を深めたいという管理者層の方々にもおすすめできる内容です。お楽しみに。

修正履歴

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
これなら分かる! エンジニアが知っておきたいIT業界用語連載記事一覧
この記事の著者

西野 大介(SOMPOホールディングス株式会社)(ニシノ ダイスケ)

 SOMPOホールディングス株式会社デジタル戦略部(SOMPO Digital Lab)勤務。損保ジャパン日本興亜グループにおける先進技術の研究開発を担当。過去には基幹システムの開発にも従事し、SoR/SoE双方の開発において幅広い経験を持つ。本業以外では、CodeZineの連載をはじめ、国内/海外の各種カンファレンスへの登壇や企業向けの講演にてテクノロジー情報を幅広く提供している。主な登壇実績:IBM THINK(米ラスベガス)、Java Day Tokyo、IBM THINK Ja...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11055 2019/06/21 10:22

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング