マイクロサービスとは？
マイクロサービスは、軽量で疎結合のモジュールで、複雑なクラウドベースのアプリケーションのビルディング・ブロックとして機能します。個々のマイクロサービスは、独立して動作する一方で、統一されたインターフェイスで疎結合されます。
マイクロサービス・アーキテクチャーは、モノリシック・アーキテクチャーの従来型開発モデルに替わる、柔軟性が高い最新の代替手法と考えられています。
モノリシック・アーキテクチャーでは、通常、各アプリケーションに 1 つの物理的サーバーまたは仮想化サーバーが割り当てられ、それらのサーバーは常に稼働しています。アプリケーションのスケーリングと可用性は、固定されたエンティティーである基盤のハードウェアに完全に依存しています。
これとは対照的にマイクロサービスでは、ワークロードの需要に対応するため動的にスケールアップするリソースに合わせて 1 台または複数のサーバーで複数のインスタンスを運用できます。個々のマイクロサービスは、多くの場合、移植性とスケーラビリティーを向上させるためにコンテナ化されます。
マイクロサービスのさまざまな特徴
開発プロセスとしてのマイクロサービス・フレームワークには、一般的ではあるものの普遍的ではない特徴がいくつかあります。
それは次のような特徴です。
- コンポーネント。マイクロサービスは、通常、個々に交換、更新可能な、異なるソフトウェア・コンポーネントで形成されます。各マイクロサービスを別々にプロビジョニング、監視、更新する必要があるため、このアーキテクチャーはクラウド管理テクノロジーに影響を与えます。
- サービス。コンポーネントを構成するサービスは、オンデマンドの通信には利用可能な一方で、要求と呼び出しの合間には常時アクティブではない可能性もあります。
- 独立した導入。ほとんどの場合、個々のサービス・コンポーネントは、互いに独立してマイクロサービス・フレームワーク内で動作します。1 つのコンポーネントが変更または更新されても、特に従来型のモノリシック・アーキテクチャーと比較して、ほかのサービスやコンポーネントに対する影響がほとんどありません。
- セキュリティー。マイクロサービス間の通信は、多くの場合 mutual transport layer security (mTLS) で暗号化され、転送中にマルウェアや侵入からデータを保護します。
- コンテナ化。マイクロサービスは、多くの場合コンテナに導入され、高い移植性とスケーラビリティーが実現します。
マイクロサービス・アーキテクチャーを採用すると、アプリケーションのスケールアップが容易になり開発が高速化されます。その結果、イノベーションが可能となり、新機能の市場投入までの時間が短縮されます。
マイクロサービスとクラウド・アプリケーションのメリット
アーキテクチャー固有のクラウドにおける柔軟性により、マイクロサービスの人気は高まっています。実際、インテルが実施した最近の調査では、すべての新しいクラウドネイティブなアプリケーションおよび SaaS ソリューションの 83% でマイクロサービスが利用されていることが明らかになりました。1
マイクロサービスの最大メリットの 1 つに導入のスピードと柔軟性があります。クラウド・アプリケーションとワークロードの規模と範囲の拡大が続くなか、新しい需要に対応するためモノリシック・アーキテクチャーを適応させるのは、ますます困難で長時間を要するようになっています。マイクロサービスは分散型なため、分散型モデルで開発、導入と維持の管理を行えます。
例えば、1 つまたは複数のマイクロサービスに対する責任をさまざまな独立した開発チームに割り当てることができます。責任を分配することで、各チームのビジネス能力に応じた DevOps 機能の再編成を促進します。これは、開発プロセス全体の最新化とサイロの排除につながります。
マイクロサービスには導入時の課題もいくつかあります。個々のモジュールは異なるシステムで稼働していて要求に応答するため、モジュールごとのパフォーマンスに一貫性がなくなる場合があります。
同様に、需要の急激な高まりなどにより、一部のマイクロサービスでレイテンシーが問題となることもあります。こうした問題は、多くの場合、需要レベルのピーク時に対応できるようリソースを過剰プロビジョニングすることで解決できます。
マイクロサービスは分散型であるため、特定モジュールに影響を与えるサービス障害がほかのモジュールにほとんどまたは全く影響を与えない場合があります。これは 1 つのメリットですが、サービス障害が課題につながることもあります。
例えば、障害の発生したサービスが停止した後にそのサービスをデバッグする難しさが考えられます。解決策の 1 つは、事前にインフラストラクチャーを調整してすべてのプロセスとデータフローを監視することです。こうした監視プロトコルは、インテル® テクノロジーを搭載したクラウド・プラットフォームに内蔵されたハードウェア支援型テレメトリー・コレクターやパフォーマンス監視ユニット (PMU) を活用します。
マイクロサービス・アーキテクチャーの仕組み
マイクロサービス・アーキテクチャーでは、複雑なアプリケーションは、独立して開発および導入できる別個の機能に分割されます。多くの場合、個々のマイクロサービスは API を通じた相互通信を行い、緩やかに接続されていますが、各マイクロサービスは別個に開発、導入、更新することができます。
マイクロサービス導入は、多くの場合 3 パターンの 1 つに当てはまります。
- クラウドネイティブ。定評があり、大規模に利用されているアプリケーションやサービスの中にはマイクロサービスとして始まり、クラウドに残っているものもあります。International Data Corporation (IDC) によると、マイクロサービスの約 56% はクラウドネイティブで、残りの 44% が従来型のアプリケーションとして生まれたものです。2
- リファクター・アンド・シフト。こうした導入は、オンプレミスまたはエッジのデータセンターで始まり、クラウドベースのマイクロサービス・アーキテクチャーに適応させるためにリファクターされます。リファクターには、モノリシック・アーキテクチャーで関連づけられたデータベースやそのほかのリソースを再マッピングして対応するマイクロサービスとつなげる作業などがあります。
- リフト・アンド・シフト。組織によっては、既存のアプリケーションをリファクターせず、シンプルな「リフト・アンド・シフト」の変更で、アプリケーションをマイクロサービス・アーキテクチャーに移行させます。
マイクロサービスと DevOps
マイクロサービス・アーキテクチャーが持つ分散型の性質により、多くのDevOps チームはアプリケーション開発に対して機能横断的なアプローチを採用するようになります。
例えば 1 つのチームをファームウェアの作業に割り当て、ほかのチームはミドルウェアの作業、3 つ目のチームはユーザー・インターフェイスの作業をするというように、スタックでソフトウェア・アプリケーションを開発する代わりに、マイクロサービスの開発作業は多くの場合ビジネス機能に基づいて構成されます。
ある意味で、開発プロセスや DevOps チームの組織が、緩やかなインタラクションを行う、ある程度独立した自己完結するコンポーネントを持つマイクロサービスの構造自体を模倣することになります。
モノリシック・アプリケーションをマイクロサービス・アーキテクチャーへと近代化させるのが壮大な事業であり、数多くの試行を繰り返さなければならない可能性があることを、すべてのステークホルダーが理解していることが重要です。アーキテクトや開発者は、モノリスのさまざまな側面を厳密に評価して、各側面の移行アプローチを決定する必要があります。
マイクロサービスのセキュリティー
マイクロサービスは多くの場合、相互作用するよう設計されるため、データがインタラクションの各端で利用されている間、またはそれらの 2 点の間で転送されている間のデータ保護が重要です。
相互 transport layer security (mTLS) による暗号化は、各エンドポイントおよび通信中のデータ侵害とマルウェアの危険を軽減するのに役立つソリューションです。mTLS の目的は、各マイクロサービスが実行するすべての要求を暗号化することです。セキュリティーに対するこうした包括的なアプローチが、各マイクロサービス、ユーザーと接続を独立的に検証、認証しなければならない、ゼロトラスト環境の基盤を形成します。
しかし、必ずしも各マイクロサービスに認証と暗号化を含める必要があるわけではありません。冗長性を回避するため、多くの開発者は代わりにサービスメッシュを導入します。メッシュは、マイクロサービス・アーキテクチャー内のインフラストラクチャー層またはプロキシー・インスタンスとして機能して、通信の安全保護、制御と監視に役立ちます。
セキュリティー・プロトコルには大幅なコンピューティング能力が必要な場合があり、これによってリソースが使用されマイクロサービスの提供が遅れることがあります。暗号化アルゴリズムを高速化しレイテンシーを軽減するため、マイクロサービス開発者はインテル® データ・プロテクション・テクノロジー (インテル® DPT) を導入することができます。
インテル® DPT にはインテル® AES New Instructions (インテル® AES-NI) とインテル® セキュア・キー・インストラクション、インテル® Digital Random Number Generator (インテル® DRNG) が含まれ、暗号化キーの高速生成が実現します。
これらの高度なアルゴリズム保護は、インテル® Xeon® スケーラブル・プロセッサー・ファミリーの内蔵型セキュリティー機能向けに最適化されています。例えば、インテル® アドバンスト・ベクトル・エクステンション 512 (インテル® AVX-512) と、対称型暗号化、セキュアハッシュ化、関数ステッチングといったアルゴリズムのイノベーションにより、暗号化のパフォーマンスが大幅に向上します。
こうしたハードウェア支援型のセキュリティー機能は、インテル® Xeon® スケーラブル・プロセッサー・ファミリーを搭載した主要なクラウド・サービス・プロバイダーで利用できます。
マイクロサービス・アーキテクチャーの例と進化し続けるフレームワーク
クラウド・アプリケーションの規模と範囲は増大を続けており、開発者は、複雑で複数機能を持つアプリケーションを構築し、変化し続ける使用モデルに迅速に対応するため、ますますマイクロサービスに頼るようになっています。
マイクロサービス・ベースの導入では、通常、複数の緩やかに接続されたコンポーネント・サービスが個別に実行されています。こうしたモジュール型コンポーネントが連携して動作し、統一されたユーザー体験またはアプリケーションを作り出します。
グループの特性に応じてユーザー体験を差別化する一部のマイクロサービス・ベースのアプリケーションでは、マイクロサービスを使用するメリットの 1 つにコードを共有し再利用できることがあります。このアプローチにより、同じサービスのインスタンスを複数構築して維持する必要性が排除されます。異なる体験の 1 つをカスタマイズする必要がある場合は、追加のマイクロサービスを利用できます。
例えば、人気の高いライドシェア・アプリケーションは、マイクロサービス・ベースですが運転手と乗客のユーザー体験は異なります。運転者管理、位置追跡、乗客プロファイル、支払い処理などはそれぞれ異なるマイクロサービスとなっており、それらが集められてユーザーと運転者のデバイスでそれぞれのインターフェイスを支えています。すべてのインターフェイスは同じブランド共通ですが、機能の一部は各グループによって異なる場合があるのです。
マイクロサービス・アーキテクチャーは、e コマースストアでもよく利用されている環境です。推薦商品やチェックアウトのプロセスは、個々のマイクロサービスとして開発、導入されているかもしれませんが、買い物客は、オンラインストアのブランド化された環境とインターフェイスの中で両方のプロセスを体験することになります。
マイクロサービスを使用するべき場合
マイクロサービスのアプローチは、最も複雑なソリューションをコンポーネント部分に分割することで、アプリケーションの移行とスケールアップに役立つことがあります。各マイクロサービスは独自に開発・導入されており、さまざまなマイクロサービスは疎結合されたエンティティーとして一緒に運用されます。
組織がマイクロサービスを利用する可能性が最も高いのは、新しいクラウドネイティブなソリューションを開発する場合です。また、既存のモノリシック・アーキテクチャーが、組織において変化するニーズに応えるにはあまりに扱いにくくなった場合にマイクロサービスを導入することもあります。
マイクロサービス・アーキテクチャーへの移行は、組織や DevOps チーム自体の構造の変化につながる可能性もあります。時間が経つにつれ、チームは、テクノロジー・スタックの機能レイヤーを模倣するサイロの代わりに、機能横断的にビジネス能力を重視する新しい焦点に合わせることになるかもしれません。