マイクロサービス:拡張可能なソフトウェアを、より迅速にデリバリする

共有

マイクロサービスとは

マイクロサービスとは、単一目的のサービスの連続的なデリバリを優先順位付けするために個々のチームが用いる構造的なアプローチを意味します。マイクロサービスモデルは、緊密に統合されたモジュールから成り、頻繁に納品できず、単一ユニットとして規模の拡大縮小を行う必要がある従来のモノリシックソフトウェアの対極にあるものです。モノリシックアプローチは一部の組織やアプリケーションではうまく機能しますが、より優れたアジリティや拡張性を求める企業では、マイクロサービスの方が一般的になり始めています。


Microservices Cartoon


マイクロサービスが重要である理由

顧客のニーズにより敏感に反応

マイクロサービスアーキテクチャを採用している企業は、顧客が必要とするときに、固定されたリリーススケジュールに縛られることなく、機能を即座にデリバリできます。

ソフトウェアチームのスループットが向上

マイクロサービスは、アジャイルとDevOpsの原則の上に構築されているため、ソフトウェアチームは、個別の機能をすばやく反復処理しながら、並行して作業を実行できます。

システムの拡張性と信頼性の向上

マイクロサービスアーキテクチャは、高い維持性能を誇ります。反復可能な自動化機能に立脚しており、サービスを細かく拡大縮小することが可能で、個々のコンポーネントに不具合が生じてもシステムが動作し続けるよう設計されています。




マイクロサービスとPivotal

Pivotalは、高性能なマイクロサービスアーキテクチャの設計をお手伝いするほか、マイクロサービスを実行するための世界クラスの環境を提供します。

Work with our Pivotal Labs team to initially target applications that require feature iterations and extreme scalability, and then learn how to build teams focused on delivery.

Deploy and manage microservices with Pivotal Cloud Foundry—our cloud-native platform that accelerates your time to value.

Empower your developers with patterns from Spring Cloud Services that overcome key challenges and operational overheads when building distributed systems with microservices



マイクロサービスアーキテクチャを検討する際の 考慮事項

マイクロサービスはすべての組織やアプリケーションに適合するわけではなく、適切に導入されないとコストが高額になる場合があります。事前に把握しておくべき事柄:

組織の準備はできているか

マイクロサービスへの移行は、技術的というより、組織的な移行です。チームは、自動化と継続的デリバリ重視のアプローチによるソフトウェア構築を受け入れる準備を整える必要があります。あなたの組織は、職務的サイロを排除し、サービスの構築と運用の両方を行う自己充足的なチームをつくる準備はできていますか?変更管理プロセスは、人的介入なしに、デプロイパイプラインに耐えられますか?

熱心すぎる開発者を抱えていないか

すべてのアプリケーションがマイクロサービスを必要としているわけではありません。マイクロサービスをすべてに適用しようと意気込む開発者は、ビジネス上変更の必要がない既存のアプリケーションのコードの記述に時間を大いに取られる恐れがあります。変更の頻度が低いアプリケーション、またはミッションクリティカルな機能を提供しないアプリケーションは、モノリシック状態のままの方が具合がいいかもしれません。マイクロサービスはアジリティを向上させますが、同時に複雑さも増大させます。マイクロサービスを採用する前に、アジリティの向上が本当に必要かどうか確認してください。

サービスの連携をどうするか

マイクロサービスは互いにゆるくつながっており、頻繁に変化します。サービスの最新URLをどのように確認しますか?また、数が日々変化するサービスインスタンスへのトラフィックの経路をどのように決定しますか?サービスでデータをどのようにやりとりするか?多くの場合、現在配備されているサービスの検出、負荷分散、およびメッセージングのためのテクノロジーは、マイクロサービスによって導入されるダイナミクスにとって非常に不適切です。

複雑な環境における「Day2」管理をどうするか

管理するアイテムの数が増えると、運用上のリスクも増えます。何百または何千ものサーバーにわたって何百または何千ものマイクロサービスを構築することは、新しいアプローチを取らない限り必ずや管理上の頭痛の種になるでしょう。基幹マシンのパッチやアップグレードをどうするか?あなたは、依存関係を追跡したり、リスクにさらされているアプリケーションを特定したりできますか?最新のアプリケーション構成を用いて、何十もあるマイクロサービスインスタンスを最新状態に維持することについてはどうでしょうか。マイクロサービスプラットフォームを構築するために使用するコンポーネントと、それらのコンポーネントやサービスをどこで実行するかは、今後数年間にわたって組織のアジリティに大きな影響を与えます。



大きな違い:マイクロサービスと従来のアーキテクチャとの比較
マイクロサービスアーキテクチャ
従来のアーキテクチャ
焦点が1つ。 1つ行えばうまくいきます。マイクロサービスは特定の課題領域をターゲットとし、そのエクスペリエンスを実現するために必要なすべて(データを含む)が網羅されています。マイクロサービスの「マイクロ」は、規模ではなく、範囲を意味しています。
焦点が広い。 ソリューションは、緊密に統合されたソフトウェアパッケージにより、多くのビジネス課題を一度に解決しようとします。
ゆるく連結されている。マイクロサービスアーキテクチャは、サービスができる限り自己完結であるとともに、他のサービスに対するハードコーディングされた参照を避けることを必要とします。
緊密に連結されている。 システムはしばしば相互依存しているコンポーネントがクモの巣のように連結し合うため、慎重に手順を組まなければデプロイできません。
継続的にデリバリされる。マイクロサービスは、頻繁な変更を必要とするアプリケーションを担当するチームに最適です。できるだけ早く市場に価値を届けるため、マイクロサービスは自動化を通じて定期的に実稼働環境にデリバリされます。
スケジュールされたデリバリに依存する。開発されたアプリケーションは、予定されたスケジュールでアップデートされます。その頻度は、四半期に1度や年に1度である場合もよくあります。
個別のチームがサービスのライフサイクルに責任を負う。マイクロサービスへの転換は、テクノロジーと同様、チーム構造も重要です。マイクロサービスは、個別のチームによって構築、納品、および実行されます。すべてのサービスをこのように扱う必要はないが、ビジネスクリティカルなサービスにとってはこれが強力なモデルとなります。
多くのチームがサービスのライフサイクルに責任を負う。ソフトウェアの最初のイテレーションの構築に対して責任を負うのはプロジェクトチームですが、プロジェクトチームは構築が終わると解散し、次の仕事へと移ります。ソフトウェアは運用チームに引き渡され、保守されます。
設計パターンとテクノロジーは、大規模な分散システムを重視している。マイクロサービスの構築と実行には、モノリシックソフトウェアの制作と同じアプローチやツールを用いることはできません。マイクロサービスアーキテクチャは、サービス検出、メッセージング、ネットワークの経路決定、不具合の検出、ロギング、ストレージ、識別などのための一連のサービスに依存しています。
プロセスを第一とした設計パターンとテクノロジーを有する。モノリシックソフトウェアの制作には、主要な開発段階、QA、および実稼働環境へのリリースに焦点を当てた、サイロ化されたツールやプロセスが用いられます。