だらけた日記

Infrastructure as Code: 原則・課題・ベストプラクティス

1章: 課題と原則

バージョン管理システム（VCS）を用いた管理

バージョン管理システム、特にGitを活用することにより、クラウドインフラの管理が革新的に改善されます。以下にその主要な利点を示します。

  1. トレーサビリティ
    Gitを使って変更をコミットすることで、誰がいつ何の変更を加えたのかが明確に記録されます。これにより、問題が発生した際のデバッグが格段に容易になります。
  2. ロールバック
    不具合が発生した場合、以前の安定した状態に簡単に戻ることができます。これは、複数の変更が原因でシステムに問題が生じた際に特に価値があります。
  3. 可視化と通知
    変更がプルリクエスト（PR）でレビューされ、マージされる過程を通じて、開発チーム全体が最新の状況を常に把握できます。さらに、Gitと連携したSlackの通知システムを設定することで、関連するメンバーが変更を追跡しやすくなり、重大な問題に気づくチャンスが増加します。
  4. アクショナビリティ
    GitHub Actionsなどのツールを利用して、特定の条件下で自動的にトリガーされるアクションを設定できます。これにより、自動テスト後に環境にデプロイを行うプロセスが自動化され、特定の人のナレッジに依存しないで誰でも簡単にデプロイが可能になります。

小刻みな変更の重要性

小刻みな変更を実施することの利点は多岐にわたります。効率的な開発プロセスを実現するための主要な戦略として、以下の点が挙げられます。

  1. テストと検証の容易さ
    小規模な変更はテストが容易であり、問題が発生した場合には対応も迅速に行えます。
  2. 問題の特定の容易さ
    小さな変更で問題が発生した場合、原因を特定しやすく、大規模な変更時と比べて修正も迅速に行えます。
  3. 復元の簡便さ
    万が一、問題が解決できない場合でも、小規模な変更であれば前の状態への復元が格段に簡単です。
  4. 進捗の可視性とモチベーション
    定期的に成果を出すことは、作業のモチベーションを維持する上で重要です。小刻みに成果を上げることで、未完成の大規模な作業によるストレスを軽減し、チームの士気を高めます。
  5. フィードバックの迅速化
    頻繁に変更をリリースすることで、利用者や他の開発者からのフィードバックを早期に得ることができ、製品の質の向上に直結します。

変更回数を最小限に抑えようとする場合、小刻みな変更の重要性が見落とされることがあります。これにより、ITシステムの堅牢性が損なわれる可能性があります。システムを絶えず変更し、改良しているチームは、大小の障害に対処する力を持っています。例えば、CloudFormationを必要最低限しか使わない場合、手順を忘れたり、復元に時間がかかったりすることがあります。さらに、変更前後の違和感に気づきにくくなり、システムに手を加えることへの恐怖がなくなることがあります。

堅牢とは何か

堅牢とは何かについて、rfc761のRobustness Principleで次のように述べられています。

TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

(翻訳)TCPの実装は、以下の一般的な堅牢性の原則に従うべきです：自分が行うことには保守的であり、他者から受け入れることには寛容であること。

ここで言及されているのはTCPレベルの話ですが、若干受け入れがたい面もあります。この原則によれば、サービスやドメイン、インフラが守るべき本質的な特性やデータを保持しながらも、外部からの変化や脅威、脆弱性といったものに対して、そして新機能のリリースに対しても、柔軟に対応することが求められます。

2章: ダイナミックインフラストラクチャプラットフォーム

ストレージ

  1. ブロックストレージ
    • サーバーインスタンスのライフサイクルとは異なる独立したストレージ: ブロックストレージはサーバーインスタンスのルートストレージとは別に存在し、サーバーインスタンスが終了してもデータが保持される。
    • ネットワーク経由でアロケートされるためのパフォーマンス調整が必要: レイテンシが発生することがあるため、最適なパフォーマンスを得るためには構成設定や利用方法のチューニングが必要。
    • マウントしたサーバーからのみアクセス可能: 特定のサーバーにマウントされ、そのサーバーからのみアクセスが可能。他のサーバーにアクセスを許可するためには、ストレージを再マウントする必要がある。
    • 例としてAWSのEBSがある: Amazon Web ServicesのElastic Block Store (EBS) が代表例。
  2. オブジェクトストレージ
    • 複数のサーバーからアクセス可能: ブロックストレージと異なり、オブジェクトストレージは複数のサーバーからのアクセスが可能で、分散アクセスに適している。
    • レイテンシが比較的高い: アクセス速度がブロックストレージに比べて遅い可能性がある。
    • 例としてAWSのS3がある: Amazon Web ServicesのSimple Storage Service (S3) が代表例。

※レイテンシ: データが送信元から目的地に到達するまでの遅延時間

DynamicInfrastructurePlatformType

  1. パブリッククラウド
    • パブリッククラウドは、クラウドサービスプロバイダーによって管理される環境で、多数の異なる顧客が共有します。これにより、コスト削減が可能になり、広範なスケーラビリティが提供されます。
    • 料金体系は主に使用量に基づいており、「ペイ・アズ・ユー・ゴー」スタイルが一般的です。
  2. コミュニティクラウド
    • コミュニティクラウドは、特定の共通の関心事（例えば、セキュリティ要件、規制の遵守など）を持つ限定された顧客グループのために構築されます。これはパブリッククラウドとプライベートクラウドの中間に位置します。
    • このタイプのクラウドは、そのコミュニティに特有の要件に合わせてカスタマイズされます。
  3. プライベートクラウド
    • プライベートクラウドは、特定の組織内部で運用される専用のクラウド環境です。これにより、より厳密な制御とカスタマイズが可能になり、セキュリティとプライバシーが強化されます。
    • 組織は自社のデータセンターで運用することも、サードパーティのベンダーにホスティングを依頼することも可能です。この場合、リソースは他の企業と共有されません。

9章: インフラストラクチャ定義パターン

アンチパターン

  1. 手作りインフラストラクチャ

    対話的GUIやツールを使って手作業で作成や変更を加えると、それを反復することは容易でない。そのため、環境（本番や開発など）の間に不一致が生まれてしまう。 -> 解決：IaCを使って、再現、再構築、複製ができるようにする

  2. 環境ごとの定義ファイル

    環境ごとに別々のファイルを作る。複数のファイルを最新で統一的な状態に保つためには手作業が必要になることがある。これでは、全てが統一的なものになっていることを保証できない。 -> 解決：各環境に固有なオプションを設定するためのパラメータ化する。再現、再構築、複製するときに環境固有パラメータを使うことができる。

  3. ものりシックスタック

    ものりシックスタックは、インフラの異なるようのの統合や共有が単純になる。しかし、変更がめんどくさくなる。

    • 小さな変更で多くのものが動かなくなることが起きやすくなる
    • インフラないの部分部分の密結合が裂けにくくなる
    • 環境の各インスタンスが大きくコストのかかるものになる
    • 開発、テストのためにスタック全体をまとめてテストしなければならないくなるので、変更が面倒になる
    • スタックの大きさに合わせて多くの人がインフラに変更をかけれられ湯尾にすると、誰かにどこかを壊される危険性が高くなる
    • それに対し、リスクを最低限に抑えるために、変更を加えられるのを小さなグループだけに絞ると、変更が実現するまでなあい間待たされるようになる 人々が変更を加えるのを恐れるようになったら、インフラストラクチャ定義がモノ利シックになっていると考えることができる。

関連記事

だらけた日記

© 2023 NYBEYOND.