VM ワークロードのデプロイの概要

このガイドでは、VM ランタイムを使用して、ベアメタル上の Google Distributed Cloud（GDC）エアギャップクラスタに仮想マシン（VM）ベースのワークロードをデプロイするために必要な概念的なコンテキストについて説明します。このガイドのワークロードは、オンプレミスハードウェアで使用可能なサンプルチケット発行システムプラットフォームです。

アーキテクチャ

リソース階層

GDC では、チケット発行システムを構成するコンポーネントを、顧客組織と同じように、運用チーム専用のテナント組織にデプロイします。組織は、まとめて管理されるクラスタ、インフラストラクチャリソース、アプリケーションワークロードの集合です。GDC インスタンス内の各組織は専用のサーバーセットを使用するため、テナント間の分離が強化されます。インフラストラクチャの詳細については、アクセス境界を設計するをご覧ください。

GDC エアギャップリソース階層

また、チケット発行システムのリソースをプロジェクトにまとめてデプロイして管理することで、ソフトウェアポリシーと適用を使用して組織内の論理的な分離を実現します。プロジェクト内のリソースは、ライフサイクルを通じて一緒に維持する必要があるコンポーネントを結合することを目的としています。

チケット発行システムは、ロードバランサを使用して、永続データを保存するデータベースサーバーに接続するアプリケーションサーバー間でトラフィックを転送する 3 階層アーキテクチャに従います。

3 層アーキテクチャの図

このアーキテクチャでは、各階層を個別に開発して維持できるため、スケーラビリティと保守性が向上します。また、懸念事項を明確に分離できるため、デバッグやトラブルシューティングが容易になります。これらの階層を GDC プロジェクト内にカプセル化すると、アプリケーションサーバーやデータベースサーバーなどのコンポーネントをまとめてデプロイして管理できます。

ネットワーキング

本番環境でチケット発行システムを実行するには、ノード障害が発生した場合に高可用性を実現するために、2 つ以上のアプリケーションサーバーをデプロイする必要があります。このトポロジでは、ロードバランサと組み合わせて、複数のマシンに負荷を分散してアプリケーションを水平方向にスケーリングすることもできます。GDC の Kubernetes ネイティブプラットフォームは、Cloud Service Mesh を使用して、チケット発行システムを構成するアプリケーションサーバーにトラフィックを安全にルーティングします。

Cloud Service Mesh は、サービスの管理、監視、保護を行うオープンソースプロジェクトに基づく Google の実装です。Cloud Service Mesh の次の機能を利用して、GDC でチケット販売システムをホストします。

ロードバランシング: Cloud Service Mesh は、トラフィックフローとインフラストラクチャのスケーリングを分離し、動的リクエストルーティングなどのさまざまなトラフィック管理機能を利用できるようにします。チケット発行システムには永続的なクライアント接続が必要なため、DestinationRules を使用してスティッキーセッションを有効にし、トラフィックルーティングの動作を構成します。

TLS 終端: Cloud Service Mesh は、TLS 証明書を使用して Ingress ゲートウェイを公開し、アプリケーションコードを変更することなく、mTLS（Mutual Transport Layer Security）を介してクラスタ内でトランスポート認証を提供します。
障害復旧: Cloud Service Mesh には、タイムアウト、サーキットブレーカー、アクティブヘルスチェック、制限付き再試行など、重要な障害復旧機能が多数用意されています。

Kubernetes クラスタ内では、標準の Service オブジェクトを使用して、アプリケーションサーバーとデータベースサーバーをネットワークに公開します。Service は、セレクタを使用してインスタンスをターゲットにする便利な方法を提供し、クラスタ対応 DNS サーバーを使用してクラスタ内で名前解決を提供します。

apiVersion: v1
kind: Service
metadata:
  name: http-ingress
spec:
  selector:
    app.kubernetes.io/component: application-server
  ports:
  - name: http
    port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: database-ingress
spec:
  selector:
    app.kubernetes.io/component: database-server
  ports:
  - name: mysql
    port: 3306

コンピューティング

