Azureコストの削減方法を見つける為に日々Azureポータルとにらめっこしているイオンスマートテクノロジー株式会社(AST)の岩崎です。
以下のアドベントカレンダーの21日目の記事です。
今回はAzureのApplicationGateway(以降Appgw)やFireWallのログをNewRelicに転送した時の課題と解決のお話となります。
最終的にはNewRelicさんの手厚いサポートと対応の早さで解決しています。
背景
- 弊社はオブザーバビリティのツールとしてNewRelicを使用している
- LogAnalyticsのコストがiAEONのユーザー増加(アクセス数増）に伴い日々増加傾向にある
- 不要なログは停止して、これ以上ログを削減する方法がなくなってきた
解決策
- ログ単価の安いNewRelicに転送する事でコスト削減しつつ、メトリックの閲覧やログ検索がNewRelicの画面内で完結して使用しやすくなるので一石二鳥ではないかと言う事でNewRelicにログを転送する事にしました
課題
- 同じ時間で絞り、Azureのログ件数とNewRelicのログ件数を比較したところ大きな件数の差異があり、ログ欠落が発生
- NewRerlicへ転送される時間が遅い(タイムラグがある)
課題１ ログ件数が一致しない。欠落が発生か！？
ログが欠落していないか確認する為にAzureLogAnalyticsとNewRelicのログ件数を同じ時間で30秒間の件数を確認すると、数十件の差があり欠落しているのではないかと調査を実施していきます。(非常に焦る)
AppgwのログでAzureとNewRelicの時間の項目に着目するとそれぞれ以下の項目があります。
Azure
| 項目 | 値 |
|---|---|
| TimeGenerated [UTC] | 2024-09-30T07:56:16Z |
| timeStamp_t [UTC] | 2024-09-30T07:56:16Z |
NewRelic
| 項目 | 値 |
|---|---|
| Time | 2024-09-30T07:56:16+00:00 |
| Time Stamp | 2024-09-30T07:56:16+00:00 |
| Timestamp | 2024/9/30 9:00:01 |
同じ時間が入っている項目は正しく連携されているのがわかりますが、NewRelicの項目のTimestampの時間2024/9/30 9:00:01がAzureにはない時間が格納されています。
ドキュメント ログ本文の時刻情報をイベントのタイムスタンプに適用する方法より
New Relic が該当ログイベントを受信した時刻に基づいたタイムスタンプ属性が暗黙的に自動付与されます。
AzureからNewRelicに転送する時にTimestampを使用していない時は、NewRelicが受信した時間が格納されるようです。
んっ、7:56:16のログデータがNewRelicに取り込まれたのが9:00:01で約１時間４分のタイムラグがあります。これが２つ目の課題となります。
New Relic では、ログイベントをはじめとした各種テレメトリーデータにそれぞれに固有のタイムスタンプ (timestamp) 属性を保持しています。 このタイムスタンプ属性は、例えば NRQL クエリで SINCE-UNTIL 句を使用して、特定の期間内の情報を集計して可視化する場合や、アラート条件の評価を行う際にも参照されています。
ドキュメントからTimestampは時間を指定する時に参照される項目のようです。
AzureとNewRelicで同じ時間帯の件数を比較していたと思ったら、NewRelicは取り込まれた時間の件数と比較していました。これで件数に差異がある理由がわかりました。
NewRelicが取り込まれた時間ではなくAzureでログが発生した時間で検索したいと思うので、AzureでTimestampにログが作成された時間を格納する方法をNewRelicさんに教えていただき、無事解決するk事ができました。
その後、この改修はNewRelicさんの中で正式版としてリリースされたようです。
保険として滞留が発生してもログが削除されないようにメッセージの保持期間を72時間に設定しています。
設定方法を直ぐ教えて頂き、本当に助かりました。感謝！
課題2 NewRerlicへ転送される時間が遅い(タイムラグがある)
ログの転送はNewRelicから提供されているAPMテンプレートを使用して実現しています。
推奨されているEventHubベーステンプレート使用しました。
Azureからのログやアクティビティログの転送
サンプルの構成
最初は実際のログ量からサイジングせず、構築しました。これがいけなかった。
EventHubの性能にに関係しそうな項目は以下となります。
Event Hubs名前空間
| 項目 | 値 |
|---|---|
| 価格レベル | Standard |
| スループットユニット | 20 ※自動インフレを有効にすると自動的に変化する |
| 自動インフレ | 有効 最大40 |
1つのスループットユニットにより次の事が可能
- イングレス: 1 秒あたり最大で 1 MB または 1,000 イベント (どちらか先に到達した方)
- エグレス: 1 秒あたり最大で 2 MB または 4,096 イベント
Event Hubs
| 項目 | 値 |
|---|---|
| パーティション数 | 1 |
Azure Function
| 項目 | 値 |
|---|---|
| AppServicePlanの種類 | 従量課金 |
タイムラグがあるので調査していくとEvent Hubs名前空間のメトリックのメッセージ、スループットの
IncomingとOutgoingに差異がある事がわかります。
Incomingが多くて、Outgoingが少ない事からEventHubがAppgwから取り込んだログをAzure Functionへ送信するのが遅れている事がわかります。
EvnetHubで滞留しているので同時に処理する性能が低いと思い、Event HUbsのパーティション数を増やす事にします。
Event Hubs名前空間の価格レベルがStandardの場合、作成後はパーティション数を変更できない為、再度Event Hubs名前空間を作成し、今後のログ量増加を見込み最大のパーティション数にしています。 パーティション数が多くても価格はかわらない。
Event Hubs
| 項目 | 値 |
|---|---|
| パーティション数 | 1→32 |
IncomingとOutgoingの差異がほぼなくなった事が確認でき、滞留せずに処理されている事が推測できます。
実はパーティション数の変更の前にAzure Functionの性能が足りないと思い、Planの種類を従量課金からFunction Premiumに変更したが、改善されませんでした。
1分以内にはNewRelicに取り込まれているのでほぼタイムラグがないと言えると思います。
まとめ
- EvnetHubsのメトリックをチェックし、滞留が発生していないか確認する
- ログ量からEvnetHubsのサイジングは大事
イオングループで、一緒に働きませんか？
イオングループでは、エンジニアを積極採用中です。少しでもご興味もった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。 皆さまとお話できるのを楽しみにしています！
Discussion