クラウドを最大限活用するinfrastructure as codeを考えよう

Copyright © NTT Communications Corporation. All Rights Reserved.
クラウドを最大限活用するInfrastructure as
Codeを考えよう
NTTコミュニケーションズ
イノベーションセンター　テクノロジー部門
牧志　純
1

Infrastructure as Code
インフラをコードで記述し、ソフトウェアと同じように取り扱うプラクティス。コードを
実装・変更し、テストし、それを本番に適用する一連のアプローチとそれを構成す
る技術。
Deﬁne everything as code.
Deﬁning all your stuff “as code” is a core practice for making changes rapidly and
reliably. There are a few reasons why this helps:
● Reusability
● Consistency
● Transparency
2
"Infrastructure as Code: Dynamic Systems for the Cloud Age", Kief Morris, O’Reilly

自己紹介
3
NTTコミュニケーションズ
プラットフォームアーキテクト
牧志　純
略歴
● OpenFlowなどのSDN技術開発
● エンタープライズクラウドのNWオーケストレータ開発
● アメリカシリコンバレー駐在(2016 - 2019)
● DevOpsプラットフォーム開発(現在)
外部発表
● KubeCon 2019 Europe
● Google Cloud Next Tokyo 2019
● KubeCon 2020 Europe
@JunMakishi
https://github.com/j-maxi

NTTコミュニケーションズの
プラットフォームサービス開発
4

Flexible InterConnect
5

Super OCN Flexible Connect
6

裏側はGCP/GKE Kubernetes 
クラウド上でマイクロサービスを高
速で開発できるSDKを整備
共通機能を整備することで、
標準アーキテクチャでコントローラを
量産
Preview
Active
コンテナ基盤およびその運用モ
デル (SRE) を標準化
DevOps
platform
Design
Patterns
アプリケーション開発者の
End-EndのDevOps (CI/CD)
を支援するデザインパターン
／カタログを提供
裏側 - ソフトウェア基盤技術の標準化
7
SDK Portal
サービタイゼーション
共通コンポーネント
KUJIRA基盤
Qmonus SDK

Infrastructure as Codeを分解する
8