チケット発行システムでは、オンプレミスインストールをホストするためにベアメタルまたは仮想マシンのいずれかを使用することが推奨されています。Google Distributed Cloud（GDC）の仮想マシン（VM）管理を使用して、アプリケーションサーバーとデータベースサーバーの両方を VM ワークロードとしてデプロイしました。Kubernetes リソースを定義することで、VirtualMachine と VirtualMachineDisk の両方を指定して、さまざまなタイプのサーバーのニーズに合わせてリソースを調整できました。VirtualMachineExternalAccess を使用すると、VM のデータ転送（イン）とデータ転送（アウト）を構成できます。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: vm1-boot-disk
spec:
  size: 100G
  source:
    image:
      name: ts-ticketing-system-app-server-2023-08-18-203258
      namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  labels:
    app.kubernetes.io/component: application-server
  name: vm1
  namespace: support
spec:
  compute:
    vcpus: 8
    memory: 12G
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: vm1-boot-disk

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: vm1
  namespace: support
spec:
  enabled: true
  ports:
   - name: ssh
     protocol: TCP
     port: 22

ゲスト OS イメージについては、コンプライアンスとセキュリティの要件を満たすカスタムイメージを作成しました。実行中の VM インスタンスには、VirtualMachineAccessRequest を使用して SSH 経由で接続できます。これにより、Kubernetes RBAC を介して VM への接続機能を制限し、カスタムイメージにローカルユーザーアカウントを作成する必要がなくなります。アクセスリクエストでは、有効期間（TTL）も定義します。これにより、時間ベースのアクセスリクエストで、自動的に期限切れになる VM を管理できます。

自動化

このプロジェクトの重要な成果物として、広範な自動化をサポートし、デプロイ間の構成のずれを減らすことができる、チケット発行システムのインスタンスを繰り返しインストールするアプローチを設計しました。

リリースパイプライン

アプリケーションサーバーイメージとデータベースサーバーイメージのカスタマイズは、ベースオペレーティングシステムイメージから始まり、各サーバーイメージに必要な依存関係をインストールするために必要に応じてベースイメージを変更します。ベース OS イメージは、オンプレミスインストールでチケット発行システムをホストするために広く採用されているため、選択しました。このベース OS イメージは、NIST-800-53 コントロールを満たす準拠イメージを提供するために必要な Security Technical Implementation Guides（STIG）を満たすために必要なセキュリティ強化機能も提供します。

継続的インテグレーション（CI）パイプラインでは、次のワークフローを使用してアプリケーションサーバーイメージとデータベースサーバーイメージをカスタマイズしました。

継続的インテグレーションワークフロー

デベロッパーがカスタマイズスクリプトまたはイメージの依存関係を変更すると、CI ツールで自動ワークフローがトリガーされ、GDC リリースにバンドルされる新しいイメージのセットが生成されます。イメージのビルドの一環として、OS の依存関係（yum update）も更新し、圧縮を使用してイメージをスパース化して、イメージを顧客環境に転送するために必要なイメージサイズを縮小します。

ソフトウェア開発ライフサイクル

ソフトウェア開発ライフサイクル（SDLC）は、組織がソフトウェアの計画、作成、テスト、デプロイを行うのに役立つプロセスです。明確に定義された SDLC に従うことで、組織はソフトウェアが一貫性のある再現可能な方法で開発されることを保証し、潜在的な問題を早期に特定できます。継続的インテグレーション（CI）パイプラインでのイメージのビルドに加えて、テストと品質保証のために、チケット発行システムのプレリリースバージョンを開発してステージングする環境も定義しました。

GDC プロジェクトごとに別のインスタンスのチケット発行システムをデプロイすることで、同じ GDC インスタンス上の既存のインスタンスに影響を与えることなく、変更を個別にテストできました。ResourceManager API を使用して、Kubernetes リソースを使用してプロジェクトを宣言的に作成および削除しました。

apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-staging

チャートのパッケージ化と、仮想マシンなどのインフラストラクチャをコードとして管理することと組み合わせることで、デベロッパーは本番環境インスタンスと並行して、変更の反復処理や新機能のテストを迅速に行うことができます。宣言型 API を使用すると、自動テスト実行フレームワークで定期的な回帰テストを実行し、既存の機能を確認することもできます。

操作性

運用性とは、システムを運用および保守する際の容易さです。これは、ソフトウェアアプリケーションの設計において重要な考慮事項です。効果的なモニタリングは、システムに大きな影響を与える前に問題を特定して対処できるため、運用性に貢献します。モニタリングは、改善の機会を特定し、サービスレベル目標（SLO）のベースラインを確立するためにも使用できます。

