大きさよりも独立性
マイクロサービスは小さく作ろうとすると失敗する（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
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分？ 不足する対策を16項目でチェック -
事例
[Wrike Japan 株式会社] 世界的な家電メーカーが実践する「クリエイティブプロセス効率化」の方法とは？ -
事例
[Wrike Japan 株式会社] 世界的テクノロジー企業に学ぶ、プロセス標準化とプロジェクト納品自動化の秘訣 -
事例
[Wrike Japan 株式会社] ソニー・ピクチャーズ テレビジョンに学ぶ、次世代サービスデリバリーのヒント -
事例
[Wrike Japan 株式会社] ソミック石川に学ぶ、ICT浸透後に直面した「工数管理」の課題と解決策
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Copilot」はなぜ放置される？ “議事録要約止まり”を脱する処方箋
-
2
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
3
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
4
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
5
「データストレージの活用方法」に関するアンケート
-
6
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは？
-
7
ANAが専用回線から移行した「NaaS」の全貌 ネットワーク準備が数カ月から数週間に
-
8
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
9
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
-
10
「プログラマー不要論」にThe Linux Foundationが示した答え
ホワイトペーパーランキング PR
-
1
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
2
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
4
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
5
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
ドラマで分かる、標的型攻撃メールの被害を受ける企業と回避できる企業の分岐点
-
9
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
10
少額減価償却資産が40万円未満へ拡大、令和8年度税制改正で押さえるべき変更点
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー