現在、 AWS Graviton5 プロセッサを搭載した  Amazon EC2 の R9g インスタンスと R9gd インスタンスが一般的に利用できるようになっています。R9g インスタンスはメモリ最適化されており、AWS がこれまでに構築した中で最もエネルギー効率の高いプロセッサを搭載した Graviton4 ベースの R8g インスタンスと比較して、コンピューティングパフォーマンスが最大 25% 向上します。 R9g インスタンスは、データベース、インメモリキャッシュ (Valkey、Redis、MemCached)、リアルタイムのビッグデータ分析、コンテナ化されたマイクロサービスベースのアプリケーション (Kubernetes、Docker、EKS、ECS など) を含む Linux ベースのワークロード、C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションなど、メモリを大量に消費するワークロードに最適です。 R9gd インスタンスには、ローカルの NVMe ベースの SSD ブロックレベルストレージが含まれており、オープンソースデータベース、分散型リアルタイムビッグデータ分析、大規模なインメモリデータベース、大規模なキャッシュワークロードなど、高速で低レイテンシーのローカルストレージを必要とするメモリ集約型のワークロードに最適です。 現在 R8g インスタンスでワークロードを実行している場合、R9g を使用すると、消費電力を抑えながら、より高速なメモリ、より高いネットワークと Amazon EBS の帯域幅、大きな L3 キャッシュにより、vCPU あたりのパフォーマンスが向上します。 R9g は何が違うのか Graviton5 プロセッサは、Graviton4 に比べていくつかのハードウェア改善をもたらしています。 vCPU あたりのコンピューティングパフォーマンスが最大 25% 向上 DDR5 8800 MT/s メモリ（Graviton4 の 5600 MT/s から増加）、クラウドで利用可能な最速のメモリ L3 キャッシュが 5 倍大きく、データの局所性が向上 最大のインスタンスサイズでは最大 2 倍のネットワークと EBS 帯域幅 (最大 100 Gbps のネットワーク、48 xlarge では最大 72 Gbps の EBS) 最大 3 倍のパケット処理パフォーマンス R9g インスタンスと R9gd インスタンスは、Amazon EBS と Amazon VPC ネットワーキング間の帯域幅割り当てを 25% 調整できるインスタンス帯域幅設定 (IBC) をサポートしています。これにより、データベースやキャッシュなど、特定の帯域幅要件を持つワークロードのパフォーマンスを最適化できます。 すべての R9g および R9gd インスタンスは AWS Nitro System 上で動作し、仮想化、ストレージ、ネットワーキングを専用ハードウェアにオフロードします。これにより、インスタンス間の強固なセキュリティ分離を維持しながら、アプリケーションはベアメタルに近いパフォーマンスを実現できます。 R9g インスタンスと R9gd インスタンスには、今年初めに C9g と M9g インスタンスで導入された Nitro System と同じ拡張機能である Nitro Isolation Engine (NIE) が搭載されています。Nitro Isolation Engine (NIE) は、インスタンスの分離を強制し、正式な検証を利用して数学的な精度で分離を保証します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。Nitro Isolation Engine の詳細については、 ブログ投稿 をご覧ください。対象範囲や前提条件を含む形式検証の結果の詳細については、 テクニカルホワイトペーパー を参照してください。 EC2 R9g および R9gd インスタンスの仕様 R9gとR9gdのインスタンスはそれぞれ、ミディアムからメタル 48XL まで、11種類のサイズでご利用いただけます。次の表は、各サイズの完全な仕様を示しています。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9g.medium 1 8 EBS のみ 最大 15 最大 12 r9g.large 2 16 EBS のみ 最大 15 最大 12 r9g.xlarge 4 32 EBS のみ 最大 15 最大 12 r9g.2xlarge 8 64 EBS のみ 最大 17 最大 12 r9g.4xlarge 16 128 EBS のみ 最大 17 最大 12 r9g.8xlarge 32 256 EBS のみ 17 12 r9g.12xlarge 48 384 EBS のみ 25 18 r9g.16xlarge 64 512 EBS のみ 34 24 r9g.24xlarge 96 768 EBS のみ 50 36 r9g.48xlarge 192 1536 EBS のみ 100 72 r9g.metal‑48xl 192 1536 EBS のみ 100 72 R9gd インスタンスは、高速で低レイテンシーのスクラッチスペースまたは一時キャッシュを必要とするワークロード向けに、ローカル NVMe ベースの SSD ストレージを追加することで、R9g と同じコンピューティング性能とネットワークパフォーマンスを提供します。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ (NVMe SSD) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9gd.medium 1 8 1 x 59 GB 最大 15 最大 12 r9gd.large 2 16 1 x 118 GB 最大 15 最大 12 r9gd.xlarge 4 32 1 x 237 GB 最大 15 最大 12 r9gd.2xlarg 8 64 1 x 474 GB 最大 17 最大 12 r9gd.4xlarge 16 128 1 x 950 GB 最大 17 最大 12 r9gd.8xlarge 32 256 1 x 1900 GB 17 12 r9gd.12xlarge 48 384 3 x 950 GB 25 18 r9gd.16xlarge 64 512 1 x 3800 GB 34 24 r9gd.24xlarge 96 768 3 x 1900 GB 50 36 r9gd.48xlarge 192 1536 3 x 3800 GB 100 72 r9gd.metal‑48xl 192 1536 3 x 3800 GB 100 72 使用の開始 サポートされている任意の ARM ベースの AMI を使用して、 Amazon EC2 コンソールから R9g インスタンスと R9gd インスタンスを起動できます。R9g インスタンスは、Amazon Linux 2023、Amazon Linux 2、Ubuntu 22.04+、RHEL 8.4+、SUSE Linux エンタープライズサーバー 15 SP3+、Debian 12+、およびその他の主要な Linux ディストリビューションをサポートしています。 R8g から移行する場合、ほとんどのアプリケーションではコードを変更する必要はありません。同等の R9g インスタンスサイズを選択すると、アプリケーションのパフォーマンスが向上します。コンテナ化されたワークロードの場合、R9g は Amazon EKS、 Amazon   ECS 、および標準の Kubernetes デプロイメントと連携します。Arm64 用に構築されたマルチアーキテクチャコンテナイメージは変更なしで動作します。 始めるのに役立つリソースはいくつかあります。 AWS Graviton 入門ガイドでは 、Graviton ベースのインスタンスでワークロードを構築、実行、最適化する方法について説明しています。 Graviton節約ダッシュボードは 、コスト削減を追跡するのに役立ちます。 AWS Transform は Java アプリケーションを x86 から Graviton に移行するためのコード変換を自動化します。詳細については、 AWS Graviton プロセッサをご覧になるか、AWS Graviton でコンピューティングをレベルアップしてください 。 料金と利用可能なリージョン Amazon EC2 R9g および R9gd インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、および欧州 (フランクフルト) リージョンで利用可能です。 R9g および R9gd インスタンスは、Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細な料金については、「 Amazon EC2 の料金 」ページにアクセスしてください。 始める準備はできましたか? Amazon EC2 コンソール から R9g インスタンスを起動してください。詳細については、 Amazon EC2 R9g インスタンスページを参照してください 。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 Amazon EC2 用 AWS re:Post でフィードバックを共有するか、通常の AWS サポートの連絡先から連絡してください 。 – Daniel Abib 原文は こちら です。

