Infrastructure as Codeで壁を越える技術を身につけよう！

INFRASTRUCTURE AS CODE で壁を越える技術を⾝につけよう︕
© 2023, Amazon Web Services, Inc. or its affiliates.
< #AWSDevLiveShow
⾼野賢司
ソリューションアーキテクト
アマゾンウェブサービスジャパン合同会社
Infrastructure as Code で
壁を越える技術を⾝につけよう︕
A W S D E V E L O P E R L I V E S H O W 2 0 2 3
⼯藤朋哉
Prototyping Engineer
⼭崎宏紀
ソリューションアーキテクト

View Slide

< #AWSDevLiveShow
エンジニアの⼼理的な『壁』と
Infrastructure as Code
今⽇のテーマ

View Slide

< #AWSDevLiveShow
3
⾼野賢司⼯藤朋哉⼭崎宏紀
ソリューションアーキテクト Prototyping Engineer ソリューションアーキテクト
ビルドやデプロイが
成功する瞬間
新しい技術に
触れている瞬間
⾃動化したタスクが
うまく動いた瞬間
皆様の「エンジニアをやっていて楽しいと思う瞬間」を #AWSDevLiveShow でツイートしてください︕

View Slide

< #AWSDevLiveShow
エンジニアの職務満⾜度と『楽しさ』
4
リーン
マネジメント
継続的
デリバリー
職務満⾜度
組織の
パフォーマンス
出典: LeanとDevOpsの科学［Accelerate］
テクノロジーの戦略的活⽤が組織変⾰を加速する
職務満⾜度を向上させる要素
• 仕事で必要なツールとリソースを
従業員に提供する（選択の⾃由が必要）
• ⾃⾝の専⾨知識を活⽤できる
有意義な仕事を従業員に提供する
出典: https://dora.dev/devops-capabilities/cultural/job-satisfaction/
アーキテクチャ設計、開発、⾃動化、ピアレビュー
監視、分析、デバッグ、ドキュメント作成
⼿動での作業、障害対応、チーム間の調整
エンジニアにとって楽しいタスク
減らしたい
※ 個⼈の感想です

View Slide

< #AWSDevLiveShow
Infrastructure as Code で壁を越える技術を⾝につけよう︕
1. めんどうな⼿作業の壁
2. 未知の技術の壁
3. チームの⽂化の壁
今⽇話さないこと︓
Infrastructure as Code (IaC) ツールやクラウドサービスの詳細・⽐較
7
皆様の「エンジニアをやっていて壁を感じる瞬間」を #AWSDevLiveShow でツイートしてください︕

View Slide

< #AWSDevLiveShow
めんどうな⼿作業の壁
8

View Slide

< #AWSDevLiveShow
⼿作業、つらくないですか︖
• ⼿作業での環境構築、ダブルチェック
• 構築⼿順書の作成、更新、レビュー
• インフラの詳細設計書、パラメータシートの作成
• 設定値の指差し確認
• ⾃分だけの開発環境がない
• テスト環境が本番環境と違う
• 「あの環境、今どんな設定だっけ︖」
9

View Slide

< #AWSDevLiveShow
Infrastructure as Code (IaC) とは︖
⼿動ではなく、コードによって
インフラストラクチャの管理やプロビジョニングを⾏うプロセス
10
ソースコード
IaC ツール
クラウドリソース
ソフトウェア開発のプラクティスをインフラ構築の⾃動化に活かす
継続的デリバリーに必須の技術のひとつ
リソースは
この状態であるべき
（宣⾔的）
⽬的の状態に
収束
https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html

View Slide

< #AWSDevLiveShow
IaC で⼿作業をなくそう
• 作業ミスや解釈違いが発⽣しない
• 作業時間を拘束されない
• リソースが正しく設定されることを
IaC ツールが担保
• いつでもリソースを作成・破棄
• 以前の状態にロールバック可能
• リソースの依存関係を⾃動で解決
11

View Slide

< #AWSDevLiveShow
「うちの会社では使えない…」︖
IaC が置き換えるものを理解しましょう

View Slide

