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

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

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

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

SRE で AWS Well-Architected 輪読会を実施しました!

執筆者:SRE シラト
・最近、初めて野球観戦に行って大興奮しました。
・今のところ推しは、ソフトバンク 東浜。
・プロ野球チップスで当たるといいな。

今回のお話

SRE で AWS Well-Architected(以下、W/A)の輪読会を実施しました。
感想や実際にW/Aをどう活用していくべきかについて話し合いましたのでご紹介いたします!
※ SREは現在3名体制

実施背景

SRE の Roadmap に『AWS のベストプラクティス実装』を組み込みました。
W/A は、SRE全体で共通認識にした方が良さそうと判断し、輪読会の実施に至りました。

詳細

項目 詳細
頻度 1, 2週間ごとに3時間まとめて確保
ペース 一度に一柱
事前準備 一読(1時間前後)
進め方 ベストプラクティス一つにつき10分のペースでディスカッション。
課題意識があること、よくわからなかったこと等なんでもOK!

感想

1. ポジティブな意見

・可視化の重要性を再確認できた。
・課題意識のすり合わせができた。
・すぐにアクションに結びつく項目があった。
例)スクラム、NSM、Cfn gitops導入等
・最初の方に単語の意味をすり合わせしてよかった。
例) ワークロード = ComicFesta, Coolmic等プロジェクト単位

2. その他の意見

・一周だけでは、断片的な内容しか覚えていない。
・一人で読むのは辛いので、チームで苦労を共にするのがおすすめ。
・やることが多すぎてどこから手を付けるべきか判断が難しい。
・そもそもすべて対応することが現実的なのだろうか。
・難解な記述があり、原文の方がわかりやすい場合がある。

誤解していたこと

輪読会を終えて、個人的に誤解していたことが2点ありました。

1. SRE だけが W/A を理解していればOK

ビジネスサイドなど他チームと話し合う必要性のある項目が多数あります。

例えば、 運用上の優秀性 の『OPS 8: ワークロードの正常性をどのように把握しますか?』には、KPIの異常検知の話が出てきます。
異常検知するとしても、ビジネスサイドと正常を定義しないといけませんよね。

2. チェックリストすべて満たすことがゴール

一番大きな誤解でした。
AWS Well-Architectedの活用方法(2019) では以下の通りに言及されております。

Q:全項目ベストプラクティスに則っていないとダメなのか?
A:ベストプラクティスを理解した上で、皆様が「(ビジネス的な)判断をする」ことが重要

リスクや改善点の"顕在化"が重要となり、ビジネス判断でどこまで対応するかを話し合うことが大切とのことでした。

例えば、『Multi-AZの方が良いらしい』という理由で、Multi-AZにするのはNG。
ビジネスサイドにリスクを噛み砕いて説明した上で、判断できるといいのかなーと個人的には思っております。

アクション

まずは、『SRE が W/A の項目を噛み砕いて説明できるようにする』ことを目標にアクションする予定です。
一読だけでは、自信を持って自分の言葉で説明することはできませんでした。

プロジェクト全体を巻き込むには、以下の説明ができるようになる必要があると考えております。
・対応状況
・対応しないことのリスク
・対応するためにする具体的なアクション

まとめ

今回は、SREでの取り組みについてご紹介でした!
W/A をコミュニケーションツールとして、活用できるよう取り組んでいきます!

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での可視化までやってみました!
少しでも参考になれば幸いです!

トップに戻る