1. 背景の紹介

現在、リアルタイムデータウェアハウスによって提供されるリアルタイム配信インジケーターの優先レベルはますます重要になってきており、別個のレポート表示やその他の機能、特に下流のルールエンジンに提供される関連データではなくなりました。配信業務の広告配信に直接影響を及ぼし、データが遅延したり、異常により直接的または間接的に資産の損失が発生する可能性があります。

配送管理プラットフォームのリンクパノラマの観点から見ると、大量のデータを迅速に処理し、有効な情報を迅速に分析できるリアルタイムデータウェアハウスは不可欠な部分であり、配送管理プラットフォームの手動制御もサポートします。リアルタイムのノード事故により、配信リンク全体が正常に動作しなくなる可能性があります。また、配信ルールエンジンは自動操作であり、サービスは 24 時間稼働する必要があるため、タイムリーかつ効果的なデータ品質の監視と警告が実現されます。ビジネスデータの異常変動や不適合を迅速に特定できるようにする必要があるため、カオスエンジニアリングの導入を計画しており、積極的に障害を注入することで、可能な限り事前にリスクを察知し、潜在的な問題を発見できるようにすることを期待しています。対象を絞った予防と強化を実行することで、障害発生時の重大な結果を回避し、リアルタイムデータウェアハウスの全体的なリスク対策機能を向上させることができます。

2. 演習範囲

カオス訓練の状況をより詳細に反映するために、リアルタイムデータウェアハウスのカオスは訓練の内容に応じて技術面とビジネス面の 2 つの部分に分けられます。

技術面のカオス：ミドルウェア、データベース、JVM、基本リソース、ネットワーク、サービスなどに基づいた共通例外を導入し、実際の業務で整理したコアアプリケーションシナリオに基づいたカオス訓練を実施し、脆弱性や緊急時対応能力をテストします。システムを改善し、チームを向上させます。安定性により処理能力が保証されます。

ビジネス面の混乱: 集中的な電子商取引活動を行っている企業の場合、さまざまな到着率、接触率、さらにマクロレベルの GMV、新規ユーザー数、ユーザーからの通話数などはすべてビジネスの健全性を反映する可能性があります。実際には、人生において安定した状態を説明するには、単一の指標ではなく、モデルを形成するための一連の指標が必要です。カオスエンジニアリングを使用するかどうかに関係なく、このような指標の健全性状態を特定することが重要であるため、データ収集、監視、および早期警告メカニズムの完全なセットをそれらの周りに確立する必要があります。、出血を特定し、修復し、止めます。

これまでデータウェアハウスのカオスプロジェクトは技術面だけでしたが、今回はデリバリーリンクの構築とプライマリリンク、バックアップリンクの完成を前提に、ビジネスサイドのカオスを複数回繰り返すことで、システム全体のデータ変更検知機能を向上させることができます。

3. 運動計画

仕事をうまくやりたいなら、まずツールを磨く必要があります。カオスドリルを実行する前に、準備作業を準備し、合理的なドリルSOP、計画、計画を策定し、ドリル環境、スクリプト、データ、ツールを分析する必要があります、シナリオ、爆発半径などの可能性評価を実施し、実現可能性が確認できた場合には、関係者と打ち合わせを行った上で実際の運用を行います。

この記事では主に、ビジネス側に基づいたリアルタイムデータウェアハウスのカオスドリルプロセスについて説明します。

1.ドリルSOPを書く

SOPとは、特定のイベントの作業手順や要件を洗練、定量化、最適化して標準的な作業プロセスを形成するための標準作業手順であり、ビジネス側の混乱、特にリアルタイムの倉庫データに関連する訓練については、次のようになります。これは初めてのことであり、業界内で適切な訓練ガイダンスの参考文献は見つかりませんでした。現在は模索段階にあります。プロジェクトを円滑に進め、その後の訓練作業をより標準化して効率化するために、全員が協力した上で、プロジェクトの初期段階で編集された SOP 訓練テンプレートは次のとおりです。

2. 訓練計画の調査

まず、リアルタイムデータウェアハウス配信リンクのコアインジケーター範囲を収集します。これに基づいて、一定期間にわたる履歴データを取得して分析し、各インジケーターに対応する健全な変動しきい値を見つけて、対応する DQC ルール監視を構成します。変動の場合健全性のしきい値内にない異常な指標については、タイムリーなアラームが数分以内 (15 分を予定) に発行され、迅速な調査と対応が提供されます。この目的を達成するために、演習の初期段階で、次のような一連のプログラムの調査と探索を実施しました。

「以下に提供するソリューションでは、例としてデバイスのアクティベーション数に基づいて指標データが分析されます。」

