NEC Mark
WebOTX Manual V10.4 (第4版)

目次を表示

5. 運用(更新・性能/障害分析)指針・手法

本節では、コンテナオーケストレーションツール環境下における、下記観点の運用指針について説明します。

5.1. オンプレミス環境との運用指針の違い

オンプレミス環境とコンテナオーケストレーションツール環境では、その運用指針に以下のような違いがあります。

運用観点 オンプレミス環境 コンテナオーケストレーションツール環境
ドメインの設定情報の更新 運用管理コマンド等、運用操作で変更します。 WebOTXコンテナビルド時に設定を変更します。
または、WebOTX Application Serverのカスタムリソースを編集し、変更します。
アプリケーション固有の設定情報の更新 マシンの環境変数を変更したり、運用管理コマンド等を使用し、JVMオプションを変更します。 コンテナの環境変数を参照するようアプリケーションを改造し、変更します。
または、アプリケーションにMicroProfile Configを実装し、設定情報をシステムプロパティ、環境変数、設定ファイル(propertiesファイル)から設定を注入し、変更します。
性能分析VisualVMなどのJVM解析ツールを使用し、アプリケーションの詳細情報を取得し、分析します。分散するサービスを対象として、MicroProfile OpenTracingと分散トレース情報可視化ツールを使用し、アプリケーションの性能を分析します。
障害解析 WebOTXやアプリケーションのログを直接参照します。 ELKスタックを使用し、各種ログを蓄積させ、取得します。
タスクマネージャやTopを使用し、CPUやメモリの使用率を取得します。 Prometheusを使用し、コンテナごとのCPUやメモリの使用率を取得します。

5.2. コンテナオーケストレーションツール環境下での運用指針

5.2.1. ドメインの設定情報の更新

ドメインの設定情報に関する更新は、WebOTX Application Serverコンテナのプロファイルにより手順が変わります。

5.2.1.1. WebOTX Application Server Standard / Express フルプロファイル版の場合

WebOTX Application Server Standard / Express フルプロファイル版コンテナの場合、生成されたコンテナイメージを使用し、otxadminコマンドを実行するようDockerfileを作成し、コンテナイメージをビルドすることで、ドメインの設定を変更できます。

設定変更手順については、[構築・運用 > コンテナ型仮想化 > WebOTX Application Server のコンテナイメージ > 生成済みのWebOTX Application Serverのコンテナイメージに対する追加構成]をご参照ください。

5.2.1.2. WebOTX Application Server Express マイクロサービスプロファイル版の場合

WebOTX Application Server Express マイクロサービスプロファイル版の場合、WebOTX Uber JARのMavenプロジェクトの設定ファイルを変更し、Uber JARを再作成することでドメインの設定を変更することができます。

  1. 設定の変更

    変更したい設定により、編集する設定ファイルが違います。

    詳しくは、[アプリケーション開発ガイド > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > 設定一覧]をご参照ください。

  2. WebOTX Uber JARのビルド

    以下のコマンドで、設定変更したWebOTX Uber JARのMavenプロジェクトをビルドします。

    cd <WebOTX Uber JAR Mavenプロジェクトのトップディレクトリ>
    mvn clean package
  3. コンテナイメージのビルド

    前項で作成したWebOTX Uber JARプロジェクトの成果物を含むコンテナイメージをビルドします。

    cd <WebOTX Uber JAR Mavenプロジェクトのtargetディレクトリ>
    docker (podman) build -t <任意のコンテナイメージのタグ名> .
  4. 設定反映の確認

    前項で作成したコンテナを起動し、domain.xmlを確認することで設定反映を確認することができます。

    コンテナ内のdomain.xmlは、以下のコマンドでローカルコピーすることができます。

    docker(podman) cp <起動したコンテナID>:/opt/WebOTX/domains/domain1/config/domain.xml <任意のdomain.xmlコピー先>

    コピーしたdomain.xmlをテキストエディタ等で開き、設定を確認してください。

5.2.1.3. WebOTX Application Server Podの更新

