service mesh マイクロサービスアーキテクチャの開発からカナリアリリースまでの全プロセスベストプラクティス（後編）¶

概要¶

本編では、カナリアリリースの全体的な状況を紹介し、Guance を使用してマイクロサービスのメトリクス、トレース、ログを可観測にします。以下、Rancher に関する操作はすべて k8s-solution-cluster クラスターで行うものとし、その都度記載は省略します。

カナリアリリース¶

カナリアリリースを実現するために、マイクロサービスをデプロイする Deployment に app=reviews というラベルを追加し、マイクロサービス名を識別します。最初にデプロイするバージョンには version=v1 のラベルを、2 回目にデプロイするバージョンには version=v2 のラベルを追加します。これにより、ラベルに基づいて各バージョンへのトラフィックの割合を制御できます。例えば、v2 をリリースした後、90% のトラフィックを v1 バージョンに、10% のトラフィックを v2 バージョンに流し、検証に問題がなければ、トラフィックを完全に v2 バージョンに切り替え、v1 バージョンを停止します。これでリリースは完了です。

手順1： reviews の削除¶

前編の操作では、Gitlab-CI の自動デプロイを説明するために、reviews の 3 つのバージョンをデプロイしました。今回の操作の前に、これら 3 つのデプロイバージョンを削除する必要があります。『Rancher』にログインし、クラスター内で『ワークロード』→『Deployments』と進み、reviews-v1 を見つけて、右側の『削除』を選択します。同様に reviews-v2、reviews-v3 を削除します。

手順2： reviews-v1 のリリース¶

『gitlab』にログインし、bookinfo-views プロジェクトを見つけて、.gitlab-ci.yml ファイルの APP_VERSION の値を "v1" に変更し、コードをコミットします。『Rancher』にログインし、クラスター内で『ワークロード』→『Deployments』と進むと、reviews-v1 のデプロイが完了していることが確認できます。

手順3： DestinationRule の作成¶

ターゲットアドレスを定義し、reviews Service のサービスディスカバリ時に subsets を v1 と v2 に分割します。このリソースを kubectl でデプロイするために、以下の内容を destination-rule-reviews.yaml ファイルに保存します。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
  namespace: prod
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

kubectl create -f destination-rule-reviews.yaml

手順4： VirtualService の作成¶

v2 をリリースする前に、まずトラフィックを完全に v1 に切り替えます。以下の内容を virtual-service-reviews.yaml ファイルに保存します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  namespace: prod
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

kubectl create -f virtual-service-reviews.yaml

http://8.136.193.105:32156/productpage にアクセスします。

手順5： reviews-v2 のリリース¶

『gitlab』にログインし、bookinfo-views プロジェクトを見つけて、.gitlab-ci.yml ファイルの APP_VERSION の値を "v2" に変更し、コードをコミットします。『Rancher』にログインし、クラスター内で『ワークロード』→『Deployments』と進むと、reviews-v2 のデプロイが完了していることが確認できます。v2 がリリースされても、この時点で http://8.136.193.105:32156/productpage にアクセスすると、reviews マイクロサービスは v1 バージョンにしかリクエストを送れません。

手順6： 10% のトラフィックを reviews-v2 に切り替え¶

virtual-service-reviews.yaml ファイルを以下の内容に変更します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  namespace: prod
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

再デプロイします。

kubectl replace -f virtual-service-reviews.yaml

http://8.136.193.105:32156/productpage に複数回アクセスすると、reviews マイクロサービスの v1 バージョンと v2 バージョンがそれぞれ 90% と 10% のトラフィックを受信します。

手順7： reviews-v2 の観測¶

1. アプリケーションパフォーマンスモニタリング（APM）¶

『Guance』にログインし、『APM』→ 右上のトポロジーアイコンをクリックします。環境とバージョンを区別するスイッチをオンにすると、reviews には 2 つのバージョンがあり、reviews:test:v2 が ratings サービスを呼び出していることがわかります。

