背伸びをしない AWS構成管理

2016/04/20

OpsJAWS #5

Agenda

1. やってみた系の負債

2. カイゼンの道筋

3. AWS Config snapshot

4. まとめ

よくあるケース：クラウド採用したけど…

• やってはみたものの、しばらく経つと… • 今本当にこのパラメーターで動いてる？

• ルール決めたつもりだけど、いつの間にか誰かが設定変更してる 等… • いざ何かやろうとしたときにリスクを積んじゃう → 高コスト体質… • 故に気が乗らない…（今動いているものを変えて何かあったら…）

• 体制・文化の問題 • （開発）インフラよりの設定変える必要があるけど、リリース後は触れない… • （運用）APへの影響が分からないから…

• カイゼンへの障壁 • いわゆる”保守”の品質（効率性・安全性）が上がらない

• 運用と保守の違い • 運用：日々システムを動かすこと、現行維持、改善の根拠となる情報収集 → いわゆる現状維持 • 保守：より良いサービスを提供し信頼を担保し続けるための活動 → いわゆるカイゼン

• いきなり理想論語っても現実的に聞こえない • ビジョンを見せるという意味では、大事だけど

• ツールとかたくさん使ってみたけど定着しない

•組織や文化まで変えられない • エンジニアレベルの話じゃなくなる

•道のりは険しい…順序建てって大事

よしDevOpsやるか！！ でも…

カイゼンの道筋（イメージ）

CI/CD DevOps アジャイル 攻めのIT

画面・手作業系 （とりあえずやってみた）

最初は ここ

理想

現実路線

ビジネススピード

安全性

AWS Config を使ってみる

• AWS-Config snapshotで全体構成の管理 • 定期的にsnapshotを取得しておく

• jsonのままだとお客さんや運用は見ないので、EXCEL化する

確認

顧客

顧客環境

AWS Config AWS Config Snapshot

(json)

Excel生成

AWS構成 パラメーターシート

Lambda function

Snapshot 取得

本番環境

複製環境

＋

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!!