大きさよりも独立性
マイクロサービスは小さく作ろうとすると失敗する(1/2 ページ)
デジタルビジネスに取り組む企業が「マイクロサービス」に注目し始めている。マイクロサービスとは何か。ガートナーの飯島公彦氏が開発のポイントを語った。
アプリケーションを素早く作ってビジネスに生かしたいと考える企業が増えている。ガートナー ジャパンのアナリスト飯島公彦氏は、同社のイベント「エンタプライズ・アプリケーション戦略&アプリケーション・アーキテクチャ サミット 2017」において、そのために注目すべき手段として挙げたのが「マイクロサービス」アーキテクチャだ。独立性の高い小規模なサービス(マイクロサービス)を組み合わせてアプリケーションを開発する手法のことを指す。実際にマイクロサービスに取り組むユーザー企業も現れ始めており、ガートナーに対するマイクロサービスの問い合わせも増えているそうだ。「基幹システムをマイクロサービスで作りたいといった相談もあった」(飯島氏)ほどである。
デジタルビジネス時代のアプリケーション開発では、時代やビジネスの変化に俊敏に対応できる「アジリティ」(敏しょう性)が求められる。ユーザー企業がマイクロサービスに取り組む目的は、アプリケーションにアジリティを持たせることにあるだろう。
ただし飯島氏は「今までの開発手法にマイクロサービスを適用しても成功は難しい」と注意を促す。本稿では飯島氏の講演を基に、マイクロサービスのメリットおよび開発のポイントを、アジリティの実現という観点で紹介する。
マイクロサービスとは
マイクロサービスのメリットを紹介する前に、まずはマイクロサービスが何かを定義しておく必要がある。マイクロサービスとは、単に小さなアプリケーションを指すわけではない。飯島氏によると「単独で展開可能かつ疎結合なアプリケーションコンポーネント。『SOA』(サービス指向アーキテクチャ)と『ドメイン駆動設計』の組み合わせが基礎になる」という。カプセル化されたビジネスロジックやフレームワークの塊が自律的に稼働し、依存性の低い状態で連係する、開発サイクルの異なるモジュールのことだといえる。
具体的なメリットには「他のサービスの影響を受けずに変更やデリバリーが可能な点、これによって分散配置や複数バージョンの共存が可能な点、サービスモジュールごとに最適な開発言語や実行環境を選択可能な点、起動やスケールアウト/インが迅速にできる点」(飯島氏)などが挙げられる。全体が単一のモジュールでできているモノリシック(一枚岩)なアプリケーションの場合、複数の機能をまとめてデプロイし、変更を加えるときも依存性を意識する必要がある。どこか1カ所を修正するだけでも、他への影響に気を付けなければならないし、テストやデプロイにも時間がかかる。一方でマイクロサービスは、一つ一つが単機能になることで、マイクロサービスごとに目的に合ったプログラミング言語を選べ、都度デリバリーや変更が可能だ。
マイクロサービスのアーキテクチャ
飯島氏によるとマイクロサービスの設計思想には、「開発の俊敏性、デプロイの柔軟性、精緻な拡張性」があるという。「マイクロサービスを作るために、アプリケーションを小さく作るにはどうすればいいのかとよく質問されるが、問題は粒度の大きさではなく、アジリティを阻害する依存性を取り払うことにある。その結果、小さい単機能のアプリケーションができる」と説明する。
既存のモノリシックなアプリケーションをマイクロサービスに作り替える上でも、新規でマイクロサービスを作る上でも、依存性をどこに見いだすか、つまりモジュールをどこで分離するか、その境界の見極めがポイントだ。飯島氏がポイントとするのは「API、機能、サービスの組み合わせ、サービス間連係(コミュニケーション)、データ」の5つだ。
1つ目のAPIは特に重要なポイントである。マイクロサービスは多くの場合、APIを持つWebサービスとして公開される。このAPIがサービスの利用者と提供者、ユーザー企業の外と中を分ける境界となる。
2つ目の機能とは機能範囲のことだ。例えばホテルのWebサイトであれば、予約機能、空室状況を閲覧する機能、ポイントサービス機能など、幾つかの機能に分けられる。マイクロサービスではこうした機能単位の依存性を絶つ。
3つ目のサービスの組み合わせは、イベントの処理手順や実行順序のことだ。マイクロサービスではユーザーからリクエストを受けるモジュールが自律的に動作するように設計する。
4つ目のサービス間連係は、複数のサービスを組み合わせて実行する処理のことだ。マイクロサービスではこれらを非同期かつ並列に処理する。
5つ目のデータは、データベースをどこに置くかだ。マスターデータを共有する場合と、モジュールごとに分散してデータを管理する方法がある。
これら5つの要素について依存性を排除していけば、大きくモノリシックだったアプリケーションの粒度が自然と小さくなり、マイクロサービスへと仕上がるそうだ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー