正規サービスのベスト プラクティス
注: 正規サービスは Cloud Service Mesh バージョン 1.6.8 以降で自動的にサポートされます。
正規サービスでは、さまざまな構成に移動できます。Cloud Service Mesh Service Dashboards を最適な状態で利用するには、サービス設定時に以下の標準的な利用方法を考慮してください。
- メッシュ全体で一意のサービス [namespace, name] を予約する。
- 正規サービスごとに 1 つのソフトウェア アプリケーションを定義する。
- 複数の環境（prod/stage/dev など）間で正規サービスをグループ化しない。
- Cloud Monitoring ダッシュボードを使用して、複数のサービスの概要を表示する。
- 正規サービスを本番環境に生かす計画を立てる。
メッシュ全体で一意のサービス [namespace, name] を予約する
あるクラスタまたはリージョンにデプロイされた正規サービスの Kubernetes Namespace と再帰サービスの名前が、別のクラスタまたはリージョンにデプロイされている場合、Cloud Service Mesh はこれらを同じ論理サービスとみなします。
この動作は、「同一性」というフリートの原則に一致しています。つまり、名前空間は同じ意味を持ち、フリート全体で同じエンティティを表す必要があります。
正規サービスごとに 1 つのソフトウェア アプリケーション
正規サービスは、単一の論理サービスまたはマイクロサービスを表します。これらは、同じソフトウェア アプリケーションとビジネス機能を表す、同種のバイナリ / ワークロードを対象にしています。
概念的に異なる複数のマイクロサービスをグループ化するために正規サービスを定義することもできますが、その場合、Service Dashboards は完全な値を提供しません。Service Dashboards には、互いに独立して動作している異なる類似コンポーネントの集約が表示されます。また構成方法も異なります。全体的な状態、パフォーマンス、構成を理解することは困難または不可能になります。
次の方法は必ずしも悪い手法ではありませんが、正規サービスが大きすぎる可能性があります。
- 1 つの正規サービスの異なるワークロード間でネットワーク トラフィックが存在する。
- 正規サービスが、異なるリリース スケジュールでデプロイされる複数のワークロードで構成されている。
- 組織内の別々のチームが、1 つの正規サービスの異なる部分を担当している。
環境間で正規サービスをグループにまとめない
多くのテクノロジー組織では、ソフトウェアの品質を確保し、リスクを制限するために、複数のデプロイ環境を採用しています。これらの環境には、開発、テスト、ステージング、本番、その他のサブセットなどがあります。
すべての環境で同じコンセプト サービスをデプロイしても、それを単一の正規サービスにすることはおすすめできません。これらのサービスは同一ではなく、組織における運用上の懸念や重点が同じレベルであるとは限りません。
たとえば、重要な本番環境のサービスで障害が発生すると、3AM のページとファイアファイトを引き起こす可能性があります。深夜に dev のデプロイが失敗しても、人に警告することはありません。パフォーマンス、キャパシティ、リリースの安全性についても同様です。
サービスを別の環境に分割する場合、次の 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、さらにはクラスタ全体などの下位レベルのリソースとは異なります。多くの場合、これらは本番環境システムの更新とメンテナンスで入れ替わります。