コンテナオーケストレーションツール環境下に存在するWebOTX Application Serverコンテナを、設定変更したコンテナイメージに更新する手順について、記載します。

  1. コンテナのビルド、更新
  2. WebOTX Podへの反映

詳しくは、以下をご参照ください。

5.2.1.4. WebOTX Application Serverのカスタムリソースの編集
WebOTX Application Serverのカスタムリソースを編集することで、WebOTX Application Serverの一部の設定を変更することができます。
詳しくは、[リファレンス > 設定 > WebOTX Operator for Kubernetes > Operator 設定項目・設定方法]をご参照ください。

5.2.2. アプリケーション固有の設定情報の更新

5.2.2.1. 基本方針

アプリケーション固有の設定情報変更には、コンテナの環境変数によって変更する方針があります。

本項では、この方針に沿った手順を説明します。

Memo
アプリケーションにMicroProfile Configを実装し、設定情報をシステムプロパティ、環境変数、設定ファイル(propertiesファイル)から 注入することもできます。
詳細は、[アプリケーション開発ガイド > その他のアプリケーション > マイクロサービスアプリケーションの開発 > MicroProfile Config]をご参照ください。

5.2.2.2. アプリケーションの改造

アプリケーションの設定情報を、OSの環境変数から取得するように、アプリケーションを改造します。

改造後、当該アプリケーションを含むWebOTX Application Serverコンテナイメージを作成し、コンテナオーケストレーションツール環境下へ反映します。

コンテナオーケストレーションツール環境下のコンテナイメージ更新方法については、本ページ [ドメインの設定情報の更新 > WebOTX Application Server Podの更新]をご参照ください。

5.2.2.3. 環境変数一覧のConfigMapの作成

環境変数一覧を記載したConfigMapを作成します。

以下にConfigMapのyamlファイルの例を記載します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: <任意のConfigMap名>
data:
  <環境変数名>: <環境変数値>

以下のコマンドで、ConfigMapをWebOTXのnamespaceへ適用します。

kubectl(oc) create -f <作成したConfigMapのyamlファイル> -n <WebOTXのnamespace>
5.2.2.4. WebOTX カスタムリソースファイルの編集

前項で作成したConfigMapをコンテナ環境変数として読み込むよう、WebOTXのカスタムリソースファイルを編集します。

- spec.deployment.envFrom:
    configMapName: <作成したConfigMap名>
5.2.2.5. 設定の反映

以下のコマンドでカスタムリソースを更新し、WebOTXのPodを更新します。

kubectl(oc) delete -f <WebOTX Application Server カスタムリソースファイル> -n <WebOTX Application Serverのnamespace>
kubectl(oc) apply -f <WebOTX Application Server カスタムリソースファイル> -n <WebOTX Application Serverのnamespace>

5.2.3. 性能分析

本項では、アプリケーションの性能分析を行うために、MicroProfile OpenTracingを実装し、可視化ツールを使用することで分散トレースを実現する方法について説明します。

クラスタ内の各ノード、PodのCPU、メモリ使用率の取得については、[構築・運用 > コンテナ環境の開発から運用まで > 監視]をご参照ください。

5.2.3.1. 使用するOSS、サービス

本項で使用するOSS、サービスについて説明します。

5.2.3.2. 動作イメージ

分散トレースは、以下のような流れで実現されます。

