Red Hatの小島です。
AWS上でのOpenShift環境の場合、OpenShift Loggingによって主に利用されるログの保存場所はAmazon CloudWatchかAmazon S3となります。本記事では、OpenShift Loggingで利用されるAWSのストレージサイズやインフラ利用料金の目安となる情報を紹介していきます。
先に結論を書いておくと、AWSの利用料金を抑えたい場合は、OpenShift LoggingによるLokiとAmazon S3を使うことを推奨します。
- OpenShift Logging 6.2によるロギング設定
- 実際にOpenShift/ROSAのOpenShift Loggingで24時間ログ保存をしてみた結果
- Loki + S3利用時とCloudWatch利用時との料金比較
- 参考情報
OpenShift Logging 6.2によるロギング設定
Amazon CloudWatchへのログ転送
OpenShift Logging 6.2では、OpenShiftのOperatorHubにある Red Hat OpenShift Logging Operatorでログ転送のための設定を作成します。この際、必要となるものは、Amazon CloudWatchを利用するための認証情報を保存したSecretリソースと、OpenShift Logging Operatorを利用して作成するClusterLogForwarderインスタンスの2つです。
CloudWatchを利用するための認証情報には、CloudWatchのログ参照/書き込み権限を持つAWS IAMユーザーのアクセスキーとシークレットアクセスキー、または、AWS Secruity Token Service (STS) を利用するためのIAMロールを利用できます。前者の場合、AWS IAMユーザーのアクセスキーとシークレットアクセスキーをOpenShiftのSecretリソースとして保存するためのYAMLは次のようになります。cw-secret はSecretリソースに付けられる名前であり、他に任意の名前を指定できます。
apiVersion: v1 kind: Secret metadata: name: cw-secret namespace: openshift-logging data: aws_access_key_id: XXXXXXXX aws_secret_access_key: YYYYYYYYYYYY
このYAMLはOpenShift CLIの oc apply -f <YAMLファイルパス> コマンドや、OpenShift Web Consoleの右上部分にある + アイコンから辿れる YAMLのインポート メニューなどからOpenShiftクラスターに適用して、Secretリソースとして保存できます。
AWS STSを利用する場合、AWS上で次のようなカスタム信頼ポリシーとCloudWatchのログ参照/書き込みを利用可能にするIAMポリシー(AWS管理ポリシーの CloudWatchLogsFullAccess など)が紐づけられたIAMロールを作成します。IAMロールのカスタム信頼ポリシーの例は次のとおりです。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<AWS_IAM_ID_PROVIDER_ID>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<AWS_IAM_ID_PROVIDER_ID>:sub": "system:serviceaccount:openshift-logging:collector" } } } ] }
このカスタム信頼ポリシーは、特定のAWS IAM IDプロバイダーに紐づけられたOpenShiftやROSAクラスター上の openshift-logging プロジェクトにある collector サービスアカウントに対して、IAMポリシーで指定されたAWSリソースへの特定の操作を許可するためのものとなります。AWS IAM IDプロバイダーのIDについては、Self-Managed OpenShift環境の場合、下記のブログを参考にしながら確認してください。
ROSAの場合は rosa list oidc-provider コマンドで、ROSAクラスターに紐づいているAWS IAM IDプロバイダーが確認できるようになっています。下記のコマンドの出力結果で表示されている oidc.op1.openshiftapps.com/289dfjXXXXXX がAWS IAM IDプロバイダーのIDとなります。
$ rosa list oidc-provider I: Fetching OIDC providers OIDC PROVIDER ARN Cluster ID In Use arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/oidc.op1.openshiftapps.com/289dfjXXXXXX 2el3cammYYYYYYY Yes
CloudWatchを利用するためのポリシーを持ったIAMロールを作成した後は、次のようなYAMLでSecretリソースを作成できます。このYAMLによって、作成したAWS IAMロールを利用するためのSecretリソースを、OpenShiftクラスターの openshift-logging プロジェクトに cw-secret-sts という名前で保存できます。
apiVersion: v1 kind: Secret metadata: name: cw-secret-sts namespace: openshift-logging stringData: cw-key: |- [default] role_arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/<AWS_IAM_ROLE_NAME> web_identity_token_file: /var/run/secrets/openshift/serviceaccount/token
こうして作成したSecretリソースを利用して、OpenShift Logging Operator の ClusterLogForwarder インスタンスを作成します。手順の概要は次のとおりです。
- OpenShiftのOperatorHubメニューから
Red Hat OpenShift LoggingOperatorを、デフォルトのパラメーターでインストール - ocコマンドで、OpenShift Loggingによるログ収集のためのサービスアカウントを作成
- ↑で作成したサービスアカウントに、ログ収集のためのクラスターロールを付与
- CloudWatchへのログ転送をするClusterLogForwarderインスタンスを作成
手順2, 3 については、次のようなOpenShift CLIのocコマンドを kubeadmin や cluster-admin などの、OpenShiftクラスターの管理者権限を持つユーザーで実行します。この例では collector という名前のサービスアカウントを openshift-logging プロジェクトに新規作成していますが、collector 以外にも任意の名前を指定できます。ただし、AWS STSを利用する場合は、前述したIAMロールのカスタム信頼ポリシーで指定しているOpenShiftクラスターのサービスアカウント名を指定するようにしてください。
oc create serviceaccount collector -n openshift-logging oc adm policy add-cluster-role-to-user collect-application-logs -z collector -n openshift-logging oc adm policy add-cluster-role-to-user collect-audit-logs -z collector -n openshift-logging oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector -n openshift-logging
手順4のClusterLogForwarderインスタンスは、AWS IAMユーザーのアクセスキーとシークレットアクセスキーを保存したSecretリソースを利用する場合、次のようなYAMLで作成できます。この時指定するサービスアカウント名とSecretリソース名については、前の手順で作成したサービスアカウント名(この例ではcollector)とSecretリソース名(この例ではcw-secret)を指定します。
また、groupNameに test-cluster-001-{.log_type||"unknown"} を指定することで、CloudWatchに保存されるロググループ名として test-cluster-001- という接頭辞にログタイプ(application, audit, infrastructure) が付いた名前を付けられます。例えば、ユーザーアプリケーションに関するログを保存するロググループ名は test-cluster-001-application となります。
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: logforwarder namespace: openshift-logging spec: serviceAccount: name: collector outputs: - name: cw type: cloudwatch cloudwatch: groupName: test-cluster-001-{.log_type||"unknown"} region: us-east-2 authentication: type: awsAccessKey awsAccessKey: keyId: secretName: cw-secret key: aws_access_key_id keySecret: secretName: cw-secret key: aws_secret_access_key pipelines: - name: forward-to-cloudwatch inputRefs: - application - infrastructure - audit outputRefs: - cw
AWS STSによるIAMロールをSecretリソースとして指定する場合、次のようなYAMLになります。ここで指定している cw-key は、前の手順で作成した cw-secret-sts Secretリソースで指定したstringDataの名前 cw-key です。
apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: logforwarder namespace: openshift-logging spec: serviceAccount: name: collector managementState: Managed outputs: - name: cw type: cloudwatch cloudwatch: authentication: type: iamRole iamRole: roleARN: secretName: cw-secret-sts key: cw-key token: from: serviceAccount groupName: 'test-cluster-001-{.log_type||"unknown"}' region: us-east-2 pipelines: - name: forward-to-cloudwatch inputRefs: - application - infrastructure - audit outputRefs: - cw
これによって、OpenShiftクラスターのコンピュートノードの数だけログ収集のためのcollector Pod(vectorプロセスが実行されています)が起動して、CloudWatchへのログ転送が開始されて、CloudWatch上でロググループを確認できるようになります。
OpenShift Loggingで収集できる組み込みのログタイプ(application, infrastructure, audit)についての解説は、下記をご参照ください。
ROSA HCPクラスターの場合の注意点
ROSA Hosted Control Plane (HCP) クラスターの場合、AWSユーザーにはOpenShiftクラスターのコンピュートノード(監査ログは /var/log/audit/audit.log に保存されます)しか見えなくなっているため、コントロールプレーン上の監査ログはそのままでは見えません。これに対してはユーザーからのリクエストを受けて、ROSA HCPの特定のバージョン以降(4.18+, 4.17.2+, 4.16.19+, 4.15.43+)から、OAuthに関する監査ログをCloudWatchにログ転送できる機能が実装されました。2025年3月時点では、S3への監査ログ転送機能は提供していません。
手順の詳細は下記のナレッジベースをご参照ください。AWS STSを利用したCloudWatchへのログ転送を実施するためのIAMロールを作成して、監査ログの転送を有効化/無効化する手順を記載しています。
補足: 上記ナレッジベース記載の手順では ocm patch コマンドで監査ログ転送を有効化していますが、rosa edit cluster コマンドでも同じ効果を得ることはできます。rosaコマンドによる、監査ログ転送の有効化コマンドは次のようになります。
rosa edit cluster -c <ROSA_HCP_CLUSTER_NAME> --audit-log-arn <AWS STSでCloudWatchを利用するためのAWS IAMロールのARN> --yes
これによって、ROSA HCPクラスターのOAuthに関するログがCloudWatchに転送されて、ocm-production-XXXXX-<ROSA_HCP_CLUSTER_NAME>という名前のロググループで確認できるようになります。転送先のCloudWatchのロググループのAWSリージョンは、ROSA HCPクラスターがあるAWSリージョンと同じものとなります。
監査ログ転送を停止したい場合、audit-log-arn オプションで空値を指定します。
rosa edit cluster -c <ROSA_HCP_Cluster_NAME> --audit-log-arn "" --yes
Loki + Amazon S3でのログ保存
AWS STSを利用せずにOpenShift Logging 6.2のLokiを利用する場合、下記の製品ドキュメントにあるクイックスタート手順に従えば、LokiによるAmazon S3へのログ保存が可能です。このクイックスタート手順に記載されている ClusterLogForwarder CR (Custom Resource) について、監査ログも転送する場合は spec.pipelines.inputRefs で application と infrastructure だけでなく audit も指定するようにしてください。
1.3. Logging 6.2 | Red Hat Product Documentation
また、LokiによるAmazon S3などを利用するためのSecretリソースの作成方法は、下記のナレッジベースにまとまっています。
ただし、AWS STSを利用したOpenShiftクラスターやROSAの場合は、若干勝手が異なります。上記のクイックスタート手順の通りにLoki Operatorをインストールすることは同じですが、Amazon S3を利用するIAMポリシー(AWS管理ポリシーの AmazonS3FullAccess など)が紐づいたIAMロールのARNを、Loki Operatorインストール時に指定する必要があります。このIAMロールのカスタム信頼ポリシーの例は次のとおりです。 なお、この例では openshift-logging プロジェクトのサービスアカウント名として logging-loki を指定しています。Loki OperatorでLokiStackインスタンスを作成する際に、LokiStackインスタンスの名前と同じ名前のサービスアカウントが自動作成されるようになっており、Amazon S3の利用権限はこのサービスアカウントに付与する必要があります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<AWS_IAM_ID_PROVIDER_ID>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<AWS_IAM_ID_PROVIDER_ID>:sub": "system:serviceaccount:openshift-logging:logging-loki" } } } ] }
OpenShiftクラスターでLoki Operatorをインストールする時には、このIAMロールのARNを指定します。
AWS STSを利用する場合、AWSアクセスキーやシークレットアクセスキーなどをSecretリソースに保存する必要はありません。Amazon S3のバケット名とリージョン名を指定するだけでいいです。下記はその1例です。
apiVersion: v1 kind: Secret metadata: name: logging-loki-s3-sts namespace: openshift-logging stringData: bucketnames: <AWS_BUCKET_NAME> region: <AWS_BUCKET_REGION(例: us-east-2)>
ClusterLogForwarderによるLokiStackへのログ転送設定が正常に完了すると、OpenShift Web Consoleからアプリケーション/インフラストラクチャー/監査ログが確認できるようになります。
また、CLI経由でもLokiにはアクセスできるようになっています。アクセス手順については、下記のブログをご参照ください。
実際にOpenShift/ROSAのOpenShift Loggingで24時間ログ保存をしてみた結果
OpenShift/ROSAクラスターを作成した後に、OpenShift Loggingによるログ転送や保存に関する設定を適用した状態で、実際にどのくらいログが保存されるのかをいくつかの構成パターンで確認してみました。ここでのLokiStackインスタンスのサイズは 1x.demo を指定しています。これらのログ保存サイズは参考値として見てください。実際の環境では application ログにユーザーのアプリケーションに関するログが追加されるなど、様々なログが追加されることに注意してください。
注: ログ転送や保存のテストのためにいくつかのサンプルアプリを実行しているため、application ログサイズが0ではありません。また、データ圧縮のパラメーターは指定していません。
Self-Managed Single Node OpenShift の1台構成
- Loki + S3
- CloudWatch
Self-Managed OpenShift の5台構成 (Control Plane: 3台, Compute: 2台)
- Loki + S3
- CloudWatch
ROSA HCP の2台構成 (Compute: 2台)
- Loki + S3
- CloudWatch
ROSA HCP 4.18 でのOAuthの監査ログ転送を有効化した状態です。
ROSA Classic の7台構成 (Control Plane: 3台, Infra Node: 2台, Compute: 2台)
- Loki + S3
- CloudWatch
補足: 2026年4月1日以降に、ROSA Classicクラスターの新規作成機能が終了する予定なので、今からのROSA Classicクラスター新規作成は推奨していません。
Loki + S3利用時とCloudWatch利用時との料金比較
Loki + S3を利用する場合と、CloudWatchへのログ転送をする場合との簡単な料金比較をしてみます。データ料金比較の簡単化のために、前述のS3とCloudWatchで保存されるログサイズの実測値を考慮して、S3でのログ保存サイズをCloudWatchでのログ保存サイズの2倍と仮定します。例えば、S3でのログ保存サイズが20GB、CloudWatchでのログ保存サイズがその半分の10GBとすると、S3へのログ転送サイズはそのまま20GB、CloudWatchへのログ転送サイズはCloudWatchが備えるデータ圧縮機能(圧縮率は0.15~0.2程度)を考慮して50GBとなります。なお、Lokiではログデータが自動的に圧縮される仕組みとなっています。
OpenShift LoggingでのLoki + S3を利用する場合は、デモ用途の 1x.demo サイズを除けば 1x.pico がLokiの最小サイズとなります。1x.pico サイズで求められるvCPU数が7個以上、メモリは17GiB以上となります。また、1x.medium が最大サイズとなり、求められるvCPU数が54個以上、メモリは139GiB以上となります。そこで、1x.pico を利用する場合と 1x.medium を利用する場合とで、次の条件を想定してみました。
50GB/日のログが発生する場合 (パターンA)
- Loki用にm5.xlarge (4vCPU, RAM16GiB) EC2インスタンスを2台用意
- このEC2インスタンス2台に接続されるEBS gp3のサイズは、それぞれ150GB
- Lokのデータ保存用途に利用されるEBS gp3のサイズは、590GB
- S3(標準)への書き込み(POST)サイズは、1リクエスト辺り1MBを想定 (実測では、数KB~2MBほどの保存データが多い)
- S3へのログ転送サイズは20GB、CloudWatchへのログ転送サイズは50GB
- S3のログ保存サイズは20GB、CloudWatchのログ保存サイズは10GB
2TB/日のログが発生する場合 (パターンB)
- Loki用にm5a.8xlarge (32vCPU, RAM128GiB) EC2インスタンスを2台用意
- このEC2インスタンス2台に接続されるEBS gp3のサイズは、それぞれ150GB
- Lokのデータ保存用途に利用されるEBS gp3のサイズは、590GB
- S3(標準)への書き込み(POST)サイズは、1リクエスト辺り1MBを想定 (実測では、数KB~2MBほどの保存データが多い)
- S3へのログ転送サイズは800GB、CloudWatchへのログ転送サイズは2TB
- S3のログ保存サイズは800GB、CloudWatchのログ保存サイズは400GB
これらの条件のもとで、パターンAとパターンBでの24時間利用料金を計算した結果が下記となります。AWSリージョンはオハイオ(us-east-2)としています。
パターンAの24時間料金(税抜)
- Loki + S3: $11.71
- EC2インスタンス+EBS: $0.192/hour x 2 x 24 + (150 x 2 + 590) x 0.08/GB/month x 1/30 = $11.59
- S3へのリクエスト: $0.005/1000リクエスト x 20000MB x 1リクエスト/MB = $0.1
- S3での保存: $0.023/GB/month x 20GB x 1/30 = $0.02
- CloudWatch: $25.01
- CloudWatchへの転送: $0.5/GB x 50GB = $25
- CloudWatchでの保存: $0.03/GB/month x 10GB x 1/30 = $0.01
- Loki + S3: $11.71
パターンBの24時間料金 (税抜)
- Loki + S3: $73.03
- EC2インスタンス+EBS: $1.376/hour x 2 x 24 + (150 x 2 + 590) x 0.08/GB/month x 1/30 = $68.42
- S3へのリクエスト: $0.005/1000リクエスト x 800000MB x 1リクエスト/MB = $4
- S3での保存: $0.023/GB/month x 800GB x 1/30 = $0.61
- CloudWatch: $1,000.4
- CloudWatchへの転送: $0.5/GB x 2000GB = $1000
- CloudWatchでの保存: $0.03/GB/month x 400GB x 1/30 = $0.4
- Loki + S3: $73.03
ログサイズが大きいほど、Loki + S3を利用する場合とCloudWatchを利用する場合とで利用料金の差が大きくなっています。そのため、AWSインフラの利用料金を抑えたい場合、ログフィルターなどを活用するとしても、OpenShift LoggingによるLokiを利用する方がいいでしょう。
また、ROSAのようなManaged OpenShift Serviceの場合、OpenShiftクラスターの運用管理をSREチームに任せることができるので、OpenShift Loggingで保存するログは、ユーザーアプリケーションに関する application ログだけでいいと割り切ることもできます。リアルタイムでの監査ログ監視が必要なければ、ROSAについてはユーザーがRed Hatサポートケース経由で監査ログを要求することもできますので、こうした仕組みもうまく活用してください。
参考情報
CloudWatch Logs と S3 にかかる料金比較
OpenShift Logging OperatorのClusterLogForwarderインスタンスを作成する際の、各パラメータの説明ドキュメント
ClusterLogForwarderインスタンスを作成するための、サンプルYAMLのリスト
ClusterLogForwarderのVector AtLeastOnceのログ転送パフォーマンス
