wwwave'sTechblog |ウェイブのエンジニアブログ

株式会社ウェイブのエンジニアによるテックブログです。会社の話や Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。

株式会社ウェイブの人事部ブログです。社内の雰囲気やイベント、福利厚生などについてお伝えいたします!

株式会社ウェイブのエンジニアブログです。 エンジニアの目線から会社の話や技術的な話をしていきます。

Sloth を用いた Grafana での Error Budget 可視化(お試し編)

執筆者:シラト

今回のお話

Prometheus SLO generator である Sloth海外向けコミック配信サービス「Coolmic」で使用してみましたのでご紹介いたします!
Prometheus と Grafana の知識がある方が対象になりますが、ご了承ください。。。

Sloth とは?

Prometheus SLO generator と謳っているように、Prometheus での SLO 管理を容易にする OSS です。
以下の手順だけであっという間に Prometheus で SLO 監視を始めることができます。

① OpenSLO に準拠した SLO 監視用の yaml ファイル作成
② Sloth のコマンド実行
③ Prometheus で SLO が監視できるように yaml ファイル出力

OpenSLO と聞き慣れないワードが出てきましたが何でしょうか?

OpenSLO とは?

Infrastructure as Code が当たり前の時代になりましたが、SLO as Code も当たり前の時代になりそうです。
OpenSLO とは、SLO の定義仕様をオープンにして、SLO の監視をベンダーに囚われないようにすることが目的みたいです。
今後、OpenSLO 対応した OSS, SaaSベンダー が増加しそうですね。

Sloth お試し

兎にも角にも実際に動作確認しました。

① yaml ファイル作成

ドキュメントに記載されている yaml ファイルを参考に作成しました。
今回は、Coolmic の以下の SLI を監視してみました。

SLI SLO
Emailログイン処理の成功割合 99.9%

サーバーサイドは Ruby on Rails を採用しており、prometheus-client でメトリクスを取得しております。 SLIを以下のように定義しました。

sli:
  events:
    error_query: sum(rate(http_server_requests_total{method="post", path="/user/sessions",kubernetes_namespace="production",code=~"(5..|4..)"}[{{.window}}]))
    total_query: sum(rate(http_server_requests_total{method="post", path="/user/sessions",kubernetes_namespace="production"}[{{.window}}]))

② Sloth インストール

ドキュメント 通りにインストールします。

$ docker pull ghcr.io/slok/sloth

③ sloth generate コマンド実行

①で作成した yaml ファイルのディレクトリを volume mount して、コンテナ内部でコマンド実行しました。
膨大な行数のyamlファイルが出力されるかと思います。

$ docker run -v /Users/hogehoge:/home ghcr.io/slok/sloth generate -i /home/error_rate/test.yaml > test.yaml

④ デプロイ

③で出力された yaml ファイルをデプロイして、Prometheus に反映されたか確認します。

⑤ Grafana ダッシュボード作成

なんと、Grafanaで可視化するための ダッシュボード が用意されておりました。
Import 用のIDをコピーして Grafana 側でダッシュボードを作成します。

⑥ Error Budget 確認

しばらくデータの蓄積を待って確認してみました。
確認する頃には、すでにError Budget枯渇しておりました😇
左下のAlert が All OK になっておりますが、これは嘘です。
Alertが多すぎるため一旦削除しているので、OK になっているだけです。。。

Alert rule について

一番の感動ポイントです🥺
なんと、Multiwindow, Multi-Burn-Rate Alerts を採用しているため、ノイズが少なくて理想的な条件になっております。

まとめ

今回はお試しとしてGrafanaでの可視化までやってみました!
少しでも参考になれば幸いです!

ギャップに刺激を受けた入社3か月のエンジニアにインタビュー

ウェイブTechブログとは?

ウェイブの仕事をエンジニア目線でお伝えするWebメディアです。毎月15日の更新を目指しています。肩の力を抜いて執筆し、ありのままのウェイブをお見せできるよう心がけています。

 


インタビュアー:広報  ホニャシマ

 ・ロングスリーパーの夜型
 ・特茶と豆乳、トマトジュースを常飲
 ・社内には言っていないが文章を書くのは苦手

インタビュイー: ComicFestaエンジニア ミウラ

・2022年2月入社
 ・酒とゲーム好きのインドア派(酒イベントのためなら外に出る)
 ・社内では酒好きで推してるが資格を持ってるのは日本茶


 

ー現在のお仕事について教えてください。

 

ミウラ

