トレタの大規模バックエンドを移行するまでの道のりと舞台裏

Transcript

1. トレタの大規模バックエンドを移行するまでの道のり と舞台裏 プロダクト開発におけるAWS活用のいろは 株式会社トレタ
2. 自己紹介 名前：柳楽瑛 入社：2018年11月 部署：プロダクト開発部SREチームに所属 領域：AWS、GCPなどクラウドサービス全般 担当：トレタのほぼ全てのサービス 　　@_windupbird_
3. 目次 - トレタのサービスと移行前の構成 - これまでの課題 - どのように解決したか？ - 移行後の構成 - 今後の課題 - まとめ
4. トレタのサービスと移行前の構成
5. トレタのサービスと移行対象 サービス群 構成: API + 複数のサービス 特性: APIが止まると他のサービス 　　 にも影響が波及する 移行対象: API
6. トレタのバックエンド API移行前の構成 NW: Public Subnet 構成: ALB + EC2 + AutoScaling API: Nginx + Unicorn 非同期処理: Sidekiq ログ収集: Fluentd
7. トレタのバックエンド API移行前のデプロイ アプリケーションのデプロイ 　CI: CircleCI 　CD: CircleCI 　Gem: Capistrano
8. これまでの課題
9. これまでの課題 課題: 長期運用 EC2レイヤー 　例:　メンテナンス（イベント） 　例:　ステータスチェック OSレイヤー 　例： OSのEOL対応 　例:　プロセスの起動設定 その他 　EC2のイメージにすべて同梱されている
10. これまでの課題 課題：開発スピード（イメージ作成） AMI の作成時間 　Packer: 30分以上 修正 　小さな修正も都度 　待ち時間が発生
11. これまでの課題 課題：開発スピード（イメージのデプロイ） Terraform 手動実行 　AMIの差し替え 　B/Gデプロイ
12. これまでの課題 課題：開発スピード（イメージのデプロイ） Terraform 手動実行 　AMIの差し替え 　B/Gデプロイ
13. これまでの課題 課題：開発スピード（イメージのデプロイ） Terraform 手動実行 　AMIの差し替え 　B/Gデプロイ 　staging/procuction 計４回の terraform apply ...
14. これまでの課題 課題：設定ファイル・Secret管理 設定ファイル（Packer管理） 　テンプレート+変数 　例: unicorn.rb Secret（Packer管理） 　暗号化してGithubに保存 　Packer Build時に複合＆埋め込み 　例: database.yml チーム間で作業の依存関係 　アプリチームからSREチームに依頼 設定待ちの状態が発生 　　packer build + terraform apply 　　staging + production
15. これまでの課題 課題：セキュリティ Public Subnet 　すべて Public Subnet に配置 　Session Manager 導入以前は ssh 接続していた ssh 接続 　CircleCI経由でデプロイ 　Security Group 22番ポート開放 　ssh 秘密鍵の管理
16. どのように解決したか？
17. どのように解決したか？ 長期運用 EC2レイヤー 　コンテナの採用 　プラットフォームはECS 　FargateでEC2の管理から解放 OSレイヤー 　UbuntuなどホストOSの管理不要 その他 　すべてEC2同梱 => 各コンテナに分離 　
18. どのように解決したか？ 開発スピード（イメージ作成） イメージの作成時間 　CodeBuild 　　docker build: 2分 素早い修正が可能に
19. どのように解決したか？ 開発スピード（イメージのデプロイ） CodePipelineの採用 　イメージ作成 　タスク定義のイメージIDの差し替え 　B/Gデプロイ
20. どのように解決したか？ 設定ファイル・Secret管理 設定ファイル 　アプリケーションのレポジトリ管理に Secret 　Parameter Store 　例: database 接続情報 環境差分（staging/production） 　コンテナの環境変数で吸収 設定待ち、チーム間の依存関係が解消
21. どのように解決したか？ セキュリティ Private Subnet 　Private Subnet にコンテナ配置 　Session Manager も廃止 ssh 接続が不要 　CodePipeline経由でデプロイ 　AWS内で完結（22番ポート開放が不要） 　ssh 秘密鍵の管理が不要に
22. 移行後の構成
23. トレタのバックエンド API移行後の構成 構成: ALB + Container + AutoScaling プラットフォーム: ECS on Fargate NW: Private Subnet API: Nginx + Unicorn 非同期処理: Sidekiq ログ収集: Fluent Bit
24. トレタのバックエンド API移行後のデプロイ アプリケーションのデプロイ 　CI: CircleCI 　CD: CodePipeline 　Gem: Capistrano
25. 今後の課題
26. 今後の課題 Log の Aggregator 課題 　EC2 の利用とメンテナンス 　fluentd バージョン古い どうする？ 　kinesis + lambda とか？
27. 今後の課題 コンテナセキュリティ イメージ脆弱性スキャン 　ECRイメージスキャン、Trivy etc… 　Pipeline への組み込み 　スキャン後のアクションなど運用も課題 信頼できるベースイメージの利用
28. 今後の課題 API以外のサブシステム 一部ECS/EKSでホストしているが、 古いサービスはEC2を利用している （Herokuもいる） 最終的にはECS/EKSに統一したい
29. まとめ
30. まとめ ECS on Fargate へ移行できた 　開発スピードの向上 　技術的負債の返却 　将来的なトイルの撲滅 　DX（Developper Experience）の向上 まだまだ改善の余地がある 　脆弱性対策 　サブシステムのコンテナ化 　周辺システムの改善 　マネージドサービスへの移行
31. 最後に エンジニア採用してます!! SRE フロントエンド サーバーサイド Clojureエンジニア　etc... https://corp.toreta.in/recruit/engineer/
32. ありがとうございました