Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie とあるインフラ運用の今昔物語
Ähnlich wie とあるインフラ運用の今昔物語 (20)
とあるインフラ運用の今昔物語
- 2. 自己紹介 $ name 杉本 啓史(Twitter: @kecSg, Qiita: @ihsiek) $ organization JAWS-UG名古屋, 株式会社エイチーム $ favorite aws service AWS Security Hub
- 3. アジェンダ - 第1章 AWS移管とAnsible運用の始まり - 第2章 行き詰まりを見せるAnsible運用 - 第3章 Amazon ECS運用のはじまり - 第4章 ECS運用の混沌期 - 第5章 ECS運用の安定化 - 第6章 Ansible運用の終焉 - あとがき
- 4. 第1章 AWS移管とAnsible運用の始まり(1) - 国内ベンダーからAWSへの移管プロジェクトが発足 - プロジェクトの参画メンバー5名 - 半数がインフラ未経験者 - コード化すれば失敗してもリトライできる
- 5. 第1章 AWS移管とAnsible運用の始まり(2) - Ansibleにするか、Terraformにするか - Terraformを使い始めている部署があった - Terraformがコケたときに他のツールの知見がほしい - Ansibleを選定 - 既存環境を読み解き、Playbookを作成 - ベンダーロックインさせない方針でマネージドサービスは対象外 - 3ヶ月後、主力サービスのAWS移管が完了👏
- 6. 第2章 行き詰まりを見せるAnsible運用 - 知見が薄いなかで書いたPlaybookの冪等性が低い - ミドルウェアの更新などに使えない - 複数プロジェクトでPlaybookを共用している恐怖 - 他プロジェクトへの影響を気にして手が出せない - リファクタリングするも運用を統一できず - リファクタリングにより共通Roleとプロジェクト固有のRoleを分離 - インフラ専任ではないのでスキルレベルがまちまち - 勝手運用が始まり、徐々に運用ルールが崩壊
- 7. 第3章 Amazon ECS運用のはじまり - 開発環境と本番環境の差を小さくしたい - 環境に依存した不具合をなくしたい - サーバリソースを有効活用したい - これまではピークに合わせてキャパシティを設計 - 閑散期はサーバが遊んでしまう - できるだけインフラの面倒をみたくない - 人的リソースの都合で管理対象を減らしたい - 純粋にDockerを触りたい
- 8. 第4章 ECS運用の混沌期(1) - インスタンスタイプの変更方法がわからない - オペレーションミスでコンテナが落ちる - 全然マネージドじゃないし、直感的じゃない - 必要インスタンス数の変更が手作業 - ECSエージェントのバージョン管理が手作業 - セキュリティグループが柔軟に設定できない
- 9. 第4章 ECS運用の混沌期(2) - EC2 Auto Scalingからの制御を覚える - EC2, EBS, セキュリティグループのカスタマイズ - インスタンスオートスケールの設定 - カスタマイズのたびに古い設定が残る - コピーした起動設定を編集することになるため、コピー元が残る - オペレーションの再現性が低い - 新しいECSクラスターを作るたびに同様のオペレーションが発生 - コード化されていないので再現性は低い
- 10. 第5章 ECS運用の安定化 - CloudFormationにECSクラスターのスタックを発見 - スタックテンプレートによるカスタマイズ - セキュリティグループの複数指定 - ルートボリュームの拡張 - インスタンスオートスケーリングの設定 - UserDataの拡張(SSMエージェントのインストールなど) - 新規サービスはDocker運用を前提とした開発方針へ - Ansibleを使って本番環境を構築する運用がなくなった - ミドルウェアの管理はアプリケーションレイヤーへ吸収
- 11. 第6章 Ansible運用の終焉(1) - ECS運用が安定したことでAnsibleの用途が激減 - 運用の混乱を避けるため、本番でのAnsible運用を凍結 - 開発環境は引き続きEC2を利用するため、Ansibleを利用
- 12. 第6章 Ansible運用の終焉(2) - 辛かったこと - 冪等性を担保する運用設計ができていなかった - 運用者に運用ルールと知識のインストールができていなかった - 緊急時に慣れた方法で対処してしまい、Playbookが置き去りになる - 勝手運用を追いかける人が出てしまい、理想から乖離する - 良かったこと - 既存構成のスナップショットをPlaybookとして残すことができた - AWS移管を短期間のトライアルアンドエラーで完遂できた - 環境変数を変えながらEC2インスタンスを構築するのには便利
- 13. あとがき
- 14. プロビジョニングとECS - なぜプロビジョニングの回でECSの話をするのか？ - ユーザーが意識しないだけでCloudFormationを使っているから - ECS on EC2はCloudFormationでカスタマイズしてからが本番 - ECS on Fargateではだめなのか？ - インフラを管理しないという意味ではFargate優位 - Fargateを使わないことのメリットもある
- 15. - メリット - dockerコマンドが使える - インフラの自由度が高い - Docker Volumesなど、Fargateでは使えない機能が使える - IOPSやインスタンス特性を自分で選択できる - Fargateと比べて低コスト - デメリット - インスタンスの存在を意識する必要がある - デフォルトのスタックテンプレートは運用性が低い - ECS最適化AMIの更新オペレーションが必要 ECS on EC2のメリット・デメリット
- 16. ECSとCloudFormationの役割 - ECSが管理する要素 - サービス/タスクの配置・管理 - メトリクスの可視化 - タスクのスケジューリング - CloudFormationのパラメータ変更 - CloudFormationが管理する要素 - Amazon VPC - Amazon EC2 - Amazon EC2 Auto Scaling - Amazon CloudWatch
- 18. ご清聴ありがとうございました！！