モニタリング

チケット発行システムを、ロギングや指標などの既存の GDC オブザーバビリティインフラストラクチャと統合しました。指標については、各 VM から HTTP エンドポイントを公開し、アプリケーションがアプリケーションサーバーとデータベースサーバーによって生成されたデータポイントをスクレイピングできるようにします。これらのエンドポイントには、アプリケーションノードエクスポータを使用して収集されたシステム指標と、アプリケーション固有の指標が含まれます。

各 VM で公開されたエンドポイントを使用して、MonitoringTarget カスタムリソースを使用してアプリケーションのポーリング動作を構成し、スクレイピング間隔を定義して指標にアノテーションを付けました。

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
  name: database-monitor
spec:
  podMetricsEndpoints:
    path:
      value: /metrics
    port:
      annotation: application.io/dbMetrics
    scrapeInterval: 60s

ロギングについては、各 VM にロギングと指標のプロセッサをインストールして構成し、関連するログを追跡してロギングツールにログデータを送信しました。このツールでは、データがインデックスに登録され、モニタリングインスタンスを介してクエリされます。監査ログは、コンプライアンスのために保持期間が延長された特別なエンドポイントに転送されます。コンテナベースのアプリケーションは、LoggingTarget カスタムリソースと AuditLoggingTarget カスタムリソースを使用して、ロギングパイプラインにプロジェクト内の特定のサービスからログを収集するように指示できます。

ロギングプロセッサとモニタリングプロセッサで使用可能なデータに基づいて、MonitoringRule カスタムリソースを使用してアラートを作成しました。これにより、この構成をチャートパッケージのコードとして管理できます。宣言型 API を使用してアラートとダッシュボードを定義すると、この構成をコードリポジトリに保存し、他のコード変更と同じコードレビューと継続的インテグレーションのプロセスに従うことができます。

障害モード

早期テストでは、リソース関連の障害モードがいくつか発見され、どの指標とアラートを最初に追加すべきかを優先順位付けするのに役立ちました。データベースの構成ミスにより、バッファテーブルが使用可能なメモリをすべて消費し、過剰なロギングによってアタッチされた永続ボリュームディスクが満杯になったため、まずメモリとディスクの使用率が高い状態をモニタリングすることから始めました。ストレージバッファサイズを調整し、ログローテーション戦略を実装した後、VM のメモリまたはディスク使用率が高くなると実行されるアラートを導入しました。

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
  name: monitoring-rule
spec:
  interval: 60s
  limit: 0
  alertRules:
  - alert: vm1_disk_usage
    expr:
      (node_filesystem_size_bytes{container_name="compute"} -
      node_filesystem_avail_bytes{container_name="compute"}) * 100 /
      node_filesystem_size_bytes{container_name="compute"} > 90
    labels:
      severity: error
      code: <a href="/distributed-cloud/hosted/docs/latest/gdch/gdch-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

システムの安定性を確認した後、チケット発行システム内のアプリケーション障害モードに焦点を当てました。アプリケーション内の問題のデバッグでは、各アプリケーションサーバー VM にセキュアシェル（SSH）を使用してチケット発行システムのログを確認する必要があることが多いため、これらのログをロギングツールに転送するようにアプリケーションを構成し、GDC のオブザーバビリティスタックを構築して、モニタリングインスタンス内のチケット発行システムのすべての運用ログをクエリできるようにしました。

一元化されたロギングにより、複数の VM から同時にログをクエリできるようになり、システムの各コンポーネントのビューを統合できました。

バックアップ

バックアップは、障害発生時にシステムを復元できるため、ソフトウェアシステムの運用性にとって重要です。GDC は、Kubernetes リソースを介して VM のバックアップと復元を提供します。VirtualMachineBackupPlanTemplate カスタムリソースを使用して VirtualMachineBackupRequest カスタムリソースを作成すると、各 VM にアタッチされた永続ボリュームをオブジェクトストレージにバックアップできます。バックアップは、設定された保持ポリシーに従って保持されます。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
  name: vm-backup-plan
spec:
  backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
  name: "db-vm-backup"
spec:
  virtualMachineBackupPlanTemplate: vm-backup-plan
  virtualMachine: db1
  virtualMachineBackupName: db-vm-backup

