OpsJAWS#5 20160420 背伸びをしないAWS構成管理

イチ個人の見解であり、所属会社や組織とは関係はありません。

Transcript

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