正規サービスのベスト プラクティス
注: 正規サービスは 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 で全期間にわたりそのサービスの 1 つの概念を維持するかどうかによって異なります。
VM インスタンス、Kubernetes Pod / Deployment、さらにはクラスタ全体などの下位レベルのリソースとは異なります。多くの場合、これらは本番環境システムの更新とメンテナンスで入れ替わります。