既存システムでインフラのコード化を行う意義
はじめに
大抵、インフラのコード化を始めるのって新規システムとかになると思います。
たしかに、最初からやる方が途中からやるのに比べて遥かに敷居が低く、費用対効果も高いと言えると思います。
まあ、インフラのコード化に限らず、TDDとかもそうです。
新しいことを始めるのは最初からの方がやりやすい。
これが、既存システムの場合は
- 今動いているものが壊れたらどうする？
- 既に出来上がっちゃってるものにそんなにコストかけてやる必要ない
とかいう感じで、コストやリスクと得られるメリットを天秤にかけた結果、敬遠されがちなのかなと思います。
たぶん、比較対象のメリットは以下の様なものでしょう。
- 自動化による人的コスト減
- 再現性のあるインフラによる追加開発やメンテナンスの効率と質の向上
- モチベーションアップ
でも、やったことがある人には判るかもしれませんが、実はもっと重要なメリットというか、意義があるんです。
それは何か
それは、今まで見えなかったものが見えるようになることです。
インフラをコード化していくとはどういうことなのか
特に僕が多くの場面で使っているChefだとそうなのですが、そのシステムを構成しているコンポーネントを洗い出し、分類し、依存関係を整理して、コードという形で定義していくという作業です。
そして、見えてくるものがある
例えば以下の様なものです。
- 役割を負い過ぎているサーバ
- 役割が重複しているサーバ
- 実は無くても良くて潰しちゃってコストを下げられるサーバ
- 耐障害性に不安があるサーバ
- 依存関係が複雑で追加開発や保守作業の足を引っ張りそうなサブシステム
- サービスが停止する原因となりそうな障害
他にも細かい所では、致命的なバグや脆弱性を内包したバージョンのまま動かしてるミドルウェアとかが見つかったりすることもありますが、まあそれはコード化特有っていう話ではなく二次的なものですね。
見えてくると改善できる
今までなんとなく動いていてなんとなくそのままでいたものが、見えてくることによって改善できるようになります。
そうなると、特に今後もある程度長く続くであろうシステムであれば、十分にコード化を進める意義があると思いませんか？
新規システムでもそうです。はじめからちゃんとやっておくと、全体を俯瞰して把握しやすくなり、改善計画を立てやすくし、成長スピードを速められます。
そのために
上述しましたが、そのシステムを構成しているコンポーネントを洗い出し、分類し、依存関係を整理して、コードという形で定義していくという作業をちゃんとやる必要があります。
これは、ある程度の「設計」や「実装」のノウハウが必要になります。
YAPCではその辺りをお話してみたいなと思っているので、気になる方は是非SNSなどでシェアして応援お願い致します！
以上、ステマですいません。。。