オプション 1: 日のディメンションに従って、最近の期間の同日の各時間におけるデバイスのアクティベーション数をその日の市場の割合として収集し、最小値と最大値を健全な変動しきい値として計算します。このインジケーター。
オプション 2: 日ディメンションに従って、同じ期間内の隣接する時間ポイントの変動データを収集してパターンを見つけます (毎日午前 9 時から午前 10 時までの変動データなど)。その後、データ統計を実行します。比較的安定した変動範囲を見つけるための一連の数学的分布方法。
オプション 3: 日ディメンションに従って、一定期間にわたる隣接する日の指数変動データを収集してパターンを見つけます。たとえば、昨日の午前 9 時から一昨日の午前 9 時までの変動データを調べて、データ統計を実行します。したがって、比較的安定した変動範囲を見つけることができれば幸いです。
オプション 4: 前の 3 つのオプションに基づいて、平日と週末で指標の変動が異なる可能性があるため、日次ディメンションの統計に基づいて、毎週月曜日などの週次ディメンションの前年比変動分布も調査しました。朝9時午前10時までの変動データをクリックし、比較的安定した変動範囲を見つけることを期待して、一連の数学的分布手法を通じてデータ統計を実行します。
オプション 5: 同様に、今週月曜日の午前 9 時から先週月曜日の午前 9 時までの変動データなど、週次次元での月ごとの変動分布も調査し、一連の数学的手法を通じてデータ統計を実行しました。比較的安定した変動幅を見つけることを
オプション 6: メインリンクとバックアップリンクに基づいて、ソースが同じである場合、リアルタイムデータウェアハウスによって計算された指標と、同じ期間の 2 つのリンクのシンクの結果データは一貫している必要があります。たとえば、プライマリリンクとバックアップリンク間の遅延が 10 分の場合、変動は 10% を超えず、平均差は 90% 以上の一貫性に達します。

プラン１からプラン５までを試行しましたが、各プランのシナリオデータは、最大値、最小値、平均値、パーセンタイル分布、分散、標準偏差などの統計データによって分析されており、かなり安定した変動を見つけることは困難です。また、指標の特定のしきい値範囲を定義することもできず、実際の訓練プロセス中に変動アラームしきい値を大きく設定しすぎると、実際の本番環境で業務データが異常に変動した場合に、アラームの検出が間に合わなくなります。小さすぎると、頻繁にアラームが発生し、健康に悪影響を及ぼします。その精度と有効性には疑問があるかもしれません。さらに、リアルタイム配信には数十のコア指標があります。各指標は、異なる健全性しきい値に対応します。コストは、収集と分析のレベルは非常に高いですが、運動の効果という観点から見ると、それほど明らかではありません。

総合的な評価に基づき、演習では主に計画 6 を採用し、合計 29 個のリアルタイム配信コア指標を収集し、一定時間 (15 分) 内でメインリンク指標とバックアップリンク指標の変動差が 10 を超えませんでした。 %。

3.穴あけ方法

赤青対決訓練では、チームを赤（守備）と青（攻撃）の２グループに分けます。

テスターは Blue Army を形成します。カオスドリル計画の策定、ターゲットシステムへのフォールトインジェクションの実行、およびドリルプロセスの詳細な記録を担当します。

リアルタイムデータウェアハウスは赤軍として開発されており、障害検出、緊急対応、トラブルシューティングを担当すると同時に、さまざまな障害シナリオの下でシステムの耐障害性、監視機能、人員対応機能、復旧機能、その他の信頼性機能も検証します。

4. 運動プロセス

練習全体の流れは大きく「準備段階」「攻防段階」「復習段階」の3段階に分かれます。

1.準備段階

計画の作成と検討が完了したら、リンク計画を確認します。
ブルーアーミーは、事前に策定された攻撃計画に従って、対応するテストデータとスクリプトを事前に準備しました。
赤軍は環境が事前に利用可能であることを確認し、事前に計画された攻撃計画に基づいて訓練前に監視、防御、緊急対応措置を計画どおりに実行します。

2. 攻撃と防御のステージ

青のチームは、事前に計画された攻撃計画に基づいて実際の攻撃動作をシミュレートし、合意された時間にドリルリンク (スタンバイリンク) を攻撃し、フォールトインジェクションを実行し、その後のレポートを容易にするために対応する操作手順を記録します。
青軍の攻撃後、赤チームはフェイシュ/電子メールアラートやその他の通知方法を通じて監視システムの動作にリアルタイムで注意を払い、異常なアラートが発生した場合は、できるだけ早くトラブルシューティングを行い、問題を特定する必要がありました。そして修理計画を評価します。
攻撃と防御の対立中、青軍は赤軍の防御手段に基づいて攻撃戦略を調整および改善し、システムの防御を突破して設定された目標を達成するために最善を尽くします。ブルーアーミーの攻撃技術と行動モデルを継続的に改善し、防御を強化します。