上部の『トレース』をクリックし、今回はリソース検索機能を使用して、reviews.prod を選択し、reviews のバージョンが v2 のトレースを見つけてクリックします。

詳細画面でフレームグラフを観測します。トレース呼び出しにエラーやタイムアウトなどの問題がある場合、明確に確認できます。ここでの project、version、env ラベルは、gitlab の bookinfo-views プロジェクトの deployment.yaml ファイルで定義された annotations です。

スパンリストで各スパンの実行時間を確認できます。

サービス呼び出し関係では、明確なトポロジー図を確認できます。

2 Istio Mesh モニタリングビュー¶

『Guance』にログインし、『シナリオ』→『ダッシュボード作成』をクリックし、Istio Mesh モニタリングビュー を選択します。このビューでは、reviews-v1 と reviews-v2 の呼び出し比率がおおよそ 9:1 であることが確認できます。

手順8：リリースの完了¶

reviews-v2 バージョンのマイクロサービスが正常に動作することが確認できたら、トラフィックを完全に v2 バージョンに切り替えます。virtual-service-reviews.yaml ファイルを以下の内容に変更します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  namespace: prod
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2

再デプロイします。

kubectl replace -f virtual-service-reviews.yaml

『注意』reviews-v2 バージョンに問題がある場合は、『Guance』にログインし、本章の最後のセクション「トレースタイムアウト分析」を参照して問題を分析し、手順6を参考にトラフィックを完全に reviews-v1 に戻し、問題が修正されたら再リリースしてください。

メトリクス¶

Bookinfo のデプロイ時に、カスタム設定で Pod を有効にする際、annotations 設定に measurement_name = "istio_prom" を追加しました。これにより、メトリクスが istio_prom メジャーメントに収集されます。『Guance』にログインし、『メトリクス』→ istio_prom メジャーメントを確認します。

これらのメトリクスを利用して、自身のプロジェクトのニーズに応じて、前の手順で紹介した Istio Mesh モニタリングビュー のようなビューを作成できます。

トレース¶

リアルユーザーモニタリング（RUM）¶

『Guance』にログインし、『RUM』に入り、devops-bookinfo アプリケーションを見つけてクリックします。

UV、PV、セッション数、アクセスされたページなどの情報を確認します。

『参考情報』フロントエンドとバックエンドが分離されたプロジェクトの場合、エクスプローラーでバックエンドのトレースやログと連携できます。詳細な手順については、Kubernetes アプリケーションの RUM-APM-LOG 連携分析を参照してください。

APM¶

『Guance』にログインし、『APM』に入ります。APM を使用してトレースデータを確認します。

ログ¶

stdout¶

DataKit のデプロイ時の設定に従い、デフォルトで /dev/stdout に出力されるログを収集します。『Guance』にログインし、『ログ』に入り、ログ情報を確認します。

『参考情報』その他のログ収集方法については、以下を参照してください。

Pod ログ収集のベストプラクティス

Kubernetes クラスターにおけるログ収集のいくつかの方法

トレースタイムアウト分析¶

Bookinfo プロジェクトには、タイムアウトをデモするサンプルがあります。jason ユーザーでログインすると、ratings サービスがタイムアウトします。新しい virtual-service-ratings-test-delay.yaml ファイルを作成し、内容は以下の通りです。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
  namespace: prod
spec:
  hosts:
  - ratings
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    fault:
      delay:
        percentage:
          value: 100.0
        fixedDelay: 7s
    route:
    - destination:
        host: ratings
        subset: v1
  - route:
    - destination:
        host: ratings
        subset: v1

リソースを作成します。

kubectl apply -f virtual-service-ratings-test-delay.yaml

jason でログインします（パスワードは空です）。

http://8.136.193.105:32156/productpage にアクセスすると、ratings サービスが到達不能になります。

『Guance』にログインし、『APM』に入ります。タイムアウトしたトレースをクリックします。

フレームグラフを観測し、タイムアウトした呼び出しを特定します。

service mesh マイクロサービスアーキテクチャの開発からカナリアリリースまでの全プロセス ベストプラクティス（後編）¶

概要¶