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 アカウント、またはプロジェクト オーナーのロールを持つプロジェクト
• Docker と Kubernetes の基礎知識

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

5. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

デフォルトのゾーンとプロジェクト構成を構成します。

gcloud config set compute/zone {{{project_0.default_zone | (zone)}}}

タスク 1. ソース リポジトリのクローンを作成する

シンプルなスタートページとプロダクト ページ、注文履歴ページを備えた架空の e コマース ウェブサイトの既存のモノリシック アプリケーションを使用します。git リポジトリからソースのクローンを作成するだけで、後はマイクロサービスへの分割と Google Kubernetes Engine（GKE）へのデプロイに集中できます。

• 以下のコマンドを実行して Cloud Shell インスタンス内に git リポジトリのクローンを作成し、適切なディレクトリに移動します。NodeJS 依存関係もインストールするので、デプロイする前にモノリスをテストできます。

cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh

このスクリプトの実行には数分かかる場合があります。

タスク 2. GKE クラスタを作成する

作業用の開発環境が整ったので、モノリスをデプロイするための Kubernetes クラスタが必要になります（最終的にはマイクロサービスもデプロイします）。クラスタを作成する前に、適切な API が有効になっていることを確認してください。

1. 次のコマンドを実行して Container API を有効にして、Google Kubernetes Engine を使用できるようにします。

gcloud services enable container.googleapis.com

2. 次のコマンドを実行して、3 つのノードを持つ fancy-cluster という名前の GKE クラスタを作成します。

gcloud container clusters create fancy-cluster --num-nodes 3 --machine-type=e2-standard-4 警告: 指定していないリージョンまたはゾーンに関してエラーが発生した場合、環境設定のセクションを参照してデフォルトのコンピューティング ゾーンが設定されていることを確認してください。

クラスタの作成には数分かかることがあります。

3. コマンドが完了したら、次のコマンドを実行して、クラスタの 3 つのワーカー VM インスタンスを確認します。

gcloud compute instances list

出力:

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.6 XX.XX.XX.XX RUNNING

Google Cloud コンソールで Kubernetes クラスタと関連情報を表示するには、ナビゲーション メニューで [Kubernetes Engine] までスクロールし、[クラスタ] をクリックします。

fancy-cluster というクラスタが表示されます。

これで完了です。最初の Kubernetes クラスタが作成されました。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 GKE クラスタを作成する

タスク 3. 既存のモノリスをデプロイする

このラボで取り上げるのはモノリスのマイクロサービスへの分割であるため、モノリシック アプリケーションを起動して実行する必要があります。

• 次のスクリプトを実行して、モノリシック アプリケーションを GKE クラスタにデプロイします。

cd ~/monolith-to-microservices ./deploy-monolith.sh

モノリスへのアクセス

1. モノリシック アプリケーションの外部 IP アドレスを見つけるには、次のコマンドを実行します。

kubectl get service monolith

出力は次のようになります。

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d

2. 出力に外部 IP が <pending> と表示される場合は、少し待ってからコマンドを再度実行します。

3. モノリスの外部 IP アドレスを決定したら、その IP アドレスをコピーします。ブラウザにこの URL（http://203.0.113.0 など）を指定して、モノリスにアクセスできるかどうかをチェックします。

注: この IP アドレスは今後も引き続き使用するので、覚えておいてください。IP アドレスは、このコマンドを使用していつでも確認できます。

モノリシック ウェブサイトのスタートページが表示されます。スタートページは、フロントエンド マイクロサービスによって後で提供される静的ページです。これで、モノリスが完全に Kubernetes で動作するようになりました。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 既存のモノリスをデプロイする

タスク 4. Orders をマイクロサービスに移行する

モノリス ウェブサイトを GKE で稼働させることができたので、各サービスのマイクロサービスへの分割を開始します。通常、プランニング業務では小さなまとまりに分割するサービスの選定を行います。ビジネス ドメインなどのアプリケーションの特定の部分が対象となります。

このラボでは例を作成して、ビジネス ドメイン関連の各サービス「Orders（注文）」、「Products（プロダクト）」、「フロントエンド」に分割します。コードはすでに移行されているため、Google Kubernetes Engine（GKE）でのサービスのビルドとデプロイに集中できます。

新しい Orders マイクロサービスを作成する

最初に分割するサービスは、Orders サービスです。提供された個別のコードベースを利用し、このサービス用の個別の Docker コンテナを作成します。

Cloud Build を使用して Docker コンテナを作成する

コードベースはすでに利用可能であるため、最初のステップは、Cloud Build を使用して Orders サービスの Docker コンテナを作成することです。

