awswakaran.tokyo #2 に参加して
AWS全然わからんのでこれに行く #awswakaran_tokyo https://t.co/Hme8OowZ9r
— ごましお (@halnique) September 25, 2019
こちらに行ってきました
第一回がやってたときに参加したかったなーと思ったので、今回はちゃんと応募＆参加できてよかったです
2019/8に発生したAZ障害についての話題は多かった印象ですね
次回もあれば参加したいです
※ 会場のドリコムさんの場所、迷って遅刻しそうでしたがギリギリセーフでした
以下メモです
「なんとなく」使うクラウドから「ちゃんと」使うクラウドへの入門
@kuro_m88 株式会社サイバーエージェント AI事業本部
↑先日のAZ障害についての件
公式ドキュメントを読む！
Auto Scaleでも在庫切れ等のリスクはある
リスクとコストの見合いは重要
利用するサービスのSLAとか調べて、その範囲外の障害時にどういうポリシーで対応するか握っておくのが大事かも
設計したり構築したら、ちゃんと試してみる（意図的に再起動するとか）
自宅サーバを始めてみる
そのコンテナ化、本当に嬉しいですか？
@euxn23
コンテナ化で嬉しいこと
- 本番と同じ環境で開発できる
- 環境構築不要
- docker-composeで依存関係もかける
本当は嬉しくないこと
- フロントエンドのホットリロードがきつい
- 複数プロジェクト等でポートぶつかる
ミドルウェアは嬉しいかも（MySQLとかElasticsearchとかredisとか）
config.devが本番とだんだん乖離してくる（envで頑張るしかないかなー）
docker-compose職人が必要な負債になってしまうこともある
RailsみたいなフルスタックなFWだと、無駄に分解しなきゃ感がある（例えばheroku使うとか検討したほうが良いかも）
マネージドサービスを使う場合、開発環境との共通化はある程度諦める（お金があるなら開発環境もAWS上に用意するなど）
localstack使ってメンテつらいとかなると本末転倒ではある
Amplify Console 誕生以来本番運用しつづけてわかったこと
@potato4d
AWS版のFirebaseみたいなもの
Amplify Console
S3+CloudFront+ACMみたいなもの
静的サイトのホスティングに特化している
Basic認証が気軽に設定できるのが嬉しい
ブランチごとにドメインが紐づいて管理可能
今静的サイトのホスティングやるならS3+CloudFrontよりベターっぽい
Firebaseとは要比較
大規模障害から見えたAWSのバックエンド
@varusan 株式会社ドリコムインフラストラクチャー部
私とあなたのAZは違う
起こったこと
- EC2のステータスチェック失敗、疎通停止
- だいたいSTOP/STARTで復帰したが、だめなやつもいた
- AMIとって起動もだめ
（あとから考える）対応策
- 止まったら困るインスタンスはスナップショットを日次で取っておく
- 本番はMulti-AZでAuto ScaleしなくてもASGは設定しておく
Elasticacheにもひっそり障害（負荷が微増）
CloudWatch上はavairableになっていたが、metricは送られていない！
原因はやっぱりEC2が基盤になっているから（RDSなどなど）
ALBで5xxが発生
障害発生したAZにルーティングされた場合、WAFが5xxに？
対応としては、WAF無効化とか障害のあったAZをサブネットごと外すとか（要3つめのAZ）
Health Dashboardは見よう
Atlantis + Terraform で実現するAWSインフラGitOps(仮題)
@かたいなか
IaC
メリット
- 再現性を持たせられる
- 設定が見れる
- チームで知見の共有しやすい（history, review）
実践Terraform
https://www.amazon.co.jp/dp/B07XT7LJLC/
構築したあとのお話
- 改修への対応
- AWS新機能導入
- 設定値の変更
- メンバーのスキル上昇
つまり何回も変更を適用する→アプリケーションのようにデプロイしたい
Atlantis
TerraformをPRベースで適用するOSS
