モノリシック VM の移行 - 最適化

ワークロードを VM からコンテナに移行すると、さまざまな可能性が広がります。コンテナを最適化して、モダナイゼーションツールとプロセスを適用できます。ワークロードのソースコードを変更してデプロイする作業が大幅に簡素化されます。同時に、ロギングやモニタリングなどの運用ツールとワークロードの連携も簡単になります。

目標

このチュートリアルでは、次の方法を学習します。

移行アーティファクトを確認する。
移行されたワークロードのソースコードと Dockerfile を変更する。
Cloud Operations を活用して、移行したワークロードのログをモニタリングして表示する。
モダナイゼーションのベストプラクティスを利用して、ワークロードをさらに最適化する。

始める前に

このチュートリアルは、移行とデプロイチュートリアルのフォローアップです。始める前に、VM の移行計画を作成してカスタマイズしてください。その後、コンテナ化されたアーティファクトをデプロイします。

移行アーティファクトを確認する

このセクションでは、移行プロセス中に作成されたアーティファクトとその役割について説明します。これらのファイルを変更して、今後のワークロードの強化と更新を行うことができます。

Dockerfile 構成を表示します。

cat  ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile

FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.12.1 as migrate-for-anthos-runtime
FROM gcr.io/my-project/ledgermonolith-service-non-runnable-base:8-25-2022--22-12-57 as source-content

COPY --from=migrate-for-anthos-runtime / /

ADD blocklist.yaml /.m4a/blocklist.yaml
ADD logs.yaml /code/config/logs/logsArtifact.yaml
ADD services-config.yaml /.m4a/

ENTRYPOINT [ "/.v2k.go" ]

このファイルには、ワークロードのコンテナイメージを生成するために必要なステップが記述されています。ライブラリの追加と更新、ソースコードの変更、新しいファイルの追加を行うことができます。この構成の最新のリファレンスについては、こちらをご覧ください。

deployment_spec.yaml ファイルを表示します。

cat  ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  creationTimestamp: null
  labels:
    app: ledgermonolith-service
    migrate-for-anthos-optimization: "true"
    migrate-for-anthos-version: v1.12.1
  name: ledgermonolith-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ledgermonolith-service
      migrate-for-anthos-optimization: "true"
      migrate-for-anthos-version: v1.12.1
  serviceName: ledgermonolith-service
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: ledgermonolith-service
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: v1.12.1
    spec:
      containers:
      - env:
        - name: HC_V2K_SERVICE_MANAGER
          value: "true"
        image: gcr.io/my-project/ledgermonolith-service:8-25-2022--22-12-57
        imagePullPolicy: IfNotPresent
        name: ledgermonolith-service
        resources: {}
        volumeMounts:
        - mountPath: /var/lib/postgresql
          name: ledgermonolith-db
          subPath: var/lib/postgresql
      volumes:
      - name: ledgermonolith-db
        persistentVolumeClaim:
          claimName: ledgermonolith-db
  updateStrategy: {}
. . .
. . .

このファイルには、移行されたワークロードの Kubernetes リソース定義が記述されています。ここでは、プロセスの StatefulSet、ポートの Service、移行されたデータベースを保持する PersistentVolumeClaim と PersistentVolume のペアを定義します。

このサンプル出力では、StatefulSet の Docker イメージセットは gcr.io/my-project/ledgermonolith-service:11-24-2021--16-22-59 です。これは移行プロセス中に生成され、元の VM のワークロードが含まれています。

ソースコードを変更する

次に、ワークロードのソースコードと Dockerfile を変更する方法について説明します。また、新しいコンテナイメージにタグを付けて push し、更新したワークロードをクラスタにデプロイします。

残高を照会したときに常に固定の残高が返されるように、台帳のメインコントローラを変更します。次のコマンドを実行します。これにより、Long balance = 12345L; が Long balance = info.getBalance(); になります。
```
sed -i 's/Long balance = info.getBalance();/Long balance = 12345L;/g' \
${HOME}/bank-of-anthos/src/ledgermonolith/src/main/java/anthos/samples/bankofanthos/ledgermonolith/LedgerMonolithController.java
```
サービスのソースコードのルートに移動し、Java アーティファクトをビルドします。
```
cd ${HOME}/bank-of-anthos/src/ledgermonolith/
mvn -f . package
```
注: Bank of Anthos をビルドするには、Java 17 以降が必要です。

Dockerfile に COPY コマンドを追加して、新しくビルドされた Java アーティファクトをコンテナイメージにコピーします。

echo "COPY ${HOME}/bank-of-anthos/src/ledgermonolith/target/ledgermonolith-1.0.jar /opt/monolith/ledgermonolith.jar" >> ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile

