耐障害性向上・パフォーマンス改善・運用負荷軽減をどう実現する？事業を支えるSREのノウハウを共有 に参加しました。オンライン参加。簡単に所感をまとめます。
所感
「コスト最適化」「安定稼働」「アジリティ向上」 のための取り組みが聴けてよかったです。知らない単語とか出てきてちょっと話に追い付けないところもあったけど。
正直、昔は SRE = インフラエンジニア みたいな雑なイメージしか持ってなかったけど、ここ何年か SRE チームと一緒に仕事する機会が増えてからは自分にも「コスト最適化」「安定稼働」「アジリティ向上」の意識が芽生えるようになりました。たぶん。
SRE に限った話でもないけど、現状をしっかり把握して仮説を立てて検証するということと、ものごとを定量的に把握することが重要な気がします。
自分専用の使い捨て検証環境欲しい...。
以下、メモから抜粋。
アソビューSREで実施した各種最適化の視点について
- 性能限界を意識する
- Aurora
- 24xlarge
- 最大コネクション数 16000
- Aurora
- キャパシティプランニング
- 負荷テストで指標を定める
- どれくらいの負荷に耐えられるか
- どれくらいパフォーマンスが出せるか
- スペック/パフォーマンスの相関
- 限界値に対して必要なスペック/リソース
- Pod 負荷率
- Pod ごとの性能限界
- 秒間処理可能数
- スパイクを予測する
- 事前のトラフィック量からスパイクを予測する
- 安定稼働基準
- 5倍のスパイクに耐えられるように
- Pod 負荷率, CPU 利用率 20%以内
- 5倍のスパイクに耐えられるように
- Aurora Serverless v2
- 利用メモリが減る (CPU に依存する)
- HPA
- datadog メトリクス
- CircleCI
- ジョブが実行されるリージョンに近いところにビルドイメージを配置する
- オーバーヘッド削減
- 通信コスト削減
SRE初心者が急成長しているEV充電サービスの安定稼働にコミットした話
- OCPP
- リソース不足による障害
- スケールアウト
- バッチ実行頻度を下げる
- DB スケールアップ
- デプロイの際にCPU利用率が跳ねる
- 旧コンテナが落ちる際に一斉に接続断される
- WebSocket 再接続による負荷増
- 再接続が集中しない仕組み
- Exponential Backoff
- リトライによる再接続のタイミングを分散させる
- 線形デプロイ (CodeDeploy)
- Graceful Update (自前)
- CodeDeploy → EventBridge に通知
- Lambda で接続断
- 少しずつ置き換える
