目指せアーキテクチャマスター！#2 講師LT「私だったらこう作る」

講師としてLTをしてくださったGF君島さんのスライドです。

Transcript

1. 目指せAWSアーキテクチャ マスター！ #2 ~アーキテクチャ図持ち込み LT大会~
2. 自己紹介 • 氏名:君島 翔 • 株式会社ギークフィード • エンジニア/執行役員 • 2022- Japan AWS Top Engineer • 2022- AWS Ambassador • AWS Ambassador - Certification All-Star Award 初代の金ジャケを 持っています
3. 私だったらこう作る
4. Phase1 ビジネス背景: 普段はインフラエンジニアが毎朝9:00に出社して、朝一に30分くら いかけて前日の売上データをSQLで集計して、Excelで纏めて営業 担当者に報告していた。 さらに「手動だとたまに数値が間違っている」「インフラエンジニ アが休みだと報告が来ない」といった課題が出ており、完全自動化 したい。 ・売上データには機密データが入っている恐れが あるので、セキュリティ用件も考える必要がある。 ・自動化する予算があまりないのでコストは抑えたい。 ・売上データは、RDS (PostgreSQL) に格納されている。 ・処理時間は5分程度。 ・エラーが発生した場合は、すぐに再試行できるか、通知が来るようにしたい。 ・エラー通知：基本はメール通知だが、重大なエラー時のみ管理者にSlackしたい。
5. Phase2 Postgresのpg_cronに集計を 任せる。 日次実行のLambdaがRead DBとレポート出力程度に 軽量化できる メリ：各リソースの権限,処理は極小化 デメ：pg_cronがこけた場合の通知は 即座にはできない。 真面目にやるとエラー監視も考慮。 ただ、もともと担当者休みの日はでき ていなかったし、厳密さは要件をすり 合わせたい。 Metric Filter + Alarm
6. 別解 GitHub Actions＋ Self-hosted Runnerで 日次集計を行う。 メリ：運用/通知シンプル化 デメ：EC2コスト発生。 開始時刻はずれやすいかも。 GitHub障害に引っ張られる。 443とRDSのOutだけでOK。 ポーリングするから。 GitHub Secrets に認証情報も持っておく。