はじめに

近年はコンテナでアプリケーションを稼働させるケースが増えています。本番環境でコンテナアプリケーションを信頼性高く稼働させるためにはオーケストレーションサービスが欠かせません(なぜコンテナオーケストレーションサービスが必要なのかについてはこちらを参照してください)。

本Postでは、最もよく利用されているコンテナオーケストレーションサービスであるAmazon ECSAmazon EKS上でアプリケーションを稼働させている方を対象に、New RelicのInfrastructure、APMの導入手順を整理していきます。

なお、オブザーバビリティ実現のためにはBrowserやMobile、Syntheticsなどのデータも収集することになりますが、セットアップという観点では直接コンテナオーケストレーションかどうかで影響受けないので、本Postでは割愛します。

構成パターン

Amazon ECSもAmazon EKSも、共にコントロールプレーンと呼ばれるコンポーネントとデータプレーンと呼ばれるコンポーネントに別れます。さらに、AWSではデータプレーンはEC2とFargateという2種類のタイプに別れます。全部で4パターンになります。

  1. Amazon ECS / EC2パターン
  2. Amazon ECS / Fargateパターン
  3. Amazon EKS / EC2パターン
  4. Amazon EKS / Fargateパターン

それぞれの環境で微妙に実現手順が異なるため、ご自身の環境ではどこにどのようにセットアップしたら良いか迷うことがあると思います。そんな時は本Postを参考にしてみてください。
 

1. Amazon ECS / EC2の場合

ECS for EC2環境へのNew Relic導入方法は下記3ステップの通りとなります。

  1. AWS Cloud Integrationをセットアップし、AWSの各種リソースのCloudWatchのメトリクス情報を連携します
  2. ECS Integrationをセットアップし、Task内のコンテナレベルのメトリクスを収集します。データプレーンがEC2の場合はデーモン構成でセットアップします。セットアップ詳細はこちらのブログもご参照してください。
  3. APMをセットアップし、アプリケーションのパフォーマンス情報を収集します。APMエージェントを設定するだけで分散トレーシングやLogs in Contextが自動的に有効になります。

2. Amazon ECS / Fargateの場合

ECS for Fargate環境へのNew Relic導入方法は下記3ステップの通りとなります。

  1. AWS Cloud Integrationをセットアップし、AWSの各種リソースのCloudWatchのメトリクス情報を連携します
  2. ECS Integrationをセットアップし、Task内のコンテナレベルのメトリクスを収集します。データプレーンがFargateの場合はサイドカー構成でセットアップします。セットアップ詳細はこちらのブログもご参照してください。
  3. APMをセットアップし、アプリケーションのパフォーマンス情報を収集します。APMエージェントを設定するだけで分散トレーシングやLogs in Contextが自動的に有効になります。

3. Amazon EKS / EC2 の場合

Amazon EKS for EC2環境へのNew Relic導入方法は下記3ステップの通りとなります。

  1. AWS Cloud Integrationをセットアップし、AWSの各種リソースのCloudWatchのメトリクス情報を連携します
  2. Kubernetes Integrationをセットアップし、Kubernetesクラスターの各種情報(クラスター、ノード、Podなどの情報)を収集します
  3. APMをセットアップし、アプリケーションのパフォーマンス情報を収集します。APMエージェントを設定するだけで分散トレーシングやLogs in Contextが自動的に有効になります。

ログの転送はKubernetes integration側で送る場合とAPMから直接送るケースがあります。主に以下の目的で使い分けます。

  • アプリケーションログのみを転送対象とする場合:APMから直接転送
  • APMからの直接転送の非対応言語 or アプリケーションログ以外のPodのログも転送する場合:k8s integration経由での転送

4. Amazon EKS / Fargateの場合

Amazon EKS for Fargate環境へのNew Relic導入方法は下記3ステップの通りとなります。

  1. AWS Cloud Integrationをセットアップし、AWSの各種リソースのCloudWatchのメトリクス情報を連携します
  2. Fargate向けのKubernetes Integration をセットアップし、Kubernetesクラスターの各種情報(クラスター、Podなどの情報)を収集します
  3. APMをセットアップし、アプリケーションのパフォーマンス情報を収集します。APMエージェントを設定するだけで分散トレーシングやLogs in Contextが自動的に有効になります。

ログの転送はk8s integration側で送る場合とAPMから直接送るケースがあります。主に以下の目的で使い分けます。

  • アプリケーションログのみを転送対象とする場合:APMから直接転送
  • APMからの直接転送の非対応言語 or アプリケーションログ以外のPodのログも転送する場合:fluentbitコンテナサイドカー経由での転送

おわりに

いかがでしたか?一度考え方がわかれば、環境に合わせたセットアップを行うだけなのですが、何から手をつけて良いか分からない状態だとこの差を意識することは難しいのもまた事実です。本Postが皆様のコンテナアプリケーションのオブザーバビリティ実現の第一歩として参考になれば幸いです。