「データ分析基盤の障害対応事例LT祭り」Data Engineering Study #4イベントレポート

第1回から第3回までは、「DWH・BIツールの選定、データ収集基盤の勉強会、作った分析基盤を組織に浸透させていく方法」というテーマについて扱ってきました。

過去のイベントレポートはこちら

今回第4回はスピンオフとして「データ分析基盤の障害対応事例LT祭り」と題し、6名の方々から障害対応を行った際のリアルな声をご紹介させていただきました。

当日の発表内容はこちらのYouTubeからご覧ください。

正確な意思決定を阻む問題・障害との向き合い方

株式会社はてな Mackerelチーム Customer Reliability Engineerに所属されている、吉田 康久 氏（@syou6162）。RDBMSでは担保できていた制約がデータ基盤に入れられなかったために集計の差異が発生した事例と、データマートが広く使われている中で目的にそぐわないデータをもとに意思決定されてしまった事例についてお話しいただきました。

RDBMSでは担保できていた制約がデータ基盤に入れられなかったために集計の差異が発生した事例

吉田康久氏：「MySQLやPostgreSQLなどのRDBMSは制約をかけることができ、RDBMSはデータを守る最後の砦だと考えています。しかし、データ基盤を扱っていく上で制約がつけられないデータストアも多く存在します。そういった制約をつけられないデータストアをデータ基盤に転送していると、たまに問題が発生し障害につながってしまいます。

例えば、Salesforceやスプレッドシートのデータは制約をつける事ができません。Saleforceでは同名企業があまりにも多いと重複して入力ミスが起こり、スプレッドシートでは売上を調べるときにKPIが二重カウントされる可能性があります。そうした問題が発生してから発覚したのがもし１ヶ月後とかだと、記憶も薄れてしまい調査も大変になってしまいます。」

では、こういった問題を防ぐためにはどういった対策が必要なのでしょうか。同氏は「SQL上で満たしてほしい制約と期待する結果をvalidation」することが解説しています。

吉田康久氏：「YAMLにSQLを書いて、会社の名前が一意であるかを定期的にチェックしていく事が大切です。それを満たしていない場合はslackで通知して、事務の方に素早くデータを直してもらってデータがきちんとした状態を保っていかなければなりません。

また、必須のカラムだと思っていたものにNULLが入っていたら、Salesforceの入力規則でその箇所を必須項目にしてもらうなどのコミュニケーションを図っていく必要があります。」

データマートが広く使われている中で目的にそぐわないデータをもとに意思決定されてしまった事例

吉田康久氏：「データ基盤が広く使われるようになると、鮮度の低いデータを収集したテーブルが多数存在した状況に多く陥りがちです。そういった使われていないリソースが氾濫していると、集約の目的が異なるテーブルを活用して、誤った意思決定がされてしまうことがあります。」

吉田康久氏：「こういったことを防ぐために、データマートの定期的な掃除が必要になり、四半期に一度利用頻度の低いテーブルやビューを削除するなどが有効的です。

ただ、クエリ統計量だけでテーブルやビューを削除することに自信が持てないことが多いので、どのデータが使われているかわかるデータリネージとして整備することで安心して消せます。また、descriptionでどのデータやテーブルが使われているかを明記しておくことも大切です。」

データ分析基盤の障害を未然に防ぐためのチェックリスト

出典：田中聡太郎、「データ分析基盤の障害を未然に防ぐためのチェックリスト / checklist for preventing incidents of data management system」、https://speakerdeck.com/tanakarian/checklist-for-preventing-incidents-of-data-management-system より

