マイクロサービス完全入門ガイド
この記事は9分で読めます。
日進月歩で進化するソフトウェア開発の世界では、従来型のレガシーアーキテクチャに代わって、マイクロサービスアーキテクチャを基盤とするモジュール型のアプローチの普及が進んでいます。
企業は、ビジネスニーズを満たすアジリティとスケーラビリティ、そして耐障害性の高いソリューションを求めており、マイクロサービスに基づくアプリケーション設計はデプロイの改善につながります。この記事では、マイクロサービスアーキテクチャの重要な概念や、メリットとデメリットについて説明します。
マイクロサービスのあらまし
マイクロサービスとは、大規模なアプリケーションのなかで特定の1つの機能のみを担う小型のサービスだと考えるとよいでしょう。例えば、動画共有アプリケーションであれば、動画のアップロード、トランスコード、ストリーミング、コメント、ユーザー管理の機能を、個別のマイクロサービスが担当します。
マイクロサービスは自己完結型です。つまり、個々のマイクロサービスを構成するコードベースとプロセスは、サービスごとに独立しています。このように、マイクロサービスは非集権的な性質を持ち、更新、スケーリング、メンテナンスが簡単です。開発者は、1つのサービスに修正を加えるときに、アプリケーション全体の再構築や再デプロイを行う必要がありません。例えば、新たな動画フォーマットが登場したときには、トランスコードのマイクロサービスのみをアップグレードすれば済みます。無関係なコンポーネントには影響が及びません。
マイクロサービスの3つの種類
1. コアマイクロサービス
コアマイクロサービスとは、アプリケーションの根幹をなすビジネス機能やビジネス処理を担う中心的なマイクロサービスのことです。例えば、eコマースアプリケーションであれば、商品カタログ、ユーザープロファイル、ショッピングカート、注文管理、決済処理などはコアマイクロサービスに該当します。
コアマイクロサービスは、本質的な価値をもたらす重要なアプリケーションロジックやデータ処理を実装しており、周辺を支えるその他のサービスと密接に連携して、エンドツーエンドのワークフローを実現します。コアマイクロサービスでは、機能追加のための更新が特に頻繁に行われ、ビジネスの観点から見て戦略的に重要です。
2. サポートマイクロサービス
その名前が示すとおり、これらのマイクロサービスはコアサービスの支えとなるサポート機能を提供します。例えば、監視、ロギング、設定、メッセージング、キャッシュ、認証、レート制限などを担います。サポートサービスは、ビジネス目標に直接寄与するわけではありませんが、サービス品質を向上させます。例えば、ヘルスチェックやパフォーマンス監視により、本番環境をプロアクティブに最適化できます。また、ロギングを一元化することで、問題のデバッグを迅速化します。さらに、メッセージキューは、スムーズなサービス間連携を実現します。サポートサービスは、製品よりもむしろインフラに主眼を置いています。
3. オーケストレーションマイクロサービス
オーケストレーションサービスでは、コアマイクロサービス同士の協調と、それによるアプリケーションフローの構築の管理・調整を行います。主な役割は次のとおりです。
- リクエストに応えるための複数のサービスのデータやレスポンスを集約する
- サービス間のリクエストやデータの流れを規定することで、ワークフローを実装する。
- サービスで障害が発生したときに再試行やフェイルオーバーを行い、耐障害性を確保する。
- ポリシー、統制、コンプライアンスをあらゆる環境に適用する。
こうしたオーケストレータサービスがあることで、マイクロサービス間の連携の複雑さが緩和されます。多数のコアサービス同士が直接連携するのではなく、コアサービスはいくつかのオーケストレータと連携します。こうして保守性が向上することで、サービス間通信をサービス自体の実装から抽象化できます。
マイクロサービスアーキテクチャのユースケース
動的なスケーラビリティ
マイクロサービスの重要なメリットの1つが、個別のサービスをニーズに応じてスケーリングできることです。モノリシックアプリケーションの場合、特定の関数のみで負荷が急増したときでも、すべてのコンポーネントを一律にスケーリングする必要があるため、リソースの無駄が生じます。マイクロサービスの場合、例えば動画の新規アップロードが急増したときには、自動スケーリングによって動画エンコーディングサービスのみを独立して拡張することで対処できます。無関係なサービスのスケーリングは必要ありません。きめ細かなスケーリングを通じて、コスト効率とパフォーマンスが向上します。
リリースをスピードアップ
モジュール型というマイクロサービスの特性を活かすことで、イテレーションのスピードアップや、新機能の継続的デリバリが可能になります。特定のサービスのみを対象として、変更のテストとデプロイをすばやく行うことができます。大規模なリグレッションテストは不要で、モノリシックなデプロイのリスクを排除できます。また、新バージョンを大規模にロールアウトする前に、カナリアテストとしてユーザーに向けて段階的にロールアウトすることもできます。これにより、イノベーションやバージョン更新のスピードが向上し、ユーザー体験が改善します。
テクノロジを柔軟に選択
マイクロサービスアーキテクチャでは、ニーズに最も適合するプログラミング言語やフレームワークをサービスごとに個別に選択できます。例えば、AIベースのレコメンドエンジンにPythonをトランザクションサービスにJavaを使用しても、整合性の問題は生じません。こうしてテクノロジスタックを柔軟に活用することで、開発者の生産性は向上し、さまざまな機能領域でイノベーションの速度が上がります。従来のモノリスは往々にして、テクノロジの選択に制約があります。
耐障害性
各サービスが独立していることから、1つのサービスで生じた障害が他のサービスに波及せず、アプリケーション全体として動作を継続させることができます。また、マイクロサービスに冗長性を持たせることで耐障害性も向上します。例えば、いずれかの決済サービスで障害が発生した場合でも、呼び出しを別のインスタンスにルーティングして、収益機会の損失を防ぐことができます。こうしたフォールトトレランスはミッションクリティカルな環境の支えになります。
明確な責任範囲
個々のマイクロサービスを小規模なチームが担当することで、機能の責任範囲がサービスの境界によって明確に分離されます。こうしたDevOpsモデルのもとで、各チームは特定のソリューションのイノベーションに専念できます。マイクロサービスの責任範囲は明確で、ビジネス価値に沿って技術的な意思決定が行われます。大規模なチームでモノリスを開発している場合、同じような速さでの適応は不可能です。
モノリシックとマイクロサービスのアーキテクチャの違い
密結合と疎結合
モノリシックアプリケーションはコンポーネント同士が密結合しています。つまり、UIレイヤー、ビジネスロジックレイヤ、データアクセスレイヤ、その他のコンポーネントは互いに結び付き、一体化している状態にあります。いずれか1つのモジュールに変更を加える場合でも、アプリケーション全体の再構築と再デプロイが必要になります。
一方、マイクロサービスは互いに独立した疎結合のサービスで構成されています。例えば、商品カタログのマイクロサービスは注文システムの内部実装に依存しません。このような分離構造のおかげで、サービスに変更を加えるときも、互いに影響を及ぼすことなく迅速な対応が可能になります。
きめ細かいスケーリング
モノリスの場合は、特定の関数で負荷が急増したときでも、共通のリソースプール全体をスケーリングすることになり、オーバープロビジョニングにつながります。マイクロサービスの場合は、該当するサービスのみスケールアップやスケールアウトを行うことで、インフラコストを削減できます。
更新が容易
モノリシックアプリケーションの場合、新バージョンをデプロイする前に広範な統合テストが必要です。いずれかのモジュールに変更を1つ加えただけでも、他のモジュールに影響が及ぶ可能性があります。一方、各サービスが独立しているマイクロサービスの更新は、影響を局所的にとどめることができるので、デリバリのスピードが向上します。
柔軟なテクノロジ
モノリスの場合、企業がJavaやNETのエコシステムに大きく依存していて、テクノロジの選択に制約があることが少なくありません。一方マイクロサービスでは、異なるテクノロジの組み合わせが可能です。例えば、モバイルアプリではJavaScriptを利用し、AIサービスではPythonを利用してアジリティを確保できます。
障害の分離
モノリスの場合、コンポーネントのバグがシステム全体の停止につながることがあります。マイクロサービスの場合、障害は分離されているため、システム停止なしで個別に対処できます。
一方、マイクロサービスでは分散システムも複雑化し、調整用のフレームワークが必要となります。加えて、複数のサービスにわたる分散トランザクションの監視とデバッグも課題となります。モノリスの場合、境界内ではこうしたオーバーヘッドを回避できます。
モノリスとマイクロサービスの違いをまとめます。モジュール型のマイクロサービスは、自動化と障害分離が重要な意味を持つような、複雑でスケーラブルなアプリケーションで役立ちます。モノリスは、コンポーネント間の調整がシンプルであることから、スコープが狭いアプリケーションに適しています。トレードオフを理解しておくことで、アーキテクチャに関する判断をより最適に下すことができるようになります。
マイクロサービスと他のテクノロジの連携
マイクロサービスとAPI
独立したマイクロサービス同士の効果的な連携を可能にするのは、明確に定義されたAPIです。HTTP上のRESTなどの標準的なプロトコルに従って、ウェブ技術を使用したサービス間通信が行われます。OpenAPI のような自己記述型の API 仕様では、APIの発見可能性と使いやすさが高まります。バージョン管理では、APIに追加された変更が既存の統合やクライアントに影響を及ぼすのを防ぐことができます。全体としては、接続の基本構造にあたるAPIを通じて、マイクロサービスのオーケストレーションの信頼性が確立されます。
マイクロサービスとコンテナ
コンテナでは、マイクロサービスのコード、設定、依存関係を軽量な仮想イメージにパッケージ化し、開発環境やテスト環境から本番環境まで、異なる環境間でのポータビリティを確保できます。こうしてデプロイに一貫性を持たせることは、継続的デプロイをサポートします。Kubernetesなどのコンテナオーケストレーションエンジンは、コンテナ化されたアプリケーションのプロビジョニング、スケーリング、ヘルスチェックに対処し、自動化の基盤となります。ネームスペースやクォータは、アクセス制御に役立ちます。
マイクロサービスとサービスメッシュ
サービスメッシュは、マイクロサービスの通信に伴う複雑な課題を制御するための専用インフラレイヤーです。例えば、接続の確立、再試行、ルーティング、セキュリティ、オブザーバビリティなどを扱います。Istioなどのオープンソースのツールでは、耐障害性のテスト、段階的ロールアウト、メトリクス取得などの機能を通じて、マイクロサービス間の通信の複雑さが抑えられ、信頼できるサービス間連携を容易に実現できる環境が整います。
マイクロサービスとSOAの違い
マイクロサービスは、モジュール型アーキテクチャに関する従来のSOAの考え方を進化させたものです。個別にデプロイ可能な非集権型のサービスを利用する形になっており、SOAのようなエンタープライズ規模の要素ではなく、製品の機能に沿ったサービスを使用します。また、マイクロサービスはミドルウェアでの自動化に重きを置いています。SOAはXML、SOAP、WS-*などのウェブサービス標準を使用するのに対し、マイクロサービスはRESTなどのより軽量なプロトコルを採用しています。全体として見ると、マイクロサービスはSOAのメリットにさらなる強みを加え、継続的デリバリのニーズに応えています。
マイクロサービスとクラウド
動的なマイクロサービスメッシュはクラウドインフラで効果を発揮します。クラウドでは、コンピューティング、データベース、分析などの機能をモジュール型の構成要素として迅速にプロビジョニングできます。ネットワーク、セキュリティ、キューイングに特化したマネージドサービスを利用することで、生産性はさらに向上します。リソースの使用量は自動スケーリングで効率化できます。マイクロサービスとクラウドが実現するアジリティと迅速なイノベーションは、レガシーアーキテクチャに変革をもたらします。
マイクロサービスが実現するDevOps
アジャイル開発ワークフロー
マイクロサービスでは、大規模なコードベースを製品の機能に沿ったモジュール型サービスに分割し、それぞれの開発に最適な手法を取り入れることができます。小規模なチームがサービスをエンドツーエンドで担当し、アジャイルのスプリント単位で機能を進化させます。各サービスの開発、テスト、デプロイを独立して行うことができ、調整のためのオーバーヘッドは発生しません。そのため、生産性とイノベーションが向上します。変更の導入が迅速化する一方で、品質に関する課題の影響は局所的に抑えられます。
テストの自動化
自動化したテストスイートを個々のマイクロサービスのビルドに対して実行することで、デプロイ前に品質を検証できます。単体テストでは、モジュールは機能面から検証されます。テストダブルを使用した統合テストでは、接続をシミュレートして、サービス間の連携のロジックを確認します。負荷をシミュレートして行うパフォーマンステストでは、現実的な状況で一定の水準のレスポンスを確保します。こうしたテストを自動化することで得られる信頼性のもとで、リリースまでの時間を短縮することが可能になります。
シンプルなデプロイ
コンテナを利用することで環境が標準化され、インフラ全体でサービスを一貫してデプロイできます。自動化ツールは、コンテナの大規模な管理とオーケストレーションを支えます。変更不可能なコンテナイメージは、コードや設定の不変のスナップショットとして、シンプルなロールバックを実現します。コードとしてのインフラは、ニーズに合ったプロビジョニングを自動化します。こうした一連の機能によって、継続的デリバリのパイプラインが実現されます。
動的なリソース割り当て
自動スケーリングでは、基盤のインフラリソースを動的に増減して、運用中の負荷の変化に適応できます。アプリケーション全体ではなく各サービスを独立してスケーリングできることから、効率的なコンピューティングが可能になります。こうして柔軟性を確保することで、絶えず変化するニーズを満たすことができます。
迅速な修正
障害が特定のサービスのみに限定されることから、停止が広範囲に波及せずに済みます。分散トレーシングやマイクロサービスの監視によるきめ細かな可視化を通じて、根本原因の診断のスピードが上がります。障害が検出されたときには、自動修復機能が作動するか、あるいは迅速な修正に向けてサイト信頼性エンジニアにアラートが届きます。これにより、レジリエンスやアップタイムを改善することができます。
つまり、マイクロサービスとは、ワークフローの最適化、インフラ管理、自動化に役立つDevOpsツールなのです。DevOpsの重要な目標に直接寄与し、サービスのデリバリを加速します。
マイクロサービスのビジネス上のメリット
市場投入サイクルを加速
マイクロサービスのモジュール型アーキテクチャでは、非集権型の開発、テスト、デプロイによって、迅速なイノベーションが可能になります。大きなリリースサイクルの節目まで待たなくても、個々のサービスに新機能を少しずつ追加して、ロールアウトのスピードを上げることができます。競合他社に先んじて新機能を投入し、顧客を満足させ続けるためには、こうしたアジリティが不可欠です。デリバリを頻繁に行うと、ユーザーからのフィードバックも頻繁に得られます。この両輪を回すことで、市場投入サイクルは加速します。
コストを最適化
マイクロサービスでは、リソースの割り当てやスケーリングの対象を、アプリケーション内で影響が生じている特定の領域のみに限定できます。モノリスの場合のように、アプリケーション全体を対象にする必要はありません。さらに、クラウドの従量課金と自動スケーリングの両方を活用し、使用していないキャパシティを無効化することで、需要の増減に応じてリソース使用量を最適化できます。こうしてインフラコストを最小限に抑えられます。
耐障害性が向上
独立してデプロイ可能な複数バージョンのサービスを利用することで冗長性が確保され、障害の影響を緩和できることがあります。例えば、決済処理サービスで問題が発生した場合、リクエストを別のインスタンスにルーティングして、収益への影響を最小限に抑えられます。マイクロサービスの設計によって障害を隔離することで、システムのレジリエンスはモノリスに比べて大幅に向上します。
イノベーションの速度
マイクロサービスの場合、プロダクトチームはAI/MLやAR/VRなどの新たなテクノロジを早急に実験し、差別化した機能を開発できます。時間がかかる会社の承認プロセスを待つ必要はありません。この結果、アプリケーションのさまざまな領域でイノベーションの速度が上がり、競争優位性が高まります。
成長を加速
市場投入サイクルの短縮、耐障害性を備えた運用、コストの最適化など、ここまでに取り上げた特長が相乗効果を発揮すると、ビジネスの成長は加速します。現代の市場では、一人ひとりに合った満足度の高い体験を提供できる製品やサービスを直ちに投入することが求められています。こうした市場の状況に即したデジタルトランスフォーメーションの目標を達成するうえで、ソフトウェアデリバリの効率化は企業にとって有益です。
マイクロサービスアーキテクチャの主な課題
マイクロサービスは、サービスごとの独立したスケーラビリティの確保や、機能のデリバリ速度の向上という面で、大規模で複雑なアプリケーションには絶大なメリットがあります。しかし一方で、複雑さ、デバッグ、コスト、データの完全性という面で、いくつかの軽視できない課題もあります。マイクロサービスへの移行にあたっては、このトレードオフを踏まえた戦略的な計画が必要になります。
複雑さ – マイクロサービスアーキテクチャは、管理が必要なコンポーネントやサービスの数が増えるという点で、複雑さがかなり高まる可能性があります。単一のモノリシックアプリケーションではなく、数十から数百に及ぶ小規模なサービスのデプロイ、スケーリング、更新、監視などが必要です。あわせて、複雑な分散トランザクションや一貫性の課題にも対処する必要があります。
テストとデバッグ – 独立した多数のサービスで構成されているため、テストやデバッグはかなり難しくなります。複数のサービスを連携させた場合にのみ問題が表面化することがあるほか、本番環境で生じる問題をテスト環境で再現するのが難しいことがあります。高度なトレーシング、ロギング、監視の機能が必要です。
運用コスト – マイクロサービスでは、インフラのプロビジョニング、複数の環境の設定、マイクロサービスのCI/CDパイプラインの実装、デプロイのオーケストレーションの処理、その他多数のコンポーネントの継続的な管理という面で、運用上のオーバーヘッドコストが大きくなります。こうした要素を適切に考慮しておかないと、コストがたちまち積み重なって、マイクロサービスのメリットが相殺されてしまう可能性があります。
データ完全性 – データが複数のデータベースに分散し、それぞれ異なるサービスの管轄下にある場合、データの完全性、トランザクション、整合性の確保が非常に難しくなります。競合状態を回避し、サービス間のデータ同期を常に維持しておくために、2フェーズコミット、イベントソーシング、APIゲートウェイなどの機能が必要になる場合があります。
マイクロサービスアーキテクチャに移行するかどうかの判断基準
次のような状況が生じている場合には、マイクロサービスへの移行が適している可能性が考えられます。
- 大規模でモノリシックな負荷にアプリケーションがうまく対処できていない。
- あまりに複雑で開発の速度が妨げられている。
- コードベースが手に負えないほど拡大し、機能のデリバリが阻害されている。
- 会社がコスト効率に優れたスケーラビリティを求めている。
こうした状況に当てはまる場合は、徐々にマイクロサービスに移行することがプラスに働くかもしれません。しかし、アプリケーションがシンプルな場合には、複雑さが高まることに見合うメリットが得られない可能性もあります。長期計画のメリットを評価するために、まずは影響が最も大きい領域に的を絞り、段階的に移行を進めていくとよいでしょう。
Kongの特長
KongはオープンソースのAPIゲートウェイとサービスメッシュです。モノリスの解体やサービスディスカバリをはじめ、いくつかの重要課題を解決するためのソリューションを提供し、マイクロサービスアーキテクチャに移行する企業を支援します。Kong Gatewayは、APIゲートウェイ、サービスメッシュ、サービスコントロールプラットフォームなど、クラウドネイティブのマイクロサービス向けに設計された重要なインフラ機能を備えています。Kongは、企業がマイクロサービスを大規模に導入するなかで運用やアーキテクチャに関して直面するいくつかの重要な課題を解決します。Kongのプラットフォームを利用することで、移行の複雑さ、コスト、リスクは大幅に抑えられます。
開発者のアジリティを確保し、コンプライアンスとセキュリティを維持しましょう。APIファーストの企業を目指すうえで、Kongがどのように力になるかを実際に体験して下さい。