大きさよりも独立性
マイクロサービスは小さく作ろうとすると失敗する(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
-
製品資料
[株式会社フィックスターズ] 組み込み開発特有の課題も解消できる「AI活用」の秘訣とは? -
製品資料
[株式会社スタディスト] 食品ロスを解消して“利益の創出”を実現、その第一歩は何から始める? -
製品資料
[株式会社スタディスト] 段取り替え時間に差が生まれるのはなぜ? 作業を標準化する仕組み作りのコツ -
技術文書・技術解説
[Datadog Japan合同会社] 開発と運用の人員格差をどう埋める? DevOpsを実現するための実践ポイント -
製品資料
[サイバーソリューションズ株式会社] たった1回でサプライチェーンが破滅することも メール誤送信を確実に防ぐには
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
-
2
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
3
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
4
パッチなしで「今すぐサーバを落とせ」 Kiteworks異例警告の波紋
-
5
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
6
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
7
「サイバー犯罪株式会社」に潜入 現地調査で判明した“犯罪者求人”の実態
-
8
OpenAIやAnthropicでさえ制御不能 2026年夏「3大サイバー攻撃」の衝撃
-
9
Copilot導入で陥る“目的化”の落とし穴 定着の鍵は「作り込まない」こと
-
10
IT製品の導入に関するアンケート「セキュリティ」編
ホワイトペーパーランキング PR
-
1
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
2
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
3
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
4
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
5
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
6
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
7
Linux初心者でも知らないとまずい「RHEL」「SLES」の違いとは?
-
8
東大教授と考える、AI時代の「データ主権」「信頼性」「ガバナンス」の在り方
-
9
「IT史に名を残すシステム障害」8選
-
10
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー