はじめに

先日、JAWS-UG SRE支部で「AWSでゆるSRE！LT大会」というLT大会が開催されました

connpassページに記載されている通り、ゆる〜くSREのことを話しましょう！といった趣旨のLT大会になっています

すでにAWSでガンガンSREやっている方も、これってSREに近いかも？という方も老若男女問わず、事例や技術ナレッジをショートプレゼン方式でゆるく共有しあいましょう。

オフライン限定ということで、なるべく形に残しておきたいと思ったので参加レポートを書きました！

小規模組織において、これから一緒にSREを考える仲間を増やすために実践したこと

登壇者：株式会社スカラパートナーズなむらさん

小規模組織でのインフラ構築・運用のつらみ
- インフラ担当が一人で複数プロジェクトを掛け持ち
  - 経験があるとさらに任される
  - そのままサービスがローンチ
  - 運用業務がスタート、さらなる負荷がかかる
  - 以降、上記の繰り返し
    - トイルがどんどん降りかかる悲劇。。。
助けてもらうには？
- 助けてもらう練習をする！！
  - 周囲からすると「助けたいけど何したらいいかわらない」から
- 具体的には、インフラも「チーム開発」をするという選択をとった
  - IaCの導入に加えて、CI/CDパイプラインも取り込む
    - CDK Pipelinesを導入
  - cdk diffの結果を確認してプルリクにくっつける、そのままレビューしてもらう
    - 構築を一部頼めるようになった
  - 事故防止のために、diffはできるけどdeployはできない権限設定を実施した
    - bootstrapが終わったら権限を切り替える運用をしている
質問
- 権限の切り替えは手作業？
  - Yes
- 今後人数が増えた時の展望はある？
  - ひとまずは安全性を重視しているので、そこまでは考えていない
  - 開発者とCI/CDを回せることを、まずは意識している

EC2 AutoScalingでスケーリングポリシー設定を失敗してうまくスケーリングされなかった件

登壇者：日本アイ・ビー・エム手嶋達也さん

構成と要件
- シンプルなよくあるAutoScalingの構成
  - ASグループ内の平均CPU利用率、サーバー個別のメモリ使用率を閾値に設定
- 突然アラート発生！！アラートが止まらない！！
原因
- 起動と停止を繰り返していた。。。
- CPU利用率が急上昇、一方でメモリは定常だった
  - CPU利用率を見てスケールアウト！！
  - いや、メモリは大丈夫だからスケールイン！！
  - 以降、上記の繰り返し。。。
解決方法
- 複合条件のポリシーが作れない。。。
- 解決策その１：いっそのことLambdaで頑張る！！
  - Lambdaでメトリクスを取得して抽出、スケールアウトさせる
- 解決策その２：CWアラームの複合アラームを使用する
  - or条件を書いてASの条件を設定できる
そもそもCPUとメモリの複合条件って必要？
- メモリが上昇する場合＝メモリリークを起こしている可能性が高いのでは？
- インスタンスの再起動やスペック選定のし直しなどが大善手の可能性がある

ALBのアクセスログをAthenaで分析してSLOをゆるく決める

登壇者：ENECHANGE株式会社岩本隆史さん

「SLO決められない」問題
- SLI、SLIがスムーズに決められない問題はよく聞く
- まずはAthenaで分析してみることをお勧めする
可用性分析クエリ
- 一回クエリを作成すれば、繰り返し使用できる
- ただ、GETばかり出てきてつまらない。。。
  - POSTに絞って再実行してみると良い
  - でも「GETばっかりじゃん、ちぇっ」って気分を最初は味わいたいw
- 一番リクエストが多いエンドポイント＝クリティカルジャーニーと決めてしまう！
- レイテンシ分析クエリも作成しておく
  - 結果を元にレイテンシSLOもゆるっと設定してしまう
- 以上、数分で決めることができる！！
  - ゆるすぎるかもしれないが、決められないよりはまし
注意
- クエリ実行にはログテーブルの作成を行う必要がある
  - 作り方は公式ドキュメントに記載されているので、実装も難しくはない
SLO、ゆるっと決めてしまってもいいじゃないか！！
- コピペ用クエリも資料中に用意したので、ぜひ活用してください
質問
- 定期的な見直しは？
  - Lambda、CWアラームを仕込んでいるので、その出力結果を参考に見直ししている
  - 必要に応じて見直しをしているような感じ
  - エラーバジェットもゆる〜く実施している
- SLOの値をチェックする方法は？
  - 結果をslackに飛ばしているので、最初のチェックはslack
  - アプリケーション開発チームが各々ダッシュボード見るような感じ

オンコールよもやま話

登壇者：ウォンテッドリー株式会社白鳥昇治さん

ウォンテッドリーのオンコール体制
- EKS上でk8sを動かしてインフラ基盤を構築
  - 各プロダクトチームに対して、インフラチームからインフラ基盤を提供している
- オンコール
  - 休日夜間はPagerDutyで電話が飛ぶように設定
    - 休日夜間帯の障害は、外的影響によるものがほとんど
  - 平日日中に障害が起こったら人がワラワラ集まってくる
    - インシデントコマンダーが人員整理する
    - 平日日中の障害は、リリース影響によるものがほとんど
  - 余計なオンコールを無くすために、不要なアラートを整理した
    - slackのチャネルを重要度に基づいて分割
アラートの通知フロー
- 各リソース　→　DataDog or NweRelic →　PagerDutyにトリガー
思い切って減らしたアラート
- DBのディスク容量、CPU利用率
- k8s Podのスケール上限
- AWS Service Status
  - 提供しているサービスそのものが落ちるわけではない
  - X見た方がサービス障害に気づきやすいw