はじめに 前々回の記事ではROSA HCPの概要やメリットを紹介し、前回の記事ではROSA HCPクラスターを実際に構築してきました。 今回は、本番運用を見据えた、ROSA HCPクラスターにおける「ログ保管の自動化」 についてご紹介します。 KubernetesやOpenShift環境では、Podが再起動したり削除されたりすると、コンテナ内に出力されていたログは消えてしまいます。そのため、システムの安定運用やトラブルシューティングを行うためには、コンテナログを保管する仕組みが必須となります。 そこで、AWSの運用に慣れたエンジニアにとって、最も親和性が高く手軽なログ保管先となるのが「Amazon CloudWatch Logs」です。 本記事では、具体的な設定手順に進む前の前提知識として、まずはROSA環境におけるログ保管の全体像を整理し、その後CloudWatch Logsへ転送する具体的な設定方法を解説していきます。 ROSAで出力されるログの種類 CloudWatch Logsへの転送設定を始める前に、まずはROSAが出力するログの種類についてご紹介します。 ROSAを構成するコンポーネントから出力されるログは以下の3種類に大別されます。 ROSA with HCPでは、ログ種別によってログの転送方法が異なるため注意が必要です。 ログ種別 概要 転送方法 アプリケーションログ ユーザーがデプロイしたPod(コンテナ)から出力されるログ OpenShift Logging インフラストラクチャログ ワーカーノードやOpenShiftのシステムコンポーネント(※)から出力されるログ OpenShift Logging 監査ログ クラスター内での操作履歴のログ ROSA with HCPの標準機能 ※インフラストラクチャログにおけるシステムコンポーネントの定義 OpenShfitの仕様上、以下のnamespaceで実行されているPodはすべて「OpenShiftのシステムコンポーネント」とみなされ、それらが出力するログはインフラストラクチャログとして分類されます。 default kube–xxx openshift-xxx   OpenShift Loggingとは ROSA with HCPにおいて、アプリケーションログ・インフラストラクチャログを収集し、外部へ転送するための機能が「OpenShift Logging」です。 Kubernetes標準の機能だけでは、Podが再起動したり削除されたりするとコンテナ内のログも一緒に消えてしまいます。OpenShift Loggingは、クラスター内の各コンテナが出力するログをリアルタイムに収集し、外部（今回はCloudWatch Logs）へと転送するパイプラインを自動管理してくれます。 OpenShift Loggingを構成する主要コンポーネント 現在のOpenShift Loggingは以下のコンポーネントで構成されます。 Cluster Logging Operator ログ収集エンジンや転送設定全体のライフサイクルを管理するコンポーネントです。 ログ収集エンジン 各ワーカーノードにDaemonSetとして配置され、ノード上で動くコンテナのログを収集するコンポーネントです。以前のOpenShiftではFluentdがログ収集エンジンとして使用されていましたが、現在の最新バージョンではパフォーマンスとリソース効率に優れたVectorがデフォルトのエンジンとして採用されています。   ログ転送パイプラインを定義する「ClusterLogForwarder」 OpenShift Loggingは、ログの転送パイプラインの定義を「ClusterLogForwarder」というカスタムリソースで定義します。 これにより、YAMLファイルを1つ定義するだけで、「どのログを」「どこへ転送するか」を自由に設定することができるようになっています。  ClusterLogForwarderに定義する転送パイプラインは、主に以下の３つの要素を組み合わせて設定します。 Inputs（入力元）： どのログを対象にするか Outputs（出力先）： どこに送るか Pipelines（経路の結合）： どのInputsを、どのOutputsへ紐付けるか ログ転送のデータフロー OpenShift Loggingを利用したログ転送のデータフローを図に示すと以下のようになります。 ログ収集エンジンであるVectorはClusterLogForwarderの定義に従い、Inputsに設定したアプリケーションログやインフラストラクチャログを収集し、Outputsに設定したCloudWatch Logsにログを転送します。 OpenShift Loggingを利用したCloudWatch Logsへのログ転送設定 ここからは実際にOpenShift Loggingを利用したCloudWatch Logsへのログ転送設定をご紹介します。 前提条件 ROSAクラスターが構築済みであること（前回の記事を参照） ROSAクラスターにCLIでログインできていること ROSAクラスターの管理コンソールにWebブラウザからログインできていること 事前準備（ロググループとIAMロール・ポリシーの作成） ロググループの作成 まずは転送先ロググループを作成します。 以下はCloudFormationでロググループを作成する際のサンプルになります AWSTemplateFormatVersion: '2010-09-09' Description: 'Log Group for OpenShift Logging' Resources: # アプリケーションログ用のロググループ LogGroupApp: Type: AWS::Logs::LogGroup DeletionPolicy: "Delete" Properties: LogGroupName: /rosa/hcp-cluster/application # インフラストラクチャログ用のロググループ LogGroupInfra: Type: AWS::Logs::LogGroup DeletionPolicy: "Delete" Properties: LogGroupName: /rosa/hcp-cluster/infrastructure 上記CloudFormationを適用すると以下のロググループが作成されます。 ※OpenShift Loggingはアプリケーションログを「<任意の値>/application」、インフラストラクチャログを「<任意の値>/infrastructure」の名称のロググループにログを転送します。 IAMロール・IAMポリシーの作成 OpenShift Loggingに割り当てるIAMロール・IAMポリシーを作成します。 以下はCloudFormationでIAMロールを作成する際のサンプルになります AWSTemplateFormatVersion: '2010-09-09' Description: 'IAM Role and Policy for OpenShift Logging' Parameters: # ROSA構築時に作成したOIDCエンドポイント OidcEndpoint: Type: String Description: 'The OIDC Endpoint' Resources: # CloudWatch Logs へのアクセス許可ポリシー OpenShiftLoggingPolicy: Type: 'AWS::IAM::ManagedPolicy' Properties: ManagedPolicyName: 'rosa-openshift-logging-policy' PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - 'logs:PutLogEvents' - 'logs:PutRetentionPolicy' - 'logs:CreateLogStream' - 'logs:DescribeLogGroups' - 'logs:DescribeLogStreams' Resource: 'arn:aws:logs:*:*:*' # ログ転送用 IAM ロール OpenShiftLoggingRole: Type: 'AWS::IAM::Role' Properties: RoleName: 'rosa-openshift-logging-role' AssumeRolePolicyDocument: !Sub | { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/${OidcEndpoint}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OidcEndpoint}:sub": "system:serviceaccount:openshift-logging:cloudwatch-log-forwarder-sa" } } } ] } ManagedPolicyArns: - !Ref OpenShiftLoggingPolicy 上記CloudFormationの「OidcEndpoint」というパラメーターには、前回の記事で作成したoidc-configの情報を以下のrosaコマンドで確認し、「ISSUER URL」の値の「https://」を除いた値を設定してください。 $ rosa list oidc-config # 出力例 ID MANAGED ISSUER URL SECRET ARN XXXXXXXXX true https://xxxx/xxxxx CloudFormationを適用すると以下のIAMロールが作成されます。 OpenShift Loggingのインストール Cluster Logging Operatorのデプロイ まず、OpenShift Loggingのコンポーネントの1つである「Cluster Logging Operator」をデプロイします。 以下はCluster Logging Operatorをyamlファイルでデプロイする際のサンプルになります。 opensfhit-logging-operator.yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-logging-operaror-group namespace: openshift-logging spec: upgradeStrategy: Default --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-logging-operaror-subscription namespace: openshift-logging spec: # インストールするOpenShift Loggingのチャンネルを指定 channel: stable-6.4 # インストールするOpenShift Loggingのバージョンを指定 startingCSV: cluster-logging.v6.4.1 installPlanApproval: Manual name: cluster-logging source: redhat-operators sourceNamespace: openshift-marketplace 作成したopensfhit-logging-operator.yamlをROSAクラスターにログインし、適用します。 $ oc login https://api.your-cluster-name.xxxx.p1.openshiftapps.com:443 --username cluster-admin --password XXXXX-XXXXX-XXXXX-XXXXX $ oc apply -f opensfhit-logging-operator.yaml OpenShiftの管理コンソール上の「エコシステム」→「インストール済みのOperator」のページで「cluster-logging」が選択できるようになります。 「cluster-logging」を選択し、「installPlan」のページに遷移すると、OpenShift Logging Operatorのインストールの承認確認画面が表示されるため、「承認」を選択します。 インストールを承認すると、ROSAクラスター上にCluster Logging Operatorが起動します。 $ oc get pod -n openshift-logging NAME READY STATUS RESTARTS AGE cluster-logging-operator-dd4646d96-zcw6g 1/1 Running 0 45s Secretリソースのデプロイ 次に、ログ収集エンジンにIAMロールを割り当てるためのSecretリソースをデプロイします。 以下はSecretのサンプルになります。 secret.yaml apiVersion: v1 kind: Secret metadata: name: cloudwatch-credentials namespace: openshift-logging stringData: # 作成したIAMロールのARNを指定 role_arn: arn:aws:iam::xxx:role/rosa-openshift-logging-role 作成したsecret.yamlをROSAクラスターに適用します。 $ oc apply -f secret.yaml ServiceAccountのデプロイ ログ収集エンジンに割り当てるServiceAccoutをデプロイします。 以下はServiceAccountのサンプルになります。 serviceaccount.yaml apiVersion: v1 kind: ServiceAccount metadata: name: cloudwatch-log-forwarder-sa namespace: openshift-logging 作成したserviceaccount.yamlをROSAクラスターに適用します。 $ oc apply -f secret.yaml ClusterRoleBindingのデプロイ ログ収集エンジンにログ収集権限を付与するため、ClusterRoleBindingリソースでServiceAccoutに権限の割り当てを行います。 割り当てるClusterRoleは Cluster Logging Operatorのデプロイ時に自動で作成されるClusterRoleを割り当てます。 以下はClusterRoleBindingのサンプルになります。 cluster-role-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: logging-collector-logs-writer-crb subjects: - kind: ServiceAccount name: cloudwatch-log-forwarder-sa namespace: openshift-logging roleRef: kind: ClusterRole name: logging-collector-logs-writer apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: collect-application-logs-crb subjects: - kind: ServiceAccount name: cloudwatch-log-forwarder-sa namespace: openshift-logging roleRef: kind: ClusterRole name: collect-application-logs apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: collect-infrastructure-logs-crb subjects: - kind: ServiceAccount name: cloudwatch-log-forwarder-sa namespace: openshift-logging roleRef: kind: ClusterRole name: collect-infrastructure-logs apiGroup: rbac.authorization.k8s.io 作成したcluster-role-binding.yamlをROSAクラスターに適用します。 $ oc apply -f cluster-role-binding.yaml ClusterLogForwarderのデプロイ ログ収集エンジンをデプロイするためのカスタムリソース(CR)であるClusterLogForwarderをデプロイします。 OpenShift Logging OperatorはClusterLogForwarderに定義した設定内容に基づいてログ収集エンジンをデプロイします。 以下はClusterLogForwarderのサンプルになります。 cluster-log-forwarder.yaml apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: cloudwatch-cluster-log-forwarder namespace: openshift-logging spec: collector: tolerations: - operator: "Exists" serviceAccount: # 3.ServiceAccoutのデプロイで作成したServiceAccout名を指定 name: cloudwatch-log-forwarder-sa outputs: - name: cloudwatch-output type: cloudwatch cloudwatch: # 作成したロググループ名を指定 # {.log_type||"unknown"}の部分はinputRefsで指定している「application」・「infrastructure」の文字列が埋め込まれる groupName: '/rosa/hcp-cluster/{.log_type||"unknown"}' # ロググループを作成したリージョンを指定 region: us-east-1 authentication: type: iamRole iamRole: roleARN: key: role_arn # 2.Secretリソースのデプロイで作成したSecret名を指定 secretName: cloudwatch-credentials token: from: serviceAccount pipelines: - name: to-cloudwatch # アプリケーションログとインフラストラクチャログを収集するように指定 inputRefs: - application - infrastructure outputRefs: - cloudwatch-output 作成したcluster-log-forwarder.yamlをROSAクラスターに適用します。 $ oc apply -f cluster-log-forcluster-log-forwarder.yaml 動作確認 OpenShift Loggingのインストール後、Podが正常に起動しているか確認してください。 $ oc get pod -n openshift-logging NAME READY STATUS RESTARTS AGE cloudwatch-cluster-log-forwarder-fngmj 1/1 Running 0 61s cloudwatch-cluster-log-forwarder-pgx5h 1/1 Running 0 62s cluster-logging-operator-8646fc6b78-5hh5v 1/1 Running 0 12m 次に、作成したロググループにインフラストラクチャログ・アプリケーションログが転送されていることを確認してください。 ※今回はアプリケーションログを出力させるために「test」というnamespace配下にテスト用の「app-log-test」という名前のPodを起動させ、ログ出力させています。 作成したロググループにアプリケーションログ・インフラストラクチャログのログストリームが作成されていることがわかります。以上で、アプリケーションログ・インフラストラクチャログをCloudWatch Logsに転送する設定は完了になります。 【補足】監査ログ（Audit Logs）の転送設定について ROSA with HCPにおける監査ログはRedHatが管理するコントロールプレーン側で出力されるため、ワーカーノード上に存在するOpenShift Loggingではログの収集が行えません。 そのため、ROSA with HCPでは、監査ログをCloudWatch Logsへ転送する標準機能が用意されています。 監査ログのCloudWatch Logsへの転送を有効化したい場合は、ROSAがCloudWatchにログを書き込むための専用IAMロールを作成し、そのIAMロールのARNを rosa コマンドのオプションに設定します。 以下はCloudFormationでIAMロールを作成する際のサンプルになります。 AWSTemplateFormatVersion: '2010-09-09' Description: 'IAM Role and Policy for ROSA HCP Audit Log' Parameters: # ROSA構築時に作成したOIDCエンドポイント OidcEndpoint: Type: String Description: 'The OIDC Endpoint' Resources: # 1. CloudWatch Logs へのアクセス許可ポリシー RosaAuditLogPolicy: Type: 'AWS::IAM::ManagedPolicy' Properties: ManagedPolicyName: 'rosa-audit-log-policy' PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - 'logs:CreateLogGroup' - 'logs:CreateLogStream' - 'logs:DescribeLogGroups' - 'logs:DescribeLogStreams' - 'logs:PutLogEvents' - 'logs:PutRetentionPolicy' Resource: 'arn:aws:logs:*:*:*' # 2. Auditログ転送用 IAM ロール RosaAuditLogRole: Type: 'AWS::IAM::Role' Properties: RoleName: 'rosa-audit-log-role' AssumeRolePolicyDocument: !Sub | { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/${OidcEndpoint}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OidcEndpoint}:sub": "system:serviceaccount:openshift-config-managed:cloudwatch-audit-exporter" } } } ] } ManagedPolicyArns: - !Ref RosaAuditLogPolicy 上記CloudFormationの「OidcEndpoint」というパラメーターには、OpenShift Logging用のIAMロールを作成した時と同様に、oidc-configの「ISSUER URL」の「https://」を除いた値を設定してください。 CloudFormationを適用すると以下のIAMロールが作成されます。 以下のrosaコマンドで監査ログの転送を有効化します。 $ rosa edit cluster --cluster=<クラスター名> \ --audit-log-arn="arn:aws:iam::xxxxxxx:role/rosa-audit-log-role" CloudWatch Logsに以下のようなロググループが作成されていれば、監査ログの転送設定は完了です。 ※ロググループ名は「ocm-production-<クラスターのID>-<クラスター名>」の形式で自動作成されます。 また、クラスター構築時に–domain-prefixを設定していた場合は、「ocm-production-<クラスターのID>-<domain-prefixの値>」の形式となります。 おわりに ROSAクラスターにおけるCloudWatch Logsへのログ転送方法について解説しました。 実際にROSAクラスターを運用する際の参考になれば幸いです。 次回はROSAクラスター上のメトリクスをCloudWatchに転送する方法についてご紹介します。 参考文献 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4 https://docs.aws.amazon.com/ja_jp/rosa/latest/userguide/what-is-rosa.html https://docs.redhat.com/en/documentation/red_hat_openshift_logging/6.6/html/install/installing-the-red-hat-openshift-logging-operator ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~ ログ転送設定 ~ first appeared on SIOS Tech Lab .