通常、Docker コンテナの作成は、2 ステップのプロセスで行われます。具体的には、Docker コンテナをビルドするステップと、ビルドしたコンテナをレジストリに push してそのイメージを保管し、GKE がそこからイメージを pull できるようにするステップです。Cloud Build を使用して単一のコマンドで Docker コンテナをビルドし、イメージを Container Registry に保存します。この方法で、イメージをビルドして Container Registry に移動するための単一のコマンドを発行できます。手動で Docker ファイルを作成して push するプロセスを確認するには、Google Cloud Container Registry のドキュメントに移動して Container Registry のクイックスタートをご覧ください。

Google Cloud Build は、ディレクトリにあるファイルを圧縮して Cloud Storage バケットに移動します。その後、ビルドプロセスでそのバケットからすべてのファイルを取得し、Dockerfile を使用して Docker ビルドプロセスを実行します。--tag フラグは、Docker イメージの gcr.io としてホストで指定されます。作成された Docker イメージは Google Cloud Container Registry に push されます。

1. 次のコマンドを実行して、Docker コンテナをビルドし、ビルドしたコンテナを Google Container Registry に push します。

cd ~/monolith-to-microservices/microservices/src/orders gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .

このプロセスが完了するまでには 1 分ほどかかります。完了すると、ターミナルに次のような結果が出力されます。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io//orders:1.0.0 SUCCESS

2. ビルド履歴を表示したり、プロセスをリアルタイムで確認したりするには、コンソールで左上のナビゲーション メニューボタンをクリックして [CI/CD] までスクロールし、[Cloud Build] > [履歴] をクリックします。ここには過去のすべてのビルドのリストが表示されます。リストには、作成したばかりのビルドが 1 つだけ示されているはずです。

ビルド ID をクリックすると、そのビルドのすべての詳細が表示されます。詳細にはログ出力も含まれます。

[ビルドの詳細] ページの右のセクションで [実行の詳細] タブをクリックすると、作成したコンテナ イメージが表示されます。

コンテナを GKE にデプロイする

ウェブサイトをコンテナ化して、Google Container Registry にそのコンテナを push したら、次は Kubernetes にデプロイします。

Kubernetes では、アプリケーションは Pod として表されます。Pod は、1 つのコンテナ（または密接に結合されたコンテナのグループ）を表す単位です。Pod は、Kubernetes でデプロイ可能な最小単位です。このチュートリアルでは、各 Pod にマイクロサービス コンテナのみが含まれています。

GKE クラスタにアプリケーションをデプロイして管理するには、Kubernetes クラスタ管理システムとの通信が必要になります。通常、これを行うには、Cloud Shell 内から kubectl コマンドライン ツールを使用します。

最初に、Deployment リソースを作成します。Deployment は、アプリケーションの複数のコピー（レプリカと呼ばれる）を管理し、クラスタ内の個々のノード上で実行されるようにスケジューリングします。今回の場合、Deployment ではアプリケーションの 1 つの Pod のみが実行されます。これらの処理を行うために、Deployment は ReplicaSet を作成します。ReplicaSet の役割は、指定された数のレプリカが常に実行されるようにすることです。

以下の kubectl create deployment コマンドを使用すると、Kubernetes は 1 つのレプリカを含む Orders という Deployment をクラスタに作成します。

• 次のコマンドを実行して、アプリケーションをデプロイします。

kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 注: YAML ファイルを使用して Kubernetes クラスタへの変更（デプロイメントやサービスの作成または変更など）を宣言したり、GitHub や Cloud Source Repositories などのソース管理システムを使用してそれらの変更を保存したりすることをおすすめします。詳細については、Kubernetes Deployments のドキュメントをご覧ください。

デプロイを確認する

• 次のコマンドを実行して、Deployment が正常に作成されたことを確認します。

kubectl get all

Pod のステータスが [実行中] になるまで少し時間がかかることがあります。

出力:

NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s

現在の Deployment、必要な Pod 数が 1 の Replicaset、実行中の Pod を確認できます。すべて正常に作成されていることがわかります。

Cloud Console のナビゲーション メニューから [Kubernetes Engine] > [ワークロード] に移動すると、Kubernetes Deployment を表示することもできます。

GKE コンテナを公開する

アプリケーションを GKE にデプロイしましたが、クラスタの外部からアクセスする方法がありません。GKE で実行するコンテナには外部 IP アドレスがないため、デフォルトでは、このコンテナにインターネットからアクセスすることはできません。Service リソースを使用して、アプリケーションをインターネットからのトラフィックに明示的に公開する必要があります。Service は、アプリケーションの Pod にネットワーキングと IP サポートを提供します。GKE は、アプリケーションの外部 IP とロードバランサ（課金対象 - Google Cloud ウェブサイトで Compute Engine の料金をご確認ください）を作成します。

