正規サービスのベスト プラクティス
注: 正規サービスは Cloud Service Mesh バージョン 1.6.8 以降で自動的にサポートされます。
正規サービスは、多様な構成パターンに対応しています。Cloud Service Mesh サービス ダッシュボードを最大限に活用するため、サービスを設定する際に以下の標準的な手法を検討してください。
- サービス [namespace, name] がメッシュ全体で重複しないようにする。
- 正規サービスごとに 1 つのソフトウェア アプリケーションを定義する。
- 異なる環境（本番 / ステージング / 開発環境など）を同じ正規サービスにまとめない。
- Cloud Monitoring ダッシュボードを使用して、複数のサービスの高レベルのビューを作成する。
- 正規サービスを本番環境に生かす計画を立てる。
サービス [namespace, name] がメッシュ全体で重複しないようにする
あるクラスタまたはリージョンにデプロイされている正規サービスが、別のクラスタまたはリージョンにデプロイされている正規サービスと同じ Kubernetes Namespace および正規サービス名を持つ場合、Cloud Service Mesh はそれらを同じ論理サービスとみなします。
この動作は、「同一性」というフリートの原則に一致しています。この原則は、「ある特定の名前空間は、フリート全体を通して同じ意味を持ち、同じエンティティを表す必要がある」というものです。
正規サービスごとに 1 つのソフトウェア アプリケーション
正規サービスは、単一の論理サービスまたはマイクロサービスを表します。つまり、正規サービスは、同じソフトウェア アプリケーションやビジネス機能を表す同種のバイナリ / ワークロードを包含するように設計されています。
概念的に異なる複数のマイクロサービスをグループ化する正規サービスを定義することも可能ですが、その場合、サービス ダッシュボードの価値は十分に発揮されません。そこに表示されるのは、互いに独立して動作し、構成も大きく異なる異種のコンポーネントの集計結果となります。これでは、全体的な状態、パフォーマンス、構成を把握することは困難であり、不可能でさえあります。
次の方法は必ずしも悪い手法ではありませんが、正規サービスが大きすぎる可能性があります。
- 1 つの正規サービスの異なるワークロード間でネットワーク トラフィックが存在する。
- 正規サービスが、異なるリリース スケジュールでデプロイされる複数のワークロードで構成されている。
- 組織内の別々のチームが、1 つの正規サービスの異なる部分を担当している。
異なる環境を同じ正規サービスにまとめない
多くのテクノロジー組織では、ソフトウェアの品質を確保し、リスクを制限するために、複数のデプロイ環境を採用しています。これらの環境には、開発、テスト、ステージング、本番、その他のサブセットなどがあります。
たとえそれぞれの環境に同じ概念のサービスをデプロイしていても、それらを単一の正規サービスにすることは望ましくありません。これらのサービスは同一ではなく、組織における運用上の懸念や重点が同じレベルであるとは限りません。
たとえば、重要な本番環境のサービスで障害が発生した場合、午前 3 時に緊急呼び出しがかかり、障害に対処しなければならない可能性があります。しかし、深夜に本番環境のデプロイメントで障害が発生しても、誰かに知らせる必要はありません。パフォーマンス、キャパシティ、リリースの安全性についても同じことが言えます。
サービスを別の環境に分割する場合、次の 3 つの方法があります。厳密さに欠けますが簡単に行う方法もあれば、複雑ですが厳密な分類が可能な方法もあります。
- 複数のサービス名（
payments-prodやpayments-testなど）を使用して分割する。 - 複数の名前空間（
billing-teamやbilling-team-testなど）を使用して分割する。 - 複数のフリートを使用して分割する。環境ごとに 1 つずつ使用します。
任意の集計で Cloud Monitoring のカスタム ダッシュボードを使用する
データ集計のために正規サービスの規模を意図的に拡大するのではなく、Cloud Monitoring ダッシュボードを使用して一度で複数の論理サービスの高レベルのビューを作成します。
正規サービスは長期保存を目的としている
正規サービスの開発、探索、テスト以外のケースでは、正規サービスはグローバルで高レベルの論理サービスを表します。これらのサービスは変化が遅く、長期的に存在する傾向があります。これには、サービス名の変更は含まれません。名前は変更できますが、変更すると指標、SLO、ログに影響します。ただし、Display name フィールドは中断なく自由に調整できます。
通常、新しい正規サービスは新しいソフトウェアや更新されたソフトウェアを表しますが、正規サービスの廃止はサービスのサポート終了を意味します。Cloud Service Mesh 内のあるサービスについて、そのサービスの存続期間全体を通してサービスの単一の概念 / 定義を維持しなければ、サービス、プラン、プロジェクト キャパシティの過去の実績を確認することはできません。
これは、VM インスタンスや Kubernetes Pod / Deployment などの低レベルのリソース、さらにはクラスタ全体とは対照的であることに注意してください。これらのリソースは、本番環境システムの更新やメンテナンスの一環として頻繁に追加・削除されます。