ユビー株式会社に所属し、データエンジニアをされている、田中 聡太郎 氏(@__sotaron__）。障害対応をどうするかではなく、ベースとなるデータへの信頼性(Data Reliability)の概念と事前防止策の具体的なチェックリストの事例についてお話ししていただきました。

データの品質指標

田中 聡太郎 氏：「データへの信頼性（DataRealiability）は各社がデータを扱っていく上で、データの品質に目を向けた考え方です。データの品質とは、「データそのもののデータ品質」と「BIツールやデータストアなどのデータ関連システムの品質」に分かれています。

データ品質指標の代表的なものとして「完全性(Integrity)・一貫性（Consistency）・一意性（Uniqueness）」が挙げられ、データ関連システムの品質指標の代表的なものとして「適時性（Timeliness）・可用性（Availability）・冗長性（Redundancy）」が挙げられます。

これらの品質指標に基づいてデータの品質を保っていく事が重要です。」

こういった指標をもとに品質チェックリストはどのようなものを作成すればいいのでしょうか。同氏は大きく３つの場合に分けて解説をしています。

ELTパイプライン、ワークフローの場合

田中 聡太郎 氏：「ELTパイプラインやワークフローを作りっぱなしにして、壊れた時に初めて気がつくこともあります。リトライを考慮できていないとデータが重複したり、欠損したりするので冪等性（べきとうせい）は大切です。

また、適時性の概念に近いが、よく更新されるデータはデータ反映が適切にされるように、静的なデータとは違うパイプラインに乗せるなどを考える必要があります。

そして個人的に大事だと考えていて、ストリームデータを扱っているときにデプロイを考えずにやると、データが欠損したりとかでリカバーが大変になります。ストリームデータを扱っているときはしっかりデプロイ戦略を考えることをチェックリストに加える事が重要です。」

データストアの場合

田中 聡太郎 氏：「データストアはデータロストしないことが一番重要なので、故障して一時的に繋がらなかったりしてもデータロスとしないようにバックアップを取ったり、リストアするようにテストをしておく必要があります。また、バックアップがどこまで戻れるのかを把握しておくことも大切です。

あとは、failoverの挙動もちゃんとテストしているかも重要で、failoverは機能的に提供されているが安心しきってはいけません。暗黙的に条件がいくつもあったりするので、それをちゃんとテストしているのか、そして条件はどうすれば守れるのかを品質のチェックリストとして確認する必要があります。」

BIツールの場合

田中 聡太郎 氏：「故障した時にシートの情報をロストしないか、であったりグラフや数表の描画や表示にかかる時間におけるユーザーからの体感値の報告は無視しておくのは良くなくて、ある日グラフが見えなくなることの前兆かもしれません。

RetroactiveからProactiveへ

田中 聡太郎 氏：「総じて、小さな失敗や事故は発生しうる前提で考える必要があります。バグのないプログラムは書くのが難しいので、そこは起こるのはしょうがない。なので、品質をちゃんと気にして、小さな失敗や事故を通して、大きな事故につながらないように気を配る必要があります。

実際、品質をどんなにチェックしていても障害は起こりうるものなので、障害対応もうまく活用していく事が大切です。データ分析基盤で起こった障害においてもポストモーテルを行うべきで、そのプロセスからただ振り返りをするのではなく、顧客のデータ品質やデータ関連システムの品質への期待値を知り、それを還元していく必要があります。

それを通して知った品質の期待値をチェックリストやサービスレベル（SLI）に落とし込んでいって、組織内で継続的な品質の向上や維持のサイクルを回していくことが大切になります。」

IoTデバイスデータ収集の難しい点

株式会社Mobility Technologiesに所属し、データエンジニアをされている渡部 徹太郎 氏（@fetarodc）。障害対応の中でも、IoT分野に特化したコアなお話をして頂きました。

渡部 徹太郎 氏：「ドライブレコーダーのデータを収集することは、webのアクセスログを解析するデータ収集とは全く異なっていて、ドライブレコーダーのデータ特有の癖を知らないと思わぬ障害に躓いてしまいます。IoTデバイスからのデータ収集は一味違く、「エンジニアの総合格闘技」と呼ばれるほど、多種多様な知識が必要となります。」

さらに、同氏はIoTデバイスデータの特徴は以下の10個あると解説されています。

• バイナリーデータを扱う
• CPUのアーキテクチャがx86/x64とは限らない
• プログラムのサイズに制限がある
• ネットワークが切れることがある
• ネットワーク帯域が有限である
• 電源が落ちることがある
• 電力が有限である
• ログは見ることができない
• アップデートは一大イベント
• 時間が正しいとは限らない

その中でも、同氏が実際にハマった箇所についてお話しいただきました。

バイナリーデータを扱う

渡部 徹太郎 氏：「IoTやり始めの人がハマることとして、リトルエンディアンとビッグエンディアンというデータの並びを取り違えてしまい、Floatが変な値になってしまうことがあります。また、-z方向の加速度を取っているつもりが、常に値が入っていてバグかと思ったら、実は重力加速度だったということもありました。」

ネットワークが切れることがある

渡部 徹太郎 氏：「webデータ収集にはない特徴として、「ネットワークが切れることがある」という問題があります。wifiの2.4GHz帯の電波は、他のwifi機器やbluetooth機器と干渉するので、チャンネルが混んでいて通信速度が出ないということにハマりやすいです。そのため、デバイス間のチャンネル変更が必要になります。

また、実は意外と知られていない事として、天井がないと電波が反射せず無線電波は弱くなります。屋外の駐車場だと天井がないため、電波が弱いという障害にもあいました。」

時間が正しいとは限らない

渡部 徹太郎 氏：「IoTデバイスのマザーボードには時計が内蔵されていないため、起動直後は2000年1月1日になってしまいます。こういったデータははじかないと、分析する際にエラーが起こります。GPS等を取れれば正しい時刻にはなりますが、こういった障害はIoTならではだと考えています。」

障害、解決、その先に

登壇資料はこちらからご覧ください。

フリーランスでデータ分析基盤構築を主業務とされている岩崎晃 氏（@sista05）。データ分析基盤で障害が起こった際の構成変更による対応とマネージドサービスを用いた対応の２種類の事例についてお話しいただきました。

岩崎晃 氏：「ログデータを収集する中で取り扱うアプリの数が増えていくに従って、ログの量が増大し、しばしばログの流れが詰まることが増えました。ログの滞留はユーザーからは見えないためサービス影響はないものの、裏では対応に追われ工数が積み重なってしまいました。

この問題の調査を続けていくと、複数の原因があることがわかりました。ログの流量が1M%を越えるあたりから、送信先となる本体aggregatorとheartbeat連携が取りづらくなっていました。fluentd aggregatorの問題ではありますが、別プロジェクトなため改修の依頼が受け付けられず、ログがつまりやすい状況はそのまま抱え込まざるをえませんでした。また、構成上にも問題があり、それもログ滞留の問題となっていました。docker自体が高負荷になると落ちることは頻繁にあり、バッファ格納先がEFSなので書き込み速度が遅いという状態でした。Service discoveryはDNSランドロビンなので負荷分散性能が悪いなどの間接的要因も挙げられました。

それらは枯れた技術で対応可能でしたが、最新の技術を使おうとして運用継続の観点が疎かになっていました。」

同氏は構成を変更することで多くの問題に対策を行いました。以下はその対策の詳細のお話です。

岩崎晃 氏：「少なくともダウンしないために、fluentd aggregatorはdockerからEC2に変更し、そしてEFSを廃止し、EBSを導入しました。負荷分散もDNSラウンドロビンからCLBに変更しました。本体aggregatorとheartbeat連携が釣りづらくなる問題は本体aggregator側で改修ができないので、データドックでバッファ蓄積を監視し、特定の閾値を超過した場合はバッファをリフレッシュするシグナルを発行することで解消しました。

運用保守は枯れたシステムの方が知見もバグも出揃っていて頼もしい部分があるので、なんでも最新技術を使おうとするのではなく、用途にあった構成を組む必要があります。また、dockerは長期運用・安定が求められる構成では避けることが望ましいと考えています。設計はシステムを構成する要素を十分に満たしているかを検討した上で、保守する人が保守しやすい簡潔な構成にする必要があります。」

次にワークフローエンジンにDigdagを用いて際に起きた障害の事例をお話しいただきました。

岩崎晃 氏：「運用していく中で、日次実行ジョブがたまに流れていないことが判明し、ジョブを再送しようにも、UIにアクセスできるジョブの停止をすることができなくなりました。また、営業の人もアクセスするため業務に支障が出るようになってしまいました。

原因を調査すると、バッチ処理の際に数十Gバイトのデータをサーバー自身のメモリに溜め込んでおり、処理を圧迫していることがわかりました。サーバー自身をリソース強化して対応することも可能でしたが、運用を継続するに連れてデータが肥大化していくことがわかっていたので、いたずらにサーバーを強化することは本質的な解決にはなりませんでした。」

同氏はスケールを考慮した構成に変更することで対策を行いました。

岩崎晃 氏：「今回も構成を根本的に見直して冗長化構成を図ることにしました。まず、バッチ処理をサーバー自身で行わずfargateに移行し、サーバー本体をDigdagからEC2に、耐障害性向上のためにAuroraに変更しました。そしてログイン用のUIは本体と分離し、サーバー自身にリソースが必要な場合でも、速やかにスケールして対応できるようにEC2はオートスケーリンググループに組み込みました。

修正前の構成は様々なところで見受けられましたが、ネットではDigdagをdocker＋embulkで構成している例が多く、それに引きずられたのではないかと考えています。

これまでに紹介した例はスケールに対応できずに破綻する例だった。クラウド環境では、サーバー構成もなるべく冗長化する形をとるべきと思います。とにかく、可用性とスケーラビリティが大切になるので、それらに全振りした環境を作ることが大切です。」

最後に個人情報に関して発生した問題をマネージドサービスで解決した事例を紹介していただきました。

岩崎晃 氏：「今回は構成に問題があった訳ではないが、ログに個人情報を特定できるものがあったため度々問題視されていました。断片的にでも企業などの個人情報がわかってしまうと、インサイダーなどの問題に抵触する恐れがありました。こういった問題は顧客のためだけでなく、分析者・開発者を守るためにも重要なことでログマスキングの重要性が高まってきました。

しかし、この問題は単純に個別に情報をマスクすれば済むものではありませんでした。例えば、マスク処理を入れていない出力パラメーターに誤って個人情報が含まれる可能性があります。また、クエリ処理でクエリストリングが用いられることは一般的でありますが、ストリングの中で固有の情報をマスクすることは難しいです。」

クエリストリングは品質向上のために重要で闇雲にマスクできないという問題を抱える中、同氏がGCPで情報漏洩対策用のCloudDLPで試みた解決策についてお話をいただきました。

岩崎晃 氏：「個人情報に該当するものをIPアドレス・個人名に相当すると判断できる機械学習でマスキングを図り、紐付けできるIDを付与することでクエリ分析対策も可能になりました。ランダムに現れる情報のマスキングは機械学習に任せてしまおう事がベストだと考えており、DLPなどを用いても防ぐことのできない情報漏洩については、社内での情報管理体制を構築し、準備しておくことが重要です。」

障害はチャンスだ！障害を前向きに捉える

出典：岩崎晃、「障害はチャンスだ！ 障害を前向きに捉える」、https://speakerdeck.com/tanakarian/checklist-for-preventing-incidents-of-data-management-system より

株式会社リクルートでデータエンジニアをされている山田 雄氏（@nii_yan）。発生してしまった障害に対し、どのような対応を行うか。また、障害対応というものをどう捉えるかをお話しいただきました。

山田 雄氏：「データ基盤・インフラは水道のようなものだと思っています。データはパイプラインで流れていて、いつでもほしいデータをとることができます。水道が止まるようにデータの流れが止まると、分析しているユーザーが困ってしまいます。

そのため、データ基盤が水道のようになってくると使えるのが当たり前になり、エンジニアが責められる事があっても褒められることはなくなります。

会社においてもインフラの人の評価は難しく、障害を見てマイナス評価をしていく事が多いですが、障害対応によってその後の印象が変わっていくこともあり、障害対応によって得られることも多いと考えています。」

同氏は障害対応時の進め方や学びの重要性を指摘しています。

障害対応は人も組織も成長できるチャンス

山田 雄氏：「障害対応をするときは対面でホワイトボードを使ったりして話し合っていくが多いと思います。その際に障害対応に精通した社員のコマンドを見て学ぶ事ができ、ペアプロをすると自分もコマンドを覚える事ができるため、スキルを向上させる事ができます。

また、その場にいる人で対応するため、知らないシステムでも基盤の仕様にも詳しくなれるのも重要な点だと思います。

障害対応時は自身の能力を伸ばせるチャンスだと考えているので、障害対応には率先して当たりことが大切です。また、障害対応時のルールを事前に定めておく事が重要で、誰が旗振りをやるのかであったり、優先順位を定めておく必要があります。」

さらに、障害対応の振り返りであったり、ポストモーテムの必要性についても解説していただきました。

再発を防ぐために

山田 雄氏：「ポストモーテムを一言で表すと、障害の事後検証報告書です。ポストモーテムを作ることで組織の知識として貯めておくことが事ができるので、障害復旧に携わった本人以外に組織も成長できます。

ポストモーテムの例として、概要・どの程度のものだったのかとしてのインパクト・根本原因・根本原因よりも深掘りした内容の発生原因・そしてどのように対応したか。また、教訓としてうまくいったこと・うまくいかなかったこと・幸運だったことを書き、タイムラインはできるだけ細く記載し、再発防止策も書くことが大切です。

障害は起きないに越したことはないが、障害の起きないシステムは存在しないので、障害が起きる前提で考えておく事がいいと思います。

また、障害が起きてもマイナスなことだけでなく、知識が付く機会で、人が成長できるチャンスなので、しっかり振り返りをして共有しておくことで組織も成長できるチャンスです。そして、障害対応の仕方によっては社内で認められて、基盤の価値が上がっていくのではないかと考えています。」

バッチとストリーミング、それぞれの障害に立ち向かう

出典：大久保諒、「バッチとストリーミング、それぞれの障害に立ち向かう」、https://speakerdeck.com/syucream/batutitosutorimingu-sorezorefalsezhang-hai-nili-tixiang-kau

株式会社メルカリでデータエンジニアをされている大久保諒氏（@syu_cream）。

大久保氏がメルペイで実際に運用していたバッチ・ストリーミングについて、実際に起こった障害と対応についてお話しいただきました。

まず、データ分析の領域ではお馴染みのバッチ処理とストリーミング処理の特徴について解説していただきました。

大久保諒氏：「バッチ処理とストリーミング処理の二つのシステムが持つ利点としては、柔軟なワークロードに対応でき、バッチ処理でうまく扱えなかったワークロードに対してストリーミング処理を行ったり、途中までストリーミング処理を行って最後にバッチ処理を行うなどの混在をさせる事ができる点です。

ただ、二系統のシステムを持つので障害が増えたり、運用コストが増える事があります。それだけでなく、それぞれ異なるフレームワークやインフラのノウハウが求められたり、開発コストが増える欠点があります。」

まず、バッチ処理のシステムの障害事例を紹介していただきました。

大久保諒氏：「BigQuery側で差分更新で歯抜けになるレコードが生じるという事がありました。毎回スパナーとかにフルスキャンして全入れ替えをBigQueryにすると、データベースへの負荷やトラフィック量とかのコストが増大するので、できれば更新されたデータだけ転送したいと考えました。そのため、最後に同期したタイミングを記憶して、そこから現在に至るまでの差分をBigQueryに届けて、現存するテーブルと差分だけのテーブルを組み合わせて、結果を最終的なテーブルに描き戻すことをして全体的なパイプラインの負荷を減らしていました。」

この問題はさらに苦労した点があると、同氏はお話してくださいました。

根本的な解決が難しい問題も

大久保諒氏：「ある特定のカラムが更新されないという問題が生じたため、差分の値をチェックするカラムを調べました。すると、モノトニックに更新処理をしていった時系列を逆行する形でDML手動実行をしたことで、BigQuery上で古いままのレコードだと判断され、差分更新が行われない事がわかりました。

この問題は手軽な解決方法が見つかっておらず、使うカラム・クエリは気をつけてアップデートする必要があります。

また、差分レコードがうまくされても、BigQuery側で更新されていないケースが見つかった。現存するテーブルと差分だけのテーブルを結合させていた部分で、読み取った差分と既存レコードに重複がある場合は、新しい差分を優先することで一旦は解決したものの、中身としては消化不良が残る結果となりました。」

次に、ストリーミング処理のシステム障害事例を紹介していただきました。

ストリーミング処理はコストがかさむ

大久保諒氏：「メルペイの小規模のマイクロサービスのログ収集パイプラインだったものをメルカリでも転用し、API Gatewayの役割をするマイクロサービスのアクセスログの収集にも活用しましたが、過去に想定していたトラフィック量と異なりすぎて処理が詰まってしまいました。

その時は、スケールアウトしたりお金で解決する手段は取らずに、愚直な対応、捨てられるログは捨てるなどしていましたが、バッチ処理に比べて課金額大きいので再構築を検討しました。

AvroのGenericRecordデータを用いた中間表現では、冗長的な表現をしていたためデータフローの課金が増えていたので、スキーマ解決の仕組みを再構築してスキーマ分の冗長的なトラフィックを削除する対策を取りました。」

利点も大きいが壁も高い

大久保諒氏：「バッチ処理とストリーミング処理の量アプローチを採用するケースが多々あるが、それぞれ障害のパターンがあるため困難を極める事があります。アーキテクチャ全体を見渡して問題を切り分けていき、場合によっては全体を刷新していく事が重要だと思います。」

過去のData Engineering Studyのアーカイブ動画

Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。

当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。

過去のアーカイブもYoutube上にございますので、ぜひご覧ください。

https://www.youtube.com/channel/UCFde45ijA-G9zs7s2CuftRw