
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Create a GKE Cluster
/ 20
Deploy Existing Monolith
/ 20
Migrate Orders to a microservice
/ 20
Migrate Products to microservice
/ 20
Migrate Frontend to microservice
/ 20
モノリシック アプリケーションをマイクロサービス アーキテクチャに移行する理由は何でしょうか。アプリケーションをマイクロサービスに分割すると、次のような利点があります。その多くはマイクロサービスが疎結合であることに起因しています。
モノリスと比較した場合、マイクロサービスには次のような欠点があります。
このラボでは、既存のモノリシック アプリケーションを Google Kubernetes Engine クラスタにデプロイし、それをマイクロサービスに分割します。Kubernetes は、コンテナの管理、ホスト、スケーリング、デプロイを行うプラットフォームです。コンテナは移植性の高い手法で、コードをパッケージ化して実行します。それぞれのマイクロサービスを独自のコンテナ内で実行できるので、この手法はマイクロサービスのパターンにも適しています。
まず、モノリスを一度に 3 つのマイクロサービスに分割します。マイクロサービスには、「Orders(注文)」、「Products(プロダクト)」、「フロントエンド」が含まれます。Cloud Build を使用して各マイクロサービスの Docker イメージをビルドします。次に、Kubernetes Service タイプの LoadBalancer を使用して Google Kubernetes Engine(GKE)にマイクロサービスをデプロイして公開します。各サービスに対してこれを行い、同時にモノリスからそれらをリファクタリングします。プロセス中は、モノリスを削除する最後の段階まで、モノリスとマイクロサービスの両方が実行されます。
こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します)。
ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [ユーザー名] を確認できます。
[次へ] をクリックします。
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [パスワード] を確認できます。
[次へ] をクリックします。
その後次のように進みます。
その後、このタブで Google Cloud コンソールが開きます。
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
[承認] をクリックします。
出力は次のようになります。
出力:
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
デフォルトのゾーンとプロジェクト構成を構成します。
シンプルなスタートページとプロダクト ページ、注文履歴ページを備えた架空の e コマース ウェブサイトの既存のモノリシック アプリケーションを使用します。git リポジトリからソースのクローンを作成するだけで、後はマイクロサービスへの分割と Google Kubernetes Engine(GKE)へのデプロイに集中できます。
このスクリプトの実行には数分かかる場合があります。
作業用の開発環境が整ったので、モノリスをデプロイするための Kubernetes クラスタが必要になります(最終的にはマイクロサービスもデプロイします)。クラスタを作成する前に、適切な API が有効になっていることを確認してください。
クラスタの作成には数分かかることがあります。
出力:
Google Cloud コンソールで Kubernetes クラスタと関連情報を表示するには、ナビゲーション メニューで [Kubernetes Engine] までスクロールし、[クラスタ] をクリックします。
fancy-cluster というクラスタが表示されます。
これで完了です。最初の Kubernetes クラスタが作成されました。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
このラボで取り上げるのはモノリスのマイクロサービスへの分割であるため、モノリシック アプリケーションを起動して実行する必要があります。
出力は次のようになります。
出力に外部 IP が <pending>
と表示される場合は、少し待ってからコマンドを再度実行します。
モノリスの外部 IP アドレスを決定したら、その IP アドレスをコピーします。ブラウザにこの URL(http://203.0.113.0 など)を指定して、モノリスにアクセスできるかどうかをチェックします。
モノリシック ウェブサイトのスタートページが表示されます。スタートページは、フロントエンド マイクロサービスによって後で提供される静的ページです。これで、モノリスが完全に Kubernetes で動作するようになりました。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
モノリス ウェブサイトを GKE で稼働させることができたので、各サービスのマイクロサービスへの分割を開始します。通常、プランニング業務では小さなまとまりに分割するサービスの選定を行います。ビジネス ドメインなどのアプリケーションの特定の部分が対象となります。
このラボでは例を作成して、ビジネス ドメイン関連の各サービス「Orders(注文)」、「Products(プロダクト)」、「フロントエンド」に分割します。コードはすでに移行されているため、Google Kubernetes Engine(GKE)でのサービスのビルドとデプロイに集中できます。
最初に分割するサービスは、Orders サービスです。提供された個別のコードベースを利用し、このサービス用の個別の 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 分ほどかかります。完了すると、ターミナルに次のような結果が出力されます。
ビルド ID をクリックすると、そのビルドのすべての詳細が表示されます。詳細にはログ出力も含まれます。
[ビルドの詳細] ページの右のセクションで [実行の詳細] タブをクリックすると、作成したコンテナ イメージが表示されます。
ウェブサイトをコンテナ化して、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 をクラスタに作成します。
Pod のステータスが [実行中] になるまで少し時間がかかることがあります。
出力:
現在の Deployment、必要な Pod 数が 1 の Replicaset
、実行中の Pod を確認できます。すべて正常に作成されていることがわかります。
Cloud Console のナビゲーション メニューから [Kubernetes Engine] > [ワークロード] に移動すると、Kubernetes Deployment を表示することもできます。
アプリケーションを 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 にトラフィックをルートする必要があります。
GKE は、Deployment ではなく Service リソースに外部 IP アドレスを割り当てます。
kubectl get service
コマンドを使用して Service を調べます。出力:
アプリケーションの外部 IP アドレスを確認したら、その IP アドレスをコピーします。新しい Orders サービスを指すようにモノリスを変更するときは、次のステップで使用できるように保存します。
Orders サービスをモノリスから削除したため、新しい外部の Orders マイクロサービスを指すようにモノリスを変更する必要があります。
モノリスを分割する場合は、単一のコードベースから複数のマイクロサービスへのコードの一部を削除して、それらを個別にデプロイします。マイクロサービスは別のサーバーで実行されているため、サービス URL を絶対パスとして参照することはできません。Order マイクロサービスのサーバー アドレスへのルートが必要です。その場合、分割された各サービスの URL を更新するために、モノリス サービスへのダウンタイムが必要になります。マイクロサービスの移行プロセス中にマイクロサービスとモノリスを本番環境に移行する際は、このダウンタイムを考慮してください。
新しい Orders マイクロサービスの IP アドレスを指すように、モノリスの構成ファイルを更新する必要があります。
nano
エディタを使用して、ローカル URL を Orders マイクロサービスの IP アドレスに置き換えます。エディタを開くと、ファイルは以下のようになっています。
REACT_APP_ORDERS_URL
を新しい形式に置き換え、その際に IP アドレスを Orders マイクロサービスのものにします。つまり、以下のようになります。Ctrl+O
キー、ENTER
キー、Ctrl+X
キーを押して、nano エディタにファイルを保存します。
ファイルに設定した URL に移動して、新しいマイクロサービスをテストします。Orders マイクロサービスから JSON レスポンスが返されます。
次に、モノリス フロントエンドを再ビルドし、ビルドプロセスを繰り返すことによって、モノリスのコンテナをビルドして GKE クラスタに再デプロイします。
次に Products サービスを移行して、サービスの分割を続けます。以前と同じプロセスに従います。以下のコマンドを実行して Docker コンテナをビルドし、ビルドしたコンテナをデプロイして Kubernetes Service 経由で公開します。
出力:
新しい Products マイクロサービスを指すようにモノリスを再構成するときは、次のステップで IP アドレスを使用します。
nano
エディタを使用して、ローカル URL を新しいプロダクト マイクロサービスの IP アドレスに置き換えます。エディタを開くと、ファイルは以下のようになっています。
REACT_APP_PRODUCTS_URL
を新しい形式に置き換え、その際に IP アドレスを Products マイクロサービスのものにします。つまり、以下のようになります。Ctrl+O
キー、ENTER
キー、Ctrl+X
キーを押して、ファイルを保存します。
ファイルに設定した URL に移動して、新しいマイクロサービスをテストします。Products マイクロサービスから JSON レスポンスが返されます。
次に、モノリス フロントエンドを再ビルドし、ビルドプロセスを繰り返すことによって、モノリスのコンテナをビルドして GKE クラスタに再デプロイします。以下のコマンドを実行して、これらのステップを完了します。
モノリス構成ファイルを再ビルドする:
移行プロセスの最後のステップは、フロントエンド コードをマイクロサービスに移動して、モノリスをシャットダウンすることです。このステップが完了すると、モノリスがマイクロサービス アーキテクチャに正常に移行されます。
最後の 2 つのステップと同じ手順に沿って、新しいフロントエンド マイクロサービスを作成します。
以前は、モノリスを再ビルドするときに、モノリスを指すように構成を更新しました。今回は、フロントエンド マイクロサービスに同じ構成を使用する必要があります。
これが完了したら、以前のステップと同じ手順に沿って操作します。以下のコマンドを実行して Docker コンテナをビルドし、ビルドしたコンテナをデプロイして Kubernetes Service 経由で公開します。
Google Cloud Build を使用して Docker コンテナを作成する:
すべてのサービスがマイクロサービスとして実行されたので、モノリシック アプリケーションを削除できます。実際の移行には、DNS の変更なども伴います。DNS の変更は、アプリケーションの新しいフロントエンド マイクロサービスを指すように既存のドメイン名を取得するために行われます。
すべてが正常に機能していることを確認するには、モノリス サービスの古い IP アドレスが現在は機能しておらず、フロントエンド サービスの新しい IP アドレスが新しいアプリケーションをホストしている必要があります。
出力は次のようになります。
フロントエンド マイクロサービスの外部 IP アドレスを決定したら、IP アドレスをコピーします。ブラウザにこの URL(http://203.0.113.0 など)を指定して、フロントエンドにアクセスできるかどうかをチェックします。ウェブサイトは、モノリスをマイクロサービスに分割する前のものと同じである必要があります。
モノリシック アプリケーションをマイクロサービスに分割し、それらを Google Kubernetes Engine にデプロイしました。
このセルフペース ラボは、「Website on Google Cloud」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、このラボの修了後、次のクエストに登録すれば、すぐにクレジットを受け取ることができます。他の受講可能なクエストについては、Google Cloud Skills Boost カタログをご覧ください。
ハンズオン チャレンジラボを受講して、スキルを証明し、知識を確認することもできます。このクエストを完了したら、チャレンジラボを受講しましょう。
事例紹介動画「Google Cloud でスケーラブルなウェブ アプリケーションをホストする」に進んで学習を続けるか、以下のおすすめをご確認ください。
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2023 年 9 月 20 日
ラボの最終テスト日: 2023 年 9 月 20 日
Copyright 2025 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。
このコンテンツは現在ご利用いただけません
利用可能になりましたら、メールでお知らせいたします
ありがとうございます。
利用可能になりましたら、メールでご連絡いたします
One lab at a time
Confirm to end all existing labs and start this one