コンテナイメージをビルドして push します。

docker build . -t gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance --no-cache
docker push gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance

イメージのソースを最近 push したイメージに変更します。

sed -i 's/image:.*/gcr.io\/$PROJECT_ID\/ledgermonolith-service:static-balance/g' ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml

次のコマンドを使用すると、Pod の状態を確認できます。

kubectl get pods

ledgermonolith-service Pod が実行されるまでに数秒かかることがあります。

NAME                           READY   STATUS    RESTARTS   AGE
accounts-db-0                  1/1     Running   0          3m53s
contacts-d5dcdc87c-jbrhf       1/1     Running   0          3m53s
frontend-5768bd978-xdvpl       1/1     Running   0          3m53s
ledgermonolith-service-0       1/1     Running   0          1m11s
loadgenerator-8485dfd-582xv    1/1     Running   0          3m53s
userservice-8477dfcb46-rzw7z   1/1     Running   0          3m53s

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

kubectl get service frontend

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

ブラウザを開いて、前に確認した外部 IP アドレスのウェブページにアクセスします（HTTPS ではなく HTTP を使用してください）。
```
http://EXTERNAL_IP
```
デフォルトの認証情報でログインすると、トランザクションを確認できるはずです。ソースコードを変更した結果、残高が $123.45 と表示されます。

コンテナをモニタリングする

このセクションでは、ワークロードをコンテナに移行して、ログの閲覧や、アプリケーションとサービスのモニタリングなどのオブザーバビリティを改善する方法について確認します。

Google Cloud コンソールを開き、GKE プロダクトに移動して [ワークロード] をクリックします。
ledgermonolith-service ワークロードをクリックすると、現在のステータスと過去のステータスが表示されます。このページでは、メモリと CPU の使用状況、イベント、仕様を確認できます。
[ログ] タブをクリックして、ワークロードの履歴ログを表示します。この情報は、Cloud Logging を使用して表示することもできます。

その他の最適化

このほかにも、コンテナのエクスペリエンスを強化できる多くの最適化プロセスとアクティビティがあります。このチュートリアルでは、これらのアクティビティについて詳しく説明しませんが、いくつか例を挙げておきます。

セキュリティポリシーと ID ポリシーを追加する。ポリシーを設定することで、外部だけでなく、サービス間で発生するさまざまなワークロードと構成へのアクセスを制限できます。ロールベースのアクセス制御や、上り（内向き）アクセスと下り（外向き）アクセスなどのポリシーなどが含まれます。
継続的インテグレーションとデプロイのパイプラインと統合する。ワークロードを継続的インテグレーションとデプロイのパイプラインに統合することで、機能の開発とテストを高速化できます。
移行したワークロードをマイクロサービスに分割する。現在、移行された ledgermonolith-service ワークロードは 3 つの論理プロセスと 1 つのデータベースで構成されています。これらは複数のマイクロサービスに分割できるので、特定のサービスとプロセスを対象とした詳細なスケーリングとポリシーの設定が可能になります。これにより、開発や反復処理をスムーズに行うことができます。
サービスメッシュを構成する。ワークロード全体にサービスメッシュを実装すると、トラフィック管理、相互認証、オブザーバビリティなどの機能を利用できます。サービスメッシュは、1 つのクラスタ内または複数のクラスタ間で実装できます。
自動スケーリングとローリングアップデートを有効にする。Kubernetes では、自動スケーリングとローリングアップデートを設定することで、ワークロードをフォールトトレラントにし、可用性を高めることができます。自動スケーリングには、ノードと Pod の水平スケーリング、割り当てられたリソースの垂直スケーリングが含まれます。ワークロードの複数のレプリカをスケジューリングし、復元力のある方法で一度に 1 つずつアップグレードを行って、この機能を構成します。

まとめ

このチュートリアルでは、複数のサービスで構成されるライブアプリケーションを使用しました。この中には GKE クラスタ上で稼働するサービスもあれば、Compute Engine の VM 上で稼働するサービスもありました。これで、VM から GKE クラスタに、データベースとモノリシックサービスを正常に移行できました。このプロセスにより、コンピューティングコストが削減され、デベロッパーによる開発が容易になります。最後に、ソースコードとモダナイゼーションのベストプラクティスを迅速に繰り返す方法を確認しました。

クリーンアップ

Google Cloud で不要な課金を避けるため、作業が終了したら、このチュートリアルで使用したリソースを削除してください。このようなリソースとしては、次のものがあります。

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

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

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

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

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

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

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

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

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

次のステップ

移行計画のベストプラクティスについて学ぶ。