このラボでは、便宜上サービスの公開を簡素化していますが、通常は、API ゲートウェイを使用してパブリック エンドポイントを保護します。Google Cloud アーキテクチャ センターで、マイクロサービスのベスト プラクティスの詳細をご確認ください。

Orders サービスをデプロイしたとき、Kubernetes Deployment 経由で内部ポート 8081 に公開しました。このサービスを外部に公開するには、LoadBalancer タイプの Kubernetes Service を作成し、外部ポート 80 から内部ポート 8081 にトラフィックをルートする必要があります。

• 次のコマンドを実行して、ウェブサイトをインターネットに公開します。

kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081

サービスへのアクセス

GKE は、Deployment ではなく Service リソースに外部 IP アドレスを割り当てます。

• GKE によってアプリケーション用にプロビジョニングされた外部 IP を確認するには、次のように kubectl get service コマンドを使用して Service を調べます。

kubectl get service orders

出力:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3s

アプリケーションの外部 IP アドレスを確認したら、その IP アドレスをコピーします。新しい Orders サービスを指すようにモノリスを変更するときは、次のステップで使用できるように保存します。

モノリスを再構成する

Orders サービスをモノリスから削除したため、新しい外部の Orders マイクロサービスを指すようにモノリスを変更する必要があります。

モノリスを分割する場合は、単一のコードベースから複数のマイクロサービスへのコードの一部を削除して、それらを個別にデプロイします。マイクロサービスは別のサーバーで実行されているため、サービス URL を絶対パスとして参照することはできません。Order マイクロサービスのサーバー アドレスへのルートが必要です。その場合、分割された各サービスの URL を更新するために、モノリス サービスへのダウンタイムが必要になります。マイクロサービスの移行プロセス中にマイクロサービスとモノリスを本番環境に移行する際は、このダウンタイムを考慮してください。

新しい Orders マイクロサービスの IP アドレスを指すように、モノリスの構成ファイルを更新する必要があります。

1. nano エディタを使用して、ローカル URL を Orders マイクロサービスの IP アドレスに置き換えます。

cd ~/monolith-to-microservices/react-app nano .env.monolith

エディタを開くと、ファイルは以下のようになっています。

REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products

2. REACT_APP_ORDERS_URL を新しい形式に置き換え、その際に IP アドレスを Orders マイクロサービスのものにします。つまり、以下のようになります。

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products

3. Ctrl+O キー、ENTER キー、Ctrl+X キーを押して、nano エディタにファイルを保存します。

4. ファイルに設定した URL に移動して、新しいマイクロサービスをテストします。Orders マイクロサービスから JSON レスポンスが返されます。

5. 次に、モノリス フロントエンドを再ビルドし、ビルドプロセスを繰り返すことによって、モノリスのコンテナをビルドして GKE クラスタに再デプロイします。

• モノリス構成ファイルを再ビルドする:

npm run build:monolith

6. Cloud Build を使用して Docker コンテナを作成する:

cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

7. コンテナを GKE にデプロイする:

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0

8. ブラウザでモノリシック アプリケーションの Orders ページに移動して、アプリケーションが Orders マイクロサービスに到達していることを確認します。以下に示すように、すべての Orders ID の末尾は -MICROSERVICE にする必要があります。

