好きです AWS 〜 移行を通した AWS とのつきあいかた

AWS LT 資料
https://connpass.com/event/143424/

Transcript

1. 好きです 移⾏を通した とのつきあいかた ウーマンメディア技術 伊藤 聡介
4. 移⾏しないといけない…
5. Corporate data center: OpenStack Web Front instance group Web Users App Users Corporate data center Batch API instance group Batch Solr memcache (twemproxy) ※ 細かいのは省略してます
6. API サーバー フロントサーバー バッチサーバー ツールサーバー DB (MySQL) Solr Memcache リバースプロキシやロードバランサーとか
7. インフラまわりは得意じゃない DB をぶっ壊したことがあります
8. oO( 気が重い )
9. わたしたちチーム から への移⾏ から AWS Elasticsearch Service への移⾏ による構成管理
10. とにかく に 慣れないといけない
11. とりあえずポチポチする AWS の便利さを存分に味わうのが⼤事 好きにぶっ壊せる楽しさ AWS のハンズオンで体系的に学べる
12. なんとなく 慣れてきて 知ったかぶりできる 感じになってきた
13. やるべきことを 考える
14. サブネットの切り⽅ 開発環境どうするか 踏み台とかセキュリティとかどうするか DB の移⾏⼿順はどうするか 構成管理どうするか
15. バッチで⽣成したファイルを 各サーバーに配布してる
16. S3 と Redis で 管理することにした 他サービスから PUT してもらえる
17. Elasticsearch に どうデータを⼊れるか
18. Glue や Kinesis Firehose が 候補に挙がる
19. 結局 Python のバッチで バルクで⼊れた やってみたら 別に問題なかった
20. 構成管理をどうするか
21. CloudFormation か Terraform 今回は Terraform を使った
22. で書く
23. 構成
24. depends ➔ network middleware application operation
25. make で構築 $ make dev-plan DOCKER_SERVICE=terraform-application $ make dev-apply DOCKER_SERVICE=terraform-middleware
26. こんな構成になりました
27. VPC Availability Zone Availability Zone Web Front instance group Aurora S3 Redis Cache Elasticsearch Web Users App Users Corporate data center Batch API instance group Batch ※ Subnet とか リバースプロキシとか細かいものは省略してます
28. Terraform で スクラップ & ビルド やりやすくなった
29. 構成をチーム内外で 共有もできる
30. 実感として ポチポチは意外に忘れる
31. 実際、本番環境で S3 の VPC エンドポイント 作成し忘れてた
32. 結構いい感じ 独特の書き⽅とか 変更時の差分とか闇もある
33. 監視は CloudWatch が使える
35. 困ったこと DNS の切り替え → こわい → 荷重とかで徐々に移⾏する DB の切り替え → こわい → レプリケーションの切り替えは気をつける
36. できなかったこと コンテナ化して Fargate で動かす CodeDeploy でデプロイ⾃動化など
37. トライしやすい DevOps がやりやすくなる インフラまわりの忌避感が薄くなる マネージドサービスが多い チューニング的なことをしなくて済む
38. AWS の⽅々に相談できた Terraform で構成管理 & レビューできたのもよい ベストプラクティス & アンチパターンが⾒つかりやすい
39. インフラまわり得意でなくても やりやすくなった
40. == なにかわからないもの
41. != なにかわからないもの
42. == エンジニアの道具箱
43. 好きです