ID:75411さん

## 使用技術 | 項目 | 使用技術 | | --- | --- | | バックエンド | PHP、Laravel | | フロントエンド | PHP、Laravel | | インフラ | AWS（ECS、RDS、Redis、ALB、WAF、CloudWatch、S3） | | データベース | PostgreSQL | | CI/CD | GitHub Actions | | テスト | PHPUnit、Playwright | | 開発環境 | Docker、GitHub | | コミュニケーション | Slack、DocBase | ### 役割 - 機能全般の設計、開発、構築、運用保守を担当 - フロントエンド、バックエンド、インフラを横断的に担当 ### 実装機能 - 問い合わせフォーム - 記事一覧・詳細表示 - CMS（記事管理システム） ### — 取り組み — ### **既存インフラのIaC化（Terraform）** - EC2 → ECS - 手動デプロイからCI/CD（github actions）を導入 - AutoScalingの設定を実施 - STGリリース後にE2Eテスト導入 ### サーバレス化 - Laravel → s3 + Cloudfront + Next.js - コスト・サイトメンテナンス工数削減 - チーム内で扱う技術統一（認知負荷削減） - Next.jsの学習コンテンツ

- 使用技術 | インフラ | AWS（ECS、RDS、Aurora、Redis、ALB、WAF、CloudWatch、S3, EventBridge、Config、Budgets、Lambda） | | --- | --- | | データベース | PostgreSQL、Mysql、Redis | | CICD | github actions、codepipline | | コミュニケーション | Slack、DocBase | - 役職 - Embedded SRE - 役割 - 他チームのSRE導入と改善 - サービスレベル目標 - 監視 - インシデント対応 - ポストモーテム - トイルの撲滅 ### — 取り組み — ### セキュリティ（事業部） - AWSセキュリティインシデントGameDayの参加 - セキュリティ勉強会の開催 - 予防的統制 - AWS Config（人的ミスの防止） - [required-tags](https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/required-tags.html) - [vpc-sg-open-only-to-authorized-ports](https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html) - AWS Inspecter - ECSデプロイ前の脆弱性スキャンの実施 - criticalがあった場合はデプロイ中止 - 発見的統制 - AWS Budgets - 不正利用の早期発見 - 不正なリソースの起動・高額なコスト請求 【なぜやったか・課題】 - インフラ設定ミスやサイバー攻撃によるセキュリティインシデントを未然に防ぐ必要があると考えた 【工夫】 - まずすぐに出来るところから設定した - オオカミアラートにならないように、チェックは最低限にした 【成果】 - 人的ミスがなくなった - 各チームがインフラコストに関して関心を持ってコストカットなどを独自で実施してくれるようになった - 各チームセキュリティの意識が高まった ### インフラコスト最適化 - Compute Savings Plans - EC2、ECS - RI - RDS、ErasticCache - 検証・開発環境の土日・平日夜間停止 - EC2、RDS - EventBridge Scheduler - ECS - EventBridge Rule、Lambda - S3コスト削減 - s3 Storage Lens 有効 - ストレージクラスの変更 - S3 標準　⇒ S3 Intelligent-Tiering - https://dev.classmethod.jp/articles/should_i_choice_s3_storage_class_2023/ - コストタグの整備とBudgets Reportとアラーム設定 - 狙い - コストの可視化（特定のサービスやリソースにかかる費用把握） - 不正利用の早期発見（マイニングなど） - タグ - Env : 環境名 - Service： サービス名 - DivisionCode : 部署名 - タグ設定漏れ防止 - Configルールの設定と非準拠時のアラーム設定 【なぜやったか・課題】 - インフラコストが年々コスト上昇している - インフラコスト削減ができていない 【工夫】 - 現状のコスト分析をした - どのチームがどれくらい使っているか？ - サービス規模やスペックに合っているサーバー・サービスを使っているか？ - タグを設定して、分析できるようにした - S3のストレージクラスの見直し 【成果】 - インフラコスト約800万削減 ### 他チームのRDSから**Aurora移行支援** - RDS for PostgreSQL → Aurora PostgreSQL - 移行方法 - [Aurora リードレプリカの使用](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html#AuroraPostgreSQL.Migrating.RDSPostgreSQL.Replica) - 移行理由 - パフォーマンスの向上 - 可用性・耐障害性の向上 ### 事業部のインフラ**Health イベント**の監視 - イベントの情報のslack通知 ### SRE活動の他チームの横展開 - 監視の整備（cloudwatch） - cloudwatch agentの設定 - アラートのslack通知（SNSとCahtbot） - 各種メトリクスのダッシュボードを作成 - ECS・RDS、ALB etc - CUJ・SLI・SLOの設定の支援 - エラーバジェットによる開発 ### 他チームのECS移行支援 IaCによる移行工数削減に成功 - terraform コードの配布 - terraform 使い方の教育とレビュー - ECS用のDockerFileの作成の支援 インフラ・CICD関連支援 - RDSメジャーバージョンアップ - 経験あり - B/G デプロイ - インプレースアップグレード - DMS - CICDの時間短縮 - Dockerイメージの脆弱診断をTrivy・Dockleを導入 - 脆弱診断をTrivy・DockleをECRスキャンに変更