Azure コンテナーアプリの可視化戦略(後編)

4 minute read

<前編は、Observability とは何かについて説明しましたが、後編は、サンプルアプリケーションを具体例にして説明します。>

Daprを使用したサンプルアプリケーション概要

アプリケーションはシンプルで、名前と在庫量のプロパティを持つ商品のコレクションを取得します。しかし、裏では、意図的に分散システムが非同期に通信するように複雑にしました。技術的には、これはすべて同期通信であり、自分のダミーのイベントバスを構築します。

3つの主要なサービスを持っています：

Product Service：すべての商品とそれに関連する在庫を返す責任があります。
Inventory Service：Product Serviceが作成した商品の在庫を追跡し、更新する責任があります。
Events Service：イベントバスとして機能する責任があります。
サービスはイベントを通じて互いに通信します。特定の商品の在庫が更新されると、イベントがInventory Serviceから発生し、Events Serviceに送られ、Events ServiceはそれをProducts Serviceにプッシュして、正確な在庫量を表示します。

サービス間呼び出しのためにDaprを使用しています。再び、バズワードを外すと、Daprはサービス間通信、ネットワークリトライ、エラーハンドリング、ステート管理などの一般的なロジックを、あなたのメインのアプリケーションコンテナと並行して動作するコンテナ（したがって、サイドカーコンテナと呼ばれます）にオフロードします。一般的な機能がサイドカーによって処理されることで、アプリケーションはメンテナンスや更新が容易になり、これらの機能に対する変更は多くの場合、アプリケーションコードを変更せずに行うことができます。あなたのコードでは、ビジネスロジックに焦点を当てることができます。

サンプルアプリケーションのセットアップ

リポジトリはこちらにあります：AbdullahAbuHassann/ACA-Observability: Azure Container Apps Observability with Open Telemetry (github…

前提条件

Azure Log Analytics Workspace、Azure Application Insights Resource、Azure Container Registryリソースを作成します。Application Insightsリソースを作成するときは、作成したLog Analyticsリソースと同じものを選択してください。
Azure Application Insightsの接続文字列をポータルの概要ページでメモしてください。
リソースグループを作成し、その名前をメモしてください。
ローカルマシンにDockerがインストールされていることを確認してください。

セットアップ手順

Azureにログインします（Azure CLIがインストールされていることを確認してください）
```
az login  
```
Azure Container Registryに認証します（ポータルから取得できる認証情報が必要な場合があります）
```
az acr login --name myregistry  
```

リポジトリをローカルにクローンします

git clone https://github.com/AbdullahAbuHassann/ACA-Observability.git

Products Serviceを設定します

/productsに移動します。config.tsファイルの接続文字列プロパティを、前提条件セクションでメモした接続文字列に置き換えます。
```
const options: AzureMonitorOpenTelemetryOptions = {  
    azureMonitorExporterOptions: {  
      connectionString: "REPLACE_WITH_CONNECTION_STRING",  
    }  
  };  
```
次に、提供されたDockerfileからDockerコンテナをビルドします。以下のACRNameを適切に置き換えてください（/products内にいることを確認してください）。
```
docker build -t <ACRName>.azurecr.io/products:v1 .  
```
コンテナをAzureにプッシュします
```
docker push <ACRName>.azurecr.io/products:v1 .  
```
ステップ4を/inventoryと/eventsで繰り返します（異なるイメージ名を使用することを確認してください）

Bicepテンプレートのセットアップ

/infra/appinsights.bicepに移動し、appInsightsNameとworkspaceResourceIdを埋めます

param location string = 'westeurope' // 必要に応じて場所を変更できます  
param appInsightsName string = '<App Insights Resource Name>' // Application Insightsリソースの一意の名前を提供します  
param workspaceResourceId string = '<Resource ID of the Log Analytics workspace>' // Log AnalyticsワークスペースのリソースIDを提供します  
  
resource appInsights 'Microsoft.Insights/components@2020-02-02-preview' = {  
  name: appInsightsName  
  location: location  
  kind: 'web'  
  properties: {  
    Application_Type: 'web'  
    WorkspaceResourceId: workspaceResourceId  
  }  
}  

/infra/aca.bicepに移動し、environmentName、acrName、Log Analytics Workspace Id & Key、Image names、ユーザーマネージドアイデンティティのスコープのRG Name、daprAIConnectionStringを調整します

param environmentName string = '<ACA Environment Name>' // Azure Container Apps環境の一意の名前を提供します  
param acrName string = '<ACR Name>' // Azure Container Registryの名前を提供します  
  
// 管理環境が同じリソースグループとサブスクリプションにあると仮定  
var environmentId = resourceId('Microsoft.App/managedEnvironments', environmentName)  
param location string = 'westeurope' // 必要に応じて変更します  
param logAnalyticsCustomerId string = '<Workspace ID>'// Log Analytics WorkspaceのCustomer IDを提供します  
param logAnalyticsSharedKey string = '<Workspace Key>' // Log Analytics WorkspaceのShared Keyを提供します  
param inventoryImage string = '<Image Name>' // ACR名のプレフィックスなしでイメージ名を提供します。例：'inventory:v1'  
param eventsImage string = '<Image Name>'  // ACR名のプレフィックスなしでイメージ名を提供します。例：'events:v1'  
param productsImage string = '<Image Name>' // ACR名のプレフィックスなしでイメージ名を提供します。例：'products:v1'  
  
// AcrPull権限を割り当てます  
module roleAssignment 'roleassignment.bicep' = {  
  name: 'container-registry-role-assignment'  
  scope: resourceGroup('<RG Name>') //値を置き換えます  
  params: {  
    roleId: '7f951dda-4ed3-4680-a7ca-43fe172d538d' // AcrPull  
    principalId: userManagedIdentity.properties.principalId  
    registryName: acrName  
  }  
}  
// Azure Container Apps環境  
resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2023-05-01' = {  
  name: environmentName  
  location: location  
  properties: {  
    appLogsConfiguration: {  
      destination: 'log-analytics'  
      logAnalyticsConfiguration: {  
        customerId: logAnalyticsCustomerId  
        sharedKey: logAnalyticsSharedKey  
      }  
    }  
    daprAIConnectionString: '<App Insights Connection String>'  
  }  
}  

