AI時代のDevOps入門

Transcript

1. AI時代のDevOps入門 バックエンドチームがTerraformに 挑戦した実体験 奥野 志洋
2. 奥野 志洋 おくの ゆきひろ ディップ株式会社 新卒2 年⽬ バックエンドエンジニアとして入社 スクラムで開発していく中で Next.js やTerraform など別領域も 電車に乗らない人生に憧れ エンジニアを志す
3. Copyright © DIP Corporation, All rights reserved. 突然ですが、こんな経験ありませんか？
4. 今回のスプリントで対応する PBIを実装する際には、インフラリソースの設定変更 （もしくは新たなリソースの作成）が必要だね アプリケーション開発チーム とあるスクラムチームにて、 、
5. アプリケーション開発チーム インフラチーム 作業依頼 とあるスクラムチームにて、 、
6. アプリケーション開発チーム インフラチーム 〜待機中〜 とあるスクラムチームにて、 、
7. アプリケーション開発チーム インフラチーム 作業完了 とあるスクラムチームにて、 、
8. アプリケーション開発チーム インフラチーム とあるスクラムチームにて、 、 自分でも設定変更できるけど、 インフラのリソースはインフラチームが 管理するものだから依頼して変えてもらうか インフラチームの作業待ちになって しまったぞ、 、
9. 細かな依頼が多くて 本当にやりたい作業の時間が無くなる、 、 、 アプリケーション開発チーム インフラチーム とあるスクラムチームにて、 、 リソースをコード管理したいけど アプリケーションの仕様に依存するリソースが多くて 管理が難しい、もしくはできない、 、
10. アプリケーション開発チーム インフラチーム アプリケーション開発チーム アプリケーション開発チーム 複数のプロダクトを見ているケースだと更に深刻化
11. Copyright © DIP Corporation, All rights reserved. アプリケーションの開発チームが インフラリソースの設定変更すれば良いのでは？
12. Copyright © DIP Corporation, All rights reserved. でもIaC (Infrastructure as Code) ってなんか難しそう、 、
13. Copyright © DIP Corporation, All rights reserved. 実体験を共有する事で皆さんのIac に対する ハードルを下げる20 分にします！！
14. 01 02 03 04 05 IaC 、Terraform の基本 IaC 挑戦の背景 Agenda チームで実際に取り組んだこと 得られた成果、学び 今後の課題、展望
15. Copyright © DIP Corporation, All rights reserved. IaC 挑戦の背景
16. IaC挑戦の背景① : システムのリアーキテクチャ 複数のシステムが共通の DB 、 テーブル、レコードを 参照、更新 開発チームは利用者単位で分割 同様のロジックが各所に分散、 異なる業務のロジックが密結合 している状態
17. IaC挑戦の背景① : システムのリアーキテクチャ 一つの業務変更が 複数のチームに影響を与える 全チームで足並みを揃えて 矛盾が起きないように慎重に 開発するのが常態化 結果的に 開発生産性の低下や 障害へ繋がってしまっていた
18. IaC挑戦の背景① : システムのリアーキテクチャ DDD( ドメイン駆動設計) という設計思想を取り入れて 画面中心の設計から業務中心の設計へ DDD の話が気になる方は弊社のテックブログを参照！ 僕もこの前、Go でDDD やってる話で登壇したので後ほど、記事書きますのでぜひ
19. 求人 IaC挑戦の背景① : システムのリアーキテクチャ DDD( ドメイン駆動設計) では業務を整理して 境界づけられたコンテキストという単位で分割する そして境界づけられたコンテキストはDB を別に持つ事や 結合度を下げる意図からイベント駆動を用いて連携する設計を選択しました 勤怠管理 振り込み 応募 承認 スキマバイトサービスのイベント連携例
20. IaC挑戦の背景① : システムのリアーキテクチャ イベント連携に使うインフラリソースは アプリケーションに依存するものが多い コミュニケーションコストを減らし、タスク待ちの状態を無くして リアーキのプロジェクトをスピード感高めて行うために 自分たちでIaC でインフラリソースを構築、管理していくことを定めた インフラリソースもコンテキスト単位のモジュールで分割して管理したい ↓
21. IaC挑戦の背景② : Everything as Codeの実現 Everything as Code プロジェクトに関連する全ての情報をアプリケーションの管理リポジトリ内 でAI が読みやすい形式で管理すること 人間にしか無い暗黙知を無くし、AI に渡すコンテキストの質を高めて アウトプットの質、速度を高め生産性を上げていくという考え方
22. IaC挑戦の背景② : Everything as Codeの実現 アプリケーションのコードとインフラリソースのコードを 同じチームで管理することで 自然にEverything as Code の恩恵を得ることができるのでは？
23. Copyright © DIP Corporation, All rights reserved. IaC 、Terraform の基本
24. IaC、Terraformの基本 : IaCのメリット 冪等性の実現 ・ミスの削減、工数の短縮化 手動操作によるインフラ設定を自動化 バージョン管理ツールでの管理 ・履歴の可視化。差分での管理が可能 ・操作を何度実行しても、その結果が常に同じになる性質 ・インフラコードの信頼性向上、定義をチーム間での共有可能
25. IaC、Terraformの基本 : Terraformとは インフラストラクチャをコードで管理するための オープンソースツール ・マルチクラウド対応 ・宣言型アプローチ ・HCL （HashiCorp Configuration Language ）
26. IaC、Terraformの基本 : 基本コマンド terraform init terraform fmt : 初期化コマンド : フォーマット( エディタが自動で行う) terraform plan : ローカルとリモートの状態を比較 　　　　　 実際にどのような変更が適用されるかを表示 terraform apply : インフラに変更を適用 実行後にState ファイルが最新の状態に更新
27. IaC、Terraformの基本 : state state ファイル : 現在のAWS リソースの設定状態を 　 管理するファイル AWS だとs3 に保存 apply apply
28. Copyright © DIP Corporation, All rights reserved. チームで実際に取り組んだこと
29. チームで実際に取り組んだこと : plan genによるコード生成 terraform plan -generate-config-out オプション Terraform 1.5 で追加された -generate-config-out オプション 使用することで、既存リソースの HCL を自動で生成することができる
30. チームで実際に取り組んだこと : plan genによるコード生成 import ブロック to : terraform 上で管理するためのリソース名 id : provider(aws) などの世界での識別ID import ブロックの定義方法は Registy に記載
31. チームで実際に取り組んだこと : plan genによるコード生成 1. 手動で開発環境にリソース作成 2. plan generate で自動コード生成 3. AI によってコードを整える( デフォルト値の省略) 4. モジュール化してリソースを一般化 都度、Registry を参照して 理解を深めるとともに 設定を最適化
32. チームで実際に取り組んだこと : AWSのキャッチアップ AWS の知識をスクラムチームでキャッチアップ AWS Black Belt Online Seminar という公式が各リソースについて 説明する動画を視聴する時間をスプリント内で設定
33. チームで実際に取り組んだこと : CICDの構築 リソースの変更計画をGitHub 上で確認可能 不慣れな領域かつ他チームから見てもらうので レビュー・コミュニケーションのコストを下げたかった PR の作成時にterraform plan の結果を自動でコメントするワークフローの作成 レビューで承認されPR がマージされたらブランチに応じて各環境へ自動apply
34. チームで実際に取り組んだこと : Everything as code 同一リポジトリでプロジェクトに関連するコードを格納 ・各マイクロサービスのコード ・Terraform などのIaC コード ・ドメイン知識を記載しているドキュメント 生成AI に渡すコンテキストの質を向上させる アプリケーションのコードとインフラのコードを同じリポジトリで 管理することによるメリットも感じた
35. チームで実際に取り組んだこと : Everything as code 具体例 : Eventbridge のtarget 入力トランスフォーマーという イベントモデルに格納されている 値を変換してターゲットに渡す定義 アプリケーションの処理に 依存する定義内容
36. チームで実際に取り組んだこと : Everything as code 具体例 : API GateWay API のIF を定義するopenAPI のyaml を body に渡すことで管理、更新の手間を削減
37. チームで実際に取り組んだこと : コミュニケーションの変化 インフラチームの方にプランニングに参加してもらう ただ、依頼するといった関係性ではなく スクラムイベントの中で自然とコミュニケーションの増加 また、 アプリケーションの開発チームもAWS の知識を今よりも 獲得していくことでより本質的な議論、相談ができるように
38. Copyright © DIP Corporation, All rights reserved. 得られた成果・気づき
39. 得られた成果・気づき terraform plan -generate-config-out オプションによる コード生成フロー もちろん、最初に開発環境に手動で構築したものを基にするため IaC の良さと相反する要素もある しかし、最初のキャッチアップとしては効率の良いフローだと感じました 生成されたものをRegistry などで調べながら実装していくことで AWS やTerraform のキャッチアップをしつつ、リソースを構築、IaC 化を 効率良く勧められていることを実感できた
40. 得られた成果・気づき 開発メンバーのスキル向上 AWS の知識のキャッチアップを進んだことで リアーキテクチャをしていく際にもAWS のリソースを含めた構成の設計など より本質的な議論ができるようになったと感じました 領域による縦割りではなく、スクラムチームとして機能横断的なチームへと 成長をしていくことができた
41. 得られた成果・気づき Everything as Code による同一リポジトリでコード管理 DDD の性質上、アプリケーションロジックや境界づけられたコンテキスト といった知識に依存するインフラリソースに関する定義の効率化に成功した AI へのインプットの質を高めてより良いアウトプットを期待していたが それだけでなく、人間にとっても認知負荷を下げることにつながった
42. 得られた成果・気づき インフラメンバーとのコミュニケーションの変化 それまではお互いから何か依頼ごとがあればコミュニケーションをとる形 今回の取り組みによって課題解決のために今よりも深いコミュニケーションを とって連携ができているように感じた
43. Copyright © DIP Corporation, All rights reserved. 今後の展望・課題
44. 今後の展望・課題 本番環境にデプロイした後の運用、管理 まだ、リアーキテクチャをしている途中で本番環境にデプロイできていない 今後、デプロイした後にどのように運用、管理をするかというイメージが 自分の中で言語化できていない インフラのチームにコミュニケーションをとって 構築したリソースを本番環境にデプロイ後にどのような業務をしているのか 聞いてみるところから始める
45. 今後の展望・課題 リソース管理の最適化 まだ、最適な構成でリソースやモジュールの管理が出来てはいないと思う ここもインフラチームにコミュニケーションを密にとってキャッチアップして 構成を進化させていきたい 今だとterragrunt 気になっている
46. 今後の展望・課題 作業の分担が難しい state で管理するといった性質上、アプリケーションのコードのように 複数人での分担や並行でタスクを進めていくことが難しい 細かい単位でPR を出して細かい単位でapply していくといった方針で plan 結果を細かい単位で反映し、タスクを分割できる状態に整理する モジュール管理やstate の単位を適切な範囲で行うよう構成を進化させていきたい
47. 今後の展望・課題 ポイントの見積もり精度 まだまだ不慣れな領域のため、見積もりの精度が悪い 難しそう、時間がかかりそうと言った所感で見積もったが、 意外とすぐ終わってしまったというケースが多く、ベロシティがブレてしまった ただ、うまく見積もれていないということに気づけていることはプラス
48. 今後の展望・課題 組織の取り組みの展開、文化の醸成 今回のような取り組みを組織へ展開、共有することで 領域による縦割りの体制からよりアジャイルな組織へと進化していけると 感じた そのために、組織へ取り組みを展開することで 領域に関係なく開発組織全体がDevOps としてワンチームで同じ方向に向いてい けるキッカケになればと良いなと思う
49. Copyright © DIP Corporation, All rights reserved. ご清聴ありがとうございました！ 少しでもIaC のハードルが下がっていれば幸いです！