9. [進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Orders をマイクロサービスに移行する

タスク 5. Products をマイクロサービスに移行する

新しい Products マイクロサービスを作成する

次に Products サービスを移行して、サービスの分割を続けます。以前と同じプロセスに従います。以下のコマンドを実行して Docker コンテナをビルドし、ビルドしたコンテナをデプロイして Kubernetes Service 経由で公開します。

1. Cloud Build を使用して Docker コンテナを作成する:

cd ~/monolith-to-microservices/microservices/src/products gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .

2. コンテナを GKE にデプロイする:

kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0

3. GKE コンテナを公開する:

kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082

4. Orders サービスの場合と同じ方法で、Products サービスのパブリック IP を見つける:

kubectl get service products

出力:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d

新しい Products マイクロサービスを指すようにモノリスを再構成するときは、次のステップで IP アドレスを使用します。

モノリスを再構成する

1. nano エディタを使用して、ローカル URL を新しいプロダクト マイクロサービスの IP アドレスに置き換えます。

cd ~/monolith-to-microservices/react-app nano .env.monolith

エディタを開くと、ファイルは以下のようになっています。

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products

2. REACT_APP_PRODUCTS_URL を新しい形式に置き換え、その際に IP アドレスを Products マイクロサービスのものにします。つまり、以下のようになります。

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products

3. Ctrl+O キー、ENTER キー、Ctrl+X キーを押して、ファイルを保存します。

4. ファイルに設定した URL に移動して、新しいマイクロサービスをテストします。Products マイクロサービスから JSON レスポンスが返されます。

5. 次に、モノリス フロントエンドを再ビルドし、ビルドプロセスを繰り返すことによって、モノリスのコンテナをビルドして GKE クラスタに再デプロイします。以下のコマンドを実行して、これらのステップを完了します。

6. モノリス構成ファイルを再ビルドする:

npm run build:monolith

7. Cloud Build を使用して Docker コンテナを作成する:

cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .

8. コンテナを GKE にデプロイする:

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0

9. ブラウザでモノリシック アプリケーションの Products ページに移動して、アプリケーションが Products マイクロサービスに到達していることを確認します。以下に示すように、すべての Products 名の先頭は MS- にする必要があります。

10. [進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Products をマイクロサービスに移行する

タスク 6. フロントエンドをマイクロサービスに移行する

移行プロセスの最後のステップは、フロントエンド コードをマイクロサービスに移動して、モノリスをシャットダウンすることです。このステップが完了すると、モノリスがマイクロサービス アーキテクチャに正常に移行されます。

新しいフロントエンド マイクロサービスを作成する

最後の 2 つのステップと同じ手順に沿って、新しいフロントエンド マイクロサービスを作成します。

以前は、モノリスを再ビルドするときに、モノリスを指すように構成を更新しました。今回は、フロントエンド マイクロサービスに同じ構成を使用する必要があります。

1. 次のコマンドを実行して、マイクロサービス URL 構成ファイルをフロントエンド マイクロサービス コードベースにコピーします。

cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build

2. これが完了したら、以前のステップと同じ手順に沿って操作します。以下のコマンドを実行して Docker コンテナをビルドし、ビルドしたコンテナをデプロイして Kubernetes Service 経由で公開します。

3. Google Cloud Build を使用して Docker コンテナを作成する:

cd ~/monolith-to-microservices/microservices/src/frontend gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .

4. コンテナを GKE にデプロイする:

kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0

5. GKE コンテナを公開する:

kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080

6. [進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 フロントエンドをマイクロサービスに移行する

モノリスを削除する

すべてのサービスがマイクロサービスとして実行されたので、モノリシック アプリケーションを削除できます。実際の移行には、DNS の変更なども伴います。DNS の変更は、アプリケーションの新しいフロントエンド マイクロサービスを指すように既存のドメイン名を取得するために行われます。

• 次のコマンドを実行して、モノリスを削除します。

kubectl delete deployment monolith kubectl delete service monolith

作業内容をテストする

すべてが正常に機能していることを確認するには、モノリス サービスの古い IP アドレスが現在は機能しておらず、フロントエンド サービスの新しい IP アドレスが新しいアプリケーションをホストしている必要があります。

• すべてのサービスと IP アドレスのリストを表示するには、次のコマンドを実行します。

kubectl get services

出力は次のようになります。

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m

フロントエンド マイクロサービスの外部 IP アドレスを決定したら、IP アドレスをコピーします。ブラウザにこの URL（http://203.0.113.0 など）を指定して、フロントエンドにアクセスできるかどうかをチェックします。ウェブサイトは、モノリスをマイクロサービスに分割する前のものと同じである必要があります。

お疲れさまでした

モノリシック アプリケーションをマイクロサービスに分割し、それらを Google Kubernetes Engine にデプロイしました。

クエストを完了する

このセルフペース ラボは、「Website on Google Cloud」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、このラボの修了後、次のクエストに登録すれば、すぐにクレジットを受け取ることができます。他の受講可能なクエストについては、Google Cloud Skills Boost カタログをご覧ください。

ハンズオン チャレンジラボを受講して、スキルを証明し、知識を確認することもできます。このクエストを完了したら、チャレンジラボを受講しましょう。

次のラボを受講する

事例紹介動画「Google Cloud でスケーラブルなウェブ アプリケーションをホストする」に進んで学習を続けるか、以下のおすすめをご確認ください。

• Compute Engine を使用した Google Cloud でのウェブアプリのホスティング
• 「Google Cloud で静的ウェブアプリをホストする」に関する動画

次のステップ / 補足資料

• Docker ドキュメント: https://docs.docker.com/
• Kubernetes のドキュメント
• Google Kubernetes Engine（GKE）のドキュメント
• Google Cloud Build のドキュメント
• Google Container Registry のドキュメント
• モノリスからマイクロサービスに移行する
• マイクロサービスのベスト プラクティス

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 9 月 20 日

ラボの最終テスト日: 2023 年 9 月 20 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。