- 海外からの死活監視
  - サービス提供してる国のみに絞った
まとめ
- AWSサービスの弾力性が上がっているので、勝手に直るものに対してアラート設定する必要はないと感じた
質問
- これから体制を組む状態だが、休日夜間出動することになったらメンバーをどうやって賄っている？
  - インフラチームが交代で夜間いるようにしている
  - 出動があってもなくても、待機手当を出している
- アラートを減らしすぎちゃった。。。ということはあった？
  - 元々多すぎたので、今のところはない
  - ただ、CPU100%のアラートは様子見して復活させるかもしれない

Security Hubは俺の姑

登壇者：株式会社Gunosy 山口隆史さん

はじめに
- Security HUbのネタセッションです
  - でも、あるあるを元にしたネタセッションなので共感してもらえると思っています
- 付き合い方を考えてみよう、という目的で話す
  - 「嫁」ではなく「姑」なので！
Security Hubについて
- AWSのリソースコンフィグのチェック、イベントの集約などを実施
- 外部ツールとの統合も可能
- 修復アクションもある
  - 細かいことに気づく、ご近所付き合いが上手で情報通、お世話上手なスーパー姑さん
困ること
- チェックが細かい
  - 「ここちょっと、埃残ってるよ」みたいな指摘が多め
- お金のことをあまり気にしてくれない
  - 「CloudTrail追跡をCW Logsに全部流そう！」
    - 言ってることはわかる、でもやったら課金爆発してしまう！！
    - ご利用は計画的に
- こっちの事情を気にせずに色々言ってくる
  - 「物理MFA推奨！」
    - 言ってることはわかる、でも運用の都合があるのよ。。。
  - その他、組織の事情に合わないことを色々言ってくる
- 集めた情報を整理して伝えてくれない
  - Security Hubはそのままダッシュボードにはならない、別途作ろう
- 時々お願いしたことを忘れる
  - サービスアップデート時のバグで例外処理が外れてたり。。。
    - 例外にした「理由」をドキュメントにしておきましょう
まとめ
- 程よい距離感で姑さん（Security Hub）と付き合いましょう！
質問
- アラートの重要度は通知してる？
  - 通知はしてない、つど画面を確認している
  - 変なものを引っ掛けてくるので、Security Hubで通知はさせてない

クォータ到達を未然に察知 – AWS Service Quotas を自動でモニタリングしてみた話

登壇者：株式会社X-Tech5 菊池宣明さん

Service Quotasについて
- AWSのサービス上限の確認、緩和申請
運用あるある
- 未然に緩和申請を防げない
- 実績がないと緩和できない
- クオーター到達要因を調べて未然に申請を防ぎたい！
モニタリングの仕組み
- Lambdaを定期実行してクオーターの情報を取得
  - Service QuotasのAPI、CWのAPI、それぞれで取得できる値が異なる
  - クオーターの利用率はデフォルトでコンソール画面に表示されてないので注意
- DataDogに発砲してslackに連携
改善点
- スロットリングを防ぎたい
質問
- ログから文字列をどうやって抽出している？
  - JSON形式でログを出力できれば、DataDogの機能を使用してJSONから抽出できる

App Runner実践

登壇者：株式会社dotD 伊藤明彦さん

App Runnerとは
- コンテナ、コードを即デプロイできる
- インフラのチューニングもある程度は可能
IaCとの組み合わせ
- アプリとインフラのライフサイクルをきれいにしたい
  - しかし、お互いのリソースの間の依存関係があるためうまくいかない
- 役割分担も大変
  - 「インフラ用意したよ！」 → 「いやRoute53もインフラじゃないの？」的はことがおこりがち
CloudFrontとの組み合わせ
- ディストリビューションの後ろでS3とAppRunnerをぶら下げたい
  - App Runnerのデフォルトエンドポイントに接続できちゃう問題が発生
- 解決策
  - CFでカスタムヘッダー持たせて、そのヘッダーだけ許可する
    - アプリ側の協力も必要。。。
  - WAFのIP制限でCFのIPだけを許可する
    - でもめんどくさい。。。
- CloudFrontのリスエストサイズ上限に引っかかることがある
  - AppRunnerのデフォルトドメインを使用 or Lambdaにオフロードする
コンテナ起動時のトラブル
- 起動に失敗するとロールバックされる問題
  - 停止中はさわれなくなる。。。
- 初回起動時にNW接続できない問題
  - 連鎖的にトラブルが波及
  - 停止状態のまま設定変更できず、永久に起動できなくなるなんてことも。。。
- 対策
  - エクスポネンシャルバックオフを仕込んでおく
  - 外部接続なしモードの使用
質問
- WAFは直接アタッチできる？
  - できるが、CloudFrontとAppRunnerで重複してWAFアタッチするのは面倒なので、CloudFrontにアタッチしている
- デバック、コンソールでやりにくいとかはある？
  - 特にないが、App Runnerのデプロイが遅いのが注意かも
- 使い所が難しいような気がするが、ユースケースはどこにある？
  - 単品で動かすWebアプリなら十分
  - App Runnerは動いてる間課金されるので、少しレスポンスが早い（かも）
    - 料金も少し安い（らしい）
  - サイドカー使わなくて良い（コンテナ一つで良い）ならApp Runnerで良いかも

【参加レポート】JAWS-UG SRE支部 #7 AWSでゆるSRE！LT大会