Azureコストの削減方法を見つける為に日々Azureポータルとにらめっこしているイオンスマートテクノロジー株式会社(AST)の岩崎です。
数か月前に検証した記事となりますので、最新の画面や仕様と違う可能性があります。
削減対象を見つける
コスト管理画面でサービス毎の比率を円グラフで表示される等、どこから手を付けるにはうってつけの画面です。
今回はAzureMonitorのコスト削減に取り組むために、試してみたのがMicrosoft Fabricです。
AzureMonitorで一番高いコストがLogAnalyticsに保存しているログ量に対するコストです。
このログ量を減らす事が良い方法なのですが、もうこれ以上減らせないでもコストを削減しなくてはいけない、考えた方法としてログの保管先を変更して、保管料金を下げる方法でした。
Azure FabricではKQLDBに保存する事ができる為、LogAnalyticsのKQLと同じなので新たにクエリ言語を学習する必要はありません。
削減額
コストの計算。
信頼されたワークスペースを設定できるF64 SKU以上なのでF64で計算
1日のログが500GBの場合
| Microsoft Fabric容量 | ||
|---|---|---|
| F64 | 従量課金 ¥1,511,464.419/月 | Reservation ¥898,859.575/月(～41% の節約) |
| OneLake Storage |
|---|
| OneLake ストレージ/月 GB あたりの¥3.8514 |
| Azure Monitor |
|---|
| Analytics ログ 500 GB/日 ¥193,223.49/日 ¥386.45/GB |
上記の価格表を基に1日500GBのログ量の1か月(31日)の場合
Microsoft Fabric＋OneLake Storage＝¥1,511,464.419/月＋¥59,696/月＝¥1,571,161/月
Azure Monitor ＝ ¥5,989,928/月
※計算間違っていたらすみません
※今回選択した構成にはEventHubのコストが発生しますが、削減額を覆すほどインパクトのある金額にならないと思うので除外。
構成
保存するログはApplicationGatewayのAccess Logログです。
簡単ですが構成はこうなります
四苦八苦したJSONファイルの階層構造
このログをそのままKQLDBに保存すると、階層構造になっており、カラムの指定が少し大変です。
階層構造はこの画像のように「properties」配下にもう一階層あり、「clientIP」等を列として表示する方法が見つけられませんでした。
私は「properties」配下のカラムも「rulename」と同じ階層にして、表示や検索したかったのでKQLDBに保存する時にフラット化しました。
実装方法
FabricのDataFactoreyの画面で「新規」ー「Eventstram」を選択
名前を入力し「作成」
「Add external source」クリック
「Azure Event Hubs」をクリック
「Cloud connection」は 「新規作成」クリック
Azureポータルから Event Hubsの名前空間とEvent Hubの名前を入力して、「Create」をクリック
参考：Event Hubの画面
※ApplicationGatewayの診断設定で「イベント ハブへのストリーム」をチェックし、対象のEvent Hubを指定します
コンシューマグループはAzureポータル画面のEvent Hubの「エンティティ」エリアの「コンシューマグループ」の値を入れる。プルダウンで表示される
「Next」→「Add」クリック
コンシューマグループはAzureポータル画面のEvent Hubの「エンティティ」エリアの「コンシューマグループ」の値を入れる。プルダウンで表示される
「Next」→「Add」クリック
「Expand」をクリック
Expand・・・配列の展開変換は、配列内の値ごとに新しい行を作成する場合に使用します。
「鉛筆マーク」 クリック
値を入力して 「Save」
| 項目 | 値 |
|---|---|
| Operation name | 例 Expand1 ※適当な名前、変更可 |
| Array | records ※展開したいfields名 |
| How | should we treat missing/empty arrays? Don’t create row for missing/empty array |
 |
出力先がないとエラーとなるが無視して、「＋」をクリック、「Managed fields」クリック
「鉛筆マーク」 クリック
「＋Add fields」クリック 、「Imported Schema」を展開、取り込みたいfieldsを選択、「properties」を展開、取り込みたいfieldsを選択し、「Add」クリック、「Save」クリック
※例はApplicationGatewayのレコード。他のリソースは別のfields名になっていると思う
| プロパティ | 説明 |
|---|---|
| EventProcessedUtcTime | Stream Analytics でイベントを処理する日時。 |
| EventEnqueuedUtcTime | Event Hubs でイベントを受信する日時。 |
| PartitionId | 入力アダプターの 0 から始まるパーティション ID。 |
出力先がないとエラーとなるが無視して、「＋」をクリック、「KQLデータベース」クリック
「鉛筆マーク」クリック
項目に値を設定して、「Save」
| 項目 | 値 |
|---|---|
| Data ingestion mode | Event processing before ingestion |
| Destination name | KQLDB ※EventStream上の名前。変更可 |
| ワークスペース | Fabricのワークスペース名を選択 |
| KQL データベース | Eventhouseの名前を選択 |
| Destination table | 新規作成 クリック、適当な名前。Azureのリソースの名前がわかりやすいかも Eventhouse上のテーブル名 |
| Input data format | Json |
エラーが表示されなければ、画面上部の「Publish」をクリック
完了。
ログはリアルタイムでKQLDBに格納される
KQLDBを検索する
まとめ
ログの保管料を下げる方法としては有効だと思います。
でも、LogAnaltyicsの画面で慣れてしまっていると、Fabricの画面だと見づらい部分があります。
ここは実際に使ってみて、うーん、と悩むのが良いと思います。
コストをとるか画面の使い勝手をとるか。
コストとの闘いはまだまだ続く・・・
参考ページ
以下手順を IoT Hub から Event Hubs に読み替えて参照
イオングループで、一緒に働きませんか？
イオングループでは、エンジニアを積極採用中です。少しでもご興味もった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています！
Discussion