koudenpaのブログ

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

モニタリングの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年ほど勤めました。

続きを読む

エンジニア定年に思うこと

本日、IT業界で俗にエンジニア定年と言われている35歳になりました。

結構なオッサンになったものです。

さて、定年を迎えてみて感じるのは、全然定年じゃないなぁ、という実感です。

自分は自分を中の上のエンジニアと位置付けているのですが、その辺も交えてエンジニア定年についてそれを迎えた時点で所感をメモしておきたいと思います。

続きを読む

就職までの出来事

自分は、非常にユニークな人間だと思います。

これは、文字通り一意であるという意味で、同じような履歴(書)を持っているエンジニアはおそらくこの世に居ないでしょう。

丁度エンジニア定年を迎え、そろそろ半生という時期になって、あんまりポジティブではない履歴も自分の中ではある程度笑って思い出せるようになってきたので、軽くでもたな卸ししておこうと思う次第です。

とはいえ、全然書けないこともあるわけですが。

続きを読む

Metrin と mkr コマンドでCloudWatchのメトリックをMackerelのサービスメトリックとして投げる

RDS Aurora にはインスタンス毎の情報のほかに、クラスタ毎に割り当てられているストレージボリュームに関する情報がある。

これは、現在のMackerelのAWSインテグレーションでは収集されない。 (2017/10/13現在、多分)

が、収集しておきたい情報なのでサービスメトリックとして投稿したい。

が、CloudWatchのAPI結果の整形だとか、Lambdaとか、よく知らない&面倒くさい。

と、Google検索をさまよっていたら Metrin という素晴らしいツールを作ってらっしゃる方がいらっしゃったので使わせていただいた。

Metrinとmkrが動作するように設定されている環境ならこれだけで飛んでいく、素晴らしい汎用性に感動した。

metrin \
  --region ap-northeast-1 \
  --namespace AWS/RDS \
  --metric-name VolumeBytesUsed \
  --dimension DbClusterIdentifier:$clustername \
  --dimension EngineName:aurora \
  --statistic Maximum \
  --start-time -3600 \
  print --last-value-only \
  | mkr throw -s $servicename

# DbClusterIdentifier+EngineName:auroraのメトリックには以下があるようだ
# - VolumeBytesUsed
# - VolumeReadIOPs
# - VolumeWriteIOPs

こちらのQiita記事で知った。

qiita.com

リポジトリやバイナリの配布はGitHub

github.com