Terraform meetup tokyo#3 インフラ実装をUMLで設計する

Terraform meetup tokyo#3 インフラ実装をUMLで設計する

2019年12月02日に Terraform meetup tokyo#3 の LT で発表した資料です
https://terraform-jp.connpass.com/event/153286/

A780df2258e55a4a5feb1aef3ca909d4?s=128

Toshihiko Nozaki

December 02, 2019
Tweet

Transcript

  1. 2019/12/02 Terraform meetup tokyo#3 インフラ実装を UML で設計する 〜 インフラを⼀つのアプリと捉えよう〜 フリーランス@⼤阪

    野崎敏彦
  2. ⾃⼰紹介 • 野崎敏彦 • フリーランス • ⾃宅は⼤阪、年の 60% は東京 •

    主に AWS インフラ⽀援その他もろもろやってます。 • Windows/WPF でゴリッゴリネイティブアプリ作ったりもしてます。 • Twitter : @bukaz54 2
  3. 今⽇伝えたいこと • UML で考えよう。 3 AWS Cloud VPC Public subnet

    Private subnet Boundary Control Entiry
  4. 4 去年 8 ⽉頃の話

  5. こんなの。 • 実際は他システム連携や API の認可なども。 5 AWS Cloud VPC Public

    subnet Private subnet ECS Cluster Load Balancer App Container Database AWS CodePipeline Frontend (AWS 以外の⽅ごめんなさい)
  6. 開発ステージ毎の AWS アカウント • 各環境は workspace で分離 6

  7. configuration の分割 • Database スタック • Application スタック • CI/CD

    スタック • 運⽤ツール スタック • DNS スタック 7
  8. 8 しぬかとおもった

  9. 次ステージで apply 失敗 • 更新、削除できないリソース • Configuration 間での循環参照 9

  10. 「環境もう1セットほしい」と⾔われる • 「QAチームを投⼊することになりました。」 • 「DB は開発チームと共有で。」 10

  11. 環境の破棄が⼤変 • apply に苦労する configuration は destroy も困難 11

  12. 12 なぜこうなった︖

  13. ビルド⼿順が複雑なアプリと同じ状態 • 曖昧なコンポーネント分割 • 複雑な依存関係 • ライフサイクルの異なるリソースが混在 • 異なるデプロイ⽅法(アップデートできるのか、別で作って切り替 えるのか)の混在

    13
  14. 14 どうするか。

  15. オブジェクト図、クラス図を描こう 15

  16. ⼀部拡⼤ 16

  17. インフラ全体を⼀つのアプリケーションと捉える • これだけの数の、ライフサイクルの全く異なるオブジェクト群を設 計無しでコーディングしたら失敗するのは当たり前。 • ある程度の規模を超えたら、アーキテクチャ図からコーディングに 直⾏するのは困難。 • UML を活⽤し、きちんとコンポーネント分割を⾏おう。

    17
  18. 責務で分割する 18 AWS Cloud VPC Public subnet Private subnet Boundary

    Control Entiry • VPC にロバストネス図乗せるのおすすめ。 ALB Container Database
  19. 関⼼事で分割する • 各レイヤーのアクセス制御を担う Security Group は独⽴させる。 • AWS W-A /

    sec 「全レイヤーへのセキュリティの適⽤」 19
  20. ライフサイクルで分割する • ECR や Hosted Zone など、初期段階で⽤意しておきたいもの。 • 消さないもの(間違って消したら困るもの、存在するだけなら無料 なもの)

    20
  21. 開発ステージまたぎ依存の可視化 • Database を共有することはよくある。 21

  22. 22 ところで。

  23. マルチベンダー開発 • もちろん各プロジェクトは並列運転 23

  24. インフラは⼀⼈ • インフラがボトルネックになることもちらほら。 24

  25. AWSに乗せてALB→DBを通すまでが勝負 • 可⽤性などの⾮機能要件はその後の開発サイクルで順次対応。 25

  26. スタートダッシュ超重要 • トランザクションデータを扱う WebAPI が多い。 • 基本的には似通ったアーキテクチャ。 26 重要

  27. インフラを量産したい • デプロイできなければ開発サイクルが回らない。 • 似たようなアーキテクチャのシステムなら即⽴ち上げられるだけの インフラ供給⼒を確⽴したい。 • 「再利⽤」。 27

  28. 28 話をもどしまして。

  29. Configuration 分割結果 • Common • Hosted Zone • ACM •

    ECS Cluster • ECR • etc … • Security Group • Load Balancer • ALB, • Listener, • Target Group • Database • RDS Instance (ignore_changes) • Bastion Host • Backend App • ECS Service • Task Definition • IAM Role • Frontend App • S3 Bucket 29
  30. 効果 • configuration 単位での再利⽤性。 • CI/CD の⾃動化が「困難な箇所」 が明確になる。 • terraform

    state mv でのリファク タリングへの道。 30 • 3ヶ⽉後の⾃分へのドキュメンテーション。 • 引き継ぎ時にも有効。 • 開発チームと同じ⾔葉でインフラについて会話ができる。
  31. まとめ • アーキテクチャ図からコンポーネント設計を経てコーディングに進。 • 再利⽤性は作り込むもの。 • UML は共通⾔語。きちんとドキュメントを残す。 31