5.2.3.3. 環境構築
Jaegerの構築
WebOTXの設定
  1. MicroProfile OpenTracingの実装

    アプリケーションの各処理に、MicroProfile OpenTracing実装を追加し、WebOTX Application Serverコンテナへ反映します。

    MicroProfile OpenTracingの実装方法は、[アプリケーション開発ガイド > その他のアプリケーション > マイクロサービスアプリケーションの開発 > MicroProfile OpenTracing」をご参照ください。

    本項では、以下で紹介されているサンプルを基に説明します。

    [構築・運用 > コンテナ環境の開発から運用まで > アプリケーション開発手法 > 新規アプリケーションの開発 > アプリケーションの統合 > sample_uberjar_project.zip]

  2. ドメインへの設定
  3. WebOTX Podの更新

    以下のコマンドでWebOTXのカスタムリソースを更新し、WebOTXのPodを更新します。

    kubectl(oc) delete -f <WebOTX Application Server カスタムリソースファイル> -n <WebOTX Application Serverのnamespace>
    kubectl(oc) apply -f <WebOTX Application Server カスタムリソースファイル> -n <WebOTX Application Serverのnamespace>
5.2.3.4. 分散トレースによるアプリケーションの性能分析
事前準備

予め、WebOTX Application Serverに配備したアプリケーションへリクエストし、MicroProfile OpenTracingが実装されている処理を通し、Jaegerへ情報を蓄積させます。

本項では、以下のサンプルがKubernetes環境上へ配備されているとして説明します。

[アプリケーション開発手法 > 新規アプリケーションの開発 > アプリケーションの統合 > sample_uberjar_project.zip]

Jaegerへ情報を蓄積させるため、以下のエンドポイントにアクセスします。

<WebOTX Application ServerのURL>/sample-app-1.0-SNAPSHOT/sample_service_a/service_a

Jaegerによる性能分析

JaegerのWebUIにアクセスし、左ペイン[Search]からトレース情報を絞り込み、検索します。

絞り込み項目には、以下のようなものがあります。

項目名説明
Serviceトレース情報を発したサービス名です。WebOTX Application ServerのJavaシステムプロパティ"JAEGER_SERVICE_NAME"値となります。
Operation"all"、"HTTP GET <エンドポイントのパス>"等、そのトレース情報の動作の形態です。
Tagsアプリケーションの処理（スパン）に設定したタグです。
Lookbackトレース情報が発生した時間です。
Min / Max Durationスパンにかかった最短 / 最大の時間です。
Limit Results一度に表示する検索結果の量です。

検索結果より、"jaegerservice: SampleServiceA.serviceA"を選択すると、以下のような画面となります。

5.2.4. 障害解析

コンテナオーケストレーションツール環境下で障害が発生した場合、以下の要素を使用して解析することができます。

大項目中項目小項目説明
WebOTXログWebOTXのログ障害発生時の各種ログを参照し、原因を探ることができます。
アプリケーション固有のログ
コンテナ内の任意のファイル
KubernetesクラスタEventsWebOTXのPodKubernetesのPod Eventを参照し、各コンテナに関する情報を取得することができます。
ノードKubernetesのノード Eventを参照し、WebOTXのPodが動作しているノードに関する情報を取得することができます。
マシンリソースCPU使用率障害発生時のマシンリソース使用率を参照することができます。参照方法については、[構築・運用 > コンテナ環境の開発から運用まで > 監視 > Kubernetesノードリソース監視の実現方針]をご参照ください。
メモリ使用率
5.2.4.1. ログ取得

ログ取得の手法について記載します。

5.2.4.2. Kubernetesリソースの解析
Pod、ノードの状態、Eventの取得

以下のコマンドで、Podやノードの状態、Eventを取得することができます。

kubectl (oc) describe (po / node) -n <WebOTXのnamespace> <WebOTXのPod / ノード名>

取得した結果から以下を取り出します。

情報種別Kubernetesリソース情報取得箇所
状態PodStatus
ノードConditions.Type
イベントPod、ノード共通Events
状態値の例
イベント値の例
5.2.4.3. Kubernetesノードリソースの解析

Prometheusを使用し、障害発生時のマシンリソースの使用率を把握することができます。

Prometheusの構築、使用方法については、[構築・運用 > コンテナ環境の開発から運用まで > 監視 > Kubernetesノードリソース監視の実現方針]をご参照ください。

Prometheusの利用

PrometheusのWebUIを使用し、PromQLの実行結果をグラフ化し、障害発生時前後のマシンリソースの使用状況を把握することができます。

構成要素の説明

  1. PromQLの入力欄です。
  2. グラフの表示期間です。
  3. グラフの右端となる日時です。障害発生日時〜を指定します。
  4. データの表示間隔です。「<指定値>秒毎」のように指定します。
PromQL例

各PromQLの例は、[構築・運用 > コンテナ環境の開発から運用まで > 監視 > PromQLの実行]をご参照ください。

Copyright (C) 1998 - 2021 NEC Corporation. All rights reserved.