GSP699

はじめに

モノリシック アプリケーションをマイクロサービス アーキテクチャに移行する理由は何でしょうか。アプリケーションをマイクロサービスに分割すると、次のような利点があります。その多くはマイクロサービスが疎結合であることに起因しています。

• マイクロサービスは個別にテストしてデプロイできます。デプロイ単位が小さいほど、デプロイが容易になります。
• 異なる言語やフレームワークで実装できます。マイクロサービスごとに、ユースケースに最適なテクノロジーを自由に選択できます。
• 異なるチームで管理できます。マイクロサービス間の境界により、1 つのチームが 1 つまたは複数のマイクロサービスを簡単に管理できます。
• マイクロサービスに移行することで、チーム間の依存関係が緩和されます。各チームは、依存しているマイクロサービスの API のみを考慮し、マイクロサービスの実装方法やリリース サイクルなどについて考える必要はありません。
• 障害に対する設計が簡単になります。サービス間に明確な境界があるので、サービスが停止した場合の対処方法を決定しやすくなります。

モノリスと比較した場合、マイクロサービスには次のような欠点があります。

• マイクロサービス ベースのアプリを構成するサービスの相互関係が明確でない場合が多く、システム全体の複雑さは増大する傾向があります。
• モノリスの内部と異なり、マイクロサービスはネットワークを介して通信を行うため、セキュリティ上の問題が発生することがあります。この問題を解決するため、Istio はマイクロサービス間のトラフィックを自動的に暗号化しています。
• サービス間のレイテンシのため、モノリシック アプローチと同じレベルのパフォーマンスを実現するのが困難な場合があります。
• システムの動作は、単一のサービスに起因するのではなく、多くのシステムとシステム間のやり取りによって引き起こされます。このため、本番環境でのシステムの動作を把握することは難しくなります（可観測性が低くなります）。Istio は、この問題の解決策となります。

このラボでは、既存のモノリシック アプリケーションを Google Kubernetes Engine クラスタにデプロイし、それをマイクロサービスに分割します。Kubernetes は、コンテナの管理、ホスト、スケーリング、デプロイを行うプラットフォームです。コンテナは移植性の高い手法で、コードをパッケージ化して実行します。それぞれのマイクロサービスを独自のコンテナ内で実行できるので、この手法はマイクロサービスのパターンにも適しています。

マイクロサービスのアーキテクチャ図

まず、モノリスを一度に 3 つのマイクロサービスに分割します。マイクロサービスには、「Orders（注文）」、「Products（プロダクト）」、「フロントエンド」が含まれます。Cloud Build を使用して各マイクロサービスの Docker イメージをビルドします。次に、Kubernetes Service タイプの LoadBalancer を使用して Google Kubernetes Engine（GKE）にマイクロサービスをデプロイして公開します。各サービスに対してこれを行い、同時にモノリスからそれらをリファクタリングします。プロセス中は、モノリスを削除する最後の段階まで、モノリスとマイクロサービスの両方が実行されます。

ラボの内容

• モノリスからマイクロサービスへの分割方法

• Google Kubernetes Engine クラスタの作成方法

• Docker イメージの作成方法

• Docker イメージを Kubernetes にデプロイする方法

前提条件

• プロジェクトを作成するための管理者権限を持つ Google Cloud Platform アカウント、またはプロジェクト オーナーの役割を持つプロジェクト

• Docker と Kubernetes の基礎知識