【レポート】SRE Lounge #11

SRE Lounge #11という勉強会に参加してきました。
今回はサイボウズさんのオフィスで開催でした。

eurekaのパフォーマンス定点観測会の取り組み紹介2019

eurekaでは「パフォーマンス定点観測会」と称してバックエンドエンジニアとSREが週次でメトリクスを確認し,システムの品質観測と改善を行っています. この会を2年間ほど継続する中で,溜まってきた知見を紹介します.

エウレカさんではパフォ会というMTGを毎週水曜日にやっているそうです。
パフォ会とはパフォーマンス定点観測会のことで、プロダクトの可用性、パフォーマンス向上を目的とした週次MTGで2年程継続しているそうです。(いい取り組みですね。)
毎週水曜日にやっている理由はサービスの特性(出会い系アプリ)上、土日にリクエストが増えるので水曜日にやれば先週の土日の状況がわかるのと月火の平日の状態も分かる、なにか問題があっても木金で対応できるからだそうです。内容は基本的にdatadogに集約していてパフォ会用のダッシュボードを見る感じだそうですが、DBだけはメトリクス対応していないためAWSAuroraのパフォーマンスインサイトを見ているということでした。

SLI/SLOもチェックしていて、SLIは総リクエストに対する500エラーの比率で99.95%以上をSLOと設定して継続して達成し続けているようです。また、ここでトイルの改善についても話し合っているということでした。

ここで気になった点としてAPIのエンドポイント毎じゃなくて全てのAPIの500エラー数/総リクエストだと例えば重要な決済のAPIが30%しか成功していないのに検索APIが100%、他のAPIも100%だったら結果的にSLOを達成してしまって重要な指標を見逃すのではないかという疑問があったので質問してみたのですが、そこは確かに認識していて今後の課題だと思っているということでした。

Cybozuにおける大規模インフラ基盤の移行プロジェクトManekiの紹介

Cybozuではインフラ基盤の移行プロジェクトManekiが最近動き出しました。 Kubernetesを利用したNeco基盤に移行するにあたり、 Manekiプロジェクトが目指すところ、現在わかっている課題などのお話をできればと思います。

サイボウズさんではサービスの特性上、検索機能の前提が全ドキュメントを検索したりする必要があるので、サイズが大きいと大変らしいのですが、企業単位でデータ量がまちまちで非常に大きなインデックスを持っていたり、逆にめっちゃ小さかったりするので、新しいシステムではサイズの大きさでシャードを分ける設計にしているそうです。

印象に残ったのはまだManekiはリリースしていないインフラ基盤で、ログの設計や監視についてもまだ未構築らしく、うちの会社だとリリース前のサービス構成を紹介するのはポリシー的にNGですが、サイボウズさんの度量の広さ的な自由さを感じました。

安定・安価な ECS auto scaling を目指して

ECS で Fargate を利用せずに auto scaling させる場合、1 つの ECS クラスタを 1 つの EC2 auto scaling group で管理し、EC2 auto scaling group の capacity を修正して ECS cluster を拡張・縮小させ、ECS service の desired count を修正してタスクの数を増減するのが一般的かと思います。 本発表では、auto scaling group を用いて auto scaling する場合に遭遇したトラブルとそれらの対処法について説明します。

ECSのオートスケーリングのお話でした。

なぜ今回Fargateを使わないのかというのはRI、スポットインスタンスと比べるとまだ高い、パフォーマンスも比較すると低く、タスクの起動が遅いという理由からだそうです。ただし、コスト以外については検証はしていなく、検証するリソースが足りないというのが課題だそうです。あとはログがAWSLOGSに限定されるので見づらいということでした。

まとめ

いろんな勉強会がありますけどSREという括りだとSLOとか監視とかオートスケーリングとか関心のあるトピックス、テーマの話が多いのでやっぱり勉強になることが多いなーと思いました。
個人的にはサイボウズさんのオフィス家から近いのでとても素敵だと思いました。
ビルも新しくて綺麗。

コメントを残す