同様に、バックアップから VM の状態を復元するには、VirtualMachineRestoreRequest カスタムリソースを作成して、アプリケーションサーバーとデータベースサーバーの両方を復元します。このとき、どちらのサービスのコードや構成も変更しません。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
  name: vm-restore-1
spec:
  virtualMachineBackup: db-vm-backup
  restoreName: restore1
  restoredResourceName: db1

アップグレード

チケット発行システムとその依存関係のソフトウェアライフサイクルをサポートするために、3 種類のソフトウェアアップグレードを特定しました。ダウンタイムとサービスの中断を最小限に抑えるため、それぞれ個別に処理されます。

OS のアップグレード。
パッチバージョンやメジャーバージョンなどのプラットフォームアップグレード。
構成の更新。

OS のアップグレードでは、アプリケーションサーバーとデータベースサーバーの両方に対して新しい VM イメージを継続的にビルドしてリリースし、各 GDC リリースで配布します。これらのイメージには、セキュリティの脆弱性の修正と基盤となるオペレーティングシステムのアップデートが含まれています。

チケット発行システムプラットフォームのアップグレードでは、既存の VM イメージに更新を適用する必要があるため、不変インフラストラクチャに依存してパッチ適用とメジャーリリースバージョンの更新を行うことはできません。プラットフォームアップグレードの場合、パッチまたはメジャーリリースバージョンを開発環境とステージング環境でテストして検証してから、GDC リリースとともにスタンドアロンアップグレードパッケージをリリースします。

最後に、更新セットやその他のユーザーデータのチケット発行システム API を介して、ダウンタイムなしで構成の更新が適用されます。構成の更新は、開発環境とステージング環境で開発とテストを行い、GDC リリースプロセスで複数の更新セットをまとめてパッケージ化します。

統合

ID プロバイダ

お客様にシームレスなジャーニーを提供し、組織がユーザーをオンボーディングできるように、チケット発行システムを GDC で利用可能な複数の ID プロバイダと統合します。通常、企業や公共部門のお客様は、従業員に利用資格を付与したり取り消したりするために、独自の管理された ID プロバイダを使用しています。コンプライアンス要件と ID とアクセス管理の容易さから、これらのユーザーは既存の ID プロバイダを信頼できる情報源として使用し、従業員のチケット発行システムへのアクセスを管理したいと考えています。

このチケット発行システムは、マルチ ID プロバイダモジュールを介して SAML 2.0 プロバイダと OIDC プロバイダの両方をサポートしています。このモジュールは、アプリケーションサーバー VM イメージで事前に有効になっています。お客様は組織の ID プロバイダを通じて認証を行い、チケット発行システム内でユーザーが自動的に作成され、ロールが割り当てられます。

ID プロバイダサーバーへの下り（外向き）は ProjectNetworkPolicy カスタムリソースで許可されます。これにより、GDC の組織から外部サービスにアクセスできるかどうかが制限されます。これらのポリシーを使用すると、ネットワーク上でチケット発行システムがアクセスできるエンドポイントを宣言的に制御できます。

アラートの取り込み

ユーザーがログインしてサポートケースを手動で作成できるようにするだけでなく、システムアラートに応じてチケット発行システムのインシデントも作成します。

この統合を実現するため、オープンソースの Kubernetes Webhook をカスタマイズして、アプリケーションからアラートを受信し、Cloud Service Mesh を介して公開されたチケット発行システム API エンドポイントを使用してインシデントのライフサイクルを管理しました。

API キーは、ロールベースアクセス制御（RBAC）で制御される Kubernetes シークレットによってバックアップされた GDC シークレットストアを使用して保存されます。API エンドポイントやインシデントのカスタマイズフィールドなどの他の構成は、Kubernetes ConfigMap の Key-Value ストレージで管理されます。

メール

チケット発行システムには、メールサーバー統合機能が用意されており、お客様はメールベースのサポートを受けることができます。自動化されたワークフローにより、お客様からのメールがサポートケースに変換され、ケースリンクを含む自動返信がお客様に送信されます。これにより、サポートチームは受信トレイをより適切に管理し、メールリクエストを体系的に追跡して解決し、より優れたカスタマーサービスを提供できます。

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-traffic-from-ticketing-system
spec:
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - ticketing-system

