モノリス VM の移行 - 概要と設定

重要: Google Cloud コンソールの Migrate to Containers UI、migctl、処理クラスタを使用してワークロードを Google Cloud に移行する CRD は非推奨になりました。2024 年 5 月まではサポートが提供されますが、それ以降は利用できなくなります。Migrate to Containers をまだ使用していない場合は、Migrate to Containers CLI を使用してローカルマシンで移行を実施してください。詳細については、Migrate to Containers CLI のアーキテクチャをご覧ください。

このチュートリアルでは、まだ完全にモダナイズされていないサンプル アプリケーションの概要と、そのサービスのすべてを GKE に移行するために必要な手順について説明します。このアプリケーションは、サービスの一部を GKE クラスタで実行し、残りのサービスはモノリスとして VM で実行します。

このチュートリアルは、次の 4 つのセクションから構成されます。

1. 概要と設定。

   このセクションでは、このチュートリアルの背景を確認し、チュートリアルの残りの部分に進むために必要なインフラストラクチャとツールを設定します。

2. 調査と評価（Day 0）

   次に、調査ツールを使用して VM の移行への適性を評価し、移行に備えて処理クラスタを作成します。

3. 移行とデプロイ（Day 1）。

   評価したら、モノリシック VM の移行計画を作成し、イメージとデータの完全な移行を行い、新しく作成したアーティファクトを Kubernetes にデプロイする方法を確認します。

4. 最適化（Day 2）。

   最後に、ソースコードの変更をコンテナ化された環境にすばやくデプロイする方法と、マイクロサービス、オブザーバビリティ、モダナイゼーションのベスト プラクティスについて確認します。

背景

現在でも、大企業における従来型アプリケーションの多くはモノリシックであり、専用のテクノロジー スタックやコンピューティング負荷の高い仮想マシン（VM）で稼働しています。こうしたサービスは、大規模アプリケーションの仕組みにとって重要なことが多く、稼働費用やライセンス料など多額の運用コストが発生します。さらにその性質上、VM は、GKE クラスタ内のコンテナなど、より軽いソリューションへの移行が難しい場合があります。

このチュートリアルでは、簡単かつコードを一切変更せずモノリス サービスとそのデータベースを VM から GKE 環境に移行するために、Migrate to Containers を活用する方法について説明します。これにより、運用コストが削減され、開発がスムーズに行えるようになります。次に、ソースコードの変更とモダナイゼーションのベスト プラクティスをデプロイして、新しく移行されたワークロードを活用する方法について確認します。

ここで使用するサンプル アプリケーションは、リテール バンキング サービスをシミュレートする Bank of Anthos で、トランザクションを処理する独自のネットワークとデータベースを備えています。

Bank of Anthos のウェブ フロントエンド、ユーザー、連絡先サービスは、コンテナ化済みのマイクロサービスで、アカウント データベースとともに GKE 上のコンテナで動作します。ただし、モノリシックのトランザクション台帳とトランザクション データベースは、まだ単独の仮想マシン上で動作しています。現在のワークフローを中断することなく運用コストを削減するには、この VM が GKE へ簡単に移行できる必要があります。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

• GKE
• Compute Engine

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

必要なツール

このチュートリアルは、このチュートリアルで使用する gcloud、kubectl、git、migctl コマンドライン ツールと一緒にプリインストールされる Cloud Shell を使用して進めることができます。Cloud Shell を使用すると、これらのコマンドライン ツールをワークステーションにインストールする必要はありません。

Cloud Shell を使用するには:

1. Google Cloud コンソールに移動します。

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

   Google Cloud コンソールの一番下にある新しいフレームの中で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。

   

必要な API

Compute Engine のサポート有効化

1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

3. Google Cloud プロジェクトで課金が有効になっていることを確認します。

4. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

5. Google Cloud プロジェクトで課金が有効になっていることを確認します。

6. Compute Engine API を有効にします。

   API の有効化

GKE の有効化と設定

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にします。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得します。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

Bank of Anthos のデプロイ

このセクションでは、台帳のモノリス VM を Compute Engine にデプロイし、Bank of Anthos の残りのサービスを動作させる GKE クラスタを作成します。

1. Bank of Anthos モノリスのデプロイに必要な環境変数を設定します。

   export PROJECT_ID=PROJECT_ID
   export ZONE=COMPUTE_ZONE
   

2. Bank of Anthos リポジトリのクローンをホーム ディレクトリに作成します。

   git clone https://github.com/GoogleCloudPlatform/bank-of-anthos ${HOME}/bank-of-anthos
   

3. Bank of Anthos の台帳モノリスを Compute Engine にデプロイします。

   cd ${HOME}/bank-of-anthos
   make monolith-deploy
   

   このコマンドは、Bank of Anthos のソース モノリス イメージを使用して Compute Engine に VM を作成します。

   注: make monolith-deploy は、デフォルト ネットワークが作成されていることを前提としています。これがデフォルトの動作ですが、ポリシー制約により、新しいプロジェクトでデフォルト ネットワークを作成できないことがあります（特に、組織ポリシー constraints/compute.skipDefaultNetworkCreation）。