< #AWSDevLiveShow
インフラ構築の V 字モデルと IaC
13
要件定義
基本設計
詳細設計
実装・デバッグ
単体テスト
結合テスト
総合テスト
Why
What
How
• 要件定義書
• ⾮機能要件定義書
• 基本設計書
• 詳細設計書
• 構築⼿順書
• パラメータシート
検証
ドキュメント通りに構築・設定されたことを確認
複数のコンポーネントが期待通りに振る舞うことを確認
• IP アドレスやホスト名、OS のタイムゾーンが正しいか
• HTTP サーバーのバージョンや設定が正しいか
• ディレクトリの名前やパーミッションが正しいか
• 定期実⾏ジョブが正しく定義されたか ...etc
• ある拠点から SSH でログインできるか
• インターネット経由で Web ページが正しく表⽰されるか
• 定期実⾏ジョブが時刻通りに実⾏されるか ...etc
システム全体が期待通りに振る舞うことを確認
• パフォーマンスは⼗分か
• ⾼負荷時にも正しく応答するか
• 意図しない⼈がアクセス可能でないか ..etc
IaC で置き換え可能な範囲

View Slide

< #AWSDevLiveShow
インフラ構築の V 字モデルと IaC
14
要件定義
基本設計
IaC 実装・デプロイ
結合テスト
総合テスト
Why
What
• 基本設計書
検証
複数のコンポーネントが期待通りに振る舞うことを確認
• ある拠点から SSH でログインできるか
• インターネット経由で Web ページが正しく表⽰されるか
• 定期実⾏ジョブが時刻通りに実⾏されるか ...etc
システム全体が期待通りに振る舞うことを確認
• パフォーマンスは⼗分か
• ⾼負荷時にも正しく応答するか
• 意図しない⼈がアクセス可能でないか ..etc
マネージドサービスで設計とテストを単純化。アプリとインフラの境界が曖昧に
顧客のストーリーやアーキテクチャ決定の経緯（Why）がより重要に
• コードレビュー（ピアレビュー）
• ユニットテストの⾃動化
• 静的チェック（SAST）
• 要件定義書
• ⾮機能要件定義書
ドキュメントとしてのコード

View Slide

< #AWSDevLiveShow
Infrastructure as Code は継続的デリバリーの基礎
15
バージョン管理
環境の分離
セキュリティの
シフトレフト
継続的
インテグレーション (CI)
トランクベース開発
デプロイの⾃動化
プルリクエストと
ピアレビュー

View Slide

< #AWSDevLiveShow
• ⼿作業での設定では
ミスが避けられず再現性がない
• ⼿順書を読んで状態を理解するには
脳内にインタープリタが必要
• ⼿順書にない操作を排除するには
エラー処理や条件分岐が複雑になる
• 詳細設計書やパラメータシートも
⾃然⾔語である必要性は薄い
（理解できるのはエンジニアだけ）
本当は難しい『⼿順書』

View Slide

< #AWSDevLiveShow
個⼈の意識を変⾰する⽅法︓まずは試してみる
20
new ec2.Vpc(this, 'Vpc', {
ipAddresses: IpAddresses.cidr('10.0.0.0/16'),
maxAzs: 2,
natGateways: 0,
}
TypeScript
1. VPC などをクリック
2. 名前タグの⾃動⽣成の欄に handson-ユーザ名と⼊⼒。例) handson-user1
3. サブネット CIDR ブロックをカスタマイズを展開
4. ⼀番⽬のサブネットの CIDR ブロックのap-northeast-1aを 10.0.0.0/18 に変更
5. ⼆番⽬のサブネットの CIDR ブロックのap-northeast-1cを 10.0.64.0/18 に変更
6. 三番名のサブネットの CIDR ブロックのap-northeast-1aを 10.0.128.0/18 に変更
7. 四番⽬のサブネットの CIDR ブロックのap-northeast-1cを 10.0.192.0/18 に変更
8. NAT ゲートウェイはなしを選択
9. VPC エンドポイントはなしを選択
10. その他はデフォルトのままにする
11. VPC を作成をクリック
※ その他の項⽬はデフォルトのままにします。
⼿順書
IaC (AWS CDK)
vs

