AIツールの進化が加速するなか、エンジニアの仕事はどう変わっているのか。日々の開発でAIを使い続けるエンジニア3名に、活用の実態から失敗談、半年後の開発スタイルの展望まで、本音で語ってもらいました。 登場人物 名前 役割 あさしん( @asashin227 ) （写真右下） 名古屋プロダクト部のエンジニアリングマネージャー。仕事でもプライベートでもAIをうまく使う方法を常に模索中。エンジニア以外でもAIを使えるようにスタメン内でのハンズオンやAIもくもく会を運営しています おしん( @38Punkd ) （写真左下） iOS開発を得意とするエンジニア。AIを使って積極的にAndroidやWeb技術にチャレンジ中。プライベートではAIでインフラ中心のエンジニアをしている いが( @cochumo ) （写真真ん中） フロントエンドを専門領域としているエンジニア。AIを使ってバックエンド開発にも軸足を伸ばしています。今回のインタビュアーも兼任。 1日の業務の50〜80%がAIと対話。コードの外にも使い道は広がる ── 1日の業務のうち、何%くらいAIと対話したり、作業を任せたりしていますか？ あさしん： ミーティングが結構多いので、思ったよりは使えていないんですよね。それでも50〜60%くらいにはなっていると思います。ミーティングの前に依頼しておいて、ミーティング後に確認みたいな使い方をしています。 おしん： 自分はあまりミーティングが多くないので、70〜80%は使っていますね。 いが： 60%ぐらいでしょうか。作るものの方向性についてメンバーとディスカッションする部分は人間がやらないといけないので、100%にはならないですね。 ── どんな場面でAIを活用していますか？ おしん： 仕様の方向性をまずAIと話して、提案の形に整えてから人間とのディスカッションに持ち込む流れが増えてきました。ステークホルダーへの合意形成の前段階だったり、CS（Customer Success）へのお知らせ文や顧客との調整の頭出しにも使っています。まるっと投げるというよりは、自分なりの仮説がある状態でブラッシュアップしていく、という使い方が多いですね。 あさしん： 最近はClaude Cowork（以下Coworkと表記）をコーディング以外の場面でも使えるようにしていきたいなと思っていて、少しずつ試しています。割合はこれからも増えていきそうだという感覚はありますね。 いが： Coworkいいですよね。社内のチャットのステータス変更の処理を自動化してスケジューリングさせるような使い方は、本当に助かっています。 スピードは上がった。でも、楽しさの「質」が変わった ── AI導入から、開発のスピード感や楽しさはどう変わりましたか？ あさしん： スピード感は確実に上がりましたね。やりたいことを自然言語で書けばとりあえず動く状態になるので、試行錯誤の回数が格段に増えています。ただ、仕事においては「プログラミングは自分がやらなくていい」という目標をもともと持っていたので、AIがコードを書くことへの心理的な変化はそれほどないというか。メンバーが書いてくれるのとAIが書いてくれるのとで、感覚的にはさほど変わらないんです。変わったと思うのは、人との解釈合わせにかかるコミュニケーションコストが減ったことです。AIへの指示は自分の責任で完結するから、より言語化の精度を上げないといけないという意識が強まりましたね。 おしん： 楽しさという意味では、むしろ大きくなりました。これまでネット上の記事を探し回ることに費やしていた時間をAIが肩代わりしてくれるので、「プロダクトの仕様をどう改善すれば売上に貢献できるか」という、本来考えるべきことに頭を使える時間が増えています。 いが： AIの進化にはワクワクするんですけど、AIに実装をやらせているとき自体はそんなにワクワクしなくなってきました。自分が書いていないからのめり込めなくて、複数のことを並行して浅く広く動かす形になってしまっている。コードを書いているときの楽しさは、正直なくなってきましたね。 おしん： ただ、その代わりに。職人的な充実感よりも、事業を前に進めている手応えに重きが移ってきた感覚がありますね。 ── 具体的に「これはAIにやらせて正解だった」という事例はありますか？ あさしん： テストケースを大量に作らせるのはAIが得意な領域で、活用しています。あとは先ほど触れたCoworkですね。カンファレンスのグッズを企画するときに、会話の中で出てきたアイデアをそのままデータ化したり、作ったデータをNano Bnanaで画像に合成して、それっぽいイメージを可視化できるのが便利でした。コーディング以外のプロトタイプも、以前より格段に作りやすくなっています。 いが： Coworkは自然言語で指示してワークフローを組むと、ブラウザ操作まで実行してくれます。そこが本当に大きい。こういった活用はこれからさらに広がっていくんだろうなと感じています。 ガードレールを引かないと、リポジトリもドキュメントも静かに汚れていく ── 逆に、失敗したことや、気をつけていることはありますか？ あさしん： 個々のミスというより、チーム全体として気になっているのはリポジトリに入っているドキュメントが少しずつ汚れていくことです。うちもそこまでドキュメントの文化が強いわけじゃないので、誰も深く見ていない箇所でAIが誤った内容を書き込んでいても気づけない。ガードレールをきちんと設計しておかないと、気づかないうちに的外れな方向へ進んでしまう。意識して向き合わなければならない課題だと思っています。 おしん： 嘘とまでは言えないけれど、根拠があいまいなままでも断言してしまうのがAIの特性だと思っていて。わずかでも事実と違う内容が混ざると、ドキュメント全体の信頼性が揺らいでしまいますよね。 いが： 仕様書をAIに書かせた場合でもユーザーインタビューに基づいた内容なのか、推測で書いたものなのか、根拠がまったくない記述なのか、読んだだけでは区別がつかない。その3パターンをちゃんと分類する仕組みを作って曖昧なところを明示的に固めていく、そういう工夫をこれからも続けていきたいですね。 ── プロンプトや指示の出し方で、自分なりにこだわっていることはありますか？ あさしん： まず一度考えさせる、というのは意識しています。「プランニングしてください」と明示的に書いてから進めるようにしていて。あとは、プロンプトで都度指示することより、ドキュメントを整えて自動的によい動きをしてくれる環境をつくることを優先していますね。スキルの整備やエージェントの動きを定期的に見直すのも続けています。週に一度くらいは、同じ作業を繰り返していたらスキルとして切り出す習慣もつけています。 セッションの履歴を見て、繰り返しやっていることをスキル化するのは効果的です。全セッションを遡る必要はなく、そのセッション内のやり取りから切り出すだけで十分なことが多い。CLI（Command Line Interface）やLSP（Language Server Protocol）をちゃんと使い込むと、その辺りがうまく機能すると思いますね。 これからのエンジニアに求められるのは、ドメイン分解力・抽象力・言語化力だ ── 半年後、自分たちの開発スタイルはどうなっていると思いますか？ あさしん： コーディング作業そのものは今より少なくなると思っています。その代わり、課題を持っているステークホルダーとのコミュニケーションがより重要になってくる。FDE（Forward Deployed Engineer）と呼ばれる役割、つまりお客さんの現場に立ってエンジニアとして提案していくような動き方も、これから注目されていくはずです。 いが： すでに別の会社では、CxO（Chief x Officer）にAI活用が得意な人を一人つけて、その人がやりたいことをPoC（Proof of Concept: 概念実証）化していくという動き方をしているところも出てきていますよね。 おしん： Figmaじゃなくてプロダクトレベルでのモックを素早く作る、という段階は確実に進んでいくと思います。エンジニアの強みは、やりたいことに対してどのアプローチが現実的かを具体的に示せる点にあります。自分のタスクや技術領域だけを見ていればいいという姿勢は通用しなくなって、事業全体を見渡して課題を見つけ動かしていけるエンジニアが、これからの開発を牽引していくと思っています。 ── AIが進化し続ける中で、エンジニアが磨くべき「コアスキル」とは何でしょうか？ あさしん： ITバブルの頃、エンジニアの工数が一番レバレッジが効くと言われていたのは、一人分の工数をかけることで、かけた工数をソフトウェアとして何万人というユーザーに展開できる、かけ算的な成長ができるからでした。今後はAIによってプログラミングが民主化されて誰もが主体的に開発できるようになってくる。そういった中で自分たちが発揮できる価値を捉えていく必要があります。アウトプットがソフトウェアである以上、ソフトウェアがわかる人向けの言語化の仕方はエンジニアならではの強みになると思う。 あとはロジックの破綻を整理してあげるとか、ドメイン駆動開発をエンジニアが担ってAIにドメインごとの指示を出していくとか、そういうやり方が主流になっていくでしょう。ドメイン分解能力、抽象能力、言語化能力、そして事業全体を俯瞰できる広い視野。自分のタスクだけ見ていればいいというエンジニアはどんどん淘汰されていって、事業全体から課題を見つけて推進できるエンジニアが成長して牽引できると思っています。 おしん： エンジニアの専門性はPMやデザイナーとも融合してきているし、モバイル・バックエンド・フロントエンドといった境界もなくなりつつある。そこをコアスキルにするのはもったいない。エンジニアが磨くべきは事業理解であり、事業ドメインをソフトウェア設計に落とし込んで、リリース後も安定的に運用できる力こそが本質なんじゃないかと思っています。 おわりに 今回はテックブログとしては新しい取り組みである「エンジニア3人でAI活用の座談会をする」という記事を作成しました。 AIを使える人と使えない人で、仕事の速さも質も変わってきており、何に注力して、何をAIに任せていくか、そして自身の思考をどこに使っていけばいいのかヒントが掴めたように思えます。 AIの使い方に正解はないからこそ、同じように模索しているエンジニアの方とお話してみたいと思っています。この記事が、そのきっかけになれば嬉しいです。 herp.careers 本記事はインタビュー音声をもとに編集・再構成しています。