4. ポート 8080 で VM インスタンスへのリクエストを許可するファイアウォール ルールを作成します。これは、フロントエンド サービスがソースモノリスとの通信に使用します。

   gcloud compute --project=PROJECT_ID firewall-rules create default-allow-http \
     --direction=INGRESS --priority=1000 --network=default --action=ALLOW \
     --rules=tcp:8080 --source-ranges=0.0.0.0/0 --target-tags=monolith
   

   注: プロジェクトにすでに上記のファイアウォールがある場合は、再作成するか編集して、ターゲットタグに monolith を追加する必要があります。

5. 残りの Bank of Anthos サービスをホストする GKE クラスタを作成します。

   gcloud container clusters create boa-cluster \
     --zone COMPUTE_ZONE --project=PROJECT_ID \
     --machine-type=e2-standard-4 --num-nodes=4 \
     --subnetwork=default
   

6. クラスタを作成したら、その認証情報を取得して、Kubernetes コンテキストがそのクラスタを指すように設定します。

   gcloud container clusters get-credentials boa-cluster \
     --zone COMPUTE_ZONE --project=PROJECT_ID
   

7. プロジェクト ID は、GKE サービスが台帳モノリス VM と通信する方法を記述するために使用される ConfigMap に置き換えます。

   sed -i 's/\[PROJECT_ID\]/'PROJECT_ID'/g' ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
   

   このファイルを表示して、変更が正常に適用されていることを確認します。

   cat ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml | grep ADDR
   

   プロジェクト ID が、台帳サービスのホストに挿入されていることを確認できます。

   TRANSACTIONS_API_ADDR: "ledgermonolith-service.c.PROJECT_ID.internal:8080"
   BALANCES_API_ADDR: "ledgermonolith-service.c.PROJECT_ID.internal:8080"
   HISTORY_API_ADDR: "ledgermonolith-service.c.PROJECT_ID.internal:8080"
   CONTACTS_API_ADDR: "contacts:8080"
   USERSERVICE_API_ADDR: "userservice:8080
   

8. さまざまな Bank of Anthos サービスをクラスタに適用します。

   cd ${HOME}/bank-of-anthos/
   kubectl apply -f src/ledgermonolith/config.yaml
   kubectl apply -f extras/jwt/jwt-secret.yaml
   kubectl apply -f kubernetes-manifests/accounts-db.yaml
   kubectl apply -f kubernetes-manifests/userservice.yaml
   kubectl apply -f kubernetes-manifests/contacts.yaml
   kubectl apply -f kubernetes-manifests/frontend.yaml
   kubectl apply -f kubernetes-manifests/loadgenerator.yaml
   

   Pod の状態は、次のコマンドで確認できます。

   kubectl get pods
   

   すべての Pod が起動して、動作するまで数分かかることがあります。

   NAME                           READY   STATUS    RESTARTS   AGE
   accounts-db-0                  1/1     Running   0          51s
   contacts-d5dcdc87c-5l9xf       1/1     Running   0          50s
   frontend-5768bd978-s6vkq       1/1     Running   0          50s
   loadgenerator-8485dfd-wjvst    1/1     Running   0          50s
   userservice-8477dfcb46-htw96   1/1     Running   0          51s
   

9. すべての Pod が Running に設定されたら、frontend LoadBalancer サービスの外部 IP アドレスを確認できます。

   kubectl get service frontend
   

   NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
   frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   4m
   

10. これで、ブラウザを開いて上記外部 IP アドレスのウェブページにアクセスできます（HTTPS ではなく HTTP を使用してください）。

    http://EXTERNAL_IP
    

    デフォルトの認証情報でログインすると、ダッシュボードにトランザクションが表示されます。表示されているトランザクションは、現在 VM でホストされている台帳モノリスから送信されているものです。

    

クリーンアップ

不要な Google Cloud 料金が発生しないようにするには、このチュートリアルで使用したリソースを、使用し終わったらすぐに削除する必要があります。こうしたリソースとしては、次のものがあります。

• boa-cluster GKE クラスタ
• ledgermonolith-service Compute Engine VM

これらのリソースを手動で削除するか、以下の手順に沿ってプロジェクトを削除します。これにより、すべてのリソースが削除されます。

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Google Cloud コンソールで、[リソースの管理] ページに移動します。

[リソースの管理] に移動

プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。

ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

必要な API を有効にして Bank of Anthos の設定をデプロイしたので、チュートリアルの次のセクション（調査と評価）に進みましょう。次のセクションでは、移行調査ツールを使用して、Migrate to Containers ツールを使用する移行に VM が適しているかどうかを評価する方法を説明します。

チュートリアルをここで終了する場合は、Google Cloud のプロジェクトとリソースを忘れずにクリーンアップしてください。