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

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

アーキテクチャ

リソース階層

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

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

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

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

3 層アーキテクチャの図

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

ネットワーキング

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

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

  • ロード バランシング: Cloud Service Mesh は、トラフィック フローをインフラストラクチャのスケーリングから切り離し、動的なリクエスト ルーティングなど、多くのトラフィック管理機能を実現します。チケット販売システムでは永続的なクライアント接続が必要なため、DestinationRules を使用してスティッキー セッションを有効にし、トラフィック ルーティングの動作を構成します。

  • TLS 終端: Cloud Service Mesh は、TLS 証明書を使用して Ingress ゲートウェイを公開し、アプリケーション コードを変更することなく、mTLS（相互 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

コンピューティング

この発券システムでは、オンプレミス インストールのホストにベアメタルまたは仮想マシンのいずれかを使用することが推奨されています。そこで、GDC Virtual 仮想マシン（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 コントロールに準拠したイメージを提供するために必要なセキュリティ技術実装ガイド（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 を使用すると、自動テスト実行フレームワークで定期的な回帰テストを実行し、既存の機能を検証することもできます。

Operability（車両の稼働状態）

操作性とは、システムの操作とメンテナンスの容易さのことです。これは、ソフトウェア アプリケーションの設計において重要な考慮事項です。効果的なモニタリングは、システムに大きな影響を与える前に問題を特定して対処できるため、運用性に貢献します。モニタリングは、改善の機会を特定し、サービスレベル目標（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: TS-R0001
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

システムの安定性を確認した後、チケット発行システム内のアプリケーション障害モードに焦点を移しました。アプリケーション内の問題をデバッグするには、各アプリケーション サーバー VM に Secure Shell（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 種類のソフトウェア アップグレードを特定しました。それぞれを個別に処理して、ダウンタイムとサービスの中断を最小限に抑えます。

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

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

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

最後に、更新セットやその他のユーザーデータ用のチケット発行システム API を介して、ダウンタイムなしで構成の更新が適用されます。Google は、開発環境とステージング環境で構成の更新を開発してテストしてから、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 Secret を基盤とする GDC Secret ストアを使用して保存されます。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）、Payment Card Industry データ セキュリティ基準（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 インスタンスごとにプライマリ データベース サーバーとレプリカ データベース サーバーの両方を構成します。

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

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

  1. バイナリログを有効にします。

  2. サーバー ID を設定します。

  3. レプリケーション ユーザー アカウントを作成します。

  4. バックアップを作成する。

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

  1. サーバー ID を設定します。

  2. レプリケーション ユーザーの認証情報と、ホストやポートなどのプライマリ接続の詳細を構成します。

  3. バックアップから復元すると、バイナリログの位置が再開されます。

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