S3 Files という新しい機能が発表されましたので、さっそく使ってみました。 また、ざっとドキュメントを読んだ所感もあわせて書いておきます。 Announcing Amazon S3 Files, making S3 buckets accessible as file systems - AWS Discover more about what's new at AWS with Announcing Amazon S3 Files, making S3 buckets accessible as file systems aws.amazon.com 概要 S3 Files は、**汎用 S3 バケットを EC2、Lambda、ECS/EKS などからマウントし、ファイルシステムとして利用できる機能**です。 S3 Vectors のように別種の S3 リソースが増えるわけではなく、利用するのは通常の汎用 S3 バケットです。 以前から Mountpoint for Amazon S3 という仕組みはありました。 こちらも S3 バケットをマウントして使えるという点では似ていますが、あくまでクライアント側のツールであり、共有ファイルシステムそのものではありません。 それに対して S3 Files は、S3 バケットを背後に持ちながら、より本格的なファイルシステムとして扱えるようにした機能、という理解です。 ファイルシステム作成 前提として、リンク先となる汎用 S3 バケットではバージョニングを有効化しておく必要があります。 「ファイルシステムを作成」をクリックします。 事前に作成しておいたバージョニング有効済みのバケットと、マウントターゲットが作成される VPC を選択します。 私の環境では、この後 5 分ほどで作成が完了しました。 作成できました。見た目はかなり EFS を思い出させます。 実際、ドキュメントによれば S3 Files は Amazon EFS を用いて実装されているようです。 マウントターゲット EFS と同様に、マウントターゲットが指定した VPC 配下に作成されます。 セキュリティグループはデフォルトのものがアタッチされていました。 このままでは使えない場合があるため、マウント元の EC2 などから通信できるよう、適切なセキュリティグループに変更または設定を調整しておく必要があります。 EC2 からのマウント 前提：EC2 に付与された IAM ロールに十分な権限が必要です。今回は検証のため、Administrator 権限を付与した状態で実行しています。 上記画面の「EC2 インスタンスへのアタッチ」より、マウント手順を確認できます。 アタッチ先 EC2 やマウントポイントなどを指定すると、下部のコマンド例に内容が反映されます。 この画面の入力はコマンド例に反映されるだけで、実際の変更はそのコマンドを実行して行います。 手順どおりに実行するだけですが、内部的には efs-utils を使うようです。 したがって、efs-utils の前提条件は満たしておく必要があります。 $ sudo mount -t s3files fs-011ca9d3df3f21efd /mnt/s3files $ sudo mount | tail -n 1 127.0.0.1:/ on /mnt/s3files type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20721,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1) $ df -T /mnt/s3files Filesystem Type 1K-blocks Used Available Use% Mounted on 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/s3files OS からは NFSv4 のファイルシステムとして見えていることが分かります。 続いて、一般ユーザーが扱えるサブディレクトリを作成し、その中でファイルを作成してみます。 $ sudo mkdir -p /mnt/s3files/work $ sudo chown ec2-user:ec2-user /mnt/s3files/work $ chmod 755 /mnt/s3files/work $ touch /mnt/s3files/work/hello.txt $ ls -l /mnt/s3files/work/hello.txt -rw-r--r--. 1 ec2-user ec2-user 0 Apr 8 10:06 /mnt/s3files/work/hello.txt $ echo "Hello S3 Files" >> /mnt/s3files/work/hello.txt $ cat /mnt/s3files/work/hello.txt Hello S3 Files ファイルの作成と追記ができました。 S3 バケット側を確認すると、ファイルが作成されており、内容も反映されていました。 自動マウントについては、fstab などを使って構成できそうですが、今回は未検証です。 アーキテクチャ おおよそ以下のような構成になっているようです。 ※ あくまでドキュメントを読んだ上での個人の理解です。 S3 とのやり取りを仲介する S3 Files が中間層として動作し、EC2 や Lambda、ECS/EKS などの compute resource は、この S3 Files を共有ファイルシステムとして利用するイメージです。 ファイルの変更はまず S3 Files 側で処理され、その後 S3 バケットへ同期されます。 一方、読み取りについては常に同じ経路を通るわけではなく、データサイズやアクセスパターンに応じて最適化されるようです。 前述の Mountpoint for Amazon S3 は、クライアント側で動くツールとしてファイル操作と S3 API の間を橋渡しするものでした。 それに対して S3 Files は、共有ファイルシステムとしての意味合いが強く、設計思想からかなり異なるように見えます。 また、S3 Files 作成時には S3 Files 用の IAM ロールが作成され、その権限で S3 バケットとの同期処理を行う構成になっています。 ただし、これだけで完結するわけではなく、マウントする側の EC2 などにも別途 IAM 権限が必要です。 権限関連 当然ながら、利用には IAM 権限が必要です。 権限はざっくり分けると、以下の 3 種類があります。 S3 Files を作成・管理するための権限 S3 Files 自身が S3 バケットと同期するための権限 EC2 や ECS/EKS など、実際にマウントして使うクライアント側の権限 単に S3 の権限だけでよいわけではなく、新しい service prefix である s3files: の権限も必要になります。 また、クライアント側には s3files:* 系の権限に加えて、状況によってはリンク先 S3 バケットを直接読むための権限も必要です。 したがって、実運用では権限設計はかなり丁寧にやる必要がありそうです。 How S3 Files works with IAM - Amazon Simple Storage Service Learn how S3 Files works with IAM. docs.aws.amazon.com 最後に 今回は EC2 からマウントして試してみましたが、同時に Lambda や ECS/EKS からも利用できるようです。 そのため、サービス間でファイルを受け渡すような構成はかなりやりやすくなりそうです。 S3 を単なるオブジェクト置き場として使うのではなく、共有ファイルシステムのように扱えるようになる、というのがこの機能の面白いところだと思いました。 今回はハンズオン目的だったため、権限関連はかなり雑に試しています。その点はご了承ください。 お読みいただきありがとうございました。