Cloudの普及
9
分散されたコンポーネント、サービスを組み合わせる時代
● Microserviceの普及
● Purpose-build databaseを使ったアーキテクチャパターン
● Multi Cloudの採用
2021 HashiCorp State of Cloud Strategy Survey (https://www.hashicorp.com/state-of-the-cloud)

競争力としてのInfrastructure as Code
Infrastructureをコードで管理することは強い組織の必要条件
● 早くかつ安全にインフラを変更するためにはきちんとした変更管理が必要 *1
● あとからコード化・自動化するのは手遅れになるケースが多い
Infrastructure as Codeはツールだけの話ではない
● 組織として、インフラとその上のアプリケーションのライフサイクルをどう管理するか
● 組織によって、最適なツールスタックが異なる
Infrastructure as Codeのツール/エコシステムが解く課題を分析し、組織に
あったツールスタックを組み方を考察する
10
*1 "2020 Puppet State of DevOps Report", https://puppet.com/resources/report/2020-state-of-devops-report

Infrastructure as Codeを分解する
Feedback loop
Test
Workﬂow
User Interface どうやってインフラをコード定義するか。
どうやってインフラに設定を適用するか（順序）。
どうやってインフラが正常か確認するか。
どうやってインフラを観察し期待値に収束させるか。
User
Infrastructure
11

本発表のフォーカス
Feedback loop
Test
Workﬂow
User Interface どうやってインフラをコード定義するか。
どうやってインフラに設定を適用するか（順序）。
どうやってインフラが正常か確認するか。
どうやってインフラを観察し期待値に収束させるか。
User
Infrastructure
12

Terraform、Kubernetesを例に考える
13
Feedback loop
Test
Workﬂow
User Interface
Terraform
Kubernetes
+kubectl
HCL
(Hashicorp Conﬁguration Language)
YAML
Reconcile Loopによる
コンテナ (Pod) の自動構築
Stateファイルを使った
Diffの計算
宣言されたものを
kubectlで１つ１つ適用
変更のPreview Dry Run
依存関係を自動解決

User Interface
インフラを制御するコード定義であり、ソフトウェア開発者が実装・管理する対象。
ある程度の規模になると、共通的なコードと環境依存のコードを分離し、さらにテンプレートやオー
バーレイを使ってコードを実装・保守メンテしたくなる。
14
## GCP Memorystore (REDIS) ###
resource "google_redis_instance" "cache" {
name = "ha-memory-cache"
tier = "BASIC"
memory_size_gb = 1
location_id = "asia-northeast1"
redis_version = "REDIS_4_0"
}
YAMLでリソースを１つ１つ宣言する。
HCLでリソースを１つ１つ宣言する。
## Deployment ###
apiVersion: v1
kind: Deployment
metadata:
name: redis
spec:
template:
...
Terraform Kubernetes (+kubectl)
User Interface

Workﬂow
インフラ制御を実行する方法および、その実行順序を制御する方式。
CI/CDパイプラインの中で順序を明示的に指定(kubectlを呼ぶ順番を制御) するだけでなく、ツー
ルによっては自動で順序を解決する。
15
## GCP Memorystore (REDIS) ###
resource "google_redis_instance" "cache" {
name = "ha-memory-cache"
authorized_network =
google_compute_network.test.self_link
}
kubectlコマンドで明示的に順番に設定
リソース間のDependency graphを自動解決
networkを先に構築してから redisが作
成される
### Ingress設定前にPodをReady stateにしたい ###
$ kubectl apply -f resources.yaml
$ kubectl apply -f gce-ingress.yaml
※ Kubernetes標準のリソースは順序を意識
しなくて良いものがそもそも多い
Workﬂow

Test
定義したコードを試験する方式、および実際に設定したインフラを試験する方式。
セキュリティポリシー通り設定されているか検査することも必要(例： CIS Benchmark)。
ある程度の規模になると、インフラを設定・確認する
sandbox環境が欲しくなる。
16
$ terraform plan
# google_redis_instance.cache will be created
+ resource "google_redis_instance" "cache" {
+ name = "ha-memory-cache"
+ id = (known after apply)
...
}
Plan: 1 to add, 0 to change, 0 to destroy.
サーバ側でリソースを作成せず検査する
適用する変更点のPreviewを見て確認
### Server Side Apply (option: DryRun) ###
kubectl apply -f target.yaml --dry-run=server
Test

Feedback loop
宣言したコード通りにインフラ設定を収束する方式。
過去にデプロイしたインフラのStateを持ち、今回適用するコードとの差分を計算し、期待値に収束さ
せる。
17
$ terraform apply
# google_redis_instance.cache will be updated in-place
~ resource "google_redis_instance" "cache" {
~ memory_size_gb = 10
}
...
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
tfstateファイルに保存したstateと比較し変更を適用
コントローラのReconcile loopにより状態
を観察・収束
Deployment/
ReplicaSet
Controller
が作る
Deployment
ReplicaSet
Pod (Container)
Feedback loop

ツールを組み合わせる
設定したいインフラの性質、管理したいライフサイクルの単位を考慮して、
ツールスタックを作る
18
HCL
ArgoCD
YAML
Terraform
Feedback loop
Test
Workﬂow
User Interface
組み上げ例
（NTT Comの例ではありません）
GCPリソースをデプロイ
するスタック
コンテナをデプロイする
スタック
Container
Kubernetes
(Deployment)

インターフェースの複雑化
リソース数の増大に伴い、インターフェース管理が複雑・煩雑化してくる。
一般的なProgramming言語で活用してきたソフトウェア開発アプローチを適用していきたい。
（例：　コンテクストをモジュールにまとめる）
19
Feedback loop
Test
Workﬂow
User Interface
依存関係がわかりにくく、
見通しが悪くなってくる
(module化を進める？）
環境ごとのリソース定義を重複して
管理することで保守コストが増大
HCL
ArgoCD
YAML
Terraform
Container
Kubernetes
(Deployment)

期待するライフサイクルとFeedback loopの乖離
単体のツールだけではリソースのライフサイクルと、実際に変更を計算・適用する
Feedback
loopの頻度が合わなくなってくる。
● 本来はリソースごとに変更したいアクター、変更頻度が異なる
○ Conﬁguration Driftを強く制限したいリソースは早い
Feedback loopを
● 1つの大きなFeedback loopでは変更管理が大変
20
Feedback loop
Test
Workﬂow
User Interface
全リソースを一括で
変更管理する大きい
Feedback Loop
(Stateを分ける?)
HCL
ArgoCD
YAML
Terraform
Container
Kubernetes
(Deployment)
プリセットされたリソース
(例: Deployment, ReplicaSet)
のための小さいFeedback Loop

Infrastructure as Codeでぶつかる壁
● 分散するリソース定義とコスト高な変更管理
○ 「ここを変更する場合、こっちも変更しないとダメだよ」
● 属人的なノウハウ
○ 「ここで宣言してるリソースって何に使ってるんですか？」
● ガバナンスを効かせにくい
○ 「この命名規則に基づいて管理してるので独自で命名しないで」
● 独自Script/DSLの保守コスト増大
○ 「Python + Jinjaでテンプレート化したツールをどうやって試験しよう・・」
● アプリ開発者がコントロールできない
○ 「新しいクラウドサービスを試したい？ PRを作ってインフラ担当の Approvalをもらってください。次
のリリースで適用します。」
● 第三者の変更に気づけない
○ 「パブリッククラウド側のバージョンアップで設定値が変わっていました」
21
※個人の経験の一例

Infrastructure as Codeのエコシステム
※　どのツールが良い・悪いと述べるつもりはなく、
各ツールがどのような課題を解いているのか簡単に探索していきます
22

Kustomize
Kubernetesのマニフェスト/設定ファイルについてレイヤ管理するためのソリューション。複雑化す
るUser Interfaceの課題を解く。
23
root
├── base
│ ├── configMap.yaml
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── production
│ ├── deployment.yaml
│ └── kustomization.yaml
└── staging
├── kustomization.yaml
└── map.yaml
共通の
マニフェスト
環境特有の
マニフェスト
User Interface
環境差分を効果的に管理することができる
ため、Kubernetes利用時の最初の選択肢
となる。
● 共通マニフェストに対して、環境特有の設
定をOverlayする。
YAMLゆえに表現力が限定的かつ
Validationが弱い印象。

Pulumi
General Purpose Language (Javascript, Python, Golang, .NET) を使って、インフラを制御する
ためのソリューション。
24
User Interface Feedback loop
Workﬂow
一般的なプログラミング言語でマルチクラウドの設
定順序を指示
ステートを持ち、
適用すべき変更を計算
ソフトウェア開発者の手でマルチクラウド
をコントロールできる
● 馴染みのある言語を User Interfaceとし
て採用できる
● Stateを使ったFeedback loopがある
リソース数が多くなると、過度に抽象化し
てしまったり、巨大なプログラムになってし
まう傾向があり、IaC専用のテクニックが求
められる。

番外編: Pulumi Sample
Serverless functionのlogicを書きながら、そのデプロイまで１つの
typescriptで書くことができる
のなど、General Purpose Languageならではの長所を活用できる。
25
API Gateway
AWS Lambda

Crossplane
異なるベンダのインフラをKubernetesのAPIからコントロールするためのソリューション。
2021年9
月14日にCNCFのIncubating projectに。
26
Feedback loop
Workﬂow
Universal Control Plane
Controlled by Kubernetes’
Reconcile Loop
ユーザは宣言的APIを叩くだけで、残りはサーバ側で
ステートをコントロールしてくれる。クライアント側では
User Interfaceに注意すれば良いので、スケールする
（はず）。
● Kubernetesは分散コントローラとして良くできている
ので、Kubernetesにまとめたいと考えるのは自然な
流れ。
コミュティが大きくなってきており、ベンダ
APIの進化に
タイムリーに追従できるか注目したい。

番外編: PaaSの土台としてのCrossplane
複数のリソースを集約(compose) して、１つの抽象化したKubernetes APIとしてユーザに提供す
ることができ、独自のPlatformサービスを構築できるポテンシャルがある。
27
from: https://github.com/crossplane-contrib/crossplane-cdk8s
エンドユーザが利用する API
CrossplaneのReconcile loop
で複数のリソースをデプロイ

NTT CommunicationsのInfrastructure as Code
28

クラウドを活用するためのConﬁguration as Data
インフラ設定 (Conﬁg) をCodeではなくDataとして捉え、アグレッシブにインフラを管理。
● Dataを最適な単位のFeedback loopで動的に検査・生成・処理する。
○ 安全に早くインフラを変更する。また、変更頻度を意識してループ設計をする。
● そのDataを生成するCode (User Interface) は別で考える。
○ CI/CDはDataを処理するパイプラインと考える。
29

効果的なFeedback loopを考える
DevOpsのサイクルも立派なFeedback loop。
● CI/CDパイプラインの中でConﬁguration (Data) を計算・検査・適用する。
● 適用するタイミングをコントロールし、統一的なワークフローを適用できる。
全てをReconcile loopにまとめるのは早計。
● 分散システムで、Control Loopを手懐けるのは難しい。
● 連続するControl loopが問題でエラーが伝搬する、または復旧できない恐怖 *1。
システムの特性によってインフラのライフサイクルを見極め選択できることが重要。
● 例：Autoscalingを使うか、自分で観察・試験してからスケールアウトするか
30
DevOps Kubernetes
Reconcile Loop
vs
*1 Metastable Failure in Distributed Systems,
https://sigops.org/s/conferences/hotos/2021/papers/
hotos21-s11-bronson.pdf

効果的なUser Interfaceを考える
構造化されたDataを処理するのに適したインターフェースを使いスケールさせる。
● Config (Data) 生成ロジックの実装に、ソフトウェア開発のプラクティスを反映。
● 柔軟性も大切だが、Config (Data) 構造をシンプルに処理したい。
● Config管理のために複雑な独自システム・ルールを作り上げるのは避けたい。
● Dataをそのまま愚直に宣言する (ハードコードする) 方が最良なケースもある *1。
31
Configuration Complexity Clock,
http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html
Configの
ハードコード
パラメータ地
獄
複雑な
独自スクリプト
独自DSL
=Config生成
ソフトウェア

CUE言語の採用
● Data unificationに特化
○ データを任意の階層で結合し、Dataを生成できる。
○ 結合の順序に関係なく一貫した結果を生成できる。
● TypeもValue
○ TypeもValidationもValueであり、シンプルにDataの検査が
できる。
● プログラマビリティ
○ Module化などソフトウェア開発プラクティスを適用できる。
○ Go APIをサポート。
32
// Data
Alice: age: 20
// Type
People: age: int
// Constraint
Member: age: > 18
// Validate
Alice & People & Member
Types are Values
CUE
Google / Borgで利用されているGCL (Configuration Language) の著者の1人であるMarcel
van Lohuizenがその経験を元に一から作り上げた Configuration言語

Qmonus Value Streamの開発
33
Build Test
Pipeline
Qmonus Value Stream
Delivery
User Interface
Workﬂow
Feedback loop
DevOpsのFeedback loopを高速に回すための内製プラットフォーム
● CUEでモジュール化したマルチクラウドの
Deploymentカタログを提供
● アプリケーション単位でパラメータを変更しながら
Feedback loopを回しやすくする仕組
み (CI/CDパイプライン) の提供
アプリケーション単位で
コントロールするループ
TM

デモ１: Qmonus Value Streamを使ったデプロイ
34
Build Test
Online Butique Deployment
Design Pattern
Pipeline
Qmonus Value Stream
Delivery
Kubernetes
Manifest
Validate & Generate

デモ２: GCP Memorystoreの利用
35
Build Test
Online Butique Deployment
Design Pattern
Pipeline
Qmonus Value Stream
Delivery
Kubernetes
Manifest
Validate & Generate
Memorystore
Design Pattern
GCP
Manifest
CUEを活用して、Package化されたDeploymentレシピをCompose

デモ３: GCP Memorystoreのスケールアップ
36
Build Test
Pipeline
Qmonus Value Stream
Delivery
Memorystore Parameterを変更して、再デプロイ
CI/CDを活用したFeedback Loop

番外編: 小さいFeedback Loopの導入
37
Build Test
Pipeline
Qmonus Value Stream
Delivery
Argo Rollouts
Feedback loop
作り上げた大きいFeedback loop (CI/CDパイプライン) からリソースを切り出して、
宣言的APIで小さくコントロールしたいFeedback loopを導入していく。
● 例： Argo Rolloutにより、Blue/Greenデプロイ処理はコントローラに委譲する。
● 必要ならCrossplaneも使っていく。

最後に
38

まとめ
Infrastructure as Codeはソフトウェア競争力の源泉
● アプリケーションを継続的に開発して、ユーザに価値を届ける、ビジネスを発展させるための
基礎
● Infrastructureへ投資し続けるためのEnabler
User InterfaceおよびFeedback loopをどう組み上げるかが重要
● Conﬁguration as Dataのプラクティスの広がり
● リソースのライフサイクルを見極めて、
Feedback loopを設計する
● User Interfaceにソフトウェア開発プラクティスを適用する
● NTTコミュニケーションズで開発したQmonus Value Streamの組み上げ例：
○ User Interface　＝　CUE言語
○ Feedback loop　＝　アプリ開発者が小さく回すことができる
CI/CDループ (Tekton +
Pulumiの上に独自で実装したソフトウェア
)
39

取り組み紹介
　Qmonus Value Stream開発の取り組みと技術
● "社内DevOps基盤、Tekton、Cuelang", Fukabori.fm, episode 50, https://fukabori.fm/episode/50
● "Deliver Your Cloud Native Application with Design Pattern as Code", KubeCon Europe 2020,
https://sched.co/ZeiY
40
その他 Infrastructure as Codeで操作できるインフラの拡充と展開も進めています
● APIで操作できるインフラ・プラットフォームサービス(Smart Data Platform)

We are hiring
プロダクト志向で、DevOpsプラットフォーム = Qmonus Value Streamを一緒に開発し
てくれるメンバーを募集しています！
41
社内で得た経験 (ユーザ検証) を元にアーキテクチャをアップデート中
興味がある方は採用ページまたは　　　@JunMakishi まで

本発表についての問い合わせは 
NTTコミュニケーションズ　イノベーションセンター 
テクノロジー部門　DevOps基盤PJ 
までお願いします 
42

クラウドを最大限活用するinfrastructure as codeを考えよう

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à クラウドを最大限活用するinfrastructure as codeを考えよう

Similaire à クラウドを最大限活用するinfrastructure as codeを考えよう (20)

Plus de NTT Communications Technology Development

Plus de NTT Communications Technology Development (20)

クラウドを最大限活用するinfrastructure as codeを考えよう