目次


マイクロサービスへのリファクタリング, 第 3 回

マイクロサービス導入へのロードマップ

モノリシックなアプリケーションを一連のマイクロサービスに段階的に移行する

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: マイクロサービスへのリファクタリング, 第 3 回

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:マイクロサービスへのリファクタリング, 第 3 回

このシリーズの続きに乞うご期待。

このシリーズの第 1 回で、マイクロサービス・ベースの手法に合わせてコードを再編成する主な理由と、その際の推奨事項を説明しました。第 2 回では、マイクロサービスに基づくデータのリファクタリングによって解決できる類の問題を説明しました。

今回はシリーズの締めくくりとして、これまでのアドバイスを、モノリシックなアプリケーションから一連のマイクロサービスへと 4 段階で変換するロードマップに適用します。これまでマイクロサービスを導入する顧客を支援してきた経験から言うと、段階を踏むことなく、完全なマイクロサービス戦略に一気に移行する顧客はごくまれです。ほとんどの顧客は、段階的な手法に従ってマイクロサービスへの移行を成功させています。

1

マクロサービス

マイクロサービスに移行する際の最初のステップは、マクロサービスです。「SOA サービス」の既存のランドスケープを調べることで、ほとんどの顧客で見えてくるのはマクロサービスという形です。RESTful プロトコルを使用するように Web サービスが実装されているとしても、サービス自体は SOAP で実装されていることは珍しくありません。

出発点となるのは、サービスにアクセスする際の統一された 1 つの共通プロトコルとして、REST を採用することです (メッセージング・システムを使用した非同期サービスは特殊なケースですが、ここでは単純にするために取り上げません)。既存の Web サービスがすでに REST をサポートしているとしたら、REST を標準とすることに同意した時点で、このステップは完了したことになります!

一方、Web サービスをまったく使用しない、完全にモノリシックはアプリケーションについては、ビジネス・ロジックを RESTful Web サービスに分離できるかどうかについて調査を開始します。

あるいは、Web サービスは存在するけれども、それらのサービスが SOAP をベースとしている場合は、機能を単位としている SOAP インターフェースを、エンティティーを単位とする REST インターフェースにリファクタリングしなければなりません。

REST へのリファクタリングが完了したら、それらの REST サービスを文書化してカタログに載せられるようにする必要があります。それには、Swagger のような記述フォーマットが役立ちます。さらに、Swagger を IBM Cloud 内の API Connect などのツールと組み合わせて使用すれば、Swagger ドキュメントを取り込んで個々の IBM Cloud サービス・タイルを生成し、それらのタイルによって RESTful サービスをバインドし、呼び出すことも可能になります。

2

ミニサービス

REST に同意してインターフェースを文書化した後は、次のステップとして、サービスの分離に取り掛かります。機能分割のガイドラインに従って、サービスごとに 1 つのコンテナーになるよう最善を尽くしてください。従うべき機能分割のガイドラインは、このシリーズの第 1 回で説明していることをお忘れなく。

目標を達成するまでには、かなりの時間がかかる場合があります。マイクロサービス・アーキテクチャーに必要となる水準の運用上の規律をすぐに採用できるチームは多くはありません。「サービスごとに 1 つのコンテナー」戦略を採用するには、Cloud Foundry や IBM Cloud 内の Docker などのサポート・テクノロジーを採用する必要が生じます。多くのチームでは、このステップに時間をかけて取り組む必要があります。

同様に、「サービスごとに 1 つのコンテナー」戦略に従うには、WebSphere ND のような従来型のミドルウェアから WebSphere Liberty に移行しなければならない場合もあります。時間をかけて確実に、モニタリングおよびロギングによってこの手法をサポートできる適切なインフラストラクチャーをセットアップしてください。そのためには、IBM Cloud 内の Monitoring サービスやその他の関連するサービスを利用できます。いずれにしても、サービスの使用状況とパフォーマンスをトラッキングするための 1 つの手法を標準化する必要があります。

3

マイクロサービス

完全なマイクロサービス・アーキテクチャーを実現するためには、その前に、サービスのデプロイ方法だけでなく、サービスの構築方法についても検討する必要があります。このステップでは、サービスごとに完全に独立した継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの確立に向けて取り組みます。この目標を達成するのに役立つのは、IBM Continuous Delivery Pipeline などのツールです。

マイクロサービスへの移行過程のこの時点で、個々のマイクロサービスのスケーリングについて考え始めることもできます。スケーリングに有用な機能としては、IBM Cloud Container サービスに含まれるコンテナー・グループや、IBM Cloud サービスを対象とした自動スケーリングなどがあります。自動スケーリングでは、ユーザーが定義するスケーリング・ポリシーに応じて、いくつものアプリケーション・インスタンスが動的に調整されます。

4

大規模なマイクロサービス

最後のステップは、完全にスケールアウトするマイクロサービス手法への移行です。けれども多くのチームは、このステップを踏む必要はありません!私の経験から言うと、ほとんどのプロジェクトは最終的に、少数 (通常は 10 未満) のマイクロサービスで構成されることになるためです。

このステップでは、サービス・ディスカバリーに関して検討することが必要になります。具体的には、サービスをどのように発見するのか、ルーティング・ルールをどのようにセットアップするのかといった質問の答えを見つけるわけですが、ここで役立つのが、IBM Cloud 内でのサービス・ディスカバリーです。IBM Cloud 内では、ハードコーディングされたネットワーク・アドレスではなく、論理名に基づいてマイクロサービスを見つけることができます。しかも、正常に動作しないマイクロサービスは自動的に削除されます。

最後に、ダウンストリームのサービスで障害が発生した場合に備えておく必要があります。この場合、IBM Cloud 上の IBM Cloud Kubernetes Service 内で Netflix Hystrix などのライブラリーを実行できます。

まとめ

現在のアプリケーションを最終的なマイクロサービスの「至福の境地」へと移行するためのロードマップを理解した今、移行プロセスを早速開始できます。この記事の説明らからわかったように、各ステップが次のステップの土台となります。正直なところ、最終目的地の手前で止めるのでも構いません。

第 1 回第 2 回で警告したように、マイクロサービスが目新しいからといって採用することは避けてください。解決しようとしている問題が、マイクロサービス・アーキテクチャーで解決するのが適切なものである場合にだけ、アプリケーションにビジネス価値を追加する全体的なプロセスの一環として、マイクロサービスを採用してください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Java technology
ArticleID=1064767
ArticleTitle=マイクロサービスへのリファクタリング, 第 3 回: マイクロサービス導入へのロードマップ
publish-date=02282019