自社WEBサービスのAWS活用と継続的改善 -入社４ヶ月目の視点-

Transcript

1. 自社WEBサービスのAWS活用と継続的改善
 〜入社４ヶ月目の視点〜

2. 前提
 本セッションの話す内容と資料について、下記をご留意ください。
 ❏ 2024年7月29日時点の情報であること
 
 ❏ 入社して4ヶ月の社員が話をすること

3. 自己紹介
 ❏ 株式会社グッドバトン
 
 ❏ 梅西　一秀（うめにし　かずひで）
 
 ❏ 2024年4月入社
 
 ❏ ３児の父親
 
 ❏ システム・サービス開発歴：21年（AWS歴：6年）
 

4. 会社紹介
 ❏ 会社名：株式会社グッドバトン
 ❏ 設立：2017年7月7日
 ❏ 事業内容
 ❏ 病児保育室の検索・予約サービス 
 ❏ 病児保育室の経営コンサルティング 
 

5. あずかるこちゃん 病児保育ネット予約サービス 

6. 開発環境
 ❏ インフラ：AWS、Line、SendGrid、Rollbar、Datadog、ImageFlux
 ❏ バックエンド：Ruby
 ❏ フロントエンド：TypeScript、React、(jQuery)
 ❏ データベース：Aurora(MySQL)、ElastiCache(Redis)
 ❏ バージョン管理：GitHub
 ❏ CI/CD：CircleCI
 ❏ ドキュメント：Notion、Figma、GoogleDrive
 ❏ チケット管理：Notion、GitHub
 ❏ コミュニケーション：Slack、Zoom、Discord

7. サービス構成

8. 改善できていること

9. 改善できていること（１／４）
 ※Amazon ECS に最適化された Linux AMI メタデータを取得する： https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html ❏ ECS on EC2 から ECS Fargate に移行
 ❏ EC2の管理コスト削減し、可用性を向上できた
 ❏ EC2のリソース管理がなくなり、最適化されている
 ❏ AMI交換含むパッチ適用の考慮(※)がなくなった

10. 改善できていること（２／４）
 ❏ デプロイが自動化できている
 ❏ DBスキーマ更新はDBマイグレーション機能を利用している
 ❏ データ洗い替えは Rakeタスク(※)で実施している
 ①ビルド・イメージをECRにプッシュ ②DBマイグレーション実行タスク起動 ③ホールド（追加） ④WEB・バッチのタスクをデプロイ ⑤Rakeタスクの実行 push trigger ※Rake は Make によく似た機能を持つ Ruby で書かれたシンプルなビルドツール 　https://docs.ruby-lang.org/ja/latest/library/rake.html より抜粋
11. 改善できていること（３／４）
 ❏ 不要なAWSの設定やリソースの変更・削除（１／２）
 ❏ ローカルからのRDSアクセスを、踏み台によるSSHポートフォワーディングから SSMのポートフォワーディングに変更
 引用：https://aws.amazon.com/jp/blogs/news/use-port-forwarding-in-aws-systems-manager-session-manager-to-connect-to-remote-hosts-jp/ # TASK_ID=3b72eca0146e45f9af3be8e2a6414075 TASK_ID=$(aws ecs list-tasks --cluster ${CLUSTER} \ --service ${SERVICE} | jq -r '.taskArns[0]' | awk -F'/' '{print $NF}') # CONTAINER_ID=3b72eca0146e45f9af3be8e2a6414075-3215599361 CONTAINER_ID=$(aws ecs describe-tasks \ --cluster ${CLUSTER} --task ${TASK_ID} \ jq -r --arg N ${CONTAINER_NAME} '.tasks[0].containers[] | select(.name == $N).runtimeId') # ポートフォワーディング接続 aws ssm start-session \ --target ecs:${CLUSTER}_${TASK_ID}_${CONTAINER_ID} \ --document-name AWS-StartPortForwardingSessionToRemoteHost \ --parameters '{"host":["'${DB_ENDPOINT}'"],"portNumber":["3306"], "localPortNumber":["'${DB_LOCAL_PORT}'"]}'
12. ❏ 不要なAWSの設定やリソースの変更・削除
 ❏ Cloud Watch Logs のサブスクリプション フィルター削除
 実行コストを無視できないよ 改善できていること（４／４）
 . . . ログ出力
13. 改善したいこと

14. 改善したいこと（１／５）
 ❏ バックエンドとフロントエンドの分離
 ❏ 運用・管理コストを削減できる
 ❏ メンテナンス性とパフォーマンスが向上できる

15. 改善したいこと（２／５）
 ❏ セキュリティを強化する
 ❏ Amazon GuardDuty Malware Protection for Amazon S3の導入検討
 S3 バケットにアップロードされた新しいオ ブジェクトにマルウェアがないか継続的 に評価し、見つかったマルウェアを隔離 または排除するためのアクションを実行 できます。Amazon GuardDuty Malware Protection は、Amazon Web Services (AWS) が開発した、業界をリードする複 数のサードパーティーマルウェアスキャ ンエンジンを使用して、Amazon S3 のス ケール、レイテンシー、耐障害性を低下 させることなくマルウェアを検出します
 引用元：https://aws.amazon.com/jp/blogs/news/introducing-amazon-guardduty-malware-protection-for-amazon-s3/
16. 改善したいこと（３／５）
 ❏ コストを最適化する
 ❏ S3の Intelligent-Tiering の設定
 ✓ ライフサイクル設定との比較や併用の検討したほうが良いかもしれない... 🤔
 引用元：https://aws.amazon.com/jp/s3/storage-classes/intelligent-tiering/
17. ❏ Auroraインスタンスクラスと下記パラメータ設定値の見直し
 ❏ WEBサーバー(Nginx)リクエスト最大数
 ❏ アプリサーバー(Puma)リクエスト最大数
 ❏ Railsのコネクションプーリング最大数
 ❏ Auroraのコネクション最大数
 改善したいこと（４／５）
 引用元：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html#AuroraMySQL.Managing.MaxConnections
18. ❏ S3バケットのプリフィックス設計を見直す
 ❏ 1prefixあたり以下の上限があり、超えると 503 エラーになる
 ❏ PUT/COPY/POST/DELETE：3,500 リクエスト/秒
 ❏ GET/HEAD：5,500 リクエスト/秒
 改善したいこと（５／５）
 引用元：https://pages.awscloud.com/rs/112-TZM-766/images/AWS-01_Storage_AWS_Summit_JP_2024.pdf 参考：https://repost.aws/ja/knowledge-center/http-5xx-errors-s3
19. まとめ
 ❏ 弊社とそのサービスを紹介
 
 ❏ サービスの改善していること・改善したいことを一部紹介
 
 ❏ 関連サービスや技術等で相談し合える仲間を探してます！

20. ご清聴ありがとうございました