マイクロサービス・プロジェクトの実装方法（その3）
マイクロサービス・アプリケーション開発に関する6部構成のシリーズでは、現在のニーズに最適なクラウドベースのパイロット・プロジェクトを定義するためのコンテキストを提供し、長期的なクラウド導入の決定に備えます。
このパート3では、独自のマイクロサービス・プロジェクトを実装するための方法を提供します。
既存のアプリケーションを進化させる
ここでは、既存のアプリケーションの小規模なものから大規模なものへの変革の可能性を視野に入れながら、さまざまな規模のマイクロサービス・アプリケーション開発の具体的な道筋を描く方法について、さらに深く掘り下げていく。
事前のアプリケーションなしにマイクロサービス・プロジェクトを構築することは関連性があり重要ですが、私たちはマイクロサービスを構築する際の「モノリス・ファースト」のアプローチに同意しています。つまり、最初にアイデアを検証するために、できる限りの方法でアプリケーションを構築することを意味します。次に、このブログ・シリーズの原則を適用して、最初のモノリスをマイクロサービス・プロジェクトへと拡張し、進化させます。ビジネスに価値を還元しない、アーキテクチャー的に純粋なマイクロサービスの作成には価値がありません。
マイクロサービス・プロジェクトを成功させるために理解すべき3つの領域は、ビジネス、文化とスキルセット、そしてテクノロジーです。
ビジネスニーズの把握と定義
なぜマイクロサービスへの移行を考えているのですか？多くの企業にとって、より効率的なソフトウェア開発とオペレーションの実践は、ビジネスにより早く価値を提供し、より良いエクスペリエンスを提供するために必要です。
マイクロサービス・プロジェクトが既存のアプリケーションやインフラに与える影響を理解する前に、ビジネスのどの部分の動きが遅すぎて満足のいく成果が得られていないのかを理解する必要があります。多くの場合、組織の関与システム（SOE）がスピードダウンの原因となっています。これらのシステムは、ウェブ、モバイル、APIなど、多くのチャネルを通じて利用できます。スピードの欠如は、マイクロサービス・ベースのアーキテクチャへと移行する主な理由となっています。
マイクロサービス指向のアプローチを採用する前に、企業とビジネス利害関係者は、何が十分な速さで市場に投入されていないのかを知る必要があります。より速くするために、アプリケーションのどの部分に改善や修正が必要ですか？この問いに答えるには、既存のモノリスのどの部分をマイクロサービスの進化の対象とすべきかが関わってきます。
ユーザー・エクスペリエンス・フローやアーキテクチャー図を使用すると、チームはヒートマップ形式の注釈を介して既存のモノリスのセクションを迅速に切り分けることができます。例えば、問題点の優先順位を赤・黄・緑の3段階で示すと、ストアフロントのWebアプリケーションアーカイブは次のようになります。
現時点では、網羅的ではなく反復的にオープンに考えると、アセスメントの主な目標は次のとおりとなります。
モノリスが提供する個別のビジネス機能を特定する
ビジネス機能を変更するために必要な相対的なスピードと複雑さを理解する。
特定のビジネス機能に対するフィードバック・サイクルの高速化を望むビジネス・オーナーの要望を理解する。
自社の文化とスキルセットを理解する
マイクロサービス・ベースのアーキテクチャに限ったことではありませんが、デジタル・トランスフォーメーションを成功させるには、組織のチーム、文化、スキルセットを十分に理解することが欠かせません。
通常、エンジニアリングモノリスでは、ほとんどの組織はサイロ化されており、ソフトウェア開発ライフサイクルに沿って必要に応じてチームが参加します。これにより、明確に定義された境界が作られることが多く、その境界に沿って制限的な役割と責任が設定されます。
マイクロサービス・アーキテクチャーは、チームがソフトウェア開発とオペレーション全体のライフサイクルを管理する力を持つ場合にのみ成功します。マイクロサービス・ベースのアーキテクチャーを導入する際には、すべての役割と責任を代表する部門横断的なチームを構築することが基本となります。デザインから開発、オペレーション、ビジネス・オーナーに至るまで、すべての人が緊密に協力し合い、しばしば同じ場所に配置されます。
設計、開発、オペレーションなど、すべての利害関係者をチームに意図的に参加させているため、作業はより迅速かつ効率的に動き、ビジネス目標を達成するためのユーザー・エクスペリエンスの向上に明確に焦点を当てることができます。
部門横断的なチームは、チーム全体での個人のスキルの急速な向上もサポートします。設計からオペレーション、ランタイムデータに至るまで、マイクロサービスが担当するすべてをチームが管理すると、1人のチームメンバーが1つのタスクを実行することはありません。多くの場合、フロントエンド・エンジニアはデータベース管理スキルを向上させる一方、オペレーション指向のチーム・メンバーは、ユーザー・インターフェースのフレームワークの違いについてより深く学ぶことになります。このようにスキルセットを拡張すると、非常に特殊な役割を果たす専門家を常に探すのではなく、バランスの取れたチームメンバーで構成された新しいチームを構築することがはるかに簡単になるため、IT組織全体がマイクロサービスで成功するのに役立ちます。
テクノロジーを理解する
ビジネス上の問題とチームの文化やスキルセットに対処しない限り、マイクロサービス・テクノロジーを効果的に導入することはできず、同じプロセスや構造を維持することになります。
既存のテクノロジースタックの適切な分析は組織によって大きく異なりますが、ここで説明する簡素化されたアプローチは、マイクロサービス・プロジェクトの初期の成功と継続的な成功の両方を保証するのに役立ちます。小規模から始めて、反復的で進歩的な成功を定義することは、派手ですべてを一度に変革するようなアプローチよりも、はるかに達成可能で実りあるアプローチです。
テクノロジーを理解する最初の段階は、既存のモノリスに含まれる大まかなサービスを特定することです。このようなコースグレイン・サービスを特定することは、データ構造の複雑さ、現在のコンポーネント間の結合レベル、新しいコースグレイン・サービスを担当するチームなどを理解するのに役立ちます。粗視化されたサービスのレビューを成功させることで、特定のサービスの内部およびサービス間の両方のデータ境界を明確に理解することができます。
きめ細かなサービスを特定したら、そのような粗視化されたサービスをきめ細かいマイクロサービスに進化させる方法についての計画を作成する必要があります。これらのマイクロサービスは、これまでの作業に基づいて、すべて同様のデータを使用し、「独自の」データを所有し、どのデータをどこから読み、他のサービスに書き込む必要があるかを理解している必要があります。ここから、個々の微細なマイクロサービスのレジリエンス、拡張性、アジリティを特定し、実装することができます。
APIとマイクロサービスは、より大きな全体の2つの部分です。きめ細かなマイクロサービスについての理解が深まれば、インターフェイスについての理解も深まり、どのインターフェイスがクリティカルパスで、どのインターフェイスがオプションで、どのインターフェイスがもう不要なのかがわかるようになります。既存のインターフェイスまたはAPIを、粗視化されたきめ細かなマイクロサービスのいずれかにマッピングできない場合、ほとんどの場合、それを廃止することができます。
マイクロサービスの取り組みのサイジング
ビジネスを理解し、チーム構造を理解し、テクノロジーを理解するという大仕事をこなすことで、チームや大規模な組織は、それが概念実証の範囲であろうと、試験的な範囲であろうと、大規模な進化の範囲であろうと、特定のモノリスのマイクロサービスの進化全体を理解する準備が整います。
すべての分析とプランニング作業が完了したら、次のステップはタイムライン、納品速度、および期待される成果を定義することです。
次の記事では、マイクロサービス・トランスフォーメーションに取り組む際に適用できる開発とオペレーションのパターンについて検討します。
ここからどうするか
モノリシック・アプリケーションのモダナイズとリファクタリングについては、詳細なアーキテクチャーの進行状況をご覧ください。
Roland Barcia（IBM Distinguished Engineer/CTO）とRick Osowski（Senior Technical Staff Member）が、Kyleと共同でこの記事を執筆しました。