k近傍法による異常検知のライブラリをmrubyで作ってみた - Fire Engine
こんにちは！インフラエンジニア見習いつるべーです。 今回は、mrubyという組込ソフトウェア向けの軽量なRuby言語を使って、k近傍法による異常検知を行うスクリプトを書いてみたので、そちらの紹介です！ 目次 なぜ作ったのか 作ったもの ソースコード 使い方 mrubyに入門するには Changefinderとの比較から見るKNNの特徴 今後やりたいこと オマケ：k近傍法(K-Nearest Neighbor :KNN)に基づく異常検知の理論 なぜ作ったのか 今回は、「何かの問題を解決したい」というよりは、「Rubyの勉強がてらに何か作ってみよう」という動機で作りました。 ただ、一般的なRuby（CRuby）ではなくmrubyを選択したのには理由があります。 私が勤めているGMOペパボでは、mrubyを利用してミドルウェアの振る舞いを設定・制御する仕組み（これを"Middleware Con
機械学習モデルの局所的な解釈に着目したシステムにおける異常の原因診断手法の構想 - Fire Engine
著者 鶴田 博文, 坪内 佑樹 所属 さくらインターネット株式会社 さくらインターネット研究所 研究会 第8回WebSystemArchitecture研究会 1. はじめに インターネットを介して利用するシステムの大規模化に伴い，システムの構成要素数の増大や，構成要素間の関係性の複雑化が進んでいる． そのため，システムの性能に異常が発生したときに，システムの状態を示す指標であるメトリックをシステム管理者が網羅的に目視することや，メトリック間の関係性を把握することができず，システムの異常原因を特定することが難しくなっている． この問題を解決するために，深層学習などの機械学習モデルを用いて，システムの異常の原因を診断する手法が提案されている[1,2]． これらの手法は，システム管理者が異常の根本原因を絞り込むために活用することが期待できる． しかし，原因診断を行うためには，事前に機械学習モデ
企業研究者の立場からKaggleに取り組む意義を考えた - Fire Engine
先日，Kaggleで初めてコンペに挑戦し，その振り返りをブログに書きました． 現在，企業で研究者として働いている私は，Kaggleのコンペに取り組むことは非常に学びが多く，自身の研究活動にも良い貢献をするだろうと確信しました． 私自身Kaggleに取り組むまでKaggleと研究に繋がりを見いだせておらず，実際にコンペに取り組むことでその繋がりが見えてきました． まだ1コンペしか参加経験がないビギナーではありますが，私が考えている研究者としてKaggleに取り組む意義について現時点の考えをまとめたいと思います． 自分の立場について Kaggleへの取り組みが研究に良い貢献をするかどうかは，研究の分野や内容に依存すると思うので，私の立場をはっきりさせておきます． 私は現在，インターネットインフラサービスを提供するさくらインターネット株式会社の組織内研究所であるさくらインターネット研究所で研究員
Kaggle初コンペの振り返り〜Riiidコンペで銀メダル獲得〜 - Fire Engine
Kaggleで開催されていたRiiid! Answer Correctness Predictionに参加しました．結果を簡単にまとめると以下の通りです． 順位：139位（3406チーム中） メダル：銀メダル（上位5%以内） 解法：LightGBMとSAKTのアンサンブル チーム：1人で参加 自身初となるデータ解析コンペでしたが，なんとか銀メダルを獲得することができました．今回はその振り返りを時系列で書いていきたいと思います． 先に感想を述べると，Kaggleは本や論文ではなかなか得られない学びに溢れている上に，世界中の人々と順位を競い合うゲームのような感じでとにかく楽しいので最高すぎました． この記事がこれからKaggleを始める方々の参考になれば嬉しいです． 目次 Kaggleとの出会い コンペ参戦準備 コンペに登録 初Submit 特徴量エンジニアリング モデルの構築 アンサンブル学
グラフィカルモデルに基づく因果探索手法の調査 - Fire Engine
最近，因果推論や因果探索に興味を持ち，勉強している．というのも最近，ゆううきさん と一緒に分散システムの異常の原因を即時に診断するための研究を進めている．原因を診断するためのアプローチとして，サーバやコンテナ等から取得できる様々なメトリック（CPU使用率やメモリ使用率など）を（グラフ理論における）ノードとして，因果グラフを構築することを考えている．メトリック同士の単なる「相関」ではなく，結果と原因の関係である「因果」を捉えようとするアプローチである．例えば，システムの障害が発生した場合，相関だけでは，AとBが関連がありそうというところまでしか言えないが，因果を特定できると理想的には，Aの原因はBであるといった議論ができるため，有用だと考えている． 実際に，前述のような因果グラフを構築して障害の原因を特定しようというアプローチは，以下の例に挙げるようにここ数年で増えている印象がある． 「Mi
GMOペパボ株式会社を退職しました - Fire Engine
2019年7月24日が最終出社日でした。ペパボでは、ロリポップやへテムルといったレンタルサーバサービスのインフラエンジニアとして働いており、約1年半在籍していました。 今回は、ペパボでの一年半の振り返りと、転職に至った経緯などについて書いていきたいと思います。 ペパボでの一年半の振り返り 私はペパボカレッジの枠でペパボに採用されました。ペパボカレッジとは第二新卒エンジニア向け研修のことで、中途採用でも現場に配属される前にしっかり研修を受けることができます。私はエンジニア歴も浅いし、そもそもインフラの経験がなかったため、このペパボカレッジの応募はまたとないチャンスだと感じました。実際に研修では約一ヶ月間で広大なインフラの分野の知識を爆速で学んでいきます。具体的な研修内容などは以前のブログに書きました。頑張りたい人を応援してくれる本当にいい仕組みです。 研修が終わって、配属後も周りのエンジニア
遺伝的アルゴリズムの並列化とgoroutineによる実装 - Fire Engine
先日、「遺伝的アルゴリズムをGoで実装してみた」という記事を書きました。 この内容で2019年7月13日（土）に開催されるGo Conference'19 in Fukuokaに登壇させていただくことになったので、開発中のeagoというパッケージをもっと作り込んで行きたいと思います。 今回は、遺伝的アルゴリズム（以下、GA）の計算処理をgoroutineでサクッと並列化した話です。 概要 GAは複数の個体を用いた多点探索のアルゴリズムであるため、本質的に並列化と親和性が高い手法であると言えます。実用的な観点からも短い計算時間で良好な解を得ることが望まれているため、これまでに数多くの並列化手法が提案されています。 今回はGo言語の強みの一つであるgoroutineを使ってGAの処理の一部を並列化してみます。また、擬似問題に対してベンチマークを取り、実装した並列処理が全体の計算時間短縮に有効で
ユーザが接続先を意識しないSSHプロキシサーバを作った - Fire Engine
今回は、ユーザが接続先を意識しないSSHプロキシサーバを作った話です。 SSHのユーザ名から動的に接続先ホストを決定し、SSH接続をプロキシします。 github.com 作った背景 比較的規模の大きなサーバ群を管理しており、そこに対して接続してくるユーザに特定のサーバを使ってもらいたい場合を考えます。 すなわち「ユーザtsurubeeには、ssh102サーバを使ってほしい」といったようにユーザとマシン間が紐づいている場合の一番単純な運用方法は、個々のユーザが接続先ホストの情報を知っていることです。 これでも問題ないのですが、何かしらのサーバ管理の理由でユーザに使ってもらいたいサーバが変更した場合、ユーザに通知するなどして意識的に接続先を変更してもらう必要があります。 このようなユーザとそのユーザに使ってもらいたいサーバの紐付け情報をサーバ管理側が一元的に管理して、ユーザに意識させることな
Dynamic Time Warping（動的時間伸縮法）で時系列データをクラスタリングする - Fire Engine
最近時系列データのクラスタリングに興味を持ち始めて、いくつか論文読んだり、アルゴリズムについて調べていたら、実装してみたくなったので勉強のために作ってみました。 実装の言語にはGolangを用いていて、クラスタリングのアルゴリズムは、Dynamic Time Warping（以下、DTW）とk-medoids法を組み合わせたものです。 作ったもの 使い方 検証 実装したアルゴリズム Dynamic Time Warping（DTW） k-medoids さいごに 作ったもの github.com tsclusterはtime series clusteringの略です。 今回は作ったのは、特定のアルゴリズムのみですが、今後興味があるアルゴリズムがあれば、ここに実装していきます。 使い方 func main() { var dataset [][]float64 dataset = appe
Site Reliability Engineering – 10章 時系列データからの実践的なアラート - Fire Engine
こんにちは、つるべーです。 先日、福岡のインフラ界隈のエンジニアの方々がやっているSRE本の輪読会に参加し、発表をさせていただいたので、その時の内容をまとめます。 私は、10章の「時系列データからの実践的なアラート」を担当させてもらいました。 はじめに なぜ「時系列データからの実践的なアラート」が必要かを考えてみた。 Webサービスの大規模化や複雑化に伴い、サーバ台数の増加やシステム構成の複雑化が進んだことで、サーバのメトリクス等の情報を高解像度かつ長期間保持したいという要望が高まっている。また、サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいといったシーンも増え、時系列データベースに溜め込んだデータを用いた柔軟なアラーティングの需要が高まっているのではないだろうか。 概要 10章ではBorgmonと呼ばれるGoogleの内部システムについての話が中心だが、「アラ
ペパカレのインフラ研修を修了した - Fire Engine
どうもつるべーです。 私は2018年3月1日から、GMOペパボ本社にてペパボカレッジ（通称ペパカレ）のインフラ研修を受けており、4月6日に無事修了することができました！ 今回は研修で学んだことやこれからやりたいことなどを書いていきます。 以前ペパボへの転職エントリーも書いたので、よければ読んでください！ blog.tsurubee.tech ペパカレって？ ペパカレとは第二新卒エンジニア向け研修のことで、中途で入ってもみっちり研修を受けられます。 私はペパカレ6期生で、これまでWebアプリケーションエンジニアとモバイルアプリケーションエンジニアの採用があったみたいですが、インフラエンジニアのペパカレは今回が初めてだったようです。 ペパボカレッジについては詳しく知りたい方は下の記事を見てください！ www.wantedly.com やったこと 作業環境ハンズオン zshの導入 tmuxの導入
消防士を辞めて1年2ヶ月…GMOペパボのインフラエンジニアになった - Fire Engine
2018年2月1日にGMOペパボ株式会社に入社しました！ 消防士を辞めてエンジニアに転職してからの1年2ヶ月は福岡のシステム開発会社で機械学習などのデータサイエンスの分野に取り組んでいましたが、ペパボにはインフラエンジニアとして入社しました。今回の記事は、いわゆる転職エントリというやつです！転職の理由などを振り返っていきます！ 消防士からエンジニアへの転職については下の記事にまとめてます。 blog.tsurubee.tech なぜインフラエンジニアになったのか 私はこれまでデータサイエンスの分野に取り組んできたため、「機械学習エンジニア」や「データサイエンティスト」といった道もあったのですが、インフラエンジニアになりました。その理由を書いていきます。 データサイエンスの分野は、機械学習のアルゴリズムへの理解や、それらをプログラムに落とす力はもちろんのこと、それに加えて対象となるドメイン（
消防士からエンジニアに転職した話 - Fire Engine
私は2016年10月まで消防士の仕事をしていて、2016年11月からITエンジニアに転職しました。学生時代の専攻も情報系とは全く関係なく、プログラミングに初めて触れたのが2016年の1月からで、勉強を始めて約10ヶ月で転職に至りました。今回は、そんな少し変わった経歴を歩んでいる私が、なぜ消防士を辞めてエンジニアに転職したか、ゼロからプログラミングの勉強を始めて転職するまでの道のりなどを書いていきたいと思います。 目次 自己紹介 なぜ転職したのか 消防士という仕事 仕事の位置付け すべての経験をプラスにする 転職活動について ゼロからプログラミングを始めて転職するまでの道のり 勉強したこと モチベーションを保つために 今後について 自己紹介 私は化学の研究者→消防士→ITエンジニアと異色の経歴を歩んでいる20代後半の男です。 学生時代は、大学・大学院で化学を専攻し、博士課程まで進学しました。
異常検知ライブラリを作ってみた - Fire Engine
今回の記事は、前職消防士でゼロからプログラミングを始めた超未熟者の私が、異常検知ライブラリを作った話です。 なぜ作ったか マインド的背景 消防士を辞めてエンジニアに転職してから1年、いろんな技術に触れました。TensorFlow、scikit-learn、Dockerなどなど、必死になって使い方を覚えました。しかしだんだん、「これ、コマンド覚えてるだけで自分に何も技術身についてなくない？」という疑問や焦りが湧いてきて、自分は便利なツールを使いこなせるようになりたいんじゃなくて、いつの日かみんなが使って便利なツールを作る側になりたいんだ、ということに気づきました。そのような思いから今回初めてライブラリを作り、公開してみました。 データサイエンス的背景 世の中は時系列データで溢れています。ビジネスの場において、データの何かしらの変化の兆候を捉えて、いち早く意思決定をしたいという場面がよくありま
消防士からエンジニアに転職して1年が経った - Fire Engine
消防士として働いていた私がゼロからプログラミングを始めて、ITエンジニアに転職してから1年が経ちました。今回は、1年間エンジニアとして働いた今の率直な思いと、1年の振り返りをしていこうと思います。 転職してどうだったか 私はエンジニアという仕事は自分に合っているし、転職して本当によかったと思っています。しかしそれは、すべての人に「ITエンジニアっていいよ！」って勧められるというわけではなく、当たり前のことですが、合う・合わないがあると思います。 私が思うエンジニアの仕事が合う人の特徴は「学ぶことが好きだ」ということに尽きると思っています。正直、エンジニアとして1年間働いて、未経験でもそこそこいけるなっという感覚の方が強かったです。それは、目の前の業務にだけ集中し、業務で必要な技術だけを追えばなんとか仕事はこなせるようになるからです。しかし、そのような場合は大抵、業務で使うフレームワークやラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