メールを Kubernetes Service として公開すると、サービスディスカバリとドメイン名解決も提供され、メールサーバーバックエンドとチケット発行システムなどのクライアントがさらに分離されます。

コンプライアンス

監査ロギング

監査ログは、ソフトウェアの使用状況を追跡してモニタリングし、システムアクティビティの記録を提供することで、コンプライアンス体制に貢献します。監査ログは、承認されていないユーザーによるアクセス試行を記録し、API の使用状況を追跡し、潜在的なセキュリティリスクを特定します。監査ログは、医療保険の相互運用性と説明責任に関する法律（HIPAA）、ペイメント・カード情報に関するセキュリティ基準（PCI DSS）、サーベンスオクスリー法（SOX）などのコンプライアンス要件を満たしています。

GDC は、プラットフォーム内の管理アクティビティとアクセスを記録し、これらのログを構成可能な期間保持するシステムを提供します。AuditLoggingTarget カスタムリソースをデプロイすると、アプリケーションから監査ログを収集するようにロギングパイプラインが構成されます。

チケット発行システムでは、収集されたシステム監査イベントと、チケット発行システムのセキュリティ監査ログによって生成されたアプリケーション固有のイベントの両方に対して、監査ロギングターゲットを構成しました。両方のタイプのログは、一元化された Loki インスタンスに送信されます。ここで、クエリを作成し、モニタリングインスタンスでダッシュボードを表示できます。

アクセス制御

アクセス制御とは、アクセスをリクエストするユーザーまたはプロセスの ID に基づいて、リソースへのアクセスを許可または拒否するプロセスです。これにより、データが不正アクセスから保護され、承認されたユーザーのみがシステムを変更できるようになります。GDC では、Kubernetes RBAC を使用してポリシーを宣言し、チケット発行システムアプリケーションで構成されるシステムリソースに対する認可を適用します。

GDC で ProjectRole を定義すると、プリセットの認可ロールを使用して Kubernetes リソースへのきめ細かいアクセス権を付与できます。

apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
  name: ticketing-system-admin
  labels:
    resourcemanager.gdc.goog/rbac-selector: system
spec:
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    - events
    - pods/log
    - services
    verbs:
    - get
    - list

障害復旧

データベースレプリケーション

障害復旧（DR）の要件を満たすため、複数の GDC インスタンスにプライマリ / セカンダリ構成でチケット発行システムをデプロイします。このモードでは、通常、チケット発行システムへのリクエストはプライマリサイトに転送され、セカンダリサイトはデータベースのバイナリログを継続的に複製します。フェイルオーバーイベントが発生すると、セカンダリサイトが新しいプライマリサイトに昇格し、リクエストが新しいプライマリに転送されます。

データベースレプリケーション機能に基づいて、設定されたパラメータに基づいて GDC インスタンスごとにプライマリデータベースサーバーとレプリカデータベースサーバーの両方を構成します。

バイナリログの保持期間よりも長く実行されている既存のインスタンスでレプリケーションを有効にするには、データベースバックアップを使用してレプリカデータベースを復元し、プライマリデータベースからレプリケーションを開始します。

プライマリモードでは、アプリケーションサーバーとデータベースは現在と同じように動作しますが、プライマリデータベースはレプリケーションを有効にするように構成されます。次に例を示します。

バイナリログを有効にします。
サーバー ID を設定します。
レプリケーションユーザーアカウントを作成します。
バックアップの作成。

レプリカモードでは、アプリケーションサーバーはレプリカデータベースに直接接続しないように、チケット発行ウェブサービスを無効にします。レプリカデータベースは、プライマリデータベースからのレプリケーションを開始するように構成する必要があります。次に例を示します。

サーバー ID を設定します。
レプリケーションユーザーの認証情報と、ホストやポートなどのプライマリ接続の詳細情報を構成します。
バックアップから復元し、バイナリログの位置を再開します。

データベースレプリケーションでは、レプリカがプライマリデータベースに接続してレプリケーションを開始するために、ネットワーク接続が必要です。レプリケーション用にプライマリデータベースエンドポイントを公開するには、Cloud Service Mesh を使用して、サービスメッシュで TLS 終端をサポートする Ingress サービスメッシュを作成します。これは、チケット発行システムウェブアプリケーションで HTTPS データ転送を処理する方法と同様です。

VM ワークロードのデプロイの概要 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。