3. 見直し・改善段階

カオス訓練の後、赤チームと青チームのパフォーマンスを要約して評価し、分析し、システムのセキュリティと攻撃防止能力を評価します。
システムのセキュリティ戦略を改善するために、経験と教訓を要約し、成功した防御手段と失敗した攻撃方法を要約します。
評価結果と蓄積された経験に基づいて、システムの抜け穴や弱点を修復し、システムのリスク耐性を向上させるための改善計画を策定します。

5. 実際の攻防戦

この演習では合計 29 の指数変動ケースがあり、全体的な演習操作は同様です。

事例17「あるチャネルでリコール製品回収UVが正時変動する」を例に、具体的なドリル作業手順は以下の通りです。

1. データの準備

バックグラウンドデータベースを通じて、本番のプライマリ (バックアップ) リンクを引き出し、特定のチャネル (たとえばmedia_id= '2') で特定の時間 (たとえばhour= 10) で、製品コレクションに対応する全体の統計値 N を呼び出します。紫外線。

--渠道小时整点维度下，商品收藏uv汇总数据
select
  `指标名称`,
  `日期`,
  '2' as `指标ID`,
  `小时段`,
  sum(`指标值`)
from table_a
where
  date = date_format(now(), '%Y%m%d')
  and `指标名称` in ( '商品收藏uv' )
  and `小时段` = 10
  AND `指标id` = '2'
GROUP BY
  `指标名称`,
  `日期`,
  `小时段`
order by
  指标名称;

バックアップリンクを引き出し、特定のチャネル ( media_id= '2' など) で、特定の時間 (= 10 などhour) の特定の詳細データを、製品コレクション uv の対応する値を n として記録します。 n を n+ に変更すると、その後 0.1N がバックアップリンクに注入され、その結果、アクティブリンクとバックアップリンクの間に 10% の変動差が生じます。

-- 明细数据
select
  t.指标名称,t.账户id,t.计划ID,t.设备类型,t.指标值
from
  (
    select
      `账户id`,
      `计划id`,
      `指标名称`,
      `指标值`,
      `设备类型` ,
      row_number() over (partition by 指标名称 order by 指标值 desc ) as rn
    from  table_a
    where
      date = date_format(now(), '%Y%m%d')
      and `指标名称` in ('商品收藏uv')
      and `设备类型` = '召回'
      and `小时段` = 10
      AND `指标id` = '2'
  ) t
where
  t.rn = 1
ORDER BY 指标名称;

ソート後、注入する必要のあるデータが取得されます。黄色の部分を参照してください。

2. フォールト挿入の確率

odps に注入する必要があるデータをインポートします。

インポートする前に、ドリルデータをインポートするためにデータワークスペースに新しいテストテーブル du_qa_dw_dev.hundun_case を作成する必要があります。

-- drop table if  EXISTS du_qa_dw_dev.hundun_case;
CREATE TABLE IF NOT EXISTS hundun_case
(
    message  STRING COMMENT '消息内容'
)
COMMENT '混沌演练'
;

du_qa_dw_dev.hundun_case テーブルに数値を入力します。

データのインポートが成功したことを確認します。

3.odps と kafka の同期

flink 同期スクリプトを実行して、odsp du_qa_dw_dev.hundun_case テーブルデータを対応する Kafka トピックと同期します。

フリンクタスクスクリプト:

--SQL
--********************************************************************--
--odps同步到kakfa脚本，用于实时数仓混沌演练异常注入使用
--********************************************************************--
-- 基本函数
CREATE FUNCTION JsonParseField AS 'com.alibaba.blink.udx.log.JsonParseField';
CREATE FUNCTION jsonStringUdf AS 'com.alibaba.blink.udx.udf.JsonStringUdfV2';
---同步账号表
CREATE TABLE `source` (
message                        VARCHAR  
) WITH (
   'connector' = 'du-odps',
  'endPoint' = '***',
  'project' = '***',
  'tableName' = 'hundun_case_01',
  'accessId' = '*******',
  'accessKey' = '*******'

);

CREATE TABLE `kafka_sink` (
  `messageKey`  VARBINARY,
  `message`  VARBINARY,
  PRIMARY KEY (`messageKey`) NOT ENFORCED
) WITH (
  'connector' = 'du-kafka',
  'topic' = '********',
   'properties.bootstrap.servers' = '*******',
  'properties.compression.type' = 'gzip',
  'properties.batch.size' = '40960',
  'properties.linger.ms' = '1000',
  'key.format' = 'raw',
  'value.format' = 'raw',
  'value.fields-include' = 'EXCEPT_KEY'
);