こんにちはサイオステクノロジーの前田です。 インフラを作成し運用するときには監視を行います。Kubernetes環境でも同様に監視を行います。最近では監視にプラスして「オブザーバビリティ」という、いろいろな情報を収集していくケースがあり、運用の情報整理がどんどん複雑になってきています。今回はKubernetesの基本的な監視と、オブザーバビリティについて記載します。 従来の仮想マシンや物理サーバー環境と比較して、Kubernetes環境ではコンテナの頻繁な生成・破棄、動的なIP割り当て、分散されたアーキテクチャなどの特徴があります。これに伴い生成されるログやメトリクスデータの量が劇的に増加するため、既存通りの運用ということはあまり適切でないこともあり、適切な要件整理と最適なソリューション選定が必要となります。 Kubernetes オブザーバビリティとは まず、混同されがちな「監視」と「オブザーバビリティ」を区別しましょう。 従来の「監視（Monitoring）」と「オブザーバビリティ」の違い 監視（Monitoring）： あらかじめ定義された異常（CPU高負荷、プロセスダウン等）が発生したことを検知・通知する受動的な仕組み。 オブザーバビリティ（Observability）： システムの外部出力データ（メトリクス、ログ、トレース）から、内部の状態や未知のトラブルの根本原因を「探索・特定」できる能動的な能力。   大規模な構成や継続的な開発ではオブザーバビリティの仕組みを入れることは有効です。ただコンテナ利用の最初期から導入するのは目的が見えなくて無駄が多いものです。そのためKubernetesソリューション構築初期設定にはオブザーバビリティソリューションが全部入っていない方が一般的です。 オブザーバビリティの3大要素 オブザーバビリティを実現するには、以下の3つのデータを収集して連携させていきます。   データの種類 内容 主な対象例 メトリクス（Metrics） システムの数値を定期的に計測・集約した数値データ ホスト/コンテナのCPU・メモリ使用率、Podの再起動回数 ログ（Logs） システムやアプリケーションで発生したイベントの記録データ K8sイベントログ、コンテナ標準出力（stdout/stderr）、アクセスログ トレース （Traces） 分散環境における一連のリクエスト処理経路を追跡するデータ マイクロサービス間のHTTP/gRPC呼び出し履歴、処理遅延箇所の特定 オブザーバビリティ利用時の注意点・課題 オブザーバビリティのデータ収集時には注意点や課題が発生します。よく発生する課題を下記に記載します。 データの肥大化とコスト増： Kubernetes非利用時と比較してメトリクスやログの量が膨大になります。従来同等の保持期間・取得設定にすると、ストレージコストの増大や監視ソリューション側の処理遅延を引き起こします。ログが１日に１ノードあたり数十ＧＢになるケースもあるため、データ転送する対象やデータ量を検討する必要が有ります。 データの保持期間と間引き（サンプリング）： 運用要件に合わせて、保持期間の設定（短期間保持、古いデータの自動削除）やテスト環境での試算を行う必要があります。ソリューションによってはデータの長期間保存に対応していないものも存在します。 代表的なソリューション Kubernetesにおけるオブザーバビリティソリューションには、オープンソース（OSS）から商用SaaSまで多様なツールが存在します。 機能別の主要OSSソリューション カテゴリ 代表的なツール・ソリューション 特徴 メトリクス収集・保管 Prometheus, VictoriaMetrics K8s標準のメトリクス収集基盤。大規模環境ではVictoriaMetrics等の長期保管向けエンジンの検討も有効。 ログ集約・管理 Fluent Bit, Fluentd, Grafana Loki 軽量なFluent Bitで収集し、Lokiに保管。 分散トレーシング Jaeger, Grafana Tempo, OpenTelemetry リクエスト追跡。OpenTelemetry（OTel）を標準SDKとして活用する構成が増加。 可視化（ダッシュボード） Grafana メトリクス・ログ・トレースを一元化して可視化・相関分析する標準ツール。 プラットフォーム組み込みモニタリング 主要なコンテナプラットフォームでは、Prometheusを中心としたモニタリング機能がデフォルトまたはアドオンとして提供されています。 OpenShift Monitoring: プラットフォーム構築時に標準でデプロイされる統合監視環境。 Rancher Monitoring: クラスター構築後にワンクリックで設定・統合可能なモニタリングスタック。 Prometheus Operator 最小限かつ標準的なKubernetesモニタリング構成を構築・運用する際、OSSの Prometheus Operator が広く採用されています。Prometheusという場合はPrometheus Operatorではなくメトリクス収集・蓄積の機能のPrometheusを指します。しかし、単体で導入することよりも運用しやすいように連携しているPrometheus Operatorの形式でインストールされることの方が多いです。 Prometheus Operatorの主な構成コンポーネント Prometheus Server: メトリクスの収集（Pull型）、時系列データベースへの保存。 Alertmanager: 条件に応じたアラートの集約・抑制・通知（Slack, メールなど）。 node-exporter: ホスト（ノード）レベルのハードウェア・OSリソースのメトリクス出力。 kube-state-metrics: Pod, Deployment, NodeなどKubernetesオブジェクトの状態メトリクス生成。 Grafana: 収集されたメトリクスを可視化するダッシュボード。 おわりに オブザーバビリティに関してKubernetes構成に慣れていない時点で多くの機能を導入した場合使いこなせないケースもあります。オブザーバビリティの導入については最初期はPrometheus Operatorを導入して、その後必要な機能を検討することがお勧めです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Kubernetesオブザーバビリティのはじめ first appeared on SIOS Tech Lab .