View Slide

< #AWSDevLiveShow
Infrastructure as Code は
エンジニアが
楽しい仕事に集中するための鍵

View Slide

< #AWSDevLiveShow
未知の技術の壁
22

View Slide

< #AWSDevLiveShow
IaC に踏み出せない要因をヒアリングしてみた
• モダンなプログラミング⾔語の経験がない
• プログラミングの周辺ツールがわからない
• 構築するサービスの経験がない
• 全部細かく設定しないと気が済まない
• 勝⼿に環境が壊れてしまいそう
• ユーザーにリクエストされていない
• プロジェクトマネージャーの賛同を得られない
23

View Slide

< #AWSDevLiveShow
IaC はアプリとインフラそれぞれの『隣』にある
24
インフラエンジニアのスキルアプリエンジニアのスキル
IaC で求められるスキル
ネットワークストレージ
OS ミドルウェア
データベースセキュリティ
シェル
スクリプト
ジョブ管理・
⾃動化
プログラミング
⾔語
フロントエンド
コンテナ
コンテンツ
配信
データベースセキュリティ
データ分析
ソフトウェア
設計
簡単なプログラミング⾔語または DSL
Git と Pull Request
クラウドサービスの基礎知識
ビルドとデプロイの⾃動化

View Slide

< #AWSDevLiveShow
アプリとインフラの境界が曖昧になっている
アプリケーションデータ
アプリケーション処理コード
サーバーサイド間通信暗号化
冗⻑化
プラットフォーム、アプリ実⾏基盤
OS保守、パッチ適⽤
ネットワーク構成
コンピューティングリソース
オンプレ
インフラ
例︓EC2
コンテナ
例︓ECS
サーバーレス
例︓Lambda
AWSが提供するレイヤー
お客様に管理いただくレイヤー
コンピューティングサービスその他のサービス（200以上）
Amazon SNS Amazon SQS
Amazon DynamoDB Amazon RDS
AWS CodePipeline AWS Amplify
Amazon VPC Amazon S3
アプリとインフラをサービス単位で分けられない⼀⽅で、IaC でまとめて管理できる

View Slide

< #AWSDevLiveShow
Infrastructure as Code を
あなたの⼿になじんだ道具にしよう

View Slide

< #AWSDevLiveShow
組織の⽂化の壁
27

View Slide

< #AWSDevLiveShow
組織の形はいろいろ
アプリ
開発
アプリ
運⽤
プラット
フォーム
運⽤
プラット
フォーム
開発
従来モデル
サービスチーム
DevOps モデル
アプリ
チーム
プラットフォーム
チーム
CloudOps モデル
ほかにも・・・
• ガバナンスチームが独⽴して⼀元管理
• サービスチーム内にセキュリティガーディアンを配置
• CCoE やマネージドサービスプロバイダーが介在など

View Slide

< #AWSDevLiveShow
あなたの組織の形は︖
29
開発運⽤
アプリ
インフラ

View Slide

< #AWSDevLiveShow
組織の⽂化を変⾰する⽅法︓メカニズムをつくる
30
プラットフォーム
チーム
サービス
チーム
App
Security
内部サービス
または
IaC テンプレート
利⽤公開
Infrastructure
インフラ
エンジニア
アプリ
エンジニア
共働
コードによる
コラボレーションセルフサービスで
チーム間を疎結合に
チームが
サービスを所有
ガードレールと
助⾔を提供
DevOps モデル
アプリ全体を
コードで定義

View Slide

< #AWSDevLiveShow
Infrastructure as Code で
チームが協働するメカニズムを作ろう

View Slide

< #AWSDevLiveShow
Thank you!
⾼野賢司⼯藤朋哉⼭崎宏紀
@konokenj @yh1roki

View Slide

Infrastructure as Codeで壁を越える技術を身につけよう！

Infrastructure as Codeで壁を越える技術を身につけよう！

Kenji Kono

More Decks by Kenji Kono

Other Decks in Programming

Featured

Transcript