イチ個人の見解であり、所属会社や組織とは関係はありません。
背伸びをしないAWS構成管理2016/04/20OpsJAWS #5
View Slide
Agenda1. やってみた系の負債2. カイゼンの道筋3. AWS Config snapshot4. まとめ
よくあるケース:クラウド採用したけど…• やってはみたものの、しばらく経つと…• 今本当にこのパラメーターで動いてる?• ルール決めたつもりだけど、いつの間にか誰かが設定変更してる 等…• いざ何かやろうとしたときにリスクを積んじゃう → 高コスト体質…• 故に気が乗らない…(今動いているものを変えて何かあったら…)• 体制・文化の問題• (開発)インフラよりの設定変える必要があるけど、リリース後は触れない…• (運用)APへの影響が分からないから…• カイゼンへの障壁• いわゆる”保守”の品質(効率性・安全性)が上がらない• 運用と保守の違い• 運用:日々システムを動かすこと、現行維持、改善の根拠となる情報収集 → いわゆる現状維持• 保守:より良いサービスを提供し信頼を担保し続けるための活動 → いわゆるカイゼン
• いきなり理想論語っても現実的に聞こえない• ビジョンを見せるという意味では、大事だけど• ツールとかたくさん使ってみたけど定着しない• 組織や文化まで変えられない• エンジニアレベルの話じゃなくなる• 道のりは険しい…順序建てって大事よしDevOpsやるか!! でも…
カイゼンの道筋(イメージ)CI/CD DevOps アジャイル攻めのIT画面・手作業系(とりあえずやってみた)最初はここ理想現実路線ビジネススピード安全性
AWS Config を使ってみる• AWS-Config snapshotで全体構成の管理• 定期的にsnapshotを取得しておく• jsonのままだとお客さんや運用は見ないので、EXCEL化する確認顧客顧客環境AWS ConfigAWS ConfigSnapshot(json)Excel生成AWS構成パラメーターシートLambda functionSnapshot取得本番環境複製環境+Ops複製
AWS Config snapshot活用のPoint• 差分が取れるようにするには最初も大事• ソースコード化はやっておく。もちろんバージョン管理も• 前述のEXCELのフォーマットにパラメーターを埋めてプロビジョン• rspecやserverspec、awspecでテスト• 何がうれしいか?• 今の状態が”見える”• 当初構築した環境との違いが”見える”• 維持したいVerとの差。Rspec/serverspec定期実行で自動検知もできる• 環境複製、復旧する際に必要な最新パラメーターが常に信頼できる• AWSのサービスが使える → 安全!!!• 残念なところ• 対応リソースが少ない…
まとめ• 安全性を高めるところから始める• DevOpsへの道はインフラコード化&Ver管理から ※所説あります• インフラリソースをバージョン管理できるのはクラウドのメリット• AWS-Config snapshotを使えば、全体構成をjsonで取得可能• AWSは始めやすい!!• エンジニアレベルで始めてから組織を巻き込んでいくアプローチ• Tips集めて実績つくる• ここで認めてもらえると、体制や文化的な改革も軌道に乗せやすい• DevOps(右上)への道が開ける!!!+
Let’s share the tips later!!