未来の構築：マイクロサービスアーキテクチャ

すでに数年稼働しているeコマースシステムの2〜3年のアーキテクチャロードマップについて議論するとき、典型的な質問は、マイクロサービスアーキテクチャに移行する必要があるかどうかです。

現在、マイクロサービスは流行語であるため、システムの進化のためにマイクロサービスを検討するのは自然なことです。 ただし、モノリシックシステムをマイクロサービスに再構築するための主な推進要因は、実際には次のようなビジネスおよび運用上の性質です。

1. ビジネスの成長のための設計：システムがより多くの顧客にサービスを提供し、より多くのトランザクションを処理するにつれて、より多くの容量とリソースが必要になります。 ただし、システムのすべての部分が同じ速度で成長するわけではありません。
2. トラフィックのピークの処理：理想的には、システムは、常にピークトラフィックをサポートするために、インフラストラクチャが最大容量にプッシュされないように、自動的に、または少なくとも動的に拡張できる必要があります。
3. 市場投入までの時間の短縮：機能の追加または変更に数か月ではなく数日または数週間かかり、過度の（そして多くの場合高価な）回帰テストや環境全体を実行するすべてのアプリケーションの再起動を必要としない場合、ビジネスに大きな価値があります。 これに対する答えは、モジュール性と交換可能性の設計であり、これはマイクロサービスによって促進されます。
4. コンテンツとユーザーエクスペリエンスの迅速で瞬時の変更：多くの従来のオンラインシステムは、チェックアウト、マイアカウント、およびその他の機能（つまり、モノリス）の機能も含む同じWebアプリケーションから、サーバー側でコンテンツを動的に生成します。 つまり、顧客向けのコンテンツは最新であり、パーソナライズされて管理可能である可能性がありますが、そのコンテンツを絶えず再生成すると、大量のCPUサイクルが消費され、データストレージやその他のサブシステムにオンラインで依存することになります。

マイクロサービスアーキテクチャの最終的な目標は、このアプリケーションを、デフォルトコンテンツを提供し、在庫状況に関する情報を提供し、パーソナライズされたオファーと推奨事項を提供する比較的独立したサービスに分割することです。 これらのサービスは、最高のユーザーエクスペリエンスを実現するために、調整、スケーリング、および管理できます。

ここでの考え方は、いくつかの自己完結型でスケーラブルな交換可能なサービスで構成されるシステムを持つことです。

ブリックバイブリック：システムを徐々に移動する

次に、問題は、この計画をどのように実行するかということです。 システムを最初から書き直すことは、通常は受け入れられません。 現在のプラットフォームへの投資、機能のテストと実証、または現在のシステムで完了する必要のあるその他の機能拡張があります。

ターゲットアーキテクチャについて合意し、ロードマップ開発計画に再アーキテクチャアクティビティを含めることで、システムをターゲットに向けて徐々に動かし始める方がよい場合があります。

1. 最優先のビジネス上の懸念に対処する変更を特定し、リファクタリング/移行を計画します。 たとえば、 「コンテンツ管理をシステムのトランザクション部分から切り離す」ので、変更をより迅速にサイトにプッシュできます。
2. 現在のアプリにブレンドする代わりに機能を追加する場合（たとえば、「あなたも好きかもしれません」または「追加のXを使う場合は…」）、それがインターフェースを公開するスタンドアロンサービスとして価値を提供できるものであるかどうかを検討します。独立して管理することができます。 スタンドアロンプ​​ロセスとして実行したり、最初に単独でデプロイしたりする必要はありませんが、十分に理解された依存関係を最小限に抑えてカプセル化する必要があります。
3. サブシステム（MyAccountなど）に大幅な変更を加える場合は、これを独自にアプリまたはサービスにするのに適切なタイミングであるかどうかを検討してください。 繰り返しになりますが、重要な要素は、実行時レベルだけでなく、コードへの依存関係を考慮することです。

MyAccountサービスに変更を加えることにより、他のすべてのモジュールを再コンパイルして再デプロイする必要がある場合は、（まだ）移行の候補としては適していません。 しかし、独自の特定のドメインの懸念をカバーする他の候補モジュールがあるかもしれません：

• • 顧客の電子メール通信サービス
  • サービスとしてのチェックアウト
  • アイテム在庫サービス
  • コマース検索エンジン
  • さまざまなパーソナライズ、アドバイザリー、または推奨サービス
  • 商品レビュー/評価サービス

プロジェクトを正しい方法でスケーリングする：マイクロサービスアーキテクチャのプロセスと計画を定義する

ご覧のとおり、この図はすぐに忙しくなり始め、サービスの数が増え、ソリューションの複雑さが増しているように感じます。 これに対処するには、チームはプロジェクトの次の側面に特別な注意を払う必要があります。

アーキテクチャの明確さ：これは必ずしも「事前の大規模設計」アプローチを意味するわけではありませんが、チームは、システムが構成されるサービス、およびサービスがどのように構築、展開されるかについて、共通のビジョンと理解を共有する必要があります、および監視されます。 チームは、さまざまなプラクティス（APIファースト）、フレームワーク（Spring Cloud）、共通のアプリケーションインフラストラクチャ要素（APIゲートウェイ、認証サーバー、サービスレジストリなど）を採用する準備をする必要があります。これらすべてが常に必要なわけではありませんが、必ず必要です。それらがシステムの一部になるかどうかの意識的なアーキテクチャ上の決定。

DevOps：これはもう1つの流行語ですが、このコンテキストでは非常に重要です。 システムが成長するにつれて、サービスの数が圧倒的になる可能性があるため、マイクロサービスの世界では、DevOpsが必要な要素です。 これは、ビルドの自動化と合理化、デプロイのテスト、再起動、自動スケーリング、アラートなどを意味します。いくつかのアプリケーションサーバーにデプロイされた単一のバイナリファイルは扱っていません。 それぞれが複数のインスタンスで実行される可能性のある、数十の小さな機能が存在する可能性があります。これは、誰もが手動でサポートしたいものではありません。 これらすべての実行中のアプリから手動でログを収集することを想像してみてください…

マイクロサービスアーキテクチャ：正しく理解する

マイクロサービスへの移行を間違えるには、多くの方法があります。実際のビジネスケースなしで、テクノロジーの話題をたどるだけで、相互に依存しすぎる不適切なサービスを特定し、複雑さに対処するためのDevOpsプラクティスの採用に失敗し、開発を行わないチーム内の適切なスキルなど。

ただし、適切な計画とリスク管理を行うことで、しばらくすると（そしてストレス、疑い、PMのパニック）、チームは何らかのプラスの影響を感じ始めるはずです。

• システムまたはその重要な部品の拡張性が向上
• 深夜に他のすべてを再起動することなく、新しい機能を提供する方が簡単です
• システムコンポーネントには明確な目的があるため、開発、テスト、交換が簡単です。

アーキテクチャロードマップは、2〜3年先のシステム進化の方向性を設定するのに役立つツールです。

それは、ビジネスロードマップ、戦略的テクノロジー、業界の方向性、およびチームのスキルと能力とうまく整合している必要があります。 その重要性は、マイクロサービスのような新しいアーキテクチャの概念とアプローチの導入によって特に高まります。