Recruit Technologies Open Lab (Infrastructure as Code) #03 行ってきた | Advent Calendar 2016
IT系の勉強会行ってきた Advent Calendar 2016 - Adventar の17日目!
登壇者が豪華だったので速攻申し込んだやーつ!
"Infrastructure as Code" から数年、結果どうなったか
-
歴史を振り、AWSの東京リージョンが出てから流行った
- クラウドになって作り直したり複数構築することが多くなる
→コード化、バージョン管理
→アプリケーションで培ってきたプラクティスをインフラでも適用 - サーバだけでなくDNS設定も継続的デリバリー
- ビルドを再現可能になるべき統制が担保されてることが大切
- 複雑性に立ち向かうには?
DDDを導入したり、業務をそのまま落とし込むのではなく本質に絞って落とし込む - インフラコードが3年後に負債になってるんじゃないか
Infrastructure as Code と企業文化
- Infrastructure as Codeを行う前に文化的な問題を何とかする必要がある
- コンウェイの法則の影響を受けやすく組織構造に依存する部分が出てくる
- SIer構造だと部門ごとでの利益を確保しようとするしコントロール
AWS使ってるのにExcelでの申請書を出すとか
同じ専門性の人は一か所に集めた方が効率的になる という誤解
→インフラ担当が色んなアプリを見る事によってそこがボトルネックになりやすい - プロジェクト単位でアプリとインフラ担当が一緒にいる
個人に負荷がかかってしまう。個人の能力依存が強い - プロダクトでチームを作る
変化に強い、サービスをゴールに出来るので集中しやすい
ログとかメールとかは共通基盤を使う。社内OSSを統合したり管理するのがよい - 全体的に中央集権を求めすぎるのは危険
- 文化的なチャレンジもあり会社のマインドや文化に大きく影響を受ける
- クラウドではアプリかインフラかの責任分界点が難しくなってくる
Infrastructure as Code のこれまでとこれから
-
インフラをコードする事によって、バージョン管理、自動化、テストが可能
- 過去や現在まで色んなモノが出てきてる
2013年にServerspecを作ったけども、その後も目的別に様々なツールが出てきてる - Containerによる影響が大きくなりつつある
サーバ管理よりプロセス管理に近いような構成になっている - インフラとソフトウェア開発はさらに近くなり複雑化しつつある
運用・監視もコード化する。開発者が監視まで考える方法論
- すべてのサービスで健全性と一般的な監視関連メトリックを同じように出力するのがよい
- 監視って何?
→システムの高速健康診断
わかる数値からモニタリングしていくことが大切 - 監視にも種類があり、チェック監視やメトリクス監視とかとか
- 監視はインフラ任せにしない。身近なところからいじっていく事が必要、pmsetコマンドとか
プロビジョニングツールはMakeで決まりだろ
-
Makeはベターshell scriptである というのを2012年に発表した
- Makeはシェルスクリプトで大体動く、サブコマンドで補完もきく、名前付きでパラメタ渡せる
→makeだと1行毎にリターンコードで落ちるからshellよりも安全 - プロビジョニングツールだと厳密な冪等性は保たれない事がある
→削除のべき統制担保が微妙な問題 - 最近は複雑なサーバーをどう管理というよりは、単純なサーバーをどう組み合わせるか
どれも面白い発表で参加して良かった!