INSERT INTO kafka_sink
SELECT
cast(MD5(message) as VARBINARY),
cast(message as VARBINARY)
FROM source
;

4.kafkaプラットフォームクエリデータ

flink 同期タスクを実行した後、対応するデータが正常に同期されたかどうかをバックグラウンドでクエリできます。

5. 例外挿入の通知

例外注入が完了すると、Feishu グループ通知を通じて赤軍に通知することができ、警報を受信した場合は、できるだけ早くグループに通知する必要があります。

ブルーアーミー: ブルーアーミーはデータの準備を完了しました。演習前に環境に問題がなく、ルールの設定が完了していることを確認してください。また、演習の時間計画は下流の関係者にタイムリーに通知する必要があります。

ブルース: 注入が完了しました。

6. アラームトリガー通知

赤軍は演習前に、監視プラットフォームを通じて事前に防衛ルールを設定できる。
異常な噴射後、それが期待どおりであり、異常な指標の変動が 15 分以内に見つかった場合、赤軍は時間内に訓練グループに同期しなければなりません。

中リスク** デュアルリンクのアクティブおよびスタンバイの一貫したモニタリング

サービス名：**** 環境：****** アラーム時刻：****** トリガー条件：**デュアルリンク比較異常変動が10分間継続アラーム内容：指標：prd_collect_uvマスタ比較低下： [-10%] メイン:1066 バックアップ:956

事業ドメイン：リアルタイムデータウェアハウス

申請担当者：***

期待を満たしておらず、15 分以内に異常なインジケーターの変動が見つからなかった場合、赤軍は直ちに問題を特定して追跡調査し、修理後は後続の訓練と連絡を取り、修理結果を確認する必要があります。

赤軍: 15 分以内に警報は受信されず、測位中

赤軍「原因が判明しました。攻撃の影響で警報データの送信が間に合わず、修復中です。」

赤軍: 修復しました。赤軍の再攻撃をお願いします。

7. ドリル加工の記録

次のように、時点、実行者、操作などを含む、演習中のすべての操作を収集、要約、記録します。

6. 演習の概要

7. 今後の見通し

カオス訓練では、リアルタイムデータウェアハウスビジネス側を 0 から 1 まで訓練し、一連の探索と実践を行った後、メインリンクとバックアップリンクの比較方法を通じて、訓練中に異常な変動指標を迅速に特定し、感知することができます。結果、良好な結果が得られましたが、次のような制限もあります。

訓練中に手動で挿入された異常なデータは、すぐに消去できない場合、バックアップリンクの使用に影響を与える可能性があります。
バックアップリンクのないリアルタイムの指標変動の場合、健全な指標変動範囲を見つけるために、より洗練された実現可能な計画を策定する必要があります。

これらについては、チームでさらなる検討と解決が必要であると同時に、演習の過程において、演習事例の蓄積・充実や演習ライブラリの充実を継続し、ツール（プラットフォーム）の導入や演習支援の確立などのフォローアップを計画しています。カオス訓練をより自動化、標準化、正規化し、リアルタイムデータウェアハウスの全体的なデータの安定性を向上させます。※文／袁暁

この記事は Dewu Technology のオリジナルです。さらに興味深い記事については、Dewu Technology 公式 Web サイトを参照してください。

Dewu Technology の許可なく転載することは固く禁じられています。さもなければ、法律に従って法的責任が追及されます。

リアルタイムデータウェアハウスのカオスドリル演習

1. 背景の紹介

2. 演習範囲

3. 運動計画

1.ドリルSOPを書く

2. 訓練計画の調査

3.穴あけ方法

4. 運動プロセス

1.準備段階

2. 攻撃と防御のステージ

3. 見直し・改善段階

5. 実際の攻防戦

1. データの準備

2. フォールト挿入の確率

3.odps と kafka の同期

4.kafkaプラットフォームクエリデータ

5. 例外挿入の通知

6. アラームトリガー通知

7. ドリル加工の記録

6. 演習の概要

7. 今後の見通し

おすすめ

リアルタイム データ ウェアハウスのカオス ドリル演習

1. 背景の紹介

2. 演習範囲

3. 運動計画

1.ドリルSOPを書く

2. 訓練計画の調査

3.穴あけ方法

4. 運動プロセス

1.準備段階

2. 攻撃と防御のステージ

3. 見直し・改善段階

5. 実際の攻防戦

1. データの準備

2. フォールト挿入の確率

3.odps と kafka の同期

4.kafkaプラットフォームクエリデータ

5. 例外挿入の通知

6. アラームトリガー通知

7. ドリル加工の記録

6. 演習の概要

7. 今後の見通し

おすすめ

リアルタイムデータウェアハウスのカオスドリル演習