#最初に
###Dr.Sum とは
【詳細はこちら】**Dr.Sum**は10億件のデータを1秒台で集計できる超高速データベースツールです。
また、Dr.Sumは集計速度だけでなく、データベース構築経験の少ない方でもGUI操作でDBをつくったり、データを取り込んだりできます。
データベース周りにそこまで強くないぼくのような人間でも、気軽にデータハンドリングができるところが素敵です。
さて、Dr.Sumという製品は単純にデータベースがあるだけではなく、様々なオプション製品を加えることで、多様な使い方が可能です。
詳しくは公式ホームページをご参照いただきたいのですが、
✅ データを抜いて
✅ データを加工して
✅ データを貯めて
✅ データを高速集計する
ことが可能となります。
###Dr.Sum Connect とは
【詳細はこちら】**Dr.Sum Connect**はデータを抽出・加工・取り込みをするETLツールです。
下図のように様々な環境からデータを取得して、加工して、Dr.Sumに投げ込むことのできるツールです。
エラーになったらログを吐いたり、メールを飛ばしたり、だいたいGUIで操作できるので、プログラムを書かずとも連携の仕組みを作ることができます。
基本的なスクリプトのつくり方についてはこちらの解説記事をお読みください。
Dr.Sum ConnectをつかったETLのスクリプトのつくり方
Dr.Sum ConnectはDataSpiderをOEMした製品です。
以降はConnectと表記します。
さて、先日DataSpider（Dr.Sum Connect）でSalesforceからデータを取得する際に、APIタイムアウトを乗り越える記事を書きました。
この記事で一点だけ書いていなかったことがあります。
それはETLでは必ずある、夜間連携の報告です。
メジャーなのはエラーが発生したら、関係者にメールを送るタイプですね。
深夜に気づいた時にはヘコむものです、いやまぁ朝でもヘコみますが。
でもエラーがほったらかしになるよりは何倍もマシです。
今回は正常でも異常でも処理結果をメールする仕組みを考えました。
何を送るかと言うと、メール＆添付ファイルです。
さて、この添付ファイルの意味とつくり方について、解説をしていきましょう。
#この添付ファイルの意味
夜間連携の報告を毎日受ける人にとって、大事な要素が何個かあります。
① ひと目で正常か異常かわかること
② どんな過程をたどって成功にたどり着いたかわかること
③ その他の情報が付加されていること
大事な順番は①→②→③です。
このダッシュボードは必要最低限で装飾もしていませんが、最低情報は抑えています。
左上が①、正常終了したか否かを伝えています。まず最初に目線はここに行きます。
左下が②、タイムアウトをどれくらいしたかが各オブジェクトごとにあらわされています。
右側が③、過去のタイムアウトの履歴を表示しています。
③は今後の傾向分析で役立つことになります。今はデータが溜まっていないので、まだ価値が出ていませんね。
このような情報が毎日届けば、管理者にとって親切な情報となるでしょう。
それではつくり方を解説していきます。
#メールを送るのはMotionBoard
我ながら奇跡的な絵を書いてしまいましたが、関連図はこんな感じです。
A.ConnectがSalesforceのデータをDr.Sumに取り込みます。
B.このとき正常終了、異常終了のログ情報も追記型でDr.Sumに書き込みます。
C.MotionBoardでログ情報を参照し、先程の画像のようなダッシュボードを作成します。
D.MotionBoardのタスク配信機能でメールを送ります。
MotionBoard Cloudであれば、wingarc.comからメール送信ができます。オンプレであるとメールサーバーを指定する必要があります。
ありがとうクラウド、便利です。
#ログは２パターン用意する
追記型ログと更新型ログの２パターンを用意することをオススメします。
追記型ログはMotionBoardに読み込ませる専用のテーブルです。
人間が見るとわかりにくいです。
だいたいログは**いざというときに見るものなのです。**人間に見やすい形というのも設計しておきましょう。いざというときに慌てないで済みます。
人間が見るときはこっちです。
最新情報だけピックアップしています。
ちなみに、どっちが重要だと言われると、前者になります。
前者はデータが貯まるごとにエラーの傾向がわかるようになります。
新しい発見は、データが蓄積されることで生まれていきます。
#傾向を可視化せよ
追記型ログのメリットは画面右側の傾向の可視化です。
今回のようなSalesforce側のタイムアウトエラー、エラーを受け入れて処理を作りましたが、釈然とはしません。
何か法則があるはず。
調査の一歩目はエラータイミングの調査です。
右上は曜日ごと、オブジェクト別のヒートマップ。
右下はオブジェクトごとのタイムアウト回数の日別推移です。
まずはこの形で傾向を探り、気になったところはMotionBoardで深掘りしていきます。
こんな情報が毎日届くだけで、何かしらのきっかけを生み出せそうですよね。
#タスク処理でメールを送る
MotionBoardのすばらしいところは、わざわざダッシュボードを見にいかなくても良いこと。
定期的に画面を共有してくれます。
こちらのダッシュボードは毎日7:00にメールしてくれるようにしています。
ぼくは毎日、メールを見て昨日の状況を確認しています。
追記型ログを作らなかった頃は、毎日Dr.Sumを開いてログ情報を直接確認していました。
ログ情報を取り込まなかったときは、Connectのトリガーログを確認していました。
今はメールを見るだけ、3秒で確認できるようになりました。
日々のこうしたルーティンワークの改善は、人生を楽するための方法となるでしょう。
#さいごに
いかがだったでしょうか。
今回は技術的な情報というよりは、保守を行うときのうまーい手の抜き方についての解説でした。
なるべく、なるべく自動化をするべきです、そこに神経を注ぐべきなのです。
ぼくはこれからもルーティンとなる思考は仕組みで排除できるようにしていこうと思います。