3.7.5 システム運用に必要となる機能
この項では、冗長化や各コンポーネントで注意する必要がある項目について記載します。
システム運用に必要となる機能で使用する各コンポーネントのCPU、メモリに関してはElasticsearchを除き、リソースの制限を実施していません。
そのため、実際にRASコンポーネントを使用したとき消費されるリソース量を確認し、チューニングを実施してください。
- 〈この項の構成〉
(1) Elasticsearch
(a) 冗長化・レプリケーション
クラスタ構成を実施することで冗長化できます。クラスタ構成を採ることで、Elasticsearchに格納したデータの分散管理、冗長性の確保を実現できます。
Elasticsearchをクラスタ構成にする場合、ノード障害からの保護や、ストレージの圧迫を抑制するためKubernetesノード間で分散してElasticsearchを起動させることを推奨します。
(b) CPU、メモリのチューニング
Elasticsearchは多量のリソースを使用するため、クラスタ構成を採らない場合での、起動と最低限の利用に必要と思われるリソース値による制限を実施しています。
Elasticsearchのパフォーマンスに応じてチューニングを実施してください。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「7.3.9 Elasticsearch」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |
(c) Elasticsearchデータディレクトリ・Elasticsearchリポジトリディレクトリとして使用する永続ボリュームの見積もり
ElasticsearchデータディレクトリおよびElasticsearchリポジトリディレクトリとして使用する永続ボリュームの見積もりの詳細については、「3.4.3 Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」を参照してください。
(2) Jaeger-collector
(a) 冗長化・レプリケーション
HMP-PCTOの各コンポーネントから出力されるSpanを分散させるため、またPod停止によって分散トレースとして収集する情報に欠落が生じないようにレプリケーションで冗長化を実施できます。
(b) パラメタ
Jaeger-collectorは、HMP-PCTOの各コンポーネントから送信されたSpanを受信し、Elasticsearchへと送信する動作を行います。受信したSpanを格納する内部キューの長さと、キュー内のデータの送信処理を行うワーカに対して、チューニングを行う必要があります。
そのほかのパラメタについては、Jaegerの公式ドキュメントを参照してください。
- チューニング対象のパラメタ一覧
-
表3‒28 チューニング対象のパラメタ一覧 項番
パラメタ
説明
1
collector.queueSize
Jaeger-collector は収集したSpanをElasticsearchに送付するため、受信したデータを内部のキューへと保管します。※
このキューのサイズを指定します。
2
collector.numWorks
Jaeger-collector内で動作するワーカの数を指定します。
3
collector.numShards
Elasticsearchに作成するインデックスのシャード数を指定します。
このパラメタはElasticsearchの性能に影響します。
- 注※
-
Jaeger-collectorは、内部キューがいっぱいになると古いSpanを上書きします。
- チューニング方法
-
表3‒29 チューニング方法 項番
パラメタ
チューニングの考え方
デフォルト値
1
collector.queueSize
Jaeger-collectorは、内部キューがいっぱいになると古いSpanを破棄します。そのため、「1トランザクション当たりのSpan数×Transaction per seconds × 時間(分)」で計算し、見積もりを実施します。
チューニングを行う場合は、Jaeger-collectorのjaeger_collector_queue_lengthのメトリクスを参照し、値が増長している かつ、jaeger_collector_spans_dropped_totalのメトリクスを参照したとき、Spanのdrop が発生している場合は、設定値の見直しが必要です。
「(1) Helmチャートのパラメタ」を参照してください。
2
collector.numWorks
キュー内のデータ50件に対ワーカ1つが対応します。
そのため、"キューのサイズ / 50" を設定することを推奨します。
3
collector.numShards
Elasticsearchは、インデックス内のデータをシャードという単位で分割して管理します。シャード数が多いと、Elasticsearchの検索効率は上昇しますが、消費されるメモリが多くなります。
Elasticsearchのパフォーマンスに問題がある場合にかぎり、このパラメタの数値を変更してください。
- 注※
-
デフォルト値は、Jaeger-collector 1.45.0 におけるデフォルト値です。
(c) CPU、メモリのチューニング
Jaeger-collectorは内部キューの容量、送信処理のチューニングに応じて、必要となるリソースが増加します。Jaeger-collectorのパフォーマンスに応じてチューニングを実施してください。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「(1) Helmチャートのパラメタ」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |
(3) Jaeger-query
(a) パラメタ
Jaeger-queryでは、分散トレースを参照するためのUIを提供します。チューニングとしては、分散トレース参照時の検索範囲に関して設定する必要があります。
- チューニング対象のパラメタ一覧
-
Jaeger-queryのチューニング対象のパラメタ一覧を次に示します。
表3‒31 チューニング対象のパラメタ一覧 項番
パラメタ
説明
1
jaegerQuery.maxSpanAge
Jaeger-queryがElasticsearchから分散トレースを取得する際、検索の範囲とする時間の指定を行います。
- チューニング方法
-
表3‒32 チューニング方法 項番
パラメタ
チューニングの考え方
デフォルト値
1
jaegerQuery.maxSpanAge
Elasticsearch ILMポリシーと合わせた値を設定します。
ILMポリシーで設定した削除期間内が検索可能となる範囲で設定をしてください。
「7.3.5 Jaeger-query」を参照してください。
(b) CPU、メモリのチューニング
Jaeger-queryに対するアクセスが集中するときなど、必要となるリソースが増加する場合があります。Jaeger-queryのパフォーマンスに応じてチューニングを実施してください。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「(1) Helmチャートのパラメタ」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |
(4) Logstash
(a) 冗長化・レプリケーション
メッセージログが各Kubernetesノードに起動したFilebeatより転送されるため、アクセスを分散させます。また、Pod停止によって収集するメッセージログ情報に欠落が生じないようにレプリケーションで冗長化を実施できます。
ログが大量に出力された際に、内部キューの圧迫を防ぐため、2台以上の構成で起動することを推奨します。この時、起動させるKubernetesノードは、異なるノード上で起動させるようにすることで、可用性が向上します。
(b) パラメタ
Logstashでは、Filebeatで収集したメッセージログをElasticsearchに転送する動作を行います。受信したメッセージログを送信するためにチューニングを行う必要があります。
- チューニング対象のパラメタ一覧
-
Logstashのチューニング対象のパラメタ一覧を次に示します。
表3‒34 チューニング対象のパラメタ一覧 項番
パラメタ
説明
1
logstash.pipeline.batchSize
個々のworkerがinput処理によって収集するイベントの最大数を定義します。
2
logstash.queue.event.maxEvents
内部キュー内の未読イベントの最大数を定義します。
3
logstash.queue.byte.maxBytes
内部キューの最大容量(Byte)を定義します。
- チューニング方法
-
表3‒35 チューニング方法 項番
パラメタ
チューニングの考え方
デフォルト値
1
logstash.pipeline.batchSize
数値を大きくするほど、処理効率は向上しますが、メモリのオーバーヘッドが増加します。Filebeatからログの送信に時間が掛かる場合は、この設定を見直してください。
「(1) Helmチャートのパラメタ」を参照してください。
2
logstash.queue.event.maxEvents
queue.max_eventsおよびqueue.max_bytesが未設定の場合、メモリを無制限に使用します。queue.max_eventsを設定し、メモリ使用量の上昇を抑制してください。
リソース管理の観点からqueue.max_bytesを設定し、永続キューの制限を設定することを推奨します。
3
logstash.queue.byte.maxBytes
Elasticsearchのインデックスの見積もり式 と 障害要件(Elasticsearchの復旧までの停止許容時間)を基にキューに格納するログサイズの見積もりを実施してください。
"1TPS(Transactions per seconds)当たりのログ容量×停止時間×安全係数"
(c) CPU、メモリのチューニング
Logstashでは、Filebeatから受信したメッセージログの送信処理に関するチューニングに応じて、必要となるリソースが増加します。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「(1) Helmチャートのパラメタ」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |
(5) Filebeat
(a) パラメタ
Filebeatではコンテナの標準出力として出力されたログ、各Pod内のログファイル上に出力されたログをLogstashに転送する動作を行います。メッセージログを送信するためにチューニングを行う必要があります。
- チューニング対象のパラメタ一覧
-
Filebeatのチューニング対象のパラメタ一覧を次に示します。
表3‒37 チューニング対象のパラメタ一覧 項番
パラメタ
説明
1
filebeat.queue.maxSize
内部キューとして使用する容量の最大値を定義します。
2
filebeat.queue.readAhead
内部キューに登録され、ディスク上に出力されたデータから、Logstashへの出力のためにメモリに読み取る必要のあるイベントの数を定義します。
3
filebeat.output.maxRetries
Logstashへの送信に失敗した際に実施する再送の試行回数を定義します。
- チューニング方法
-
表3‒38 チューニング方法 項番
パラメタ
チューニングの考え方
デフォルト値
1
filebeat.queue.maxSize
-
コンテナの標準出力として出力されたログの場合
Elasticsearchのインデックスの見積もり式 と 障害要件(Elasticsearchの復旧までの停止許容時間)をもとにキューに格納するログサイズの見積もりを実施してください。
"1TPS(Transactions per seconds)当たりのログ容量×停止時間×安全係数"
-
各Pod内のログファイルを参照し、出力されたログの場合
1トランザクション当たりのログ容量の見積もりを行います。共に障害要件(Elasticsearchの復旧までの停止許容時間)を基にキューに格納するログサイズの見積もりを実施してください。
"1TPS(Transactions per seconds)当たりのログ容量×停止時間×安全係数"
「(1) Helmチャートのパラメタ」を参照してください。
2
filebeat.queue.readAhead
Logstashへの出力が遅くなっている場合、一度に多くのイベントを読み取ることができない状況になるため、この設定値をデフォルト値より高い数値に設定します。このとき、メモリ使用量は増加します。
3
filebeat.output.maxRetries
無制限とした場合、キューの圧迫につながります。
そのため、機能要件に従った再送回数を定義することを推奨します。
-
(b) CPU、メモリのチューニング
Filebeatでは、メッセージログの送信処理に関するチューニングに応じて、必要となるリソースが増加します。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「(1) Helmチャートのパラメタ」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |
(6) Metricbeat
(a) 冗長化・レプリケーション
Prometheusから送信されてくるメトリクスをElasticsearchに対して送信を実施します。Prometheusからのアクセスを分散させます。メトリクスの欠落を防止するなどの意図で、レプリケーションで冗長化を実施できます。
Prometheusのレプリケーションを実施した場合や、Metricbeat停止によるメトリクス欠落を防止する必要がある場合は、2台以上の構成で起動してください。
このとき、起動させるKubernetesノードは、異なるノード上で起動させるようにすることで、可用性が向上します。
(b) パラメタ
Metricbeatでは、Prometheusより送信されたメトリクスをElasticsearchへと送信する動作を行います。送信を実施するために、次の表に示すチューニングを実施してください。
- チューニング対象のパラメタ一覧
-
Metricbeatのチューニング対象のパラメタ一覧を次に示します。
表3‒40 チューニング対象のパラメタ一覧 項番
パラメタ
説明
1
metricbeat.output.maxRetries
Elasticsearchへの送信に失敗した際に実施する再送の試行回数を定義します。
2
metricbeat.queue.maxSize
内部キューとして使用する容量の最大値を定義します。
3
metricbeat.queue.readAhead
内部キューに登録され、ディスク上に出力されたデータから、Elasticsearchへの出力のためにメモリに読み取る必要のあるイベントの数を定義します。
- チューニング方法
-
表3‒41 チューニング方法 項番
パラメタ
チューニングの考え方
デフォルト値
1
metricbeat.output.maxRetries
無制限とした場合、キューの圧迫につながります。そのため、機能要件に従った再送回数を定義することを推奨します。
「(1) Helmチャートのパラメタ」を参照してください。
2
metricbeat.queue.maxSize
Elasticsearchのインデックスの見積もり式 と 障害要件(Elasticsearchの復旧までの停止許容時間)をもとにキューに格納するログサイズの見積もりを実施してください。
"1TPS(Transactions per seconds)当たりのメトリクス容量×停止時間×安全係数"
3
metricbeat.queue.readAhead
Elasticsearchへの出力が遅くなっている場合、一度に多くのイベントを読み取ることができない状況になるため、この設定値をデフォルト値より高い数値に設定します。このとき、メモリ使用量は増加します。
(c) CPU、メモリのチューニング
Metricbeatでは、Prometheusから受信したメトリクスの送信処理に関するチューニングに応じて、必要となるリソースが増加します。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「(1) Helmチャートのパラメタ」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |
(7) Prometheus
(a) 冗長化・レプリケーション
レプリカ数の変更によって、Prometheusをレプリケーションすることはできます。ただし、起動したPrometheusごとに独立してメトリクスを収集する動作を行います。そのため、Prometheus間で収集したメトリクスの重複が発生します。
また、Metricbeatに対してのメトリクスの送信もPrometheusごとに行われるため、Elasticsearchに格納されるメトリクスデータの重複が発生します。
レプリケーションを実施する場合、起動させるKubernetesノードは、異なるノード上で起動させるようにすることで、可用性が向上します。
(b) パラメタ
Prometheusでは、各コンポーネントよりメトリクス情報の収集、参照と、Metricbeatへ転送する動作を行います。Prometheusのパフォーマンスを調整するため、次の表に示すチューニングを実施してください。
- チューニング対象のパラメタ一覧
-
Prometheusのチューニング対象のパラメタ一覧を次に示します。
表3‒43 チューニング対象のパラメタ一覧 項番
パラメタ
説明
1
prometheus.scrape.interval
Prometheusがメトリクスの取得対象から情報を取得する間隔を定義します。
2
prometheus.remoteWrite.queue.capacity
PrometheusがMetricbeatにデータの送信処理をシャードという単位で並列実行してメトリクスを送信します。
データを送信するため、シャードごとにメモリ内でキューを作成します。
このキューのサイズを指定します。
3
prometheus.remoteWrite.queue.maxShards
Metricbeatにデータを送信するシャードのサイズ、または並列処理の最大数を指定します。通常では最大数まで使用しないよう動作するが、送信が遅延した場合などに定義した最大数による送信処理を実施します。
4
prometheus.remoteWrite.queue.maxSamplesPerSend
一度にまとめて送信するデータのサイズを定義します。
5
prometheus.storage.retentionTime
データを保持し続ける期間を定義します。
- チューニング方法
-
表3‒44 チューニング方法 項番
パラメタ
チューニングの考え方
デフォルト値
1
prometheus.scrape.interval
間隔を短くするほど、Prometheusが使用するディスク容量が上昇します。メトリクス取得に関する要件と、Prometheusが使用量を基に、設定値を検討してください。
「(1) Helmチャートのパラメタ」を参照してください。
2
prometheus.remoteWrite.queue.capacity
Metricbeatに送信する処理のメモリ使用量は、「シャード数 ×(prometheus.remoteWrite.queue.capacity + prometheus.remoteWrite.queue.maxSamplesPerSend)」に比例します。
大きい値に設定するほど、多くのメモリを消費します。Prometheusとしては、prometheus.remoteWrite.queue.maxSamplesPerSendの3〜10倍程度の値に設定することを推奨しています。
3
prometheus.remoteWrite.queue.maxShards
Prometheusでは、Metricbeatへの送信に異常に時間が掛かる場合ではないかぎりデフォルト値を超えた値を設定する必要はありません。
4
prometheus.remoteWrite.queue.maxSamplesPerSend
Prometheusでは、ほとんどの利用にかぎり問題ない値としてデフォルト値が定義されています。
Prometheusのメモリ使用量が高い場合にかぎり、prometheus.remoteWrite.queue.capacityの項目に記載したメモリ使用量の見積もり式を基に、チューニングを実施してください。
5
prometheus.storage.retentionTime
Prometheusで参照可能なデータの保持期間を定義します。期間が長期になるほど、Prometheusが保持するメトリクスデータは増大します。
Prometheusの利用用途とディスクサイズに合わせて設定してください。
(c) CPU、メモリのチューニング
Prometheusでは、メトリクス収集、およびMetricbeatへの送信処理に関するチューニングに応じて、必要となるリソースが増加します。
|
項番 |
パラメタ |
説明 |
|---|---|---|
|
1 |
requests.cpu |
詳細は「(1) Helmチャートのパラメタ」を参照してください。 |
|
2 |
requests.memory |
|
|
3 |
limits.cpu |
|
|
4 |
limits.memory |