koudenpaのブログ

趣味のブログです。職業柄IT関連の記事が多いと思います。

サービスレベルについて思ったこと

ConoHaのオブジェクトストレージの特定のオブジェクト(https://object-storage.tyo1.conoha.io/v1/~~)へのHTTPSアクセスをMackerelでURL外形監視してます。

以下の表は去年12月から明けて正月明けの期間のアラートの発生と解消時刻、発生から解消までの秒数をまとめたものです。

アラート内容は全てタイムアウトです。

CreatedDateTime ClosedDateTime OpenSec
2018/1/9 18:13 2018/1/9 19:35 4907
2018/1/8 20:30 2018/1/8 20:48 1068
2018/1/8 20:05 2018/1/8 20:27 1314
2018/1/2 20:50 2018/1/2 21:19 1724
2018/1/2 20:37 2018/1/2 20:47 585
2018/1/2 20:06 2018/1/2 20:34 1673
2017/12/28 20:58 2017/12/28 21:26 1662
2017/12/25 20:38 2017/12/25 20:43 289
2017/12/19 20:08 2017/12/19 20:13 285
2017/12/12 20:04 2017/12/12 20:05 52
2017/12/8 14:33 2017/12/8 14:35 107
2017/12/7 21:58 2017/12/7 22:01 176
2017/12/6 20:03 2017/12/6 20:04 49
2017/12/5 20:03 2017/12/5 20:04 58
2017/12/4 17:33 2017/12/4 17:36 167
2017/12/3 20:03 2017/12/3 20:04 47
2017/12/1 20:04 2017/12/1 20:05 52

この状況について問い合わせたところ、ネットワークは共有なので利用状況に応じてこうしたネットワーク遅延は発生するとのことでした。

これをどう感じるかは人それぞれかと思いますが、自分は今後新規にConoHaのオブジェクトストレージを使用することはないでしょう。

VPSと違ってパブリッククラウドの同種のサービスと比べてコストメリットもほとんどありません。

続きを読む

Node-REDのMackerelノードを作る

この記事は Mackerel Advent Calendar 2017 - Qiita の13日目です。

昨日は hoosoi - Qiita さんの XXX でした。

さて、先日は Node-RED から http request node を使ってサービスメトリックを投げました。

koudenpa.hatenablog.com

API-Key を function node にべた書きするなど相当イケていない形であったことは否定できません。というか、クソ 改善の余地がある実装です。

というわけで、認証情報を秘密にすることを主な目的に Mackerel にサービスメトリックを投げるNodeを作成してみました。

Node-RED日本ユーザ会 : はじめてのノード開発

チュートリアルがあるのでそれに従って作成していきます。

やりたいことは単なるHTTPSリクエストなので、その機能があるノード参考にし パクって作成しました。

github.com

続きを読む

Node-RED から Mackerel にサービスメトリックを投げる

ここは Mackerel Advent Calendar 2017 - Qiita の13日目予定地です。

さて……

Node-RED からMackerelにメトリックを投げる例はググっても見当たらなかった気がするので、試してみた。

こういった「やってみた」は先人がいても、どんなにくだらない内容でも気にしないで発信する強い心が必要である。

とりあえず http request node でどうにかしてみる。

f:id:koudenpa:20171204234212p:plain

http request node は、リクエスト内容をNodeへのInputで指定できるので、手前のNodeでサービスメトリックをPostするように設定してやればよい。

さしあたって function node でごり押しする。

f:id:koudenpa:20171204233734p:plain

let time = (new Date()).getTime() / 1000;
let randomValue = Math.random();

msg.payload = new Array({
    name: "random-value",
    time: time,
    value: randomValue
});

// XXX Secret!
msg.headers = {
  "X-Api-Key": "かっこ悪いけれど別にAPI-Keyを埋め込んだっていいじゃない"  
};

msg.url = "https://api.mackerelio.com/api/v0/services/node-red/tsdb"
msg.method = "POST";

return msg;

どうにかなった。

Node-RED からだってメトリック投げ放題だ!

f:id:koudenpa:20171204234000p:plain

f:id:koudenpa:20171204234110p:plain

こんな感じのFlowでテストした。

f:id:koudenpa:20171204234829p:plain

これで最低限の体裁は整った。

元気と時間と運気があったらMackerel nodeをNode-REDのお勉強がてら作成したいと思う。

この記事がアドベントカレンダーからリンクされていたらお察しください。

mackerel.io

APIを直で叩けば、インターネットに接続されている環境ならメトリック投げ放題。 これはPush型のサービスの非常に大きな利点だと思う。

ただ、どうにもAPIリファレンスにベースURIが見当たらなくてちょっと困ったので、その旨サポートチームに連絡しておきました。

それでは。

モニタリングのUX

先日、Mackerel User Group主催のモニタリング勉強会に参加してきました。

mackerel-ug.connpass.com

MackerelPrometheusZabbix、という3種のモニタリングサービス・ソフトウェアそれぞれの話が聞けるなかなか面白い企画だったように思います。

そんな中で、懇親会でLINE Fukuoka(敬称略)でのPrometheus活用事例を聞いて「いいなぁ」と思ったのでメモします。

酒も入っていたし、Prometheusのアーキテクチャはさっぱり知らないので嘘八百かもしれないけれど「いいなぁ」と思ったことに変わりはないのでよし。 つまり、眉唾であるということです。

さて、自分がある程度見知っているMackerelでは 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ と発信されている通り、時系列データを新しいものは高速なストレージに、古いものは順次コストパフォーマンス重視の低速なストレージに配置しています。

同様に、Prometheusでも、直近のデータのみ書き込みできる高速なストレージに、古いデータは順次退役、バックアップして、それをリモートリードするようなことをしているとのことです。

当然ながら、退役先は低速なストレージとなるわけですが、古いデータはそれほど参照されない、という理由からモニタリング上は問題にならない、という判断です。

モニタリングに関してはこの考え方は今後当たり前になっていくような感じを受けています。

さて、聞いた事例で良いな、と思ったのはここからです。

古いデータは参照されないとはいえ、例外的な事情もあり、例えば「年末には去年末のデータがよく参照、比較される」とのことです。

これに対して、該当のデータのリモートリード先をあらかじめ高速なものにすることで、参照の応答速度を上げているとのことでした。

つまり、モニタリングデータを見る側が「去年のデータ見たいなぁ」と思った時に、サクッと出るわけです。

すさまじいUXだと思い、それを提供するエンジニアの気迫を感じました。

具体的にどうしてるのかは知らんですが、Mackerelの時系列DBの構成で言えば、特定の時系列のデータをS3からDynamoに戻すようなことを行っているのでしょう。

とても「いいなぁ」と思いました。

現場から数日後の自宅からは以上です。

この記事が嘘か誠か気になる場合は、登壇ご本人にお伺いください。

github.com

HTTPS化の流れへの違和感

HTTPだとChromeが警告を発するので、と言う理由でのHTTPS化が進んでいる。 個人的にはこの流れには強い違和感と言うか、不快感を覚える。

そもそも、インターネット上の通信を暗号化、送信先を認証する理由は、その通信を保護するためだ。 そこに関心がないなら、堂々と平文で通信すればよろしい。

平文での通信は盗聴し放題だ。 昨今は公衆無線ネットワークの普及が著しく、盗聴の敷居はとても低い。 平文でのセッションハイジャックの例を見てもそれは明らかだ。

赤の他人に赤裸々な検索ワードやツィートを見られたいとは誰も思わないでしょう。

通信をセキュアなものにする理由は、Chromeが警告を出す理由と同じものであってほしいものだ。

webmaster-ja.googleblog.com

事業サービス会社の開発部門での出来事

前回からのつづきです。

刺激が欲しくてCodeIQという転職サイトを使って、いわゆるWeb屋DMM.comラボに転職しました。

dmm-corp.com

が、今にして思うとWeb屋とはちょっと違ったかもしれないです。 結構大きな組織で、無数のサービスを保守、開発しているので、配属部署に寄りますね。

はじめの1年は、DMM.makeのサービスの保守、新規開発を行っていました。

つぎの1年は、DMM.makeの中でもロボット事業というアグレッシブな領域で、ロボットの代理店商売の舞台裏でエンジニアリングしていました。

さいごの半年は、DMM.makeの主要サービスをオンプレミスからクラウドAWS)へ移行していたら終わっていました。

Mackerel Day で少ししゃべった話です。

続きを読む

中小SI企業での出来事

前回からつづきます。

かなりユニークな経歴をへて、株式会社ネッツというIT企業に就職しました。

www.nets-web.co.jp

勉強会なりでしゃべるときの自己紹介では、名前を出さずにSI孫請け(直請けもしていましたが)と表現することが多いです。

そういった場所ではSI業界の会社は大手でもそれほど名前が通っていない(多分自分も上場企業ですら分からないです)ですから、大体こういうところで仕事していました、といったニュアンスです。

7年ほど勤めました。

続きを読む