Bicepテンプレートをデプロイします

/infraにいることを確認し、次のコマンドを実行します（前に作成したリソースグループの名前に置き換えてください）：
```
az deployment group create --resource-group <RG_Name> --template-file aca.bicep  
```
後で整理するために、リソースグループを削除します
```
az group delete -n <RG_Name> --yes  
```
アプリケーションをテストします

これで、それぞれがユニークなURLを持つ3つのAzure Container Appsが稼働しているはずです。

Postmanまたは任意のHTTP/sクライアントを使用して、以下のリクエストをシミュレートします：
1. 商品リストの取得：GET /
2. 特定の商品の在庫の更新（この例ではID 1）：POST /1/inventory {“amount”: “2”}

分析

これで、Azure Application Insights（内部的にはAzure Log Analyticsを利用）で収集したログ、メトリクス、トレースを表示することができるようになりました。以下に、どのように活用できるかの概要を示します。

Azure Application Map：アプリケーションからトレースを収集している理由を思い出してください。それは、Azure Application MapのようなサービスがトレースIDを見て、リクエストの全体の旅をマッピングできるからです。私たちは容易にボトルネックがどこにあるかを特定することができます。
障害の調査：これは、収集したログ、メトリクス、トレースを活用し、障害（400および500のステータスコード）と例外に焦点を当てたビューです。
パフォーマンスの調査：パフォーマンスに焦点を当てたビューで、リクエストを期間別にグループ化します。
収集したテレメトリのクエリ：
可用性テストの設定：
アラートの設定：

Azure Container Appsでのルート原因の特定の実例

準備がしました。これから先、問題に直面していると仮定した場合、実際にはどのようにしてルート原因を見つけるのでしょうか？

以下に簡単なガイドを示します：

アラートが発生：まず最初に、アラートを正しく設定しておくことが重要です。どのような状況がアラートを引き起こすべきかを明確に定義しておいてください。
ダッシュボード：アラートが発生したとき、それはただの出発点です。例えば、それがレスポンス時間が遅いというものだとしましょう。ユーザーは遅延を経験していますが、複雑なシステムでは、どこからトラブルシューティングを始めるべきでしょうか？ここで役立つのが、よく設計されたダッシュボードです。顧客体験に焦点を当てたダッシュボードから始めます。これは、彼らがあなたのサービスとどのように相互作用し、何がうまくいき、何がうまくいかないかについてです。これは、ビジネスチームと共有するようなダッシュボードです。次に、UIやフロントエンドのようなシステムのエントリーポイントに、そしてバックエンドにまで掘り下げます。Azure MonitorはAzure Workbooksを通じて事前に構築されたダッシュボードを提供します：Azure Workbooks overview
Application Map：ダッシュボードからアラートについて得た洞察を元に、収集したトレースを活用する時が来ました。Application Mapは、サービスがどのように互いに通信しているかを示し、問題が正確にどこにあるかを特定します。
特定のログとメトリクス：問題のあるコンポーネントやサービスを特定したら、その特定のログとメトリクスに焦点を当て、一般的なダッシュボードを超えて進みます。ログはメトリクスよりも深く掘り下げることを提供し、より多くの情報のレイヤー（次元と呼ばれる）を提供します。それらは私たちがより正確な分析のためにデータをクエリで解剖することを可能にします。
最後に

まとめると、堅牢なObservability戦略を持つことが重要です。このアプローチは、エンジニアに必要なインサイトを提供し、顧客の問題を迅速に対処することができ、これにより顧客はより幸せになります。
Observabilityは複雑なものである必要はありません。プロセスを簡素化するツールが利用可能ですが、キーとなるのは適切な戦略を持つことです。このブログ記事が、Azure Container AppsのObservability戦略を開発するための堅固な基盤を提供してくれたことを願っています。

Twitter Facebook LinkedIn

K.I

Azure コンテナーアプリの可視化戦略(後編)

Daprを使用したサンプルアプリケーション概要

サンプルアプリケーションのセットアップ

前提条件

セットアップ手順

分析

Azure Container Appsでのルート原因の特定の実例

最後に

You May Also Enjoy

開発者向けブログサマリー - 2025/07/21

開発者向けブログサマリー - 2025/07/14

開発者向けブログサマリー - 2025/07/07

開発者向けブログサマリー - 2025/04/30