ComicFestaの機能追加や不具合の改修などComicFestaの基本開発業務全般を担当しています。ユーザー様に気持ちよく使っていただく、売上に貢献できる仕組みにするといったところで、常に何か課題はあるので、それを解決するっていうのをくるくるやってますね。

 

ーComicFestaではどんな技術を使っていますか?

 

ミウラ

プログラミング言語はRubyで、フレームワークはRuby on Rails、フロントエンドは一部Vue.jsも使ってます。データベースはPostgreSQLです。インフラはAWSで構成しています。開発環境としてはそんな感じだと思います。

 

ーウェイブに転職されて3カ月強。前職とのギャップに刺激を受けたと聞きました。前職はどんなお仕事だったんですか?

 

ミウラ

いわゆるSIerで請負受注型の開発をしていました。僕の場合は、顧客のやり取りから実開発までほぼほぼ一人でやってましたね。内容としては、基幹系や業務系システムが多かったです。前職の退職前のころは、eラーニングとか小規模・中小企業向けのwebサービス系を多く担当していました。

 

ーウェイブでどんな点にギャップを感じたんですか?

 

ミウラ

もちろん会社が違うのでいろいろあるんですけど、一番ギャップを感じたのはチームでの開発と進め方ですかね。前職は、ウォーターフォールってわけでもなかったんですけど、トップダウン型の開発でした。請負ですから納期が絶対。納品日までに開発・お客様の受け入れ検証をして、リリースするって感じでした。

ウェイブはスクラムでの開発で、1週間単位でスプリントを回しています。短いスパンでリリースや検証を行うので、そこはギャップでしたね。

 

ー時間をかけて納品するというのと、短いスパンでタスクをこなしていくという違いですか?

 

ミウラ

期間の問題というよりも仕事の仕方、感覚の部分だと思います。

請負の場合は、納期までに確実に納品(リリース)することが大事なんですよね。開発期間に余裕があろうとなかろうと納品できればいいんです。納期中に確実に納品することを考えると何かあったときのバッファも必要ですし、逆に何もないと追われるような気持ちで開発してやっと納品ということになる。

もし、ウェイブのスプリント(1週間)でバッファを持ったら進まないですよね。合わない。結果、余力を想定しない形で取り組むことになります。全力でやった結果、タスクというか作りたかったものが作れなくても、それはそれでいい。1週間でやろうと思ったけどダメだった。この方法はダメだってわかったことが成功なんだってよく言われます。

前職とウェイブで納品意識というか、作る・リリース・検証するってことに考え方の違いがあるなと感じました。

 

ーその違いに刺激を受けたんですね。

 

ミウラ

そのスピード感で仕事をするから、チームの型みたいなのも違いますしね。前職がトップダウン型だったって話をしましたけど、チーム内でそれぞれが違うことをしているので、ある意味では属人化してるんです。自分の担当の部分を納期までに完成させれば良いので。

スクラムでの開発だと、今のタスクが終わったらどの機能とか問わず次のタスクをやるって感じで進みます。なので、みんなある程度は全体のことをわかってなきゃいけないんですよ。広く仕様を理解していて全体を見渡さなければいけないので、学ぶことが多いなと思いました。そもそもチームでの開発経験が乏しいので、この体制自体も刺激になっています。

 

ーなにか経験とかノウハウみたいなものが蓄積しやすく、挑戦の多い環境なのかなぁって気がしました。

 

ミウラ

そうですね。ウェイブではコードレビューなんかもするんですけど、レビューしてもらって「この辺こう書いたほうがいいよ」みたいな自分の知らない書き方を教えてもらったり、自分では気づかないところを指摘してもらえると勉強になるし、ノウハウがたまりますよね。実際それで結構早くいろんなことが覚られたと思ってます。

 

ーこれからウェイブに入りたいとか入ってもいいなぁってエンジニアの方にアドバイスはありますか?

 

ミウラ

「自分はこれしかできない」って決めつけずに、何でもやるって心意気で入ったほうがいいですね。スクラムは、みんながある程度浅く広くできて、かつ専門分野を持ってていいよねって思考です。「私はこのインフラ周りしかできません」とか、「この領域しかできません」って閉じちゃうとやっていくのが難しいかなと思います。

逆にやってなかったことに挑戦していったら、刺激がいっぱいで楽しいです。わからないときは「あの時どうしたんですか」とか「いい案があればよろしくお願いします」みたいな感じで周りとコミュニケーションを取りながら、今までにない方法とか価値観が学べると思います。

 

ウェイブではともにチャレンジしてくれるエンジニアを募集しています。
現在の募集職種はこちらをご覧ください。

recruit.wwwave.jp

トップに戻る