以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2024/07/02/204920より取得しました。
開発チームとともに進めるインフラセキュリティの継続的な改善
アンドパッドの開発体制
- マルチプロダクト
- 開発チームがいくつか
- SREチームは横断で見ている
- メインはAWSで一部GCP(Firebaseとか)
- k8sをEKSでECS on Fargateも
- 歴史の長いモノリスとマイクロサービス
- 昔はrubyだったが最近はgo
継続的なセキュリティ診断
- AWS Security Hub
- セキュリティベストプラクティスに基づいてチェックしてくれるサービス
- 定期的なセキュリティチェックはしてるが発見が送れるおそれ
- Security Hubで検知されるとSlackに通知されるように
- EventBridgeやSNSを組み合わせて
- StepFunctionSecurityHubのでステータス更新することで同じの何度も通知しないように
- チェックのルールは標準だと255件
- 導入して
- 開発初期でリスクに気づける
- 開発チームだけで自発的に完結はまだ難しい
- slackの通知きてるよってsreチームが教えてあげたり
- アップロードされたファイルをs3バケットへの追加時にスキャンしてる
- リプレース前はLambdaでやってた
- 使ってたOSSが開発終了
- Lambdaの実行コスト高い
- 同時実行数
- Antivirus for Amazon S3にリプレース
- 動かす環境の利用費とライセンス費がかかる
- S3にファイル置かれるとSNS topicに流れてSQSに流れてECS上で動くツールで処理実行
- コスト増の予兆検知するためのアラート
- 1日あたりの合計スキャンサイズの
- スキャン実行するECSタスク数
飲食店のインフラサービス “ダイニー” のトラブル対応のすべて
- Hiroaki KARASAWA (karszawa)さん dinii, inc.
飲食のインフラ
大規模障害訓練
- 心構え
- 年に1回は大規模障害が起きていた
- 日夜さまざまな障害が起きている
- →落ちる前提で向き合う必要がある
- エンジニア/ユーザサポート/営業の全メンバーで訓練実施
- 役割
- インシデントオーナー
- 対外発信
- 顧客対応
- 飲食店役
- 振り返り
- 項目ごとにオーナーあげて改善していく
- コストをかけてやってるからアクションにつなげる
- 記憶が薄れないように何回もやる
- SLA
- Uptime99.95%
- 月21.6min
- 21分止まって飲食店が対応できるのか？
- ダウンタイムの体験設計をする
ユーザサポートとの連携
- システムアラートはエンジニア
- ユーザからの問い合わせはユーザサポート
WAFでどのリクエストがBlockされたのか、ログを集計してSlackで簡単に見れるようにした
AWS WAFのトイル削減
- AWS WAF
- WAFのブロックの通知が多い
- 問題ないアラートを毎回確認するのが大変
- Lambdaでブロックしたリクエストを通知するようにした
CodeBuild上でGitHub Actionsを動かしてDBマイグレーション効率化
DBのデータ移行
- 改善前
- 踏み台サーバが1つを共用
- 手動でやっていてオペミスが怖い-
- 改善案
- CodeBuildでGitHub Actionsを動かしてDBの操作をする
- GitHub Actionsは最低でも1分動かした分の課金がされる
- CodeBuildで動かした方が安そう
開発者が安心して実行可能なSQL実行基盤の取り組み
DBオペレーション
- 本番DBのデータを操作したい時
- 踏み台サーバから接続していた
- ADRソリューション
- Bytebase
- 承認プロセスを経て実施
- DB書き込みはツールから
ポストモーテム運用を導入した話
ポストモーテム運用
- チームメンバーの増減があってナレッジの共有が急務になった
- ポストモーテム導入
- 知識のサイロ化を解消
- 体系化されたドキュメントを残す
- アラートごとに記載
- 第三者に伝わるように書く
- 週に一回振り返り
- アラート起きてSlackに通知が来ると自動でGitHubにissue起票させる
以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2024/07/02/204920より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14
