Infrastructure as Codeのこれまでとこれからに参加して

こちらのイベントに参加したので学んだことや感想などの参加記録をダラダラ書いていきます。

基調講演

Infrastructure as Codeのこれまでとこれから

Infrastructure as Code(IaC)とは
インフラをコード化すること(ChefとかAnsibleとか,K8sとかTerraformとか)

どんどんIaCが当たり前のものになっている。
自動化→ソフトウェア開発のプラクティスをシステム管理に応用→対象領域拡大

かつてはインフラが変化の制約になっていたがダイナミックインフラの発展・普及によりインフラが変化の制約ではなくなった。
だがそれによって「サーバースプロール」、「構成ドリフト」、「スノーフレーク」、「サーバの増殖」、「オートメーション恐怖症」、「システム疲労」といった問題点が顕在化した

これをIaCを使い解決しようとしている
IaCの原則は「簡単に再現できる->スノーフレーク化を避けられる」、「使い捨て->エラー体制が高い」、「統一的構成->ドリフトをなくせる」、「反復」、「変化できるデザイン」である

Infrastructure as Codeを導入して良かった点

IaCを導入するメリット
・一定の品質を保障できる
・コードレビューができる
・作業の簡素化・属人化
・テスト・デプロイも自動化
・運用コストを削減

Patterns in Infrastructure as Code

<<IaCのパターン>>
1.Environment Pattern
プロダクション・ステージングを分ける
IaCでは共通化しない。なぜなら影響範囲を小さくするため
2.Scaffold Pattern
テンプレートの変数に対し数字を入れコードをジェネレートする
セルフサービスを簡単に。ドキュメントを書く必要がある。
3.Buckup Pettern
コンフィグやリソースを手動で変更後コードをジェネレート
少し危険?でも便利。

Infrastracture as Code変遷
やるようになったこと・やらなくなったこと

なぜIaCなのか?
人間には信頼性がないため、全てをコード化する。

仮想マシンからクラウドへ
プロビジョニングツールがIaCというわけではない。
最近はコンテナオーケストレーション上に多く任せるようになった

究極のInfrastructure as Codeを目指して

IaCにおいてソースコードは開発者が作りたい理想状態
システムは現在の状態と理想状態を埋めるもの(TerraformやK8s)

Infrastructure as Code における
Test-Driven Development とその差分

テスト駆動開発とは?
1.プログラムに必要な各機能についてテストを書く
2.そのテストが動く必要最低限な実装を行う
3.コードを洗練させる
という短い工程を繰り返すスタイル

インフラでのテスト駆動開発
IaCを使い継続的なCI/CDを行う
プログレッシブテスト

IaCにおけるテスト駆動開発の問題点と解決策
・IaCの場合テストファーストを設定しづらい
->アプリケーション側と協業する
・宣言型コードのテストの価値が低い
->異常な設定が入ってないことを確認する
・本番環境でしかできないテストを再現しづらい
->負荷分散や障害試験など事前にできるものを実施
・IaCのテストが遅い
->プログレッシブテストをする。
->依存関係を明確化、最少化によりテストの分離を行う

サービスメッシュを完全に理解する

なぜインフラでサービスメッシュを気にするのか
1.モノリスな場合DBテーブルが多くなると複雑化
2.マイクロサービス化...結局複雑化するとスケールの限界が見えてくる
3.全サービスに共通の設定をまとめたくなる
サービスメッシュを利用

サービスメッシュとは
マイクロサービスに共通の規約を取り出し、サービス鵜が増えてもスケールできる構成管理をアプリケーションとインフラの間に提供しつつ、それら全体をコードで管理するための仕組み

共通設定をコード化しマイクロサービス構成でインフラとアプリの間の治安を守る

History of Infrastructure as a code testing

IaCのテスト
高水準テスト...Multi tier serviceのdeployとテスト
中水準テスト...server roleのbuildとテスト
低水準テスト...定義ファイルの有効性のテスト

IaCのテストの歴史
最初期のIaCのテストツールは低随順テストのツールが多い
Serverspecの登場後IaaSが一般化していく中でサーバーの構成をテストするプロビジョニングテストツールが増える
この頃はawspecやTerraformなどのダイナミックインフラストラクチャーをテストするツールもあるがあまり流行っていなかった
DokerをはじめとするContainerがはやり始めてからプロビジョニングテストツールが下火
Terraform,K8sなどのインフラストラクチャ定義ツールが強くなりconftestやcueなどの宣言的記述を用いる設定ファイルのvalidatoinができるツールがはやり始める

フルリモートにおける Infrastructure as Code の効果

なぜIaCを使うのか
開発と同様のレビュープロセスを踏めるようにするため
バージョンの管理を可能にする
コードの再利用ができる
手作業によるミス防止

なぜCI/CDをするのか
開発方法・デプロイ方法がコード化されることで新規メンバが追いやすい
デプロイ方法が自動化されていることでデプロイのオペミスを防ぐ
自動化による開発効率とリリーススピードの向上

こんな世の中なのでリモートで齟齬なくコミュニケーションをとるにはIaC,CI/CDは必須

IaCを使わないと
何をしたか可視化できない、いつやったのかわからない

感想

今回のイベントではIaCの基礎や歴史について復習することができた。なかなか歴史については振り返る機会は少ないのでとても有意義な時間になったと思う。次回の　Infra Study Meetup #2 にも期待!!