本記事は 2026 年 4 月 3 日 に公開された「 Introducing OpenTelemetry & PromQL support in Amazon CloudWatch 」を翻訳したものです。 Kubernetes やマイクロサービスのワークロードを AWS で実行している場合、メトリクスには namespace、pod、container、node、deployment、replica set、カスタムのビジネスディメンションなど、多数のラベルが付いているでしょう。環境全体を把握するために、メトリクスパイプラインを分割しているケースも多いはずです。AWS メトリクスには Amazon CloudWatch を使い、高カーディナリティ (多数のラベルの組み合わせを持つ) なコンテナやアプリケーションのメトリクスには別の Prometheus 互換バックエンドを使う、といった具合です。さらに進んだチームでは、Prometheus CloudWatch エクスポーターで GetMetricData API を呼び出し、AWS リソースメトリクスを Prometheus バックエンドに取り込んでいることもあります。運用負荷とコストは増えますが、すべてを一箇所でクエリできるようになります。 Amazon CloudWatch で OpenTelemetry メトリクス のネイティブ取り込みと、 Prometheus Query Language (PromQL) によるクエリがサポートされました。このプレビュー機能では、メトリクスあたり最大 150 ラベルをサポートする高カーディナリティメトリクスストアが導入され、ラベルの多いメトリクスを変換や切り捨てなしで CloudWatch に直接送信できます。AWS Vended メトリクスの自動エンリッチメントと組み合わせることで、CloudWatch がインフラストラクチャ、コンテナ、アプリケーションメトリクスの一元的な送信先になり、すべて PromQL でクエリできるようになりました。 本記事では、以下の内容を説明します。 AWS アカウントで OpenTelemetry メトリクスの取り込みと AWS リソースの自動エンリッチメントを有効化する方法 Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに Amazon CloudWatch Container Insights をデプロイする方法 Amazon CloudWatch と Amazon Managed Grafana で PromQL を使ってインフラストラクチャと AWS リソースのメトリクスをクエリする方法 OpenTelemetry SDK でカスタムアプリケーションメトリクスを作成し、AWS コンテキストで自動エンリッチメントされる様子 CloudWatch における OpenTelemetry サポートが何を意味するか OpenTelemetry Protocol (OTLP) は、OpenTelemetry (OTel) プロジェクトの標準ワイヤープロトコルです。メトリクス、トレース、ログを含むテレメトリデータのエンコードとコンポーネント間の転送方法を定義しています。このプレビューにより、CloudWatch は OpenTelemetry 互換のコレクターや SDK がメトリクスを送信できるリージョナル OTLP エンドポイントを公開します。 CloudWatch はメトリクスを受信し、新たな高カーディナリティのメトリクスストアに保存します。カウンター、ヒストグラム、ゲージ、アップダウンカウンターなどの OpenTelemetry メトリクスタイプは変換なしでそのまま保持されます。今回のリリースで、CloudWatch はオブザーバビリティの 3 本柱すべてで OpenTelemetry をサポートするようになりました。CloudWatch はすでに OTLP エンドポイント 経由でトレースとログを受け付けており、ネイティブ OTLP メトリクス取り込みが加わったことで、すべてのテレメトリをオープンスタンダードで、単一のプロトコルを通じて CloudWatch に送信できるようになりました。3 つの機能がこのことを重要にしています。 拡張されたラベルとカーディナリティのサポート OTLP で取り込まれたメトリクスは最大 150 ラベルをサポートし、CloudWatch カスタムメトリクスの 30 ディメンション制限を超えています。Kubernetes、マイクロサービス、OpenTelemetry ワークロードでフィルタリングや集計に高カーディナリティラベルを使う際の主要な制約が解消されます。制限は今後も進化するため、最新情報は クォータページ をご確認ください。 PromQL クエリのサポート OTLP 経由で取り込んだメトリクスを PromQL でクエリできます。すでに Prometheus を使っている場合、同じクエリ言語を CloudWatch や Amazon Managed Grafana で直接使えます。新しい構文を覚える必要はありません。 AWS リソースの自動エンリッチメント この機能により、AWS インフラストラクチャ全体でメトリクスをクエリ・フィルタリングする方法が根本的に変わります。CloudWatch は取り込んだすべてのメトリクスに AWS リソースコンテキスト (アカウント ID、リージョン、クラスター Amazon Resource Name (ARN)、AWS Resource Explorer からのリソースタグ) を付与します。このエンリッチメントは追加の計装なしで自動的に行われます。Container Insights、カスタムアプリケーション、AWS サービスのいずれから来たメトリクスでも、AWS アカウント、リージョン、環境タグ、アプリケーション名でフィルタリングやグループ化ができます。エクスポーター不要、カスタムラベル不要、追加の API 呼び出し不要です。 図 1: Amazon CloudWatch における OpenTelemetry メトリクスの取り込みとエンリッチメントアーキテクチャ OTLP 取り込みと AWS リソースエンリッチメントの有効化 OTLP メトリクスを取り込んでクエリする前に、2 つのアカウントレベルの設定を有効にします。1 つ目は、AWS Resource Explorer で確認できるものと同じリソースタグをテレメトリに伝播させる設定です。2 つ目は、CloudWatch の OTLP 取り込みを有効にする設定です。 両方のエンリッチメント設定は、Amazon CloudWatch コンソールまたは AWS CLI から有効にできます。 コンソールを使用する場合 CloudWatch コンソールでエンリッチメントを有効にする手順は以下のとおりです。 Amazon CloudWatch コンソールを開きます。 ナビゲーションペインで 設定  を選択します。 リソースタグのテレメトリへの伝播を有効にします。 AWS メトリクスの OTel エンリッチメントを有効にします。 両方の設定を有効にすると、アカウントでリージョナルエンドポイントへの OTLP メトリクス受信の準備が整います。 図 2: CloudWatch コンソール設定での OTel エンリッチメントとリソースタグの有効化 AWS CLI を使用する場合 AWS CLI で両方のエンリッチメントレイヤーを有効にすることもできます。以下のコマンドを実行します。 # Enable resource tags on telemetry aws observabilityadmin start-telemetry-enrichment # Enable OTel enrichment for CloudWatch aws cloudwatch start-o-tel-enrichment 両方のエンリッチメント設定がアクティブであることを確認するには、以下のコマンドを実行します。 aws cloudwatch describe-o-tel-enrichment-status エンリッチメントを有効にすると、OTLP エンドポイント経由で取り込まれたすべてのメトリクスに AWS リソースコンテキストが自動的にタグ付けされます。CloudWatch が追加する属性は以下のとおりです。 Attribute 説明 例 @aws.account AWS アカウント ID 123456789012 @aws.region AWS リージョン us-west-2 cloud.resource_id EKS クラスターの完全な ARN arn:aws:eks:us-west-2:123456789012:cluster/prod k8s.cluster.name EKS クラスター名 production-cluster k8s.namespace.name Kubernetes namespace karpenter k8s.container.name コンテナ名 controller @instrumentation.name 計装ソース cloudwatch-otel-ci リソースタグ AWS Resource Explorer からのタグ (@aws.tag.Application、@aws.tag.CostCenter、@resource.ec2.tag.ManagedBy など) env=production これらの属性は CloudWatch によって追加され、手動の計装は不要です。カスタムパイプラインの構築やエクスポーターの実行なしに、AWS アカウント、リージョン、リソースタグをまたいでクエリできるのはこのためです。 OpenTelemetry メトリクスを使った Amazon CloudWatch Container Insights OpenTelemetry と CloudWatch の連携を実際に確認するため、Container Insights から始めましょう。Amazon EKS 向け Amazon CloudWatch Container Insights で Prometheus と OpenTelemetry メトリクスが サポートされました 。コンテナメトリクスが OpenTelemetry attribute で標準化され、PromQL でクエリできるようになります。Container Insights は、コンソールまたは AWS CLI から Amazon EKS アドオンを使って 有効化 できます。 Container Insights ダッシュボード Container Insights をデプロイすると、CloudWatch は CPU 使用率、メモリ使用量、Pod 数などのクラスターレベルのメトリクスを表示するダッシュボードを自動的に作成します。ダッシュボードを表示するには、CloudWatch コンソールを開き、ナビゲーションペインから Container Insights を選択し、ドロップダウンからクラスターを選択します。クラスター、namespace、Pod レベルのビューを切り替えて、特定のワークロードを詳しく確認できます。 図 3: Amazon CloudWatch Container Insights ダッシュボード CloudWatch Query Studio で PromQL を使ってメトリクスをクエリする OTLP で取り込んだメトリクスは、CloudWatch コンソール、Amazon Managed Grafana、または PromQL と AWS Signature Version 4 (SigV4) をサポートするクエリインターフェースで PromQL を使ってクエリできます。 CloudWatch Query Studio には、コンソールで直接メトリクスを探索・可視化するための PromQL エディターが組み込まれています。PromQL クエリモードを選択して開始します。 図 4: PromQL クエリモードの Amazon CloudWatch Query Studio インターフェース エンリッチされた AWS リソースコンテキストを使ったクエリ エンリッチメントが有効になっているため、CloudWatch が自動的に追加するタグを使って AWS リソースの境界を越えてクエリできます。エクスポーター不要、カスタムラベル不要です。 # AWS Lambda function duration for functions tagged with application "order-pipeline" Duration{"@aws.tag.appname"="order-pipeline"} # Amazon EC2 CPU utilization for production delivery workloads CPUUtilization{"@aws.tag.Environment"="production", "@aws.tag.Application"="delivery"} # Running pods grouped by AWS account and namespace sum by (aws_account_id, k8s_namespace_name) (kube_pod_status_phase{phase="Running"}) 最後のクエリは、カスタム計装なしで AWS アカウントと Kubernetes namespace ごとにグループ化された実行中の Pod 数を返します。 aws_account_id ラベルはエンリッチメントレイヤーによって自動的に追加されます。 図 5: Lambda duration メトリクスをクエリする CloudWatch Query Studio Grafana で PromQL を使ってメトリクスをクエリする Amazon Managed Grafana で OTLP 取り込みメトリクスを可視化するには、CloudWatch PromQL エンドポイントを指す Prometheus データソースを追加します。このセクションでは、AWS Signature Version 4 (SigV4) 認証でデータソースを設定する手順を説明します。 Amazon Managed Grafana ワークスペースを開きます。 Data Sources を選択します。 Add data source を選択します。 データソースタイプとして Prometheus を選択します。 URL には、リージョンの CloudWatch PromQL エンドポイントを入力します: https://monitoring.<AWS Region>.amazonaws.com/v1/metrics Authentication で SigV4 を選択します。 SigV4 認証用の適切な IAM ロールを設定します。 Save & Test を選択して接続を確認します。 Save & Test が成功すると、「Data source is working」という確認メッセージが表示されます。失敗した場合は、IAM ロールに cloudwatch:GetMetricData と cloudwatch:ListMetrics の権限があること、SigV4 署名が正しく設定されていることを確認してください。 データソースを設定すると、Grafana ダッシュボードで同じ PromQL クエリを使用できます。 図 6: CloudWatch PromQL を使った Grafana Explore カスタムアプリケーションメトリクス CloudWatch OTLP 取り込みはカスタムアプリケーションメトリクスもサポートしています。OpenTelemetry SDK で計装されたアプリケーションは、クラスターで実行中の CloudWatch エージェント経由でメトリクスを送信でき、計装コードの変更は不要です。 実際の動作を確認するため、 aws-otel-community リポジトリからサンプル Python アプリケーションをデプロイします。このアプリケーションは OpenTelemetry Python SDK を使用して、カウンター、ヒストグラム、ゲージ、アップダウンカウンターなど、すべての OTel メトリクスタイプをカバーするカスタムメトリクスを出力します。例えば、アプリは API レスポンス時間を測定する latency_time ヒストグラムを定義しています。 from opentelemetry import metrics meter = metrics.get_meter(__name__) # Histogram --- measures API latency distribution latency_time = meter.create_histogram( name="latency_time", description="Measures latency time", unit="ms", ) サンプルアプリケーションのデプロイ サンプルアプリケーション とすべてのデプロイマニフェストは、GitHub の aws-otel-community リポジトリにあります。先ほどデプロイした Container Insights アドオンには、OpenTelemetry コレクターとして機能する CloudWatch エージェントが含まれています。 OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を設定して、サンプルアプリをエージェントに向けます: http://cloudwatch-agent.amazon-cloudwatch.svc.cluster.local:4317 このウォークスルーでは CloudWatch エージェントを使用していますが、OTLP/HTTP をサポートする任意の OpenTelemetry 互換コレクターや SDK を使用して、CloudWatch OTLP エンドポイントに直接メトリクスを送信できます。 PromQL でアプリケーションメトリクスをクエリする アプリケーションをデプロイしたら、CloudWatch Query Studio を開くか、Amazon Managed Grafana ワークスペースで Explore に移動し、CloudWatch PromQL データソースを選択します。 以下のクエリは、Amazon Managed Grafana でデモアプリの p99 レイテンシーを、自動エンリッチされた @aws.region ラベルでグループ化して表示します。 histogram_quantile(0.99, sum by (le, aws_region) (rate(latency_time_bucket{resource_service_name="python-demo-app"}[5m])))` 図 7: Amazon Managed Grafana でのサンプルアプリケーションの P99 レイテンシー エンリッチメントが有効になっているため、すべてのアプリケーションメトリクスに AWS リソースコンテキストが自動的に付与されます。例えば、 cpu_usage をクエリすると、追加の計装なしで以下のラベルが返されます。 図 8: カスタム OTel 計装からのエンリッチされた全ラベルの表示 料金 OTLP 取り込み機能と PromQL クエリは、プレビュー期間中は追加料金なしで利用できます。現在の料金の詳細については、Amazon CloudWatch の 料金ページ をご覧ください。 このウォークスルーで使用した Amazon EKS と Amazon Managed Grafana のリソースは、標準料金で課金されます。継続的な課金を避けるため、ウォークスルー終了後は次のセクションのクリーンアップ手順に従ってください。 クリーンアップ サンプルアプリケーションを削除します。 kubectl delete -f demo-app.yaml EKS クラスターから Amazon CloudWatch Observability アドオンを削除します。 aws eks delete-addon \ --cluster-name \ --addon-name amazon-cloudwatch-observability Grafana ワークスペースから Prometheus データソースを削除します (Grafana コンソールにログインし、Data Sources に移動して、設定した CloudWatch PromQL データソースを削除します)。 Amazon Managed Grafana ワークスペースを削除します (このウォークスルー用に作成した場合のみ)。 aws grafana delete-workspace --workspace-id Amazon EKS クラスターを削除します (このウォークスルー用に作成した場合のみ)。 aws eks delete-cluster --name OTel エンリッチメントを無効にします (アカウントで不要になった場合)。 # Disable OTel enrichment aws cloudwatch stop-o-tel-enrichment # Disable telemetry enrichment aws observabilityadmin stop-telemetry-enrichment このウォークスルー用にアタッチした IAM ポリシーをデタッチします。 aws iam detach-role-policy \ --role-name \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy まとめ 本記事では、Amazon CloudWatch でのネイティブ OpenTelemetry メトリクス取り込みについて説明しました。エンリッチメントレイヤーの有効化、Amazon EKS への Container Insights のデプロイ、OpenTelemetry SDK でのカスタムアプリケーションメトリクスの送信、PromQL でのクエリを紹介しました。 このプレビュー機能により、メトリクスパイプラインを CloudWatch に統合できます。拡張されたラベル制限を持つ高カーディナリティメトリクス、PromQL クエリ、AWS リソースの自動エンリッチメントが連携し、インフラストラクチャメトリクス、コンテナメトリクス、アプリケーションメトリクスがすべて同じパイプラインを流れ、同じ AWS リソースコンテキストを持つようになります。別々のバックエンド、エクスポーター、AWS メトリクスを統合ビューに取り込むための追加 API 呼び出しは不要です。 OpenTelemetry を使ったアプリケーションレベルの計装の実践例については、以下のリソースをご覧ください。 AWS Observability Best Practices Guide:  OpenTelemetry SDK でアプリケーションを計装するパターン One Observability Workshop : AWS でのメトリクス、トレース、ログのハンズオンラボ AWS Observability Accelerator: テレメトリ収集とクエリを自動化する CDK パターンと Terraform モジュール プレビューは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で追加料金なしで利用できます。開始するには、アカウントでエンリッチメントレイヤーを有効にし、Amazon EKS クラスターに CloudWatch Observability アドオンをデプロイしてください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Rodrigue Koffi AWS のオブザーバビリティ担当スペシャリストソリューションアーキテクトです。オブザーバビリティ、分散システム、機械学習に情熱を持っています。DevOps とソフトウェア開発のバックグラウンドがあり、Go でのプログラミングを好みます。仕事以外では、水泳や家族との時間を楽しんでいます。LinkedIn: /grkoffi